Striim を使用したデータベースの移行とレプリケーションの設計

このドキュメントでは、Striim を使用してデータベースの移行とレプリケーションを設計する方法について説明します。このドキュメントでは、データベースの移行と継続的なレプリケーションに関係するアーキテクチャのコンセプトについて説明します。このドキュメントは、データベース アーキテクトやデータベース エンジニア、および Google Cloud にデータソースを移行または複製するデータ所有者を対象としています。

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

多くの企業は、クラウドベースのサービスと技術を使用してビジネス アプリケーションを構築することで、クラウド ファースト アプリケーション戦略を進めています。企業は、サービスに対する市場投入までの時間を短縮し、お客様の需要や市場状況の変化に迅速に対応できます。クラウドベースのコンピューティングをエンドツーエンドで利用するビジネス アプリケーションは、長期的なビジネス成長に不可欠な機能です。

レガシーのミッション クリティカルなアプリケーションのクラウドへの移行に際しては、アプリケーション階層の移行、基盤となるデータベースの移行、移行時にアプリケーションへのユーザー アクセスが中断されることなく維持されることなど、いくつかの課題があります。

ビジネス アプリケーション階層の移行に多数の移行プロダクトとサービスが利用できますが、ビジネス アプリケーションを提供する基盤データベースの移行は最も困難な作業になります。

データベースへのクラウド移行には実際上、いくつかのフォームがあります。次の図は、最も基本的なユースケースを示しています。オンプレミス データベースがクラウドベースのデータベース(この場合は Cloud Spanner)に移行されています。

ソースから Cloud Spanner への基本的な移行のアーキテクチャ

次の図は、複数のデータベースの移行とアプリケーションのモダナイゼーションを行う、複雑なユースケースを示しています。

複数のソースデータベースとターゲットデータベースが関わる、データベース移行システムを使用した複雑な移行のアーキテクチャ

この設定では、2 つのソース データベースが 2 つのターゲット データベースに移行されます。ソース データベースの 1 つに、モダナイズされたフォームの対応するターゲット データベース(Google Kubernetes Engine に実装済み)にアクセスするアプリケーションからアクセスが行われます。2 つ目のソース データベースにはクライアントもあります(上の図に表示されていません)。

データベース移行システムは Google Cloud にインストールされますが、移行システムは他の場所にインストールすることもできます。たとえば、セキュリティ上の理由から、移行システムはソース データベースと同じ場所で実行される要があります。

リフト&シフト移行とオンライン データベース移行

高いレベルでは、データベース移行の 2 つの方法として、リフト&シフトとオンライン移行があります。

リフト&シフト移行の通常の処理では、ソース データベースをエクスポートまたはバックアップし、そのファイルをクラウドに移行してから、ファイルをクラウドで実行中のターゲット データベース インスタンスにインポートして復元します。新しいターゲット データベースの準備が整うと、ビジネス アプリケーションがクラウドで実行され、データにアクセスします。

リフト&シフト アプローチのデメリットは、ビジネス アプリケーションとデータベースの両方にダウンタイムが必要になることです。このアプローチでは、移行はアクティビティが少ない時間帯に慎重に計画する必要があります。このアプローチではまた、移行中にビジネス アプリケーションを停止してデータベースがクラウドに復元された後に再起動する操作が可能と想定されています。データベースの復元後にアプリケーションのテストを行うことも、ダウンタイムの増加につながります。さらに、リフト&シフト アプローチは、保護、移動、保存、最終的な削除の対象となるデータベースの中間コピーを作成します。これにより、コスト管理が複雑になります。リフト&シフト アプローチは一部のアプリケーションでは有効ですが、ほとんどのビジネス クリティカルなアプリケーションの要件からはこれらのコストは容認されません。このような理由から、オンライン データベース移行の方がはるかに効率的です。

オンライン移行アプローチは、データベースのパフォーマンスへの影響とビジネス アプリケーションのユーザーへの影響を最小限に抑えることを目的としています。オンライン アプローチでは、データベースをクラウドに移行して、ソースとターゲットの両方のデータベースを数か月間、または数年間も同期させたまま、新しいクラウドベースのビジネス アプリケーションの最適化とテストを行います。

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

クラウドへのデータベース移行では、クラウドデータベースが本番環境インスタンスになるため、移行が完了するとソース データベースは廃止されます。

