移行の概要

このドキュメントでは、データベースを Spanner に移行するプロセスについて説明します。移行元のデータベースやその他の要因に応じて、移行のステージと、各ステージで推奨されるツールについて説明します。推奨ツールには、Google Cloud プロダクトやサードパーティの商用ツールとオープンソース ツールが含まれます。これらのツールを組み合わせて移行を加速し、リスクを軽減できます。

Spanner の移行には、次のコアステージが含まれます。

  1. 移行の複雑さを評価します。
  2. スキーマを移行します。
  3. アプリケーションを移行します。
  4. パフォーマンスをテストして調整します。
  5. データを移行します。
  6. 移行を検証します。
  7. カットオーバーとフェイルオーバーのメカニズムを構成する

次の図は、このプロセスを示しています。

評価、スキーマとアプリケーションの移行、テストとチューニング、データ移行、検証、カットオーバーを示す移行プロセスの図

これらのステージでは、データベース ソースとサイズ、ダウンタイム要件、アプリケーション コードの複雑さ、シャーディング スキーマ、カスタム関数または変換、フェイルオーバーとレプリケーション戦略などの要素によって、移行計画が大きく異なる場合があります。

Amazon DynamoDB、MySQL、Oracle Database、PostgreSQL 用の移行ガイドが用意されています。これらのデータベースのいずれかから移行する場合は、関連するガイドもご覧ください。

別のデータベースから移行する場合は、このガイドで説明していないカスタマイズやツールが必要になる場合があります。

移行ツール

ソース データベースやその他の要因に応じて、移行のさまざまな段階を支援する次のツールを使用することをおすすめします。一部のツールは特定のソース データベースのみをサポートします。プロセスの一部の手順では、ツールを利用できないため、それらの手順を手動で完了します。

  • Spanner 移行ツールは、基本的な評価と、スキーマとデータの移行を行うオープンソース ツールです。
  • データ検証ツール（DVT）は、Google が構築した、オープンソースのコミュニティにサポートされている標準のデータ検証方法です。DVT を既存の Google Cloud プロダクトに統合できます。
  • Datastream は、ソース データベースから変更データ キャプチャ（CDC）イベントとバルクデータを読み取ることができる Google Cloud サービスです。
  • Dataflow は、大量のデータを Spanner にテンプレートでより効率的に書き込めるようにする Google Cloud サービスです。これらのテンプレートはダンプファイルを生成しません。ダンプファイルは、ソース データベース ツールまたはサードパーティ ツールで生成される必要があります。

次の表に、一般的なソース データベースの移行の各段階で推奨する主なツールを示します。カスタマイズにより、他のデータベースから移行できます。

ソース データベース 対象範囲を評価する スキーマを移行する アプリを移行する データを移行する データの移行を検証 カットオーバーとフェイルオーバーの構成
MySQL 手動 Spanner 移行ツール 手動 Spanner 移行ツール DVT 手動
PostgreSQL 手動 Spanner 移行ツール 手動 Spanner 移行ツール DVT 手動
その他のデータベース 手動 Spanner 移行ツール 手動 手動 DVT 手動

移行の複雑さを評価する

移行の範囲と複雑さを評価し、アプローチを計画するには、次のような移行元データベースに関するデータを収集する必要があります。

  • クエリパターン
  • ストアド プロシージャやトリガーなどのデータベース機能に依存するアプリケーション ロジックの量
  • ハードウェア要件
  • 総所有コスト（TCO）

スキーマを移行する

スキーマを Spanner スキーマに移行する前に、スキーマ間の互換性を評価し、Spanner のスキーマを最適化します。たとえば、キーの変更、インデックスの削除 / 追加、既存のテーブルの列の追加 / 削除を行います。Spanner 用にスキーマを最適化するには、スキーマ設計のベスト プラクティスと推奨される主キーの移行戦略をご覧ください。

