Zenn
Closed9

How to determine if Amazon DynamoDB is appropriate for your needs, and then plan your migraion

AWS
DynamoDB
hassaku63hassaku63

このブログの主旨

In this blog post, I explain how to evaluate DynamoDB as a potential database service for your application, and then explain how to plan your migration to DynamoDB, including best practices.

DynamoDB を選定することが適切かどうか、評価する方法を説明する。

べスプラの説明もしつつ、DDB に移行する方法を説明する

hassaku63hassaku63

Is DynamoDB right for your use case?

  1. 他のDBを使っていて、スケーラビリティの問題があった場合
  2. アプリケーション、あるいはサービスの開発に積極的に取り組んでいる場合。開発中でないレガシーアプリケーションの移行は（データアクセス層の改善に投資するつもりがないのであれば）必ずしも意味がない
  3. OLTP のワークロード。ハイパフォーマンスな read/write は DDB で簡単に管理できるようになり、負荷の増減に対して一貫したパフォーマンスを期待できるようになる
  4. 手作業の介入を必要とせず、高い可用性を一貫して提供する必要がある、ミッションクリティカルなアプリケーション
  5. データベースキャパシティの追加を管理する人員が不足していて、オペレーションチームの負荷を軽減する必要がある
  6. バックアップ・リストアの戦略によらず、高いデータの耐久性が要求される場合
  7. データベースに要求されるピークと谷を予測するデータが不足している
hassaku63hassaku63

DynamoDB suitability guidelines

DDB を使う前に、以下の評価質問のほとんどに対して yes と回答できてるのが望ましい

  1. データを 1,2 つのテーブルで、階層的または集約構造にまとめられるか？
  2. データの保護は重要？
  3. 従来のバックアップでは非現実的、またはコストがかかりすぎる場合（例えば、更新の頻度や全体のデータボリュームの問題によって）
  4. "特徴的" なデータベースワークロードを持っていますか？（1日のうち時間によって負荷が大きく変動する、あるいは高い成長率や高トラフィックイベントによって駆動される）
  5. 負荷状況によらず、チューニングを要せずに、1桁台の ms オーダーのレスポンスを一貫して要求する？
  6. スケーラブルで複製可能、あるいはグローバルな構成でサービスを提供する？
  7. 高テラバイトの規模のデータを保持する必要がある？
  8. 開発者は、短いがおそらく険しい NoSQL の学習曲線に対して投資する意思があるか？

また、DDB に不適切なワークロードには以下のようなものがある。

その1。

アドホックな（※1）クエリの要求がある場合。アプリケーションレイヤーのフレームワークなどを用いて DDB テーブルの間にリレーションを実装する方法はあるが、これらは一般的に扱いづらい。

※1 .. .事前に特定のパターンやスキーマに従って設計されていない、その場で必要に応じて行われるクエリ

その2。

OLAP あるいはデータウェアハウスの実装。このタイプのアプリケーションは fact や dimension といった分散したテーブル構造と、それを結合して提供する正規化ビューを要求する

その3。

BLOG ストレージ。DDB ではバイナリアイテムは 400kb までに制限されている。このような場合の一般的なアーキテクチャは、実体のデータを保存した S3 などへの参照を DDB テーブルに保持することである。

以上のことを考慮して DDB が適していると判断した場合は、後続の「移行計画」のセクションに行ける

hassaku63hassaku63

DynamoDB migration planning (1)

DDB への移行を計画するなら、まずは PoC の実装を検討するとよい。テスト段階で、計画時点で分からなかった変数を特定するためにシステムを並行稼働することができる。インタラクティブで、アジャイルなやり方がベスト。

このへんの詳細は Best Practices for Migrating from an RDBMS to Amazon DynamoDB (※1) を読むとよい

※1 ... AWS のホワイトペーパー。元のリンク先は pdf で、現在アーカイブ状態

ここでは RDB からの移行を念頭に置くが、他の DBMS であっても適用可能。

1. Developer training

開発者の再教育と、アプリケーション内に埋め込まれた SQL を DDB のような NoSQL への API コールに置き換えることが最初のステップになる。

Amazon DynamoDB Developer Resource を利用して、トレーニング時間を確保する。

