マルチクラウド データベース管理: アーキテクチャ、ユースケース、ベスト プラクティス

このドキュメントでは、マルチクラウド データベース管理用のデプロイ アーキテクチャ、ユースケース、ベスト プラクティスについて説明します。これは、複数のクラウド内とクラウド間でステートフル アプリケーションを設計、実装するアーキテクトとエンジニアを対象としています。

データベースにアクセスするマルチクラウド アプリケーション アーキテクチャは、ユースケースによって異なります。1 つのステートフル アプリケーション アーキテクチャですべてのマルチクラウドのユースケースをサポートすることはできません。たとえば、クラウド バースト機能のユースケースに最適なデータベース ソリューションは、複数のクラウド環境で同時に実行するアプリケーションに最適なデータベース ソリューションとは異なります。

Google Cloud などのパブリック クラウドの場合は、特定のマルチクラウド ユースケースに適したさまざまなデータベース テクノロジーがあります。単一のパブリック クラウド内の複数のリージョンにアプリケーションをデプロイするオプションの 1 つに、Cloud Spanner などのパブリック クラウドのプロバイダが管理するマルチリージョン データベースを使用する方法があります。 アプリケーションをパブリック クラウド間で移植可能にデプロイするには、PostgreSQL などのプラットフォームに依存しないデータベースをおすすめします。

このドキュメントでは、ステートフル データベース アプリケーションの定義を紹介し、引き続きマルチクラウド データベースのユースケース分析を紹介します。次に、ユースケースに基づいて、マルチクラウド デプロイ アーキテクチャ用の詳細なデータベース システムの分類を紹介します。

また、このドキュメントでは、適切なデータベース テクノロジー選択のための重要な決定事項を概説するデータベース選択のためのディシジョン ツリーも紹介します。マルチクラウド データベース管理のベスト プラクティスに関する説明で締めくくります。

主な用語と定義

このセクションでは、このドキュメントで使用する、一般的なステートフル データベース アプリケーションの用語と定義を提示します。

用語

  • パブリック クラウド。パブリック クラウドは、本番環境ワークロードの実行に使用できるマルチテナント インフラストラクチャ(通常はグローバル)とサービスを提供します。Google Cloud は、GKEAnthosマネージド データベースなどの多数のマネージド サービスを提供するパブリック クラウドです。
  • ハイブリッド クラウド。ハイブリッド クラウドは、パブリック クラウドと 1 つ以上のオンプレミス データセンターを組み合わせたものです。ハイブリッド クラウドをご利用のお客様は、オンプレミス サービスとパブリック クラウドで提供される追加サービスを組み合わせることができます。
  • マルチクラウド。マルチクラウドは、複数のパブリック クラウドとオンプレミス データセンターを組み合わせたものです。ハイブリッド クラウドはマルチクラウドのサブセットです。
  • デプロイする場所。インフラストラクチャの場所は、アプリケーションとデータベースを含むワークロードをデプロイして実行できる物理的な場所です。たとえば、Google Cloud ではデプロイの場所はゾーンとリージョンです。抽象レベルでは、パブリック クラウドのリージョンまたはゾーンとオンプレミスのデータセンターがデプロイの場所です。

ステートフル データベース アプリケーション

マルチクラウドのユースケースを定義するために、このドキュメントでは、次の図に示すように、汎用のステートフル データベース アプリケーション アーキテクチャを使用しています。

汎用的なステートフル アプリケーション アーキテクチャ。

この図は次のコンポーネントを示しています。

  • データベース。データベースは、単一インスタンス、複数インスタンス、または分散データベースで、コンピューティング ノードにデプロイされるか、クラウド マネージド サービスとして使用できます。
  • アプリケーション サービス。これらのサービスは、ビジネス ロジックを実装するアプリケーションとして結合されます。アプリケーション サービスは次のいずれかです。
    • Kubernetes でのマイクロサービス。
    • 1 つ以上の仮想マシンで実行される粗粒度のプロセス。
    • 1 つの大規模仮想マシン上のモノリシック アプリケーション。
    • Cloud Functions または Cloud Run のサーバーレス コード。一部のアプリケーション サービスではデータベースにアクセスできます。各アプリケーション サービスは複数回デプロイできます。アプリケーション サービスの各デプロイは、そのアプリケーション サービスのインスタンスです。
  • アプリケーション クライアント。アプリケーション クライアントは、アプリケーション サービスが提供する機能にアクセスします。アプリケーション クライアントは次のいずれかになります。
    • デプロイされたクライアント。コードはマシン、ノートパソコン、またはスマートフォン上で実行されます。
    • コードがデプロイされていないクライアント。クライアント コードはブラウザで実行されます。 アプリケーション クライアント インスタンスは常に 1 つ以上のアプリケーション サービス インスタンスにアクセスします。

マルチクラウド データベースに関する議論では、ステートフル アプリケーションのアーキテクチャの抽象化は、データベース、アプリケーション サービス、アプリケーション クライアントで構成されています。アプリケーションの実装では、使用するオペレーティング システムやプログラミング言語などの要因が変わる可能性があります。ただし、これらの詳細はマルチクラウド データベースの管理には影響しません。

データ ストレージ サービスとしてのキューとファイル

アプリケーション サービスでは、データの永続化に利用できる永続リソースが数多く存在します。これらのリソースには、データベース、キュー、ファイルなどがあります。永続性リソースには、それぞれ専用のストレージ データモデルとアクセス パターンが用意されています。アプリケーションでは、キュー、メッセージング システム、ファイル システムを使用しますが、次のセクションでは特にデータベースについて説明します。

デプロイの場所、状態の共有、マルチクラウド データベースの同期レプリケーションと非同期レプリケーションなどの要素については、キューとファイルにも同じ考慮事項が適用されますが、このドキュメントでは説明しません。

ネットワーキング

汎用のステートフル アプリケーション(次の図にもう一度示しています)のアーキテクチャでは、コンポーネント間の各矢印はネットワーク接続(たとえば、アプリケーション サービスにアクセスするアプリケーション クライアント)の通信関係を表します。

汎用的なステートフル アプリケーション アーキテクチャ。

ゾーン内、またはゾーン、リージョン、クラウドをまたがって接続できます。接続は、デプロイするロケーションを自由に組み合わせて行うことができます。マルチクラウド環境では、クラウド間のネットワーキングが重要な考慮事項であり、いくつかのオプションを使用できます。クラウド間のネットワークの詳細については、Google Cloud への接続: お客様のネットワーク オプションの説明をご覧ください。

このドキュメントのユースケースでは、次のことを想定しています。

  • クラウド間に安全なネットワーク接続が存在する。
  • データベースとそれらのコンポーネントは相互に通信できる。

