[レポート] DynamoDBの高度なデザインパターン #reinvent #DAT401

こんにちは。サービスグループの武田です。

DAT401 - Amazon DynamoDB Deep Dive: Advanced Design Patterns for DynamoDB に参加してきましたのでレポートをお届けします。

なおセッションの動画はYouTubeからも視聴できます。

セッション概要

This session is for those who already have some familiarity with DynamoDB. The patterns and data models discussed in this session summarize a collection of implementations and best practices leveraged by Amazon.com to deliver highly scalable solutions for a wide variety of business problems. The session also covers strategies for global secondary index sharding and index overloading, scalable graph processing with materialized queries, relational modeling with composite keys, and executing transactional workflows on DynamoDB.

機械翻訳したものも掲載します。

このセッションは、すでにDynamoDBに精通している方を対象としています。 このセッションで説明するパターンとデータモデルは、Amazon.comが活用している実装とベストプラクティスの集まりをまとめ、さまざまなビジネス上の問題に対して高度にスケーラブルなソリューションを提供します。 このセッションでは、グローバルなセカンダリインデックスのシャーディングとインデックスのオーバーロード、マテリアライズされたクエリによるスケーラブルなグラフ処理、複合キーによるリレーショナルモデリング、およびDynamoDBでのトランザクションワークフローの実行のための戦略についても説明します。

アジェンダ

• データ処理の簡単な歴史（なぜNoSQLが必要なのか？）
• DynamoDBの概要
• NoSQLのデータモデリング
  • 正規化vs非正規化
• NoSQLの一般的なデザインパターン
  • 複合キー、階層データ、関係データ
• 具体的なアプリケーションのモデリング
• 現実世界の例
• まとめ

セッションメモ

データ処理の簡単な歴史（なぜNoSQLが必要なのか？）

• 最初のデータベースは人の脳だ。ただし耐障害性は0
• 次は帳簿会計のシステム。最初の構造化データストアで長く使われた
• 続いてパンチカード。機械で処理でき現代のデータ処理のベースが生まれた
• その後テープ、ブロックストレージ、ファイルシステム、リレーショナルデータベースと急速に発展した
• この30年ほどでもっとも高価なリソースはストレージからCPUとなった
• RDBは採用率の右側だが、NoSQLは左側

• SQLとNoSQLの違い

DynamoDBの概要

• フルマネージドなNoSQLデータベース
• ドキュメントまたはkey-value形式
• ワークロードに合わせてスケール
• 速くそして一貫性がある
• アクセスコントロール
• イベント駆動プログラミング
• RDBのテーブルとよく似たテーブルがDynamoDBにもある
• テーブルにはアイテムを一意に識別するパーティションキーが必要
• オプションとしてソートキー属性を含められ、レンジクエリが実行できる

• パーティションキーは順序付けのないハッシュインデックスを構築する
• ソートキーを使用するとハッシュインデックス内で順序付けされる
• パーティションは常に3つのAZにレプリケーションされる
• パーティションキー内において、ソートキーとは異なる順序付けでインデックスを作成したい場合、ローカルセカンダリインデックスを使用する
• パーティションキーとは異なるパーティションのインデックスを作成したい場合、グローバルセカンダリインデックスを使用する
• テーブルを更新するとクライアントに応答し、非同期にGSIの更新がかかる

• ヒートマップを見たとき特定のパーティションに負荷が集中するのはアンチパターンの1つ

• DynamoDBのスループットを最大化するためには、パーティションキーを分散させリクエストが集中しないようにする
• 非常によいヒートマップが見られる

NoSQLのデータモデリング

• ソーシャルネットワークやドキュメント管理など関係モデルとして扱うのが自然だ
• 関係モデルでは複数のテーブルに分割し、問い合わせは複数のクエリかJOINを必要とする
• 非正規化することで単純なクエリとなる

