AWS Systems Manager の新しいコンポーネントは、インシデントの処理を支援することを目的としています。
AWS Systems Manager (旧称 SSM – Simple Systems Manager) は 2017 年に導入されましたが、実際には 2016 年後半にリリースされた EC2 Systems Manager にまで遡ります。
「これはEC2インスタンスを管理する方法として始まりました」とAWSのエバンジェリスト、ジュリアン・サイモン氏はThe Registerに語った。「例えば、EC2インスタンス群のパッチ適用状況を確認するといったことです。インスタンスが数個であれば手動でもできますが、LinuxとWindowsのインスタンスが100個もあるとなると、かなり難しくなります。」
現在のSystems Managerには、AWSリソースの整理、メンテナンスタスクのスケジュール設定、自動インベントリデータの収集、メトリクスとアラームの概要の表示などの機能があります。管理者はSSMドキュメントを介して複数のインスタンスに対してコマンドやスクリプトを実行することもできます。
SSM は EC2 インスタンスにインストールされたエージェントに依存しており、そのコードは GitHub でオープンソース化されています。
先週、AWSはSystems Managerに「Incident Manager」という新機能を追加しました。なぜIncident Managerなのでしょうか？「主な理由は、お客様がAWS上で完全に統合されたソリューションを求めているからです」とサイモン氏は述べています。
インシデントは、AWS モニタリングサービスである CloudWatch のアラーム、または EventBridge イベントバスを介して送信されたイベントによってトリガーされます。これらのイベントは、Incident Manager の対応計画をトリガーします。対応計画は、連絡先、エスカレーションプラン、ランブックの組み合わせです。
インシデントマネージャー...CloudWatchアラームから対応計画、修復、分析まで
AWS が示す例では、CloudWatch が EC2 VM の CPU 使用率が高いことを検出したときにイベントが生成されます。AWS ソリューションの Runbook は、応答者に連絡し、インスタンスを Auto Scaling グループにアタッチするための指示を提供します。
これは、eコマースサイトが注文しようとする顧客で溢れかえっている場合には有効な解決策となるでしょう。しかし、問題のあるプロセスが理由もなくCPUを消費している場合は、あまり効果的ではありません。対応担当者が盲目的にスケールアップしてAWSにさらなる費用をかけるのではなく、この問題に気付いてくれることを期待します。典型的なランブックには、トリアージ、診断、緩和、復旧の手順が記載されており、インシデント後レポートも含まれています。
誰のためのものですか?
インシデントマネージャーはエンドユーザー向けではなく、サポートケースではなく技術的なインシデントです。ただし、APIが用意されているため、必要に応じて他のシステムのサポートケースからインシデントをトリガーすることも可能です。また、Systems Managerの別の機能であるOpsCenterとの連携も可能で、OpsCenterは運用作業項目（OpsItem）（基本的には管理タスクのリスト）を管理するツールです。インシデントマネージャーは、識別したタスクに対してOpsItemを生成します。これらのOpsItemは、JiraやServiceNowなどのサードパーティのチケットシステムと同期できます。
インシデントマネージャーを完全に自動化し、問題を自動的に解決することは可能でしょうか？残念ながら、ランブックでコマンドを実行できるとしても、それは難しいでしょう。「複雑な問題の場合は、人間の専門家だけが解決できるでしょう」とサイモン氏は言います。
とはいえ、自動化されたプロセスでは「ログを収集し、ウェブサイトにメンテナンスページが表示されていることを確認するなど、初期段階の手順を実行できる」と同氏は付け加えた。
おそらく疑問なのは、Incident Manager が CloudWatch アラームによるエンジニアへの通知機能と比べてどれほどの価値をもたらすのかということです。CloudWatch は既に、EC2 インスタンスの再起動や自動スケーリングの設定といったアクションをトリガーする機能を備えています。
「私たちは常にまず基本的なバージョンを作り、それから顧客の意見を聞きます」とサイモン氏は語り、将来何を望むかと尋ねられると、条件付きのより洗練されたルール、つまり「もう少しインテリジェンスが、もう少し柔軟性が」あることを希望すると答えた。
「お客様へのアドバイスとしては、インシデント解決のためのベストプラクティスの構築に取り組んでおり、これはAmazonの大規模インシデント管理チームによって設計されているということです。AmazonとAWS内で何か問題が発生した際に、実際にそれらの大きな問題に対処しているのは、まさに彼らです」とサイモン氏は付け加えた。
彼はまた、数か月前に導入された AWS Fault Injector Simulator を使用するなどして、インシデント対応をテストする手段としてカオスエンジニアリングを推奨しました。
Incident Manager が優れたパフォーマンスを発揮するには、綿密な設定が不可欠です。課題は、CloudWatch のアラームを微調整し、エンジニアに必要な時に、しかも必要な時にのみアラートを通知するという最適な状態にすることです。2 つ目の課題は、何が問題なのかを正確に把握することです。多くの場合、根本原因が特定されれば、問題の解決は比較的容易です。®
