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

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種類(strongeventual)の整合性を提供
  • 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トランザクションを利用すると、複数の更新をアトミックに操作できます。

合わせて読みたい