この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちはオンジー(@onzuka_muscle)です！！
Amazon DevOps GuruがGAされていたので有効化してみました。
AWS re:Invent 2020 で発表されたサービスで、この時はまだプレビューでしたが今はGAされて利用できるようになっています。
Amazon DevOps Guruとは
Amazon DevOps Guruは、「アプリケーションの運用パフォーマンスと可用性を簡単に向上させる、機械学習 (ML) を利用したサービスです。DevOps Guru は、通常の運用パターンから逸脱した動作を検出するため、顧客に影響を与える前に迅速に運用上の問題を特定できます。」(公式引用)
これだけだとちょっとイメージがつかないのでよくある質問を見てみましょう。
Q: Amazon DevOps Guru はどのような種類の問題を検出できますか?
A: Amazon DevOps Guru は、アラームの欠落や設定ミス、リソース枯渇の早期警告、停止につながる可能性のあるコードと構成の変更などの運用上の問題を自動的に検出できます。DevOps Guru は、ML を使用してメトリックの異常を運用イベントと相関させ、適切な修復手順に専念できるコンテキストインサイトを提供します。DevOps Guru は、ウェブアプリケーションのレイテンシー急上昇、ディスクスペースの不足、不正なコードのデプロイメント、メモリリークなど、関連するアプリケーションとインフラストラクチャの指標を相互に関連付けてグループ化し、誤った冗長なアラームを減らして、重大度の高い問題に集中できるようにします。
Q: Amazon DevOps Guru はどの監視サービスと連携していますか?
A: Amazon DevOps Guru は、起動時に Amazon CloudWatch、AWS Config、AWS System Manager Ops Center、AWS CloudFormation、および AWS X-Ray からのデータを使用できます。Amazon DevOps Guru は、Atlassian OpsGenie や Pager Duty などのパートナー運用監視およびインシデント管理ソリューションとも統合されています。
Amazon CloudWatch や AWS Config といったサービスをAWSが長年培ってきたデータをもとに分析して運用上の問題を検出し修復についてアドバイスしてくれるサービスのようです。
用語(インサイト)
インサイトは、DevOps Guruの設定時に指定したAWSリソースの分析中に作成される異常値の集まりです。
各インサイトには、運用パフォーマンスを向上させるために使用できる分析結果、レコメンデーション、および分析データが含まれています。
インサイトには次の2つのタイプがあります。
- 事後的(リアクティブ)：異常が発生したとき
- 予測的(プロアクティブ)：異常な行動が発生する前
実際に異常が発生したときだけではなく、事前に予測するような分析結果も出してくれるんですね。
有効化してみる
とにかく触ってみましょう。といってもポチポチするだけで超簡単です。
「ご利用開始にあたって」をクリックします。
作成されるIAMロールの詳細が表示されます。
これらのサービスを分析対象にしているんですね。
ポリシーの中身
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"autoscaling:DescribeAutoScalingGroups",
"cloudtrail:LookupEvents",
"cloudwatch:GetMetricData",
"cloudwatch:ListMetrics",
"cloudwatch:DescribeAnomalyDetectors",
"cloudwatch:DescribeAlarms",
"cloudwatch:ListDashboards",
"cloudwatch:GetDashboard",
"cloudformation:GetTemplate",
"cloudformation:ListStacks",
"cloudformation:ListStackResources",
"cloudformation:DescribeStacks",
"cloudformation:ListImports",
"codedeploy:BatchGetDeployments",
"codedeploy:GetDeploymentGroup",
"codedeploy:ListDeployments",
"config:DescribeConfigurationRecorderStatus",
"config:GetResourceConfigHistory",
"events:ListRuleNamesByTarget",
"xray:GetServiceGraph"
],
"Resource": "*"
},
{
"Sid": "AllowPutTargetsOnASpecificRule",
"Effect": "Allow",
"Action": [
"events:PutTargets",
"events:PutRule"
],
"Resource": "arn:aws:events:*:*:rule/DevOps-Guru-managed-*"
},
{
"Sid": "AllowCreateOpsItem",
"Effect": "Allow",
"Action": [
"ssm:CreateOpsItem"
],
"Resource": "*"
},
{
"Sid": "AllowAddTagsToOpsItem",
"Effect": "Allow",
"Action": [
"ssm:AddTagsToResource"
],
"Resource": "arn:aws:ssm:*:*:opsitem/*"
},
{
"Sid": "AllowAccessOpsItem",
"Effect": "Allow",
"Action": [
"ssm:GetOpsItem",
"ssm:UpdateOpsItem"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/DevOps-GuruInsightSsmOpsItemRelated": "true"
}
}
}
]
}
分析カバレッジと通知先のSNSトピックを指定できます。
分析カバレッジは指定した「CloudFormation のスタックによって作成されたリソースに分析対象を絞る(複数選択可)」か、それとも絞らずに「そのアカウントのそのリージョンに存在するリソース全体を分析するか」選ぶオプションになります。
料金を気にする場合はスタックを個別に指定しましょう！
今回は一旦「すべて」を対象にしました。
ちなみにスタックの選択画面はこんな感じで後からいつでも変更可能です。
最後に有効化ボタンをクリックしたら完了です。簡単ですね。
なお分析完了するまでは待つ必要があります、僕の場合はリソースが少なかったので1〜2時間でしたが実環境では24時間程度かかる可能性もあるとのことです。
この分析によってベースラインが設定されて、そこから大きく外れる=異常があるといった判定になるようです。
ダッシュボードに結果が表示されました。特になんの異常も出ていないです。
異常を発生させる
流石にこれではつまらないので異常を検知してもらいインサイトがどんな風に表示されるのか見てみましょう！
なお、以下で表示しているのは事後的(リアクティブ)なインサイトです。
(自分で運用上の問題を発生させようとEC2に負荷をかけたりしてみたのですが上手くいかなかったので下記の記事に沿って進めました。)
本記事ではどんな風に分析結果が出たかをお見せするだけなので詳細な再現手順は説明しません。もし自分で試してみたい方こちらの記事の手順をご参考ください。
(引用)Gaining operational insights with AIOps using Amazon DevOps Guru
こちらの構成のリソースで異常を発生させます。HTTPでリクエストを投げるとDyanamoDB内のデータを返すという単純なアプリケーションです。
DynamoDB テーブルのReadCapacityUnits(RCU)を下げた状態で大量のリクエストを投げます。
(ウィンドウをたくさん開いてpythonでHTTPリクエストを投げまくっています。)
RCUを下げたので捌き切れずに502がちょこちょこと返ってきています。
リクエストを投げ続けたまま10分ほど待つとインサイトが出ました！早速、中を見てみましょう。
インサイトの概要と異常だと判断される根拠となったメトリクスがグラフで分かりやすく表示されています！
こちらは分析対象になっているCloudWatch メトリクスに対応しています。
またメトリクスの名前、リソースタイプ、CloudFormation スタックでのフィルタリングもできます。
別タブのグラフに切り替えてみましょう
今度はメトリクスごとに波線グラフで表示されました。
異常なレベルに達していた時間が赤く塗られていて見やすい！
各グラフを拡大して見ることもできます。
グラフの幅を変更したりCloudWatch メトリクスへのリンクもあります。
次はイベント情報を見てみましょう。こっちはCloudTrailに対応している情報ですね。
イベントとインサイトの時間を並べてくれます。
発生時間に近いイベントがすぐわかるのでこれは怪しいというイベントがパッと見で分かりますね！これは熱い。
今回、異常を発生させるために僕がスタックをUpdateしたのでまさにこのイベントが原因ですね。
誤操作やリソース変更の思わぬ影響が原因だった場合のトラブルシューティングがとても捗りそうです。
次はレコメンデーション見てみましょう。
レコメンデーションの情報が何個か表示されています。
どのメトリクスやイベントを分析した結果のレコメンデーションか説明されており、ものによってはドキュメントへのリンクもありました。
これらを調査の糸口にCloudWatchやCloudTrailを見にいくことでトラブルシューティングが捗りそうです！！
SNS通知
SNSトピックに通知先として登録していたメールアドレスにはインサイトが生成されたタイミングでこのような通知がきました。
各メトリクスの異常ごとにメールがくるので結構な量がどさっときます。
{
"AccountId": "XXXXXXXXXXX",
"Region": "ap-northeast-1",
"MessageType": "NEW_ASSOCIATION",
"InsightId": "AERaw7gP6rSXYJQ8SJMdarQAAAAAAAAAANb_epyVoK7BH_yN4cvK5FybDAYVoZcI",
"InsightDescription": "Latency",
"StartTime": 1622539920000,
"Anomalies": [
{
"Id": "AA0blHs2HetKFBuMW6IFc88AAAF5xupigOzoAEtUVOAadbGXDC3BsuAD4nB7F3Fg",
"StartTime": 1622539920000,
"SourceDetails": [
{
"DataSource": "CW_METRICS",
"DataIdentifiers": {
"namespace": "AWS/ApiGateway",
"name": "Latency",
"stat": "p50",
"unit": "None",
"period": "60",
"dimensions": "{\"ApiName\":\"ListRestApiMonitorOper\",\"Stage\":\"prod\"}"
}
}
]
}
],
"awsInsightSource": "aws.devopsguru"
}注意：通常の監視用のダッシュボードとは違って「異常」があるときだけ
多くの監視ツールとは異なり、DevOps Guru はダッシュボードが継続的に監視されることを想定していないため、通常のシステム正常性では、ダッシュボードは進行中のインサイトに対してゼロのカウンターを表示するだけです。
異常が検出された場合にのみ、アラートを発生させ、ダッシュボードにインサイトを表示します。
補足
料金
二つの課金対象があります。(以下は2021/6/1時点の情報)
- AWSリソース分析
- リソース料金グループ A(S3,Lambda) リソースあたり 0.0028 USD/1 時間
- リソース料金グループ B(それ以外) リソースあたり 0.0042 USD/1 時間
- DevOps Guru API 呼び出し
- API 呼び出しごとに 0.000040 USD (API 呼び出しが 10,000 件の場合は 0.40 USD)
料金試算ツール
分析カバレッジと同様、「スタック指定」か「そのアカウントのそのリージョンのリソース全体」かを選べます。
今回、検証で使ったスタック(Amazon API Gateway, AWS Lambda, Amazon DynamoDB)を指定して実行してみました。
このくらいのリソース量でも試算が終わるまで結構時間がかかりました。(1時間くらい？)
月当たり約8.0USDでした。
大量のリソースを分析対象にすると結構な課金になりそうですね。
コスト見積もりツールの活用と、可能であればスタック指定での分析をしましょう。
対応リージョン
よくある質問から抜粋してきました(2021/6/1時点)。
東京リージョンは使えますね。
Q: Amazon DevOps Guru はどの AWS リージョンで利用できますか?
A: Amazon DevOps Guru は、本日、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ストックホルム)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、およびアジアパシフィック (東京) の AWS リージョンでご利用いただけます。また、近日中に追加のリージョンで利用可能になる予定です。AWS リージョンサービス一覧を参照することもできます。
おわり
触ってみた感想ですが関連性の高い情報(メトリクス・イベント)がグラフで表示されるのは調査がラクになるので最高ですね！
また今回はお見せできてないですが予測的(プロアクティブ)なインサイトでインシデント・障害の予兆をキャッチして先手を打つといった使い方もできるのは熱い。
既存の運用を置き換えられるかどうかは分かりませんが、そこは「まずは試しに使って評価してみる」がクラウドの良さなので積極的に使って試してみてはいかがでしょうか？
また有効化がとても簡単なので通常の監視と併用でとりあえず使ってみるのもありなサービスだと思います。
スタック一つから料金試算ツールでコストをだいたい把握してから早速有効化してみましょう。
2021/5にGAされたばかりですのでこれからの活用事例が楽しみですね。
参考
3