機能面以外の観点では、ネットワークのサイズ、つまりスループットとレイテンシは、データベースのレイテンシとスループットに影響する可能性があります。機能の観点からは、ネットワーキングは通常、影響を与えません。

マルチクラウド データベースのユースケース

このセクションでは、マルチクラウド データベース管理の最も一般的なユースケースをいくつか紹介します。これらのユースケースでは、クラウドとデータベース ノードの間に安全なネットワーク接続があることを前提としています。

アプリケーションの移行

マルチクラウド データベース管理のコンテキストにおけるアプリケーション移行とは、アプリケーション、すべてのアプリケーション サービス、データベースを現在のクラウドからターゲット クラウドへ移行することを指します。企業がアプリケーションの移行を決定する際には、クラウド プロバイダと競合する状態を回避する、テクノロジーをモダナイズする、所有コストの総額(TCO)を削減するためなど、多くの理由が存在します。

アプリケーションの移行の目的は、現在のクラウドで本番環境を停止し、移行の完了後も移行先のクラウドで本番環境を継続することです。アプリケーション サービスは、ターゲット クラウドで実行する必要があります。サービスを実装するには、リフト&シフトのアプローチを使用できます。この方法では、ターゲット クラウドに同じコードがデプロイされます。サービスを再実装するために、ターゲット クラウドで使用できる最新のクラウド テクノロジーを使用できます。

データベースの観点から、アプリケーションの移行に関して次の代替選択肢を検討してください。

  • データベースのリフト&シフト: ターゲット クラウドで同じデータベース エンジンが使用可能な場合は、データベースをリフト&シフトして、ターゲット クラウドに同じデプロイを作成できます。
  • データベースのリフトと同等の同等のマネージド サービスへの移行: ターゲット クラウドで提供される場合、セルフマネージド データベースは、同じデータベース エンジンのマネージド バージョンに移行できます。
  • データベースのモダナイゼーション: 用意されているデータベース テクノロジーはクラウドごとに異なります。クラウド プロバイダが管理するデータベースには、より厳格なサービスレベル契約(SLA)、スケーラビリティ、自動障害復旧などの利点がある場合が考えられます。

デプロイ戦略に関係なく、データベース移行は、現在のクラウドからターゲット クラウドにデータを移動させる必要があるため、時間がかかるプロセスです。ダウンタイムが発生するエクスポートとインポートのアプローチを採用することは可能ですが、ダウンタイムを最小限またはゼロにすることをおすすめします。このアプローチは、アプリケーションのダウンタイムを最小限に抑え、企業とその顧客への影響を最小限に抑えます。

障害復旧

障害復旧とは、アプリケーションがリージョンの停止中にアプリケーション クライアントにサービスを提供し続ける機能です。障害復旧を行うには、少なくとも 2 つのリージョンにアプリケーションをデプロイし、いつでも実行できる状態である必要があります。本番環境では、アプリケーションはプライマリ リージョンで実行されます。ただし、停止が発生した場合は、セカンダリ リージョンがプライマリ リージョンになります。障害復旧では次のさまざまな準備のモデルがあります。

  • ホット スタンバイ。アプリケーションは 2 つ以上のリージョン(プライマリとセカンダリ)にデプロイされ、アプリケーションはすべてのリージョンで完全に機能します。プライマリ リージョンに障害が発生した場合、セカンダリ リージョンのアプリケーションがすぐにアプリケーション クライアント トラフィックを利用できます。
  • コールド スタンバイ。アプリケーションはプライマリ リージョンで実行されていますが、セカンダリ リージョンで起動できる状態になっています(ただし、実行はされていません)。プライマリ リージョンに障害が発生した場合、セカンダリ リージョンでアプリケーションが起動されます。アプリケーションの停止は、アプリケーションが実行でき、すべてのアプリケーション サービスをアプリケーション クライアントに提供できるようになるまで発生します。
  • スタンバイなし。このモデルでは、アプリケーション コードはデプロイの準備ができていますが、セカンダリ リージョンにはまだデプロイされていません(そのため、デプロイされたリソースは使用されません)。プライマリ リージョンが停止した場合、アプリケーションの最初のデプロイはセカンダリ リージョンで行われる必要があります。このデプロイにより、アプリケーションはコールド スタンバイと同じ状態になります。つまり、起動が必要です。このアプローチでは、アプリケーションのデプロイを最初に行う必要があるため、コールド スタンバイの場合よりもアプリケーションの停止が長くなります(アプリケーションのデプロイにはクラウド リソースの作成を含む)。

データベースの観点からは、前のリストで説明した準備モデルは、次のデータベース アプローチに対応しています。

  • トランザクション同期データベース。このデータベースはホット スタンバイ モデルに対応しています。プライマリ リージョン内のすべてのトランザクションは、セカンダリ リージョンで同期調整されます。停止時にセカンダリ リージョンがプライマリ リージョンになると、データベースに整合性があり、すぐに使用できるようになります。このモデルでは、目標復旧時点(RPO)と目標復旧時間(RTO)はどちらもゼロです。
  • 非同期で複製されるデータベース。このデータベースもホット スタンバイ モデルに対応しています。プライマリ リージョンからセカンダリ リージョンへのデータベース レプリケーションは非同期であるため、プライマリ リージョンで障害が発生すると、一部のトランザクションがセカンダリ リージョンに複製される可能性があります。セカンダリ リージョンのデータベースは本番環境の負荷に対応しますが、最新のデータが含まれていない可能性があります。このため、復元できないトランザクションがアプリケーションで失われる可能性があります。このリスクのため、このアプローチの RTO はゼロですが、RPO はゼロより大きいです。
  • アイドリング データベース。このデータベースは、コールド スタンバイ モデルに対応しています。データベースはデータなしで作成されます。プライマリ リージョンで障害が発生した場合は、アイドリング データベースにデータを読み込む必要があります。このアクションを有効にするには、プライマリ リージョンで通常のバックアップを取得し、セカンダリ リージョンに転送する必要があります。バックアップは、データベース エンジンでサポートされているものに応じて、完全または増分です。いずれの場合も、データベースが最後のバックアップに戻り、アプリケーションの観点からは、プライマリ リージョンと比較して多くのトランザクションが失われる可能性があります。このアプローチはコスト効率に優れていますが、データベースの状態が最新でないため、使用可能な最後のバックアップ以降のすべてのトランザクションが失われるリスクによって価値が軽減されます。
  • データベースなし。このモデルは、スタンバイなしの場合と同じです。セカンダリ リージョンにはデータベースがインストールされていません。プライマリ リージョンに障害が発生した場合は、データベースを作成する必要があります。作成が完了したデータベースは、アイドリング データベースの場合と同様に、アプリケーションで使用できるようにする前にデータとともに読み込む必要があります。

