スケジューリングのベストプラクティス

プロダクションパイプラインのスケジュールが簡単に管理できるようにするため、スケジューリングガイドラインを作成しました。このページを使用して、ユーザーが責任を持つスケジュールを管理してください。

概要チェックリスト

• 各データセットは1つのスケジュールでのみ構築されるべきです。
  • ノードカラードロップダウンで スケジュール数 を選択することで、Data Lineage グラフの各データセットに対するスケジュール数を確認できます。
• 各 raw Data Connection sync には1つの force build スケジュールが必要です。
  • 他のスケジュールに force builds を設定するべきではありません。Force builds は Data Connection syncs でのみ使用すべきです。
• full builds を避けて、代わりに connecting builds を使用してみてください。
• スケジュールはユーザーが所有するデータセットのみを構築すべきです。ユーザーが所有していないデータセットはスケジュールで構築しないでください。
• トラッシュされたデータセットはスケジュールで構築されるべきではありません。トラッシュされたリソースを含むスケジュールを調査し、修正するために Upgrade Assistant を使用してください。
• スケジュールにリトライを追加します（1から3分の間隔で3回のリトライを推奨します）。
• パイプラインの各ステップに複数のスケジュールを持つのではなく、データセットを論理的なスケジュールにまとめてください。

例

1つのスケジュールに結合すべき不要なスケジュールを持つパイプライン：

データセットを論理的なスケジュールに結合し、connecting build を使用します：

以下のガイダンスを使用して、パイプラインの効果的なスケジュールシステムを設定します。

ベストプラクティス

パイプラインごとに1つのスケジュール

ほとんどの場合、パイプラインごとに1つのスケジュールを持つべきです。実際、パイプライン内の各データセットは、それに関連するスケジュールビルドを1つだけ持つべきです。データセットが2つの異なるスケジュールによって構築されると、キューが発生し、両方のスケジュールが遅延する可能性があります。スケジュールのセットをシンプルで整理されたものに保つことで、各スケジュールの責任を明確にし、特定のデータセットでビルドが失敗した場合のデバッグを容易にします。また、パイプラインの設定を確認または変更したいときに確認する場所が1つだけになるため、パイプラインのメンテナンスにも役立つかもしれません。

ただし、複数の順序付けられたステップで実行されるパイプラインには例外を設けることができます。以下にいくつかの例を記載します：

1. パイプラインに複数の終端ノードがある場合、各ノードに対して別々のスケジュールを考慮することができます。以下に示す例のパイプラインでは、最も自然なアプローチは Apex 1、Apex 2、Apex 3 に定義された3つのスケジュールを設定することです。しかし、Shared にスケジュールを作成し、このデータセットを他のパイプラインへの入力として扱うことも有益かもしれません。
2. パイプラインが検証テーブルを使用している場合、それらに対して別々のスケジュールが必要になるかもしれません。
3. これらのような複雑なパイプラインを効果的に処理する方法については、安定性の推奨事項 を参照してください。

プロジェクトスコープのスケジュール

可能な限り全てのスケジュールはプロジェクトスコープにすべきで、スケジュールの成功の可否が単一ユーザー（スケジュールの所有者）の権限に依存しないようにするべきです。そうしないと、スケジュール所有者の権限が変更され、スケジュールのデータセットの構築が阻止される可能性があります。これは特に重要で、スケジュールの編集後にスケジュールの所有権が変更される可能性があるためです。スケジュールを最後に変更したユーザーがスケジュールの所有者になります。

プロジェクトスコープにできないスケジュールもあります：

• 権限が断絶された変換
• Contour のジョブ
• Fusion の同期

ユーザースコープのスケジュールには1つの所有者

プロジェクトスコープにできないスケジュールでは、特定のパイプライン上の全てのスケジュールを単一ユーザーが所有することが望ましいです。このユーザーは通常、"service user"（単一の人物に結びついていない特別なユーザーアカウント）です。または、単一の所有者はプロジェクト内のスケジュールの全ての変更に責任を持つチームリーダーであることもあります。

パイプライン上のスケジュールを単一ユーザーが所有することで、複雑さが減少し、ユーザーの権限の変更やチーム構成の変更によってスケジュールが悪影響を受ける可能性を軽減します。

上述した通り、スケジュールを最後に変更したユーザーがスケジュールの所有者になるという事実は重要であり、複数のユーザープロフィールがスケジュールを管理していて、チーム全体のアクセス権が一様でない場合、所有権の変更を考慮に入れないと、追跡が困難な権限エラーが発生する可能性があります。

リトライの使用

