2018.11.16
これだけは押さえておきたい！Salesforceへの大量データローディングで考慮しておくこと
ポスト
近年、Salesforceで大量データを扱うことも増えてきていますね。
となると当然、大量のデータを他システムからSalesforceへ一括で移行することも増えてきます。
今回は大量のデータを初期データローディングする際に考慮しておくポイントをいくつかご紹介します。
※本記事では以下の想定シナリオで記載
・初期データ移行での一括データ投入
・移行対象は 標準オブジェクト、及びカスタムオブジェクト（Big Objectは今回は割愛）
・データ件数は数千件～数100万件
・DataLoaderを使用
まずはツールの選定から
SalesforceへのデータローディングツールとしてはインポートウィザードとDataLoaderがありますが、 インポートウィザードが対応していないオブジェクトへの初期データ移行や50,000件を超えるレコードの初期データ移行となるとDataLoaderを使用することになります。
DataLoaderの使い方はこちらが参考になります。
DataLoaderではローディング時のデータの加工はできないため、 複雑な移行要件がある場合は、SalesforceアダプタのあるETLツールを検討しましょう。
弊社のクラウドデータ連携サービスDataSpider Cloudもぜひご検討下さい。
DataLoaderの設定・操作
Bulk API を使用
DataLoaderでは「Use Bulk API」をチェック。
処理時間の短縮や、1バッチが最大10,000件になるのでAPIコール数を抑える効果があります。
バッチサイズはできるだけ大きい値で設定しておきます。
－並列モードを使用
Bulk APIの並列モードを使用するとより高速になるので、大量データではなるべく並列モードを使用します。 DataLoaderでは「Enable serial mode for Bulk API」を"チェックなし"に設定
ただし並列で処理されるため親レコードのロック競合エラーが発生する可能性があります。 親レコードのロック競合を最小限に抑えるために、子レコードの更新時は親別にグループ化するようにします。 エラー対応が難しい場合は逐次モード（serial mode）を検討します。
最も効率的なDML操作を使用
大量データを初回ローディングする際は、なるべくinsertを選択します。
当然ながら、insertの場合は重複投入ができてしまいますので、エラー時の再実行など移行手順は注意が必要です。
必要に応じて、ユニークな外部IDを使用したupsertを検討します。
メモリ不足のエラー対策
対応策はバッチサイズを下げるかヒープサイズを増やすかですが、初期データ移行時は後者となるでしょう。
DataLoader起動コマンド、または DataLoaderのiniファイルの設定で、Javaヒープサイズを増やすことができるので事前に検証して最適な値に設定しておきます。
以下サンプルでは先頭行でヒープサイズの最小値と最大値を設定しています。
※DataLoaderのバージョンやインストールフォルダにより変わるので適宜読み替えて下さい。
※Program Files 以下のファイル操作はアクセスエラーとなることがあるのでデスクトップなどにコピーして編集後に戻します。
C:\Program Files (x86)\salesforce.com\Data Loader\dataloader-43.0.0.l4j.ini
-Xms1024m -Xmx1256m -jar "C:\Program Files (x86)\salesforce.com\Data Loader\dataloader-43.0.0-uber.jar"
Salesforceイベント無効化
データ件数や移行要件、作業工数などの兼ね合いで適応すべき内容は変わってくるかと思いますが、処理時間の短縮やエラーリスク軽減のためには、可能な限り停止した状態でローディングを行うのがいいでしょう。
トリガの無効化
・処理時間の短縮
・Apexのガバナ制限エラーの抑制 ※1
・DML発行とネストしたトリガ実行の抑止 ※2
※1 Apexトリガとしては大量データのバルク処理に対応したコーディングは必要です。
※2 トリガ処理で他オブジェクトへの更新や親オブジェクトへの積み上げなど行っている場合、トリガを無効化することでセットされない項目がでてきます。そういった項目は移行データに含めるよう考慮が必要です。
明確な基準はありませんが、トリガが組み込まれたオブジェクトに対して、ある程度のボリュームのデータをローディングする際はトリガは停止した状態で実施するのがベターです。
どうしても必要なトリガの処理がある場合は、部分的にトリガを有効化しておくか、データローディング完了後のApex一括処理での適用を検討します。
なお、Salesforce本番組織では手動でのトリガの停止はできないので、
以下のようにカスタム設定の変更のみで停止できるよう設計しておくのがいいでしょう。
trigger AccountTrigger on Account (before insert, before update) {
Settings__c settings = Settings__c.getOrgDefaults();
if (settings.SkipTrigger__c) return; // フラグONなら処理Skip
// 以下通常のトリガ処理を記載
for(Account a : Trigger.New) {
a.Description = 'test description';
}
}入力規則、重複ルールの無効化
注意事項としては入力チェックを無効化することで、イレギュラーなデータが取り込まれる可能性がありますので、移行リハーサルなどで事前にデータをチェックしておく必要があります。
詳細は「入力データチェック」にて後述します。
手動でオフにできますが、入力規則など大量にある場合は、トリガと同様のフラグを用意してスキップできるよう設計にしておくのもいいかと思います。
※重複ルールは、作成、編集時のアクションで許可としても、アラートにチェックを入れるとAPI経由ではエラーとなるので注意。
ワークフロー、プロセスビルダー等の無効化
メールアラート系は特に注意しましょう。
共有適用を延期
移行リハーサル等で事前に検証し、必要に応じて移行手順に組み込みましょう。
※共有設定を一時的に「公開/参照・更新可能」にするでも可。ただしApexクラス等で共有オブジェクトが参照されている場合は変更できないので注意。
※共有適用の延期機能は、デフォルトでは有効ではないので組織で有効にするにはSalesforceサポートまでお問い合わせが必要。
※DataLoaderの実行ユーザは「すべてのデータの編集」権限を持つユーザとすることでACL確認用のクエリ発行が省かれるためパフォーマンスに効果があります。
オブジェクトリレーションの先送り
また、取引先の親取引先や自己参照 などローディング時に参照先データが存在するか不明な場合はエラーとなるリスクもあります。
ローディング後に、Apex一括処理やBulk APIのupdateでリレーションを構築することを検討します。
ただし、主従関係の場合は親を指定しないと子レコードを読み込むことはできないので初回ローディング時に設定します。
その他考慮事項
整形済みのデータ準備
トリガやワークフローなどローディング時のイベントを無効化する場合は、セットされない項目も出てくるので移行データに含めるように考慮しておきます。
なおデータ加工には時間も労力もかかるため、誰が加工して準備するかは明確にしておきましょう。
インデックス項目でのソート
外部IDなどインデックスが貼られる項目を持つオブジェクトに対して大量データを投入する際、インデックスが貼られる項目は事前にソートしておくことが望ましいです。
インデックスが生成される時、HDD上でインデックスが分散することを防ぎパフォーマンス向上に効果があります。
所有者、及び所有者のロール階層
ロール階層の特定の所有者が大量のデータを保持するとデータスキューが発生しパフォーマンスにも影響するので注意。
入力データチェック
データパターンや文字コードなど本来入ってはいけないデータが入る可能性があります。
では、どうするか？
大きく分けて、事前チェックと移行後メンテナンスの２つに分類できます。
事前チェック
データ不備チェックは、移行リハーサルまでに実施しておきます。 本番相当データを受領しての事前検証や、移行リハーサルでチェックを行い本番移行までにデータクレンジングを実施してもらう というのがよくやる流れです。
移行元データはお客様の持ち物ですので、データクレンジングはお客様にて実施して頂く必要があります。 修正には業務的な視点が必要となり時間がかかることも多いので、事前チェックは早めに実施するよう心がけましょう。
データチェック方法は色々ありますが 数10万行を超えるデータの場合はExcelやテキストエディタで処理するのは現実的ではありません。
・移行リハーサルなどでSalesforceにローディング後に入力規則をONにして Bulk API を使用したチェック
・その他ツールを使用したチェック
など効率のよい方法を検討しましょう。
弊社DataSpider Cloudにはデータチェックアダプタも備えてるので大量データの事前チェックには使えるのではないでしょうか？
移行後メンテナンス
最終移行リハーサルから本番移行までに発生したイレギュラーなデータなどは運用後にお客様の方でメンテナンスする方向で調整します。
移行後に入力チェックを有効にすることでレコード登録、編集時にチェックがかかり運用フローからは逸脱しません。
分割投入
ユーザやロールなどは事前に整備しておきます。
可能であればメンテナンスの少ないマスタ系は先に投入できないか事前に調整します。
移行リハーサル用Sandbox環境
リハーサルはSandboxで行うことになりますが、Sandboxの種類によってデータストレージ上限が決められていますので、
移行データの概算件数などを元に最適なSandbox環境を決定します。
FullSandboxなどライセンスによっては、ない場合や既に使用している場合もあるので、必要となる場合は早めにお客様と調整しておきましょう。
パフォーマンス検証
本番相当データを移行したSandbox環境で総合テストなどのテストに含めるようにするのが一般的です。
※テスト観点に関しては開発機能によって異なるため割愛。
なお、移行リハーサル中は上記のようにトリガなど止めることが多いので、移行リハーサルと機能テストのスケジュールが被らないよう注意します。
さいごに
本番データ移行ではシステム停止可能期間も限られるため、時間ベースの移行スケジュールを立てて実施することになります。
当然、遅延した場合のビジネスインパクトも非常に大きくなります。
移行要件通り正確にデータ移行するのはもちろんのこと
大量データの移行では遅延やエラーリスクも高くなるため
・所要時間の把握と短縮
・予期せぬエラーを発生させない
というのがポイントになってきます。
大量データに関するベストプラクティスはSalesforceからもドキュメントやTrailheadなどで提供されていますので
基本として理解した上で、上流行程の早い段階から移行計画/設計に着手しておくのが成功の近道かと思います。