このドキュメントで説明する障害復旧アプローチは、プライマリ リージョンとセカンダリ リージョンの代わりにプライマリ クラウドとセカンダリ クラウドを使用する場合にも適用されます。主な違いは、クラウド間のネットワーク不均一により、クラウド内のリージョン間のネットワーク距離と比較してクラウド間のレイテンシが増加する可能性があることです。

クラウド全体の障害の可能性は、リージョンの障害のそれよりも低いです。 しかし、企業が 2 つのクラウドにアプリケーションをデプロイすることは有用です。このアプローチは、企業を障害から保護するのに役立ち、あるいはビジネスまたは業界の規制を満たすのに役立ちます。

障害復旧では、プライマリ リージョンとセカンダリ リージョン、プライマリ クラウドとセカンダリ クラウドを使用することもできます。このアプローチにより、企業は障害に対処するための最適な障害復旧プロセスを選択できます。アプリケーションの実行を有効にするには、停止の重大度に応じて、セカンダリ リージョンまたはセカンダリ クラウドを使用します。

クラウド バースト機能

クラウド バースト機能は、さまざまなデプロイ ロケーションでアプリケーション クライアント トラフィックをスケールアップできるようにする構成です。容量の需要が増え、スタンバイ ロケーションが追加の容量を提供すると、アプリケーションはバーストします。プライマリ ロケーションは通常のトラフィックをサポートしますが、スタンバイ ロケーションは、プライマリ ロケーションがサポートできる範囲を超えてアプリケーション クライアント トラフィックが増加した場合の追加容量を提供できます。プライマリ ロケーションとスタンバイ ロケーションの両方に、アプリケーション サービス インスタンスがデプロイされます。

クラウド バースト機能は、複数のクラウドにまたがって実装されています。ここで、1 つ目のクラウドがプライマリ クラウド、2 つ目のクラウドがスタンバイ クラウドです。ハイブリッド クラウドのコンテキストで、オンプレミス データセンターの限られた数のコンピューティング リソースをパブリック クラウドの弾力性のあるクラウド コンピューティング リソースで拡張するのに使用します。

データベースのサポートについては、次のオプションを使用できます。

  • プライマリ ロケーションのデプロイ。このデプロイでは、データベースはプライマリ ロケーションにのみデプロイされ、スタンバイ ロケーションにはデプロイされません。アプリケーションがバーストした場合、スタンバイ ロケーションのアプリケーションは、プライマリ ロケーションのデータベースにアクセスします。
  • プライマリ / スタンバイ ロケーションのデプロイ。このデプロイは、プライマリ ロケーションとスタンバイ ロケーションの両方をサポートします。データベース インスタンスは両方のロケーションにデプロイされ、そのロケーションのアプリケーション サービス インスタンスからアクセスされます(特にバーストの場合)。クラウド内およびクラウド間の障害復旧と同様に、2 つのデータベースをトランザクション的に同期することも、非同期に同期することもできます。非同期同期では、遅延が生じることがあります。更新がスタンバイ ロケーションで行われている場合、これらの更新をプライマリ ロケーションに反映する必要があります。両方の場所で同時に更新できる場合は、競合解決を実施する必要があります。

クラウド バースト機能は、ハイブリッド クラウドでオンプレミスのデータセンターの容量を増やすためによく使用されます。これは、データを国内に留める必要がある場合に、パブリック クラウド全体で使用できるアプローチです。ある国のパブリック クラウドに 1 つのリージョンしかない場合、同じ国の異なるパブリック クラウドのリージョンにバーストできます。このアプローチにより、データは国内に存在する一方で、パブリック クラウド リージョンのリージョン内のリソース制限には対処できます。

クラス最高のクラウド サービスの使用

アプリケーションの中には、単一のクラウドでは利用できない、専用のクラウドのサービスと製品を必要とするものがあります。たとえば、アプリケーションで、あるクラウドでビジネスデータのビジネス ロジック処理を、別のクラウドでビジネスデータの分析を行う場合です。このユースケースでは、アプリケーションのビジネス ロジック処理部分と分析部分が異なるクラウドにデプロイされます。

データ管理の観点からは、このユースケースは次のとおりです。

  • パーティション データ。アプリケーションの各部分には独自のデータベース(別々のパーティション)があり、どのデータベースも互いに直接接続されていません。データを管理するアプリケーションは、両方のデータベース(パーティション)で使用する必要があるすべてのデータを 2 回書き込みます。
  • 非同期で複製されるデータベース。あるクラウドのデータを他のクラウドで使用する必要がある場合は、非同期のレプリケーション関係が適している可能性があります。たとえば、分析アプリケーションがビジネス アプリケーション用の同じデータセットまたはデータセットのサブセットを必要とする場合は、後者をクラウド間で複製できます。
  • トランザクション同期データベース。このようなデータベースを使用すると、アプリケーションの両部分でデータが利用可能になります。各アプリケーションからの更新はトランザクション間で整合性があり、両方のデータベース(パーティション)ですぐに使用できます。トランザクションで同期されたデータベースは、事実上、単一の分散データベースとして機能します。

分散サービス

分散サービスは、複数のデプロイ ロケーションにデプロイされて実行されます。すべてのサービス インスタンスをすべてのデプロイ ロケーションにデプロイできます。また、ハードウェアの可用性や予想される負荷制限などの要因に基づいて、すべてのロケーションにサービスをデプロイすることも、いずれかのロケーションのみにサービスをデプロイすることもできます。

トランザクション的に同期されたデータベースのデータは、すべてのロケーションで整合しています。このため、すべてのデータベース ロケーションにサービス インスタンスをデプロイするには、このようなデータベースが最適なオプションです。

非同期でレプリケートされたデータベースを使用すると、同じデータ項目が 2 つのデプロイ ロケーションで同時に変更されるリスクがあります。2 つの競合する変更のうちどちらが最終的な整合状態なのかを判断するには、競合解決戦略を実装する必要があります。競合解決を実装することは可能ですが、それは常に簡単なわけではなく、整合状態にデータを戻すために手動による介在がときどき必要になります。

分散サービスの再配置とフェイルオーバー

クラウド リージョン全体で障害が発生した場合は、障害復旧が起動されます。ステートフル データベース アプリケーション内の単一のサービス(リージョンまたはアプリケーション全体ではない)に障害が発生した場合は、サービスを復元して再起動する必要があります。