スケジュールを設定する際はリトライを使用します。リトライはジョブの一部であり、ジョブが再試行可能な例外で失敗した場合、ビルドオーケストレーションレイヤーはビルドを失敗させずに同じジョブの新しい試行を再起動します。

スケジュールには少なくとも3回のリトライを設定し、リトライ間には少なくとも1分を設けることを推奨します。これにより、プラットフォームは失敗するジョブを自動的にインターセプトし、同じビルド内で再トリガーすることができます。1分の追加ギャップは、プラットフォームにジョブが初めて失敗した原因となる一時的な問題から回復するチャンスを与えます。

ジョブのリトライを有効にしたくない場合もあります。例えば、障害が発生した際にすぐにアラートを出したいと考えている非冪等な副作用を持つ変換を持つ、非常に厳格なサービスレベル契約（SLAs）を持つパイプラインなどです。

マルチデータセットの force builds を使用しない

スケジュールは "force-build" オプションを有効にすることができます。このオプションが有効になっていると、スケジュール内の全てのデータセットが、その新鮮さに関係なく構築されます。このオプションは Data Connection syncs にとって非常に有用で、それらはプラットフォーム内で常に最新の状態に保たれているため、force build が使用されない限り、スケジュールビルドの一部としては構築されません。ただし、派生したデータセットに対して force build オプションを持つマルチデータセットのスケジュールを持つことは、リソースの使用面でコストがかかるため、お勧めしません。代わりに、force-build する必要があるデータセットをそれぞれのスケジュールに分割します。

スケジュールに含めるものと除外するもの

スケジュールに含まれるものについては明示的にすることが重要です。パイプラインの外にあるデータセットは明示的に無視します。ビルド解決は複雑であることが多いですが、含まれるものについて明示的であることは、暗黙的であるよりも透明性を提供します。

• 以下の例のパイプラインスクリーンショットでは、Owned By Someone は Apex 2 に定義されたスケジュールから無視されるべきです。同様に、Cleaned 1 と Cleaned 2 についても、これらのいずれかでジョブをトリガーすると、権限不足によりすぐにビルドが失敗するため、無視されるべきです。

また、スケジュールは以下のようなデータセットに依存するか、それらを構築しようとするべきではありません：

• 現在ゴミ箱に入っている： トラッシュされたリソースを含む既存のスケジュールを修正するために、Upgrade Assistant を使用して、ユーザーが所有するスケジュールを調査し、問題のリソースをスケジュールから取り出すか除外します。
• Contour から生成された： スケジュールを "production ready" と見なすためには、パイプラインへの変更をレビューし、何かがおかしい場合に前のバージョンに戻すことができる必要があります。Contour はこのようなワークフローをサポートしていないため、プロダクションパイプラインでの使用をユーザーには推奨していません。
• Code Workbook から生成された： これは Contour の出力データセットよりも厳密なルールではありませんが、我々は Code Workbook をプロダクションパイプラインで使用することをお勧めしません。Code Workbook は解決策の反復には優れていますが、変更管理やリバートに関しては Code Repositories よりもロバストではありません。Code Workbook と Code Repositories の違いについて詳しく知る

パイプラインの全ての出力はスケジュールで "target" としてタグ付けされるべきです。スケジュールは1つまたは複数のターゲットを持つことができ、これらはスケジュールがインストールされているデータセットです。スケジュールはまた、1つまたは複数の出力を持つことができ、これらはスケジュールによって構築され、ビルドの他の箇所では使用されない最終的なデータセットです。ほとんどの場合、ターゲットデータセットと出力データセットは同一ですが、一部のケース（特にマルチ出力ビルド）では、ビルドは異なるターゲットと出力データセットを持つことがあります。一般的なルールとして、パイプラインの全ての出力はターゲットとして定義されるべきです。

速やかに失敗する

Advanced options の Abort build on failure チェックボックスにチェックを入れて、ジョブが失敗したらすぐにビルドが失敗するように設定します。これにより、早く信号を受け取ることができます。

スケジュールに名前を付ける

全てのスケジュールには説明的な名前をつけるべきです。スケジュールの名前は、パイプラインが複雑さを増してユーザーが増えるにつれて非常に役立ちます。

説明的なスケジュール名は、スケジュールと対話する人々、例えば、将来、スケジュールに関連する問題の修正に責任を持つ人々に、スケジュールの意図についての情報を提供します。

複数の取り込みストリームがある場合、他のユーザーがパイプラインの任意のパスをフォークすることを期待している場合、またはメンテナンスの責任が時間とともに変わることを予想している場合など、スケジュールに名前を付けることは特に重要です。