一部のユースケースでは、Google Cloud でダウンストリーム処理が行われている間、元のデータベース インスタンスが引き続き実行されることがあります。この場合、Google Cloud にソース データベースが複製されます。たとえば、Google Cloud に移行できない技術に依存するデータベースにアクセスするアプリケーションを利用している場合が該当します。同時に、Google Cloud 技術は、分析などの機能(BigQuery へのレプリケーションなど)を目的に使用されます。もう 1 つの例は、個人を特定できる情報(PII)を含むデータベースをオンプレミス環境内に配置し、難読化された PII 情報を使用する下流の処理を Google Cloud で行うことです。

これらのユースケースでは、元のデータベースを Spanner や BigQuery などの運用ターゲットや分析ターゲットに継続的に複製する必要があります。データベースの移行時にソース データベースはシャットダウンされません。

異種データベースのオンライン データベースの移行とレプリケーションは通常、さまざまなサービスのコーディングや統合を伴う、数か月から数年の複雑な作業となります。Striim などのデータベース移行と統合システムを使用すると、オンライン データベースの移行がより簡単かつ効率的になります。

次の図に、Striim によるデータ統合とインテリジェンス プラットフォームの基本デプロイ アーキテクチャ(ソースとターゲットのデータベースがそれぞれ 1 つ)を示します。

Striim を使用した基本的な移行のアーキテクチャ

Striim を使用したデータベースの移行とレプリケーション

データベース移行技術を提供する Google の技術パートナーの Striim は、ドラッグ&ドロップ インターフェースを使用した異種データベース間のデータ移動の設定により、オンライン移行を簡略化しています。このような Google Cloud への移行に際して、Striim は、利用者に負担をかけないストリーミング抽出、変換、読み込み(ETL)プラットフォームを提供します。これにより、他のソリューションよりも迅速にデプロイでき、反復処理も容易です。

利用者に負担をかけない変更データ キャプチャ(CDC)により、Striim はソース トランザクション データベースを遅くすることなくリアルタイム データを抽出し、これによりダウンタイムがなく、リスクも最小限に抑えたクラウドへのデータベース 移行が実現します。データの処理中に Striim は、包括的なストリーミング分析エンジンを使用して SQL クエリを通じて、データのフィルタリング、変換、集計、拡張を実施できます。

Striim は、オンプレミスと Google Cloud データベース間でデータを継続的にレプリケートすることで、ミッション クリティカルなアプリケーションがダウンタイムなしで実行し続けるオンライン レプリケーションをサポートします。Striim は、組み込みの継続的デリバリー検証、高可用性、フェイルオーバーを使用して、データ損失のリスクを最小限に抑えています。

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

オンライン データベースの移行と継続的なレプリケーションは、さまざまな業界固有の課題や技術的課題(業界に依存しない)に適用できます。たとえば、業界固有の用途として、クラウド データサービスとリアルタイム データを活用する金融サービスがあります。技術面をより重視したユースケースとして、レポート データベースの移行や運用データベースの段階的な移行などが考えられます。Striim は、適切なタイミングで適切な形式でデータを配信する継続的なデータ パイプラインを提供することで、これらのユースケースを可能にします。

このセクションでは、業界固有のユースケースと 2 つの技術的なユースケースで、Striim を使用してデータベースを移行する方法について説明します。

金融技術

金融技術(fintech)企業は、迅速かつ正確なデータを必要としています。たとえば、銀行の口座保有者は、口座に記録された取引や新しい残高をすぐに確認したいと思っています。借り手と貸し手は、ローン開始までの時間を節約したいと考えています。フィンテック企業は、Striim を使用して次のようなビジネス要件に対応できます。

ローン契約を迅速化する、自動化された従業員と収入確認サービスを見てみましょう。このユースケースでは、Striim はさまざまなオンプレミス ソースからのリアルタイム データを Google Cloud に統合します。この自動化により、雇用状況検証プロセスの遅れが改善します。次の図に、このユースケースのアーキテクチャを示します。

Striim を使用して Google Cloud にデータをストリーミングするフィンテックのユースケース

このアーキテクチャは、Striim のリアルタイム ストリーミング データ統合を利用しています。Striim は、さまざまな外部ソースや内部ソース(ADP などのプロセッサからの給与支払データ、他のプロバイダからの従業員データやユーザー属性データなど)を継続的に収集します。Striim は、さまざまな Google Cloud サービスにデータをフィードします。Striim は、該当する場合はOracle® GoldenGate トレイル ファイルにアクセスしてログベースの CDC によりリレーショナル データベースからデータを継続的に取得し、さらにフラット ファイルからも取得します。Striim は、集計および変換されたデータを Cloud Storage に継続的に配信して、クラウド 向けビジネス アプリケーションやサービスを駆動します。

レポートのオフロード

