インフラ担当の柴田です。
いきなりですが、皆さんAmazon Prime Dayでは何か買いましたか？ Amazon.co.jpの発表では過去最高の売上ということで、結構買い物をした人も多いのかなと思います。
私はというと、「何か買うぞー！」と思いつつ、結局電球などの日用品ぐらいしか買わず、なんとなく後悔してます。
さて、Amazonといえばそのインフラを支えているのがAWSということで、AWSのブログでAmazon.comのPrime Dayで2022年はどれだけAWSのリソースが使われたのかが紹介されています。
その中で、DynamoDBがピークには秒間1億520万のリクエストに対して1桁ミリ秒で応答したというのを見てすごいなと思うのと同時に、「そういえば最近USENIXでDynamoDBのペーパーがでてたな」と思い出しました。
DynamoDB maintained high availability while delivering single-digit millisecond responses and peaking at 105.2 million requests per second.
そこで、今回はUSENIX ATC '22で発表されていたDynamoDBのペーパー*1を紹介しようと思います。
とは言え、良い感じに紹介するのが難しく、私が気になったポイントをいくつか紹介する形にしたいと思います。
はじめに
最初に対象のペーパーですが、以下のサイトでPDFが配布されていますので気になった方は是非原文をご参照下さい。
このペーパーでは、DynamoDBが顧客の要求に答えるためにどのように進化してきたのかが紹介されています。以降でその中でも私が気になったポイントを紹介していきます。
絶対効率よりも予測可能性が安定性を向上させる
「私たちが長年にわたって学んだ次の教訓をまとめたものです」として、4つの教訓が紹介されています。いずれの教訓も興味深いのですがその中の1つに「絶対効率よりも、予測可能性が高いシステムを設計するとシステムの安定制が向上する」とありました。
Designing systems for predictability over absolute efficiency improves system stability.
なるほど、キャパシティユニットの話かなというのが思いつきました。 後、某漫画でも「急にステータスが変わると、感覚がずれて避けにくくなる」みたいなセリフがあったなというのも思いつきました。
続きの文を読んでみると、キャッシュを使うとパフォーマンスが向上するけどキャッシュが無い時の処理もちゃんと考えようねということが書いてあり、なるほど、確かにキャッシュが切れた時にパフォーマンスが落ちるというのは何となく認識しているけど、その影響がどのぐらいあるのかを計測したことはあまりないなぁと思いました。
この予測可能なパフォーマンスというのは、DynamoDBの前身となるNoSQLデータベースのDynamoの頃から重要な要件とされていたようです。
Another critical requirement for Dynamo was predictable performance so that applications could provide a consistent experience to their users.
Amazonのエンジニアもサーバーの面倒をみるのは嫌
先ほど、少し名前をだしたのですがAmazonが開発した最初のNoSQLデータベースにDynamoというサービスがありました。Dynamoは大規模で高い信頼性を提供する唯一のデーターベースサービスであったためAmazon内での採用も増えていったようです。 しかし、Dynamoは自分たちで管理する必要があり、運用上の複雑さという課題が依然として存在していました。
その頃、マネージドでエラスティックな（弾力性のある）新しいサービス（Amazon S3やAmazon SimpleDB）の提供が開始されました。そうした中で、Amazonのエンジニア達はDynamoの方がより良い場合であっても、マネージドでエラスティックなサービスの方を好んで利用したようです。そうすることで、Dynamoのようなシステムの管理から開放され、アプリケーションの開発に集中できたからのようです。
Amazon engineers preferred to use these services instead of managing their own systems like Dynamo, even though the functionality of Dynamo was often better aligned with their applications' needs.
ちなみにSimpleDBにはいくつかの制限があったので、これらの制限を取り除く方法が考えられ、Dynamoの良い部分とSimpleDBの良い部分を組み合わせるのが良いと結論になったというようなことが書かれています。
そうした検討の結果生まれたのがAmazon DynamoDBのようで、ペーパーの中でも「Amazon DynamoDBがAmazon.comで大規模な非リレーショナルデータベースを構築する中で学んだことと、AWSで高いスケーラビリティと信頼性を持つクラウドコンピューティングサービスを構築した経験に基づいて進化してきた成果」と述べています。
Amazon DynamoDB was the result of everything we’d learned from building large-scale, non-relational databases for Amazon.com and has evolved based on our experiences building highly scalable and reliable cloud computing services at AWS.
プロビジョンからオンデマンドへの旅
4章では「Journey from provisioned to on-demand」として、どうやって一貫したスループットを提供するのかやバーストについて触れられていて、いくつも気になるポイントがあるのですが、ちょっと紹介するには難しいところが多いので簡単なところだけ紹介したいと思います。
DynamoDBにはGlobal Admission Control (GAC)という、テーブルの消費容量を管理してトラフィックをコントロールする機能があり、この消費容量を管理するのにトークンバケットのアイデアが使われているというのを読み、私も似たような処理を案件で使ったと急に親近感が湧きました。
GAC builds on the same idea of token buckets.
もう1つ、親近感のわくポイントが次の一文ですね。
Because the concept of capacity units was new to customers, some found it challenging to forecast the provisioned throughput.
キャパシティユニットというコンセプトが新しいので、スループットを予測するのは難しい顧客がいたというのは、まさに私にも当てはまる問題で、デプロイした当初は大体リソースが余って勿体ない。
そこで、そういった顧客のためにオンデマンドテーブルが用意されたようです。DynamoDBが読み取りと書き込みで消費された容量に基づいて、それまでのトラフィックの最大2倍まで即座に対応できる容量を確保するとのこと。もちろん2倍以上のトラフィックが必要になる場合も、トラフィックの増加に合わせて自動で容量が割り当てられるとのこと。
DynamoDBの価格表を見ると、オンデマンドとプロビジョニングで価格の単位が違う上に、オンデマンドの方が表示されている単価が高いので、オンデマンドにすると高くなるイメージを持ちます。 しかし、実のところプロビジョニングの場合は使わなくても費用がかかる事を考えると、オンデマンドの方が安くすむ場合も多いと思います。キャパシティを予測するという難しい作業をしなくてすみますので、最初の選択肢としてはオンデマンドがおすすめです。
高耐久性の秘密
5章では「Durability and correctness」として、DynamoDBが高い耐久性や正確性をどうやって確保しているのかを説明しています。
この章を読んでいるとふと、Eight Fallacies of Distributed Computing（分散コンピューティングの8つの誤謬）を思い起こします。分散コンピューティングの8つの誤謬については、Wikipediaへのリンクを張っているのでそちらを見て頂ければと思いますが、ざっくり言うと、分散処理を作るときに忘れがちな前提を紹介しています。
さて、そんな5章で気になったポイントですが以下になります。
まずは、DynamoDBは保存するデータを至るところでチェックしているということ。
DynamoDB makes extensive use of checksums to detect silent errors.
ハードウェアが原因で発生するサイレントエラーは、検出が難しく何処でも起こる可能性があるため、DynamoDBでは至る所でチェックサムを検証しているらしいです。 しかも、このような検証は単にデータの転送時だけではなく、保存したデータに対しても継続して行われているというのがすごい。
DynamoDB also continuously verifies data at rest.
あとは、レプリケーションプロトコルの正確性を保証するのに形式手法を使っているという部分は、「聞いたことある有名なやつ！」となりました。
We use formal methods [16] extensively to ensure the correctness of our replication protocols
デプロイのポイント？
DynamoDBは、サービスの停止無く新しい機能をデプロイしているようで、そのポイントが紹介されていました。 その中の1つに、デプロイしたソフトウェアが機能せずロールバックが必要になるときがあるが、ロールバックのプロセスはテストで見落とされがちというのがあった。
The rollback procedure is often missed in testing and can lead to customer impac
これは、あるあるだなと思いました。特にDBを弄る系の処理は戻せないことがたまにあるなと（なお、このペーパーではどちらかと言うとロールバックが成功しても、ロールバック前の状態には戻らないことがあるという問題を挙げています）。 そこで、DynamoDBではデプロイ前に一度アップデートとダウングレードを行い、ロールバックした時に問題が発生しないかをテストしているとのこと。
また、デプロイの順番もよく考えられています。 分散システムは、分散しているが故に変更が一度に全てのノードに行き渡らないという課題があるのですが、DynamoDBでは新しいプロトコルをデプロイする時に、新しいプロトコルを読み取れる機能を先にデプロイし、全体に行き渡ってから新しいプロトコルで送信するようにしているようです。確かにこの方法であれば、新しいプロトコルのメッセージが送信されるときには既に全システムが読み取れる状態なので良いなと思いました。
The first step is to deploy the software to read the new message format or protocol. Once all the nodes can handle the new message, the software is updated to send new messages.
外部サービスへの依存
DynamoDBが高い可用性を維持するためには、依存するサービスがDynamoDBより高い可用性を必要とするとあり、なるほど確かにと納得しました。 加えてDynamoDBは依存するサービスが停止してもサービスを提供できるように設計されているとのことで、すごい（語彙力）。
To ensure high availability, all the services that DynamoDB depends on in the request path should be more highly available than DynamoDB.
直接関係はないのですが、AWSがサービスのSLAで提示している稼働率を各サービスの稼働率と仮定して、簡易にシステムの稼働率を計算することがあるのですが、3層構造（ELB-EC2-RDS）にしたところ、単一のサービスだと99.99％とかあるけど、3つ使うと稼働率はそれぞれを掛けるから単一より下がって、稼働率99.99％とか求められると辛いというのを思い出しました。
YCSB ?
このペーパーではYCSBを使ってベンチマークを取っているのですが、そもそもこのYCSBを知らなかったので検索してみました。 すぐに、論文を解説してくださっているBlogが見つかったので、読んでみました。
どうやら、NoSQLデータベースが台頭してきて従来のベンチマークではそれらの性能が十分に測れないとなって、Yahooの人たちが提案したベンチマークがYahoo Cloud Serving Benchmark (YCSB)らしい。
アカデミアのデファクトスタンダードになりながらも，実際にそのコードは使われていないというのは，非常に歯がゆいものがある．
という一文が興味をそそりますね。DynamoDBのベンチマークを取るときもAWSオリジナルなツールが使われたのでしょうか。
まとめ
今回はUSENIX ATC '22で発表されていたDynamoDBのペーパーの紹介ということで、気になったポイントを雑多に紹介しました。 全然触れなかったのですが3章ではアーキテクチャについても紹介されています。
全体を通して、技術的には何となくイメージができる範囲の難易度で、所々「サーバー管理したくないよな」とか「キャパシティ予想とか難しいよな」と共感できる部分もあって読んでいて面白いペーパーかなと思います。後、正誤表が出ているのですが、グラフのタイトルをタイポしているあたりも親近感が沸きます。
最後に、読み間違いが無いようにしていますが、英語には全く自信が無いので是非もとのペーパーを読んで貰えればと思います。
*1:Perianayagam, Somasundaram, et al. "Amazon {DynamoDB}: A Scalable, Predictably Performant, and Fully Managed {NoSQL} Database Service." 2022 USENIX Annual Technical Conference (USENIX ATC 22). 2022.