DynamoDB local はローカル実行できる DDB のバージョンである。これを利用して開発することで、最小の変更労力で実際の DDB に対してアクセスするアプリケーションを動かせる。また、このアプローチは開発・テスト時に発生する DDB のコストを削減することにも繋がる。

LSI, GSI についても探求すると良い。これらはクエリ最適化に役立つが追加コストが罹るので、必要に応じて利用する。

2. Data conversion

移行前に、既存のテーブルを単一のテーブルに変換できないか検討した方がよい。サイズやストレージにもよるが、この検討を先にやっておくことで後の労力を軽減できる。また、定期的にデータ移行を行うジョブを構築することもできる。

こうした非正規化の Tips は First Steps for Modeling Relational Data in DynamoDB に記載されている。このドキュメントは Relational modeling のような話も含んでいる

3. Data migration

非正規化テーブルやエクスポートされたデータが準備できたら、データのマイグレーション方法の検討をする。
一括で移行するか、最新データを同期するバッチを使うか判断する。

DMS は DDB をターゲットとしてサポートしている。ソースには RDB や S3, MongoDB をサポートする。テラバイト級のデータを移動するために Snowball を使うこともできる。
DMS を使う場合は、移行中にデータ複製のために使用した EC2 インスタンスに対してのみ料金を支払う。DDB 移行プロジェクトに DMS を利用するほとんどのケースにおいて、レプリケーションとテストの期間の後に切り替えを行う。

一般的なルールとして、データの移動のために利用可能な帯域を考慮して、データ移行に1週間以上の期間が必要であれば、移行初期に DMS の検討をした方が良い。Snowball の使用は、データ移行の共通の課題、すなわち大規模のデータ転送に N/W コストがかさむこと、転送に長い時間がかかること、セキュリティ上の考慮事項に回答できる。Snowball を使ってオンプレミスから AWS にデータを持ち込んだら、Datapipeline (※2) や DMS を使って DDB にデータをインポートする。

※2 ... 2023/12 現在は Data Pipeline のコンソールアクセスが閉じられており、おそらく利用は非推奨。

4. Consistency model

ワークロードにおいて考慮が必要なことの1つは、各テーブルが更新された後の読み込みの一貫性モデルである。

DDB はリージョン内の 3 つの AZ に対して、テーブルに更新書き込みを行う。これは耐久性のためである。また、通常すべてのロケーションに対する書き込みは 1s 以下で完了する。

DDB は、3つの読み込み一貫性モデルをサポートする。(※3)

  • eventtually consistent (※4)
  • strongly consistent
  • transactional

※3 ... リンク先のドキュメントでは3つ目の一貫性が "Global tables read consistency" として紹介されている。ちょっと違うように見えるの理由は不明。この記事の時点では Global table も Transaction もリリースされているはず
※4 ... 日本語では「結果整合性」と呼ばれるもの

あたなが明示的に指定しない限り、DDB は "eventually consistent" を利用する。 "eventually consistent" では、タイミングによって、ときどき古いデータが返される場合がある。これをあなたのアプリケーションとユーザーが受け入れられる場合は、プロビジョンするキャパシティは少なくなり、3つの一貫性モデルのうち最もコストが小さくなる。

"strong consistency" を選択する場合は、DDB はすべての書き込みに成功した最新のデータに基づくレスポンスを返す。しかしプロビジョンするキャパシティとコストは高くなる。(※5)

※5 ... 強整合性を使うと、デフォルトの結果整合の2倍のコストがかかる（要: 出典リンクの追記）

最後の書き込みが常にすべてのリクエストで利用可能である必要がある場合は transactional API の利用が最良である。トランザクションに対応し、all-or-nothing なテーブル変更をサポートするための開発者体験をシンプルにするため、DDB はトランザクション内において2つの read または write を行う。すなわち、以下の2つである。

  1. prepare the transaction
  2. commit the transaction

それぞれの read/write に対するコストは同じだが、任意のトランザクションを伴うデータ変更では要求の総数が増えるため、最もテーブル更新に対するコストが高い選択肢となる。

hassaku63hassaku63

DynamoDB migration planning (2)

続き

5. Security – encryption

この投稿で推奨している移行アプローチを採用した場合は、データ移行中の転送は暗号化される。DDB はデフォルトで暗号化が有効になっている。格納状態のデータに対する暗号化は、AES-256 が使用され、認証されないアクセスからデータを保護するのに役立つ。（※1）