障害復旧の最初のアプローチは、障害が発生したサービスを元のデプロイ ロケーションで再起動することです(原位置再起動アプローチ)。Kubernetes などのテクノロジーでは、構成に基づいてサービスが自動的に再起動します。

しかし、この原位置再起動アプローチが成功しない場合は、代わりにセカンダリ ロケーションでサービスを再起動します。サービスは、プライマリ ロケーションからセカンダリ ロケーションにフェイル オーバーします。アプリケーションが一連の分散サービスとしてデプロイされている場合は、単一のサービスのフェイルオーバーは動的に行うことができます。

データベースの観点からは、元のデプロイ ロケーションでのサービスの再起動には、特定のデータベースのデプロイは必要ありません。サービスが代わりのデプロイ ロケーションに移動されて、サービスがデータベースにアクセスすると、この文書で前に分散サービスで説明したものと同じ準備モデルが適用されます。

サービスが一時的に再配置され、再配置中に企業のレイテンシが増大することを許容できる場合、サービスはデプロイ ロケーションを超えてデータベースにアクセスできます。サービスは再配置されますが、元のデプロイ ロケーションからアクセスするのと同じ方法でデータベースにアクセスします。

コンテキスト依存のデプロイ

通常、すべてのアプリケーション クライアントに対応する単一のアプリケーション デプロイには、そのアプリケーション サービスとデータベースがすべて含まれます。ただし、例外のユースケースもあります。1 つのアプリケーション デプロイが、特定の基準に基づいて、クライアントのサブセットのみにサービスを提供できます。つまり、複数のアプリケーションのデプロイが必要になります。各デプロイはクライアントのそれぞれのサブセットにサービスを提供し、すべてのデプロイがすべてのクライアントにサービスを提供します。

コンテキスト依存のデプロイのユースケースに関する例は次のとおりです。

  • 1 つのアプリケーションがすべての小さなテナントにデプロイされるマルチテナント アプリケーションをデプロイする場合、別のアプリケーションは 10 個の中テナントごとにデプロイされ、1 つのアプリケーションはプレミアム テナントごとにデプロイされます。
  • たとえば、企業顧客と政府機関顧客など、顧客を分離する必要がある場合。
  • 開発環境、ステージング環境、本番環境を分離する必要がある場合。

データベースの観点からは、アプリケーションのデプロイごとに 1 対 1 のデプロイ戦略で 1 つのデータベースをデプロイできます。次の図に示すように、この戦略は単純なデプロイ方法です。各デプロイには独自のデータセットが存在するため、パーティション分割されたデータが作成されます。

各アプリケーションのデプロイには個別のデータベースが含まれています。

上の図は、次のことを示しています。

  • アプリケーションの 3 つのデプロイがある設定。
  • 各データセットにはそれぞれ独自のデータベースがあります。
  • データがデプロイ間で共有されることはありません。

多くの場合は 1 対 1 のデプロイが最適な戦略ですが、代わりのものもあります。

マルチテナンシーの場合は、テナントが再配置される可能性があります。小規模のテナントは中規模のテナントになり、別のアプリケーションに再配置する必要が生じる場合があります。この場合、個々のデータベースのデプロイにはデータベースの移行が必要です。分散データベースがデプロイされ、すべてのデプロイで同時に使用されている場合、すべてのテナントデータは 1 つのデータベース システムに置かれます。このため、データベース間でテナントを移動するときに、データベースを移行する必要はありません。次の図は、この種のデータベースの例を示しています。

すべてのアプリケーションのデプロイで、分散データベースが共有されます。

上の図は、次のことを示しています。

  • アプリケーションの 3 つのデプロイ。
  • デプロイはすべて、単一の分散データベースを共有します。
  • アプリケーションは各デプロイのすべてのデータにアクセスできます。
  • データ パーティショニングは実装されていません。

企業がライフサイクル オペレーションの一環としてテナントを再配置することが多い場合は、データベースのレプリケーションが役立ちます。このアプローチでは、テナントの移行前に、データベース間でテナントのデータが複製されます。この場合、独立したデータベースは異なるアプリケーション デプロイに使用され、テナント移行の直前と実行中にのみレプリケーション向けに設定されます。次の図は、テナントの移行中の 2 つのアプリケーションのデプロイ間の一時的なレプリケーションを示しています。

2 つのアプリケーション デプロイ間での一時的なデータベース レプリケーション。

上の図は、それぞれのデプロイに関連付けられたデータを保持する 3 つの別々のデータベースを持つアプリケーションの 3 つのデプロイを示しています。1 つのデータベースから別のものにデータを移行するために、一時的なデータベース移行を設定できます。

アプリケーションのポータビリティ

アプリケーションのポータビリティにより、アプリケーションを異なるデプロイ ロケーションに、特に異なるクラウドにデプロイできることを保証します。このポータビリティにより、移行専用の再設計や、アプリケーション移行の準備のための追加のアプリケーション開発を必要とせずに、いつでもアプリケーションを移行できることを保証します。

アプリケーションのポータビリティを確保するために、次のいずれかの方法を使用できます。これについては、このセクションで後述します。

  • システムベースのポータビリティ
  • API の互換性
  • 機能ベースのポータビリティ

システムベースのポータビリティでは、すべての可能性のあるデプロイで使用されるものと同じ技術コンポーネントが使用されます。システムベースのポータビリティを保証するには、それぞれのテクノロジーがすべての可能性のあるデプロイ ロケーションで利用可能である必要があります。たとえば、PostgreSQL のようなデータベースが候補である場合は、すべての可能性のあるデプロイ ロケーションにおけるその可用性を、想定する時間枠で確認する必要があります。たとえば、プログラミング言語やインフラストラクチャ テクノロジーなど、他のすべてのテクノロジーについても同じく当てはまります。次の図に示すように、このアプローチではテクノロジーに基づいて、すべてのデプロイ ロケーション間に共通の一連の機能が確立されます。

同じテクノロジーのデプロイによるポータビリティ。

上の図は、アプリケーションがデプロイされるすべてのロケーションでまったく同じデータベース システムを想定しているポータブル アプリケーションのデプロイを示しています。それぞれのロケーションで同じデータベース システムが使用されるため、アプリケーションはポータブルです。アプリケーションでは、まったく同じデータベース システムがデプロイ全体で使用されると想定できます。したがって、データベース システムのインターフェースと動作はまったく同じであると想定できます。

データベースのコンテキストでは、API 互換システムで、クライアントが特定のデータベース アクセス ライブラリ(たとえば、MySQL クライアント ライブラリ)を使用して、クラウド環境で使用できる準拠している実装に接続できるようにします。次の図は、API の互換性を示しています。

同じ API をサポートする別のテクノロジーをデプロイすることで、ポータビリティを実現。

