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

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

データベースにアクセスするマルチクラウド アプリケーション アーキテクチャは、ユースケースによって異なります。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 つのリージョンにデプロイし、いつでも実行できる状態にしておく必要があります。本番環境では、アプリケーションはプライマリ リージョンで実行されます。ただし、停止した場合、セカンダリ リージョンがプライマリ リージョンになります。障害復旧の準備状況のさまざまなモデルを以下に示します。

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

上記のリストで説明した即応能力のあるモデルは、データベースの観点では次のデータベース アプローチに対応しています。

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

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

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

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

クラウド バースト機能

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

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

データベース サポートでは、次のオプションが利用できます。

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

クラウド バースト機能は、オンプレミスのデータセンターの容量を増やすために、ハイブリッド クラウドでよく使用されます。これは、データが国内に存在する必要がある場合に、パブリック クラウド間で使用できるアプローチでもあります。パブリック クラウドに属するリージョンが 1 つの国に 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 が、この種のデータベースの例です。

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

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

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

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

データベースのアーキテクチャの分散モデルに応じて、さまざまなデータベース管理システムが実装されます。データベースのモデルには、次のようなものがあります。

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

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

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

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

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

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

データベース システムのデプロイ パターンへのマッピング

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

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

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

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

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

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

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

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


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


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


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

基盤となるデータベース テクノロジーに基づいて抽象化を追加する分散モデルの実装には、Postgres-BDR アクティブ - アクティブ システムのように、分散モデルが組み込まれたものは含まれていません。このようなシステムは、前の表にそれぞれのカテゴリで記載されています。マルチクラウドの観点では、分散モデルの実装方法とは無関係です。

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

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

データベースの移行

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

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

  • リフト&シフトデータベース インスタンスを実行している 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です。評価プロセスで許可されている場合は、これらのシステムを評価することをおすすめします。

次のステップ