Spanner 移行ツールは、Google の開発者が作成したオープンソースのコミュニティで維持するツールで、ソース データベース スキーマから Spanner スキーマを自動的に構築します。Spanner 移行ツールのスキーマ アシスタントを使用してスキーマをカスタマイズできます。

Spanner 移行ツールは、次のいずれかのロケーションからスキーマとデータを取り込みます。

  • ローカルの場所または Cloud Storage からのダンプファイル（MySQL、PostgreSQL、CSV）
  • ソース データベース（MySQL、PostgreSQL）から直接

Spanner 移行ツールは、スキーマの評価、推奨事項、移行のために次の機能を実行します。

  • データ型の互換性の評価と推奨事項
  • 主キーの編集と推奨事項
  • セカンダリ インデックスの編集と推奨事項
  • テーブルの編集と推奨事項のインターリーブ
  • 一般的な Spanner スキーマ設計の推奨事項
  • スキーマのバージョニング
  • 共同スキーマの変更

Spanner 移行ツールを使用したスキーマの移行の詳細については、Spanner 移行ツールの README.md ファイルをご覧ください。

データの移行にも、Spanner 移行ツールを使用します。

アプリケーションの移行

データベースを移行するには、さまざまなドライバとライブラリが必要であり、Spanner でサポートされていない機能の代替が必要です。同様の機能を実現し、Spanner の長所に合わせて最適化するには、コード、アプリケーション フロー、アーキテクチャの変更が必要になることがあります。

アプリケーションを Spanner に移行するために必要な変更は次のとおりです。

  • Spanner はデータベース レベルでのユーザーコードの実行をサポートしていないため、データベース レベルに保存されているプロシージャとトリガーをアプリケーションに移動する必要があります。
  • Spanner クライアント ライブラリとオブジェクト リレーショナル マッパー（ORM）を使用します。詳細については、API、クライアント ライブラリ、ORM ドライバの概要をご覧ください。
  • クエリを変換する必要がある場合は、手動で変換するか、他のサードパーティ製ツールを使用します。
  • パーティション化 DML、読み取り専用トランザクション、commit タイムスタンプ、読み取りタイムスタンプとその方法を確認するアプリケーションのパフォーマンスを最適化できます。

トランザクション処理の変更が必要になる場合もあります。これに対応するためのツールがないため、この手順は手動で完了する必要があります。以下の点にご注意ください。

  • commit あたりのミューテーションの上限は 40,000 です。テーブルの各セカンダリ インデックスは、行ごとに追加のミューテーションです。ミューテーションを使用してデータを変更するには、ミューテーションを使用してデータを挿入、更新、削除するをご覧ください。大量のデータを変更するには、パーティション化 DML を使用します。
  • Spanner のトランザクションがより分離されているため、トランザクションの分離レベルでは処理は不要です。
  • Spanner は線形化可能であるため、デフォルトで整合性とロックを処理します。

スキーマとアプリケーションのパフォーマンスをテストして調整する

パフォーマンスの調整は、データのサブセットに基づいて CPU 使用率やレイテンシなどの指標を評価し、パフォーマンスを向上させるためにスキーマとアプリケーションを調整して、再度テストする反復プロセスです。

たとえば、スキーマで、インデックスの追加や変更や主キーの変更を行うことができます。アプリケーションでは、バッチ書き込みや、クエリのマージや変更を行うことができます。

特に本番環境のトラフィックでは、パフォーマンスの調整が予期しない事態を避けるために重要です。パフォーマンス チューニングは、本番環境のトラフィック スループットとデータサイズに近い設定ほど効果的です。

