ご要望またはご協力できることがございましたらお気軽にお問い合わせください
一般的なお問い合わせと所在地情報
お問い合わせ
Control-M + GCP Cloud Run
GCP Cloud Runワークフローは、コンテナ化されたジョブが実行される前から始まります — 上流の何かが壊れると失敗する可能性があります。Cloud Storageオブジェクトが届かない。BigQueryジョブが期待されたウィンドウよりも遅れて終了する。Control-Mは、Cloud Storageの到着、BigQueryの変換、GCP Cloud Runの実行、下流の配信という完全なチェーンを調整します。
一般的なワークフローの問題
これがあなたの週のように聞こえますか？
これらはエッジケースではありません。これらは複数のツールでGCP Cloud Runジョブを実行しているチームにとっての通常の運用条件です。Control-Mがそれぞれをどのように処理するかを見てみましょう。
上流の遅延
あなたのBigQueryジョブは遅れて終了しました。Cloud Runはまだ待っています。
Control-Mは上流のジョブ状態を追跡し、依存関係が満たされたときにのみGCP Cloud Runジョブをリリースします。複雑な依存関係は切り離されたスケジュールを置き換え、早すぎる実行を防ぎ、エンドツーエンドのワークフローを同期させます。
コンテナの失敗
Cloud Runタスクが失敗しました。あなたの下流のワークフローを続行できません。
Control-MはGCP Cloud Runジョブの状態、結果、出力を監視し、実行が失敗した場合を特定し、依存するジョブが進行するのを防ぎます。回復ロジックとスケジューリングコントロールにより、失敗したコンテナワークロードが下流処理に波及するのを防ぎます。
SLAリスク
午前2:00のジョブが実行されています。午前6:00の締切が遅れています。
Control-MはGCP Cloud RunワークロードにSLA管理を付加し、完全なワークフロー内でそれを追跡します。チームは下流サービスが納品ウィンドウを逃してから遅延を発見するのではなく、締切リスクを早期に可視化できます。
実行時の上書き
今夜の実行には異なる引数が必要です。基本ジョブは変更されてはいけません。
Control-MはJSON内でGCP Cloud Run実行の上書きをサポートし、コンテナの上書き、タスク数、タイムアウトを含みます。チームは基盤となるCloud Runジョブ定義を保持しつつ、個々の実行をパラメータ化できます。
クロスツール回復
Cloud Runは成功しました。次のプラットフォームは引き継ぎを受け取っていませんでした。
Control-MはGCP Cloud Runの完了状態をより大きなジョブフローの一部として評価し、定義された依存関係に従って下流の作業をリリースします。オペレーションチームは文脈の中で壊れた引き継ぎを見て、手動でポーリングすることなくワークフローを回復できます。
統合事実
Control-M + GCP Cloud Run
|
APIおよび自動化機能 |
Control-M自動化API · GCP Cloud Runジョブ実行 · プロジェクトIDおよび地域ターゲティング · JSON実行オーバーライド · 構成可能なステータスポーリング · Cloud Run REST API |
|
デプロイメントモデルとインフラストラクチャの柔軟性 |
Control-M SaaS · Control-M自己管理 · Linuxエージェント · Windowsエージェント · 地域Cloud Runジョブ · サーバーレスコンテナ実行 |
|
セキュリティ姿勢 |
中央集権的接続プロファイル · GCPサービスアカウント認証 · GCPアクセス制御 · サービスアカウントキー認証 · セキュアな資格情報管理 |
|
インシデント対応とMTTR有効化 |
実行状況モニタリング · 結果と出力モニタリング · 複雑な依存関係の制御 · 下流カスケードの防止 · リソース制御 · SLAモニタリング · 中央集権的ワークフロー可視性 |
エンドツーエンドオーケストレーション
1つのプロダクションワークフロー。スタック内のすべてのツール。
Control-Mは、GCP Cloud Run、BigQuery、Cloud Storage、Dataflow、Composer、API、およびファイル転送を単一のジョブフローで調整します — 依存関係の追跡、SLAの可視性、およびそれら全ての自動回復を備えています。
- クロスツール依存関係: Cloud Storage → BigQuery → GCP Cloud Run → APIハンドオフ
- データ認識トリガー: ファイル到着、APIイベント、BigQuery完了、ジョブ終了ステータス
|
GCP Cloud Run |
ジョブ実行 · 実行オーバーライド · ステータスモニタリング · 結果と出力モニタリング |
|
BigQuery |
クエリ実行 · 変換オーケストレーション · 依存関係の調整 |
|
Cloud Storage |
ファイル到着検出 · 上流依存関係の制御 · データハンドオフ |
|
Dataflow |
処理ジョブのオーケストレーション · 完了追跡 · 下流依存関係の制御 |
|
クラウドコンポーザー |
DAG調整 · 実行追跡 · クロスワークフロー依存関係 |
|
API |
サービス呼び出し · ワークフロー引き渡し · 完了駆動型実行 |
|
ファイル転送 |
管理されたデリバリー · 到着検知 · 下流ワークフロートリガー |
airflow共存
Control-MはあなたのAirflow DAGを置き換えません。上にレイヤーを実行します。
一般的な異議は「私たちはすでにAirflowを使用しています。」です。問題はAirflowが何をするかではなく、Airflowが実行される前後に何が起こるかです。そこがパイプラインが実際に失敗する場所です。
AirflowはそのDAGを管理します。Control-Mはそれを取り巻くすべてを管理します。
airflowは処理する
データパイプライン内のDAGレベルのオーケストレーション
- データパイプライン内のDAGレベルのタスクオーケストレーション
- Pythonオペレーター、センサー、およびタスク依存関係
- パイプライン内で実行されるジョブの実行グラフ
- 単一のDAGコンテキスト内での再試行を管理
control-mが追加する
DAGの周りの調整レイヤー
- DAGの周りの調整層 — 上流の条件によってAirflowをトリガー: ファイル到着、APIイベント、他のツールの完了
- 各DAGのSLA貢献をエンドツーエンドワークフロー全体にわたって追跡し、単独のルーチンだけではなく
- Airflowが開始される前に上流の依存関係が失敗した場合の回復を管理
- 既存のDAGは書き直したり移行する必要がない
ワークロードを監視する
すべての依存関係にわたってGCP Cloud Runの実行を監視する。
Cloud Runはジョブ実行をGoogle Cloudの可観測性ツールを通じて公開しますが、プロダクションワークフローはしばしば複数のサービスにまたがります。Control-MはGCP Cloud Runのステータス、結果、出力、および周囲の依存関係を集中監視し、チームがワークフローの問題をより迅速に診断できるようにします:
-
ジョブ実行ステータス
-
結果と出力の監視
-
クロスプラットフォーム依存関係の可視性
-
エンドツーエンドワークフローステータス
-
SLAリスクの可視性
SLA保証
GCP Cloud Runワークフローをビジネスの締切に合わせて維持する。
Cloud Runは個々のジョブとタスクの実行を管理しますが、ビジネスの締切はしばしばコンテナが実行される前後のシステムにまたがります。Control-Mはそれらの依存関係にわたってSLA管理を適用し、上流または下流の実行がデリバリーを危険にさらす場合に回復を調整します:
-
SLAジョブ添付
-
クロスワークフロー締切追跡
-
依存関係を考慮した回復
-
中央集権的なステータス可視性
-
下流カスケードの防止
ドキュメンテーション
複雑なワークフローに秩序をもたらす
Control-Mがチームに複雑なプロセスをより高い可視性、調整、制御でオーケストレーションする方法を学ぶ。
