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

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

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

多くの企業は、クラウドベースのサービスとテクノロジーを利用してビジネス アプリケーションを構築することで、クラウド ファーストのアプリケーション戦略を採用しています。企業は、サービスの製品化までの時間を短縮し、お客様の需要や市場の変化の変化に迅速に対応して競争力を高めています。エンドツーエンドのクラウドベースのコンピューティングを最大限に活用するビジネス アプリケーションは、長期的なビジネスの成長に不可欠です。

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

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

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

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

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

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

この構成では、2 つのソース データベースが 2 つのターゲット データベースに移行されます。ソース データベースの 1 つには、対応するターゲット データベースにアクセスするアプリケーションから最新の方式(Google Kubernetes Engine に実装されています)でアクセスされます。クライアントは、もう一方のソース データベースにもあります(上図には示されていません)。

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

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

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

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

リフト & シフト方式のデメリットは、ビジネス アプリケーションとデータベースの両方でダウンタイムが必要になることです。この方式では、慎重に計画し、アクティビティの低い時間帯に移行を行う必要があります。また、移行中は、ビジネス アプリケーションを停止でき、データベースがクラウドに復元された後に再起動されることを前提としています。データベースの復元後にアプリケーションのテストを行う場合は、ダウンタイムが長くなります。さらに、リフト&シフト方式では、データベースの中間コピーが作成され、これに対するセキュリティの確保、移動、保存、最終的には削除を行う必要があります。これにより、コストと管理がより複雑になります。リフト&シフト方式は特定のアプリケーションには適していますが、ビジネス クリティカルなアプリケーションの要件では、こうしたコストを許容できません。これらの理由から、オンライン データベース移行ははるかに優れた方式です。

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

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

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

ユースケースによっては、元のデータベース インスタンスが Google Cloud でダウンストリーム処理されている間も実行され続ける場合があります。この場合、ソース データベースは Google Cloud に複製されます。たとえば、Google Cloud に移行できないテクノロジーに依存するデータベースにアクセスするアプリケーションがあるとします。同時に、BigQuery へのレプリケーションなど、Google Cloud テクノロジーが分析などの機能にも使用されています。別の例として、個人情報(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 を使用してデータベースを移行する方法について説明します。

金融テクノロジー

金融テクノロジー(フィンテック)企業には、高速で正確なデータが必要です。たとえば、バンキングのお客様は、自分のアカウントで取引内容と新しい残高がすぐに確認できることを望みます。借り手も貸し手も、ローン設定時にかかる時間を節約したいと考えています。フィンテック企業は、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などのシステムはその機能をサポートするよう構成される)。

次のステップ