このドキュメントでは、マルチクラウド データベース管理用のデプロイ アーキテクチャ、ユースケース、ベスト プラクティスについて説明します。これは、複数のクラウド内とクラウド間でステートフル アプリケーションを設計、実装するアーキテクトとエンジニアを対象としています。
データベースにアクセスするマルチクラウド アプリケーションのアーキテクチャは、ユースケースによって異なります。すべてのマルチクラウドのユースケースをサポートできる単一のステートフル アプリケーション アーキテクチャはありません。たとえば、クラウド バースト機能のユースケースに最適なデータベース ソリューションは、複数のクラウド環境で同時に実行されるアプリケーションに最適なデータベース ソリューションとは異なります。
Google Cloud などのパブリック クラウドの場合は、特定のマルチクラウド ユースケースに適したさまざまなデータベース テクノロジーがあります。単一のパブリック クラウド内の複数のリージョンにアプリケーションをデプロイする方法の一つに、Spanner などのパブリック クラウドのプロバイダが管理するマルチリージョン データベースを使用するというものがあります。アプリケーションをパブリック クラウド間で移植できるようにデプロイするには、PostgreSQL などのプラットフォームに依存しないデータベースをおすすめします。
このドキュメントでは、ステートフル データベース アプリケーションの定義を紹介し、引き続きマルチクラウド データベースのユースケース分析を紹介します。次に、ユースケースに基づいて、マルチクラウド デプロイ アーキテクチャ用の詳細なデータベース システムの分類を紹介します。
また、このドキュメントでは、適切なデータベース テクノロジー選択のための重要な決定事項を概説するデータベース選択のためのディシジョン ツリーも紹介します。マルチクラウド データベース管理のベスト プラクティスに関する説明で締めくくります。
主な用語と定義
このセクションでは、このドキュメントで使用する、一般的なステートフル データベース アプリケーションの用語と定義を提示します。
用語
- パブリック クラウド。パブリック クラウドには、お客様が本番環境ワークロードを実行するために使用できるマルチテナント インフラストラクチャ（通常はグローバル）とサービスが用意されています。Google Cloud は、GKE、GKE Enterprise、マネージド データベースなどの多くのマネージド サービスを備えたパブリック クラウドです。
- ハイブリッド クラウド。ハイブリッド クラウドは、パブリック クラウドと 1 つ以上のオンプレミス データセンターを組み合わせたものです。ハイブリッド クラウドのお客様は、パブリック クラウドによって提供される追加サービスとオンプレミス サービスを組み合わせることができます。
- マルチクラウド。マルチクラウドは、複数のパブリック クラウドとオンプレミス データセンターを組み合わせたものです。ハイブリッド クラウドはマルチクラウドの一種です。
- デプロイの場所。インフラストラクチャの場所は、アプリケーションとデータベースを含むワークロードをデプロイして実行できる物理的な場所です。たとえば、Google Cloud ではデプロイの場所はゾーンとリージョンです。抽象レベルでは、パブリック クラウドのリージョンまたはゾーンとオンプレミスのデータセンターがデプロイの場所です。
ステートフル データベース アプリケーション
マルチクラウドのユースケースを定義するために、このドキュメントでは、次の図に示すように、汎用のステートフル データベース アプリケーション アーキテクチャを使用しています。
この図は次のコンポーネントを示しています。
- データベース。データベースは、単一インスタンス、複数インスタンス、または分散データベースで、コンピューティング ノードにデプロイされるか、クラウド マネージド サービスとして使用できます。
- アプリケーション サービス。これらのサービスを組み合わせて、ビジネス ロジックが実装されます。アプリケーション サービスは次のいずれかです。
- Kubernetes のマイクロサービス。
- 1 つ以上の仮想マシンで実行される粗粒度のプロセス。
- 1 つの大規模仮想マシン上のモノリシック アプリケーション。
- Cloud Run 関数または Cloud Run のサーバーレス コード。一部のアプリケーション サービスはデータベースにアクセスできます。それぞれのアプリケーション サービスを複数回デプロイできます。アプリケーション サービスの各デプロイは、そのアプリケーション サービスのインスタンスです。
- アプリケーション クライアント。アプリケーション クライアントは、アプリケーション サービスによって提供される機能にアクセスします。アプリケーション クライアントは次のいずれかです。
- デプロイされたクライアント。コードはマシン、ノートパソコン、またはスマートフォン上で実行されます。
- デプロイされていないクライアント。クライアント コードはブラウザで実行されます。アプリケーション クライアント インスタンスは、常に 1 つ以上のアプリケーション サービス インスタンスにアクセスします。
マルチクラウド データベースを説明するコンテキストでは、ステートフル アプリケーションのアーキテクチャを抽象化して、データベース、アプリケーション サービス、アプリケーション クライアントという要素を使って表現します。アプリケーションの実装においては、オペレーティング システムやプログラミング言語の使用といった要因が異なる可能性がありますが、これらの細部はマルチクラウド データベース管理には影響しません。
データ ストレージ サービスとしてのキューとファイル
アプリケーション サービスのデータを永続化するための永続リソースは数多く存在します。たとえば、データベース、キュー、ファイルなどです。各永続リソースは、ストレージ データモデルとそれらのモデル固有のアクセス パターンを提供します。アプリケーションではキュー、メッセージング システム、ファイル システムが使用されますが、次のセクションでは特にデータベースに焦点を当てます。
デプロイの場所、状態の共有、マルチクラウド データベースの同期レプリケーションと非同期レプリケーションなどの要素については、キューとファイルにも同じ考慮事項が適用されますが、このドキュメントでは説明しません。
ネットワーキング
汎用のステートフル アプリケーション（次の図にもう一度示しています）のアーキテクチャでは、コンポーネント間の各矢印はネットワーク接続（たとえば、アプリケーション サービスにアクセスするアプリケーション クライアント）の通信関係を表します。
接続はゾーン内、ゾーン間、リージョン間、クラウド間でも行えます。デプロイのロケーション間を任意の組み合わせで接続できます。マルチクラウド環境では、クラウド間のネットワーキングは重要な考慮事項であり、使用できるオプションがいくつかあります。クラウド間のネットワーキングの詳細については、Google Cloud への接続: お客様のネットワーク オプションの説明をご覧ください。
このドキュメントのユースケースでは、次のことを前提としています。
- クラウド間に安全なネットワーク接続が存在する。
- データベースとそれらのコンポーネントは相互に通信できる。
機能面以外の観点では、ネットワークのサイズ、つまりスループットとレイテンシは、データベースのレイテンシとスループットに影響する可能性があります。機能の観点からは、ネットワーキングは通常、影響を与えません。
マルチクラウド データベースのユースケース
このセクションでは、マルチクラウド データベース管理の一般的なユースケースを示します。これらのユースケースでは、クラウドとデータベース ノードの間に安全なネットワーク接続があることを前提としています。
アプリケーションの移行
マルチクラウド データベース管理のコンテキストにおけるアプリケーション移行とは、アプリケーション、すべてのアプリケーション サービス、データベースを現在のクラウドからターゲット クラウドへ移行することを指します。企業がアプリケーションの移行を決定する理由として、クラウド プロバイダと競合する状態を回避する、テクノロジーをモダナイズする、総所有コスト（TCO）を削減するなどがあります。
アプリケーションの移行では、現行のクラウドで本番環境を停止し、移行が完了した後に移行先のクラウドで本番環境を続行します。アプリケーション サービスは、移行先のクラウドで実行する必要があります。サービスを実装するには、リフト＆シフト方式を使用できます。このアプローチでは、同じコードが移行先のクラウドにデプロイされます。サービスを再実装するために、移行先のクラウドで使用できる最新のクラウド テクノロジーを使用できます。
データベースの観点から、アプリケーションの移行に関して次の代替選択肢を検討してください。
- データベースのリフト&シフト: ターゲット クラウドで同じデータベース エンジンが使用可能な場合は、データベースをリフト&シフトして、ターゲット クラウドに同じデプロイを作成できます。
- データベースのリフトと同等の同等のマネージド サービスへの移行: ターゲット クラウドで提供される場合、セルフマネージド データベースは、同じデータベース エンジンのマネージド バージョンに移行できます。
- データベースのモダナイゼーション: 用意されているデータベース テクノロジーはクラウドごとに異なります。クラウド プロバイダが管理するデータベースには、より厳格なサービスレベル契約（SLA）、スケーラビリティ、自動障害復旧などの利点がある場合が考えられます。
デプロイ戦略に関係なく、データベースの移行は、現行のクラウドから移行先のクラウドにデータを移動させる必要があるため、時間がかかるプロセスです。ダウンタイムが発生するエクスポートとインポートのアプローチを採用することは可能ですが、移行時のダウンタイムを最小限またはゼロにすることをおすすめします。このアプローチは、アプリケーションのダウンタイムをできる限り少なくして、企業とその顧客への影響を最小限に抑えます。ただし、このアプローチでは、初期の読み込み、進行中のレプリケーション、モニタリング、きめ細かい検証、切り替え時の同期が関係することから、より複雑な移行設定が必要になります。フォールバック シナリオをサポートするには、ターゲット データベースに切り替えた後で、そこでの変更内容にソース データベースが同期するように逆レプリケーション メカニズムを実装する必要があります。
障害復旧
障害復旧とは、リージョンで停止が発生してもアプリケーション クライアントへのサービスを提供し続けることです。障害復旧を確実に行うには、アプリケーションを 2 つ以上のリージョンにデプロイし、いつでも実行できる状態にしておく必要があります。本番環境では、アプリケーションはプライマリ リージョンで実行されます。ただし、アプリケーションの停止が発生した場合、セカンダリ リージョンがプライマリ リージョンになります。以下は、障害復旧への即応能力モデルを示します。
- ホット スタンバイ。アプリケーションは複数のリージョン（プライマリとセカンダリ）にデプロイされ、すべてのリージョンでアプリケーションが完全に機能します。プライマリ リージョンに障害が発生した場合は、セカンダリ リージョンのアプリケーションが即座にアプリケーション クライアントのトラフィックを引き継ぎます。
- コールド スタンバイ。アプリケーションはプライマリ リージョンで実行されていますが、セカンダリ リージョンで起動可能な状態になっています（ただし、実行はされていません）。プライマリ リージョンに障害が発生した場合は、セカンダリ リージョンでアプリケーションが起動されます。アプリケーションの停止は、アプリケーションが実行可能となり、すべてのアプリケーション サービスをアプリケーション クライアントに提供できるまで行われます。
- スタンバイなし。このモデルでは、アプリケーション コードをセカンダリ リージョンにデプロイする準備はできていますが、まだデプロイされていません（つまり、デプロイされたリソースも使用していません）。プライマリ リージョンでアプリケーションが停止した場合、まず、セカンダリ リージョンでアプリケーションのデプロイを行う必要があります。このデプロイでは、アプリケーションはコールド スタンバイと同じ状態になります。つまり、起動する必要があります。このアプローチでは、クラウド リソースの作成を含むアプリケーションのデプロイを最初に行う必要があるため、コールド スタンバイの場合よりもアプリケーションの停止時間が長くなります。
上記のリストで説明した即応能力のあるモデルは、データベースの観点では次のデータベース アプローチに対応しています。
- トランザクション的に同期されたデータベース。このデータベースは、ホット スタンバイ モデルに相当します。プライマリ リージョン内のすべてのトランザクションが、同期的な調整でセカンダリ リージョンで commit されます。サービスの停止中にセカンダリ リージョンがプライマリ リージョンになった場合、データベースは整合性が保たれており、すぐに利用可能になります。このモデルでは、目標復旧時点（RPO）と目標復旧時間（RTO）はどちらもゼロです。
- 非同期で複製されるデータベース。このデータベースも、ホット スタンバイ モデルに相当します。プライマリ リージョンからセカンダリ リージョンへのデータベース レプリケーションは非同期であるため、プライマリ リージョンで障害が発生した場合、一部のトランザクションがセカンダリ リージョンに複製されない可能性があります。セカンダリ リージョンのデータベースは本番環境の負荷に対応する準備は整っていますが、最新のデータを持っていない場合があります。このため、復元不能なトランザクションが失われる可能性があります。このリスクのため、このアプローチでは RTO はゼロですが、RPO は 0 よりも大きくなります。
- アイドリング データベース。このデータベースはコールド スタンバイ モデルに相当します。このデータベースはデータなしで作成されます。プライマリ リージョンで障害が発生した場合、データをアイドル状態のデータベースに読み込む必要があります。そのためには、プライマリ リージョンで定期的にバックアップを作成し、セカンダリ リージョンに転送する必要があります。バックアップは、データベース エンジンのサポートに応じて、完全バックアップまたは増分バックアップになります。いずれの場合も、データベースは前回のバックアップに戻ります。アプリケーションの観点からは、プライマリ リージョンと比較して多くのトランザクションが失われる可能性があります。このアプローチは費用効率が高い可能性がありますが、データベースの状態が最新でないために最新の使用可能だったバックアップ以降のすべてのトランザクションが失われるというリスクによって価値が軽減されます。
- データベースなし。このモデルは、スタンバイなしの場合と同じです。セカンダリ リージョンにはデータベースがインストールされていません。プライマリ リージョンに障害が発生した場合は、データベースを作成する必要があります。作成が完了したデータベースは、アイドリング データベースの場合と同様に、アプリケーションで使用できるようにする前にデータとともに読み込む必要があります。
このドキュメントで説明する障害復旧アプローチは、プライマリ リージョンとセカンダリ リージョンの代わりに、プライマリ クラウドとセカンダリ クラウドを使用する場合にも適用されます。主な違いは、クラウド間にさまざまなネットワークが混在することにより、1 つのクラウド内部のリージョン間ネットワーク区間と比較して、クラウド間のレイテンシが増加する可能性があることです。異なるクラウド プロバイダのマネージド データベースの機能とデフォルト設定の違いによって、これ以外の差異が発生することもあります。
クラウド全体の障害は、リージョンの障害よりも発生する可能性が低くなります。 しかし、企業が 2 つのクラウドにアプリケーションをデプロイすることは有用です。このアプローチは、企業を障害から保護するのに役立ち、あるいはビジネスまたは業界の規制を満たすのに役立ちます。
障害復旧のもう 1 つの方法として、プライマリ リージョンとセカンダリ リージョン、プライマリ クラウドとセカンダリ クラウドを用意することがあります。このアプローチにより、企業は障害状況に対処するための最適な障害復旧プロセスを選択できます。アプリケーションの実行を可能にするには、停止の重大度に応じてセカンダリ リージョンまたはセカンダリ クラウドを使用します。
クラウド バースト機能
クラウド バースト機能とは、異なるデプロイ ロケーション間でアプリケーション クライアントのトラフィックのスケールアップを可能にする構成のことです。容量の需要が増え、スタンバイ ロケーションから追加の容量が提供されると、アプリケーションはバーストします。プライマリ ロケーションは通常のトラフィックをサポートしますが、スタンバイ ロケーションは、プライマリ ロケーションがサポートできる範囲を超えてアプリケーション クライアントのトラフィックが増加した場合に追加容量を提供できます。プライマリ ロケーションとスタンバイ ロケーションはどちらも、アプリケーション サービス インスタンスがデプロイされています。
クラウド バースト機能は、複数のクラウドにまたがって実装されています。ここで、1 つ目のクラウドがプライマリ クラウド、2 つ目のクラウドがスタンバイ クラウドです。ハイブリッド クラウドのコンテキストで、オンプレミス データセンターの限られた数のコンピューティング リソースをパブリック クラウドの弾力性のあるクラウド コンピューティング リソースで拡張するのに使用します。
データベース サポートでは、次のオプションが利用できます。
- プライマリ ロケーションへのデプロイ。このデプロイでは、データベースはプライマリ ロケーションにのみデプロイされ、スタンバイ ロケーションにはデプロイされません。アプリケーションがバーストすると、スタンバイ ロケーションのアプリケーションがプライマリ ロケーションのデータベースにアクセスします。
- プライマリ ロケーションとスタンバイ ロケーションのデプロイ。このデプロイは、プライマリ ロケーションとスタンバイ ロケーションの両方をサポートしています。データベース インスタンスは両方のロケーションにデプロイされます。バーストした場合、アプリケーション サービス インスタンスは、それぞれのロケーションにデプロイされたデータベースにアクセスします。クラウド内およびクラウド間の障害復旧と同様に、2 つのデータベースをトランザクション的に同期することも、非同期に同期することもできます。非同期の同期では遅延が発生する可能性があります。 更新がスタンバイ ロケーションで行われる場合、これらの更新をプライマリ ロケーションに伝播する必要があります。両方のロケーションで同時に更新が発生する可能性がある場合は、競合の解決を実装する必要があります。
クラウド バースト機能は、オンプレミスのデータセンターの容量を増やすために、ハイブリッド クラウドでよく使用されます。これは、データが国内に存在する必要がある場合に、パブリック クラウド間で使用できるアプローチでもあります。パブリック クラウドに属するリージョンが 1 つの国に 1 つのリージョンしかない場合、同じ国の別のパブリック クラウドのリージョンにバーストする可能性があります。このアプローチにより、パブリック クラウド リージョンのリージョン内でリソースの制約に対応しながら、データは確実に国内に保管されます。
クラス最高のクラウド サービスの使用
アプリケーションの中には、単一のクラウドでは利用できない、専用のクラウドのサービスと製品を必要とするものがあります。たとえば、アプリケーションで、あるクラウドでビジネスデータのビジネス ロジック処理を、別のクラウドでビジネスデータの分析を行う場合です。このユースケースでは、アプリケーションのビジネス ロジック処理部分と分析部分が異なるクラウドにデプロイされます。
データ管理の観点からは、このユースケースは次のとおりです。
- パーティション データ。アプリケーションの各部分には独自のデータベース（別々のパーティション）があり、どのデータベースも互いに直接接続されていません。データを管理するアプリケーションは、両方のデータベース（パーティション）で使用する必要があるすべてのデータを 2 回書き込みます。
- 非同期で複製されるデータベース。あるクラウドのデータを他のクラウドで使用する必要がある場合は、非同期のレプリケーション関係が適している可能性があります。たとえば、分析アプリケーションがビジネス アプリケーション用の同じデータセットまたはデータセットのサブセットを必要とする場合は、後者をクラウド間で複製できます。
- トランザクション的に同期されたデータベース。このようなデータベースでは、両方のアプリケーションでデータが利用可能になります。アプリケーションからの各更新はトランザクションとしての一貫性を持ち、両方のデータベース（パーティション）ですぐに使用できます。トランザクション的に同期されたデータベースは、事実上、単一の分散データベースとして機能します。
分散型サービス
分散サービスは、複数のデプロイ先ロケーションにデプロイされて実行されます。すべてのサービス インスタンスをすべてのデプロイ先ロケーションにデプロイできます。また、ハードウェアの可用性や予想される負荷の上限などの要因に基づいて、一部のサービスをすべてのロケーションにデプロイし、一部のサービスをいずれかのロケーションにのみデプロイすることもできます。
トランザクション的に同期されたデータベースのデータは、すべてのロケーションで整合しています。このため、すべてのデータベース ロケーションにサービス インスタンスをデプロイするには、このようなデータベースが最適なオプションです。
非同期でレプリケートされたデータベースを使用すると、同じデータ項目が 2 つのデプロイ ロケーションで同時に変更されるリスクがあります。2 つの競合する変更のうちどちらが最終的な整合状態なのかを判断するには、競合解決戦略を実装する必要があります。競合解決戦略を実装することは可能ですが、それがいつでも容易であるとは限りません。データを整合状態に戻すために、手動による介入が必要になることも考えられます。
分散型サービスの移動とフェイルオーバー
クラウド リージョン全体で障害が発生した場合は、障害復旧を開始します。ステートフル データベース アプリケーション内の単一のサービス（リージョンまたはアプリケーション全体ではない）に障害が発生した場合は、サービスを復元して再起動する必要があります。
障害復旧の最初のアプローチは、障害が発生したサービスを元のデプロイ ロケーションで再起動することです（原位置再起動アプローチ）。Kubernetes などのテクノロジーでは、構成に基づいてサービスが自動的に再起動します。
しかし、この原位置再起動アプローチが成功しない場合は、代わりにセカンダリ ロケーションでサービスを再起動します。サービスは、プライマリ ロケーションからセカンダリ ロケーションにフェイル オーバーします。アプリケーションが一連の分散サービスとしてデプロイされている場合は、単一のサービスのフェイルオーバーは動的に行うことができます。
データベースの観点からは、元のデプロイ ロケーションでのサービスの再起動には、特定のデータベースのデプロイは必要ありません。サービスが代わりのデプロイ ロケーションに移動し、データベースにアクセスすると、この文書で前に分散サービスで説明したものと同じ即応能力モデルが適用されます。
サービスの移動が一時的なもので、移動中に長いレイテンシを許容できる場合、サービスはデプロイ ロケーションを超えてデータベースにアクセスできます。サービスは再配置されますが、元のデプロイ ロケーションからアクセスするのと同じ方法でデータベースにアクセスします。
コンテキスト依存のデプロイ
通常、すべてのアプリケーション クライアントに対応する単一のアプリケーション デプロイには、そのアプリケーション サービスとデータベースがすべて含まれます。ただし、例外のユースケースもあります。1 つのアプリケーション デプロイが、特定の基準に基づいて、クライアントのサブセットのみにサービスを提供できます。つまり、複数のアプリケーションのデプロイが必要になります。各デプロイはクライアントのそれぞれのサブセットにサービスを提供し、すべてのデプロイがすべてのクライアントにサービスを提供します。
コンテキスト依存のデプロイのユースケースに関する例は次のとおりです。
- 1 つのアプリケーションがすべての小さなテナントにデプロイされるマルチテナント アプリケーションをデプロイする場合、別のアプリケーションは 10 個の中テナントごとにデプロイされ、1 つのアプリケーションはプレミアム テナントごとにデプロイされます。
- たとえば、企業顧客と政府機関顧客など、顧客を分離する必要がある場合。
- 開発環境、ステージング環境、本番環境を分離する必要がある場合。
データベースの観点からは、アプリケーションのデプロイごとに 1 対 1 のデプロイ戦略で 1 つのデータベースをデプロイできます。次の図に示すように、この戦略は単純なデプロイ方法です。各デプロイには独自のデータセットが存在するため、パーティション分割されたデータが作成されます。
上の図は、次のことを示しています。
- アプリケーションの 3 つのデプロイがある設定。
- 各データセットにはそれぞれ独自のデータベースがあります。
- データがデプロイ間で共有されることはありません。
多くの場合は 1 対 1 のデプロイが最適な戦略ですが、代わりのものもあります。
マルチテナントの場合、テナントを移動することがあります。小規模のテナントが中規模のテナントになり、別のアプリケーションに移動する必要が生じる場合があります。この場合、個々のデータベース デプロイでデータベースの移行が必要になります。分散データベースがデプロイされ、すべてのデプロイで同時に使用されている場合、すべてのテナントデータは単一のデータベース システムに格納されています。このため、データベース間でテナントを移動する際に、データベースを移行する必要はありません。次の図は、このようなデータベースの例を示しています。
上の図は、次のことを示しています。
- アプリケーションの 3 つのデプロイがあります。
- デプロイはすべて、単一の分散データベースを共有します。
- アプリケーションは各デプロイのすべてのデータにアクセスできます。
- データ パーティショニングは実装されていません。
ライフサイクル オペレーションの一環としてテナントを頻繁に移動する場合は、データベースのレプリケーションが有効な代替手段になることがあります。このアプローチでは、テナント移行前に、テナントデータがデータベース間で複製されます。この場合、アプリケーションのデプロイごとに独立したデータベースが使用され、テナント移行の直前と移行中にのみレプリケーションが行われます。次の図は、テナント移行中の 2 つのアプリケーション デプロイ間での一時的なレプリケーションを示しています。
上の図は、それぞれのデプロイに関連付けられたデータを保持する 3 つの別々のデータベースを持つアプリケーションの 3 つのデプロイを示しています。1 つのデータベースから別のものにデータを移行するために、一時的なデータベース移行を設定できます。
アプリケーションのポータビリティ
アプリケーションのポータビリティにより、アプリケーションを異なるデプロイ ロケーションに、特に異なるクラウドにデプロイできることを保証します。このポータビリティにより、移行専用の再設計や、アプリケーション移行の準備のための追加のアプリケーション開発を必要とせずに、いつでもアプリケーションを移行できることを保証します。
アプリケーションのポータビリティを確保するために、次のいずれかの方法を使用できます。これについては、このセクションで後述します。
- システムベースのポータビリティ
- API の互換性
- 機能ベースのポータビリティ
システムベースのポータビリティでは、すべての可能性のあるデプロイで使用されるものと同じ技術コンポーネントが使用されます。システムベースのポータビリティを保証するには、それぞれのテクノロジーがすべての可能性のあるデプロイ ロケーションで利用可能である必要があります。たとえば、PostgreSQL のようなデータベースが候補である場合は、すべての可能性のあるデプロイ ロケーションにおけるその可用性を、想定する時間枠で確認する必要があります。たとえば、プログラミング言語やインフラストラクチャ テクノロジーなど、他のすべてのテクノロジーについても同じく当てはまります。次の図に示すように、このアプローチではテクノロジーに基づいて、すべてのデプロイ ロケーション間に共通の一連の機能が確立されます。
上の図は、ポータブル アプリケーションのデプロイを示しています。アプリケーションは、デプロイされるすべてのロケーションに、まったく同じデータベース システムがあると想定しています。各ロケーションで同じデータベース システムが使用されているため、アプリを移植できます。アプリケーションは、デプロイ全体でまったく同じデータベース システムが使用されていると想定できます。したがって、まったく同じデータベース システム インターフェースと動作を使用できると想定できます。
データベースのコンテキストで、API 互換性システムでは、クライアントは特定のデータベース アクセス ライブラリ（たとえば、MySQL クライアント ライブラリ）を使用して、クラウド環境でのアプリ開発で利用可能な準拠した実装に接続できるようにします。次の図は、API の互換性を示しています。
上の図は、データベース システムではなくデータベース システムの API に基づくアプリケーションのポータビリティを示しています。データベース システムはロケーションごとに異なっていても API は同じで、公開する機能も同じです。基盤となるデータベース システムが別のデータベース テクノロジーであっても、各ロケーションで同じ API を使用できるため、アプリケーションは移植可能です。
機能ベースのポータビリティでは、同じ機能を提供するさまざまなテクノロジーをさまざまなクラウドで使用できます。たとえば、データベースの使用をリレーショナル モデルに制限できる場合があります。どのリレーショナル データベース システムでもアプリケーションをサポートできるため、アプリケーションのポータビリティに影響を与えることなく、さまざまなバージョンのさまざまなデータベース システムをさまざまなクラウドで使用できます。機能ベースのポータビリティの欠点は、データベース モデルで、すべてのリレーショナル データベース システムがサポートする部分のみを使用できることです。すべてのクラウドと互換性のあるデータベース システムではなく、データベース モデルを使用する必要があります。次の図は、機能ベースのポータビリティのアーキテクチャの例を示しています。
上の図に示すように、データベース システムの API とデータベース システムは各ロケーションで異なる場合があります。ポータビリティを保証するため、各ロケーションで使用可能な、各データベース システムと各 API の一部のみを使用する必要があります。各ロケーションでは各データベース システムのサブセットのみが一般に使用可能なため、アプリケーションは使用をそのサブセットに制限する必要があります。
このセクションのすべてのオプションに対してポータビリティを確保するには、すべてのターゲット ロケーションに完全なアーキテクチャを継続的にデプロイする必要があります。単体テストケースとシステムテスト ケースはすべて、これらのデプロイに対して実行する必要があります。これらは、インフラストラクチャとテクノロジーにおける変化を早期に検出して対処するための不可欠な要件です。
ベンダーへの依存の防止
ベンダーへの依存（ロックイン）の防止は、特定のテクノロジーやベンダーへの依存のリスクを軽減するのに役立ちます。これは一見、アプリケーションのポータビリティに似ています。ベンダーへの依存の防止は、クラウド サービスだけでなく、使用するすべてのテクノロジーに適用されます。たとえば、MySQL がデータベース システムとして使用され、クラウド内の仮想マシンにインストールされる場合、クラウドの観点では依存関係はありませんが、MySQL には依存関係があります。クラウド間でポータブルなアプリケーションが、そのクラウドとは異なるベンダーから提供されるテクノロジーに依存する場合があります。
ベンダーへの依存を防止するために、すべてのテクノロジーを置き換え可能にする必要があります。このため、アプリケーションの実装方法に影響を与えることなく、各アプリケーション サービスを異なるテクノロジー基盤に再実装できるように、すべてのアプリケーション機能を体系的かつ完全に抽象化する必要があります。データベースの観点では、こうした抽象化は、データベース モデルの使用と特定のデータベース管理システムを分離することで実現できます。
既存の本番環境データベース管理システム
多くのマルチクラウド アプリケーションでは、その設計の一部としてデータベース システムが開発されますが、多くの企業では、アプリケーション モダナイゼーションの一環としてマルチクラウド アプリケーションを開発しています。これらのアプリケーションは、新しく設計、実装されるアプリケーションが既存のデータベースにアクセスすることを前提として開発されます。
既存のデータベースをモダナイゼーション業務に組み込まない理由はさまざまです。他のデータベース システムからは使用できない特定の機能が使用されている場合があります。企業に複雑で適切に確立された管理プロセスを備えたデータベースがあり、別のシステムへの移行が非現実的または非経済的になっている場合があります。また、最初のフェーズでアプリケーションをモダナイズし、2 番目のフェーズでデータベースをモダナイズすることもあります。
企業が既存のデータベース システムを使用する場合、マルチクラウド アプリケーションの設計者は、これが唯一のデータベースとして使用されるか、または異なるデータベース システムをさまざまなデプロイ ロケーションに追加する必要があるかを決定する必要があります。たとえば、データベースがオンプレミスで使用され、アプリケーションを Google Cloud でも実行する必要がある場合は、Google Cloud にデプロイされたアプリケーション サービスがオンプレミスのデータベースにアクセスするかどうかを検討する必要があります。または、2 つ目のデータベースを Google Cloud とローカルで実行されているアプリケーション サービスの両方にデプロイする必要があるかどうかを検討します。
2 つ目のデータベースを Google Cloud にデプロイする場合、このユースケースはクラウド バーストまたは分散サービスで説明したユースケースと同じものである可能性があります。いずれの場合でも、これらのセクションと同じデータベースの説明が適用されます。ただし、既存のオンプレミスのデータベースでサポートできるクロスロケーション機能（同期やレプリケーションなど）に限定されます。
デプロイ パターン
このドキュメントで説明するユースケースでは、データベースの観点からデータベースが複数のデプロイ ロケーションにある場合、データベース同士の関係はどうなっているかという共通の疑問が発生します。
次のセクションで説明する主な種類の関係（デプロイ パターン）は次のとおりです。
- クロス データベースの依存関係が存在しない状態でのパーティション分割
- 非同期の一方向レプリケーション
- 競合解決による双方向レプリケーション
- 完全にアクティブ / アクティブな同期分散システム
このドキュメントの各ユースケースは 4 つのデプロイ パターンの 1 つ以上にマッピングできます。
次の説明では、クライアントがアプリケーション サービスに直接アクセスしていることを前提としています。ユースケースに応じて、次の図に示すように、ロードバランサがクライアントをアプリケーションに動的にアクセスするように導くために必要になる場合があります。
前の図では、クラウド ロードバランサが、クライアントの呼び出しを利用可能なロケーションの 1 つに導きます。ロードバランサにより、負荷分散ポリシーが適用され、クライアントがアプリケーションとそのデータベースの正しいロケーションに導かれることを保証します。
クロス データベースの依存関係が存在しない状態でのパーティション分割
このデプロイ パターンは、このドキュメントで説明するすべてのパターンの中で最も簡単です。各ロケーションまたは各クラウドにはデータベースがあり、データベースには相互に依存しないパーティション データセットが含まれています。データ項目は 1 つのデータベースにのみ保存されます。各データ パーティションはそれぞれ固有のデータベースに配置されます。このパターンの例は、データセットがどちらか一方のデータベースにあるマルチテナント アプリケーションです。次の図は、2 つの完全にパーティション分割されたアプリケーションを示しています。
前の図に示すように、アプリケーションは 2 つのロケーションにデプロイされ、それぞれがデータセット全体のパーティションを担当します。各データ項目はロケーションの 1 つにのみ存在し、パーティション分割されたデータセットは 2 つの間でレプリケーションされないことを保証します。
パーティション分割データベースのもう 1 つのデプロイ パターンとして、データセットを完全にパーティション分割しつつ、同じデータベース内に格納する方法があります。すべてのデータセットを含むデータベースが 1 つだけ存在します。データセットは同じデータベース内に保存されますが、データセットは完全に分割（パーティション分割）されており、データセットを変更しても別のデータセットに変更はありません。次の図は、1 つのデータベースを共有する 2 つのアプリケーションを示しています。
上の図は、次のことを示しています。
- 両方が（最初のロケーションにある）共通のロケーションを共有する 2 つのアプリケーション デプロイ。
- データセットはパーティション分割されていないため、各アプリケーションはデプロイの全データにアクセスできます。
非同期の一方向レプリケーション
このデプロイ パターンには、1 つ以上のセカンダリ データベースに複製されるプライマリ データベースがあります。セカンダリ データベースを読み取りアクセスに使用してもかまいませんが、アプリケーションではレプリケーションの遅延を考慮する必要があります。このパターンの例は、特定のユースケースに最適なデータベースをプライマリ データベースとして使用し、セカンダリ データベースを分析に使用する場合です。次の図は、一方向に複製されるデータベースにアクセスする 2 つのアプリケーションを示しています。
前の図に示すように、2 つのデータベースの一方はもう一方のレプリカです。図の矢印は、レプリケーションの方向を示します。ロケーション 1 のデータベース システムからのデータは、ロケーション 2 のデータベース システムにレプリケーションされます。
競合解決による双方向レプリケーション
このデプロイ パターンには、相互に非同期でレプリケーションされる 2 つのプライマリ データベースがあります。同じデータが各データベースに同時に書き込まれた場合（たとえば、同じ主キー）、書き込み / 書き込みの競合を引き起こす可能性があります。このリスクのため、レプリケーション中にどの状態が最後の状態かを判断するために、競合解決を設ける必要があります。このパターンは、書き込みと書き込みの競合が発生する機会が稀な状況で使用できます。次の図は、双方向レプリケーション データベースにアクセスする 2 つのアプリケーションを示しています。
上の図に示すように、各データベースは他のデータベースにレプリケーションされます。図に 2 つの別々の青い矢印で示されているように、2 つのレプリケーションは互いに独立しています。2 つのレプリケーションは独立しているため、偶然、同じデータアイテムが各アプリケーションによって変更され、同時にレプリケーションされた場合、競合が発生する可能性があります。この場合、競合解決が必要になります。
完全にアクティブ / アクティブな同期分散システム
このデプロイ パターンには、アクティブ / アクティブ（プライマリ / プライマリ）が設定された単一のデータベースがあります。アクティブ / アクティブの設定では、プライマリ データベースのデータの更新はトランザクションとしての一貫性を保持し、同期的に複製されます。このパターンのユースケースの一例として、分散コンピューティングがあります。次の図は、完全に同期されたプライマリ / プライマリ データベースにアクセスする 2 つのアプリケーションを示しています。
上の図が示すように、この配置により、各アプリケーションは、遅延や競合のリスクを生じることなく、最後に整合性が取れていた状態に常にアクセスできます。一方のデータベースでの変更は、直ちに他のデータベースで有効になります。トランザクションの変更が commit されると、変更が両方のデータベースに反映されます。
データベース システムの分類
このドキュメントで説明するデプロイ パターンで、すべてのデータベース管理システムを同じように良好な状態で使用できるわけではありません。ユースケースによっては、1 つデプロイ パターンを実装することのみが可能です。または、データベース システムのサブセットをデプロイ パターンの組み合わせで実装できる場合もあります。
次のセクションでは、さまざまなデータベース システムを分類して、4 つのデプロイ パターンにマッピングします。
データモデル、内部アーキテクチャ、デプロイモデル、トランザクション タイプなど、さまざまな分割項目でデータベースを分類できます。次のセクションでは、マルチクラウド データベース管理を目的として次の 2 つの要素を使用します。
- デプロイ アーキテクチャ。データベース管理システムがクラウドのリソース（例: コンピューティング エンジン、クラウドマネージド サービス）にデプロイされる方法についてのアーキテクチャ。
- 分散モデル。データベース システムがサポートする分散モデル（単一インスタンス、完全分散など）。
これら 2 つの要素は、マルチクラウドのユースケースとの関連性がきわめて深く、マルチクラウド データベースのユースケースから導き出される 4 つのデプロイ パターンをサポートできます。一般的な分類は、データベース管理システムでサポートされているデータモデルに基づいています。一部のシステムでは、1 つのモデルのみがサポートされます（グラフモデルなど）。他のシステムでは、複数のデータモデル（リレーショナル モデルやドキュメント モデルなど）が同時にサポートされます。ただし、マルチクラウド データベース管理のコンテキストでは、マルチクラウド アプリケーションはマルチクラウド デプロイに任意のデータモデルを使用できるため、この分類は関係ありません。
デプロイ アーキテクチャ別のデータベース システム
マルチクラウド データベース管理には、データベース管理システム用として次の 4 つの主要なデプロイ アーキテクチャが存在します。
- 組み込みのクラウド データベース。組み込みのクラウド データベースは、クラウド テクノロジーと連携するように設計、構築、最適化されています。たとえば、一部のデータベース システムでは、実装プラットフォームとして Kubernetes を使用し、Kubernetes 機能を使用しています。CockroachDB と YugaByte は、この種のデータベースの例です。これらは Kubernetes をサポートする任意のクラウドにデプロイできます。
- クラウド プロバイダが管理するデータベースクラウド プロバイダが管理するデータベースは、クラウド プロバイダ独自の技術に基づいて構築され、特定のクラウド プロバイダが管理するデータベース サービスです。この種のデータベースの例として、Spanner、Bigtable、AlloyDB for PostgreSQL があります。クラウド プロバイダが管理するデータベースは、そのクラウド プロバイダのクラウドでのみ使用でき、他の場所でインストールして実行することはできません。ただし、AlloyDB for PostgreSQL には PostgreSQL との全面的な互換性があります。
- クラウド以前のデータベース。クラウド以前のデータベースは、クラウド テクノロジーが開発される前から存在しており（長期間にわたる場合もあります）、通常はベアメタル ハードウェアおよび仮想マシン（VM）で実行されています。この種のデータベースの例として、PostgreSQL、MySQL、SQL Server があります。このようなシステムは、必要な VM やベアメタル ハードウェアをサポートするあらゆるクラウドで実行できます。
- クラウド パートナーが管理するデータベース。一部のパブリック クラウドには、そのパブリック クラウドのユーザーのデータベースをインストールして管理するデータベース パートナーがあります。このため、ユーザーがこれらのデータベースを自分で管理する必要はありません。この種のデータベースの例としては、MongoDB Atlas や MariaDB があります。
これらのメインカテゴリにはいくつかのバリエーションがあります。たとえば、クラウド用に構築されたデータベースを実装するデータベース ベンダーが、ベンダー提供のクラウドで、クラウド用に構築されたテクノロジーへのインストールとマネージド サービスを顧客に提供することもあります。このアプローチは、ベンダーが自社のデータベースのみを単一のサービスとしてサポートするパブリック クラウドを提供する場合と同等です。
クラウド以前のデータベースもコンテナに存在し、Kubernetes クラスタにデプロイできる可能性があります。ただし、これらのデータベースではスケーリング、マルチサービス、マルチ Pod デプロイなどの Kubernetes 固有の機能は使用されません。
データベース ベンダーは、同時に複数のパブリック クラウド プロバイダと提携し、複数のパブリック クラウドでクラウド パートナーが管理するデータベースとしてデータベースを提供できます。
分散モデル別のデータベース システム
データベースのアーキテクチャの分散モデルに応じて、さまざまなデータベース管理システムが実装されます。データベースのモデルには、次のようなものがあります。
- 単一インスタンス。単一のデータベース インスタンスは、1 つの VM または 1 つのコンテナで実行され、一元化されたシステムとして機能します。このシステムがすべてのデータベース アクセスを管理します。1 つのインスタンスは他のどのインスタンスにも接続できないため、このデータベース システムはレプリケーションをサポートしていません。
- 複数インスタンスのアクティブ / パッシブこの共通アーキテクチャでは、複数のデータベース インスタンスが一緒にリンクされています。最も一般的なリンクはアクティブ / パッシブ関係です。ここで、1 つのインスタンスは、インスタンスおよび書き込みと読み取りの両方をサポートするアクティブなデータベース インスタンスです。1 つ以上のパッシブ システムは読み取り専用で、プライマリから同期または非同期のいずれかでデータベースのすべての変更を受け取ります。パッシブ システムは読み取りアクセス権を提供できます。アクティブ / パッシブは、プライマリ / セカンダリまたはソース / レプリカとも呼ばれます。
- 複数インスタンスがアクティブ / アクティブ。この比較的まれなアーキテクチャでは、各インスタンスがアクティブ インスタンスになります。この場合、各インスタンスが読み取りおよび書き込みトランザクションを実行し、データの整合性を提供できます。この理由により、データの不整合を防ぐために、すべてのインスタンスが常に同期されます。
- 競合解決による複数インスタンスのアクティブ / アクティブ。このシステムも比較的まれです。各インスタンスは書き込みアクセスと読み取りアクセスが可能ですが、データベースは非同期モードで同期されます。同じデータ項目の同時更新が許可されるため、状態は不整合になります。競合解決ポリシーでは、どの状態が最後に整合性のある状態かを判断する必要があります。
- マルチインスタンス シャーディング。シャーディングは、（分離された）データ パーティションの管理に基づきます。各パーティションは、それぞれ別のデータベース インスタンスによって管理されます。時間の経過とともにより多くのシャードを動的に追加できるため、この分散はスケーラブルです。ただし、この機能は一部のシステムでサポートされていないため、シャード間のクエリを使用できない場合があります。
このセクションで説明する分散モデルはすべてシャーディングに対応しており、シャーディングされたシステムにできます。ただし、すべてのシステムがシャーディング オプションを提供するように設計されているわけではありません。シャーディングは拡張性に関係するコンセプトであり、マルチクラウド環境でアーキテクチャの面からデータベースを選択する際には関係ないことが普通です。
分散モデルは、クラウド データベースとパートナー管理のデータベースでは異なります。これらのデータベースはクラウド プロバイダのアーキテクチャに関連付けられており、これらのシステムでは、次のデプロイ ロケーションに基づいてアーキテクチャを実装しています。
- ゾーンシステム。ゾーン管理データベース システムはゾーンに関連付けられています。ゾーンが使用可能な場合は、データベース システムも使用可能になります。ただし、ゾーンが使用できなくなると、データベースにアクセスできなくなります。
- リージョン システム。リージョン管理データベースはリージョンに関連付けられており、少なくとも 1 つのゾーンにアクセスできれば、データベースにアクセスできます。ゾーンのあらゆる組み合わせにアクセスできなくなります。
- クロスリージョン システム。クロスリージョン システムは 2 つ以上のリージョンに関連付けられており、少なくとも 1 つのリージョンが利用可能であれば正しく機能します。
企業が使用する予定のすべてのクラウドにデータベースをインストールできる場合は、クロスリージョン システムはクロスクラウド システムもサポートできます。
このセクションで説明するマネージド データベース アーキテクチャの代わりに、他の方法を使用できます。リージョン システムは、2 つのゾーン間でディスクを共有している場合があります。2 つのゾーンのいずれかにアクセスできなくなった場合、データベース システムはもう一方のゾーンで処理を続行できます。ただし、停止が両方のゾーンに影響する場合、他のゾーンが完全にオンラインであっても、データベース システムは使用できなくなります。
データベース システムとデプロイ パターンのマッピング
次の表に、このドキュメントで説明するデプロイ パターンとデプロイ アーキテクチャの関係を示します。これらのフィールドには、デプロイ パターンとデプロイ アーキテクチャの組み合わせが可能になるために必要な条件が記載されています。
| デプロイ アーキテクチャ | デプロイ パターン | ||||
|---|---|---|---|---|---|
| クロス データベースの依存関係が存在しない状態でのパーティション分割 | 非同期の一方向レプリケーション | 競合解決による双方向レプリケーション | 完全にアクティブ / アクティブな同期分散システム | ||
| 組み込みのクラウド データベース | データベース システムで使用されるクラウド テクノロジーが組み込まれているすべてのクラウドで可能です。 同じデータベースが使用できない場合は、異なるデータベース システムを使用できます。 |
レプリケーションを実施するクラウド データベース。 | 双方向レプリケーションを実施するクラウド データベース。 | プライマリ / プライマリの同期を実施するクラウド データベース。 | |
| クラウド プロバイダが管理するデータベース | データベース システムが異なるクラウド システムに配置されている場合があります。 | レプリカは、クラウド プロバイダが管理するデータベースである必要はありません（デプロイ パターンにおけるデータベース移行テクノロジーのロールを参照）。 | データベースが双方向レプリケーションを実施する場合、クラウド間ではなくクラウド内のみ。 | データベースがプライマリ / プライマリの同期を実施している場合は、クラウド間ではなくクラウド内のみ。 | |
| クラウド以前のデータベース | データベース システムは、クラウドごとに同じ場合と異なる場合があります。 | 複数のクラウドにわたるレプリケーションが可能です。 | データベース システムは、双方向レプリケーションと競合解決を実施します。 | データベース システムは、プライマリ / プライマリの同期を実施します。 | |
| クラウド パートナーが管理するデータベース | クラウド システムはデータベース システムごとに異なる場合があります。 パートナーが、必要なすべてのクラウドでマネージド データベース システムを提供している場合は、同じデータベースを使用できます。 |
レプリカは、クラウド プロバイダが管理するデータベースである必要はありません。 パートナーが、必要なすべてのクラウドでマネージド データベース システムを提供している場合は、同じデータベースを使用できます。 |
データベース システムは、双方向レプリケーションと競合解決を実施します。 | データベース システムは、プライマリ / プライマリの同期を実施します。 | |
データベース システムが組み込みのレプリケーションを提供していない場合は、代わりにデータベース レプリケーション テクノロジーを使用できる場合があります。詳細については、デプロイ パターンにおけるデータベース移行テクノロジーのロールをご覧ください。
次の表に、デプロイ パターンとディストリビューション モデルの関係を示します。フィールドには、組み合わせ可能な特定のデプロイ パターンと分散モデルについての条件を規定します。
| 分散モデル | デプロイ パターン | ||||
|---|---|---|---|---|---|
| クロス データベースの依存関係が存在しない状態でのパーティション分割 | 非同期の一方向レプリケーション | 競合解決による双方向レプリケーション | 完全にアクティブ / アクティブな同期分散システム | ||
| 単一インスタンス | 関連するクラウドの同じまたは異なるデータベース システムで可能です。 | 該当なし | 該当なし | 該当なし | |
| 複数インスタンスのアクティブ / パッシブ | 関連するクラウドの同じまたは異なるデータベース システムで可能です。 | レプリケーションは複数のクラウド間で可能です。 | レプリケーションは複数のクラウド間で可能です。 | 該当なし | |
| 複数インスタンスがアクティブ / アクティブ | 関連するクラウドの同じまたは異なるデータベース システムで可能です。 | 該当なし | 該当なし | クラウド間で同期が可能です。 | |
| 競合解決による複数インスタンスのアクティブ / アクティブ | 関連するクラウドの同じまたは異なるデータベース システムで可能です。 | 該当なし | 該当なし | クラウド間で双方向レプリケーションが可能な場合に該当します。 | |
基盤となるデータベース テクノロジーに基づいて抽象化を追加する分散モデルの実装には、Postgres-BDR アクティブ - アクティブ システムのように、分散モデルが組み込まれたものは含まれていません。このようなシステムは、前の表でそれぞれのカテゴリに記載されています。マルチクラウドの観点では、分散モデルの実装方法は無関係です。
データベースの移行とレプリケーション
ユースケースによっては、企業はデータベースをあるデプロイ ロケーションから別のところに移行する必要がある場合があります。代わりに、ダウンストリーム処理では、データベースのデータを別のロケーションにレプリケーションする必要がある場合があります。次のセクションでは、データベースの移行とデータベースのレプリケーションを詳しく説明します。
データベースの移行
データベースの移行は、データベースがあるデプロイ ロケーションから別のロケーションに移動される場合に使用されます。たとえば、オンプレミスのデータセンターで実行されているデータベースが、クラウドで実行されるように移行される場合です。移行が完了すると、オンプレミス データセンターのデータベースはシャットダウンされます。
データベースを移行する主なアプローチは次のとおりです。
- リフト＆シフト。VM とデータベース インスタンスを実行しているディスクが、そのまま移行先の環境にコピーされます。コピーされると起動され、移行は完了します。
- エクスポートとインポートと、バックアップと復元どちらの方法でも、データベース システム機能を使用してデータベースを外部化し、移行先で再作成します。通常、エクスポート / インポートは ASCII 形式に基づいていますが、バックアップと復元はバイナリ形式に基づいています。
- ゼロ ダウンタイムでの移行。このアプローチでは、アプリケーション システムが移行元システムにアクセスしている間にデータベースが移行されます。初期読み込み後、変更データ キャプチャ（CDC）テクノロジーを使用して、移行元から移行先データベースに変更が送信されます。アプリケーションには、移行元データベース システムで停止してから、移行の完了後に移行先データベースで再起動するまでの間、ダウンタイムが発生します。
データベースの移行は、データベースをあるクラウドから別のクラウドに、またはある種類のデータベース エンジンから別の種類のデータベース エンジンに移行するマルチクラウドのユースケースで発生する作業です。
データベースの移行は多面的なプロセスです。詳細については、データベースの移行: コンセプトと原則（パート 1）とデータベースの移行: コンセプトと原則（パート 2）をご覧ください。
組み込みデータベース テクノロジーを使用して、データベースを移行できます。たとえば、エクスポートとインポート、バックアップと復元、組み込みのレプリケーション プロトコルがあります。移行元システムと移行先システムが異なるデータベース システムである場合は、移行テクノロジーがデータベース移行に最適なオプションです。データベース移行テクノロジーの例として、Database Migration Service、Striim、Debezium があります。
データベース レプリケーション
データベースのレプリケーションは、データベース移行に似ています。ただし、データベースのレプリケーション中、すべての変更がレプリケート先のデータベースに送信されるまで、レプリケート元のデータベース システムはそのまま維持されます。
データベース レプリケーションは、移行元データベースから移行先データベースに変更を送信する継続的なプロセスです。このプロセスが非同期の場合、変更は少し遅れて移行先データベースに到達します。プロセスが同期の場合、移行元システムへの変更は、移行先システムに対して同時に、同じトランザクションに対して行われます。
レプリケート元データベースからレプリケート先データベースにレプリケーションする以外に、レプリケート元データベースからレプリケート先分析システムにデータを複製することも普通です。
データベース移行と同様に、レプリケーション プロトコルが組み込まれている場合は、組み込みデータベース テクノロジーをデータベース レプリケーションに使用できます。組み込みのレプリケーション プロトコルがない場合は、Striim や Debezium などのレプリケーション テクノロジーを使用できます。
デプロイ パターンにおけるデータベース移行テクノロジーのロール
非同期（異種）レプリケーションなど、異なるデータベース システムがデプロイ パターンで使用されている場合に、レプリケーションを可能にする組み込みデータベース テクノロジーは一般には提供されていません。代わりに、データベース移行テクノロジーをデプロイすると、この種のレプリケーションが可能になります。これらの移行システムの一部は、双方向レプリケーションも実装しています。
データベース システムのデプロイ パターンへのマッピングの表 1 または表 2 で「該当なし」とマークされた組み合わせで使用されるデータベース システムに対してデータベース移行またはレプリケーション テクノロジーを使用できる場合、データベース レプリケーションに使用できる可能性があります。次の図は、移行テクノロジーを使用したデータベース レプリケーションのアプローチを示しています。
上の図では、ロケーション 1 のデータベースがロケーション 2 のデータベースにレプリケートされています。データベース システムのレプリケーションを直接行う代わりに、移行サーバーをデプロイしてレプリケーションを実装します。このアプローチは、データベース レプリケーション機能が実装に組み込まれておらず、データベース システムとは別のシステムに依存してレプリケーションを実装する必要がある場合に使用します。
マルチクラウド データベースの選択
マルチクラウド データベースのユースケースをデータベース システムの分類と組み合わせると、特定のユースケースに最適なデータベースの'決定で役立ちます。たとえば、アプリケーションのポータビリティでユースケースを実装するには 2 つのオプションがあります。1 つ目のオプションは、同じデータベース エンジンをすべてのクラウドで使用できることを保証することです。このアプローチにより、システムのポータビリティが保証されます。2 つ目のオプションは、同じデータモデルとクエリ インターフェースをすべてのクラウドで使用できることを保証することです。データベース システムは異なる場合がありますが、ポータビリティは機能的なインターフェース上で提供されます。
以降のセクションのディシジョン ツリーは、このドキュメントのマルチクラウド データベースのユースケースに関する意思決定基準を示しています。このディシジョン ツリーは、ユースケースごとに考慮すべき最適なデータベースについての提案事項を示しています。
既存のデータベース システムに関するベスト プラクティス
データベース システムが本番環境にある場合は、それを保持するか置換するかを決定する必要があります。次の図に、決定プロセスで尋ねる質問を示します。
ディシジョン ツリーにおける質問と回答は次のとおりです。
- データベース システムは本番環境に存在しますか？
- データベース システムが本番環境に存在しない場合は、データベース システムを選択します（マルチクラウド データベースの管理に関する決定に移動します）。
- データベース システムが本番環境に存在する場合は、保持する必要があるかどうかを評価します。
- データベース システムが本番環境に存在する場合は、保持する必要があるかどうかを評価します。
- データベース システムを保持する必要がある場合は、意思決定が下され、ディシジョン プロセスが完了します。
- データベース システムを変更する必要がある場合や、意思決定が進行中である場合は、データベース システムを選択します（マルチクラウド データベース管理に関する決定事項に進みます）。
マルチクラウド データベース管理に関する決定事項
次のディシジョン ツリーは、マルチ ロケーション データベース要件（マルチクラウド データベース デプロイを含む）があるユースケース用です。そこではデプロイ パターンを意思決定基準の基礎として使用します。
ディシジョン ツリーにおける質問と回答は次のとおりです。
- データは、データベースをまたいだ依存関係が存在しない状態で異なるデータベース間でパーティション分割されていますか？
- 「はい」の場合は、同じまたは異なるデータベース システムをロケーションごとに選択できます。
- 「いいえ」の場合は次の質問に進みます。
- 非同期の一方向レプリケーションは必要ですか？
- 「はい」の場合は、データベース レプリケーション システムを使用できるかどうかを評価します。
- 「はい」の場合は、レプリケーション システムと互換性のあるデータベース システムを選択します。
- 「いいえ」の場合は、アクティブ / パッシブ分散モデルを実装できるデータベース システムを選択します。
- 「いいえ」の場合は次の質問に進みます。
- 「はい」の場合は、データベース レプリケーション システムを使用できるかどうかを評価します。
- 同期インスタンスを備えるデータベース システムを選択します。
- 競合の解決は可能ですか？
- 「はい」の場合は、双方向レプリケーション データベース システムまたはアクティブ / アクティブ データベース システムを選択します。
- 「いいえ」の場合は、アクティブ / アクティブ システムを選択します。
- 競合の解決は可能ですか？
複数のマルチクラウド ユースケースが実装されている場合は、1 つのデータベース システムを使用してすべてのユースケースをサポートするか、複数のデータベース システムにするかを判断する必要があります。
すべてのユースケースをサポートするために 1 つのデータベース システムを使用する場合は、同期機能が最も優れているシステムが最適な選択です。たとえば、同期インスタンスだけでなく一方向のレプリケーションが必要な場合は、同期インスタンスが最適な選択です。
同期品質の階層（ゼロから最適）は、パーティション分割、単方向レプリケーション、双方向レプリケーション、完全同期レプリケーションです。
デプロイに関するベスト プラクティス
このセクションでは、マルチクラウド アプリケーションの移行または開発に使用するデータベースを選択する際のベスト プラクティスに重点を置いて説明します。
既存のデータベース管理システム
特定のユースケースで必要とされる場合を除いて、データベースを変更せずに、データベースを保持することをおすすめします。データベース管理システムが確立されていて、開発、運用、メンテナンスのプロセスが実際に稼働している企業の場合は、変更を行わないことをおすすめします。
クラウド内のデータベース システムを必要としないクラウド バースト ユースケースでは、データベースの変更は必要ありません。もう 1 つのユースケースは、同じクラウド内または別のクラウドへの、異なるデプロイ ロケーションへの非同期レプリケーションです。これらのユースケースでは、ベンチマークを実装して、ロケーション間通信と、データベースへのアクセス時にロケーション間通信とレイテンシがアプリケーション要件を満たしていることを確認することがおすすめのアプローチです。
Kubernetes サービスとしてのデータベース システム
企業が StatefulSets に基づくサービスとして、Kubernetes 内でデータベース システムを実行することを検討している場合は、次の要因を考慮する必要があります。
- データベースにアプリケーションに必要なデータベース モデルが用意されている場合。
- Kubernetes サービスとしてのデータベース システムでの運用化の実装方法を決定する非機能的な要因（たとえば、スケーリングの実行方法（スケールアップとスケールダウン）、バックアップと復元の管理方法、モニタリングをシステムによって有効にする方法）。Kubernetes ベースのデータベース システムの要件を理解しやすくするためには、企業はデータベースでの経験を比較点として使用する必要があります。
- 高可用性と障害復旧。高可用性を実現するには、リージョン内のゾーンで障害が発生しても、システムが稼働し続ける必要があります。データベースは、あるゾーンから別のゾーンにすばやくフェイルオーバーできる必要があります。ベストケースのシナリオでは、データベースの各ゾーンでインスタンスが実行され、そのインスタンスは RTO と RPO をゼロに抑えるために完全に同期されます。
- リージョン（またはクラウド）の障害に対処するための障害復旧。理想的なシナリオでは、データベースは RPO と RTO ゼロで 2 番目のリージョンで引き続き稼働します。理想的ではないシナリオでは、セカンダリ リージョンのデータベースがプライマリ データベースからのすべてのトランザクションに完全に追いつくとは限りません。
Kubernetes 内でデータベースを実行する最適な方法を判断するには、特にシステムが Kubernetes 外部の本番環境内のシステムと互換性を持つ必要がある場合に、完全なデータベース評価がおすすめのアプローチです。
Kubernetes に依存しないデータベース システム
Kubernetes のサービスとして実装されるアプリケーションでも、必ずしもデータベースを Kubernetes で実行させる必要はありません。データベース システムを Kubernetes の外部で実行させる必要がある理由はさまざまです（確立されたプロセス、企業内のプロダクトに関する知識、利用不可など）。クラウド プロバイダ管理のデータベースとクラウド パートナー管理のデータベースはどちらもこのカテゴリに分類されます。
Compute Engine でデータベースを実行することも可能です。データベース システムを選択する際は、徹底的なデータベース評価を実施して、アプリケーションのすべての要件を満たしていることを確認することがおすすめの方法です。
アプリケーション設計の観点から見ると、接続プーリングは設計上の重要な考慮事項です。データベースにアクセスするアプリケーション サービスが、内部で接続プールを使用する場合があります。接続プールの使用は、効率の向上とレイテンシの短縮に役立ちます。リクエストは起動を必要とせずにプールから行われるため、接続が作成されるのを待つ必要はありません。アプリケーション サービス インスタンスを追加してアプリケーションをスケールアップすると、各インスタンスで接続プールが作成されます。ベスト プラクティスに従っている場合、各プールで最小の接続セットが事前に作成されます。アプリケーションのスケーリングのために別のアプリケーション サービス インスタンスを作成するたびに、接続がデータベースに追加されます。設計の観点から、データベースでは無制限の接続をサポートできないため、過負荷を避けるために接続の追加を管理する必要があります。
最適なデータベース システム対データベース システムのポータビリティ
データベース システムを選択する際は、アプリケーションの要件への対応が最適なデータベース システムを選択するのが一般的です。マルチクラウド環境では、クラウドごとに最適なデータベースを選択し、ユースケースに応じてこれらのデータベースを相互に接続します。これらのシステムが異なる場合は、一方向か双方向かにかかわらず、レプリケーションにはかなりの労力が必要となります。最適なシステムを使用するメリットが、実装に必要な労力を上回れば、このアプローチが正当化される場合もあります。
ただし、すべての必要なクラウドで利用可能なデータベース システム向けのアプローチを同時に検討、評価することがおすすめの方法です。このようなデータベースは最適なオプションほど理想的ではありませんが、そのようなシステムの実装、運用、保守ははるかに容易な場合があります。
同時データベース システム評価では、両方のデータベース システムの利点と欠点が確認されており、選択のための確固たる基盤となっています。
組み込みデータベース システム対外部データベース システムのレプリケーション
すべてのデプロイ ロケーション（ゾーン、リージョン、クラウド）にデータベース システムが必要なユースケースの場合には、レプリケーションは重要な機能です。レプリケーションは、非同期、双方向、または完全に同期されたアクティブ / アクティブ レプリケーションです。データベース システムは、これらすべてのレプリケーションの形式をサポートしているわけではありません。
システム実装レプリケーションの一部としてレプリケーションをサポートしていないシステムの場合は、Striim などのシステムを使用してアーキテクチャを補完できます（データベース移行をご覧ください）。
ベスト プラクティスは、代わりのデータベース管理システムを評価して、レプリケーションが組み込まれているシステムまたはレプリケーション テクノロジーを必要とするシステムの利点と欠点を判断することです。
3 つ目のテクノロジー クラスがこの役割を担うこともあります。このクラスは、既存のデータベース システムにレプリケーションを提供するアドオンを提供します。その一例が、MariaDB Galera Cluster です。評価プロセスで認められる場合は、これらのシステムを評価することをおすすめします。
次のステップ
- ハイブリッドおよびマルチクラウドのパターンとプラクティスについて確認する。
- 他のクラウド サービス プロバイダを Google Cloud に接続するためのパターンについて確認する。
- Google Cloud でのハイブリッド クラウドとマルチクラウドのデプロイのモニタリングとロギングのアーキテクチャについて確認する。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
協力者
著者: ソリューション アーキテクト、Alex Cârciu