こんにちは、エムスリー 株式会社 エンジニアリンググループ コアSREの笠井です。
この記事はエムスリーSREがお届けするブログリレーの9日目です。 エムスリーではここ数年、 SRE の役割をプロダクト開発チームに分散・移譲する取り組みを進めています（リレーの前記事にあった「チームSRE」の体制づくりです）。
その結果、プロダクトの開発に伴うインフラ構築・管理のほとんどが各チームに一任されるようになっています。
この記事では、エムスリー でAWS Trusted Advisorを利用し、各チームが行うAWSアカウント利用の改善を進めていったことについてお話ししようと思います。
1. Trusted Advisorとは
そもそもTrusted Advisorとは、AWSの利用状況を監視し、以下5つの観点でより最適化出来る点があれば適宜通知してくれるサービスです。
- コスト最適化
- パフォーマンス
- セキュリティ
- 耐障害性
- サービスの制限(上限緩和)
もう少し具体的には、例えば以下のようなものを検知して、通知してくれます。
- 利用されていないRDS、EC2インスタンスがある
- ALBのバックエンドが1AZしかない
- ElasticIPの保持数上限が近付いている
今回は、各チームで管理しているAWSアカウントでこれらの通知が発生した際に、これを集約して処理し、JIRAへタスクとして登録、Slackへ通知する仕組みを作成したことについて、ご紹介します。
基本アーキテクチャ
以下のようなアーキテクチャにしています。
各チームが保持するAWSアカウントのCloudWatch Eventsからイベントを収集、処理用アカウントのSQSに集約し、LambdaがこのSQSをポーリング、イベントを受け取ってJIRAへチケットを作成する、という流れですね。
注意した点
この仕組みを作成するにあたり、注意した点は以下の2つです。
- 既にJIRAに登録されているイベントについてはDynamoDBを利用して重複確認を行い、重複してチケットが作られないようにする。
- Trusted Advisorから送られてくるデータはそのままでは人間による判読が難しいので、見やすいデータにし、タスクを受け取った方が対応しやすいよう対応方針を整備する。
イベントの重複確認を行う
多いものは数分間隔でチェックが行われるため、重複の確認をしない場合、管理するアカウント数や状況にもよりますが数日で数千件単位のチケットが作られることになります。
これは到底人間が対応可能な件数ではないため、重複したチケットが作られることが無いようにチェックを入れてあります。
対応しやすいようにする
以下はまだ分かり易い方ですが、Trusted Advisorから送られてくるデータは、以下のように人間による判別がかなり難しいです。
{
"version": "0",
"id": "7e72fbb0-aca9-6198-0961-059ec91b6687",
"detail-type": "Trusted Advisor Check Item Refresh Notification",
"source": "aws.trustedadvisor",
"account": "1111222233334444",
"time": "2021-01-24T22:49:45Z",
"region": "us-east-1",
"resources": [],
"detail": {
"check-name": "VPC",
"check-item-detail": {
"Status": "Yellow",
"Current Usage": "4",
"Limit Name": "VPCs",
"Region": "ap-northeast-1",
"Service": "VPC",
"Limit Amount": "5"
},
"status": "WARN",
"resource_id": "",
"uuid": "ccbb01d9-447c-46a8-8935-9aeb12fe13c6"
}
}
今回はコアSREチーム側で作成して展開しているため、通知を受け取るチームSREが単にこれを受け取っただけでは、何が問題になっているのか、何をすればいいのかが非常にわかりにくいものになってしまっています。
人間の性ですが、運用改善のためとはいえ他にやるべきことが詰まっている状況では、こういったタスクの消化に要らぬ労力を費やす必要がある場合、どうしても後回しにしてされてしまいがちです。
これを防ぐため、対応に必要な情報だけを抜き取り、通知ごとに何が問題となっていて、解消するために何をすれば良いのか、ということを明確に記載したドキュメントを用意するようにしました。
例えば上のケースでは、作成出来るVPC数の上限が近付いており、現在の上限は5、現在作成されているVPC数が4なので、今後2個以上作成する予定がある場合には上限緩和の必要がある、ということが分かりますね。
あえてやらなかったこと
今回Trusted Advisorが送ってくるデータを見ていると、使用していないインスタンスの通知や、使われていないALBなど、「わざわざタスクとして登録しなくても、そのまま削除してしまって良いのでは？」という種類の通知もありました。
しかし、これまで当ブログで紹介しているようにエムスリー ではチームSRE制を採用しており、各チームがもつAWSアカウントは各チームSRE側で管理しています。
ということは、コアSREではこれらリソースが存在している背景を把握しているわけではないので、勝手に削除するのはまずいだろうという考えのもと、あえて通知までに留めています。
まとめ
今回のシステムでは、Trusted Advisorから送られてくる通知をもとに、利用されていないインスタンスや、上限緩和の必要性があるリソースの検知などを元にして通知、JIRAタスクの登録を行い、AWSの利用改善を推進しました。
改善としては非常に地味なものですが、長い目で見ると、特に不要なリソースは削除されない限り永遠に費用がかかってしまいます。
弊社でもこのシステムにより数は多く無いものの幾つかの不要リソースが検出されて無事に整理することが出来ており、今後の活躍に期待したいところです。
We're hiring!!
エムスリーでは SRE および チーム内 SRE を随時募集しています！
