[レポート] 正しく選択できているか?AWS が提供するマネージドデータベース #awssummit

こんにちは、菊池です。

本日は、ドイツ・ベルリンで開催中のAWS Summit Berlin 2019に参加しています。

本記事はセッション、「Choosing The Right Database」のレポートです。AWSが提供する数多くのマネージドデータベースサービスの中から、アプリケーションに最適なものを選択するにはどうすべきか?という内容です。

セッション概要

How to choose the right database for your applications. AWS offers the broadest range of purpose-built databases for specific application use cases. This block will provide an overview of AWS relational, key-value, in-memory, and graph databases to help customers choose the right database for the right job. RDS, Aurora, DynamoDB, ElastiCache, Neptune + etc. (all managed databases). We'll also breifly cover new launches (Timestream, Quantum, and more) and how to apply them to your existing and new applications - with real customer examples.

スピーカーは、Randall Hunt, AWS です。

レポート

  • モダンなアプリケーションに対する要件
    • ユーザー数:百万以上
    • データボリューム:TB - PB - EB
    • ロケーション:グローバル
    • パフォーマンス:msec - microsec
    • リクエスト:100万/sec
    • アクセス元:web、モバイル、IoT、デバイス
    • スケーラビリティ:スケールアップ/ダウン、スケールアウト/イン
    • 経済性:使った分だけ課金
    • 開発:アッセンブリ不要

  • 主要なデータベースプロダクト登場の歴史

  • 一般的な分類とユースケース
    • RDB
      • 特徴:ACIDトランザクション
      • 用途:リフトアンドシフト、ERP
    • キー・バリュー
      • 特徴:高スループット・低レイテンシ・スケーラブル
      • 用途:ショッピングカート、ソーシャル、カタログ
    • ドキュメント
      • 特徴:要素への柔軟なクエリ
      • 用途:コンテンツ管理
    • インメモリ
      • 特徴:超低レイテンシ
      • 用途:リアルタイム分析、キャッシュ
    • グラフ
      • 特徴:データ間の関係性
      • 用途:ソーシャルネットワーク、レコメンド
    • 時系列
      • 特徴:時系列に沿ったデータ処理
      • 用途:IoT、イベントトラッキング
    • 台帳
      • 特徴:全ての変更データを完全・不変に管理
      • 用途:金融、ヘルスケア

  • それぞれでAWSが提供するデータベースサービス

Amazon RDS

  • 主要なデータベースエンジンを提供
    • Aurora
    • MySQL
    • PostgreSQL
    • MariaDB
    • SQL Server
    • Oracle

  • Amazon Aurora
    • MySQLとPostgreSQL互換を提供
    • 商用データベース以上のパフォーマンス・可用性を1/10のコストで実現

  • 伝統的なSQL
    • TCPベースのプロトコル
    • よく知られ、使われている
    • 一般的なJDBCドライバ
    • 個々のインスタンスをスケールアップ可能
    • リードレプリカによるスケールアウト
    • アプリケーションレベルのシャーディング
    • 結合

Amazon DynamoDB

  • SQL vs NOSQL
    • SQL
      • ストレージに最適化
      • 正規化
      • アドホックなクエリ
      • 垂直スケール
      • OLAP向き
    • NOSQL
      • コンピューティング最適化
      • 非正規化・階層化
      • 水平スケール
      • OLTPのスケールのための設計
  • Amazon DynamoDB

  • DynamoDBのデータ構造

  • スキーマとクエリ
    • HTTP接続
    • インデックス:GSI、LSI
    • DAXによる高速化
    • Global Table(マルチマスター・マルチリージョン)
    • 複数テーブルのトランザクション
    • キャパシティのプロビジョニング
    • リクエスト課金モデルもサポート
  • 近年のアップデート
    • 2017.2:TTLサポート
    • 2017.4:VPC Endpoint
    • 2017.4:DynamoDB Accelerator(DAX)
    • 2017.6:AutoScaling
    • 2017.11:Global Table
    • 2017.11:On-demand backup
    • 2017.11:Encryption at rest
    • 2018.3:Point in time recovery
    • 2018.6:99.999% SLA
    • 2018.8:Adaptive Capacity
    • 2018.11:Transactions
    • 2018.11:On-demand

Amazon DocumentDB

  • 秒間数千リクエストをmsecオーダーのレイテンシ
    • MongoDBの2倍のスループット
  • スケーラブル
  • フルマネージド
  • MongoDB 3.6互換

  • ドキュメントデータベース
    • JSONドキュメントをストア
    • フレキシブルなスキーマとインデックス
    • 柔軟なクエリ言語
      • アドホック
      • 集計

Amazon ElastiCache

  • Redis と Memcached

  • Redis
    • TCPベースのプロトコル
    • 文字列、ハッシュ、配列、Sets、Sorted Sets
    • Pub/Sub機能
    • クラスタリングのサポート
  • Memcached
    • TCPベースのプロトコル
    • 最小のコマンド
    • クライアントアプリケーションベースのパーテイショニング

Amazon Neptune

リレーションのあるアプリケーション

  • Amazon Neptune

  • アーキテクチャ

  • GremlinもしくはSPARQL/RDF

Amazon Timestream

  • 時系列データベース

Amazon Quantum Ledger Database(QLDB)

  • フルマネージドな台帳データベース

データベースの移行(AWS DMS)

  • AWSへのデータベース移行として、DMSを提供

  • フルロードと継続的なデータ同期(CDC)による移行をサポート

  • AWSへデータベースの移行をおこなたユーザー
    • Amazon も2018年12月に移行を実施

ユーザー事例

後半で、ユーザー事例の紹介がありました。

一人目は、Team Internet AGの代表、Markus Ostertag氏。

IPデータベースのリアルタイム処理に課題を抱えていました。移行先のDBとして、RDB、キーバリュー、インメモリを比較して検討。

  • RDB
    • 長所:よく知っている、柔軟なクエリ
    • 短所:レイテンシ、将来的なスケール
  • キーバリュー
    • 長所:高スループット、低レイテンシ、スケーラブル
    • 短所:データ構造
  • インメモリ
    • 長所:超低レイテンシ
    • 短所:データスキーマ、将来的なスケール

結果的に、キーバリューであるDynamoDBを選択。データ構造はインデックス設計でクリアしたそうです。結果的に学んだこととして、

  • コアな要件に注目すること
  • マイナーな短所は受け入れる。完璧なソリューションは存在しない

もう一人、SiemensのDr. Sebastian Brandt氏から、ナレッジグラフの紹介がありました。こちらはグラフデータベースであるNeptuneを採用しているようです。

まとめ

いかがでしたでしょうか?何気に、AWS公式のセッション等でDocumentDBについて聴くのは初めてでした。ユーザーとして登壇していた、Markus Ostertag氏の完璧なソリューションは存在しないという考え方が印象的です。全てを完璧にすることを目指すのではなく、1つのことをうまくやるソリューションを組み合わせることが、上手な設計に繋がると思います。

アプリケーションに最適なデータベースを選択して、よりWell-Architectedなシステムを実現しましょう。