このドキュメントでは、データベースを Spanner に移行するプロセスについて説明します。移行の各段階と、ソース データベースなどの要因に応じて各段階に推奨されるツールについて説明します。推奨されるツールには、Google Cloud プロダクト、サードパーティの商用ツール、オープンソース ツールが含まれます。これらのツールを組み合わせて移行を加速し、リスクを軽減できます。
Spanner の移行には、次の主要段階が含まれます。
- 移行の複雑さを評価します。
- スキーマを移行します。
- サンプルデータを読み込みます。
- アプリケーションを移行します。
- パフォーマンスをテストして調整します。
- データを移行します。
- 移行を検証します。
- カットオーバーとフェイルオーバーのメカニズムを構成します。
これらのステージでは、データベース ソースとサイズ、ダウンタイム要件、アプリケーション コードの複雑さ、シャーディング スキーマ、カスタム関数または変換、フェイルオーバーとレプリケーション戦略などの要素によって、移行計画が大きく異なる場合があります。
移行ツール
移行のさまざまな段階で、ソース データベースやその他の要因に応じて、次のツールを使用することをおすすめします。一部のツールは、特定のソース データベースのみをサポートしています。プロセスの一部の手順ではツールを使用できないため、手動で完了する必要があります。
Spanner 移行ツール（SMT）は、基本的な評価、スキーマ変換、データ移行を実行できるオープンソース ツールです。
データベースの移行評価（DMA）は、PostgreSQL を Spanner に移行するための基本的な評価を提供します。
Datastream は、ソース データベースから変更データ キャプチャ（CDC）イベントと一括データを読み取り、指定された宛先に書き込むことができる Google Cloud サービスです。
Dataflow は、テンプレートを使用して大量のデータを Spanner に効率的に書き込むのを支援する Google Cloud サービスです。
一括データ移行は、大規模な MySQL データセットを Spanner に直接移行できるようにする Dataflow テンプレートです。
ダウンタイムを最小限に抑えた移行では、Datastream と Dataflow を使用して次のものを移行します。
- ソース データベース内の既存のデータ。
- 移行中にソース データベースに加えられた変更のストリーム。
データ検証ツール（DVT）は、Google が構築した、オープンソースのコミュニティにサポートされている標準のデータ検証方法です。DVT は既存の Google Cloud プロダクトに統合できます。
MySQL ソース データベースの移行ツール
ソース データベースが MySQL の場合は、MySQL ダンプファイルを使用して移行の初期段階の一部を実行できます。本番環境への移行を完了するには、実行中のソース MySQL データベースに直接接続する必要があります。
次の表に、移行の段階と、ダンプファイルを使用するかどうか、ソース データベースに直接接続するかどうかに応じた移行ツールの推奨事項を示します。
| 移行段階 | ダンプファイル | ソース データベースへの直接接続 |
|---|---|---|
| 評価 | mysqldump で SMT を使用します。 |
mysqldump で SMT を使用します。 |
| スキーマの変換 | mysqldump で SMT を使用します。 |
SMT を使用してスキーマを構成して変換します。 |
| サンプルデータの読み込み |
|
一括移行を実行します。 |
| データの移行 | 該当なし | 一括移行を実行してから、ダウンタイムを最小限に抑えた移行を実行します。 |
| データの検証 | 該当なし | DVT を使用します。 |
| フェイルオーバーの構成 | 該当なし | リバース レプリケーションには SMT を使用します。 |
PostgreSQL ソース データベースの移行ツール
ソース データベースで PostgreSQL を使用している場合は、PostgreSQL ダンプファイルを使用して移行段階の一部を実行できます。移行を完了するには、実行中のソース PostgreSQL データベースに直接接続する必要があります。
次の表に、移行の段階と、ダンプファイルを使用するか移行元データベースから直接接続するかに基づく移行ツールの推奨事項を示します。
| 移行段階 | ダンプファイル | ソース データベースへの直接接続 |
|---|---|---|
| 評価 | pg_dump で SMT を使用します。 |
DMA を使用します。 |
| スキーマの変換 | pg_dump で SMT を使用します。 |
SMT を使用してスキーマを構成して変換します。 |
| サンプルデータの読み込み |
|
ダウンタイムを最小限に抑えた移行を実行します。 |
| データの移行 | 該当なし | ダウンタイムを最小限に抑えた移行を実行します。 |
| データの検証 | 該当なし | DVT を使用します。 |
| フェイルオーバー | 該当なし | 該当なし |
移行の複雑さを評価する
移行の範囲と複雑さを評価し、アプローチを計画するには、ソース データベースに関する次のようなデータを収集する必要があります。
- クエリパターン
- ストアド プロシージャやトリガーなどのデータベース機能に依存するアプリケーション ロジックの量
- ハードウェア要件
- 総所有コスト（TCO）
スキーマを移行する
スキーマを Spanner スキーマに移行する前に、スキーマ間の互換性を評価し、Spanner 用にスキーマを最適化します。たとえば、キーの変更、インデックスの削除 / 追加、既存のテーブルの列の追加 / 削除を行います。Spanner 用にスキーマを最適化するには、スキーマ設計のベスト プラクティスと推奨される主キー移行戦略をご覧ください。
Google のデベロッパーが作成したコミュニティ管理のオープンソース ツールである Spanner 移行ツールは、ソース データベース スキーマから Spanner スキーマを自動的にビルドします。スキーマは、Spanner 移行ツールのスキーマ アシスタントを使用してカスタマイズできます。
Spanner 移行ツールは、次のいずれかの場所からスキーマとデータを取り込みます。
- ローカルの場所または Cloud Storage からのダンプファイル（MySQL、PostgreSQL、CSV）
- ソース データベース（MySQL、PostgreSQL）から直接
Spanner 移行ツールは、スキーマの評価、推奨事項、移行に対して次の機能を実行します。
- データ型の互換性評価と推奨事項
- 主キーの編集と推奨事項
- セカンダリ インデックスの編集と推奨事項
- テーブルのインターリーブの編集と推奨事項
- Spanner スキーマ設計の一般的な推奨事項
- スキーマのバージョニング
- スキーマの共同変更
Spanner 移行ツールを使用したスキーマ移行の詳細については、Spanner 移行ツールの README.md ファイルをご覧ください。
また、データ移行にも Spanner 移行ツールを使用します。
サンプルデータを読み込む
Spanner 互換のスキーマを作成したら、サンプルデータを使用してテストするデータベースを準備できます。BigQuery リバース ETL ワークフローを使用してサンプルデータを読み込むことができます。詳細については、サンプルデータを読み込むをご覧ください。
アプリケーションの移行
データベースの移行には、さまざまなドライバとライブラリが必要になるほか、Spanner でサポートされていない機能の埋め合わせも必要です。Spanner の強みを活かすように最適化するには、コード、アプリケーション フロー、アーキテクチャを変更することが必要になる場合があります。
アプリケーションを Spanner に移行するために必要な変更をいくつか示します。
- Spanner はデータベース レベルでのユーザーコードの実行をサポートしていないため、データベース レベルに保存されているプロシージャとトリガーをアプリケーションに移動する必要があります。
- Spanner クライアント ライブラリとオブジェクト リレーショナル マッパー（ORM）を使用します。詳細については、API、クライアント ライブラリ、ORM ドライバの概要をご覧ください。
- クエリを翻訳する必要がある場合は、手動で翻訳するか、他のサードパーティ製ツールを使用します。
- パーティション化 DML、読み取り専用トランザクション、commit タイムスタンプ、読み取りタイムスタンプ、およびそれらがアプリケーションのパフォーマンスを最適化する方法を記録しておきます。
トランザクション処理の変更が必要になる場合もあります。この作業を支援するツールはないため、この手順は手動で行う必要があります。以下の点にご注意ください。
- 1 回の commit あたりのミューテーションの上限は 40,000 です。テーブルの各セカンダリ インデックスは、行ごとに追加のミューテーションです。ミューテーションを使用してデータを変更するには、ミューテーションを使用してデータを挿入、更新、削除するをご覧ください。大量のデータを変更するには、パーティション化 DML を使用します。
- トランザクション分離レベルの場合、Spanner トランザクションはより分離されているため、処理は必要ありません。
- Spanner は線形化可能であるため、デフォルトで整合性とロックを処理します。
スキーマとアプリケーションのパフォーマンスをテストして調整する
パフォーマンスの調整は反復的なプロセスです。データのサブセットに基づいて CPU 使用率やレイテンシなどの指標を評価し、スキーマとアプリケーションを調整してパフォーマンスを改善し、再度テストします。
たとえば、スキーマでインデックスの追加や変更、主キーの変更を行うことができます。アプリケーションでは、バッチ書き込み、クエリの結合や変更が可能です。
特に本番環境トラフィックでは、想定外の事態を回避するためにパフォーマンスの調整が重要です。パフォーマンスの調整は、設定が本番環境のライブ トラフィックのスループットとデータサイズに近いほど効果的です。
スキーマとアプリケーションのパフォーマンスをテストして調整する手順は次のとおりです。
- データのサブセットを Spanner データベースにアップロードします。詳細については、データを移行するをご覧ください。
- アプリケーションが Spanner に指すようにします。
- 基本的なフローをチェックして、正しいことを確認します。
- アプリケーションで負荷テストを実行して、パフォーマンスが期待どおりであることを確認します。最も費用のかかるクエリを特定して最適化する方法については、Query Insights でクエリのパフォーマンスの問題を検出するをご覧ください。特に、最適化されていないクエリのパフォーマンスに次の要因が寄与する可能性があります。
- 非効率的なクエリ: 効率的なクエリの作成方法については、SQL のベスト プラクティスをご覧ください。
- CPU 使用率が高い: 詳細については、高い CPU 使用率について調査するをご覧ください。
- ロック: トランザクション ロックによるボトルネックを軽減するには、高いレイテンシの原因となる可能性のあるトランザクションを特定するをご覧ください。
- 非効率なスキーマ設計: スキーマが適切に設計されていない場合、クエリの最適化はあまり役に立ちません。
- ホットスポット化: Spanner のホットスポットは、特に QPS の非常に高いアプリケーションで書き込みスループットを制限します。ホットスポットやアンチパターンを特定するには、Google Cloud コンソールでKey Visualizer の統計情報を確認します。ホットスポットを回避する方法の詳細については、ホットスポットを防ぐ主キーの選択方法をご覧ください。
- スキーマまたはインデックスを変更する場合は、満足できる結果が得られるまで正確性とパフォーマンスのテストを行います。
データベースのパフォーマンスの微調整の詳細については、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 Database からのダウンタイムを最小限に抑えた移行をサポートしています。ダウンタイムを最小限に抑えた移行は、次の 2 つのコンポーネントで構成されます。
- データベース内のすべてのデータの整合性のあるスナップショット
- そのスナップショット以降の変更（挿入と更新）のストリーム（「変更データ キャプチャ（CDC）」と呼びます）
ダウンタイムを最小限に抑えた移行はデータの保護に役立ちますが、このプロセスには次のような課題があります。
- スナップショットの移行中に CDC データを保存する。
- 受信 CDC ストリームをキャプチャしながら、CDC データを Spanner に書き込む。
- CDC データの Spanner への移行が、受信 CDC ストリームよりも高速であることを確認する。
最小限のダウンタイムでの移行を管理するために、Spanner 移行ツールは次のプロセスをオーケストレートします。
- Cloud Storage バケットを設定して、スナップショットの移行中にソース データベースで受信した CDC イベントを保存します。
- CDC データの一括読み込みを移動し、増分 CDC データを Cloud Storage バケットに継続的にストリーミングする Datastream ジョブを設定します。ソース接続プロファイルは、Spanner 移行ツール内で設定します。
- CDC イベントを Spanner に移行する Dataflow ジョブを設定します。
Dataflow は、データのほとんどをコピーすると、ソース データベースへの書き込みを停止し、データの移行が完了するまで待ちます。この結果、Spanner がソース データベースに追いつくまでの間、短いダウンタイムが発生します。その後、アプリケーションを Spanner にカットオーバーできます。
次の図は、このプロセスを示しています。
ダウンタイムを伴う移行
MySQL、PostgreSQL、Oracle Database 以外のデータベースの場合、データベースを CSV または Avro にエクスポートできる場合は、ダウンタイムありで Spanner に移行できます。Dataflow または Spanner 移行ツールを使用することをおすすめします。
ダウンタイムのある移行は、数時間のダウンタイムを処理できるテスト環境またはアプリケーションにのみ推奨されます。ライブ データベースでダウンタイムのある移行を行うと、データが失われる可能性があります。
停止時間の移行を行う手順の概要は次のとおりです。
- ソース データベースからデータのダンプファイルを生成します。
- ダンプファイルを MySQL、PostgreSQL、Avro、CSV のいずれかのダンプ形式で Cloud Storage にアップロードします。
- Dataflow または Spanner 移行ツールを使用して、ダンプファイルを Spanner に読み込みます。
複数の小さなダンプファイルを生成すると、Spanner は複数のダンプファイルを並列に読み取ることができるため、Spanner への書き込みが速くなります。
ソース データベースからダンプファイルを生成する場合は、データの一貫したスナップショットを生成するために、次の点に注意してください。
- ダンプファイルの生成中にデータが変更されないようにするには、ダンプを行う前に、ソース データベースに読み取りロックを適用します。
- レプリケーションが無効になっているソース データベースのリードレプリカを使用して、ダンプファイルを生成します。
一括移行に推奨される形式
Avro は、Spanner への一括移行に適した形式です。Avro を使用している場合は、次の点に注意してください。
- データの Avro ダンプを生成する場合は、DBeam などのツールを使用します。Avro へのエクスポートの詳細については、Spanner 以外のデータベースから Avro ファイルにデータをエクスポートするをご覧ください。
- Avro データをインポートするには、Dataflow インポート ジョブを使用します。詳細については、Spanner 以外のデータベースから 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 する。