Amazon Web Services ブログ

Amazon DynamoDB がニーズに合うかどうかを判断し、移行を計画する方法

 

分かれ道

AWS CTO のワーナー・ヴォゲルスは、AWS の仕事は「企業の痛みを管理すること」だという冗談を言うことがよくあります。これは、AWS のお客様が直面する IT 面での課題の大半における本質を突く言葉です。「お客様に最大のメリットをもたらすことができるのはどこか」と呼び掛けるだけで、しばしばデータベースと関連するライセンス費用、パフォーマンスとスケーラビリティの管理、そして専門的なデータベース管理者の人件費に関する話し合いが始まります。Amazon DynamoDB などの完全マネージド型の NoSQL データベースサービスは、これらの課題に対応し、多くのメリットをもたらします。

このブログ記事では、お使いのアプリケーションに対するデータベースサービスの候補として DynamoDB を評価する方法を説明してから、DynamoDB への移行を計画する方法を、ベストプラクティスを含めて説明します。

データベースの自由な選択

AWS では、データベースの自由な選択を信じており、お客様には必要なデータタイプ、アクセスモデル、そして拡張性に適したデータベースを評価して選択することを推奨しています。また、運用管理を AWS に任せている間は、お客様の開発者とシステム管理者が自由にそのアプリケーションを構築して動作させることが可能であるべきだとも考えています。これは、高スケールのデータベース運用に関して特に重要です。

クラウドネイティブのアプリケーションは、レガシーアプリケーションとはアーキテクチャ面で異なる場合が多く、これらは定常的に、疎結合で、複数の自動スケーリングコンピューティング層を使ってデプロイされます。オプションを検討し、必要に応じてそれらの試運転を行う時間を取ることが大切です。Polyglot Persistence、つまりクラウドネイティブのアプリケーションとレガシーアプリケーションの両方に適したデータベーステクノロジーを選ぶことに信念を持ち、アプリケーション開発課題のすべてに対して同じデータベースアプローチを使う誘惑に負けないようにしましょう。

AWS は、実験のしやすさと透明性のある料金設定を提供することによって、適切なデータベースの選択と調整をシンプルにし、コストも商用データベースエンジンより低額になります。利用可能な AWS のデータベースオプションは、その数と能力の両方で急速に成長しており、その一部はマイクロサービス、IoT、そして数多くの専門的分析に対する要件によるものです。オープンソースまたはサードパーティーデータベースエンジンの大半は、AWS Marketplace およびその他リポジトリを通じて起動および管理し、適切にサイズ調整された Amazon EC2 インスタンス上で、または Amazon Relational Database Service (Amazon RDS) を使用することで運用することができます。

また、運用作業を AWS に任せ、DynamoDB などの完全マネージド型サービスを使ってデータベース管理者のコストを回避することもできます。ワーナー・ヴォゲルスは、Amazon.com のデータベースニーズの約 70 パーセントにリレーショナルモデルが必要なく、キーバリュー型 を使用した方が役に立つことに気付きました。これが、AWS が DynamoDB を構想して構築した理由です。DynamoDB は、そのシンプルさからしばしば低スケールの運用に使用されますが、Amazon.com によって要求されるような超大規模運用にも優れた力を発揮します。

ユースケースに対する 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 学習カーブに投資する意思がありますか?

DynamoDB には適さないワークロードには以下が含まれます。

  • アドホッククエリアクセスを必要とするサービス。複数の DynamoDB テーブルにまたがってエンティティリレーションシップを実装するために外部のリレーショナルフレームワークを使用することは可能ですが、これらは概して煩雑です。
  • オンライン分析処理 (OLAP)/データウェアハウス実装。これらのタイプのアプリケーションには通常、データの正規化 (リレーショナル) ビューを本質的に提供するファクトテーブルとディメンションテーブルの分散と結合が必要です。
  • バイナリラージオブジェクト (BLOB) ストレージ。DynamoDB は最大 400 KB のバイナリアイテムを保存できますが、DynamoDB は一般的にドキュメントまたはイメージの保存には適していません。この実装により適したアーキテクチャパターンは、DynamoDB テーブルに Amazon S3 オブジェクトへのポインタを保存することです。

