クールなグルーをブログル（Amazon DevOps Guru）

# 前書き

本記事はJapan APN Ambassador Advent Calendar 2020の23日目の記事です。
APN Ambassadorとは？については、これまでの記事で説明いただいているので割愛します。

私自身は、普段はMSP（24365の有人監視運用部隊、運用の自動化推進）とセキュリティのお仕事に従事しています。
巷に言われるDevSecOpsをロールとしても体現している形となります。
（実際には、ひとりでやっているわけではなく、強いメンバーたちによって実現されているわけですが）


さて、オンライン開催となった（現地に行きたかった。。。）今年のAWS re:Inventでも、いろいろ新しい発表がありました。

GCPのAnthosを彷彿とさせるGKE Anywhereや、どっちかいうとWorkspaces形式の方が需要があるんじゃないかと思う、EC2 Mac Instanceとかインパクトのある発表が続いています。
運用に携わる私が特に気になっているのが、「Amazon DevOps Guru」。

本日は、私自身の業務に今後大きなインパクトを与える可能性のある、「Amazon DevOps Guru」のプレビューを弄りながら、紹介と感想を書いてみたいと思います。

# Amazon DevOps Guruとは？
一言で言えば、運用を補助するツールです。
メトリクスやイベントを機械学習にかけ、問題点の発見や解決のサポートを行ってくれます。
「20 年以上の Amazon と AWS の運用上の優秀性から得た機械学習を適用して、大規模で高可用性のアプリケーションを実行し、…」（FAQsから抜粋）
スゴい。。。

本家に簡潔に案内されているのでこちらを参照ください
https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html

ちなみに、「Guru（グルー）」とは、IT系の間では、「超人的技術者」のような使い方をされています。
元々は、宗教的な単語で、指導者とか道士とかの意味らしいです。

# How much?
でもお高いんでしょ？
って思ったものの、法外な金額ではなさそう。

https://aws.amazon.com/devops-guru/pricing/

# Hands-On!

理解するには手を動かすのが一番！

## 検証用アプリケーションの生成
ってことで、Amazon DevOps Gureで解析する対象のアプリケーションを作ります。

作るといっても、aws-samples上に公開されているものを拝借します。
今回は以下を利用。
https://github.com/aws-samples/amazon-api-gateway-url-shortener

ほとんど手を動かすことなく、以下のような環境ができちゃいました。
![Screenshot at Dec 16 21-13-34.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/51320/0b806e43-ec01-1310-477c-d20f3d2fb34a.png)


手順は当該リポジトリのREADME.mdにて詳細に記載いただいているので、ここでは割愛します。
各AWSリソースはCloud Formation(CFn)から生成されます。ここでは、ReadMeに倣って、Stackを「URLShortener」と名付けました。

aws-samplesには他にも様々なサンプルが公開されているので、ドキュメントだけではしっくりこないときに活用するといいと思います。

## いざ、Amazon DevOps Guru開始

マネジメントコンソールから、対象リージョンのAmazon DevOps Guruを有効化します。
2020/12/12現在、直接サービス画面には飛べません。
Amazon CodeGuruを経て遷移します。
（「DevOps Guru」、「CodeGuru」、間のスペースの有無の違いは何故だろう。。。）

![canvas (1).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/51320/8e5fbc44-1be7-d7f9-b0d7-797ef50ce010.png)


有効化時に、Stack指定？それとも全部？と聞かれます。
ここでは、先ほど作ったStackを指定します。あとで選び直すことも可能です。

SNS通知などの機能もありますが、まずはこれだけで、Amazon DevOps GuruによるDevOps生活がスタートします。
しばらくすると、解析メトリクスに追加されていることが確認できます。
![canvas (2).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/51320/482c58e3-851b-5a06-cd7a-4d740738371c.png)


## テスト

ポチポチっとしただけでDevOps Guruは働き出してくれたようなので、仕事ぶりを確認してみます。
運用上のインシデントを擬似的に起こすため、サンプル環境のDynamoDBを困らせてみます。
![canvas (5).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/51320/06cde418-4f3d-5609-d707-c1f2b3d1a4ba.png)

ConditionalCheckFailedを継続的に発生させてみます。
今回は、以下のようにダミーのURLを前提条件として、継続的なエラーを発生させました。

