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

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

関連記事

https://qiita.com/kusaaaaagi/items/018f979689113a954bbd

## プロジェクトの概要
CRMの環境刷新に伴い、新環境へのデータ移行ツールの開発依頼を受けました。
その際、ただ移行するのではなくオブジェクト構造を考慮したり、いらないデータを絞り込みしたり、名寄せをしたり、などとデータの加工要件をいただきました。
つまり、ただデータを旧環境から新環境に横流しだけでは要件を満たさないため、ETLを行いました。
また、BigQueryに関して知見があったこと、大規模データ加工が要件だったことがあり、TransformにはBigQueryを採用しました。
- Extract: Cloud Data Fusionを使用して、CRMからデータをBigQueryに転送する
- Transform: BigQuery / Dataform を使用し、データ加工する
- Load: [mitocoX](https://www.terrasky.co.jp/eai/dataspidercloud/)を使用して、BigQueryからCRMに転送する


## この記事では

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

## Extractの全体アーキテクチャ

![スクリーンショット 2024-06-25 21.52.28.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2898059/b14e2783-ba32-4839-3f38-2221ea5e2a5b.png)

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