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

これはあなたの週のように聞こえますか?

これらはエッジケースではありません。これらは、複数のツールでAWS Auto Scaling Groupワークフローを実行しているチームにとっての通常の運用条件です。Control-Mが各ケースをどのように処理するかをご覧ください。

デプロイメントタイミング

あなたのビルドは02:14に終了しました。EC2インスタンスはまだ停止しています。

Control-Mは成功した上流の完了を検知し、依存関係を評価し、必要なEC2インスタンスをオートスケーリンググループで自動的に起動します。インフラストラクチャ活動は切り離されたスケジュールではなくワークフローの状態から始まり、手動の引き継ぎや回避可能なデプロイメントの遅延を排除します。

失敗した操作

AWSが503を返しました。あなたの夜間インフラワークフローが停止しました。

Control-MはAWS Auto Scaling Groupsのジョブ実行を監視し、失敗を即座に浮き彫りにし、標準のControl-M On-Doアクションと再試行ロジックを適用して、一時的な問題がワークフローを通じて処理されるようにし、オペレーターが停滞したインフラを手動で発見し再起動することを避けます。

インスタンス制御

メンテナンスは真夜中に始まります。誤ったEC2インスタンスがまだ稼働しています。

Control-Mは、AWS Auto Scaling Groupの操作を調整し、グループの作成、更新、記述、およびインスタンスの詳細を取得するなど、スケジュールされたワークフローの一部として、インスタンスレベルの起動/停止/再起動アクションのためにAmazon EC2との統合と調整します。

ツール間依存関係

あなたのアプリケーションは準備完了です。インフラの前提条件が40分遅れて終了しました。

Control-MはAWS Auto Scaling Groupsのジョブをアプリケーション、データ、ファイル転送、クラウドジョブと同じワークフロー内に配置します。複雑な依存関係がインフラアクションが進行できるタイミングを決定し、必要な上流条件が実際に満たされるまで下流の実行を防ぎます。

SLAリスク

すべてのAWS操作が成功しました。あなたの生産準備の締切はまだ遅れました。

個々のAWS操作が成功する一方で、エンドツーエンドのワークフローがまだ遅れていることがあります。Control-MはAWS Auto Scaling GroupsのジョブにSLA管理を割り当て、より広範な依存関係チェーンを監視し、運用チームが遅延した引き渡しがビジネスの締切を逃す前にスケジュールリスクを特定できるようにします。

Control-M + AWS Auto Scaling Groups

Control-M + AWS Auto Scaling Groups

APIおよび自動化機能

Control-M Automation API · ジョブ: AWS Auto Scaling Groups · Auto Scaling Groupの作成 · Auto Scaling Groupの更新 · Auto Scaling Groupの説明 · ライフサイクルフェーズ全体でのインスタンスIDリストのリアルタイム取得 · 実行前後のステップ · 条件付きロジック · REST API設定

デプロイメントモデルとインフラの柔軟性

Control-M SaaS · Control-M自己管理 · Linuxエージェント · Windowsエージェント · 地域AWSエンドポイント

セキュリティ姿勢

AWS IAM認証 · AWSキーとシークレット(標準認証) · 中央集権的接続プロファイル

インシデント対応とMTTRの有効化

ジョブの状態/結果/出力監視 · ライフサイクルフェーズ全体でのインスタンスIDリストの取得 · SLAの添付

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

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

Control-MはAWS Auto Scaling Groups、Amazon EC2、AWS CodeBuild、Amazon S3、ファイル転送、クラウドサービス全体でのワークフローを1つのジョブフローで調整します — 依存関係の追跡、SLAの可視性、自動回復を伴います。

  • クロスツール依存関係: AWS CodeBuild → AWS Auto Scaling Groups → EC2インスタンス操作 → アプリケーションの検証
  • データ対応トリガー: ファイル到着、APIイベント、ビルド完了、上流ジョブ完了

AWS Auto Scaling Groups 

グループの作成 · グループの更新 · グループの説明 · インスタンスIDリストの取得 · 状態監視

Amazon EC2 

インスタンスの調整 · 開始/停止/再起動/終了 · インフラ依存関係の管理

AWS CodeBuild 

ビルドオーケストレーション · 完了依存関係 · 下流インフラの引き渡し

Amazon S3 

オブジェクト到着依存関係 · ワークフローのトリガー · 下流の調整

AWS Lambda 

ファンクション実行 · ワークフローディペンデンシー · ダウンストリーム処理

ファイル転送 

管理された転送 · 到着検知 · デリバリーディペンデンシー

Control-M 

スケジューリング · 複雑な依存関係 · リソースプール · リソースのロック · 変数 · SLA管理

tbd

インフラストラクチャを監視する

AWSオートスケーリンググループの操作をエンドツーエンドで監視する。

AWSはインフラストラクチャの状態を公開しますが、プロダクションワークフローは単一のスケーリンググループやEC2操作を超えて拡張します。Control-MはAWSオートスケーリンググループのジョブをその上流および下流の依存関係と共に中央集約し、プラットフォームチームに実行の1つの運用ビューを提供します:

  • ジョブ実行ステータス

  • 結果と出力の監視

  • クロスプラットフォームの依存関係の可視性

  • インフラストラクチャワークフローの履歴

  • エンドツーエンドSLAコンテキスト

TBD

SLA保証

インフラストラクチャワークフローをプロダクションの締切に合わせて保つ。

AWSはインフラストラクチャの操作を成功として報告できますが、完全なプロダクションワークフローが時間内に終了するかどうかはわかりません。Control-MはエンドツーエンドのSLA管理、依存関係を考慮したスケジューリング、周囲のワークフロー全体にわたる自動失敗処理を追加します:

  • エンドツーエンドSLA追跡

  • 複雑な依存関係管理

  • 設定可能な失敗再実行

  • 検証ポーリングコントロール

  • 調整された下流実行

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

Control-Mがチームがより大きな可視性、調整、コントロールで複雑なプロセスをオーケストレーションするのにどのように役立つかを学ぶ。