ユースケース開発自動化パフォーマンスとトラブルシューティングパフォーマンスのベストプラクティス

注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

パフォーマンスのベストプラクティス

このページでは、自動化を設定する際にパフォーマンスとリソース使用量を最適化するためのベストプラクティスを説明します。これらのガイドラインに従うことで、コンピューティングリソースの消費を最小限に抑え、大規模な自動化でも効率的に実行できます。

Foundry のリソース消費に関する一般的な情報については、リソース管理のドキュメントを参照してください。

概要

設定がベストプラクティスに従っていない場合、Automate が大量のリソースを消費する原因となることがあります。基本原則は、可能な限り操作を一括で実行することです。

自動化を作成する前に

自動化を設定する前に、Automate が本当に必要かどうかを評価します。

  • データの変更に対する自動レスポンスや、手動操作なしで実行されるスケジュール処理が必要な場合は、Automate を使用します。
  • オブジェクトのプロパティをハードコードされた値や計算値に手動で変更する場合は、Automate は必要ありません。この場合は、アクションタイプを作成し、Workshop または Object Explorer から対象のオブジェクトセットに対して直接呼び出します。この方法のほうが効率的で、アクションを実行するタイミングを直接制御できます。

Automate のコストを左右する要素を理解する

自動化のパフォーマンスを最適化する際は、次の3つの要素を考慮します。

  1. 条件の設定: 自動化の評価を引き起こす要因です。
  2. 実行モード: 条件イベントから効果の実行が生成される仕組みです。
  3. 効果の設計: 実行時にアクションや関数が行う処理です。

各要素は、その前の要素を基盤としています。実行モードと効果(要素2と3)で一括処理を行えるのは、自動化の条件(要素1)が一括操作用に設定されている場合のみです。 たとえば、個々のオブジェクトの更新を条件にすると、入力は1個のオブジェクトのみとなるため、オブジェクトを1個ずつ処理する必要があります。

条件の設定(要素1)

条件の設定によって、自動化がオブジェクトを評価し、処理する頻度が決まります。

  • 頻繁に更新されるオブジェクト(1日あたり100回以上の更新): 頻繁に更新されるオブジェクトタイプでは、時間ベースの評価とオブジェクトセット条件を組み合わせます。これにより、自動化の評価回数の上限が時間条件の頻度に制限されます。
  • 更新頻度の低いオブジェクトの場合: オブジェクト更新条件だけで十分です。

条件の設定についてはオブジェクトセット条件のドキュメントと時間条件のドキュメント、評価頻度のオプションについては評価頻度のドキュメントで詳しくはこちらをご覧ください。

シナリオ例

1,000個のオブジェクトを持つオブジェクトタイプで、各オブジェクトが1日に100回更新される場合を考えます。「オブジェクト更新時」の条件のみを使用すると、自動化の評価が1日あたり最大100,000回発生する可能性があります(更新が同時に発生しないと仮定すると、100回の更新 × 1,000個のオブジェクト)。

5分の時間条件を適用すると、評価回数の上限は1日あたり288回(1,440分 ÷ 5)となり、最大で約340分の1に削減されます。

実行モード(要素2)

実行モードによって、自動化がトリガーされたすべてのオブジェクトをまとめて処理するか、個々のオブジェクトやバッチごとに個別の実行を作成するかが決まります。実行設定について詳しくはこちらをご覧ください。 自動化の実行モードを設定する際は、ユースケースで許容される場合、オブジェクトごとの実行よりも単一実行(デフォルト)を優先します。

  • 単一実行: 条件に一致するすべてのオブジェクトに対して自動化の効果が1回実行され、オブジェクトセット全体が効果に渡されます。この設定では、トリガーされたすべてのオブジェクトを1回の自動化実行で処理します。通常は、すべてのオブジェクトを個別に処理するよりも効率的です。
  • オブジェクトごとの実行: オブジェクトまたはバッチごとに自動化の効果が個別に実行されます。失敗を分離する必要がある場合や、異なる設定でオブジェクトを処理する場合など、ビジネスロジック上、特定のバッチ処理要件がある場合に使用します。

実行モードについては、オブジェクトセット条件のドキュメントで詳しくはこちらをご覧ください。

シナリオ例: オブジェクトごとに通知を送信し、オブジェクト固有の詳細を含める必要があるアクションは、そのオブジェクトの通知を生成して送信するアクションをオブジェクトごとに実行する方法で実装できます。または、関数を呼び出す1つのアクションを単一実行し、その関数を通じて複数の通知を生成する方法でも実装できます。この場合は、後者の方法を優先してください。

効果の設計(要素3)

アクション(およびその処理を担う関数)の設計によって、一括処理を活用できるかどうかが決まります。単一のオブジェクト参照ではなく、オブジェクトセットを入力パラメーターとして受け取るようにアクションを設計します。これにより、1回の操作で多数のオブジェクトを効率的に渡せます。

アクションパラメーターの設定については、アクションタイプのドキュメントで詳しくはこちらをご覧ください。

入力パラメーターのデータ型を、効率の高い順にまとめると次のようになります。

入力データ型効率説明
オブジェクトセット最も効率的サイズにかかわらず効率的に渡せる、クエリ可能なオブジェクトセットです。
オブジェクト配列良好オブジェクトのインスタンスの配列で、中程度のサイズのバッチに適しています。パラメーターを「オブジェクト参照」に設定し、「複数の値を許可」を有効にします。
単一オブジェクト最も非効率単一のオブジェクト参照です。ビジネスロジック上必要な場合にのみ使用します。

アクションの処理を関数が担う場合は、その関数も一括入力を処理するように設計する必要があります。パフォーマンスの高い関数を記述するための詳細なガイダンスについては、関数のパフォーマンスを最適化するを参照してください。

主な考慮事項:

  • オブジェクトセットまたは配列を入力パラメーターとして受け取ります。
  • オブジェクトを個別に反復処理するのではなく、一括で計算を実行します。
  • 可能な場合は、すべてのオブジェクトをメモリーに読み込むのではなく、バックエンドで集計を使用します。

自動化を監視する

定期的な監視は、パフォーマンスの問題の特定と防止に役立ちます。次の警告兆候に注意してください。

  • 高い実行頻度: 1日に何度も実行される自動化
  • 急速に更新されるオブジェクト: 非常に頻繁に更新されるオブジェクトタイプ
  • 深い自動化チェーン: 相互にトリガーする複数の自動化
  • 非効率な関数: オブジェクトごとにオントロジークエリを実行する関数

これらのパターンが見られる場合は、詳しい診断方法と解決策について自動化のパフォーマンスのトラブルシューティングを参照してください。

監視用のツール

自動化の動作を理解するには、次のツールを使用します。

  • Automate の実行履歴: Automate の設定で利用可能で、実行パターンを表示できます
  • Autopilot: 自動化の連鎖とその依存関係を理解するのに役立ちます
  • Workflow Lineage: プラットフォーム全体にわたる自動化の依存関係を追跡します

Autopilot と Workflow Lineage には、自動化の概要ページにあるアクションメニューからアクセスできます。

自動化の依存関係については、自動化の依存関係のドキュメントで詳しくはこちらをご覧ください。