[レポート] “今だからこそ知りたい、AWSデータベース 2020 基礎”で9種類DB紹介されてましたが、みなさん全部知ってました? #AWSSummit

台帳データベースを大腸データベースと聞き間違え、一瞬固まりました。いろんなユースケースに合わせたデータベースを使っていきましょう!
2020.09.08

みなさんどうも、新卒エンジニアのたいがーです🐯

AWS Summit Online始まりましたね!今年のサミットはオンラインでの開催となり、2020/09/08~9/9に行われるライブセッションと9/30まで視聴可能なオンラインセッションで構成されています。

今日の朝会で"祭りが始まるぞ〜!!わっしょーい!!"と宣言したということで、早速ライブセッションのレポートを書いていきたいと思います!

実際のセッション動画はこちらからご覧ください!

現在、9種類(1つプレビューを含む)あるAWSのDBサービスですが、私はこのセッションを聞いて初めて出会ったDBもありました。それぞれの特性を知ることで、適材適所なDBを選べるようになっていきましょう!

スピーカー / このセッションの概要

アマゾン ウェブ サービス ジャパン株式会社 パートナー技術本部 ソリューションアーキテクト 髙橋 敏行さん

AWS におけるデータベースは、適材適所の選択が重要です。2020 年現在、AWS ではリレーショナルデータベース、key-value、ドキュメント、インメモリ、グラフ、時系列、台帳データベースを含む専用データベースエンジンから選択できます。本セッションではデータベースサービスの概要をお伝えし、AWS におけるデータベースの基礎をお伝えいたします。

今回のセッションにおけるキーワード

このセッションにおけるキーワードは、こちらの3つです。

  1. マネージドサービス
  2. Purpose built
  3. データカテゴリとデータベースサービス

セッションを聞いて、これらのキーワードを押さえられるようになりましょう!

データベース管理者の時間のうち注力したい領域に注げている時間は30%のみ

データベースの運用負荷

セッション内では、このような質問が投げかけられました。

  • 現在、何のDBを使っているのか
  • データベースの運用負荷は高くないか

オンプレミスのRDBを想像された人が多くいたのではないでしょうか。

こちらは従来のアプリケーション要件です。使われるところとしては、社内システムというのが多いのではないでしょうか。

(あとで比較として、最新のアプリケーションによる新しい要件が出てくるので、どのように変化していったのかもみていきましょう。)

オンプレミスのRDBにおいて、データベース管理は複雑で時間とコストがかかるものです。

実際に"データベース管理者のタスクと時間"というアンケートで、それぞれのタスクごとの割合を見てみましょう。

複雑で時間とコストがかかることにより、本来注力したい領域であるスクリプティングコーディングやパフォーマンスチューニングが全体の30%のみという結果になっているそうです。

マネージドサービス

そこで、AWSにおけるマネージドサービスを使いましょう!

マネージドサービスを使用することで、"スキーマ設計、クエリの構築、クエリの最適化"と言った本来注力したかった物だけに注力することができるようになります。

最新のアプリケーションによる新しい要件

最新のアプリケーションによる新しい用件ではアクセスも多様化され、高いパフォーマンス能力が求められるように変化してきました。

サービス自体も社内だけでなく、世界中に広がるようになったのにも関わらず、より低いレイテンシーが求められています。このような場合、今までのRDBだけではなく工夫が必要になってきます。

Purpose built

トラックと言っても、家庭用の物もあれば、工場への運搬に使われるものなどいろいろなものがあります。DBも同じです。

一言にDBと言っても、Relational以外にもたくさんのデータカテゴリが存在しています。合計7つです。

AWSのサービスでは、それぞれ7つのカテゴリで適用することができるマネージドデータベースサービスが提供されています。

つまり、ワークロードに応じて最適な選択が可能であり、"適材適所の選択"をすることができる、これがPurpose buildの考え方です。

Amazon.comのDBの移行

Amazon.comでは元々、Oracle Databaseを使っていました。しかし"Purpose build"の考え方を元に、適したDBに2016年から全てのDBをAWSに移行開始をしたそうです。

昨年Oracleデータベースを全て終了、全ての移行が完了し、ブログにも掲載されています。

データカテゴリとデータベースサービス

Relational databaseとAmazon Relational Detabase Service

Relational Databaseは、時間、ユーザーの名前などの一貫したデータのやり取り(トランザクション)をするのに適したデータベースです。スキーマ(複数の表)をリレーション(ある関係性)でつながった一つのモデルです。そのため細かな条件をつけて、結果を出すことが可能になっています。

従来の基幹システム、CRM、eコマースで使われている、データベースです。

AWSからは、Amazon Relational Database Service(Amazon RDS)が提供されています。

特徴としては、ハードウェアやソフトウェアのメンテナンスを行わなくていい、やりやすくなっています。

拡張もスピーディに可能であり、可用性の面も複数のDBを立ち上げ、レプリケートを行うことができます。また片方が落ちた場合、自動でフェールオーバーを行うように設定できます。

データエンジンは6つから選択可能です。

  • Amazon Aurora
  • MySQL
  • PostgreSQL
  • MariaDB
  • MicrosoftSQLServer
  • ORACLE

6つのデータベースエンジンの中には、AWSから提供されているAmazon Auroraというものがあります。

Amazon Auroraはクラウド向けに開発されたMySQL/PostgreSQLと互換性のあるRDBです。さらにOSベースであるためコストは1/10で済ませることができます。また、3AZに跨ってレプリケートやバックアップをを自動で行い、信頼性やパフォーマンスも高く設計構築されています。