上の図は、データベース システムではなく、データベース システム API に基づくアプリケーションのポータビリティを示しています。データベース システムはロケーションごとに異なっていてもかまいませんが、API は同じで、同じ機能を公開します。基盤となるデータベース システムが別のデータベース テクノロジーでも、各ロケーションで同じ API を使用することを前提とできるため、このアプリケーションはポータブルです。

機能ベースのポータビリティでは、同じ機能を提供するさまざまなテクノロジーがさまざまなクラウドで使用される可能性があります。たとえば、データベースの使用をリレーショナル モデルに限定できます。どのリレーショナル データベース システムもアプリケーションをサポートできるため、アプリケーションのポータビリティに影響を与えることなく、さまざまなバージョンのさまざまなデータベース システムをさまざまなクラウドで使用できます。機能ベースのポータビリティの欠点は、すべてのリレーショナル データベース システムがサポートするデータベース モデルの一部しか使用できないことです。すべてのクラウドと互換性があるデータベース システムの代わりに、データベース モデルを使用する必要があります。次の図は、機能ベースのポータビリティのアーキテクチャ例を示しています。

異なるテクノロジー、異なるAPI をデプロイする一方で、同じデータベース モデルをデプロイすることでポータビリティを実現。

上の図に示すように、データベース システムの API とデータベース システムは各ロケーションで異なる場合があります。ポータビリティを保証するため、各ロケーションで使用可能な、各データベース システムと各 API の一部のみを使用する必要があります。各ロケーションでは各データベース システムのサブセットのみが一般に使用可能なため、アプリケーションは使用をそのサブセットに制限する必要があります。

このセクションのすべてのオプションに対してポータビリティを確保するには、すべてのターゲット ロケーションに完全なアーキテクチャを継続的にデプロイする必要があります。単体テストケースとシステムテスト ケースはすべて、これらのデプロイに対して実行する必要があります。これらは、インフラストラクチャとテクノロジーにおける変化を早期に検出して対処するための不可欠な要件です。

ベンダー依存関係の防止

ベンダー依存関係(ロックイン)の防止は、特定のテクノロジーやベンダーへの依存のリスクを軽減するのに役立ちます。実質的には、アプリケーションのポータビリティに似ています。ベンダー依存関係の防止は、クラウド サービスだけでなく、使用するすべてのテクノロジーに適用されます。たとえば、MySQL がデータベース システムとして使用され、クラウド内の仮想マシンにインストールされる場合、クラウドの観点からは依存関係がありませんが、MySQL には依存関係があります。クラウド間でポータブルなアプリケーションは、クラウドとは異なるベンダーによって提供されるテクノロジーに依存する場合があります。

ベンダーの依存関係を防ぐには、すべてのテクノロジーを交換できる必要があります。このため、アプリケーションの実装方法に影響を与えることなく、各アプリケーション サービスを異なるテクノロジー ベースに再実装できるように、すべてのアプリケーション機能を徹底的に構造化して抽象化する必要があります。データベースの観点からは、この抽象化は、データベース モデルの使用と特定のデータベース管理システムを分離することで行えます。

既存の本番環境データベース管理システム

多くのマルチクラウド アプリケーションはデータベース システムで設計の一環として開発されていますが、多くの企業はマルチクラウド アプリケーションをアプリケーション モダナイゼーション業務の一環として開発しています。これらのアプリケーションは、新しく設計、実装されたアプリケーションが既存のデータベースにアクセスすることを前提として開発されています。

既存のデータベースをモダナイゼーション業務に組み込まない理由はさまざまです。他のデータベース システムからは使用できない特定の機能が使用されている場合があります。企業に複雑で適切に確立された管理プロセスを備えたデータベースがあり、別のシステムへの移行が非現実的または非経済的になっている場合があります。また、企業が最初のフェーズでアプリケーションをモダナイズし、2 番目のフェーズでデータベースをモダナイズすることを選択することもできます。

企業が既存のデータベース システムを使用する場合、マルチクラウド アプリケーションの設計者は、これが唯一のデータベースとして使用されるか、または異なるデータベース システムをさまざまなデプロイ ロケーションに追加する必要があるかを決定する必要があります。たとえば、データベースがオンプレミスで使用され、アプリケーションを Google Cloud でも実行する必要がある場合は、Google Cloud にデプロイされたアプリケーション サービスがオンプレミスのデータベースにアクセスするかどうかを検討する必要があります。または、Google Cloud とローカルで実行されているアプリケーション サービスの両方に 2 番目のデータベースをデプロイする必要があるかどうかを検討します。

2 番目のデータベースが Google Cloud にデプロイされている場合、ユースケースはクラウド バースト機能または分散サービスで説明したユースケースと同じになります。いずれの場合も、これらのセクションと同じデータベースの説明が適用されます。ただし、既存のオンプレミスのデータベースでサポートできるクロスロケーション機能(同期やレプリケーションなど)に限定されます。

デプロイ パターン

このドキュメントで説明するユースケースでは、データベースの観点からデータベースが複数のデプロイ ロケーションにある場合、データベース同士の関係はどうなっているかという共通の疑問が発生します。

次のセクションで説明する主な種類の関係(デプロイ パターン)は次のとおりです。

  • クロス データベースの依存関係が存在しない状態でのパーティション分割
  • 非同期の一方向レプリケーション
  • 競合解決による双方向レプリケーション
  • 完全にアクティブ / アクティブな同期分散システム

このドキュメントの各ユースケースは 4 つのデプロイ パターンの 1 つ以上にマッピングできます。

次の説明では、クライアントがアプリケーション サービスに直接アクセスしていることを前提としています。ユースケースに応じて、次の図に示すように、ロードバランサがクライアントをアプリケーションに動的にアクセスするように導くために必要になる場合があります。

負荷分散を介したクライアント アクセス。

前の図では、クラウド ロードバランサが、クライアントの呼び出しを利用可能なロケーションの 1 つに導きます。ロードバランサにより、負荷分散ポリシーが適用され、クライアントがアプリケーションとそのデータベースの正しいロケーションに導かれることを保証します。

クロス データベースの依存関係が存在しない状態でのパーティション分割

このデプロイ パターンは、このドキュメントで説明するすべてのパターンの中で最も簡単なものです。各ロケーションまたはクラウドにデータベースがあり、データベースには相互に依存していない分割データセットが含まれます。データ項目は 1 つのデータベースにのみ格納されます。各データ パーティションは、独自のデータベースにあります。このパターンの例は、データセットがいずれかのデータベースにあるマルチテナント アプリケーションです。次の図は、2 つの完全にパーティション分割されたアプリケーションを示しています。

