Werner Vogel、DynamoDBトランザクションについて語る #reinvent

AWS re:Invent 2018

#Amazon DynamoDB

#AWS

quiver

2018.12.18

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

最初に

Amazon CTOのWerner VogelやDynamoDBのゼネラルマネージャーがDynamoDBトランザクションについてざっくばらんに語っていたので、ざっとメモってみた。

参加者

Werner Vogel - Amazon CTO(トークでは "system administrator of small bookshop"と名乗っている)
Tony Petrossian - Amazon DynamoDB General Manager
もうひとり若い兄ちゃん
司会者

Amazon DynamoDB とは？

インターネットスケールアプリ向けのデータベース
ワークロードによらず、堅牢なパフォーマンスを実現
highly reliable, scalable, secure
非リレーショナルモデル(KVSやドキュメントDBとして使える)
most demanding application に使える
Supercel(Clash Royale/Clash of Clansなどを開発)の新規ゲームでは、リリース初日から何百万ものユーザーが利用
そのようなサービスに対しても、rock solid で consistent performance を提供する

DynamoDB で目指してきたもの

開発初日から古典的なDBAに要求されるようなDB管理タスクを排除
- バッファープール
- 接続数
- そういったことを考慮しなくても一貫したパフォーマンスが得られる
DynamoDB は AWS の最も偉大な成功の一つ
- 多くの顧客が利用
- Amazon 自身もいたるところで利用

どうやればDynamoDBをアプリケーションに組み込める?

データの保存も取得も API で操作
リリース当初から読み取りに関しては2種類(strong と eventual)の整合性を提供
strong consistent な場合、レプリカからもデータを読み込まないといけないため、読み取り量が倍になり、利用費も倍になる

DynamoDB はどのように発展してたか？

DynamoDB は Amazon Dynamo が先祖
Amazon.com では KVS 操作のために RDB を利用していた
primary keyで1行取得するだけのKey Value操作がDB操作の70％をしめていた
KVS操作に特化した、スケーラブルで一貫したパフォーマンスのデータベースを作るべくAmazon Dynamoが開発された
2007 年の論文を出版した "Dynamo: amazon's highly available key-value store"
10年後の 2017 年ににこの論文は SIGOPS The Hall of Fame Award を受賞した
AWS のユーザーもKVS操作を欲している
Amazon 内部で利用やAWS初期からあるKVSのAmazon SimpleDBの教訓をもとに2012年にDynamoDBをリリースした
その後も革新的な機能をリリース
- Secondary Index
- Global Table
- DynamoDB Streams
複雑でインターネットスケールで一貫した性能を要するアプリケーションに向いている

本日発表されたトランザクション機能について

トランザクション機能は多くの顧客が欲しがっていた
AWSの95%の機能は顧客要望によって実現されている
DynamoDB トランザクションによりテーブルの複数のアイテムや複数のテーブルを一貫して更新することを簡単に実現できる

DynamoDBトランザクションのユースケースは？

トランザクションに関する2つのAPI(read/write)を追加した
トランザクションを利用すれば複数の更新を全て成功、または、全て失敗にできる
APIごとに分離レベルがある
代表的なユースケースはユーザー間のポイント操作、口座の振込処理など
トランザクションを利用すれば、複雑な異常系のコードを書かなくてもすむ
口座に十分な残高があるかチェックするというような、条件を含めることもできる
DynamoDBのトランザクションは1 APIで実現
RDBMSのように、BEGINしたままCOMMIT/ABROTされないまま中途半端な状態のトランザクションは発生しない。DBAは未コミットなトランザクションを監視しなくてすむ

トランザクションの利用費

トランザクションを利用すると prepareとcommitの2回のREADが発生
READの場合、消費するcapacity unitはeventual:strong:transactional=1:2:4
WRITEの場合、消費するcapacity unitは standard:transactional=1:2
read/write独立してcapacityがオートスケールする機能も一緒にリリースされた
ワークロードによってread/writeのcapacity消費は異なることが多々ある。オートスケールを利用すると運用が楽になる

トランザクションの単位

同じAWSアカウントの同じリージョンに限られる(blast radius isolation)
リージョンやAWSアカウントをまたぐことはできない

トランザクションのサンプルコード

Uberのようなライドシェアを例にとる
2人で乗車し、それぞれが支払い、ドライバーが運賃を受け取るとする
3つの口座残高操作が発生
- 利用者1の口座から運賃を引き落とす
- 利用者2の口座から運賃を引き落とす
- ドライバーの口座へ運賃を振り込む
dynamodb::TransactWriteItems APIでこの3つをatomicに更新できる
利用者の口座に十分な残高があることのチェックも可能(.withConditionExpressoin("#balance >= :rider_fare"))
条件式を利用すれば、別途 READ して十分な残高があることをチェックしなくて良い
トランザクションはすべてのSDKで利用可能。言語を選ばない。
Python SDK(boto3)では context managerを使ってトランザクションをシュッとかける

ロールバックはどうやって実装すればよい?

一部の操作が失敗したり、条件を満たさなかったりすると、トランザクションはロールバックされる
ユーザーは commit/rollback のような操作は不要。サーバーサイドで行われる。

DynamoDBのロードマップ

開発者がDynamoDBを利用しやすいようにする
ユーザーの業種は多岐にわたる。要望を満たすべく、GDPR、コンプライアンス、バックアップなどのための機能を追加してきた
DynamoDBのミッションはスケールによらず10ミリ秒以下でレスポンスを返せること
ユーザーの様々な要望を取り込んでもこのミッションは維持する
顧客の利用費ができる限り安くなるように取り組んでいる。実際、トランザクションあたりの費用は古典的なRDBよりもずっと安い
ユーザーが特別な操作をしなくても、コンプライアンス・セキュリティレベルは向上している
サーバーサイド暗号化は以前はオプションだった。今はデフォルトで暗号化される
DynamoDBには他のデータストアのようなメンテナンスウィンドウもない。メンテナンスは透過に行われる
フルマネージドサーバーレスの素晴らしい所
PITR・バックアップはデータベースのサイズがMBだろうとTBだろうと同じように機能する
1テーブルで200TB以上の容量があり、2.5兆以上のアイテムがあっても問題ない
DynamoDBには革新的な機能が随時追加されているが、後方互換性は維持されている。
DynamoDBの前段にあるインメモリーキャッシュレイヤーのAmazon DynamoDB Accelerator (DAX)を例に取ると、エンドポイントを変えるだけでDAXの恩恵を受けられる
レイテンシーはマイクロ秒〜数ミリ秒になる