2020.01.29

Salesforceとのデータ連携におけるパフォーマンスについての考慮ポイント集

  • このエントリーをはてなブックマークに追加
  • follow us in feedly
みなさん、こんにちは。製品営業本部の河合です。

DataSpider CloudでSalesforceとのデータ連携を構築する際には様々な考慮ポイントがあります。
今回は連携処理のパフォーマンス(処理速度、メモリ使用量などのサーバー負荷)にスポットを当てて整理してみました。
Thinking Work Man - Free photo on Pixabay (13662)

パフォーマンスに影響する要素

まず、パフォーマンスに影響する要素を上げてみます。

  • データ量

    取り扱うレコード数、カラム数、ファイルサイズを指します。もちろん、量が多いほど影響は大きくなります。

  • スクリプト

    どのような処理を実装するか、Salesforceとの連携に使うAPIは何か、分岐やループ・データ変換などの複雑さなど、様々な要素が影響します。

  • トリガー

    いつ、どんな処理が、どれくらい実行されるのか、によって影響が変わります。 また、設定の中にはパフォーマンスに影響するものもあります。

他にも、ネットワーク環境やSalesforceとデータ連携する別システムの仕様などの要素も影響しますが、話が広がりすぎてしまうため、今回は省略します。

考慮ポイント

さて、それぞれの要素について、どのような考慮が必要かを考えてみます。

データ量

処理に使うデータは必要最低限になるようにスクリプトを実装します。

  • 必要なカラムのみ取得する

    SOQLは「SELECT * FROM ~~」という表記は使えませんが、不要なカラムはSELECTしないようにします。

  • 必要なレコードのみ取得する

    期間を指定する、カテゴリ等の項目で絞り込むなど、処理対象レコードを必要最低限にします。複雑なSOQLはタイムアウトする可能性もあるため、Salesforceのオブジェクト構成やインデックスなどを適切に設定します。

    参考:SOQL クエリの処理速度への考慮事項について

スクリプト

ロジックやデータ変換の無駄をなくすことはもちろんですが、要件定義や設計の段階から意識しておく内容も含まれます。

  • 使用するAPI

    Salesforceとの連携にあたり、どのAPIを使うか検討します。 APIによって、実行できる処理や大量データへの適正が異なります。 また、APIによって使用するアダプタが異なります。

    • SOAP API:Salesforceアダプタ
    • REST API:RESTアダプタ
    • Bulk API:Salesforce Bulkアダプタ

      

    参考:どの API を使用するか?

  • バッチサイズ

    Salesforceへの書き込みを指定した件数分まとめて行います。SOAP APIでは最大200、Bulk APIでは最大10,000とすることができます。数値を大きくするほど書き込みの効率は上がりますが、Apexトリガーなどがガバナ制限に抵触する可能性があるため、適切な値を設定する必要があります。

  • マルチストリームコンバータが有効なコンポーネントを使用する

    マルチストリームコンバータとは「結合」「集計」「ソート」のコンポーネントに使われているデータ変換を効率的に処理する機能です。 上記に該当する処理を実装する場合は、これらのコンポーネントを使うことにより、高い処理速度を実現することができます。

    参考:ヘルプ:Multi-Stream Converter (結合・集計・ソート)

  • PSP処理を有効化する

    PSP(パラレルストリーミング処理、Parallel Stream Processing)は、データの読み込み~書き込みまでを並列で実行することで、メモリの消費を抑えつつ、高速に処理を行う機能です。

    こちらは様々なコンポーネントで使用可能で、対応しているかは各コンポーネントのヘルプに記載されています。

    なお、PSPを有効化した場合、一部のコンポーネント変数に値がセットされなくなります。 こちらもヘルプに載っていますので、事前に確認しておくことをお勧めします。

    参考:PSP MonitorでPSPの実力を検証!

  • データ変換などをSalesforceに寄せる

    複雑なデータ変換などにより、連携サーバーの負荷が高くなってしまう場合、一部の処理をSalesforce側に実装することも検討します。 Apexトリガーやプロセスビルダー、数式項目やApexで独自のAPIを作成するなどの仕組みを構築します。

  • 本番相当のデータでテストを実施

    開発したスクリプトのテストは「本番相当のデータ」「本番相当のデータ量」を使用したケースを含めることを推奨します。想定外のデータによる開発の手戻り、予定時間内に処理が終わらない、予定外のスケールアップで追加費用が発生するなど、プロジェクトに大きな影響が発生する可能性があります。

  • スクリプトレビューの実施

    コーディング規約で細かい定義がされていない場合、実装は各エンジニアに委ねることになります。無駄な実装を発見できるだけでなく、バグを事前に発見できたり、ノウハウを共有することでエンジニアのスキルアップにも繋がります。

  • トリガー
    • ログレベル

      ログレベルを「FINEST」や「DEBUG」に設定すると、ログに出力される内容が多くなります。 その分、ログファイルへの書き込み処理が多くなるため、パフォーマンスが劣化します。通常は「INFO」とし、エラー調査時のみ「DEBUG」を使う、といった運用がお勧めです。

    • インターバルトリガー
      • 実行時間

        24時間実行する必要があるか、を検討して設定します。 例えば、基幹システムとSalesforceのデータをリアルタイムに同期する場合、業務時間外も同じように連携する必要があるか、不要であれば業務時間外は動作しないように設定します。連携サーバーの負荷軽減だけでなく、SalesforceのAPIコール数節約にも繋がります。

      • 起動制限

        1回の処理時間と実行間隔によっては、前の処理が終わる前に次の処理の開始時間となるケースがあります。 前の処理が終わるまで待つのか、そのまま処理を開始するのか、適切に設定します。

    • HTTPトリガー
      • スクリプトの最大同時実行数

        HTTPトリガーはリクエストを受けた数だけ同時に発火します。 必要に応じて、最大同時実行数を制限します。

おわりに

Salesforceとのデータ連携におけるパフォーマンスへの考慮ポイントをまとめてみました。
なお、省略したものも含め、パフォーマンスに影響するポイントは多く、事前に予想を立てるのは困難です。

DataSpider Cloudではかなり安い金額で試用できる評価版を提供しています。
可能であれば、検証フェーズを設け、データパターンの洗い出しや処理速度のアタリをつけておくとスムーズかと思います。

今回は以上となります。
本記事が何かのお役に立てば幸いです。
18 件
     
  • banner
  • banner

関連する記事