完全にパーティション分割されたデータベースのデプロイ。

前の図に示すように、アプリケーションは 2 つのロケーションにデプロイされ、それぞれがデータセット全体のパーティションを担当します。各データ項目はロケーションの 1 つにのみ存在し、パーティション分割されたデータセットは 2 つの間でレプリケーションされないことを保証します。

パーティション分割されたデータベースの別のデプロイ パターンでは、データセットが完全にパーティション分割されますが、同じデータベース内に格納されます。すべてのデータセットを含むデータベースは 1 つだけです。データセットは同じデータベース内に格納されますが、データセットは完全に分離(パーティション分割)されており、データセットを変更しても別のデータセットに変更はありません。次の図は、単一のデータベースを共有する 2 つのアプリケーションを示しています。

複数のロケーションをサポートする単一のデータベース インスタンス。

上の図は、次のことを示しています。

  • 両方が(最初のロケーションにある)共通のロケーションを共有する 2 つのアプリケーション デプロイ。
  • データセットはパーティション分割されていないため、各アプリケーションはデプロイの全データにアクセスできます。

非同期の一方向レプリケーション

このデプロイ パターンでは、1 つ以上のセカンダリ データベースにレプリケートされるプライマリ データベースがあります。セカンダリ データベースは読み取りアクセスに使用できます。このパターンの例は、特定のユースケースに最適なデータベースがプライマリ データベースとして使用され、セカンダリ データベースが分析に使用される場合です。次の図は、一方向レプリケーション データベースにアクセスする 2 つのアプリケーションを示しています。

非同期の一方向レプリケーション

前の図に示すように、2 つのデータベースの一方はもう一方のレプリカです。図の矢印は、レプリケーションの方向を示します。ロケーション 1 のデータベース システムからのデータは、ロケーション 2 のデータベース システムにレプリケーションされます。

競合解決による双方向レプリケーション

このデプロイ パターンには、相互に非同期でレプリケーションされる 2 つのプライマリ データベースがあります。同じデータが各データベースに同時に書き込まれた場合(たとえば、同じ主キー)、書き込み / 書き込みの競合を引き起こす可能性があります。このリスクのため、レプリケーション中にどの状態が最後の状態かを判断するために、競合解決を設ける必要があります。このパターンは、書き込みと書き込みの競合が発生する機会が稀な状況で使用できます。次の図は、双方向レプリケーション データベースにアクセスする 2 つのアプリケーションを示しています。

競合解決による双方向レプリケーション

上の図に示すように、各データベースは他のデータベースにレプリケーションされます。図に 2 つの別々の青い矢印で示されているように、2 つのレプリケーションは互いに独立しています。2 つのレプリケーションは独立しているため、偶然、同じデータアイテムが各アプリケーションによって変更され、同時にレプリケーションされた場合、競合が発生する可能性があります。この場合、競合解決が必要になります。

完全にアクティブ / アクティブな同期分散システム

このデプロイ パターンには、アクティブ - アクティブ(プライマリ - プライマリまたはマスター - マスター)の設定を持つ単一のデータベースがあります。アクティブ - アクティブ設定では、プライマリ データベースのデータの更新がトランザクションで整合性を持ち、同期的にレプリケートされます。このパターンのユースケースの例は、分散コンピューティングです。次の図は、完全に同期されたプライマリ - プライマリ データベースにアクセスする 2 つのアプリケーションを示しています。

完全なプライマリ / プライマリの同期が行われる分散データベース。

上の図が示すように、この配置により、各アプリケーションは、遅延や競合のリスクを生じることなく、最後に整合性が取れていた状態に常にアクセスできます。一方のデータベースでの変更は、直ちに他のデータベースで有効になります。トランザクションの変更が commit されると、変更が両方のデータベースに反映されます。

データベース システムの分類

このドキュメントで説明するデプロイ パターンで、すべてのデータベース管理システムを同じように良好な状態で使用できるわけではありません。ユースケースによっては、1 つデプロイ パターンを実装することのみが可能です。または、データベース システムのサブセットをデプロイ パターンの組み合わせで実装できる場合もあります。

次のセクションでは、さまざまなデータベース システムを分類し、4 つのデプロイ パターンにマッピングします。

データモデル、内部アーキテクチャ、デプロイモデル、トランザクション タイプなど、さまざまな分割項目でデータベースを分類できます。次のセクションでは、マルチクラウド データベース管理を目的として 2 つの分割項目を使用します。

  • デプロイ アーキテクチャ。データベース管理システムがクラウドのリソース(例: コンピューティング エンジン、クラウドマネージド サービス)にデプロイされる方法についてのアーキテクチャ。
  • 分散モデル。データベース システムがサポートする分散のモデル(例: 単一インスタンスまたは完全に分散)。

この 2 つの区分は、マルチクラウドのユースケースで最も関連性が高いものであり、マルチクラウド データベースのユースケースから派生した 4 つのデプロイ パターンをサポートできます。一般的な分類は、データベース管理システムでサポートされるデータモデルに基づいています。一部のシステムでは 1 つのモデル(グラフモデルなど)のみがサポートされています。他のシステムでは複数のデータモデルを同時にサポートしています(たとえば、リレーショナル モデルとドキュメント モデル)。ただし、マルチクラウド データベースのコンテキストでは、マルチクラウド アプリケーションでマルチクラウド デプロイに任意のデータモデルを使用できるため、この分類は関係ありません。

デプロイ アーキテクチャ別のデータベース システム

マルチクラウド データベース管理には、データベース管理システム用の次の 4 つの主要なデプロイ アーキテクチャが存在します。

  • 組み込みのクラウド データベース。組み込みクラウド データベースは、クラウド テクノロジーで動作するように設計、構築、最適化されています。たとえば、一部のデータベース システムでは、実装プラットフォームとして Kubernetes を使用し、Kubernetes の機能を使用しています。この種のデータベースとしては、CockroachDBYugaByte などがあります。これらは、Kubernetes をサポートしている任意のクラウドにデプロイできます。
  • クラウド プロバイダが管理するデータベースクラウド プロバイダが管理するデータベースは、クラウド プロバイダ独自のテクノロジーに構築されている、特定のクラウド プロバイダが管理するデータベース サービスです。Cloud SpannerCloud Bigtable がこの種のデータベースの例です。クラウド プロバイダが管理するデータベースは、クラウド プロバイダのクラウドでのみ使用でき、他の場所でインストールして実行できません。
  • クラウド以前のデータベース。クラウド以前のデータベースは、クラウド テクノロジーの開発前(場合によっては長期間)に存在していました。通常はベアメタル ハードウェアと仮想マシン(VM)で実行されます。PostgreSQLMySQL が、この種のデータベースの例です。こうしたシステムは、必要な仮想マシンやベアメタル ハードウェアをサポートするクラウド上で実行できます。
  • クラウド パートナーが管理するデータベース。一部のパブリック クラウドには、パブリック クラウドにお客様のデータベースをインストールして管理するデータベース パートナーがいます。このため、お客様がこれらのデータベースを自分で管理する必要はありません。このようなデータベースとしては、MongoDB AtlasMariaDB などがあります。

