CRMデータ移行ツール開発の苦労話 ~ Extract編 ~

データ移行プロジェクトの中で直面した課題とその解決方法について、備忘録としてまとめました。

関連記事

プロジェクトの概要

CRMの環境刷新に伴い、新環境へのデータ移行ツールの開発依頼を受けました。
その際、ただ移行するのではなくオブジェクト構造を考慮したり、いらないデータを絞り込みしたり、名寄せをしたり、などとデータの加工要件をいただきました。
つまり、ただデータを旧環境から新環境に横流しだけでは要件を満たさないため、ETLを行いました。
また、BigQueryに関して知見があったこと、大規模データ加工が要件だったことがあり、TransformにはBigQueryを採用しました。

• Extract: Cloud Data Fusionを使用して、CRMからデータをBigQueryに転送する
• Transform: BigQuery / Dataform を使用し、データ加工する
• Load: mitocoXを使用して、BigQueryからCRMに転送する

この記事では

Extractに対象を絞って、まとめます。

Extractの全体アーキテクチャ

• Cloud Data Fusion: Salesforceプラグインを使用してデータ移行を行う.
• Cloudbuild (Terraform): Cloud Data Fusionのインスタンス, パイプラインを作成 / 削除する.
• Google Workflows: 全体のデータ移行を制御するステートマシン.

苦労した点

1. Cloud Data Fusionの運用問題

Cloud Data Fusion　（以下、CDF）をプロジェクト当初から採用していたのですが、ツールの制約に振り回されていました。

1.1 パイプラインの同時実行制限

• 課題: パイプラインの同時実行が制限されているため、効率的に処理が進まない。
  • 詳細: CDFでは、一度に実行できるパイプラインの数が限られており、特に大量のデータを移行する際にボトルネックとなります。特に、ビジネスのピーク時にはこの制限が顕著に現れました。
• 解決策: パイプラインのスケジューリングを工夫し、リソースの最適な使用を図る。
  • 具体例: ジョブの優先順位を設定し、夜間や週末などリソースが空いている時間帯に集中して実行することで、業務時間中の負荷を軽減しました。

1.2 インスタンスの立ち上げの困難さ

• 課題: 必要に応じてインスタンスを立ち上げるのが困難で、手間がかかる。
  • 詳細: インスタンスの立ち上げには時間がかかり、手動での設定が煩雑でした。
• 解決策: 自動化ツールの活用とスクリプトの作成で、インスタンスの立ち上げを簡素化。
  • 具体例: Terraformを使ってインフラをコード化し、簡単にインスタンスを立ち上げることができるようにしました。これにより、設定ミスのリスクも軽減しました。

2. CDFのAPI上限問題

2.1 Compute Engine APIの制限

• 課題: ディスク容量やCPU数など、Compute Engine APIの制限がデータ移行の妨げに。
  • 詳細: データ量が多いと、APIのリソース制限にすぐに達してしまい、移行が停止してしまうことがありました。
• 解決策: リソース配分を最適化し、必要な部分だけに集中してリソースを割り当てる。
  • 具体例: データの移行を段階的に行い、重要なデータから先に移行することで、リソースを効率的に使用しました。また、APIの制限を超えないように、移行ジョブを小分けにする工夫も行いました。

3. Salesforceプラグインの扱い

• 課題: Salesforceプラグインがどのようにダウンロード・運用されているかが不明確。
  • 詳細: Salesforceからデータを抽出するためのプラグインの入手と設定が複雑で、初期設定に時間がかかりました。
• 解決策: Mavenを使用して、Javaプログラムをjarファイルやjsonにパッケージ化して管理する。
  • 具体例: Mavenを使ってプラグインをパッケージ化し、デプロイを自動化するスクリプトを作成しました。これにより、設定ミスが減り、迅速に環境を構築できるようになりました。

4. 一時的なワークフローの構築

4.1 パイプラインの都度削除

• 課題: CDFが常時起動しているとコストがかかるため、パイプラインを都度削除する必要がある。
  • 詳細: CDFのパイプラインを常に動かしておくと、リソース使用量が増え、コストがかさみます。
• 解決策: 自動的にインフラを消去するスクリプトを作成し、一時的なワークフローを構築する。
  • 具体例: パイプラインが終了したら自動でリソースを削除するスクリプトを作成しました。これにより、コスト削減が実現しました。

4.2 移行オブジェクトの多さ

• 課題: 移行対象オブジェクトが20~30個ある場合、手動での削除が非常に負担になる。
  • 詳細: 手動での操作が多いと、人為的なミスが発生しやすくなります。
• 解決策: Terraformを使用してインフラをリモートで管理し、自動的に設定を適用・削除する。
  • 具体例: Terraformのスクリプトを使ってインフラをコードで管理し、簡単に設定を適用・削除できるようにしました。これにより、手動操作の手間が大幅に減り、エラーも減少しました。

5. ジョブの並列実行の制限

5.1 最大2時間かかるジョブ

• 課題: 長時間かかるジョブの並列実行が効率的に行えない。
  • 詳細: 一度に実行できるジョブの数が限られているため、全体の移行時間が長くなりました。
• 解決策: ジョブの分割とリソースの最適化を図り、並列実行数を増やす方法を模索。
  • 具体例: 長時間かかるジョブを小分けにし、並行して実行できるように工夫しました。また、リソースの使用状況を監視し、最適化しました。

5.2 Cloud Buildの同時実行制限

• 課題: Cloud Buildを同時に5つまでしか起動できない。
  • 詳細: 複数のビルドジョブが同時に必要な場合、制限により遅延が発生しました。
• 解決策: ジョブの優先順位を設定し、適切にスケジューリングすることで効率化を図る。
  • 具体例: ジョブの優先順位を決定し、重要なジョブから順に実行するようにスケジューリングしました。また、並行して実行できるジョブの数を最大限に活用しました。