RDSMSとNoSQLの違い

NoSQLは"Not only SQL"と言われ、RDBMSの課題を解決するために生まれました。 RDBMSではないDBの総称であるため、クエリの方法は各DBによって異なります。(RDBMSはSQLを使用可能)

RDSMSとNoSQLのそれぞれの特徴を見ていきます。RDSMSでは複数の人が書き換えたとしても一貫性を保つことができる、トランザクション処理を特徴としています。その点、NoSQLではトランザクション処理は限定的になっています。

NoSQLはトランザクションを限定的にすることで、シンプルなDBの形をしているため高いスケーラビリティが特徴になっています。

先ほどの図においてRelational以外のところは全てNoSQLとなっています。

それでは、NoSQLを一つずつ見ていきましょう。

Key-Value databaseとAmazon DynamaDB / Wide column storeとAmazon Keyspaces

Key-value databaseは、"キーとバリュー"という一対一のシンプルなデータで出来ていることによる、超高速なパフォーマンスが強みです。

RDBとは違い、厳格にスキーマを設定する必要がありません。なので、変更が柔軟にできるようになっています。

AWSからは、キーバリュー マネジメントデータベースサービスであるAmazon DynamoDBが提供されています。

特徴は、サーバレスのタイプであると言う点です。またシンプルである分、低レイテンシーでどんな規模でも対応ができます。データのレプリケーションも自動でとるため、信頼性も保証されます。

また、Wide column storeとして、Apache Cassandraと互換性のあるマネージドサービスのAmazon Keyspacesも提供されています。スケーラブルで高い可用性が特徴です。

Document databaseとAmazon DocumentDB

Document databaseはJSONやXMLと言う技法で書かれたデータを直接扱い、検索することができるDBです。Document DataはRDBで扱う場合、変換が必要でした。

AWSでは、ドキュメント用のDBとしてMongoDBと互換性のあるAmazon DocumenDBが提供されています。

高速、スケーラブル、高可用性が特徴です。低レイテンシーでデータのやり取りが可能です。

In-memory databaseとAmazon Elasticache

In-memoryはデータの使い方のことです。ゲームのランキングなどは、レイテンシーが低く、高速でやり取りが必要であるため、In memoryを使います。メモリの上で処理することによって、マイクロ秒単位でデータのやり取りをすることが出来ます。

AWSでは、Amazon ElastiCacheという低レイテンシーなRedis/Memcachedの互換性があるマネージドインメモリーデータストアが提供されています。

Graph databaseとAmazon Neptune

Graph databaseはデータ間を相互に結びつけ、それぞれのデータ同士の多対多の関係をグラフで表します。

ユースケースとしては、SNSニュースフィード、リコメンデーション、不正検出と言った関係性からの検索です。

AWSでは、マネージドグラフデータベースであるAmazon Neptuneが提供されています。

msのレイテンシーで数十億の関係を照会可能であったり、3AZのレプリケート、SPARQLと言う言語での検索も可能です。

Time-Series databaseとAmazon Timestream(プレビュー)

Time-Series databaseは、時間が主軸とされ、特定の間隔で記録され続ける時系列のデータベースです。

ユースケースは、アプリケーションイベントやIoTセンサー、DevOpsデータである細かいログデータを分析する時などです。

時系列データは、大量のデータを分析する、リレーショナルデータベースではデータが入り続けるため、負荷が高くなりすぎてしまうと言う問題点がありました。また、既存の時系列データベースは、スケーラビリティや高可用性、運用管理に問題がありました。

そこで、登場したのが、フルマネージドのAmazon Timestreamという時系列データベースサービスです。現在、プレビューとして提供されています。

Ledger databaseとAmazon Quantum Ledger Database(Amazon QLDB)

Ledgerは台帳という意味で、アプリケーションデータの変更履歴のデータベースです。今はどういったものが入っているのか、過去はどういったものが入っていたのかを表構造でアクセス可能です。トランザクションをハッシュ関数として保存をし、常に前に変更点を踏まえてハッシュ値を作っているため、履歴はイミュータブル(変更や削除が不可能)となっており、意図しない変更が発生していないことを検証します。銀行やECサイトなどで使われる、履歴が大事とされる場面で使われるデータベースです。

従来のデータベースでは、管理面や保守面でよく課題が発生していました。

Amazon Quantum Ledger Databaseはマネージド型台帳データベースとなっています。また、高い拡張性も実現しています。

AWSデータサービスの事例

先ほどにも記載しましたが、Amazon.comではOracle DatabaseからDynamoDBに移行することでこのような効果が得られました。

また、もう一つの事例としては、民泊サービスairbnbが挙げられていました。

それぞれのDBを目的によって使い分けています。

まとめ

  • 目的に応じてデータベースを選択する
  • AWSでは多様なデータベースの選択肢
  • ワークロードに応じて最適な選択が可能

今のデータベース、何のために使っていますか?

適材適所の選択を行いましょう!

感想

比較的に馴染みのあるDBから、馴染みのないDBまで多数紹介されました。

その中でも台帳データベースはセッションの途中で、台帳を大腸と聞き間違え、大腸データサービス・・・?台帳!!と一人で納得していました。(SNSで見てみると同じ方がいらっしゃって少親近感を感じました。笑)

ユースケースに応じて、その状況にあったDBを選択することは非常に重要なことです。これからもいろいろなDBサービスを触っていこうと思いました。

皆さんも状況に応じて、いろいろなデータベースを検討していきましょう!以上、たいがーでした🐯