これらの考慮事項を検討した後で DynamoDB がニーズに適していると判断したら、次の移行計画セクションのステップを実行する用意が整ったことになります。

DynamoDB 移行計画

従来型データベースのワークロードを DynamoDB に移行するときは、初期概念実証の実装を検討する必要があります。また、テストフェーズ中にシステムを並行して実行し、計画フェーズ中に分からなかったすべての不確定要素を識別することもできます。反復型の俊敏なアプローチが最良です。このセクションの移行計画ステップの詳しい説明については、Best Practices for Migrating from an RDBMS to Amazon DynamoDB を参照してください。

簡略化のため、ここではオンプレミスの RDBMS を DynamoDB に移行していることを前提としますが、他の移行ケースでもこれらのステップに従うことが可能です。

1.開発者トレーニング

データ駆動のシステムをデータセンターからクラウドに移行するときの最初のステップは、開発者がコード内の埋め込み SQL の使用から、DynamoDB などの NoSQL システムへの API コールの実行に切り替えることができるようにする開発者の再訓練です。

Amazon DynamoDB の開発者用リソースを使用した開発者のためのトレーニング時間を確保してください。この開発者用リソースには、セルフペースラボ、お客様事例、および高品質のトレーニングが含まれています。一般の開発者は、DynamoDB について十分理解するために 2～3 日かかり、実験を行って、効率的なコーディングとユニットテストのためにそれぞれの開発ツールを準備する上でさらに数日必要になります。

DynamoDB ローカル は、開発チームが DynamoDB ウェブサービスにアクセスすることなくアプリケーションを記述してテストするために使用できる DynamoDB のダウンロード可能なバージョンです。コードが完成したら、変更をいくつか行うだけで、コードをウェブサービスで実行できます。このアプローチを活用することによって、開発とテストに DynamoDB を使用するコストを回避することもできます。

開発チームは、移行したテーブルの名前と値のペア全体におけるクエリ最適化をサポートするために、ローカルとグローバルのセカンダリインデックスの使用も検討する必要があります。グローバルセカンダリインデックスは、外部の AWS が管理する DynamoDB テーブルと同様に透過的に機能し、これらの使用には追加のコストが発生します。グローバルセカンダリインデックスは、必要な場合にのみ使用してください。

2.データの変換

移行プロセスの後半における時間と手間を省くため、サイズとストレージの考慮事項に応じて、移行前にソースデータベースで既存のテーブルを単一のテーブルに変換することを検討する必要があります。AWS への移行のために定期的にデータを出力するデータベースジョブを作成することもできます。参考のために、リレーショナルモデリング を含む DynamoDB でリレーショナルデータをモデル化するための最初のステップで非正規化のためのヒントを確認してください。

変換プロセスを容易にするため、AWS Marketplace では、データを RDBMS とその他ソースから DynamoDB にパイプするための AWS パートナーによるサードパーティーツールを利用できます。AWS Marketplace ツールには、時間単位で使用できるという利点があり、請求イベントはユーザーの AWS 請求書に送信されます。AWS Marketplace ソリューションの使用が済めば、その使用を終了して、リソースへの支払いを停止することができます。

3.データの移行

非正規化されたテーブル、またはエクスポートされたソースデータの準備が整ったら、移行ソースからターゲットへの切り替え前に、データをすべて一括で同時に移行するか、または切り替え直前の同期化ステップを伴うバッチで移行するかを検討してください。AWS Database Migration Service (AWS DMS) は DynamoDB を移行ターゲットとして扱い、ソースはサポートされるリレーショナルデータベース、または Amazon S3 もしくは MongoDB になります。AWS DMS がサポートする移行シナリオの多くは、中間ステップとして、テラバイト単位のデータの移動に AWS Snowball を使用することもできます。AWS DMS では、データの移動とレプリケーションプロセスで使用する Amazon EC2 インスタンスのコストのみを支払います。大抵の DynamoDB 移行プロジェクトは AWS DMS を使用してデータを移動させた後、レプリケーションとテストの期間を経て切り替えを行います。

