注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
スケジュール設定のベストプラクティス
本番パイプラインのスケジュールを容易に管理できるように、スケジュール設定のガイドラインをまとめました。このページを活用して、担当するスケジュールを管理してください。
- 各データセットは、1つのスケジュールだけでビルドするようにしてください。
- Data Lineage グラフのノードの色のドロップダウンでスケジュールカウントを選択すると、各データセットのスケジュール数を確認できます。
- Data Connection の生データの同期ごとに、強制 Build のスケジュールを1つ設定する必要があります。
- ほかのスケジュールには強制ビルドを設定しないでください。強制ビルドは Data Connection の同期でのみ使用してください。
- フルビルドの使用をできるだけ避け、代わりに接続ビルドを使用してください。
- スケジュールでは、ご自身が所有するデータセットのみをビルドするようにし、所有していないデータセットはビルドしないでください。
- ゴミ箱に移動したデータセットは、スケジュールでビルドしないでください。Upgrade Assistant を使用して、ゴミ箱に移動したリソースを含むスケジュールを調査し、修正します。
- スケジュールに再試行を追加します（1～3分の間隔で3回の再試行を推奨します）。
- パイプラインの各ステップに複数のスケジュールを設定することは避け、代わりにデータセットを論理的にまとめたスケジュールを作成してください。
例
1つのスケジュールにまとめるべき、不要なスケジュールを含むパイプライン：
接続ビルドを使用して、データセットを論理的にまとめたスケジュールを作成します。
以下のガイダンスに沿って、パイプラインに効果的なスケジュール体系を設定してください。
ベストプラクティス
パイプラインごとに1個のスケジュール
ほとんどの場合、パイプラインごとにスケジュールは1個だけにするべきです。実際、パイプライン内の各データセットに関連付けるスケジュール済みビルドは、1個だけにするべきです。2個の異なるスケジュールでデータセットをビルドすると、待ち行列が発生し、両方のスケジュールが遅くなることがあります。スケジュールの構成をシンプルに整理しておくと、各スケジュールの役割が明確になり、特定のデータセットでビルドに失敗した場合のデバッグが容易になります。また、パイプラインの設定時に確認や変更を行う場所が1か所だけになるため、パイプラインの保守にも役立ちます。
複数のステップを順番に実行するパイプラインでは、例外として扱える場合があります。その例を以下に示します。
- パイプラインに複数の終端ノードがある場合は、ノードごとに個別のスケジュールを検討してもよいでしょう。以下のパイプラインの例では、
Apex 1、Apex 2、Apex 3にそれぞれ定義する3個のスケジュールを設定するのが最も自然な方法です。ただし、Sharedにスケジュールを作成し、このデータセットをほかのパイプラインへの入力として扱うことも有益な場合があります。 - パイプラインで検証テーブルを使用している場合は、それらに個別のスケジュールが必要になることがあります。
- このような複雑なパイプラインを効果的に扱う方法については、安定性に関する推奨事項を参照してください。
プロジェクトスコープのスケジュール
スケジュールを正常に実行できるかどうかが単一のユーザー（スケジュールの所有者）の権限に依存しないよう、可能な場合はすべてのスケジュールをプロジェクトスコープにするべきです。そうしないと、スケジュールの所有者の権限が変更され、スケジュールのデータセットをビルドできなくなることがあります。スケジュールを最後に変更したユーザーがそのスケジュールの所有者になるため、スケジュールの編集後に所有者が変わる可能性がある点からも、これは特に重要です。
スケジュールをプロジェクトスコープにできない場合もあります。
- 権限の継承が切断されているトランスフォーム
- Contour ジョブ
- Fusion 同期
ユーザースコープのスケジュールごとに1人の所有者
プロジェクトスコープにできないスケジュールについては、特定のパイプライン上のすべてのスケジュールを1人のユーザーが所有することが望ましいです。このユーザーには、多くの場合「サービスユーザー」（特定の個人に紐付かない特別なユーザーアカウント）を使用します。あるいは、プロジェクト内のスケジュールのすべての変更に責任を持つチームリーダーを、単一の所有者にすることもできます。
パイプライン上のスケジュールを単一のユーザーが所有することで、複雑さを軽減し、ユーザー権限やチーム構成の変更による悪影響からスケジュールを保護できます。
単一の所有者にすることは、権限の一貫性を保つだけでなく、Builds アプリケーションで関連するビルドを追跡しやすくするうえでも役立ちます。Builds では、「実行者」ですべてのビルドを絞り込めます。
前述のとおり、スケジュールを最後に変更したユーザーが、そのスケジュールの所有者になります。複数のユーザープロフィールでスケジュールを管理していて、チーム内のアクセス権が均一でない場合、所有者の変更を考慮していないと、原因の特定が難しい権限エラーが発生する可能性があります。
再試行を使用する
スケジュールの設定時には、再試行を使用します。再試行はジョブの一部です。再試行可能な例外によってジョブの実行に失敗した場合、ビルドのオーケストレーションレイヤーはビルドを失敗させずに、同じジョブの新しい試行を開始します。
スケジュールには3回以上の再試行を設定し、再試行間の間隔を1分以上にすることを推奨します。これにより、プラットフォームは失敗するジョブを自動的に捕捉し、同じビルド内で再度実行できます。1分の間隔を設けることで、最初のジョブの失敗を引き起こした一時的な問題からプラットフォームが回復する機会を確保できます。
ジョブの再試行を有効にしない方がよい場合もあります。たとえば、非常に厳しいサービスレベル契約（SLA）があり、失敗が発生したらすぐに通知を受けたいパイプラインや、冪等でない副次的効果を持つトランスフォームです。ただし、スケジュールの設定で再試行を有効にしていなくても、裁定の一環としてジョブが再試行されることがあります。
複数データセットの強制ビルドは避ける
スケジュールでは「強制ビルド」オプションを有効にできます。このオプションを有効にすると、スケジュール内のすべてのデータセットが、古くなっているかどうかにかかわらずビルドされます。このオプションは Data Connection の同期に非常に便利です。Data Connection の同期はプラットフォーム上では常に最新とみなされるため、強制ビルドを使用しない限り、スケジュール済みビルドの一部としてビルドされることはありません。ただし、リソース使用量の面でコストが高くなる可能性があるため、派生データセットを含む複数データセットのスケジュールで強制ビルドオプションを使用することは推奨しません。代わりに、強制ビルドが必要なデータセットが専用のスケジュールに含まれるように、スケジュールを分割します。
スケジュールに含めるものと除外するもの
スケジュールに含めるものを明示します。パイプラインの外にあるデータセットは、明示的に無視します。ビルドの解決は複雑になることがありますが、含めるものを暗黙的にするよりも、明示する方が透明性を高められます。
- 以下のパイプライン例のスクリーンショットでは、
Apex 2に定義されたスケジュールでOwned By Someoneを無視するべきです。Cleaned 1とCleaned 2にも同じことが当てはまります。どちらかのジョブを実行すると、権限不足のためビルドは直ちに失敗します。
また、スケジュールは、次のようなデータセットに依存したり、それらをビルドしようとしたりするべきではありません。
- 現在ゴミ箱にあるデータセット： ゴミ箱内のリソースを含む既存のスケジュールに対処するには、Upgrade Assistant を使用して所有しているスケジュールを調査し、該当するリソースをゴミ箱から戻すか、スケジュールから除外します。
- Contour から生成されたデータセット： スケジュールを「本番環境で使用可能」とみなすには、パイプラインの変更をレビューし、問題が発生した場合に以前のバージョンに戻せる必要があります。Contour はこのようなワークフローに対応していないため、本番パイプラインでの使用は推奨しません。
- Code Workbook および Code Workspaces から生成されたデータセット： Contour の出力データセットほど厳格なルールではありませんが、本番パイプラインで Code Workbook と Code Workspaces を使用することは推奨しません。Code Workbook と Code Workspaces は、試行を重ねてソリューションを改善するには優れていますが、変更管理や元に戻す機能の堅牢性では Code Repositories に及びません。Code Workbook、Code Workspaces、Code Repositories の違いについて詳しくはこちら。
パイプラインのすべての出力は、スケジュール内で「対象」としてタグ付けするべきです。スケジュールには1個または複数の対象を設定できます。対象とは、そのスケジュールが設定されているデータセットです。また、スケジュールには1個または複数の出力を設定できます。出力とは、スケジュールによってビルドされ、ビルド内のほかの場所では使用されない最終的なデータセットです。ほとんどの場合、対象データセットと出力データセットは同じですが、場合によっては（特に複数出力のビルドでは）、ビルドの対象データセットと出力データセットが異なることがあります。一般的なルールとして、パイプラインのすべての出力を対象として定義するべきです。
早期に失敗させる
詳細設定の一つのジョブが失敗した時点で Build を中止するチェックボックスをオンにして、ジョブの実行に失敗したら直ちにビルドを失敗させるよう設定します。早期に失敗させることで、より早く問題を把握できます。
スケジュールに名前を付ける
すべてのスケジュールに、内容がわかる名前を付けるべきです。時間とともにパイプラインが複雑になり、ユーザーが増えるにつれて、スケジュール名は非常に役立ちます。
内容がわかるスケジュール名は、スケジュールに関わる人にその目的を伝えます。たとえば、将来そのスケジュールに関する問題の修正を担当する人に役立ちます。
複数の取り込みストリームがある場合、ほかのユーザーがパイプライン内のいずれかのパスを分岐させることが予想される場合、または時間とともに保守の担当者が変わることが想定される場合は、スケジュールに名前を付けることが特に重要です。