• DynamoDBのキーコンセプト（キーの選び方）
  • パーティションキー
    • 多数の値をもつ
    • 平均的で分散したリクエスト
  • ソートキー
    • 1:nやn:nの関連付け
    • 複数のエンティティをクエリする
    • レンジクエリを使用する
• ユースケースを理解する
  • OLTP/OLAP/DSS
  • データのライフサイクル
• アクセスパターンを特定する
  • read/writeワークロード
  • クエリ集約の定義
• データモデリング
  • リレーショナルなデザインパターンを避け、1つのテーブルを使用する
• 試行を繰り返す

NoSQLの一般的なデザインパターン

• DynamoDB StreamsとAWS Lambda
  • 従来のストアドプロシージャと同じようなしくみが作れる
  • DynamoDBとLambdaは分離されているので、行儀の悪いコードが入っても可用性を落とさない
  • アイテムの変化をトリガーできるため集約処理なども可能
• 複合キー（Composite Key）
  • 2つのデータを結合したデータを作成しソートキーとする
    • StatusとDateをアンスコで結合する例を考える
    • Dateをソートキーにするのが自然だが、そうするとStatusの絞り込みができない
  • クエリでbegins_withを使用することで前方一致検索が可能
• 高度なデータモデリング
  • OLTPアプリケーション
    • 階層的な構造およびエンティティ駆動のワークフロー
    • 複雑なクエリとACIDが最重要
  • バージョン履歴の管理
    • バージョンを付与したアイテムの追加および現在のバージョンを更新する
  • リレーショナルなトランザクションの管理
    • 親子関係のある複数のエンティティを更新する
  • Amazonが使っていたDynamoDB Transactions APIを新機能として発表した
    • 同期的な更新、追加、削除、チェックが可能
      • アトミック
      • 自動ロールバック
    • 複数テーブルをサポート
    • 複雑な条件チェック
    • 正規化されたデータのメンテナンスには向かない

• 階層的なデータ
  • 複合ソートキーを使用して階層を定義する
  • ソート条件付きの高度に選択的なクエリ
  • クエリの複雑さを軽減する
  • これを関係モデルで実装すると高価なJOINが必要

具体的なアプリケーションのモデリング

• リレーショナルデータのモデリング
  • 架空の配達サービスを考える
  • シンプルな用件を出してエンティティモデルを考える

• アクセスパターン
  • 注文の取得
    • 日付の範囲
  • 注文詳細の取得
    • ステータス
    • アイテム
  • 配送の取得
    • 日付の範囲
  • 配送可能な運転手の取得
    • 地理座標および時間
  • 顧客情報の取得
  • ベンダー情報の取得
• リレーショナルなアプローチ
  • データセットを拡大するにつれてJOINは非常に高価になる

• NoSQLなアプローチ
  • アクセスパターンに応じて必要なテーブルを作成する
  • 必要に応じてGSIを作成する

現実世界の例

• AudibleなeBook同期サービス
  • 関係モデルでは5つのテーブルを必要としていた
  • 1つのテーブルと3つのGSIを作成した
  • 20のアクセスパターンをカバーした

• サーバーレスパラダイム
  • S3には個人情報などを暗号化して格納
  • DynamoDBには暗号化されていない検索可能なメタデータを格納

まとめ

• NoSQLは「リレーショナルではない」という意味ではない
• ER図はまだ重要
• RDBMSはNoSQLによってなくなるわけではない
• スケールが必要なOLTPやDSSにはNoSQLを使用する
• OLAPやスケールが重要ではないOLTPにはRDBMSを使用する

最後に

DynamoDBのDeep Diveということで、DynamoDBの内部的な構造やそれを踏まえた正しい設計が紹介されている有意義なセッションでした。また発表されたばかりの新機能であるDynamoDB Transactions APIにも触れられ、それでもRDBMSの代替ではないということを再認識できました。NoSQL全般に言えることですが、アプリケーションのアクセスパターンに合わせてテーブルやインデックスを設計する必要があり、こればっかりは自分で経験していくしかないなと感じました。きちんと特性を理解して使いこなしていきましょう！