Werner Vogel、DynamoDBトランザクションについて語る #reinvent
最初に
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の恩恵を受けられる
- レイテンシーはマイクロ秒〜数ミリ秒になる
デッドロックは起こる?
- デッドロックは起こらない
- 楽観的並行性制御を採用している
- トランザクションが長く残ることも
- DynamoDBでは従来のDBAがやってきたようなトランザクション・デッドロック監視は不要
- トランザクションの完了・キャンセルはサーバーサイド(AWS)で行い、キャンセルした場合は、エラー原因がAPIのレスポンスに含まれる
まとめ
DynamoDBトランザクションを利用すると、複数の更新をアトミックに操作できます。