主要カテゴリにはいくつかのバリエーションがあります。たとえば、クラウド用に構築されたデータベースを実装するデータベース ベンダーは、クラウド用に構築されたテクノロジーでのインストールと、ベンダーが提供するクラウドでの顧客に対するマネージド サービスも提供できます。このアプローチは、ベンダーが単一のサービスとして自社のデータベースのみをサポートするパブリック クラウドを提供している場合と同等です。

クラウド以前のデータベースもコンテナに存在し、Kubernetes クラスタにデプロイできる可能性があります。ただし、これらのデータベースではスケーリング、マルチサービス、マルチ Pod デプロイなどの Kubernetes 固有の機能は使用されません。

データベース ベンダーは、同時に複数のパブリック クラウド プロバイダと提携し、複数のパブリック クラウドでクラウド パートナーが管理するデータベースとしてデータベースを提供できます。

分散モデル別のデータベース システム

データベース アーキテクチャのディストリビューション モデルに応じて、さまざまなデータベース管理システムが実装されます。データベースのモデルは次のとおりです。

  • 単一インスタンス。単一のデータベース インスタンスは 1 つの VM または 1 つのコンテナ上で実行され、一元化されたシステムとして機能します。このシステムはすべてのデータベース アクセスを管理します。単一インスタンスは他のインスタンスに接続できないため、データベース システムはレプリケーションをサポートしていません。
  • 複数インスタンスのアクティブ / パッシブこの共通アーキテクチャでは、複数のデータベース インスタンスが一緒にリンクされています。最も一般的なリンクはアクティブ / パッシブ関係です。ここで、1 つのインスタンスは、インスタンスおよび書き込みと読み取りの両方をサポートするアクティブなデータベース インスタンスです。1 つ以上のパッシブ システムは読み取り専用で、プライマリから同期または非同期のいずれかでデータベースのすべての変更を受け取ります。パッシブ システムは読み取りアクセス権を提供できます。アクティブ / パッシブは、プライマリ / セカンダリまたはマスター / スレーブとも呼ばれます。
  • 複数インスタンスがアクティブ / アクティブ。この比較的一般的でないアーキテクチャでは、各インスタンスがアクティブ インスタンスです。この場合、各インスタンスはトランザクションの読み取りと書き込み、データの整合性の確保を実行できます。そのため、データの不整合を防ぐため、すべてのインスタンスが常に同期されます。
  • 競合解決による複数インスタンスのアクティブ / アクティブ。これも比較的一般的でないシステムです。各インスタンスは書き込みアクセスと読み取りアクセスに使用できますが、データベースは非同期モードで同期されます。同じデータ項目を同時に更新できるため、整合性のない状態が生じます。競合解決ポリシーでは、どの状態が最後に一貫した状態であったかを判断する必要があります。
  • 複数インスタンス シャーディング。シャーディングは、(結合されていない)データ パーティションの管理に基づいて行われます。各データベース インスタンスが各パーティションを管理します。シャードは時間の経過とともに動的に追加できるため、この分散はスケーラブルです。ただし、クロスシャード クエリはすべてのシステムでサポートされているわけではないため、不可能な場合があります。

このセクションで説明するすべての分散モデルはシャーディングをサポートしており、シャーディング システムにできます。ただし、すべてのシステムがシャーディング オプションを提供するように設計されているわけではありません。シャーディングはスケーラビリティのコンセプトであり、通常はマルチクラウド環境におけるアーキテクチャ データベースの選択とは関係ありません。

分散モデルは、クラウド データベースとパートナー管理データベースで異なります。これらのデータベースはクラウド プロバイダのアーキテクチャに関連付けられているため、これらのシステムは次のデプロイ ロケーションに基づいてアーキテクチャを実装します。

  • ゾーンシステム。ゾーン マネージド データベース システムはゾーンに関連付けられています。ゾーンが利用可能な場合、データベース システムも使用できます。ただし、ゾーンが利用不可能になれば、データベースにアクセスできなくなります。
  • リージョン システム。リージョン マネージド データベースはリージョンに関連付けられ、1 つ以上のゾーンがアクセス可能な場合にアクセスできます。ゾーンの組み合わせによっては、アクセス不能になる可能性があります。
  • クロスリージョン システム。クロスリージョン システムは 2 つ以上のリージョンに関連付けられ、1 つ以上のリージョンが使用可能な場合に適切に機能します。

企業が使用する予定のすべてのクラウドにデータベースをインストールできる場合は、クロスリージョン システムはクロスクラウド システムもサポートできます。

このセクションで説明するマネージド データベース アーキテクチャに代わる方法は他にもあります。リージョン システムは、2 つのゾーン間でディスクを共有する場合があります。2 つのゾーンのいずれかがアクセス不能になった場合、データベース システムは残りのゾーンで続行できます。ただし、停止が両方のゾーンに影響する場合、他のゾーンが完全にオンラインになっても、データベース システムは使用できません。

データベース システムをデプロイ パターンにマッピングする

次の表に、このドキュメントで説明するデプロイ パターンとデプロイ アーキテクチャの関係を示します。このフィールドは、デプロイ パターンとデプロイ アーキテクチャに基づいて、組み合わせを可能にするために必要な条件を示しています。

デプロイ アーキテクチャ デプロイ パターン
クロス データベースの依存関係が存在しない状態でのパーティション分割 非同期の一方向レプリケーション 競合解決による双方向レプリケーション 完全にアクティブ / アクティブな同期分散システム
組み込みのクラウド データベース データベース システムで使用されるクラウド テクノロジーが組み込まれているすべてのクラウドで可能です。

同じデータベースが使用できない場合は、異なるデータベース システムを使用できます。
レプリケーションを実施するクラウド データベース。 双方向レプリケーションを実施するクラウド データベース。 プライマリ / プライマリの同期を実施するクラウド データベース。
クラウド プロバイダが管理するデータベース クラウド システムはデータベース システムごとに異なる場合があります。 レプリカは、クラウド プロバイダが管理するデータベースである必要はありません(デプロイ パターンにおけるデータベース移行テクノロジーのロールを参照)。 データベースが双方向レプリケーションを実施する場合、クラウド間ではなくクラウド内のみ。 データベースがプライマリ / プライマリの同期を実施している場合は、クラウド間ではなくクラウド内のみ。
クラウド以前のデータベース データベース システムは、クラウドごとに同じ場合と異なる場合があります。 複数のクラウドにわたるレプリケーションが可能です。 データベース システムは、双方向レプリケーションと競合解決を実施します。 データベース システムは、プライマリ / プライマリの同期を実施します。
クラウド パートナーが管理するデータベース クラウド システムはデータベース システムごとに異なる場合があります。

