はじめに

タイトルの通りですが、Well-Architected IaC Analyzer というツールを触る機会がありました。今回はこの仕組みをデプロイする際の注意点や実際使ってみての所感などを紹介します。

AWS Well-Architected Tool とは

Well-Architected IaC Analyzer の前に、そもそも AWS Well-Architected Tool とはなんでしょうか。公式ドキュメントには以下のように記載されています。

AWS Well-Architected Tool (AWS WA Tool) は、AWS のベストプラクティスを使用してアーキテクチャを測定するための一貫したプロセスを提供するクラウド内のサービスです。AWS WA Tool は、以下を実行することで製品ライフサイクル全体を支援します。

– 決定事項のドキュメント化を支援する
– ベストプラクティスに基づいてワークロードを改善するための推奨事項を提供する
– ワークロードの信頼性、安全性、効率性、費用対効果の向上

AWS WA Tool を使用すると、AWS Well-Architected フレームワークのベストプラクティスを使用して、ワークロードを文書化して測定します。

かなりざっくりいうと、AWS が長年培ってきたベストプラクティス集を活用して、顧客のワークロードの改善を支援するツールということがわかりました。なお用語集はこちらになります。

Well-Architected IaC Analyzer とは

Well-Architected IaC Analyzer は、この AWS WA Tool の仕組みを LLM を用いて簡素化する仕組みで、主に IaC コードを対象として評価します。以下のようなアーキテクチャとなっています。(こちらより抜粋)

バックエンド

  • S3 バケットに AWS Well-Architected Framework のホワイトペーパーが配置される
  • それらのドキュメントを Knowledge Bases for Amazon Bedrock のベクトルデータベースと同期する
  • 定期的にトリガーされる Lambda 関数がドキュメントを最新化する

フロントエンド

  • ALB 配下の Amazon ECS で Streamlit をホスト
  • ユーザーがアップロードした IaC コードは S3 バケットに格納される
  • Streamlit が Well-Architected Tool の API を直接呼び出し、IaC コードに対する評価結果を画面に描画する

構築

基本的に README 通りに進めれば問題ありませんが、いくつか注意点があります。

構築時の注意点

  • AWS CDK と Docker が動く環境で構築すること
  • 以下のモデルが存在するリージョンを選択すること
    • arn:aws:bedrock:ap-northeast-1::foundation-model/amazon.titan-embed-text-v2:0
    • anthropic.claude-3-5-sonnet-20240620-v1:0 (こちらは変更可能)
  • プライベート環境へのアクセスができない場合は注意書きを読んだ上でパブリックアクセスを有効化すること
    • デフォルトだと ALB が internal で作成される
    • ただし、変更すると認証なしで HTTP 80 を 0.0.0.0/0 で公開してしまう

ALB の件はとりわけ重要です。以下のような対策をする必要があります。

  • 構築後、即時にセキュリティグループで IP 制限をかける、またはあらかじめ CDK コードを修正する
  • CDK コードを修正して HTTPS 化する

使ってみる

早速ですが使ってみましょう。cdk deploy でスタックを構築すると、コンソールに CloudFormation の Outputs が表示されます。WA-IaC-Analyzer-<リージョン名>-GenAIStack.StreamlitAppServiceServiceXXXXXXXX という出力がアプリの URL になっているのでアクセスします。以下のような画面です。

試しにこの仕組み自体の IaC コードをアップロードしてみます。

構築時、cdk.out フォルダ内に WA-IaC-Analyzer-<リージョン名>-GenAIStack.template.json というテンプレートが生成されているはずなので、これを使います。なお Terraform で書かれたコードでも動作するようです。

アップロード後、このような画面に遷移します。ワークロード ID を入力するフォームがあります。あらかじめワークロードを作っておく必要があるようです。が、構築時に DO-NOT-DELETE_WAIaCAnalyzerApp_<リージョン名>_XXXXXXXX というワークロードが作成されており、これの ID を指定する形でも問題ありませんでした。

レビューする観点として柱を選択します。今回は [Cost Optimization] のみ選択しました。[Review Uploaded Document] をクリックします。

しばらく待つと、IaC コードの評価結果が表示されます。ベストプラクティスと照合して見当たらなかった観点、およびベストプラクティスに適合した観点が検出されました。縦長すぎるので画像では展開していませんが、検出された項目がひとつずつリストされています。

この評価結果は、[Download Recomendations] をクリックすることで CSV 形式でダウンロードすることができます。

[Complete Well-Archicted Review] をクリックすることで、評価結果がさきほど入力したワークロードに同期されます。画面には以下のようなサマリーが表示されます。

マネジメントコンソールを確認します。ワークロードが更新され、マイルストーンが追加されていました。

実行時の注意点

使ってみて、少し注意点もありました。

  • すべての柱を対象にレビューを実行するとかなり時間がかかる (ECS で実行され、20-30 分かかる)
  • 存在しないワークロード ID を指定した場合、その時点でバリデーションされるわけではなく、レビュー途中でエラーが発生し以下のような Traceback が表示される

おわりに

Well-Architected IaC Analyzer を触ってみました。LLM を有効活用するよい例だと思います。また、以下は改善の余地もあるため、コントビュートチャンスかもしれないなとも思いました。気になるエンジニアの方は貢献してみてもよいかもしれません。

  • ワークロード ID の存在チェックを実装
  • CDK の実行で、aarch64 などのように CPU アーキテクチャが x86_64, arm64 というリテラル以外で検出された場合に失敗する (該当コード)
  • 別アカウントのワークロード ARN を指定できるようにする

実装がまだ荒削りな部分もあり POC 的な趣が強いようにも感じましたが、社内利用などでは十分に効果を発揮しそうです。