スキーマとアプリケーションのパフォーマンスをテストして調整するには、次の操作を行います。

  1. データのサブセットを Spanner データベースにアップロードする。詳細については、データの移行をご覧ください。
  2. アプリケーションを Spanner に指定する。
  3. 基本的なフローをチェックして、正確性を検証します。
  4. アプリケーションの負荷テストを実行して、パフォーマンスが期待どおりであることを確認します。最もコストの高いクエリを特定して最適化するには、Query Insights でクエリのパフォーマンスの問題を検出するをご覧ください。特に、最適化されていないクエリのパフォーマンスに次の要因が寄与する可能性があります。
    1. 非効率的なクエリ: 効率的なクエリを作成する方法については、SQL のベスト プラクティスをご覧ください。
    2. 高 CPU 使用率: 詳細については、高 CPU 使用率の調査をご覧ください。
    3. ロック: トランザクションのロックが原因のボトルネックを減らすには、高レイテンシの原因となるトランザクションを特定するをご覧ください。
    4. 非効率的なスキーマ設計: スキーマが適切に設計されていない場合、クエリの最適化はあまり役に立ちません。
    5. ホットスポット: Spanner のホットスポットは、特に QPS が高いアプリケーションの場合、書き込みスループットを制限します。ホットスポットまたはアンチパターンを特定するには、Google Cloud コンソールから Key Visualizer の統計情報を確認します。ホットスポットの回避の詳細については、ホットスポットを防ぐための主キーの選択をご覧ください。
  5. スキーマまたはインデックスを変更する場合は、十分な結果が得られるまで、正確性とパフォーマンスのテストを繰り返します。

データベースのパフォーマンスの微調整の詳細については、Spanner サポートにお問い合わせください。

データを移行する

Spanner スキーマを最適化してアプリケーションを移行したら、本番環境サイズの空の Spanner データベースにデータを移動して、Spanner データベースに切り替えます。

ソース データベースによっては、最小限のダウンタイムでデータベースを移行できる場合や、長時間のダウンタイムが必要になる場合もあります。

最小限のダウンタイムでの移行と、長時間のダウンタイムでの移行の両方で、Dataflow と Spanner 移行ツールを使用することをおすすめします。

次の表に、サポートされているソース、形式、サイズ、スループットなど、最小限のダウンタイムでの移行と長時間のダウンタイムでの移行の違いを示します。

最小限のダウンタイムでの移行 ダウンタイムを伴う移行
サポート対象のソース MySQL、PostgreSQL CSV または Avro にエクスポートできるデータベース。
サポートされているデータ形式 直接接続MySQL データベースに直接接続するをご覧ください。 MySQL、PostgreSQL、CSV、Avro
サポートされるデータベース サイズ 上限なし 上限なし
最大スループット 1 時間あたり 45 GB 1 時間あたり 200 GB

最小限のダウンタイムで移行

Spanner は、MySQL、PostgreSQL、Oracle データベースから最小限のダウンタイムで移行できます。最小限のダウンタイムで移行するには、次の 2 つのコンポーネントを使用します。

  • データベース内のすべてのデータの一貫したスナップショット
  • そのスナップショット以降の変更（挿入と更新）のストリーム（変更データ キャプチャ（CDC）と呼ばれる）。

最小限のダウンタイムでデータを保護できますが、このプロセスには次のような課題があります。

  • スナップショットの移行中に CDC データを保存する。
  • 受信 CDC ストリームのキャプチャ中に CDC データを Spanner に書き込む。
  • Spanner への CDC データの移行が受信 CDC ストリームよりも高速であることを確認する。

最小限のダウンタイムでの移行を管理するために、Spanner 移行ツールは次のプロセスをオーケストレートします。

  1. Cloud Storage バケットを設定して、スナップショットの移行中にソース データベースで受信した CDC イベントを保存します。
  2. CDC データの一括読み込みを移動し、増分 CDC データを Cloud Storage バケットに継続的にストリーミングする Datastream ジョブを設定します。Spanner 移行ツール内でソース接続プロファイルを設定します。
  3. CDC イベントを Spanner に移行する Dataflow ジョブを設定します。

Dataflow がほとんどのデータをコピーすると、ソース データベースへの書き込みを停止し、データの移行が完了するまで待機します。この結果、Spanner がソース データベースに追いつくまでの間、短いダウンタイムが発生します。その後、アプリケーションを Spanner にカットオーバーできます。

