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

こんにちは、坂巻です。

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がある
• 適材適所でデータベースを選択する

感想

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