一部の技術的ユースケースでは、トランザクション ワークロードと分析ワークロードが区別されます。トランザクション データベースで分析クエリを実行すると、ソース トランザクション データベースのパフォーマンス ヒット数が増え、分析クエリを返す際のレイテンシが高くなるため、この処理は意味がありません。

この区別に対処するため、トランザクション データのサブセットを Google Cloud に継続的に配信し、BigQuery でさらに分析とレポート作成する方法があります。次の図に、アーキテクチャの例を示します。

トランザクション データベースと分析データベースにワークロードを分割するアーキテクチャ

ストリーミング データ パイプラインのデータを変換して正規化する機能により、Striim はソース トランザクション データの一部を選択して分析プラットフォームに統合し、残りのデータを Google Cloud データ ターゲットに継続的に移行します。

段階的な移行

大規模な企業には、数年分の貴重なデータを保持する大規模なオンプレミス データベースがあります。これらのデータベースをクラウドに移行する作業は、何年もかかることがあります。BigQuery、Cloud Spanner、Pub/Sub などの新しいクラウド データベース 技術から得られるはずの機会の損失も、レガシー データベースの維持に伴うコストになります。

レガシー システムの維持と最新のクラウド データベーステクノロジーの活用との間のバランスを見つけるため、段階的なアプローチで Striim を使用してデータのサブセットを Google Cloud データベースに移行し、本番環境のソース データベースを実行し続けることができます。開発者は、小さなサブセットから開始して、本番環境のオンプレミス データベースに影響を与えることなく、新しいクラウド データベースでアプリケーション層をテストすることもできます。

アプリケーション層の適合性が確認できたら、データベース全体の移行が完了するまで移行対象のサブセットを徐々に増やすことができます。この定期的な移行により、リスクを管理しながら最小限のダウンタイムで本番環境システムを移行できます。

デプロイ アーキテクチャ

このセクションのデプロイ アーキテクチャは、データベースの移行とレプリケーションのさまざまなユースケースで使われる、さまざまなデータベース、アプリケーション、クラウド サービスを示しています。

基本的なデプロイ アーキテクチャ

次の図に単純なデプロイ アーキテクチャを示します。ソース データベース システムがクラウドベースのデータベース システムである Cloud Spanner に移行されています。このアーキテクチャはこのドキュメント全体で使用され、継続的なレプリケーションと完全移行または段階的移行の両方で機能します。

Striim を使用した基本的な移行のアーキテクチャ

このアーキテクチャでは、ソース データベース システムはクラウドベースのデータベース システム(この場合は Cloud Spanner)に移行されます。データベース移行システムの Striim は両方のシステムに接続し、ソースからターゲット データベース システムにデータを移行します。

複雑さが中程度のデプロイ アーキテクチャ

次の図に、2 つのソース データベース システムを含むアーキテクチャを示します。このアーキテクチャは前のアーキテクチャよりも複雑で、データベースの移行とデータベースのレプリケーションに使用できます。

オンプレミス データベースとクラウドのソース データベースから、トランザクションと分析ターゲット データベースへの移行

この図は、2 つのソース データベース システムを含む初期アーキテクチャを示しています。1 つのソースは、パブリック クラウドで実行されている移行対象のデータベース システム(S1)です。2 番目のソースは、オンプレミスのデータセンターで稼働しているデータベース システム(S2)で、そのデータとその後の変更は分析のために BigQuery にレプリケートされます。2 つのターゲットデータベース システムがデプロイされます。S1 からデータを受信する Cloud Spanner(移行)と S2 からデータの連続ストリームを受信する BigQuery です。

次の図は、データベースの移行が完了した後のデプロイ アーキテクチャを表しています。S1 が終了し、対応する Cloud Spanner ターゲットは Striim に接続されなくなりました。

トランザクション データベースが Striim から切断される、移行完了後のアーキテクチャ

このシナリオは、デプロイ アーキテクチャが必ずしも静的ではないことを示しています。1 回限りのデータベース移行などの一部のユースケースでは、移行が完了するまで、移行システムをシステムまたはサービスに接続する必要があります。データベース レプリケーションなど、他のユースケースはより静的です。このアーキテクチャは、1 つのアーキテクチャが複数のユースケースを処理する方法を示しています。

複雑なデプロイ アーキテクチャ

このセクションでは、フォールバックとして設計された移行について説明します。移行後に発生したエラーによりソースでの処理に戻る必要がある場合、フォールバックが必要になることがあります。フォールバックを設定し移行が元に戻されると、ターゲットでの変更が移行元に伝達されます。

このデプロイ アーキテクチャはレプリケーションと移行を必要とし、このドキュメントで説明している 3 つのアーキテクチャの中で最も複雑なものです。

