📙

AWSの構成図を自動で作成する「AWSでのワークロード検出」を使ってみた

2023/08/18に公開

AWS

architecture

tech

「AWSでのワークロード検出 workload discovery on AWS」とは、AWS上で展開しているサービスのアーキテクチャ図（構成図）を自動で描画してくれるソリューションです。

今回これを試してみたので、気づいた点をいくつか書いていきたいと思います。
構築方法などは公式ガイドで十分に分かると思うのでこの記事では触れません。ご了承ください。

実用性は…？

運用は…個人的には難しいかなという気がします。やるなら、

初回だけこのソリューションに構成図を出してもらう
ソリューションは削除。今後は手動で構成図をメンテ
厳しくなってきたらソリューションをもう1回立てて構成図を出してもらう

といった運用になるかなと思います。理由は下に書きます。

◯ 構築・導入は楽

ソリューションの構築自体は楽です。必要なのは2stepsだけで、簡単に構築できます。
詳細はガイドを見ていただきたいですが、

好きなAWSアカウントにソリューションCFnをデプロイ
構成図を書きたいリソースがあるAWSアカウントとリージョンに、追加CFnをデプロイ

構築は30分〜1時間で終わります。

▲ 継続利用はコストが気になる

ソリューションのアーキテクチャ図が公式に描かれているので何となく分かると思いますが、こいつはなぜか常時起動ソリューションです。（図を書くときだけ起動して欲しい。）

バージニア北部で1ヶ月に$425と書かれているので、約6万円です。

構成図は1度欲しいと言うより、図が古くなってメンテされないことだと思いますが、その問題を解決するために毎月6万円出せるか（しかも、後ほど書くが結局図の手動調整は必須。）という天秤ですね。

▲ 構成図の手動調整が必要

自動で出してくれますが、流石にそのまま使うのは厳しそうでした。

理由1: 巨大ワークロードは厳しいかもしれない

600個くらいのリソース（IAMなどの小さいものも含む）を選択して構成図を描き出そうとするとエラーになりました。エラーメッセージを読む限り、 response payload sizeに限界があるみたいです。

それらしき issue はありましたが、これはページネーションの話をしていて構成図の描画とは違うかもしれないです。

とにかく、もし大きなワークロードを展開しているのなら構成図に描ききれない可能性があるということです。

理由2: 勝手に関連リソースが図に配置される

AWS構成図を描くとき、構成図に表したいリソースを選ぶ必要があります。

イメージ

しかしながら、選択したリソースに関連するリソースが勝手に裏で選択されて構成図に落とし込まれる、という仕様があるので、構成図に欲しい物が一発で出せないという苦しみがあります。

例えば自分の場合、上の画面でAWS::EC2::Subnetだけを選択して構成図を自動作成したところ、

VPC
ENI
NAT
EC2
Route Table
Network ACL
Lambda
Tag

が同時にやってきました。
サブネットが所属するVPC、そしてサブネットに所属する諸々のリソースが選ばれた感じですね。

これは嬉しいように見えて危険な機能で、構成図に入れるべき忘れ物がなくなるというメリットはありますが、自分の取捨選択が無意味になるというデメリットを抱えています。

その結果こうなります。（構成図の一部だけ記載）

関連リソースが勝手に選ばれるで、そこそこのリソースを選択するだけでとんでもない量のリソースが選択され、それらの関連が全部線で表されています。

FilterとRemoveでリソースを消せる

構成図に余計なものが入り込むのですが、それらを消す機能も存在します。
一つがFilterで、もう一つがRemoveです。

Filterはその名の通りの仕事をし、選択リソースの種類だけを表示したり、逆に隠したりしてくれます。

Removeはもう少し細かい調整用で、選択したリソース1つ1つを構成図から消し去ります。
Filterはリソースの種類単位で、Removeはリソース1つ１つの単位です。

理由3: 図中のリソース配置場所が人が欲しい物に合わない

構成図は各リソースを適度にグルーピングしてくれます。
同じサブネットに属するEC2とLambdaはまとめて中に配置してくれたり、S３ Bucketは一箇所に集めてくれたり、です。

ただ、この構成図の配置が必ずしも人が欲しいものではないわけです。
（※そんなこと言ってしまえばあらゆる構成図はそうですが。）

例えば上から下へアクセス経路が流れるように図を書きたい場合は、テコ入れが必要です。
常時このソリューションを起動し続けると最新の構成図を出してくれますが、、出してくれる構成図が欲しいものでないならコストとの天秤はますます厳しくなります。

理由4: リソース名が省略される

長いリソース名は省略されてしまいます。
そのため、各リソースに似たような prefix を付けている場合はもうどれがどれか分かりません。

例えば以下はCFｎを構成図に描いたものですが、すべてworkload-dis...となっていてあまり意味のない図になっています。

このあたりを制御するオプションはないので、コードを書き換えるなどの対応も検討しないといけません。

理由5: その他細かいこと

例えば、サブネットは構成図において public も private も同じ色で表示されます。
慣習的に（？）、publicは緑、privateは青で図示することが多いので、少し困ります。

また、明示的に関連がない限りリソース間の矢印は伸びないので、アプリケーションのアクセス経路などは当然図示されません。

プラクティス

専用AWSアカウントを作ると良い

これはガイドにも書かれているのですが、実際その通りでした。
このソリューションはそこそこのリソースを作るので、既存のAWSアカウントにデプロイするとそこにあったリソースを汚してしまいます。

コストが見にくくなったり、構成図を作成するときにこのソリューションを図に盛り込んでしまったりと、意識することが増えてしまいました。可能なら専用AWSアカウントにデプロイしたほうが良いです。

Filterで大まかに絞った後にRemoveで調整すると良い

Filter機能を使うと、不要なリソースをその種類ごとごっそり消せます。
例えば、CloudFormationStackは構成図に要らない！というときに便利です。

その後、Removeで1つ1つ不要なリソースを消すのがおすすめです。
例えば、EC2の中でもこれは構成図に要らない！という使い方です。

draw.ioにexportして使うと良い

構成図はExportできます。json, csv, draw.ioがありますが、手直しのしやすさからもdraw.ioが良いと思います。

1度きりの使用が良い

月6万円分ずっと起動するのは割に合わないと思いました。
最初にざっくりと頭を出してもらう分には使ってもいいかなと感じたので、パッと立ててぱっと構成図を出してパッと削除するのが良いかなと思います。

そうすれば金額は数時間分で済みます。

終わりに

いい感じの構成図を出して、それが古くならないように継続的に更新する、という願いがいかに難しいかを再認識しました。

本当に構成図は必要か？　なんのために？　を問い直して、
どんな情報が入った図あれば嬉しい（基準を満たす）のかは明確にしておくべきですね。