```sh:iyagarase.sh
#!/bin/sh
  
for i in {1..360}

do
    aws dynamodb update-item \
        --table-name URLShortener-LinkTable-XXXXXXXXXXX \
        --key '{ "id": { "S": "myqiita" }}' \
        --update-expression "set #seturl = :newval" \
        --expression-attribute-names '{ "#seturl": "url" }' \
        --expression-attribute-values '{ ":curval": { "S": "https://qiita.com/Hiroyama-YutakaXXX" }, ":newval": { "S": "https://qiita.com/Hiroyama-Yutaka" } }' \
        --condition-expression "#seturl = :curval" \
        --profile hogefuga

    sleep 10;
done
```

暫く後、DevOps Guruのコンソールを覗くと、インサイトの発生痕跡が！
（↑のスクリプト、1回では何もでなかったので、２回叩きました。この辺は機械学習の判定になるので、ケースバイケースな気がします。）
![canvas (4).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/51320/ac4ae0ae-85e1-a94b-a44e-07c6171d9987.png)

インサイトのリスト
![Screenshot at Dec 16 21-35-58.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/51320/1834faa7-66b6-7cec-57f4-98b9746fdacc.png)

インサイトの中身
![canvas (6).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/51320/fb225a29-b116-9dd5-84db-ee1200bbd87a.png)

グルー先生が、スタイリッシュに問題点を伝えてくれます。
MTTRも計測してくれるのがCool :)

# まとめ
機能面とコスト、それぞれの観点で記載します。
※あくまでプレビュー版です。ネガティブなコメントは、GA版へのフィードバックとして。

## 機能
情報を収集し分析する、自身の環境にチューニング済みの完成された基盤をすでに持っているユーザーからすれば、目新らしいものではないかもしれません。
しかしながら、そうでないユーザーたち（ほとんどがそうだと思う）からすれば、基盤を構築、運用することなくオンデマンドに利用できるこのサービスは、非常に強力なツールになりそうです。
現状、DevOpsの"Dev"側へのメトリクスを中心に解析していそうで（完全な推測）、これだけでMSP事業者が不要になることはないですが、組み合わせることでより高度な運用の可能性を感じました。

例えば、SQS。DevOps Guru登場前は、一般的にはCWのメトリクスを静的に監視するか、ハートビート的に出し入れして生存確認するくらいが関の山だったと思います。
AWSの機関として動いているSQSのようなサービスについて、一般的なAWSユーザーからは到底収集できない膨大な学習データを元にしたプロアクティブなアラートは、これまでの機能では実現できなかっただろうと思います。

## コスト
コスパとしては悪くないんじゃないかなと思っています。むしろ、破格。
（ベータ版のため、今後、対象となるメトリクスが増えると変わってくるかもですが）

さらに対象リソースを絞り込めるのはすごくありがたいです。
ベストプラクティスとして、機能や運用レベルごとにAWSアカウントを分けるのがベターとは理解しているものの、必ずしもDevOps Guruを導入したいアカウントのリソース全てを対象としたくないことはありうるので。

ただし、絞り込みは現状、CFnスタック単位のみっぽいです。
CDKやSAMを含むCFn派には問題ないですが、Terraform派の人は辛いかもです。

話は逸れますが、AWS Protonも、CFn＋Jinjaな感じっぽいのでCFnをファーストチョイスにした方がいいんだろうか（Issueは早速上げられている模様）。
もともとCFn派の僕は無問題でしたが、タグでのリソース絞り込みなどTerraform派の救いも欲しいところ。
マネコン派の人はこれを機にIaCを検討しましょう。
CFn、SAM、CDK、Terraform、その他、AWSのIaCには選択肢が増えすぎて悩ましい。。。

また、従量課金について、このような間接的サービスには、予め上限を設定（突破後は機能を自動停止）できるとありがたいなぁと思いました。

# 参照
Amazon DevOps Guru
https://aws.amazon.com/devops-guru/
利用したサンプル環境
https://aws.amazon.com/blogs/compute/building-a-serverless-url-shortener-app-without-lambda-part-1/
DynamoDBでのConditionalCheckFailed
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/WorkingWithItems.html#WorkingWithItems.ReadingData
AWS ProtonロードマップのTerraformに関するIssue
https://github.com/aws/aws-proton-public-roadmap/issues/1