Amazon DynamoDB を使ったマルチリージョン戦略: Part 1

アプリケーションを複数の離れた地域で動作させることになった場合、たくさんの課題を解決する必要があります。まず、何がビジネスの成長につながるか？レジリエンシーは？ (障害復旧ができるか？) 可用性や災害対策などの耐障害性に関するアプリケーションの要件については、単一の AWS リージョンを使うことで満たすことができるかもしれません。もし、マルチリージョンのソリューションが必要となった場合は、次のような課題の解決方法を考える必要があります。

• 複数リージョン間で重要なデータを同期し、かつ、一貫性を担保する方法
• データ量とユーザートラフィックが増加しても、アプリケーションのスケーラビリティ、信頼性、パフォーマンスを維持する方法
• 障害が発生してもなグレード (例えば可用性) を落とさずに動作しつづける方法
• オペレーションオーバーヘッドを最小限に抑えて課題管理に対処する方法

マルチリージョン戦略の導入は骨の折れる作業であり、最大の課題はデータの取り扱いに関するものです。このブログでは、まず最初にマルチリージョン戦略の構築に取り掛かる方法、つまり戦略の不可欠な部分としてレジリエンシーに重点を置いて、どこに着目してその戦略を進めていくかについて説明します。次に、 Amazon Web Services (AWS) の複数リージョンを使用した、耐障害性の高いマルチリージョンアプリケーションを構築する方法について説明します。最後に、Amazon DynamoDB とその検証済みのマルチリージョンデータレプリケーション機能を使用して、これらの課題を解決する方法について説明します。データアーキテクチャを単一のリージョンから複数のリージョンに進化させるための段階的な手法を紹介します。

このブログシリーズでは、DynamoDB を初めて使用する方も、すでに DynamoDB ベースのアプリケーションを実行している方も、ビジネスニーズが 1 つの地域や AWS リージョンを超えて拡大するにつれて、大きな視野で考えつつも、小規模で始めることができ、また、自身のペースでスケーリングできるようにするためのガイドとなるでしょう。

マルチリージョン展開のためのビジネス要件

マルチリージョンの導入に着手する前に、アプリケーションとデータベースを複数のリージョンで運用するためのビジネス要件を慎重に検討する必要があります。AWS のお客様からよく聞かれる理由は次のとおりです。

• レジリエンシー (高可用性と災害復旧) — 自然災害、ハードウェア障害、ソフトウェアのバグ、人為的ミスにより、事業運営に支障をきたし、ビジネスに悪影響を及ぼす可能性があります。障害が発生してもビジネスを継続するには、災害復旧ソリューションを導入する必要があります。このソリューションは、販売機会の損失、法的影響、ブランドへの悪影響、顧客の信頼損失からビジネスを守ります。また、1 つのリージョン内で達成できる 99.99% (フォーナイン) よりも高い可用性が必要な場合もあります。99.999% (ファイブナイン) の可用性が必要な場合、少なくとも 2 つのリージョンを使用する必要があります。
• 地理的拡大 — 会社・組織が新しい地域、国、さらには大陸への進出して、事業の拡大を決定した場合、サービスの応答時間を短縮し、優れたカスタマーエクスペリエンスを提供するために、アプリケーションをユーザーのいる場所の近くで稼働させる必要があります。

AWS のお客様は、多くの場合、レジリエンシーを第一に優先し、その後、サービス地域の拡大を進めます。もし、ビジネスの優先度がサービス地域の拡大であったとしても、レジリエンシーは考慮する必要があります。

ベストプラクティスとして、マルチリージョン戦略はレジリエンシー戦略を含む必要があります。より広い視点で見たとしても、ビジネスにとって重要なすべてのアプリケーションを構築する際には、セキュリティと同様に、耐障害性を基本的には考える必要があります。

