この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは。AWS 事業本部コンサルティング部に所属している今泉（@bun76235104）です。
- オンプレミスでインフラの基本設計・運用設計をやってきたけど、AWSでどのような点に注意して設計すれば良いか分からない
- 今作っている設計で考慮が漏れているか分からない
- 現状のAWS環境がベストプラクティスに反していないか確認したい
そんなことを考えたことはありませんか？
そんな時にAWS Well-Architected Toolを使うと課題を浮き彫りにしやすいと聞いて、遅ればせながら試していました。
試している中、ちょうど以下のアップデートで「AWS Well-Architected Toolとの統合機能の提供により、AWS Well-Architected Toolを使うのに必要な時間を減らせるかもしれない」と耳にして試してみました！
AWS Well-Architected Frameworkとは何か。何がうれしいの？
これに関しては、以下記事で読み方まで分かりやすく紹介していますのでぜひ一度ご覧ください。
AWSとAWSユーザの10年以上の経験からまとめられたベストプラクティス集です。 いいかえれば、多くの失敗反省を元に作られています。 これからAWSを活用する際に、皆さんが同じ失敗をしないためのガイドラインとも言えます。 AWSを始めたら、まずは目を通してもらいたいドキュメントです。
ということで、この考え方に反しないように設計・運用したいと思うのが人情ですよね。
AWS Well-Architected Toolで何を解決できるのか？
現状のAWSアカウントにおいて、AWS Well-Architected Frameworkなどのガイドラインに準拠しているかの確認に役立ちます。
簡単に言うと、AWSから質問が与えられ、それに対して現状や設計を考慮しながら回答していくことで、最終的にはAWSからレポートを受け取ることができます。
2022/11/8時点で以下のガイドラインに対するレビューが可能です。
- AWS Well-Architected Framework
- AWS Foundational Technical Review (FTR)
- Serverless Applications Lens
- SaaS Lens
また、カスタムレンズという機能で独自のルールを作成できます。
カスタムレンズはAWS Organizationと統合でき、組織内の複数のアカウントで共有できます。
AWS Well-Architected Toolでは、アプリケーションレイヤ（ログ収集など）の考慮も必要であるため、ステークホルダーで集まってワイガヤしながら話し合うのが理想的だと思います。
ステークホルダーでレビュー・結果の共有を続けることで以下のような点で力になってくれそうです。
- 設計・運用に対する疑問解決
- 現在のAWS環境がベストプラクティスに準拠しているか
- 設計段階においてどのような考え方で、どのようなサービスを利用すれば良いか
- ステークホルダー間での意識の共有
- 環境の継続的な改善
なお、AWS Well-Architected Toolに利用料金は必要ありませんが、すべての質問に答えていくのには人的コストがかかりますので、思い立ったら早めに着手すると良いと思います。
それでは、実際に画面をみていきましょう。
Step1: ワークロードを作成する
サービストップ画面から「ワークロードの定義」をクリックします。
ワークロードに必要な情報を入力していきます。
縦に長くて見にくいですが、全体像はこのようになっています。
今回は以下のように設定をしてみました。
| 項目 | 設定値 | 備考 |
|---|---|---|
| 名前 | test_public_service | ワークロードの名前です。プロジェクト名やシステム名など分かりやすい命名で良いと思います。（参考: 公式のよくある質問） |
| 説明 | テスト用 | |
| レビューの所有者 | test_public_service.jp | レビューを受けて改善・管理していく責任者や部門名など |
| 環境 | 本番稼働前 | 今回は本番稼働前の設計段階という想定でこちらを選択 |
| リージョン | アジアパシフィック（大阪）、アジアパシフィック（東京） | メインリージョン:東京、DRリージョン:大阪を想定 |
| AWS以外の領域 | Firebase、オンプレミス（東京データセンター） | 利用するサービス・オンプレとの接続などの前提を記載 |
| アカウント | 空欄 | 複数のアカウントをまたぐ場合は記載 |
| アプリケーション | 空欄 | 今回は実際に動作しているアプリケーションがないため空欄 |
| アーキテクチャ設計 | 空欄 | 今回は空欄にしていますが、最新の設計書や構成図のリンクを貼ることで進めやすいと思います |
| 業界の種類 | 一般公共サービス | |
| 業界 | 一般公共サービス | |
| AWS Trusted Advisor | 有効 | 最新のアップデートです。今回はこれを試してみました。 |
この設定値で、次にレンズの適用に進みます。
今回はAWS Well-Architected Frameworkのみ有効にして「ワークロードの定義」をクリックします。
以下のようにワークロードが作成されました。
Step2: レビュー開始（質問に答えていく）
レビュー画面のイメージ
先ほど作成したワークロードの「レビューを続ける」をクリックして、質問の回答画面を開いてみます。
Well-Architected Frameworkの考えに従った質問が表示されます。
「情報」をクリックすることで質問の意図や、参照リンクなどが表示されます。
2022年11月8日現時点では58個の質問となっていますが、1問1問のボリュームがあるため、すべてを回答するのにはそれなりに時間がかかります。
なお、AWS Well-Architected Frameworkには6つの柱がありますが、初期状態では以下の優先度で質問が表示されます。
- 運用上の優秀性
- セキュリティ
- 信頼性
- パフォーマンス効率
- コスト最適化
- 持続可能性
要件によって重要視したい項目は違うと思いますので、今回は順番を変えてみます。
初期状態はこうです。
こう並び替えてみます。（ドラッグ&ドロップで並び替えできました）
この後に再度「レビューを続ける」から質問の画面に遷移してみると、以下のように並び替え後の6つの柱の優先度にしたがって、質問の順番も変わっています。
Trusted Advisorによるチェック
従来であれば、すべての質問に対して「現状でベストプラクティスを守れているか？」ということを考えるために、現状のAWSアカウント内のリソースを自分で確認していく必要がありましたが以下アップデートにより一部の質問で確認作業を簡略化できるようになりました。
一部の質問を表示すると、以下のように「Trusted Advisor チェックが利用可能」と表示されますので、「チェックを表示」をクリックしてみます。
この質問では以下のように現状の環境から、削除するべきと考えられるリソースがないかチェックしてくれるようです。
他の質問も見てみると同様に、現在の環境をチェックしてベストプラクティスに応じている状態か確認できます。
「現状でAWSリソースはないが、インフラ基本設計・運用設計の参考にしたい」といったユースケースには合わないかもしれませんが、「すでにAWSのリソースが存在しているアカウント内でベストプラクティスにのっとっているいるか確認・改善し続けたい」という場合にはマッチしそうです。
レポートを出力する
質問に回答していくことで、ワークロードの画面からレポートの出力が可能となります。
すべての質問に答えていなくても出力できるので、優先度の高い柱から優先して考慮していくことができそうです。
Trusted Advisor機能の有効化のための注意事項
最後にTrusted Advisorの機能を有効化する際の注意点を紹介します。
Trusted Advisorによるチェックの機能を使うためには、ワークロードを作成する画面で下の方にあったチェックボックスを有効にしておく必要があります。
すでに作成しているワークロードでも以下のように変更可能です。
機能を有効化する際には、IAMロールの作成も必要になりますが、ナビゲーションにしたがってボタンを押すだけで作成が可能です。
権限の詳細は以下ドキュメントをご参照ください。
まとめ
- AWS Well-Architected ToolはAWSのベストプラクティスと現状の乖離をチェックするのに役立つ
- Trusted Advisorとの統合機能は手動で現状のAWS環境を確認する手間を省いてくれる
- 一部の質問に自動で回答してくれる訳ではありません
- 現状を考慮しながらステークホルダーで話し合う時間は必要です
ぜひ設計や運用改善に悩んでいる方はご活用ください！
7
