【レポート】AWS におけるデータベースの選択指針 #AWSSummit

本日はAWS Summit Tokyo 2019に参加しています。 本エントリは「【初級】AWS におけるデータベースの選択指針」のセッションレポートになります。
2019.06.14

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、坂巻です。

2019/6/12(水)~14(金) の期間で開催されている、AWS Summit Tokyo 2019からセッションをレポートします。 本記事は「【初級】AWS におけるデータベースの選択指針」のレポートになります。

セッション情報

スピーカー:高橋 敏行氏 (アマゾン ウェブ サービス ジャパン株式会社)

データベースは、企業のシステムにおいて重要なコンポーネントの1つです。AWS ではデータベースを実行する方法に多くの選択肢があります。お客様がオンプレミスで使用しているデータベースを AWS に移行する際に、その選択肢の中から最適なものを選ぶガイドラインを、ユースケースと交えてご紹介します。

レポート

  • モバイル/IOTの登場で新しいアプリケーションの要件がでてきた
    • 従来のデータベースでは対応できない
  • 万能のデータベースは存在しない(Werner Vogels/CTO - Amazon.com)
    • "A one size fits all database doesn't fit anyone"
  • データベースの選択
    • AWSでは多様なデータベースの選択肢
    • ワークロードに応じて最適な選択が可能

適材適所に選択することが重要

データカテゴリ/AWSのデータベースサービス

  • リレーショナル:RDS
  • キーバリュー:DynamoDB
  • ドキュメント:DocumentDB
  • インメモリー:ElastiCache
  • グラフ:Neptune
  • 時系列:Timestream
  • 台帳:Quantum Ledger Database(通称QLDB)

全てマネージドサービス

自動化された管理タスク

  • データベース管理者
    • スキーマデザイン
    • クエリの作成
    • クエリの最適化
  • AWS
    • 自動化されたフェイルオーバー
    • バックアップとリカバリ
    • 分離とセキュリティ
    • コンプライアンス準拠
    • 数クリックでスケール
    • 自動化されたパッチ適用
    • 拡張モニタリング
    • 定期的に実施するメンテナンス

時間のかかるデータベース管理タスクを自動化
より付加価値の高いタスクに専念できる

データベース構築の選択肢

  • 仮想サーバ(EC2)
  • マネージド・サービス(RDS等)

マネージドサービスを使うと導入 & 運用面でメリットが多い
マネージドサービスで検討し、要件に合わない場合は仮想サーバを選択

リレーショナルデータベース

Amaon RDS
  • 6つのエンジン
    • Amazon Aurora
    • PostgreSQL
    • MySQL
    • MariaDB
    • Oracle
    • SQL Server

RDB(リレーショナルデータ)

  • テーブル間でデータを分割
  • 高度に構造化されたデータ
  • キーを介して確率された関係性
  • データの正確性と一貫性
ユースケース
  • エンタープライズアプリ
  • SaaSアプリケーション
  • Eコマースアプリケーション
  • ウェブアプリケーション
選択指針
  • 汎用的
  • 既存アプリケーション移行
  • 正規化/リレーショナル
  • SQLを使用可能
  • 柔軟なクエリ
  • トランザクション処理
  • データの堅牢性/一貫性

Non リレーショナル

NoSQL

  • RDBMSではないデータベースの総称
  • 従来のRDBMSの課題を解決するために生まれた
  • NoSQLは非常に多くの種類がある

リレーショナルデータベースでできなかったことを解決

RDBMSとNoSQLの特徴
  • リレーショナルデータベース
    • ストレージに最適化
    • 正規化/リレーショナル
    • SQLを使用可能
    • トランザクション処理
    • データの堅牢性/一貫性
    • スケールアウトの煩雑さ
  • NoSQL
    • 計算リソースに最適化
    • 非正規化/階層構造
    • データベースによる異なるクエリ
    • トランザクション処理は限定的
    • データの堅牢性/一貫性はデータベースによる
    • 高いスケーラビリティ

キーバリューストア

  • KVS
  • キーとバリューという単純な概念
ユースケース
  • あらゆる規模で低レイテンシー高スループットのデータアクセス
    • モバイル
    • ウェブ
    • ゲーム
    • 広告技術 etc
解決したい課題
  • インターネットスケールのシステム
    • スケール規模を事前に予測するのが難しい
    • 低レイテンシー/高スループットが求められる
  • RDBはスケールに限界がある
    • スケールアップはハードウェアの性能・容量に依存
    • スケールアウトさせるには分散管理が必要
