- 公開日
- 最終更新日
【OpsCenter】AWSのインシデント管理をもっとスマートに
この記事を共有する
目次
はじめに
こんにちは、サービスGの佐藤です。
今回は、AWSリソースを運用管理をする上で便利なOpsCenterについてまとめていきたいと思います。
AWS Systems Managerの一部として提供されているものですが、
割と目立たない場所（タブの下のほう）にあり、聞き馴染みのない方もいらっしゃるかもしれません。
本記事で、その概要と使われ方についてをハンズオンも交えて、 お伝えできればと思います。
本記事でわかること
- OpsCenterについての概要
- OpsCenterを使用した、タスク管理の自動化
- OpsCenterの設定・登録方法
こんな方におすすめ
- AWS運用を担当していて、インシデント管理を効率化したい方
- EC2やLambdaなどのリソースで自動復旧や通知を仕組み化したい方
- AWS Systems Managerの機能をもっと活用したいと考えている方
- 監査対応や履歴管理を強化したいインフラエンジニア・SREの方
OpsCenterとは
冒頭お伝えしたとおり、AWS Systems Managerの機能の一部として提供されており、
AWSリソース上で発生したインシデントを一元的に管理することができます。
OpsCenterは設定したインシデント毎にOpsItemsを発行し、
運用者がなにに対し、調査・解決を実施するべきかを記載します。
また、AWS Systems Manager Automationと紐づけることで、
インシデント発生後の自動対応の設定を行うことも可能です。
EventBridgeルールとAutomationを組み合わせることで、Runbookの自動実行も可能になります。
要するにインシデントに基づいて、
自動的にチケット（タスク）を作成＋RunBookでのタスク実行が可能になります。
より詳細は公式ドキュメントを参照ください。
https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/OpsCenter.html
ユースケース
上記の概要を踏まえると以下のようなユースケースが想定されます。
- EC2停止後、EventBridgeルールで停止を検知しOpsItemsを作成、復旧 ※1
- Lambdaの失敗をOpsItemsに記録し、対象のLambdaを絞りあてて調査を実施
- バッチ適用失敗をOpsItemsに登録し再度実行
※1 のちほどハンズオンで実施します。
自動検知→自動復旧を一連の流れで実施してくれるのも強みの一つですが、
OpsItemsの登録によってインシデント履歴が残せるのも大きなメリットの一つと思います。
また、OpsItemsは手動登録も可能となっており、
急遽発生するメンテナンス作業等についてもOpsItemsを発行・管理することで、
より運用を一元的に管理することが可能となると思われます。
実際に作成してみる
それでは実際にOpsCenterの設定を行っていきたいと思います。
今回はEC2の停止を検知し、OpsItemsとして登録し、復旧させるパターンを試してみます。
全体構成としては以下のようになります。
[EventBridgeルール] → [OpsItem作成] → [SSM AutomationでEC2起動]
事前準備：
- パブリックな環境でEC2を作成し、起動中である。
- EC2にSystems Manager Agentがインストール済みである。
- EC2にSSMアクセス権限（AmazonSSMManagedInstanceCore）が付与されている
- Automation実行用のIAMロール（AutomationAssumeRole）が作成済み
※上記手順については割愛します。
①EventBridgeルールを作成
EC2の停止を検知し、OpsItem作成するルールを作成します。
①-1 イベントパターンとしてEC2の停止を設定。
例）
{
"source": ["aws.ec2"],
"detail-type": ["EC2 Instance State-change Notification"],
"detail": {
"state": ["stopped"],
"instance-id": ["任意のインスタンスIDを指定"]
}
}
①-2 ターゲットの設定でSystems Manager OpsItemを選択する。
System Manager OpsItemを作成するためのロールの作成が必要になってきます。
※ターゲット作成時に自動的に新規作成することも可能です。
許可設定は以下のようになります。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:CreateOpsItem",
"ssm:AddTagsToResource"
],
"Resource": [
"arn:aws:ssm:*:*:opsitem/*"
]
}
]
}
設定後、Eventbrige Ruleのターゲットを確認すると、 opsitemが追加されています。
EC2を停止させ、5分ほど時間を置きOpsCenterを確認すると、 OpsItemの登録が確認できます。
②OpsItem登録後、停止したEC2を自動起動させる
②-1 OpsItem詳細からランブックを選択する
登録されたOpsitemを選択すると、ランブックが選択できます。
AWS側で用意されているランブックも選択可能ですが、
自身が作成したランブックも選択可能となります。
今回はカスタムランブックとして用意しておいた、
EC2-Autostartを選択します。
（対象EC2を起動させるものです。）
※作成されたOpsItemの詳細から実行させたいランブックが選択できる。
ランブックについて詳細は割愛しますが、大事になってくる箇所は以下です。
6行目：parametersでInstanceIdsを定義 ⇒実行前に入力するインスタンスIDをパラメータとして定義。 "type": "StringList"としているため、複数IDの受け渡しも可能となります。
18行目：mainSteps内で上記インスタンスID（パラメータ）を実際の起動対象のInstanceIdと定義。
{
"schemaVersion": "0.3",
"description":test
"assumeRole": "arn:aws:iam::{accountID}:role/｛ロール名｝",
"parameters": {
"InstanceIds": {
"type": "StringList"
}
},
"mainSteps": [
{
"name": "StartInstances",
"action": "aws:executeAwsApi",
"isEnd": true,
"inputs": {
"Service": "ec2",
"Api": "StartInstances",
"InstanceIds": "{{ InstanceIds }}"
}
②-2 選択したランブックを実行させる
オートメーションを実行するを選択します。
選択後の画面で先ほどのparametersの項目があるので、 復旧させたいインスタンスIDをここに入力します。
実行し、EC2を確認すると対象のインスタンスが起動していることがわかります。
ハンズオンは以上です。
まとめ
今回はEC2を例に簡単な例を取り上げてみました。
AWSリソース上でのインシデント管理をコンソール上で行い、
その後の対応方法も簡単にランブックを利用することでより一層、一元的な管理が行えそうです。
例えば、運用者はOpsItemを確認し問題なければ、
決められたランブックを実行するだけで対応が済むなど運用手順の簡素化にもつながるかなと感じました。
以上です。
この記事は私が書きました
佐藤 祐弥
記事一覧日々の業務上での学びをコツコツアウトプットできればなと思います。
