【実務・中級編】 データ移行の内部処理 – Cloud Spanner

【Cloud Spanner極限解説】Dataflowインポート/エクスポートの内部構造と、数TB超の巨大データを爆速かつ安全に移行する実務設計パターン

こんにちは。Cloud Spannerの黎明期から数々のミッションクリティカルな分散システムの設計・運用を手がけてきたチーフアーキテクトだ。

コードレビューや設計レビューをしていると、Cloud Spannerのデータ移行（インポート・エコシステム）について、いまだに「Dataflowテンプレートをポチるだけの簡単な作業」と誤解しているエンジニアに遭遇する。数GBの小さなおもちゃのようなデータセットならそれでも動くだろう。しかし、数TB、数千億行におよぶプロダクションデータを扱うレイヤーにおいて、その甘い認識は必ず本番障害という名のしっぺ返しを食らう。

今回は、Cloud Spannerのインポート/エクスポートジョブが裏側でどのようにDataflowと結合し、どのような分散メカニズムでAvroデータを処理しているのか、そのコアアーキテクチャを剥き出しにして解説しよう。単なるマニュアルの焼き直しではない、現場で血を流しながら得た「極限の知見」を伝授する。

—

1. アーキテクチャの真実：なぜCloud SpannerはDataflowを介すのか

まず大前提として、Cloud Spannerは単一の巨大なRDBMSではなく、数千・数万のコミットメントグループ（Splits）にデータを自動分割し、グローバルに分散配置されたLSMツリーベースのストレージエンジンである。

この分散ストレージからデータを一括で吸い出したり、逆に流し込んだりする場合、単一のクライアントからSQLを投げていてはネットワークやコーディネーション層が即座にボトルネックになる。

ここで登場するのが Apache Beam (Google Cloud Dataflow) だ。

[ Cloud Spanner ]
│
▼ (スプリット単位での並列ストリーム読み出し / Splits API)
[ Dataflow Worker (HPAによる動的スケールアウト) ]
│
▼ (Cloud Storageへの並列シリアライズ)
[ GCS: Avro Files + Manifest JSON ]

インポート/エクスポートの内部シーケンス

1. メタデータの解決:
Spanner側は自身のストレージパーティション（Split）の境界情報を知っている。インポート/エクスポートを起動すると、内部で専用のAPI（`PartitionQuery` や `PartitionRead`）が走り、データ全体を論理的な「チャンク（断片）」に分割してDataflowジョブへタスクとして配布する。
2. Dataflowワーカーの並列駆動:
Dataflowのオートスケーリングにより、ワーカーノードが動的にプロビジョニングされる。各ワーカーは割り当てられたSpannerのSplitから並列でデータを抽出し、あるいはCloud StorageからAvroデータを読み込んでバルクインサートを行う。
3. Avro + マニフェスト形式:
データ本体はGoogle Cloud Storage (GCS) に Apache Avro 形式で保存される。同時に、テーブルスキーマやファイルのマッピングを定義した `manifest.json` が生成される。

—

2. Avro形式とデータ型マッピングの罠

Dataflow経由のエクスポート/インポートでは、Spannerのデータ型が一度Avroスキーマに変換される。ここで多くのエンジニアがハマる「型変換の落とし穴」がある。

特に注意すべきなのは以下の型だ：

  • `TIMESTAMP`: Avroではミリ秒またはマイクロ秒精度のタイムスタンプ（論理型 `timestamp-micros`）としてマッピングされるが、タイムゾーンの扱いやエポックからの精度落ちに注意が必要。
  • `BYTES`: バイナリデータやシリアライズされたProtobufなどを格納している場合、Avroの `bytes` 型へのシリアライズ/デシリアライズコストがCPUを激しく消費する。
  • `ARRAY`: スキーマ設計においてアンチパターンとされることもある `ARRAY` 型だが、移行時のAvro表現では `array` 型として素直にマッピングされる。ただし、ネストが深いデータ構造を持つ場合、Dataflowワーカーのヒープメモリを圧迫する原因になる。

—

3. 数TB超の移行を成功させるための「実務設計パターン」

ここからが本題だ。数TB規模のデータを移行・バックアップする際、デフォルト設定のままジョブを流すと、ほぼ確実に以下のいずれかの障害に直面する。

1. Spanner側のCPU使用率急上昇によるレイテンシ悪化（スロットリング）
2. DataflowワーカーのOut of Memory (OOM)
3. トランザクション競合（Mutationsの制限超過）

これを回避するための、シニアエンジニアが実践すべき設計パターンを公開する。

パターンA: 読み出し負荷の制御（Export時）