選択指針
  • スケーラービリティが求められる
  • レスポンスタイム数ミリ秒が求められる
  • シンプルなクエリ

Amazon DynamoDB

  • 規模に関係なく数ミリ秒のレスポンス
  • 1日10兆件以上のリクエスト処理
  • 毎秒2千万を超えるリクエストをサポート

ドキュメントデータベース

  • JSONやXML等の不定形なデータ構造(キーバリューに近い)
  • 複雑なデータモデルを用意に表現
ユースケース
  • コンテンツ管理
    • ニュース記事、ブログ、レシピ 等
  • カタログ
  • プロファイル管理

頻繁に変化するデータを格納

解決したい課題
  • 頻繁に変更される属性情報
    • Amazon.comの商品属性情報
    • アプリケーションログ
  • RDBではスキーマ設計が必要
    • 全ての属性情報定義は難しい
    • 属性を定義しないとINSERTできない
選択指針
  • スキーマを決められないデータの格納
    • JSONやXML形式のそのまま扱いたい
  • 構造を意識したとキュメンと思考の検索

Amazon DocumentDB

  • フルマネージドなMongoDB互換
  • 読み取り容量を数百万件/秒までスケール

インメモリデータベース

  • KVS
  • 非常に高いパフォーマンス
  • Redis & Memcached
ユースケース
  • データキャッシュ
  • 推論キャッシュ
  • クエリキャッシュ
解決したい課題
  • リアルタイム性の高いアプリケーシ
    • Webサイト、ゲーム、デバイス 等
  • RDBではマイクロ秒レベルのレイテンシは困難
    • スキャンや結合のコストが大きい
選択指針
  • ミリ秒未満のレイテンシーが求められる
  • キャッシュ可能
    • 障害時のデータ損失リスクを許容できる
    • インメモリ処理のため障害よるデータ損失の可能性がある

Amazon ElastiCache

  • マイクロ秒の応答時間
  • フルマネージドな運用管理

グラフデータベース

  • 複雑な関係性を表すのを得意とする
    • SNSのフレンド関連性等
  • 全ての関連が多対多の関係
ユースケース
  • SNSニュースフィード
  • リコメンデーション
  • 不正検出
解決したい課題
  • グラフ構造を扱うアプリケーション
    • レイテンシーがミリ秒
    • 関連を検索
    • 何百万人ものユーザ照会
  • RDBでは多対多は不得意
    • スケールアップに限界がある
選択指針
  • 関連を探索するクエリ(トラバーサル)
  • 短いクエリが大量にある

Amazon Neptune

  • 数十億のリレーションシップを扱える
  • ミリ秒のレイテンシー
  • 専用のグラフデータベースエンジン

時系列データベース

  • 時間が唯一の主軸
  • 特定の感覚で記録され続ける
  • 時間の経過に伴う変化を測定
解決したい課題
  • 大量ログの絶え間ない格納
  • RDBではログの格納と分析の両立が難しい
選択指針
  • 時系列データを扱うか
    • 大量、粒度が小さい、すぐに分析したい
    • 多数のソースから頻繁に送信される

Amazon Timestream(Preview)

  • RDBの1/10のコストで1000倍のパフォーマンス
  • 一日あたり数兆規模のイベントに対応

台帳データベース

  • データの変更履歴はイミュータブル(変更、削除不可)
  • 意図しない変更が発生してないことを暗号技術で検証
ユースケース
  • 集中管理を行う元帳として利用
    • ヘルスケア:医療カルテ、保険ログ
    • 政府機関:戸籍、住民票..
    • 民間企業:監査証跡、契約書管理..
解決したい課題
  • 台帳を管理しなければならないか
    • 変更履歴の追跡
    • 改ざんがないことの証明
  • RDBでは管理者が存在する
    • 管理者が操作せきる可能性がある
選択指針
  • 履歴の追跡と変更管理
    • 完全で検証可能な変更履歴を維持したい
    • 管理者でも変更履歴を改ざんできないことを保証したい

Amazon Quantum Ledger Database(Preview)

  • スケーラブルで完全
  • 検証可能なトランザクション
  • データの変更全てを追跡可能

まとめ

  • 用途にあわせた7つのDBがある
  • 適材適所でデータベースを選択する

感想

データベース種別によるユースケースの説明があり、選択指針を振り返ることができました。「万能のデータベースは存在しない」を念頭に、適材適所でデータベースを選択していきたいと思います。