原則として、移動に利用できる帯域幅を考えると、データの移行に 1 週間以上かかるという場合は、初期移行に Snowball の使用を検討するようにしてください。Snowball は、AWS クラウドから、またはそれに対する大量のデータの転送がセキュアに行われるように設計されたデバイスを使用する、ペタバイト規模のデータ転送ソリューションです。Snowball の使用は、高額なネットワークコスト、長い転送時間、およびセキュリティ面での懸念を含む大規模なデータ転送に伴う一般的な課題に対処します。Snowball では、オンプレミスのデバイスにデータを移動させます。デバイスはその後、AWS データセンターにセキュアに輸送されます。次にその内容が Amazon S3 にロードされ、ロードされたら AWS Data Pipeline を使用して DynamoDB にインポート、または先ほど説明した方法で AWS DMS を通じてインポートすることができます。

4.整合性モデル

ワークロードに対する考慮事項のひとつに、各テーブルの更新後に必要な読み込み整合性モデルがあります。DynamoDB はテーブルの更新を、耐久性のために各 AWS リージョン内にある 3 つのアベイラビリティーゾーンに書き込み、通常 1 秒以下ですべてのデータがすべてのロケーションに書き込まれます。

DynamoDB は、結果整合性、強一貫性、およびトランザクションの 3 つの読み込み整合性をサポートします。アプリケーションに異なる整合性モデルを指定した場合を除き、DynamoDB は結果整合性読み込みを使用します。アプリケーションとユーザーが、タイミングに基づいて取得レスポンスが時折古いデータを取り出す可能性がある結果整合性読み込みを許容できる場合、より少ないキャパシティーをプロビジョニングできるため、コストが整合性の 3 つの選択肢の中で最も低くなります。

強一貫性読み込みを選択する場合、DynamoDB は正常に行われたすべての書き込み操作からの最新データでレスポンスを返し、プロビジョニングするキャパシティーとコストが増加します。

すべてのリクエストに対して最後の書き込みが常に利用可能であることを必須とするトランザクションアプリケーションについては、トランザクション API が最も良い選択です。トランザクションをサポートし、「オールオアナッシング」のテーブル変更を行う開発者経験をシンプルにするため、DynamoDB はトランザクションの全アイテムの、2 つの基本的な読み込みと書き込みを行います。そのひとつはトランザクションを準備するためのもので、もうひとつはトランザクションをコミットするためのものです。それぞれの読み込みと書き込みのコストは同じですが、どのトランザクション変更についても読み込みと書き込みの合計回数を増加させるため、最も高額なテーブル更新オプションと読み込み整合性モデルになります。

5.セキュリティ – 暗号化

この記事で推奨されている移行アプローチを使用する場合、データは移行中の転送時に暗号化されます。DynamoDB で新しいテーブルを作成するときは、保管時の暗号化がデフォルトで有効化されます。DynamoDB の保管時の暗号化は、不正アクセスからデータを保護するために役立つ 256 ビットの Advanced Encryption Standard (AES-256) を使用します。保管時の暗号化メカニズムは、テーブルの暗号化に使用される暗号化キーの管理のために AWS Key Management Service (AWS KMS) を統合しています。この機能は、機密性のあるデータの保護に関わる運用上の負担と複雑性を取り除きます。暗号化によるパフォーマンスの低下やコストの負担はありません。

新しいテーブルを作成するときは、テーブルの暗号化を目的として AWS KMS でカスタマーマスターキー (CMK) を作成して使用するための 2 つの暗号化オプションのいずれかを選択します。最初のオプションはデフォルトの暗号化タイプである AWS 所有の CMK です。このデフォルトオプションでは、DynamoDB が単一のサービス CMK を使ってテーブルを暗号化します。このキーが存在しない場合、DynamoDB が無料でキーを作成して管理し、キーを無効化することはできません。