次の図は、このプロセスを示しています。

図は、最小限のダウンタイムで移行プロセスを示しています。

ダウンタイムを伴う移行

MySQL、PostgreSQL、Oracle データベース以外のデータベースで、CSV または Avro にエクスポートできる場合、ダウンタイムを伴って Spanner に移行できます。Dataflow または Spanner 移行ツールを使用することをおすすめします。

ダウンタイムを伴う移行は、テスト環境や数時間のダウンタイムを許容できるアプリケーションでのみおすすめします。ライブ データベースでダウンタイムが発生すると、データが失われる可能性があります。

ダウンタイムの移行を実行する手順は次のとおりです。

  1. ソース データベースのデータのダンプファイルを生成します。
  2. ダンプファイルを MySQL、PostgreSQL、Avro、または CSV のダンプ形式で Cloud Storage にアップロードします。
  3. Dataflow または Spanner 移行ツールを使用して、ダンプファイルを Spanner に読み込みます。

複数の小さなダンプファイルを生成すると、Spanner は複数のダンプファイルを並列で読み取ることができるため、Spanner への書き込みが迅速に行われます。

ソース データベースからダンプファイルを生成する場合、一貫性のあるデータ スナップショットを生成するには、次の点に注意してください。

  • ダンプファイルの生成中にデータが変更されないようにするには、ダンプを実行する前に、ソース データベースに読み取りロックを適用します。
  • レプリケーションを無効にして、ソース データベースからリードレプリカを使用してダンプファイルを生成します。

Avro は、Spanner に一括で移行する際に推奨される形式です。Avro を使用している場合は、次の点を考慮してください。

CSV を使用している場合は、次の点を考慮してください。

  • データの CSV ダンプを生成するには、ソースでサポートされている CSV 生成を使用します。データに改行が含まれている場合は、カスタム行区切り文字を使用します。
  • CSV データをインポートするには、Dataflow インポート ジョブを使用します。独自の Dataflow インポート テンプレートを作成することも、Google Cloud インポート テンプレートを使用することもできます。詳細については、Dataflow データ パイプライン テンプレートをご覧ください。

MySQL または PostgreSQL を使用している場合は、Spanner 移行ツールを使用できます。

カスタム スクリプトを使用して Spanner にデータを読み込む方法については、一括読み込みのパフォーマンス ガイドラインをご覧ください。

データの移行を検証する

データ検証は、ソーステーブルと宛先テーブルの両方のデータを比較して、一致することを確認します。

データ検証ツール（DVT）は、データストアに接続し、ソースと Spanner 間のチェックを実行することができるオープンソースのツールです。移行の一部として、次のように基本的な検証を行うことをおすすめします。

  • すべてのテーブルが作成され、すべてのスキーマ マッピングが正しいことを確認します。
  • 各テーブルの行数を照合します。
  • ランダムな行を抽出して正確性を確認します。
  • 列（count、sum、avg、min、max、group by）を検証します。
  • 行レベルで巡回冗長検査またはハッシュ関数を比較します。

より具体的な検証を行うには、移行中にカスタム チェックを作成します。

カットオーバーとフェイルオーバーのメカニズムを構成する

移行には時間がかかり、複雑になります。フォールバックを使用すると、移行中にエラーが発生した場合の影響が大幅に軽減され、最小限のダウンタイムでソース データベースに戻すことができます。

現在の推奨事項は、変更ストリームを使用してリバース レプリケーションを実行し、Pub/Sub または Cloud Storage などのストリームを介してソース データベースに書き戻すことです。

図はカットオーバー プロセスを示しています。

逆レプリケーションでは、次のことを行う必要があります。

  • データ型またはコンテンツの変更を処理します。
  • 移行中に行われた変換を元に戻します。
  • ソースのシャーディング スキームを考慮して、適切な宛先にデータを push します。