ご要望またはご協力できることがございましたらお気軽にお問い合わせください
一般的なお問い合わせと所在地情報
お問い合わせ
Control-M + GCPバッチ
あなたのGCPバッチワークフローは、スクリプトやコンテナが実行される前に始まります — そして、上流で何かが壊れると失敗する可能性があります。Cloud Storageオブジェクトが到着しない。Dataflowジョブが処理ウィンドウを超えて実行される。Control-Mは、Cloud Storageの到着、Dataflow処理、GCPバッチ実行、BigQueryのローディングという完全なチェーンをオーケストレートします。
一般的なワークフローの問題
これはあなたの週のように聞こえますか？
これらはエッジケースではありません。これらは、複数のツールでGCPバッチジョブを実行しているチームにとっての通常の運用条件です。Control-Mが各ケースをどのように処理するかを見てみましょう。
上流の依存関係
あなたのCloud Storage入力が遅れています。バッチジョブは安全に開始できません。
Control-Mは、必要な上流条件が満たされるのを待ってからGCPバッチジョブを開始し、その後、結果のジョブ状態に基づいて下流の依存関係を調整します。これにより、壊れやすい時間ベースのスケジューリングを避け、ワークフローを通じて不完全な入力が連鎖するのを防ぎます。
スポット中断
スポットVMが実行中に消えます。あなたの処理ウィンドウはどんどん狭くなっています。
GCPバッチは、スポットVMのプリエンプションによって引き起こされた失敗を含む、失敗したタスクを再試行できます。Control-Mは全体のGCPバッチジョブを監視し、その結果の状態に基づいて回復と下流実行を調整し、より広いワークフローを管理します。
失敗の伝播
バッチジョブが失敗しました。BigQueryは不完全な結果を読み込んではいけません。
Control-MはGCPバッチジョブの結果を検出し、必要な完了条件が満たされない場合に依存する処理を保留します。下流のBigQuery、転送、またはアプリケーションジョブは、失敗が解決され、ワークフローが安全に続行できるまで保護されます。
SLAリスク
ジョブはまだ実行中です。あなたの下流の納品締切が近づいています。
Control-MはGCPバッチジョブをエンドツーエンドのサービスワークフローに組み込み、依存ジョブ全体のSLA監視をサポートします。オペレーションチームは、遅延処理が納品を脅かすときにそれを確認し、全体のビジネスワークフローが目標を逃す前に介入できます。
オペレーションの可視性
GCPにはログがあります。オペレーションは依然として全体のワークフローコンテキストが必要です。
Control-Mは、GCPバッチの状態、結果、出力をワークフロー内の他のジョブとともに監視します。Cloud Loggingが有効になっていると、バッチログはジョブの状態と出力とともにControl-Mモニタリングドメインに保存され、調査や回復中のコンテキスト切り替えが減少します。
Control-M + GCPバッチ
Control-M + GCPバッチ
|
APIおよび自動化機能 |
Control-M Automation API · Control-M Web · ジョブバッチ · ConnectionProfileバッチ · 高度なJSONジョブ定義 · 設定可能なステータスポーリング |
|
展開モデルとインフラストラクチャの柔軟性 |
Control-M · Control-M SaaS · Linuxエージェントプラグイン · Windowsエージェントプラグイン · スクリプトワークロード · コンテナワークロード · 標準またはスポットVM · マシンタイプまたはインスタンステンプレート |
|
セキュリティポスチャ |
GCPサービスアカウント認証 · IAMロールベースの認証 · セキュア接続プロファイル · 中央集権的接続プロファイル · ローカル接続プロファイル |
|
インシデントレスポンスとMTTRの実現 |
設定可能な最大タスク再試行回数 · ジョブステータス監視 · 結果と出力監視 · Cloud Loggingサポート · SLAジョブ添付 · 依存関係に基づくカスケード防止 |
エンドツーエンドオーケストレーション
1つの生産ワークフロー。スタック内のすべてのツール。
Control-Mは、GCPバッチ、Cloud Storage、Dataflow、BigQuery、Airflow、ファイル転送、クラウドサービス全体を単一のジョブフローでオーケストレートします — 依存関係の追跡、SLAの可視性、およびすべての自動回復を備えています。
- クロスツール依存関係: Cloud Storage → Dataflow → GCPバッチ → BigQuery
- データ対応トリガー: ファイル到着、APIイベント、上流ジョブの完了、バッチジョブのステータス
|
GCPバッチ |
スクリプト実行 · コンテナ実行 · ステータス監視 · 出力監視 · SLA調整 |
|
Cloud Storage |
ファイル到着 · 上流依存関係 · 下流リリース |
|
GCP Dataflow |
ジョブ実行 · ステータストラッキング · 依存関係調整 |
|
BigQuery |
クエリ実行 · 下流処理 · 依存関係調整 |
|
Airflow |
DAGオーケストレーション · ステータストラッキング · クロスツール依存関係 |
|
管理されたファイル転送 |
安全な転送 · ファイル到着検出 · 配送調整 |
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 Batchのステータスと出力をコンテキスト内で監視します。
GCP BatchはジョブステータスとCloud Loggingデータを公開しますが、生産サポートは多くのサービスにまたがることがよくあります。Control-MはGCP Batchの実行を上流および下流のジョブと同じ運用ビューに統合し、チームにトラブルシューティングのためのエンドツーエンドのコンテキストを提供します:
-
GCP Batch実行ステータス
-
ジョブの結果と出力
-
上流および下流の依存関係
-
Cloud Loggingの可視性
-
エンドツーエンドのワークフロー監視
SLA保証
GCP Batchジョブを超えた配信SLAを保護します。
GCP Batchはそのコンピュートワークロードの実行を管理しますが、周囲の企業プロセスの配信コミットメントを所有していません。Control-MはBatchの実行をエンドツーエンドのワークフロー依存関係とSLA管理に接続し、チームが完全なサービス結果を管理できるようにします:
-
エンドツーエンドのSLAトラッキング
-
クロスプラットフォーム依存関係の可視性
-
遅延ワークフローレス検出
-
制御された下流実行
-
集中操作監視
ドキュメント
複雑なワークフローを整える
Control-Mがチームに複雑なプロセスを可視化、調整、制御する方法を学ぶ。
