[レポート] DAT201: Amazon DynamoDBの最新情報について！ #reinvent

おつかれさまです。どうやら会場にドッペルゲンガーがいる疑惑の新井です。

re:invent3日目セッションのA Deep Dive into What's New for Amazon DynamoDBに参加してきたので、セッションレポート投稿していきます。

前回から今回のreinventまでに発表があった、Dynamodb関連のアップデートを総括するようなセッションでした。

セッション概要

This is the general what's-new session for Amazon DynamoDB in which we cover newly announced features and provide an end-to-end view of recent innovations. We also share some customer success stories and use cases. Come to this session to learn all about what’s new for DynamoDB.

登壇者

• Tony Petrossian (General Manager, DynamoDB, Amazon)
• Jeff Wierer (Sr. Manager)

これまでのアップデートの内容

Point-in-time recovery

特徴として以下があげられています。

• 予想外の事故時の即時リカバリ用を想定 (オペミスなどを)
• バックアップ時にオリジナルテーブルのパフォーマンスに影響を与えない
• 1秒単位で復元可能
• テーブルデータを連続的にバックアップされる
• 復元時は新規テーブルが作成される
• 保持期間は、35 日間 (5 週間) に固定されており、変更することはできない
• あくまで即時リカバリ用なので、基本的なバックアップはOn-Demand-Backupを使う

• https://aws.amazon.com/jp/blogs/aws/new-amazon-dynamodb-continuous-backups-and-point-in-time-recovery-pitr/

SLA 99.999%

AWSはサービスコミットメントとして、各AWSリージョンごとに

• グローバルテーブルSLAが適用される場合、少なくとも99.999％
• 標準SLAが適用される場合、少なくとも99.99％

の月額稼働率を達成するための努力を行うとのことです。DynamoDBがサービスコミットメントを満たしていない場合は、サービスクレジットを受け取れます。

• https://aws.amazon.com/jp/dynamodb/sla/

Adaptive capacity

まず前提としてこれは機能ではないでが、DynamoDBの内部的構造の非常に重要な改善をおこなったという話です。

よく言われているDynamoDBのパーティションキー設計のベストプラクティスとして、可能な限りキーを分散させるとういのがあります。この１つの理由として、全体のキャパユニットが各パーティションに均一に割り当てられるため、ホットキーなどがある場合はスロットルが発生しやすくなるという問題がりました。

が、実際のワークロードでは、わかっちゃいるけど分散されている理想のキー設計が出来ないケースがあるよね？というフィードバックがあり、アップデートが行われたそうです。 これにより、不均等なアクセスパターンでも、ホットパーティションに対して読み書きを継続することができるようになったようです。

また、アダプティブキャパシティーは、すべての DynamoDB テーブルに対して自動的に有効になるため、明示的に有効または無効にする必要はないです。

• https://aws.amazon.com/jp/blogs/database/how-amazon-dynamodb-adaptive-capacity-accommodates-uneven-data-access-patterns-or-why-what-you-know-about-dynamodb-might-be-outdated/

• https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/bp-partition-key-design.html#bp-partition-key-partitions-adaptive

DynamoDB Transactions

• 複数のテーブルや複数のアイテムにまたがって、処理をおこないたい

• single api call でwrite/readなど複数の連続的処理が可能

• トランザクション分離レベルはSerializable
• トランザクション中にアイテムはロックされない
• トランザクション中にアイテムがトランザクション外で変更された場合、トランザクションはキャンセルされ、原因となったアイテムに関する詳細情報と共に例外がスローされる

• https://aws.amazon.com/jp/about-aws/whats-new/2018/11/announcing-amazon-dynamodb-support-for-transactions/

Dynamodb On-demand

• プロビジョンドキャパシティが0からスタートするので使わなければ課金されない
• 実質無制限
• オートスケーリングなど、ミニマムからスタートする場合と比べてよりコスト最適化が図れる
• 使いどころとしては、
  • 例えば、２週間に1度の数分間にアクセスがあるテーブル
  • 基本的には使われないようなテーブル
  • キャパシティが頻繁に上下するようなテーブル
• 一定のレンジでキャパシープランニングができる場合は、オートスケーリングやスケジューリング機能を利用する方がコスト的にはお得
• キャパシープランニングが出来ない場合も、一定期間On-demandで利用して測定した後、プロビジョンドモードに切り替えるのもあり

• https://aws.amazon.com/jp/blogs/aws/amazon-dynamodb-on-demand-no-capacity-planning-and-pay-per-request-pricing/

CassandraからDynamoDBへのマイグレーション事例

まとめ

今回のreinventで、DynamoDBのTransactionsとOn-demandの２つのアップデートがありましたが、どちらも反響は大きかったのではないでしょうか。(2018/11/28時点)

以上現地からのレポートでした。