※1 ... 「格納状態のデータに対する暗号化」に対応する原文は "Encryption at rest" と表現される。"at rest" は休止状態を意味し、転じてストレージの中にあるデータのことを指す言葉として使われているらしい。

テーブルに格納したデータの暗号化に KMS を使うこともできる。この機能によって、オペレーション負荷と機密
データの保護複雑性がなくなる。パフォーマンスの低下や暗号化に関連するコストの増加はない。

テーブルを作成するとき、テーブルの暗号化を目的として CMK を使用するために2つの選択肢がある。

1つは AWS-owned CDK であり、デフォルトはこちら。CMK のみによってテーブルは暗号化される。鍵がない場合は DDB が内部的にこれを作成する。これは無効化できない。

もう1つは AWS managed CDK である。こちらはユーザーが自分で CMK を作成するパターン。マネコン上でも作成・保存された CMK が確認できる。KMS の料金が発生する。こちらの選択肢ではキーポリシーを確認できるが、DDB 使用のために作成されたポリシーは変更できない。
こちらのオプションには監査とセキュリティ監視の視点から価値がある。CloudTrail のログから KMS 暗号化の API 呼び出しを表示できるため、DDB に対する暗号化と復号の処理を確認できる。

6. Network security – VPC endpoint for DynamoDB

多くの顧客は、VPC Endpoint を利用して DDB へのアクセスを行う。
VPC Endpoint を用いることで、プライベートサブネットからの NAT や、仮想的な N/W Gateway あるいは Internet Gateway を介して DDB に接続する場合のセキュリティ上の懸念事項が軽減できる。

アプリケーションと DDB 間の、転送中の最適なセキュリティを確保するために、VPC Endpoint の有効化を検討すべきである。

7. Performance – throughput and auto scaling

DDB のパフォーマンスを管理するための労力は非常に少ない。あなたが設定したスループットに基づき、わずかな応答時間のばらつきで期待通りにサービスは動作する。
パフォーマンスのための計画を自動化し、あなたのスループット設定の潜在的なエラーを軽減するために、新しいサービスの機能を利用できる。

1つ目は Throughput Capacity for Reads and Writes のガイドを読むこと。過剰ではコストが増加し、過少ではアプリケーションのパフォーマンス低下を招く可能性がある。

2つ目は auto scaling を使うこと。間違った RCU/WCU を設定してしまわないように、auto scaling を検討できる。
auto scaling では、時間の経過とともに必要に応じてキャパシティが自動調整される。コストの考慮事項に基づき、スケーリングの上限を設定できる。CloudWatch と DDB コンソールを使用して auto scaling の監視を行い、スケーリングの上限が低すぎないことを確認することができる。この方法を使うことで、auto scaling の管理を常時気にかける必要はなくなる。

DynamoDB on-demand capacity mode を使うこともできる。この選択肢はスケーリングをすべて AWS に管理させることができる。

8. Required performance – microseconds versus milliseconds?

あなたのワークロードに非常に高いパフォーマンス要求があり、レスポンスタイムに1桁 milli sec ではなく micro sec が求められる場合、DAX を検討するかもしれない。Read が重たいアプリケーションが要求するスループットを下げるために、インメモリな DAX を使用できる。ほとんどの場合、DDB 操作のコストも低減できる。

hassaku63hassaku63

DynamoDB migration planning (3)

続き

9. Reliability considerations

DDB への移行が終わったら、データロスから復旧するためのバックアップを考慮する必要がある。DDB はリージョナルなサービスなので、任意の DDB サービス障害から復旧できる方法も考慮する必要がある。

従来のデータ保護の方法として、DDB は point-in-time recovery をサポートしている。他の方法で保護できない(?) 場合、あるいは S3 など他のロケーションからオンデマンドで再構築することができない場合、アプリケーション起因のでデータ破損やユーザーエラーからテーブルデータ保護するために PITR を有効化する必要がある。
PITR を使う場合、テーブルのリカバリは新しいテーブルの作成によって行われる。つまり、スループットや auto scaling limit などの関連する設定は再設定する必要がある。

