AWS中級者を目指すためのAmazon DynamoDB入門 意思決定編

導入

「AWS中級者を目指すための」と題して、AWSの各サービスについての深掘りをしていく記事です。
これらの記事では、自分が業務をしている際や勉強をしている際に疑問に感じたことを解消し、表面的にしかわかっていないところから一歩ステップアップするための記事となっています。

DynamoDBは、AWSのサービスの中でも比較的よく目にするサービスである一方、実務で使用するシーンは限られるように感じ、実際にどういったシーンで使用するべきかまで言及しているようなハンズオンや記事は少ないように感じます。
また、そういったことについて言及している公式ドキュメントも、そういった観点を持っていない限りアクセスしにくいです。
この記事では、公式ドキュメントをもとに、どのような意思決定をもとにDynamoDBを使用するべきかについて、記載をします。

対象読者

• Amazon DynamoDBについてざっくりわかっている方
• DynamoDBの利用シーンや、設計観点の理解が不安な方

そのため、この記事を通して、Amazon DynamoDBについて知ってもらうことで、同様のモヤモヤを抱えている方の一助になればと考えています。
また、この記事では、意思決定をする際の重要な根拠を示せるようになるため、ほとんどが引用となっていますこと、ご了承ください。

この記事を作成するに際して感じていた課題

• AWSの入門記事等でアプリを作成する際、何のことわりもなくDynamoDBを使用している理由に説得性が欠けていると感じている
• DynamoDBのドキュメントを見るとメリットばかり書いてあるが、実際の活用事例の多さに対し利点のギャップがある
• DynamoDBについて表面的になぞった記事ばかり転がっている
• DynamoDBを使用することを前提にしていて意思決定に関する情報が薄い
• 上記の理由のため、適切な活用シーンがわからない

この記事で解決したいこと

• どういったシーンであればDynamoDBを採用できるかを理解する
• アクセスパターンの洗い出しについて理解する

ユースケースに対する DynamoDB の適性

以下に当てはまる場合は、DynamoDB を検討してください。

1. 他の従来型データベースシステムで拡張性問題が生じたことがある。
2. アプリケーションまたはサービスの開発に積極的に関与している。開発中ではないレガシーアプリケーションを移行することは、そのアプリケーションのデータアクセス層、インライン SQL コード、またはストアドプロシージャや関数を実装するために時間と労力を費やしてもよいという場合を除いて、必ずしも道理にかなうとは限りません。
3. オンライントランザクション処理 (OLTP) ワークロードを扱っている。DynamoDB を使うと、高パフォーマンスの読み込みと書き込みの管理が容易になり、多種多様なロード全体で実質的に一貫したパフォーマンスを期待できます。
4. 手動での介入なく常に高可用性を保たなければならないミッションクリティカルなアプリケーションをデプロイしている。
5. 追加のデータベース機能の管理に関して人材が不足しており、運用チームの作業量を減らさなくてはならない。
6. バックアップ/復元戦略を問わず、高レベルのデータ耐久性が必要。
7. 必要なデータベースパフォーマンスにおけるピークと谷を予想するためのデータが不十分。

DynamoDB 適合性ガイドライン

DynamoDB の使用を決定する前に、以下の評価質問のほとんどに「はい」と答えることができる必要があります。

1. データを 1～2 テーブルの階層構造または集約構造に編成できますか?
2. データ保護は重要ですか?
3. テーブルの更新率、または全体的なデータサイズが原因で、従来のバックアップの実現が困難、またはコストが法外に高くなりますか?
4. データベースのワークロードが時間帯によって大幅に変化する、または高成長率や高トラフィックイベントによって左右されますか?
5. ロード状態にかかわらず、かつ調整取り組みなしで、アプリケーションまたはサービスには、常に 10 ミリ秒未満の応答時間が必要ですか?
6. 拡張可能な設定、レプリケートされた設定、またはグローバル設定でサービスを提供する必要がありますか?
7. アプリケーションには、高テラバイトのサイズ範囲でデータを保存する必要がありますか?
8. 開発者のために、短期間でも急勾配である可能性がある NoSQL 学習カーブに投資する意思がありますか?

アクセスパターン

以下のAWS ドキュメントでは、DynamoDB のデータモデル設計で重要となる「アクセスパターンの洗い出し」について、体系的なアプローチを説明しています。

まとめ

自分としては、まず、基本的には、高トラフィックイベントがある等、低レイテンシが求められるシステムだとわかれば、まずDynamoDBの使用、部分使用を検討しようと思います。
その上でアクセスパターンを考慮して1,2テーブルで表現できないかを検討しますが、おそらくここがかなり時間が要する場面になると思います。
「NoSQL学習カーブに投資する意思がありますか？」という項目があるように、DynamoDBの設計はRDBのそれとは違うのと、求められるシーンを考慮すると、そもそも複雑でかつ低レイテンシが求められる難易度の高いケースと考えるのが妥当です。

とはいえ、「投資する意思がないのでやりません」ともできないので、そもそも投資が必要だということを前提に、設計に必要な工程に対してより多くのリソースを避けるよう握っておくのが、ひとまず考えられる特効の策かと考えられます。

参考

https://aws.amazon.com/jp/architecture/?
https://docs.aws.amazon.com/prescriptive-guidance/latest/dynamodb-data-modeling/process-flow.html
https://aws.amazon.com/jp/blogs/news/how-to-determine-if-amazon-dynamodb-is-appropriate-for-your-needs-and-then-plan-your-migration/
https://aws.amazon.com/jp/blogs/news/how-to-determine-if-amazon-dynamodb-is-appropriate-for-your-needs-and-then-plan-your-migration/