エクスポートは一見すると「読むだけ」なので安全に思われがちだが、巨大なテーブルを全件スキャンすると、Spannerのリーダー/フォロワーレプリカのディスクI/OとCPUが飽和する。

  • 対策:
  • 本番稼働中のプライマリインスタンスではなく、リードオンリーレプリカ（Read-only Replica）に対してエクスポートを実行する。SpannerではStale Read（古くなったデータの読み取り）を活用することで、トランザクションロックを一切取得せずに安全にデータを抜き出すことが可能だ。
  • Dataflowのパラメータで、ワーカーの最大数（`maxNumWorkers`）をあらかじめ制限し、Spannerへの同時リクエスト数をスロットリングする。

パターンB: 書き込みの最適化とバッチサイズ（Import時）

インポート時は、膨大なMutations（変更レコード）がSpannerに流し込まれる。Spannerの1トランザクションあたりのMutation数制限（通常20,000制限、またはサイズ制限）に抵触すると、ジョブが異常終了する。

  • Dataflowワーカーのサイジングとチューニングの例:

インポート用テンプレートを実行する際のGCloudコマンドのベストプラクティスを見せよう。

gcloud dataflow jobs run spanner-import-prod \
–gcs-location=gs://dataflow-templates-${REGION}/latest/GCS_Text_to_Cloud_Spanner (※実際はSpanner-to-GCS等の適切なテンプレート) \
–region=${REGION} \
–parameters \
rangePadding=10,\
tableId=TargetTable,\
instanceId=my-spanner-instance,\
databaseId=my-database,\
inputDir=gs://my-bucket/export-dir/ \
–max-workers=50 \
–worker-machine-type=n2-standard-4

ここで重要なのは、ワーカーのスペックと数のバランスだ。
メモリ不足でOOMを吐く場合は、単にワーカー数を増やすのではなく、`n2-standard-4` のようにメモリに余裕のあるマシンタイプ（CPUあたりのメモリが多い構成）を選定するのが鉄則である。Avroファイルのデシリアライズには見た目以上のメモリが必要になるからだ。

パターンC: 外部キー制約（Foreign Keys）とインターリーブ（Interleaved Tables）の順序制御

Cloud Spannerの真骨頂である「インターリーブ構造（親子関係）」や「外部キー制約」が存在する場合、インポートの順序を誤ると一発で失敗する。

  • 原則:
  • 親テーブルが完全にインポートされる前に子テーブルのインポートが走ると、外部キー制約違反（あるいはインターリーブの親不在）で即死する。
  • 設計プラクティス: 巨大なデータセットを移行する場合、制約（Foreign Key）を一度一時的に無効化（あるいはスキーマから除外して後からALTERで付与）するか、Dataflowジョブをテーブルの依存関係のツリー構造に従って完全に直列・段階的に実行するオーケストレーション（Cloud Composer / Apache Airflowなど）を必ず挟むこと。一撃の巨大ジョブで全てを解決しようとしてはいけない。

—

4. パフォーマンスチューニングの極意：プロファイリングとトラブルシューティング

もし君のチームが移行ジョブの遅延やエラーに悩まされているなら、以下のチェックリストを上から順に確認してほしい。

1. Dataflowジョブグラフの監視:
Cloud ConsoleのDataflowモニタリングで、「Data Elements (Bytes)」や「Bytes per second」のグラフが特定のワーカーで偏っていないか（ホットスポットが発生していないか）を確認する。もし偏りがある場合、Spanner側のスプリット分割が偏っている（単一の主キーにデータが集中しているなど、スキーマ設計のアンチパターン）可能性が高い。
2. シャッフルとネットワークコスト:
DataflowワーカーとGCSバケット、そしてCloud Spannerのインスタンスは、必ず同一のリージョンで稼働させなければならない。クロスリージョンを跨いだ瞬間、レイテンシの悪化だけでなく、法外なネットワークエグレス料金が発生する。
3. カスタムワーカーイメージの活用:
デフォルトのDataflowコンテナではなく、特定のカスタムAvroパースロジックやカスタムコードを挟む必要がある場合は、Apache BeamのJava/Python SDKを用いたカスタムパイプラインを構築する。その際、I/Oのバッチ処理（`ParDo` 内でのバルク書き込みバッファリング）を適切に実装し、RPCのラウンドトリップ数を極限まで減らすことがプロのエンジニアの仕事だ。

—

チーフアーキテクトからのメッセージ

Cloud SpannerとDataflowの連携によるデータ移行は、単なる「データのコピー」ではない。分散ストレージの物理限界、ネットワークのトポロジー、そしてトランザクションの整合性を極限まで理解した者だけが使いこなせる、洗練されたアーキテクチャの芸術である。

「動けばいい」の精神で設計された移行パイプラインは、本番直前のリハーサルで必ず崩壊する。今日解説したアーキテクチャの裏側と設計パターンを胸に刻み、堅牢でスケーラブルなデータ基盤を構築してほしい。

君たちのコードレビューを、楽しみにしている。

スポンサーリンク

コメント

タイトルとURLをコピーしました