DDB は on-demand backup and restore にも対応している。スケジュールによって、あるいは必要に応じて、データを個別に保護できる。これはテーブルのパフォーマンスに影響を与えず、バックアップの処理は数秒以内に完了する。バックアップはカタログで保存され、取り出し用に使用できる。バックアップはテーブルの状態に関わらず保存されるので、テーブルの意図しない削除にも利用できる。(※1)

※1 ... 原文のニュアンスについて補足

データの保存を表現する語彙に "store" ではなく "preserve" が使われている。

These backups also can be used to protect against inadvertent table deletion because they are preserved regardless of table status.

この単語には保護 や維持するのニュアンスが強調されている点が、単に特定の場所に格納されていることを示す "store" との違いになる。

取得したバックアップは時間経過や外部からの影響から守られていて、バックアップ取得時点の状態を維持したまま保存されていることを示唆するニュアンスで "preserve" が用いられている...と思われる

10. Regional resiliency

アプリケーションをマルチリージョンにデプロイしたり、世界中に提供したいなら、global tables を考慮する。
global tables はサポートされてるすべてのリージョンにDDB テーブルをデプロイし、マルチマスターのレプリケーションを提供する。

global tables best practices の内容に従い、auto scaling の有効化をキャパシティ管理の規定の選択とすることが重要。

strongly consistent reads は、global tables の中の単一のリージョンでのみ使用できる。eventually consistent reads が唯一使用可能な読み込みタイプである。

11. Optimizing capacity and spending

データを移行したら、DDB の利用を最適化していくことが重要。以下の内容に従って、キャパシティや費用の最適化をやっていく。

AWS は最近（出典元の執筆 = 2019/01 時点）on-demand capacity mode というキャパシティを発表した。これを使うと、AWS が read/write のキャパシティをピークの山と谷に一致するように調整してくれるようになる。初期のキャパシティ設定や auto scaling の設定は必要ない。しかし、相対的にキャパシティが安定している場合は on-demand capacity は運用コストの低減には役立たないかもしれない。

以下、DDB の価格を理解するための重要事項。

  • 運用時には、時間ごとに一定な provisioned capacity に基づく料金もしくは（on-demand モードを使用して）on-demand な料金を支払う
  • RCU と WCU の価格はリージョン単位で異なる
  • auto scaling は、常に最小のキャパシティを使用する状態を確認するために使える
  • eventually consistent reads が使えるなら使う。同じ capacity であっても、eventually consistent の方が strongly consistent reads よりも多くの要求を扱える
  • マルチリージョンなアプリケーションを開発する場合は、リージョン間の転送コストを考慮する
  • リージョン間のデータ転送コストの管理に気を配る（おそらく AWS の外への転送コストも含む文脈？）
  • CloudWatch, Cost Explorer, Budgets をキャパシティと費用の管理に使用する
  • 事前にキャパシティを購入しておくこともできる (reserved capacity)。read/write のスループットが予想できているなら、reserved capacity は通常の provisioned capacity の価格よりも大幅に費用を削減できる。（reserved capacity は、on-demand capacity モードには適用できないことに注意。なぜなら、 on-demand capacity はプロビジョニングされたキャパシティではなく、リクエストごとに支払う方式であるため）

多くの AWS の最適化活動と同じように、自分が必要とするパフォーマンスやストレージに対してだけ支払っている（過剰に支払わない）ことを確認するために、監視と反復的な活動を実施するのが重要である。

hassaku63hassaku63

Summary

このポストでは DDB を評価する方法、DDB への移行を計画する方法について説明した。

hassaku63hassaku63

完走した感想。

原則的なものはなんとなく俯瞰できた。ただ、細部の話は相変わらず全然なので、これは脳内インデックスを構築するためのものとして記憶して、各論はここに登場したドキュメントを追いかけないと実践に近い知識は得られなさそう。

例えばテーブル非正規化にまつわる話、キャパシティ管理のオプション、一貫性モデルあたり。

あと、DDB に向かない用途として OLAP のユースケースが出てきたが、fact や dimension のような設計パターンは全然知らなかったので、それを眺めたりする時間も大変知識の広がりを感じてよかった

OLAP あるいはデータウェアハウスの実装。このタイプのアプリケーションは fact や dimension といった分散したテーブル構造と、それを結合して提供する正規化ビューを要求する

このスクラップは4ヶ月前にクローズされました