【JAWS-UG朝会】今更ながら Amazon DynamoDB の論文を真面目に読んでみた

Slide 1

Slide 1 text

Slide 2

Slide 2 text

2 自己紹介 ● 加藤雅己（かとうまさき） ● 外資系ITコンサルティング会社3年目（2021年新卒入社） ● 好きなAWSサービス ● AWS初心者 ● JAWS朝会初登壇です！ ● 普段はアプリケーションアーキテクトとして働いています AWS Lambda Amazon DynamoDB NAT gateway 休みの日はフリスビーを投げたりプログラムを書いたりな日々を過ごしています AWS Ground Station

Slide 3

Slide 3 text

3 今日のまとめどんな論文を読んだの？ ● Amazon DynamoDB: A Scalable, Predictably Performant, and Fully Managed NoSQL Database Service （動画） 2022年7月に公開された論文 Amazon DynamoDBのアーキテクチャとその進化の歴史を紹介なんで読もうと思ったの？ ● ネットで感想記事見つけた⇒こんな論文があるんだ ● サービスの中身を知っていた方がいいものを作れるのでは？と感じたので読んでみた！ ● 最初は日本語の解説記事を読んだだけだったが、気付いたら英語でも読んだ感想 ● 技術的な話よりは課題に対するアプローチの歴史の話で読みやすかった（途中PaxosやB treeの話がでて、そこは難しかった） ● AWSエンジニアの顧客体験への強い熱意を感じた

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 7 Amazon DynamoDBの特徴 NoSQLデータベースらしいシンプルなクエリ操作 ● NoSQL = Not only SQLの略 ● RDBは多機能⇒代わりに制約も多い〇：厳密なデータ構造、 JOINなどの複雑なクエリ、データの強い整合性等 ✖：書き込みの負荷分散が難しい等 ● RDBの持つ多彩な機能を制限する代わりに、特定のユースケースにおいてメリットを持つDBのことをNoSQLと呼ぶ ● DynamoDBはPut/Get/Scanなどシンプルなクエリしかサポートしない代わりにパフォーマンスがテーブルのサイズ・リクエスト量によらず一貫「キャパシティ」という概念を用いたスループット制御 ● 読み込みや書き込み等の APIコールに対し、キャパシティを消費 ⇒キャパシティが不足していればスロットルがかかる ● リリース当初、キャパシティは事前にユーザーが定義する必要があった ⇒2018年にオンデマンドに設定可能に Amazon DynamoDBとは？ Amazon Prime Day期間（66時間）合計での数兆req・ピーク時最大8920万req/秒の中でも1 桁ミリ秒のレイテンシを出し続けたとのこと！！ I/Oやコンピューティング時間ではなく、キャパシティという単位を用いることで裏のサーバーを意識させない設計？

Slide 8

Slide 8 text

Slide 9

Slide 9 text

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 9 論文の構成 1. 導入 DynamoDBの特徴を紹介 2. 歴史もともと2つのDBだったものをDynamoDBにしたんだよ、みたいな話 3. アーキテクチャ DynamoDBのアーキテクチャについて。後述 4. プロビジョンドからオンデマンドへの旅パフォーマンスの課題をどうやって解決したのかという話。後述 5. 耐久性と完全性データが壊れたり失われたりしないようにどうやっているか 6. 可用性 DynamoDBを止めないようにする仕組みの紹介 7. ベンチマーク DynamoDBはすごい 8. 結論 DynamoDBはすごい今日は時間の関係から、ここだけを紹介このへんもめちゃくちゃ面白かったです

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 11 マイクロサービスアーキテクチャ複数のマイクロサービスを組み合わせ、 NoSQL DBサービスを実現ストレージノードは最低 3つのAZにデータを複製 DynamoDBのアーキテクチャ Global Admission Control スループット制御 Request Router Metadata Service リクエスト受付・振分けテーブルに関するメタデータ管理 Authentication System 認証システム Autoadmin Service パーティション配置の管理など AZ-a AZ-b AZ-c Storage Node SSD SSD Storage Node SSD SSD Storage Node SSD SSD 11

