Posted at

AWS Summit Tokyo 2019 (6/14 Amazon DynamoDB Deep Dive)

聴きながらとったメモ

登壇者 アマゾンソリューションアーキテクト 成田 俊


  • アマゾンで買い物をするサイトはバックエンドにDynamoDBを使用している。

  • 高速で一貫した性能。

  • 99.999%のSLA。

  • DynamoDBはテーブルでデータを分割し、アイテムとしてデータを保存する。

  • 各アイテムはアトリビュート(列)を持っているが、データごとにアトリビュートが違っていてもいい。

  • ソートキーはオプションだが、ソートキーをつけることで幅広い検索ができる(範囲検索とか)。

  • パーティションキーとソートキーを指定してGet/Put/Update/Deleteする

  • DynamnoDBでACIDトランザクションが可能になった。これによって複数の処理が全て成功するか全て失敗するか、という設計ができるようになった。

  • 内部ではパーティションキーを元にItemの保存位置が決まり、スケールのためにパーテーションという単位で分散保存している。

  • パーテーションは3つのコピーを持つことで冗長性を確保している。

  • パーティションキーとソートキーだけで検索できない場合はセカンダリインデックスを使う。

  • LocalSecondaryIndexは同じパーティションキーでの検索に使う。

  • GlobalSecondaryIndexはパーティションキーをまたいで検索できる。

  • クライアントがテーブルに対して更新処理を行うと、GlobalIndex用のテーブルに対して非同期に更新を行う。

  • バーストキャパシティによって、過去300秒分で使わなかったキャパシティを使用してバーストできる。

  • オートスケーリングできる。

  • アクセスされるキーに偏りがあると負荷が偏るため、パーティションキーの設計時には書くパーティションに分散されるように考慮する必要がある。

  • あるパーティションに負荷が偏った場合に、Adaptive Capacity機能によって、他のパーティションのキャパシティを負荷がかかっているパーティションにもってこれる。

  • オンデマンドによってサーバー料金ではなく、リクエストに対して課金できる。

  • オンデマンドとインスタンスは運用中に設定変更で変更できる。

  • Scale fearlessly with amazon dynamo db adaptive... というセッションが参考になる。

  • 「サーバーレスアプリケーション向けのDB 設計ベストプラクティス」

  • NoSQLは正規化しすぎると効率が落ちることがある。非正規化し、データは多少重複していてもアプリから操作しやすい構造にする。

  • N:MリレーションではtableとGSIによって双方向の関係性を保存する。

  • GSI OVERLOADINGにより、セカンダリインデックスの数の制約を超えた設計が可能になる。