AWS でアプリケーションを構築する際の耐障害性に関する包括的なレビューについては、「信頼性の柱 — AWS Well-Architected フレームワークとAWSでのワークロードのディザスタリカバリ:クラウドでのリカバリ」を参照してください。
ビジネスの推進させることに加えて、データの他のリージョンへの複製に影響する可能性のあるコンプライアンス要件も考慮する必要があります。たとえば、セキュリティ上の懸念や政府からのデータ要求に対する懸念から、国やより広範な組織など、地政学的または法的に許される場所の内にデータを保管することに重点を置くこともあります。その一例が、欧州連合における個人データの保護とプライバシーに関する欧州連合の一般データ保護規則 (GDPR) です。

ビジネスの要件が決まったら、ビジネスチームと IT チームの両方と協力して、ビジネスにとって重要なアプリケーションを特定して分析できます。たとえば、取引後の市場分析やチャットボットよりも、顧客向けのアプリケーションの方が重要だとわかるかもしれません。場合によっては、アプリケーション内でトレードオフの決定を行う必要がある場合もあります。たとえば、電子商取引システムでは、クリックストリームの処理よりも購入取引の処理能力を優先する必要があります。

重要なのは、最も重要なビジネス機能から始めて、ユーザーに価値をもたらすすべてのステップを見直し、各機能の依存関係ツリーを把握することです。依存関係ツリーは、その機能を実行するために必要なすべてのアプリケーション、サービス、およびデータベースで構成されているはずです。次に、各ステップで障害があった場合のビジネスに与える影響を考える必要があります。そのため、各ステップで、システムダウンタイム (復旧時間目標 (RTO) とデータ損失 – 復旧ポイント目標 (RPO) の可用性目標と災害復旧目標を定義する必要があります。これらの目標は、各障害の重要度と潜在的な影響の度合いに基づいて定義されます。アプリケーションは、中断が発生した場合のビジネスへの潜在的な影響度合いに基づいて、階層別にグループ化されます。各階層 (Tier) には RPO、RTO、可用性指標が定義されており、Tier 1のアプリケーションが最も重要なものとして最初に着手すべきものです。たとえば、ある組織ではアプリケーションを次のように分類することがあるでしょう。

• Tier 1 — 2 時間の RTO、30 秒の RPO、99.999% の可用性
• Tier 2 — 8 時間の RTO、4 時間の RPO、99.9% の可用性
• Tier 3 — 24 時間の RTO、24 時間の RPO、98% の可用性
• Tier 4 — 48 時間の RTO、48 時間の RPO、95% の可用性

この例では、Tier 1 アプリケーションとは、注文処理や顧客関係管理など、この組織の運営に不可欠と考えられるアプリケーションです。一部の Tier 1 アプリケーションの中断は、ビジネスパートナーやその他の企業にも影響を与える可能性があります。

アプリケーションとサービスの分析と優先順位付けに使用できる手法はいくつかあります。役に立つと思われる手法の 1 つに、故障モードおよび影響分析 (FMEA) と呼ばれるものがあります。FMEAは国際標準化機構 (ISO) のエンジニアリング手法で、重大度、確率、検出可能性に基づいてリスクを把握し、優先順位を付け、それぞれ 1 ～ 10 のスケールで評価します。これら3つのディメンションを掛けて、1 ～ 1,000 のリスク優先度 (RPN) を推定します。確率がきわめて低く、重症度が低く、検出しやすいリスクの RPN は 1 です。きわめて頻繁に発生し、恒久的に損害を与え、検出が不可能なリスクの RPN は 1,000 です。例として、「AWS でのミッションクリティカルな金融サービスアプリケーションの構築」の付録Fを参照してください。

AWS におけるレジリエンシーとマルチリージョン戦略

レジリエンシー戦略では、コストとビジネスリスクに最も大きな影響を与えるアプリケーションとサービスを優先する必要があります。たとえば、Tier 1のアプリケーションでは、ファイブ・ナイン (99.999) の可用性要件を満たすマルチリージョン・ソリューションが必要になります。アプリケーションの RTO と RPO によって、バックアップとリストア、パイロットライト、ウォームスタンバイ、アクティブ/アクティブ (図 1 参照) のどのディザスタリカバリのアプローチを選択すべきかが決まります。

図 1 : 最も優先順位の低いものからミッションクリティカルなものまでの災害復旧アプローチ

図の左端、アクティブ/パッシブのバックアップとリストア戦略は最もシンプルでコストは最小ですが、RTO とRPO が最も高くなります。一方で右端の、アクティブ/アクティブ戦略は、RTO と RPO が最も低くなりますが、コストと複雑さが最も高くなります。詳細については、「クラウドの障害復旧オプション」を参照してください。

進化的アプローチ: 単一リージョンからマルチリージョンへ

はじめに、先ほど特定したビジネスクリティカルなアプリケーションを 1 つ思い出してください。マルチリージョン戦略は、ビジネスの目標や目的と密接に関連していることでしょう。私たちの経験では、単一のリージョンから複数のリージョンへの進化を説明するロードマップを作成すると役に立ちます。規模を拡大する前に、まず小規模から始めて、どの分野を改善する必要があるかを判断する方がよいでしょう。

たとえば、あなたの最終目標がアクティブ/アクティブなマルチリージョン戦略を実施することだとしましょう。アプリケーション全体に取り組むのではなく、特定のユースケース (アーキテクチャの垂直部分) を取り上げて、アクティブ/パッシブのパイロットライト戦略の要件を徐々に実装することもできます。その後、学んだノウハウと自動化したプロセスを基に、ウォームスタンバイ戦略のより複雑な要件を実装できます。その時点から、繰り返し、測定、学習、自動化を続けることができます。自動化された設計パターンとベストプラクティスの強固な経験値があれば、最も複雑なアーキテクチャであるマルチサイトアクティブ/アクティブ戦略の要件の実装を進めることができます。

このアプローチでは、小さな実験を一度に 1 回繰り返して目に見える成果をすばやく生み出すことで、最終目標に向かって進むことができます。これらの各実験では、AWS Well-Architected Framework を使用して、信頼性が高く、安全で、効率的で、費用対効果の高いアプリケーションを AWS で設計および運用するためのベストプラクティスとコア戦略を繰り返し実装することをお勧めします。このフレームワークは、AWS がさまざまな業種やユースケースにわたって何千ものソリューションを設計してきた長年の経験に基づいています。

AWS のグローバルインフラストラクチャのおかげで、実験のたびに費用対効果の高い方法で段階的に構築、測定、学習できます。ビジネスのニーズに合わせて即座にスケールアップまたはスケールダウンできることがわかっているので、必要なリソースだけをプロビジョニングできます。これにより、コストが削減され、ユーザーの要求を満たす機能が向上します。

この記事の執筆時点で、AWSは世界中の 31 の地理的リージョン内の 99 のアベイラビリティーゾーンにまたがるグローバルネットワークを持ち、カナダ、イスラエル、ニュージーランド、タイにさらに 12 のアベイラビリティーゾーンと 4 つの AWS リージョンを開設する計画も発表されています。

なぜ DynamoDB なのか？

DynamoDB はフルマネージド型のサーバーレスデータベースで、どのような規模でも低レイテンシーを実現し、リアルタイムで容量を柔軟に管理できます。さまざまな業界の数十万のAWSのお客様が、ミッションクリティカルなアプリケーションやその他のアプリケーションに DynamoDB を選択しています。金融サービス、コマース、アドテック、モノのインターネット (IoT)、ゲームアプリケーション (いくつか例を挙げると) は、DynamoDB を利用して何兆ものアイテムを保存し、1 桁のミリ秒単位で結果を返し、世界中の何百万ものユーザーやスマートデバイスからの 1 秒間に数百万のリクエストを管理しています。

たとえば、DynamoDB は、Alexa、Amazon.com サイト、すべての Amazon フルフィルメントセンターを含む、トラフィックの多い複数の Amazon プロパティとシステムを支えています。2022 年の Amazon プライムデーの期間中、これらのシステムは DynamoDB API に対して何兆回もの呼び出しを行い、ピーク時には 1 秒あたり 1 億 520 万リクエストに達しました。一方、DynamoDB は高い可用性を維持し、1 桁のミリ秒の応答を返しました。DynamoDB を使用すると、このような規模のアプリケーションを最小限の労力で構築できます。

経験豊富なデータベースプロフェッショナルは、本番用データベースの容量を拡張するのが面倒であることを知っています。アプリケーションのパフォーマンスに影響し、ダウンタイムが発生する可能性もあります。さらに、基盤となるデータベーステクノロジーによっては、スケーリングに数時間または数日かかる場合があります。DynamoDB では、テーブルの容量をその場で変更できます。アプリケーショントラフィックパターンに基づいて容量を簡単に増減できます。さらに、グローバルテーブルのクロスリージョンレプリケーション機能はサービスに組み込まれており、フルマネージドなサービスとなっています。1 つのリージョンから始めて、DynamoDB の機能を詳しく見ていきましょう。

DynamoDB を初めて使用する場合、1 つのリージョンに DynamoDB テーブルを作成することから始めるのが一番です。AWS のドキュメントには、DynamoDB ベースのアプリケーションの開発に役立ついくつかの例とチュートリアルが記載されています。DynamoDB を単一のリージョンで使用すると、次のようなメリットがあります。

• パフォーマンスとスケーラビリティ — DynamoDBは 1 日あたり 10 兆件を超えるリクエストを処理でき、最小限のデータベース管理で 1 秒あたり 2,000 万件を超えるリクエストのピークをサポートできます。テーブルのキャパシティモードで定義されている応答時間にはほとんど変化がなく、期待どおりに動作します。DynamoDB には、テーブルの読み取りと書き込みを処理するための 2 つのキャパシティモードがあります。
  • プロビジョニングモード — プロビジョニングモードでは、アプリケーションで必要になると予想される 1 秒あたりの読み取りと書き込みの回数を指定します。プロビジョニングモードは、指定したプロビジョニングされた容量を適切に使用できると確信できる場合に、費用対効果が高くなります。また、Auto Scaling を使用して、トラフィックの変化に応じてテーブルのプロビジョニング容量を自動的に調整することもできます。これにより、コストを予測しやすくするために、定義したリクエストレート以下を維持できます。
  • オンデマンドモード — オンデマンドモードでは、DynamoDB がお客様に代わってキャパシティを管理します。アプリケーションで実行されると予想される読み取りと書き込みのスループットを指定する必要はありません。アプリケーションが増えたり下がったりしても、即座に対応できます。オンデマンドモードは、予測が難しいアプリケーションや、使用率が高いかどうか確信が持てない場合に最適です。支払いは実際に使用した分だけです。
• 高い可用性と耐久性 — DynamoDB は耐障害性を念頭に置いて設計されています。単一リージョン内で 99.99% の稼働率を誇るサービスレベル契約 (SLA) により、高い可用性と耐久性を実現します。DynamoDB 内のデータはソリッドステートディスク (SSD) に確実に保存され、リージョン内のつのアベイラビリティーゾーンに自動的に複製されます。また、DynamoDB は、高速なパフォーマンスと一貫性を維持しながら、スループットとストレージの要件を満たすのに十分な数のサーバーにテーブルのデータとトラフィックを自動的に分散します。一貫性について言えば、DynamoDB は読み取り整合性の 3 つのモデルをサポートしています。結果整合性、強力な整合性、トランザクション整合性です。
• バックアップと復元 — データの耐障害性とバックアップのニーズに対応するため、DynamoDB では 2 種類のフルマネージドバックアップを提供しています。
  • オンデマンドバックアップ — オンデマンドバックアップを使用してテーブルのフルバックアップを作成して、長期間のデータアーカイブとコンプライアンスを実現できます。これらのバックアップは、明示的に削除されるまで保持されます。テーブルのサイズに関係なく、バックアップは数秒で完了します。テーブルのパフォーマンスや可用性に影響を与えることなく、AWS マネジメントコンソールまたはAWS API からいつでもテーブルデータをバックアップおよび復元できます。必要に応じて、DynamoDB と AWS Backup の統合 (「AWS Backup と DynamoDB の使用」を参照) を使用して、テーブルのスケジュールと保持ポリシーを含むバックアッププランを作成できます。さらに、クロスアカウントコピーやクロスリージョンコピーも可能です。
  • ポイントインタイムリカバリ — ポイントインタイムリカバリは、アプリケーションエラーによる誤った書き込みや削除操作からデータを保護します。DynamoDB はテーブルの増分バックアップを管理するので、オンデマンドバックアップの作成、管理、スケジュールについて心配する必要はありません。過去 35 日以内の任意の時点までデータを復元できます。誤って書き込んだり削除したりした場合でも、アイテムキーを特定してテーブルを前回正常終了時点に復元し、復元されたテーブルから正しいデータを選択してプロダクションテーブルに書き込むことで、元のデータを復元できます。
• セキュリティとコンプライアンス — AWS 責任共有モデルで説明されているように、セキュリティは AWS とお客様の組織間で責任を共有しています。DynamoDB は、保存中のユーザーデータ、クライアントと DynamoDB 間、およびDynamoDBと同じリージョンにある他の AWS リソース間で転送中のデータを保護します。また、DynamoDB リソースの使用権を誰が認証し許可できるか、会社側で完全に制御できます。DynamoDB を使用する際のコンプライアンス責任は、データの機密性、組織のコンプライアンス目標、適用される法律や規制によって決まります。AWSは、システムおよび組織管理 (SOC) 、ペイメントカード業界 (PCI) 、連邦リスクおよび承認管理プログラム (FedRAMP) 、医療保険の相互運用性と説明責任に関する法律 (HIPAA) など、複数の AWS コンプライアンスプログラムの一環として、サードパーティの監査人と協力して DynamoDB のコンプライアンスを評価しています。特定のコンプライアンスプログラムの対象に含まれる AWS サービスの最新リストについては、「コンプライアンスプログラムによる AWS 対象範囲内のサービス」を参照してください。セキュリティとコンプライアンスの目標を満たすように DynamoDB を設定する方法の詳細については、「Amazon DynamoDB のセキュリティとコンプライアンス」を参照してください。

マルチリージョン DynamoDB: グローバルテーブル

DynamoDB は AWS グローバルバックボーンを使用して、グローバルテーブルと呼ばれる機能を通じて、フルマネージド、マルチリージョン、マルチアクティブデータレプリケーションを提供します。グローバルテーブルは、以下の図 2 に示すように、リージョンごとに 1 つずつ、複数のレプリカテーブルで構成されます。すべてのレプリカには同じテーブル名と同じプライマリキーがあります。グローバルテーブルは、コンソール、AWS コマンドラインインターフェイス (AWS CLI) 、または AWS SDK を使用して作成できます。現在のバージョンのグローバルテーブルバージョン 2019.11.21 では、単一リージョンのテーブルをグローバルテーブルに変換できます。

図 2 : 3 つのリージョンに複製された1つのグローバルテーブル

単一リージョン DynamoDB テーブルの利点に加えて、グローバルテーブルには次のような独自の利点があります。

• ローカルでの読み取りと書き込みによるグローバルデータアクセス — グローバルテーブルを使用すると、任意のリージョンからデータを読み込んだり、任意のリージョンにデータを書き込んだりできます。DynamoDBは、通常は 1 秒以内にデータを他のリージョンに非同期で複製します。データ複製はアプリケーション書き込みのパフォーマンスに影響しません。グローバルテーブルでは、各レプリカテーブルに同じデータ項目セットが格納され、最終的にはすべてのリージョンでデータの整合性が保たれます。アプリケーションは同じリージョンでは強い整合性のある読み取りを実行できますが、データレプリケーションの非同期性により、グローバルテーブルの他のリージョンからレプリケートされたデータは、結果整合性の読み取りとなります。トランザクション操作で ACID が保証されるのは、書き込みが行われたリージョンだけです。
• レジリエンシー — グローバルテーブルは 99.999% のアップタイムSLA を提供しており、マルチリージョンのレジリエンシーを備えた災害に強いソリューションを構築できます。アプリケーションにカスタムロジックを実装して、グローバルテーブルのリージョンが分離されたり、デグレードしたときにそれを検出して、読み取りと書き込みを別のリージョンにリダイレクトできます。さらに、DynamoDB は、実行されたがまだ他のリージョンに伝達されていない書き込みをすべて追跡します。何らかの理由で通信が中断された場合、DynamoDB はリージョンがオンラインに戻ったときに保留中の書き込みをすべて伝達します。
• コンフリクトの解決 — グローバルテーブル内の同じアイテムへの書き込みが2つの異なるリージョンで同時に行われると、書き込みコンフリクトが発生する可能性があります。データの一貫性を確保するために、DynamoDB グローバルテーブルは最終書き込み優先の競合解決メカニズムを採用しています。これにより、すべてのレプリカテーブルが最新の更新内容に統一され、すべてのレプリカテーブルが同じデータを持つ状態に収束します。
• 運用効率 — グローバルテーブルにより、データの複製という難しい作業が不要になるため、アプリケーションのビジネスロジックに集中できます。Amazon CloudWatch を使用して DynamoDB をモニタリングし (DynamoDB のメトリックスとディメンションを参照) 、 ReplicationLatency メトリックスを使用してグローバルテーブルのレプリケーション遅延量を追跡できます。ReplicationLatency は ミリ 秒単位で表され、ソース・リージョン/デスティネーション・リージョンのペアごとに出力されます。

コストの観点からは、読み込み容量とストレージについては通常の DynamoDB 料金と、クロスリージョンレプリケーションのデータ転送料金をお支払いいただきます。書き込み容量は、複製された書き込み容量単位で請求されます。詳細については、Amazon DynamoDB の料金表を参照してください。

まとめ

DynamoDB を使ったマルチリージョン戦略に関するブログシリーズの第1回目では、マルチリージョン戦略の構築方法について説明しました。まず、ビジネスドライバーの特定、アプリケーションとサービスの優先順位付け、レジリエンシー目標の定義から始めることを紹介しました。優れたマルチリージョン戦略の不可欠な部分としてのレジリエンシーの重要性を強調し、AWS での災害復旧アプローチを取り上げました。最後に、マルチアクティブ、マルチリージョンの機能を提供するフルマネージド型のサーバーレスデータベースサービスとして DynamoDB を紹介し、シングルリージョンとマルチリージョンの両方のコンテキストでの機能について説明しました。

本シリーズの次回の記事では、DynamoDB を使用するマルチリージョン戦略とユースケースに焦点を当てます。

著者について

Edin Zulich は AWS のデータベースソリューションアーキテクトチームを率いています。あらゆる業界の多くのお客様が、困難なデータ管理の問題に対するスケーラブルで費用対効果の高いソリューションを設計できるよう支援してきました。Edin は 2016 年に AWS に入社し、2005 年から分散データ技術に携わってきました。

Guillermo Tantachuco は AWS のプリンシパルソリューションアーキテクトで、アプリケーションやデータアーキテクチャ、DevOps、多層防御、耐障害性など、ソフトウェア配信やインターネット規模のシステムのあらゆる面で金融サービスのお客様を支援しています。2011 年以来、フォーチュン 500 およびグローバル企業でクラウドネイティブおよびデジタル変革イニシアチブの実施を主導してきました。彼は家族、ビジネス、テクノロジー、サッカーに情熱を注いでいます。

この記事は 2023/02/02 に Edin Zulich, Guillermo Tantachuco によって書かれた Accelerate your multi-region strategy with Amazon DynamoDB: Part 1 を翻訳した記事です。この記事はソリューションアーキテクトの池尾 誠哉が翻訳しました。