Control-M + Argo Workflows

あなたのArgo Workflowsランは、Kubernetesネイティブワークフローが実行される前に開始されます — そして、何か上流で壊れると失敗する可能性があります。到着しないS3入力アーティファクト。完了ウィンドウを逃すKubernetesジョブ。Control-Mは、S3アーティファクトの到着、Spark変換、Argo Workflowの実行、およびSnowflakeのロードの全チェーンを調整します。

あなたのようなパイプラインで見る統合事実を見る

一般的なワークフローの問題

これはあなたの週のようですか？

これらはエッジケースではありません。これらは、複数のツールでArgoワークフローパイプラインを運用しているチームにとっての通常の運用条件です。Control-Mがそれぞれをどのように処理するかは以下の通りです。

上流依存関係

あなたのArgoワークフローは準備完了です。S3入力アーティファクトがありません。

Control-Mは、必要な上流デリバリーが完了するまでArgoワークフローを保持し、その後ワークフローを順次提出します。クロスツールの依存関係により、Kubernetesコンピュートは不足している入力に対して開始できず、前提条件が満たされるまで生産パイプラインは進行しません。

ワークフローフェイル

ワークフローが02:14に失敗しました。下流処理はまだキューに入っています。

Control-Mはワークフローの状態を監視し、失敗が発生した場合にArgoワークフローを自動的に再試行できます。構成可能なポーリングと障害耐性が検出を管理し、下流の依存関係はArgo実行が必要な状態に達するまでゲートされます。

パラメータドリフト

ワークフローが開始されました。生産実行は順序を維持する必要があります。

Control-Mは、調整されたジョブフローの一部としてArgoワークフローを提出し、ワークフローの実行を手動起動ステップではなく生産スケジュールの一部にします。チームは、同じ生産実行に依存する上流ジョブや下流プロセスとArgoの実行を調整できます。

SLAリスク

DAGが実行中ですが、06:00のデリバリーが遅れています。

Control-Mは、Argoジョブをエンドツーエンドの生産ワークフロー内に配置するため、デリバリーに対するその貢献が広範なスケジュール内で追跡されます。オペレーションチームは、下流の消費者が影響を受けた後に遅延を発見するのではなく、ビジネスプロセスの文脈でワークフローを見ることができます。

回復制御

ワークフローには介入が必要です。誰もKubernetes状態を手動で編集してはいけません。

Control-Mは、Hold、Release、Stop、およびTerminateを含むArgoワークフロー操作を公開し、Retryアクションも提供します。オペレーターは、Kubernetesワークフローの前後のジョブとの調整を維持しながら、生産オーケストレーションレイヤーを通じて回復を制御できます。

Control-M + Argo workflows

ワークロードタイプ	Argo Workflowを提出 · Argo Workflowを監視 · Kubernetesネイティブワークフロー · ワークフローの再試行 · ワークフロー状態操作（保留 · 解放 · 停止 · 終了）
トリガータイプ	高度なスケジューリング基準 · 上流ジョブの完了 · Control-M依存関係 · Control-M変数
ツール間依存関係	Kubernetesワークフロー · S3アーティファクト配信 · Spark処理 · Snowflakeジョブ · データベースジョブ · ファイル転送 · REST API呼び出し
クラウドプラットフォーム	Kubernetes · Amazon EKS · Azure Kubernetes Service · Google Kubernetes Engine · オンプレミスKubernetes · アクセス可能な任意のArgo Workflowsエンドポイント
エラーハンドリング	ワークフローの再試行 · 設定可能な障害耐性 · 設定可能なステータスポーリング · 保留 · 解放 · 停止 · 終了
スループット	ワークフロー単位の提出 · Kubernetesネイティブワークフローの実行 · 設定可能なステータスポーリング · 中央集権的なマルチワークフローのスケジューリング
可観測性	ワークフローの状態 · 結果 · 出力 · エンドツーエンドの依存関係の可視性 · Control-M監視

エンドツーエンドオーケストレーション

1つのプロダクションワークフロー。スタック内のすべてのツール。

Control-Mは、Argo Workflows、Kubernetes、Spark、Snowflake、ファイル転送、およびクラウドサービスを単一のジョブフローで調整します — 依存関係の追跡、SLAの可視性、および自動リカバリをすべて実現します。

ツール間依存関係：Spark → Argo Workflow → Snowflake → 分析ハンドオフ
データ対応トリガー：ファイル到着、APIイベント、上流ジョブの完了、ワークフレス結果

すべての統合を見る

Argo Workflows	ワークフローの提出 · 状態監視 · 再試行 · 状態操作（保留 · 解放 · 停止 · 終了）
Kubernetes	コンテナ化されたワークロードの実行 · 名前空間の調整 · ワークフローインフラストラクチャ
Apache Spark	データ処理 · 変換ジョブ · 上流依存関係の調整
Snowflake	データロード · SQL実行 · 下流分析依存関係
Amazon S3	アーティファクトの到着 · オブジェクトの配信 · パイプライン入力の調整
ファイル転送	管理された配信 · 到着依存関係 · 下流ハンドオフ
REST API	サービスの呼び出し · レスポンス駆動の依存関係 · アプリケーションハンドオフ

パイプラインを監視する

Argoワークフローステータス、結果、および出力を中央で監視

ArgoはそのKubernetesワークフロー内部で何が起こっているかを示します。プロダクションデータパイプラインはその境界を超えて拡張します。Control-Mは、Argoの実行を周囲のジョブや依存関係とともに中央集中的に監視し、チームに次のもののオペレーショナルビューを提供します:

ワークフロー実行ステータス
結果とワークフロー出力
Argoノードの詳細
上流および下流の依存関係
エンドツーエンドのプロダクションワークフロー状態

SLA保証

ArgoパイプラインをデリバリーSLAに整合させる

成功したDAGは、上流の入力が遅れたり、下流の処理が停止した場合でも、遅いビジネス結果に寄与する可能性があります。Control-Mは、Argoの実行を広範なプロダクションスケジュールに接続し、チームが次のものを通じて配信パフォーマンスを管理できるようにします:

エンドツーエンドのワークフロー依存関係
プロダクションスケジュール内のArgo実行
高度なスケジューリング基準
調整された障害回復
下流ワークロードの実行

ドキュメント

ArgoワークフローとControl-Mの統合

複雑なワークフローに秩序をもたらす

Control-Mがチームにどのように可視性、調整、および制御を強化して複雑なプロセスをオーケストレーションするのかを学ぶ。

コンサルテーションをスケジュールセルフガイドデモを始める

ワークフローオーケストレーション

メインフレーム簡素化