ご要望またはご協力できることがございましたらお気軽にお問い合わせください
一般的なお問い合わせと所在地情報
お問い合わせ
Control-M + GCP Functions
あなたのGCP Functionsのワークフローは、HTTP関数の呼び出しが実行される前に始まります — そして、何か上流で破損すると失敗する可能性があります。Google Cloud Storageオブジェクトが遅れて到着します。GCP Dataflowジョブが処理ウィンドウを逃します。Control-Mは完全なチェーンを調整します：Google Cloud Storageの到着、GCP Dataflowの処理、GCP Functionsの実行、そして下流のデリバリー。
一般的なワークフローの問題
これはあなたの週間のようですか？
これらは端のケースではありません。それらは複数のツールでGCP Functionsワークフローを実行しているチームの通常の運用条件です。Control-Mがそれぞれをどのように処理するかは次のとおりです。
上流依存関係
あなたの Dataflow ジョブは遅れて終了しました。関数はまだ安全に実行できません。
Control-M は上流の GCP Dataflow ジョブを明示的な依存関係として追跡し、その前提条件が成功裏に完了したときにのみ GCP 関数のジョブをリリースします。これにより、切り離されたスケジュールや手動介入に依存することなく、実行順序が決定的に保たれます。
呼び出し失敗
関数が呼び出されました。プロダクションは結果を待っています。
Control-M は GCP 関数のジョブステータスを構成可能な頻度でポーリングし、障害許容を適用し、結果として得られるジョブ状態を広範なワークフローに反映します。これにより、失敗した呼び出しの後に依存するプロダクションステップが続行されるのを防ぎます。
認証失敗
IAMの変更が行われました。あなたの午前2時の関数呼び出しは停止しました。
Control-M はサービスアカウントまたは IAM 認証を使用した管理された GCP 関数接続プロファイルを使用します。資格情報は外部ボールトを通じて取得でき、オーケストレーションロジックとシークレットを分離し、認証の失敗を運用上簡単に孤立させることができます。
トラブルシューティングの遅延
関数が失敗しました。現在、3つのチームがコンテキストを探しています。
Control-Mは、GCP Functionsのログをジョブ出力に取得し、ステータス、結果、および周囲のワークフロー依存関係を同じ運用ビューで表示します。これにより、応答者は別々のコンソールを介してエンドツーエンドのシーケンスを再構築することなく、実行コンテキストを得ることができます。
SLAリスク
関数は05:42に成功しました。しかし、ビジネスの締切は依然として遅れました。
Control-Mは、GCP FunctionsジョブをエンドツーエンドのサービスSLAに接続し、関数の成功を終了ラインとして扱うのではなく、チームがより広いワークフローへの貢献を確認できるようにします。これにより、下流の配信が目標を逃す前に対応できます。
Control-M + GCP Functions
Control-M + GCP Functions
|
APIと自動化機能 |
ジョブ:GCP Functions · Automation API REST API · Automation API CLI · JSONジョブ定義 · URLパラメータ · JSONボディパラメータ · Cloud Functions API V1 · Cloud Functions API V2 |
|
デプロイメントモデルとインフラストラクチャの柔軟性 |
Control-M SaaS · Linuxエージェントプラグイン · Windowsエージェントプラグイン · 中央集権的接続プロファイル · GCP Functionsエンドポイント · Automation APIプロビジョニング（ctmプロビジョンイメージ） · エージェント9.0.21.000+ |
|
セキュリティ姿勢 |
GCPサービスアカウント認証 · IAMロール認証 · セキュア接続プロファイル · 外部ボールト統合 · サービスアカウントキー · GCPアクセス制御（サービスアカウント/IAM） · HTTPS APIエンドポイント |
|
インシデント応答とMTTRの有効化 |
設定可能なステータスポーリング · 障害耐性 · 関数ログの取得 · ジョブのステータスと出力 · クロスワークフロー依存関係の制御 · SLAジョブの添付 |
エンドツーエンドオーケストレーション
1 つのプロダクションワークフロー。スタック内のすべてのツール。
Control-Mは、GCP Functions、GCP Workflows、GCP Dataflow、BigQuery、Google Cloud Storage、およびGCP Composer全体でワークフローを調整します — 依存関係の追跡、SLAの可視性、および自動回復を含む一つのジョブフローで。
- クロスツール依存関係: Google Cloud Storage → GCP Dataflow → GCP Functions → GCP Workflows
- データ認識トリガー: Google Cloud Storageオブジェクトの到着、APIイベント、GCP Dataflowの完了、上流ジョブの終了状態
|
GCP Functions |
関数呼び出し · URL/ボディパラメータ · API V1/V2 · ステータスポーリング · ログ取得 |
|
GCP Workflows |
ワークフロー実行 · JSONパラメータ · 実行ステータス · ワークフロー結果 · 依存関係調整 |
|
GCP Dataflow |
クラシック/フレックステンプレート実行 · ジョブモニタリング · 出力取得 · SLA調整 |
|
BigQuery |
クエリ実行 · テーブルロード · 抽出 · ルーチン · ワークフロー依存関係 |
|
Google Cloud Storage |
オブジェクトウォッチ · クラウドファイル転送 · 到着依存関係 · 管理されたデリバリー |
|
GCP Composer |
DAG 実行 · パラメータ · タスク出力 · DAG ステータストラッキング |
ワークフローを監視する
GCP 関数の実行を完全なワークフローのコンテキストで表示
Google Cloud は関数レベルの実行情報を公開しますが、プロダクションインシデントは通常 1 つのサービス境界で停止しません。Control-M は GCP 関数のステータス、結果、出力、および周囲の依存関係を運用ワークフローのビューに取り込み、チームが何が実行され、何が次に待機しているかを迅速に把握できるようにします：
-
関数実行ステータス
-
関数の結果と出力
-
上流および下流の依存関係
-
集中運用ワークフローの可視性
SLA 確保
エンドツーエンドサービスの締切に対して GCP 関数を管理する
関数の成功した呼び出しは、ビジネスサービスが時間通りに終了することを証明するものではありません。Control-M は GCP 関数の実行をより広範なサービス SLA に接続し、運用チームに下流のデリバリーに影響を与える前に遅延を特定するために必要なワークフロー レベルのコンテキストを提供します：
-
エンドツーエンド SLA トラッキング
-
予測 SLA 遅延検出
-
クロスプラットフォーム依存関係の可視性
-
自動化された障害処理
ドキュメント
複雑なワークフローに秩序をもたらす
Control-M がチームがより大きな可視性、調整、および制御で複雑なプロセスをオーケストレーションするのにどのように役立つかを学ぶ。