2 番目の暗号化オプションは、AWS 管理の CMK と呼ばれるものです。このオプションを選択すると、CMK が作成されてユーザーのアカウントに保存され、AWS KMS がそれを管理します (AWS KMS 料金が適用されます)。このオプションでは、AWS アカウントで CMK とそのポリシーを表示することができますが、DynamoDB による CMK の使用のために作成されたキーポリシーを変更することはできません。AWS CloudTrail ログで AWS KMS に対して実行された API コールを閲覧することによって、作成した DynamoDB テーブルにおける暗号化と復号化操作を確認することができるため、この 2　番目のオプションには監査およびセキュリティ監視において大きな価値があります。

DynamoDB とのコミュニケーションには、SSL/TLS 暗号化を使用することでネットワークトラフィックを保護する HTTPS プロトコルがデフォルトで使用され、これには AWS Command Line Interface および AWS SDK からのコミュニケーションが含まれます。

6.ネットワークセキュリティ – DynamoDB のための VPC エンドポイント

AWS のお客様の多くは、セキュアな DynamoDB のための VPC エンドポイントを使用して、それぞれの VPC から DynamoDB にアクセスします。そうすることによって、ネットワークアドレス変換ゲートウェイ経由のプライベートサブネット、または仮想プライベートゲートウェイやインターネットゲートウェイから DynamoDB に接続することに関するセキュリティ懸念が軽減されます。アプリケーション層と DynamoDB 間の転送における最適なセキュリティのため、DynamoDB インスタンスに対する VPC エンドポイントの有効化を計画するようにしてください。

7.パフォーマンス – スループットと Auto Scaling

DynamoDB のパフォーマンスの管理には、管理上の労力がほとんど必要ありません。このサービスは、スループット設定の基づいた応答時間における変化がほとんどない状態で期待通りに動作します。サービスの新しい機能をいくつか使用して、パフォーマンスのための計画を自動化し、スループットの設定におけるエラーの可能性を軽減することができます。

まず、読み込みと書き込みのスループットキャパシティーガイドを使用してください。より多くのキャパシティーを使うと、キャパシティーのコストが希望の金額よりも高くなる可能性があり、必要な量よりも少ないキャパシティーは、アプリケーションパフォーマンスの低下につながる場合があります。

次に、読み込みキャパシティーユニットと書き込みキャパシティーユニットを誤って設定することについて心配しなくてもすむように、テーブルに Auto Scaling を有効化するようにしてください。Auto Scaling を使用することにより、時間の経過とともに必要となるパフォーマンスに基づいて AWS がキャパシティーを増減させます。コストの考慮事項に基づいてスケーリングに制限を設定することができ、設定後は Amazon CloudWatch と DynamoDB コンソールを使って Auto Scaling の自動化を監視し、Auto Scaling の上限を低く設定しすぎていないことを確認できます。このアプローチを使用することによって、経時的に Auto Scaling を管理する必要がなくなります。

また、DynamoDB のオンデマンドキャパシティーモードに切り替えて、AWS にすべてのスケーリングアクティビティの管理を任せるユーザーもいるかもしれません。

8.必要なパフォーマンス – マイクロ秒対ミリ秒

ワークロードに、一桁のミリ秒単位ではなくマイクロ秒単位で測定される応答時間を伴う極めて高いパフォーマンスが必要である場合、Amazon DynamoDB Accelerator (DAX) をテストしてみるとよいかもしれません。DAX のインメモリアクセラレーションを使用すると、読み込み集約型の所定のアプリケーションに必要な DynamoDB スループットキャパシティーを低減させることができるため、ほとんどの場合において DynamoDB の運用コストも削減されます。

9.信頼性に関する考慮事項

データを DynamoDB に移行した後は、データ損失イベントから復旧できるように、テーブルの内容をバックアップで保護する必要があります。DynamoDB はリージョンサービスであるため、DynamoDB サービスに不具合が生じた場合に復旧できるようにすることも考慮するようにしてください。

従来のデータ保護については、ポイントインタイムリカバリ (PITR) が DynamoDB でサポートされています。他の方法でテーブルの内容を保護できる、または Amazon S3 などの固定ロケーションからオンデマンドで再構築できる場合を除き、PITR を有効化して、アプリケーションが原因の破損やユーザーエラーからテーブルデータを保護するようにしてください。テーブルを復旧する必要がある場合、テーブルは新しいテーブルとして復旧され、スループット設定、および Auto Scaling の制限と関連設定を再確立しなければなりません。