このアーキテクチャはまた、クラスタ化された環境で Striim がどのように動作してスループットの向上をサポートできるかを示しています。次のアーキテクチャのクラスタは、十分な容量を提供するため 3 つの Compute Engine インスタンスで構成されています。Compute Engine の各インスタンスは異なるゾーンに配置され、ゾーンやインスタンスの障害からの保護を目的とした高可用性を提供します。

この場合、オンプレミスのデータセンターにある 2 つのソース データベースがクラウドにレプリケートされます。1 つのデータベースは Cloud Spanner に、もう 1 つは BigQuery にレプリケートされます。また、移行によって、パブリック クラウドのデータベースから Cloud SQL インスタンスにデータが移動します。

次の図に、移行が完了する前のデプロイ アーキテクチャを示します。

Striim 移行システムを使用した、複数のソース データベースとターゲット データベースのアーキテクチャ

3 つのソース データベースが Striim に接続され、Striim は 3 つのターゲットデータベースにデータを移行しレプリケートします。オンプレミス データセンターの 2 つのソース データベースは、BigQuery と Cloud Spanner にレプリケートされ、クラウド内のソース データベースが Cloud SQL に移行されます。

移行が完了すると、フォールバックを設定できるよう、Cloud SQL からクラウド データベースにフローが逆行します。ターゲットに加えた変更をソースでも使用できるようにするには、ソースの移行後に逆移行を設定する必要があります。

次の図に、可能性としてのフォールバックのために行う構成の変更を示します。

Striim 移行システムを使用したソース データベースへのフォールバックのアーキテクチャ

データフローの方向は、元のソース データベースと Cloud SQL 間で逆になります。移行が完了し、フォールバックの必要もないと判断されると、移行に関連するシステム(Cloud SQL とオンプレミス データセンターのソース データベースを含む)は切断されます。

次の図は、このデプロイ アーキテクチャが継続的なレプリケーションのユースケースをサポートする仕組みを示しています。

Striim を使用して、2 つのオンプレミス ソース データベースから複数のターゲットに継続的なレプリケーションを行うアーキテクチャ

オンプレミス データセンター内の 2 つのソース データベースは、BigQuery と Cloud Spanner に継続的にレプリケートされます。

以上の説明のように、このデプロイ アーキテクチャは複雑さに関係なくさまざまなユースケースをサポートできます。この構成は、データ移動の方向が逆になった場合などに応じて、動的に変更することもできます。

このアーキテクチャは、負荷の増加や急増に対応できるよう拡張することも可能です。

デプロイ アーキテクチャの複雑さに対する移行仕様

前述のアーキテクチャでは、次の 2 つの側面が複雑さの原因になっています。

  • Striim に接続されているデータベース システムの数
  • ユースケースが完了してからの、デプロイ アーキテクチャの変更

デプロイ アーキテクチャとは関係なく、移行の仕様自体で複雑さを考慮することもできます。

たとえば、オンプレミスの MySQL データベースをクラウドの MySQL データベースに移行する場合、スキーマとデータが同一であれば仕様はコピーとなるため、移行仕様は加工を要しません。ただし、Oracle データベースから Cloud Spanner データベースに移行する場合、ソーススキーマとターゲット スキーマは異なり、移行中にデータを変換する必要があるため、移行の複雑さが大幅に増加します。

次の表に、移行仕様の複雑さを判断する大まかなアプローチを示します。移行やレプリケーションの複雑さとともに機能も記されています。[ユースケース]列を使用して要件を評価できます。

機能 似ている 異なる ユースケース
ソースとターゲット データベースのシステム 複雑さ小 複雑さ大
ソースとターゲット データベースのスキーマ 複雑さ小 複雑さ大
ソースとターゲット データベースのデータ 複雑さ小 複雑さ大
データ パーティショニング(存在する場合) 複雑さ小 複雑さ大
データの分離または統合 複雑さ大 複雑さ大

移行の複雑さは、実装されるユースケースに基づいた範囲を持つ指標です。ユースケースの機能ごとの複雑さ小と複雑さ大の比率に基づいて、ユースケースの全体的な複雑さを決定できます。

高度なユースケースでは特に、複雑さを決めるのに他の事項も考慮の対象になります。例:

  • 複数のソース データベースが 1 つのターゲット データベースに統合されますか?
  • 複数のソース データベースからのデータが、再シャーディングや再パーティショニングなど、一連のターゲット データベースに再配分されますか。
  • ターゲット システムで適切に整理されたデータセットを提供するため、移行中にデータを拡充したり短縮しますか。

ユースケースに機能を追加するごとに複雑さが増します(Striimなどのシステムはその機能をサポートするよう構成される)。

次のステップ