パートナーが、必要なすべてのクラウドでマネージド データベース システムを提供している場合は、同じデータベースを使用できます。
レプリカは、クラウド プロバイダが管理するデータベースである必要はありません。

パートナーが、必要なすべてのクラウドでマネージド データベース システムを提供している場合は、同じデータベースを使用できます。
データベース システムは、双方向レプリケーションと競合解決を実施します。 データベース システムは、プライマリ / プライマリの同期を実施します。

データベース システムが組み込みのレプリケーションを提供していない場合は、代わりにデータベース レプリケーション テクノロジーを使用できる場合があります。詳細については、デプロイ パターンにおけるデータベース移行テクノロジーのロールをご覧ください。

次の表に、デプロイ パターンとディストリビューション モデルの関係を示します。フィールドには、組み合わせ可能な特定のデプロイ パターンと分散モデルについての条件を規定します。

分散モデル デプロイ パターン
クロス データベースの依存関係が存在しない状態でのパーティション分割 非同期の一方向レプリケーション 競合解決による双方向レプリケーション 完全にアクティブ / アクティブな同期分散システム
単一インスタンス 関連するクラウドの同じまたは異なるデータベース システムで可能です。 該当なし 該当なし 該当なし


複数インスタンスのアクティブ / パッシブ
関連するクラウドの同じまたは異なるデータベース システムで可能です。 レプリケーションは複数のクラウド間で可能です。 レプリケーションは複数のクラウド間で可能です。 該当なし


複数インスタンスがアクティブ / アクティブ
関連するクラウドの同じまたは異なるデータベース システムで可能です。 該当なし 該当なし クラウド間で同期が可能です。


競合解決による複数インスタンスのアクティブ / アクティブ
関連するクラウドの同じまたは異なるデータベース システムで可能です。 該当なし 該当なし クラウド間で双方向レプリケーションが可能な場合に該当します。

基盤となるデータベース テクノロジーに基づいて抽象化を追加する分散モデルの実装には、アクティブ - アクティブ システムである Postgres-BDR などの分散モデルが含まれていない場合があります。そのようなシステムは、上記の表の該当するカテゴリに含まれています。マルチクラウドの観点からは、分散モデルの実装方法は関係ありません。

データベースの移行とレプリケーション

ユースケースによっては、企業はデータベースをあるデプロイ ロケーションから別のところに移行する必要がある場合があります。代わりに、ダウンストリーム処理では、データベースのデータを別のロケーションにレプリケーションする必要がある場合があります。次のセクションでは、データベースの移行とデータベースのレプリケーションを詳しく説明します。

データベースの移行

データベースの移行は、データベースが 1 つのデプロイ ロケーションから別のロケーションに移動される場合に使用されます。たとえば、オンプレミスのデータセンターで実行されているデータベースは、クラウドで実行されるように移行されます。移行が完了すると、オンプレミス データセンターでデータベースがシャットダウンされます。

データベースを移行する主なアプローチは次のとおりです。

  • リフト&シフト。データベース インスタンスを実行している VM とディスクは、そのまま移行先の環境にコピーされます。コピーされた後、起動され、移行が完了します。
  • エクスポートとインポート、バックアップと復元。どちらの方法も、データベース システム機能を使用してデータベースを外部化し、ターゲット ロケーションで再作成します。通常、エクスポート/インポートは ASCII 形式に基づきますが、バックアップと復元はバイナリ形式に基づきます。
  • ゼロ ダウンタイムでの移行。このアプローチでは、アプリケーション システムが移行元システムにアクセスしている間にデータベースが移行されます。初期読み込み後、変更データ キャプチャ(CDC)テクノロジーを使用して、移行元から移行先データベースに変更が送信されます。アプリケーションは、移行元データベース システムで停止してから、移行の完了後に移行先データベースで再起動するまでの間、ダウンタイムが発生します。

データベースの移行は、データベースがあるクラウドから別のクラウドに、またはある種類のデータベース エンジンから別の種類のデータベース エンジンに移行される場合に関連します。

データベースの移行は複数ファセット プロセスです。詳細については、データベースの移行: コンセプトと原則(パート 1)データベースの移行: コンセプトと原則(パート 2)をご覧ください。

組み込みデータベース テクノロジーを使用して、データベースの移行を行うことができます(たとえば、エクスポート / インポート、バックアップ / 復元、組み込みのレプリケーション プロトコル)。移行元システムと移行先システムが異なるデータベース システムである場合は、移行テクノロジーがデータベース移行に最適なオプションです。StriimDebezium は両方とも、データベース移行テクノロジーの例です。

データベース レプリケーション

データベース レプリケーションは、データベースの移行と似ています。ただし、データベースのレプリケーション中は、すべての変更がターゲット データベースに送信される間、ソース データベース システムは維持されます。

データベース レプリケーションは、移行元データベースから移行先データベースに変更を送信する継続的なプロセスです。このプロセスが非同期の場合、変更は少し遅れて移行先データベースに到達します。プロセスが同期の場合、移行元システムへの変更は、移行先システムに対して同時に、同じトランザクションに対して行われます。

ソース データベースからターゲット データベースにレプリケーションする以外に、ソース データベースからターゲット分析システムにデータを複製することが頻繁にあります。

データベース移行と同様に、レプリケーション プロトコルが組み込まれている場合は、組み込みデータベース テクノロジーをデータベース レプリケーションに使用できます。組み込みのレプリケーション プロトコルがない場合は、StriimDebezium などのレプリケーション テクノロジーを使用できます。

デプロイ パターンにおけるデータベース移行テクノロジーのロール

非同期(異種)レプリケーションなど、異なるデータベース システムがデプロイ パターンで使用されている場合、レプリケーションを可能にする組み込みデータベース テクノロジーは通常利用できません。代わりに、データベース移行テクノロジーをデプロイして、この種のレプリケーションを有効にできます。これらの移行システムの一部は、双方向レプリケーションも実装します。

データベース移行またはレプリケーション テクノロジーが、データベース システムをデプロイメント パターンにマッピングするの表 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 です。評価プロセスで許容される場合は、これらのシステムを評価することをおすすめします。

次のステップ