Slide 12

Slide 12 text

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 12 マルチテナントアーキテクチャ × シングルテナントエクスペリエンス 1つのテーブルを小さなパーティションに分割し、ストレージノードに分散配置。 1つのストレージノードには複数のパーティションが配置される（マルチテナントアーキテクチャ）が、同じノードに別のパーティションがいることをユーザーは意識しない（シングルテナントエクスペリエンス） DynamoDBのアーキテクチャ Partition 1-A Storage Node Partition 1-B Partition 1-C Table1 Table2 Partition 2-A Partition 2-B Partition 2-C 分割分散して配置 Partition 1-A Partition 1-B Partition 1-C Partition 2-A Partition 2-B Partition 2-C Storage Node Storage Node 12

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Storage Node マルチテナントアーキテクチャの抱える2つの課題 1つのノードに複数のパーティションを共存させるため、パーティションに予めスループット制限をかける仕組みを採用（WCU/RCU）プロビジョンドからオンデマンドへの旅 (1/8) Table 1 - Partition A Table 2 - Partition X Table 1 - Partition A Table 1 - Partition B Table 1 - Partition C テーブルのスループットをパーティションに均等に割当合計スループットがノードの限界を超えないよう配置 Table1: 2400 WCU 800 WCU 800 WCU 800 WCU 800 WCU 900 WCU 2000 WCU （ユーザーが設定） 14

Slide 15

Slide 15 text

© 2022, Amazon Web Service, Inc. or its affiliates. All rights reserved. マルチテナントアーキテクチャの抱える2つの課題プロビジョンドからオンデマンドへの旅 (2/8) 15 Storage Node Table 1 - Partition A Table 2 - Partition X Table 1 - Partition A Table 1 - Partition B Table 1 - Partition C テーブルのスループットをパーティションに均等に割当合計スループットがノードの限界を超えないよう配置 Table1: 2400 WCU 800 WCU 800 WCU 800 WCU 800 WCU 900 WCU 2000 WCU 1つのノードに複数のパーティションを共存させるため、パーティションに予めスループット制限をかける仕組みを採用（WCU/RCU） ⇒リクエストの空間的・時間的な不均一性に対応できず、スロットリング（流量制限）がかかる課題が発生　複数の解決策によりスループットを管理、調整しスロットリングを抑制⇒オンデマンドキャパシティの実現へ課題1: 特定のキー領域へのアクセス集中課題2: 瞬間的なアクセス量の増加

Slide 16

Slide 16 text

Storage Node バーストによる瞬間的なリクエスト増大の吸収普段使い切っていないキャパシティを保存⇒リクエスト増加時にバーストさせ瞬間的なリクエスト増加に対応ストレージノードのキャパシティを超える場合には他のパーティションへ迷惑をかけるためバースト不可プロビジョンドからオンデマンドへの旅 (3/8) Table 1 - Partition A Table 2 - Partition X バースト可能な場合バーストできない場合 800 WCU 1200 WCU 2000 WCU Storage Node Table 1 - Partition A Table 2 - Partition X 800 WCU 400 WCU 2000 WCU 16 ノードの限界を超えスロットリングがかかる ※課題として残る +700 WCU +700 WCU 例：800WCUのPartition Aに1500WCUのリクエストが来た場合

Slide 17

Slide 17 text

キャパシティ調整による空間的リクエスト分布の吸収長期間特定のパーティションにアクセスが集中する場合には、均等に割り当てたキャパシティの使用量に応じた再割り当てを実施。プロビジョンドからオンデマンドへの旅 (4/8) 例：800WCUのPartition Aに1500WCUのリクエストが来た場合 Table 1 - Partition A Table 1 - Partition B Table 1 - Partition C Table1: 2400 WCU 800 WCU 800 WCU Table 1 - Partition A Table 1 - Partition B Table 1 - Partition C Table1: 2400 WCU 1500 WCU 600 WCU 300 WCU 1500 WCU 割り当てを再分配割当量を超え瞬間的にスロットリングがかかる ※課題として残る 17 初期状態最終状態

