Amazon DynamoDB Deep Dive

クラウドを利用する大規模サービスな特徴

• 数百万以上のユーザー
• TB/PBのデータ

Amazon.comのDB

• OracleからDynamoDBへ
• ワークフローの処理が1秒程度から100msまで改善
• スケーリングとメンテナンスのオペレーションコストが1/10に

Amazon DynamoDBの特徴

• フルマネージド

  • メンテナンスフリー
  • サーバーレス
  • Auto scaling
  • バックアップ/リストア
  • Global Tables

• ハイパフォーマンス

  • 高速で一貫した性能
  • 事実上無制限のスループット
  • ストレージ容量も制限なし

• エンタープライズ対応

  • 暗号化
  • 権限管理

過去21ヶ月の主要アップデート

• TTL
• VPC Endpoint
• DAX
• Auto scaling
• Global tables
• ondemand backup
• encryption at rest
• Point in Time Recovery
• SLA
• adaptive capacity

テーブル構造

• テーブル（Table）
• テーブルの中にアイテム（Item）
• アイテムは属性（Attribute）を持つ
• Partition Keyが必須

• Sort Keyはオプション

  • 1対Nのリレーション関係を実現できる
  • Queryによる柔軟なクエリ

Item操作

• 読み込み

  • GetItem
  • TransactGetItems
  • BatchGet
  • Query
  • Scan

• 書き込み

  • PutItem
  • Update
  • TransactionWriteItems
  • BatchWriteItem
  • Delete
• QueryではSort Keyの指定は任意
• 書き込みは条件付き書き込みも可能

DynamoDB Transactions

• 複数Item/複数tableに対する書き込み操作や読み込み操作でのACIDトランザクションが可能になった
• いわゆるAll or Nothingが実現できるようになった

Partition Keys

• パーティションキーはアイテムを一意に識別
• パーティションキーの値をもとにItemがどこに位置するかが決まる
• 内部ではスケールのためにパーティションという単位で分散して保持
• パーティションキーごとのソートキー数は無限

Partitions are three-way replicated

• データは合計3箇所に保存される

Local Secondary Index（LSI）

• Sort Key以外に絞り込み検索を行うキーを持たせることができる
• 全ての要素（テーブルとインデックス）の合計サイズをパーティションキーごとに10GBに制限

Global Secondary Index（GSI）

• Partition Key属性の代わりとなる
• 元のテーブルとキャパシティは別で管理

• Tableに対するUpdateがあると、GSIに非同期に書き込まれる

  • 書き込んだ直後にインデックスを参照すると値が反映されていないことがあるかもしれない

Burst Capacity

• パーティションごとのキャパシティのうち、利用されなかった分を過去300秒まで貯めておいて使える

Auto Scaling

• フルマネージドでWCU/RCU、GSIに対する設定を管理
• ターゲット使用率と上限、下限を設定するだけ

パーティション内でのスループット

• テーブルスループットはパーティションに均等に付与される
• 全体で合計値の性能が出るように設計されている
• アクセスされるキーに偏りが発生すると思うように性能が出ないのでキーの設計に注意
• テーブル全体では余裕があるのにスロットリングが発生しする事態に陥る

Adaptive capacity

• 余裕があるパーティションのキャパシティを負荷が高まっているパーティションに割り振る
• リリース当初は5〜20分かかっていたのが、2019年のアップデートで即時的ようになった

DynamoDB on-demand

• キャパシティユニットをプロビジョニングせず使った分だけの請求モデル

キャパシティの改善の詳細

• https://www.slideshare.net/AmazonWebServices/scale-fearlessly-with-amazon-dynamodb-adaptive-capacity-adb302-santa-clara-aws-summit

データモデリング

• NoSQLはRDBとは全く特性が異なるので、それらを理解した上で適所で活用する
• NoSQL、DynamoDBの特徴を理解した上でテーブルを設計する

Tenets of DynamoDB Data Modeling

• ユースケースの理解

• アクセスパターンの理解

  • Read/Writeのワークロードについて
  • Queryの大きさや集計

• Data-modeling

  • NoSQLデザインパターン

• Review → Repeat → Review

  • 失敗したとしてもNoSQLなのでちょっとずつデータ構造を変えることもできる
  • 継続的に考えていくことが大切

学習教材

• https://www.qwiklabs.com/focuses/271?locale=ja&parent=catalog
• https://www.slideshare.net/AmazonWebServicesJapan/db-144577033
• BlackBelt Seminar - Amazon DynamoDB Advanced Design Pattern

GSI Overloading

• GSIの多重定義
• GSIの制限：テーブルあたりデフォルト最大20個まで
• 一つのGSIで複数の用途に利用できるように設計する
• 多数の異なるデータをもとにクエリをかけたい場面で効果的

Query Conditions

• ユースケースに対して以下の項目をまとめた表

  • パラメタ
  • 検索対象のテーブル/インデックス
  • キーの検索条件
  • フィルタ条件

まとめ

• 構築・運用にかかる時間を削減し、本来のビジネス価値を高めることに投資できる！

サービス責任者が語るAmazon Aurora MySQL/PostgreSQLの詳細と内部構造

Amazon Aurora

• Enterprise database at open source price
• Delivered as a managed service
• コマーシャルデータベースの性能と可用性
• オープンソースデータベースのシンプルさとコスト効果
• MySQL/PostgreSQLと互換性がある
• 利用した分だけお支払い

Aurora scale-out, distributed architecture

• log-structured 分散ストレージシステム
• ストレージボリュームは3AZに数百〜数千インスタンスのストレージノードに配置

Six-way replicated storage

• データは6ノードに非同期・並列で書き込む
• 書き込みクォーラムは4/6、読み込みクォーラムは3/6ノード
• ノードの修復にはPeer to peer "gossip protocol" を利用

Write and read throughput

• Aurora MySQL is 5x faster than MySQL

Bulk data load performance

• Aurora MySQL loads data 2.5x faster than MySQL
• Aurora PostgreSQL loads data 2x faster than PostgreSQL

（途中打ち合わせが入ったため、本日はここまで）

感想

DynamoDB Deep DiveはAWS Summitの会場で聞くことができたので、その復習として聞くことができた。

もともとデータの整合性を犠牲にしてスループットとスケーラビリティを高めたのがDynamoDBだったと思うが、強い整合性のある読み込みやDynamoDB Transactionsのおかげでそれすらも両立できるようになったとのこと。

一括操作でも、一部失敗した場合はアプリケーションでそれをハンドリングしてリトライしなければいけなかったのが、全部成功 or 全部ロールバックの動作が実現できるようになったとのこと。

スタートアップのエンジニア一人では到底実現が現実的でないことを、凄まじい技術力で次々シンプルなAPI化して提供してくれるAWSには頭が上がらない。。。

今までデータベースにはMySQL（on RDS）しか使ったことがなく、最近のプロジェクトでようやくDynamoDBを使い始めたのでまだまだ初心者の域を脱せないが、そのポテンシャルをちょっとでも多く引き出せるように引き続き勉強を重ねていきたい。