ご要望またはご協力できることがございましたらお気軽にお問い合わせください
一般的なお問い合わせと所在地情報
お問い合わせ
Control-M + Kubernetes
あなたのKubernetesワークフローは、単一のポッドが実行される前から始まります—そして、上流で何かが壊れると失敗する可能性があります。ジョブが読み取るファイルがS3に到達しなかった。フィードしているSparkの変換が長引いてウィンドウを逃しました。Control-Mは、ファイル到着、上流変換、Kubernetesジョブ実行、下流のデリバリーという完全な連鎖をオーケストレーションします。
一般的なワークフローの問題
これがあなたの週のように聞こえますか？
これらはエッジケースではありません。複数のツールでKubernetesワークロードを実行しているチームにとって、通常の運用条件です。Control-Mがそれぞれをどのように処理するかを見てみましょう。
ポッド依存関係
ジョブがデプロイされました。上流データのロードは終了していません。
Kubernetesはワークロードを正常に起動しますが、必要な上流プロセスはまだ実行中です。Control-Mは実行前にクロスプラットフォームの依存関係を評価し、早すぎるポッドの起動を防ぎ、必要な前提条件が不足していることによる失敗を排除します。
失敗回復
コンテナが午前2時13分にクラッシュしました。誰も気づきませんでした。
Control-MはKubernetesのジョブ完了状態と失敗条件をリアルタイムで監視します。自動再試行、エスカレーションポリシー、および回復ワークフローが即座に実行され、手動介入を減らし、インシデント解決時間を短縮します。
クロスプラットフォームフロー
AWSが終了しました。Kubernetesが実行されました。下流APIが失敗しました。
マルチプラットフォームのワークフローは、単一のツール内で失敗することはほとんどありません。Control-Mはクラウドサービス、Kubernetesクラスター、API、データベース、およびファイル転送全体での実行を追跡し、孤立したトラブルシューティングではなく、調整された回復を提供します。
SLAリスク
デプロイメントは成功しました。ビジネスの締切は守れませんでした。
健全なKubernetesジョブはワークフローの完了を保証しません。Control-MはエンドツーエンドのSLAパフォーマンスを追跡し、違反が発生する前に予測し、修復オプションがまだ利用可能な状態でチームに警告します。
環境のスプロール
3つのクラスター。2つのクラウド。1つのプロダクションインシデント。
Control-MはKubernetes環境全体にわたって中央集権的な可視性を提供します。クラスターの場所に関係なく、チームは依存関係、実行履歴、アラート、およびワークフローの状態を単一のオーケストレーションレイヤーから管理できます。
統合の事実
Control-M + Kubernetes
|
APIおよび自動化機能 |
Kubernetes API · REST API · イベント駆動型自動化 · Webhookトリガー · RESTジョブ実行 · インフラストラクチャワークフローオーケストレーション |
|
デプロイメントモデルとインフラストラクチャの柔軟性 |
SaaS · オンプレミス · ハイブリッドクラウド · マルチクラスタKubernetes · コンテナ化デプロイメント · パブリッククラウド · プライベートクラウド |
|
セキュリティ姿勢 |
RBAC · LDAP統合 · SAML/SSO · シークレット管理統合 · 転送中の暗号化 · 保存時の暗号化 · 監査ログ |
|
インシデントレスポンスとMTTRの有効化 |
構成可能なバックオフによる自動再試行 · 失敗状態検出 · SLA違反アラート · PagerDuty統合 · ServiceNow統合 · 自動修復ワークフロー |
エンドツーエンドオーケストレーション
1つの生産ワークフロー。スタック内のすべてのツール。
Control-Mは、Kubernetes、Jenkins、GitHub Actions、Terraform、クラウドサービス、API、ファイル転送を1つのジョブフローでオーケストレーションします—すべての依存関係追跡、SLAの可視性、自動回復を伴います。
- ツール間依存関係: GitHub Actions → Terraform → Kubernetesデプロイメント → API検証
- データ認識トリガー: ファイル到着、APIイベント、デプロイメント完了、ワークロード終了状態
|
Kubernetes |
ジョブ実行 · ワークロード監視 · 完了状態追跡 · 失敗処理 |
|
Jenkins |
パイプライントリガー · ステータス追跡 · デプロイメント調整 |
|
GitHub Actions |
ワークフロートリガー · CI/CD依存関係管理 · 完了イベント |
|
Terraform |
インフラストラクチャプロビジョニング · 依存関係制御 · 環境準備 |
|
AWS |
クラウドサービスオーケストレーション · イベント調整 · ワークロード依存関係 |
|
ServiceNow |
変更承認 · インシデント作成 · ワークフローエスカレーション |
|
PagerDuty |
アラートルーティング · オンコール通知 · 自動エスカレーション |
エアフロー共存
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 は書き換えたり移行したりする必要はありません
ワークロードを監視する
すべての依存関係にわたる Kubernetes 実行を監視します。
Kubernetes はクラスター内のワークロードの可視性を提供しますが、生産ワークフローはそれを超えて拡張します。Control-M は、インフラストラクチャ、自動化ツール、クラウドサービス、および Kubernetes 実行状態全体にわたる中央集権的な運用ビューを提供します:
-
ジョブ実行状況
-
ポッド完了追跡
-
クロスツール依存関係
-
実行時履歴
-
SLA リスク指標
SLA 保証
Kubernetes ワークフローをスケジュール通りに保つ。
Kubernetes はワークロードの状況を報告しますが、ビジネスレベルの納品義務を管理しません。Control-M は、すべての依存システムにわたるワークフローの完了を追跡し、SLA リスクを予測し、締切を逃す前に回復アクションを開始します:
-
SLA 違反予測
-
自動エスカレーション
-
締切追跡
-
依存関係を考慮した回復
-
優先度に基づくアラート
ドキュメント
複雑なワークフローに秩序をもたらす
Control-M が、チームがより大きな可視性、調整、および制御を持って複雑なプロセスをオーケストレーションするのをどのように支援するかを学ぶ。
