ジョブ スケジュールのアンチパターンの特定
- バッチデータレイクの取り込み（Real-Time CDP）
- プロファイルのバッチインジェストサービス（Real-Time CDP）
- IDのバッチ取得（Real-Time CDP）
- バッチセグメント化（Real-Time CDP）
- バッチ宛先のアクティベーション（Real-Time CDP）
- スケジュールされたバッチキャンペーン （Adobe Journey Optimizer）
ジョブスケジュール のタイムラインビューは、データパイプラインのパフォーマンスと信頼性に悪影響を与える可能性のある一般的な設定問題を特定するのに役立ちます。 こうしたアンチパターンは、しばしばジョブの失敗、データの不整合、システムパフォーマンスの低下につながります。 最も一般的な4つのアンチパターンは、インターフェイスの警告インジケーターを通じて自動的に検出および表示されます。 これらのパターンを早期に発見することで、ビジネスに影響を与える前に問題を回避するために、ジョブを再構成できます。
自動的に検出されたアンチパターン auto-detection
ジョブ スケジュール は、4つの一般的なアンチパターンを自動的に検出し、インターフェイスに警告インジケーターを表示します。 バッチパイプラインのアンチパターンの場合、関連する概要カード にインジケーターが表示され、問題の説明、推奨アクション、影響を受けるデータセットまたは宛先のリストが表示された詳細パネルが開きます。 キャンペーンタイミングのアンチパターンの場合、影響を受けるキャンペーンは、タイムラインで直接セグメント化の終了前に開始 ラベルの下にグループ化されます。
前提条件 prerequisites
アンチパターンを特定する前に、次のことをおこなう必要があります。
- ジョブスケジュールの表示 アクセス制御権限を持つ ジョブスケジュール にアクセスできます。
- ジョブスケジュールのインターフェイス と、タイムラインビューの読み取り方法について説明します。
- 基本的な バッチ取り込み、 セグメント化、 プロファイル処理の概念について説明します。
クイックリファレンス anti-pattern-quick-reference
スケジュール重複 schedule-overlap-pattern
影響の重要度：高| プライマリの問題：リソースの競合
探すべきこと：複数のジョブが同時に実行または連続して実行するようにスケジュールされています。特に、リソースを多く消費するジョブが重複している場合に注意してください。
一般的な例としては、スケジュールされたセグメンテーションジョブと同時にバッチ取り込みジョブが実行されます。 これにより、両方の操作に大きな処理能力とメモリが必要なため、リソースの競合が発生します。
問題がある理由:
- リソース競合：複数のリソース集約型ジョブを同時に実行すると、システムリソース（CPU、メモリ、I/O）を競合して、すべてのジョブの実行が遅くなります。
- 予測不可能なパフォーマンス：ジョブの期間に一貫性がなくなり、信頼性の高いスケジュールを計画することが困難になります。
- カスケーディング遅延：ジョブが予想よりも時間がかかる場合、下流の依存ジョブが遅延し、パイプライン全体に波及効果が生じる可能性があります。
- エラーのリスクが高まります: リソースの使い果たしにより、ジョブがタイムアウトしたり、完全に失敗したりする可能性があります。
解決方法:
- ジョブスケジュールを時間差にする: リソース集約的な操作を同時に実行するのではなく、順次実行します。
- バッファー時間を追加：処理のバリエーションを考慮して、ジョブ間に十分な間隔を空けます。
- 依存関係を確認：他のユーザーが安全に開始する前に完了する必要があるジョブを特定します。
スケジュールされた宛先のアクティブ化に近づきすぎているセグメント化が ジョブスケジュール によって検出されると、宛先のアクティブ化の概要カードに警告インジケーターが表示されます。 警告インジケーターを選択して、検出された発生回数、タイミング競合の説明、推奨事項、影響を受ける宛先の表を示すパネルを開きます。
セグメント化が終了する前にキャンペーンを開始 campaign-start-before-segmentation-end
影響の重要度：高| プライマリの問題：不完全なオーディエンスに対するキャンペーン送信
検索対象：上流のセグメント化ジョブが完了する前に開始時間が設定された、Adobe Journey Optimizerのスケジュールされたバッチキャンペーン。
問題がある理由:
- 古いオーディエンスまたは部分的なオーディエンス: セグメント化が完了する前に開始されるキャンペーンは、オーディエンスの不完全な評価に対して送信されます。
- サイレントエラー：キャンペーンは必ずしもエラーではありません。 スケジュールどおりに送信されますが、間違ったデータに対して送信されるか、ウィンドウが完全に失われます。
- 非表示の依存関係：統合ビューがなければ、顧客がサポートチケットを調査するまで、セグメンテーションとキャンペーン配信のタイミングの競合は表示されません。
解決方法:
- バッファー時間を追加: セグメント化が完了すると予測された後、セグメント化期間の通常の変動を吸収するのに十分な余裕を持って、キャンペーンを開始するようにスケジュールを変更します。
- 依存関係チェーンを確認：キャンペーンオーディエンスがどのセグメント化ジョブに依存しているかを確認し、競合を削除するためにスケジュールを調整します。
ジョブスケジュール は、影響を受けるキャンペーンを開始の下にグループ化することで、タイムライン上でこの競合を直接検出します。セグメント化の終了 ラベルの下の キャンペーン 行の下にグループ化します。 詳しくは、 キャンペーンのスケジュールされたタイミング を参照してください。
スケジュールされたジョブの密度 scheduled-density
影響の重要度：高| プライマリの問題: パイプラインのボトルネック
検索対象：複数のバッチが同じ時間内にスケジュールされたデータセットが多すぎます。特に、これらのバッチが近くに積み重ねられ、セグメント化の開始時間などの重要な処理ウィンドウの近くでスケジュールされている場合に注意してください。
このパターンには、通常、次のものが含まれます。
- 1日に複数のバッチを実行する複数のデータセット
- ETL ジョブ（データレイクの取り込みとプロファイルの取り込み）が同じ時間内にクラスター化されます
- スケジュールされたセグメンテーションウィンドウの直前またはスケジュールされたバッチ取り込み
問題がある理由:
- パイプラインのボトルネック：異なるデータセットからの多数のバッチが短い時間内に積み重なると、取り込みパイプラインを圧倒する処理のボトルネックが生じます。
- プロファイルの可用性の遅延: セグメント化の開始時間に近すぎて実行されるプロファイル取り込みジョブが時間内に完了しない可能性があり、その結果、オーディエンスの評価が不完全または陳腐化する可能性があります。
- 予測不可能なセグメンテーション: セグメンテーションの開始時にアップストリーム取り込みジョブが引き続き実行されている場合、不完全なデータに対してオーディエンスを評価するリスクがあり、オーディエンスメンバーシップが正しくありません。
- カスケーディングエラー：重なり合ったスケジュール内の1つの遅延バッチがドミノ効果を引き起こす可能性があり、その後のすべてのバッチとダウンストリームプロセスが遅延します。
- リソースひずみ：処理中の取り込みジョブが多すぎると、システムが十分なリソースの割り当てに苦慮し、処理時間が遅くなったり、エラーが発生したりする可能性があります。
解決方法:
- バッチの統合：複数の小さいバッチを、データセットごとに少ない大きいバッチにまとめて、バッチの頻度を減らします。
- 均等に配布：取り込みジョブを特定の時間にクラスタリングするのではなく、1日を通して分散させます。
- バッファー時間を追加: プロファイルの取り込みの完了からセグメント化の開始までの間に、最低1～2時間のバッファーを確保します。
- 要件を確認：すべてのデータセットが本当に複数の日次バッチを必要とするかどうかを評価します。 多くのユースケースでは、更新の頻度を減らすことができます。
スケジュールされたセグメント化の実行に近づきすぎているプロファイル取り込みジョブが ジョブスケジュール で検出されると、セグメント化概要カードに警告インジケーターが表示されます。 警告インジケーターを選択して、検出された発生回数、タイミング競合の説明、推奨事項、影響を受けるデータセットのテーブルを示すパネルを開きます。
プロファイル取り込み日別制限 profile-ingestion-daily-limit
影響の重大度：高| プライマリの問題: システム ガードレール
何を探すべきか：毎日のプロファイル取り込みが90回の実行システムガードレールに近づいているか、それを超えているときに、プロファイル取り込み概要カードに警告インジケーターが表示されます。 警告インジケーターを選択すると、選択した期間の各日の1日当たりの実行数を示す棒グラフが表示されます。
このグラフでは、色分けされた棒グラフを使用して、カウントが制限に対してどこに落ちるかを示します。
- 赤いバー（90回以上）:1日の制限を超えています。 処理の非効率性は、プロファイルが有効なすべてのデータセットに影響を与える可能性があります。
- オレンジ色のバー（72～89回）:1日の上限に近づいています。
- 緑の棒（72点以下）：許容範囲内です。
問題がある理由:
- 処理非効率: 1日あたり90回を超えるプロファイル取り込みが実行されると、すべてのプロファイル対応データセットに影響を与える可能性のある処理オーバーヘッドが作成されます。
- リソース競合：合計実行数が多いと、ダウンストリームのセグメンテーションとアクティブ化のジョブが遅れる可能性があります。
- データの古さ: プロファイル処理が継続的に実行されると、個々のバッチの完了に時間がかかり、セグメント化のデータの可用性が遅れる場合があります。
解決方法:
- データセットごとのバッチ頻度を減らします: バッチを統合して、毎日トリガーされるプロファイル取り込み実行を減らします。 詳細なガイダンスについては、 データセットごとの過剰なバッチ を参照してください。
- すべての取り込みスケジュールを監査: プロファイル取り込み用にスケジュールされたすべてのデータセットを確認し、バッチ頻度が不必要に高いデータセットを特定します。
データセットあたりの過剰なバッチ excessive-batches-per-dataset
影響の重要度: Medium | プライマリの問題：非効率的な処理
何を探すべきか:1日を通してスケジュールされた個別のバッチジョブの数が多すぎる単一のデータセットで、タイムライン上に縦のジョブスタックが長く作成されます。
このパターンでは、多数の個々のバッチ取り込みジョブを頻繁に、1日に何十回ものバッチでスケジュールした単一のデータセットが必要です。
問題がある理由:
- 非効率的な処理：各バッチジョブには、オーバーヘッドのコスト （初期化、検証、メタデータの更新）があります。 多数の小さいバッチの処理は、多数の大きいバッチの処理よりも大幅に効率が低くなります。
- エラーの増加：ジョブが増えることで、エラーの機会が増えます。 失敗した各バッチには、調査と潜在的な再処理が必要です。
- 不要なシステム読み込み：頻繁に発生する小さなバッチにより、実際のデータ処理ではなくオーバーヘッドのタスクでシステムが常にビジー状態になり、全体的なスループットが低下します。
- データの可用性の遅延：逆説的に、多数の小さいバッチを実行すると、統合されたバッチと比較して、下流プロセスでデータが利用可能になるときに遅延する可能性があります。
- 困難な検査: データセットごとに数十のバッチジョブの成功とパフォーマンスを追跡すると、操作が複雑になり、時間がかかります。
- プロファイル処理の遅延：各プロファイル取り込みバッチトリガープロファイル処理。 小規模なバッチが頻繁に実行されると、プロファイル処理がほぼ継続的に実行され、効率的なバッチ最適化が妨げられる可能性があります。
解決方法:
- バッチ頻度を減らす：ほとんどのユースケースで、データセットごとに1日あたりのバッチ数を減らします。
- バッチサイズを増やす：すぐに取り込むよりも取り込みをトリガーする前に、より多くのデータを蓄積します。
- ビジネスニーズに合わせる：毎時間の更新が本当に必要かどうか、または毎日/2回の毎日の更新で十分かどうかを確認します。
- リアルタイムにストリーミングを使用：頻繁なバッチを使用してストリーミングをシミュレートするのではなく、リアルタイム要件を満たすストリーミング取り込みに切り替えます。
- 1日の合計実行を監視：複数のデータセットのバッチ頻度が高い場合、合計はシステムガードレールを超える可能性があります。 「 プロファイル取り込み日の上限」を参照してください。
次の手順 next-steps
ジョブスケジュールのアンチパターンを特定した後：
- ジョブの詳細を表示して、特定のデータセットと問題の原因となる可能性のあるジョブ実行を調査します。
- ジョブスケジュールの概要を確認して、インターフェイスとインスペクション機能について確認します。
- データ読み込みスケジュールを最適化するための バッチ取り込みについて説明します。
- オーディエンス評価の適切なタイミングを確保するために、 セグメント化スケジュール について理解します。
- エンドツーエンドのパイプラインを可視化するために、宛先データフローの監視を確認します。
- プロファイルの取り込み日の上限に近づいたときに通知を受け取るように、 アラート を設定します。