DynamoDB は、オンデマンドバックアップと復元もサポートするため、データをスケジュールに従って、または必要に応じて個別に保護することができます。テーブルに対するパフォーマンス面での影響はなく、バックアッププロセスは数秒で完了します。バックアップはカタログ化され、取得用に保存されます。これらのバックアップはテーブルのステータスに関係なく維持されるため、不注意による削除からもテーブルを保護します。

10.リージョン的な回復性

アプリケーションの複数の AWS リージョンにまたがったデプロイメント、または世界的な規模でのデプロイメントには、グローバルテーブルの使用を検討する必要があります。グローバルテーブルは、マルチマスターレプリケーションを使って DynamoDB テーブルをサポートされているリージョン全体にグローバルにデプロイするために使用できます。グローバルテーブルのベストプラクティスに従うこと、および適切なキャパシティー管理のために Auto Scaling を有効化することが大切です。強一貫性読み込みは、結果整合性読み込みが利用できる唯一の読み込みタイプであるグローバルテーブル一群のうち、単一のリージョンでしか利用できないことに注意してください。

11.キャパシティーと支出の最適化

データの移行後は、DynamoDB の使用を最適化することが大切です。DynamoDB のキャパシティーと支出を最適化するためのヒントについて、以下の項目を検討してください。

先日、AWS は On-Demand キャパシティーモードと呼ばれる機能を発表しました。On-Demand を使用する場合、AWS が読み込み/書き込みキャパシティーを必要なスループットのピークと谷に合わせて調整することを許可し、初期キャパシティーと自動スケーリングモデルを作成して維持する必要はありません。ただし、アプリケーションに比較的安定したキャパシティーがある場合は、On-Demand でも運用コストが削減されない可能性があります。

DynamoDB の料金設定を理解することが大切です。

  • 運用中の料金は、プロビジョニングされたキャパシティーに基づいた 1 時間当たりの定額料金を支払い、On-Demand キャパシティーモードを使用するときはオンデマンド料金を支払います。
  • 読み込みキャパシティーユニットと書き込みキャパシティーユニットの料金はリージョンごとに設定されています。
  • 常に最小のキャパシティーを使用していることを確実にするためには、Auto Scaling を使用できます。
  • 結果整合性読み込みを使用できる場合は、同じレベルのキャパシティーでも、強一貫性読み込みより多くの結果整合性読み込みがサポートされるため、結果整合性読み込みを使用してください。
  • 複数のリージョンに DynamoDB テーブルをデプロイした場合は、リージョン間でのデータ転送コストを考慮してください。
  • リージョン間のデータ転送料金は、慎重に管理するようにしてください。
  • キャパシティーと支出の管理には、Amazon CloudWatch、AWS Cost Explorer、および AWS Budgets を使用してください。
  • DynamoDB のお客様として、リザーブドキャパシティーを事前に購入することができます。DynamoDB の書き込み/読み込みスループットに対するニーズを予測することができる場合、リザーブドキャパシティーは、DynamoDB のプロビジョンドスループットキャパシティーの通常料金と比べて大幅なコスト節約を提供します。(リザーブドキャパシティーは、プロビジョニングされたキャパシティーではなく、キャパシティーに対するリクエストの料金を支払っていることから、On-Demand キャパシティーには適用されないことに注意してください。)

大部分の AWS 最適化アクティビティと同様に、必要なパフォーマンスとストレージリソースのみに料金を支払っていることを確実にするため、DynamoDB の使用を監視して検討し直すことが大切です。

まとめ

この記事では、お使いのアプリケーションに対するデータベースサービスの候補として DynamoDB を評価する方法と、DynamoDB への移行を計画する方法について説明しました。このブログ記事に関するご質問またはコメントは、以下のコメントセクションからお送りください。

著者について

Lex Crosett の写真Lex Crosett はボストンを拠点とする AWS エンタープライズソリューションアーキテクトです。