Slide 18

Slide 18 text

テーブル全域の監視による不当なスロットルの防止パーティションのキャパシティが少ないことによる不当なスロットルを防止するため、テーブル全域の流量監視サービス（GAC）を作成。リクエスト時に都度キャパシティを割当ての許可をとることで不当なスロットルを防止。プロビジョンドからオンデマンドへの旅 (5/8) 18 Global Admission Control Request Router AZ-c Storage Node AZ-b Storage Node AZ-a Storage Node ①ストレージノードへのリクエスト前にGACへテーブルのキャパシティを確認 ②テーブルのキャパシティが残っている場合のみストレージノードへアクセスストレージノード内の流量制限は残す ⇒ハードウェアの限界を超えたリクエストを拒否 ※GACのような攻めの仕組みとストレージノードの流量制限のような守りの仕組みが共存するケースが多くみられ、印象的だった

Slide 19

Slide 19 text

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 消費キャパシティの監視によるパーティションの適切な配置換えストレージノード内のパーティションの消費キャパシティが閾値を超えた場合、パーティションを追い出すようリクエストを出すことでノードのキャパシティを超えることを予防する。プロビジョンドからオンデマンドへの旅 (6/8) Storage Node Table 3 - Partition Y 2000 WCU Storage Node Table 1 - Partition A Table 2 - Partition X 600 WCU 1200 WCU 2000 WCU 300 WCU 19 Auto Admin Service ①Partition Xを追い出すようリクエスト ②空きがあるノードを探し、 Partition Xを移動

Slide 20

Slide 20 text

リクエストが集中するパーティションの分割特定の範囲へのアクセスが集中する場合、どうしてもスロットルがかかりやすい。こういったアクセスが集中するパーティションを分割することでノードの流量制限を超えることを予防。 ①特定のキーへのアクセス集中②テーブル全域のスキャンはパーティション分割の効果がないため分割しないプロビジョンドからオンデマンドへの旅 (7/8) 20 Table 1 - Partition A Table 1 - Partition B Table 1 - Partition C Table 1 - Partition A Table 1 - Partition B Table 1 - Partition C Table 1 - Partition D PartitionCにリクエストが集中 Partitionを分割しリクエストを平準化

Slide 21

Slide 21 text

ついにオンデマンドへプロビジョンドからオンデマンドへの旅 (8/8) 21 これらの仕組みにより、消費した流量からオンデマンドにキャパシティを設定する仕組みが構築された。時間的なリクエスト分布による課題空間的なリクエスト分布による課題 GACによるテーブル全域でのキャパシティ管理バーストキャパシティスループットを監視しパーティションの適切な配置換えパーティション割当てキャパシティの動的な調整パーティションの分割オンデマンドキャパシティプロビジョンドキャパシティ

Slide 22

Slide 22 text

Slide 23

Slide 23 text

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 感想&今日のまとめ ● 技術的な話よりは課題に対するアプローチの歴史の話だった ○ 出てきた課題に対し、迅速に対応可能な部分から改善していく姿勢は見習いたい ○ 攻めと守りの仕組みを作ることで安全なアプリケーションを設計できる ■ 本日紹介しなかった可用性/耐久性についての考え方でも同じ ● AWSエンジニアの顧客体験への強い熱意を感じた ○ 論文中に「エクスペリエンス」という単語が非常に多く見られた ● AWSサービスはその実装を意識させない作りになっていることが多いが、裏側まで知ることでより良いアプリケーションを設計できるのではないか参考 ● Amazon DynamoDB: A Scalable, Predictably Performant, and Fully Managed NoSQL Database Service ● USENIX ATC '22 - Amazon DynamoDB: A Scalable, Predictably Performant, and Fully Managed NoSQL Database Service - YouTube ● Amazon DynamoDB の論文を読んでいく - Qiita ● AmazonのDynamoDB論文を眺めた | Takuya Kitazawa 23