AWS Well-Architected Tool
AWS WA Tool を活用し、AWS Well-Architected フレームワークのベストプラクティスを使用してワークロードのドキュメント化および測定ができます。
これらのベストプラクティスは、AWS ソリューションアーキテクトによって、さまざまなビジネスでのソリューションの構築における長年の経験に基づいて開発されました。
このフレームワークは、アーキテクチャを測定するための一貫したアプローチを提供します。また、時間の経過とともにニーズに応じてスケーリングする設計を実装するのに役立つガイダンスも提供します。
なにかアドバイスしてくれるみたいだけど何を言ってるのかさっぱりわからないので使ってみる
ワークロードの定義
これからAWSを利用して何かしらのWebサービスを提供しようと考えている場合の前提条件を記入していく
例えばここでは ちょっとしたWebサイト、CMSであったりを導入したWebサイト構築を想定する
レビュー
作成したワークロードに対して AWS の質問に回答しどのようなシステムを作りたいのかを具体的にしていく
要件定義みたいな感じ
ここで作成してみたワークロードに対するレビュー項目は全部で 35問！！ それぞれにチェック項目が５～項目くらいあるため
ちゃんと定義する場合はそれなりに時間がかります
以下は一例として参考までに
運用上の優秀製
- OPS1. 優先順位はどのように決めれば良いでしょうか
だれもが、ビジネスを成功させるうえで自分が果たす役割を理解する必要があります。リソースの優先順位を設定するため、共通の目標を設定してください。これにより、取り組みから得られるメリットが最大化されます。 - OPS2. ワークロードの状態を理解できるようにするには、ワークロードをどう設計すればよいでしょうか?
ワークロードを設計する際には、すべてのコンポーネントにわたって内部状態 (メトリクス、ログ、トレースなど) を理解するために必要な情報が送出されるようにします。これにより、適時に必要な応答を提供できるようになります。 - OPS3. どのようにして欠点を減らし、修正を簡単にし、本番環境へのフローを改善しますか?
リファクタリング、品質についてのすばやいフィードバック、バグ修正を可能にし、本番環境への変更のフローを改善するアプローチを採用します。これらにより、本番環境に採用される有益な変更を加速させ、デプロイされた問題を制限できます。またデプロイアクティビティを通じて挿入された問題をすばやく特定し、修復できます。 - OPS4. どのようにデプロイのリスクを軽減しますか?
品質に関する迅速なフィードバックを提供し、望ましい結果をもたらさない変更から迅速に復旧できるようにするアプローチを採用します。このような手法を使用すると、変更のデプロイによって生じる問題の影響を軽減できます。 - OPS5. ワークロードをサポートする準備が整っていることはどうすれば確認できるでしょうか?
ワークロード、プロセス、手順、従業員の運用準備状況を評価し、ワークロードに関連する運用上のリスクを理解するようにします。 - OPS6. ワークロードの正常性をどのように把握しますか?
ワークロードメトリクスの定義、キャプチャ、分析をすると、適切なアクションを取れるようにワークロードイベントの可視性を高めることができます。 - OPS7. オペレーションの正常性をどのように把握しますか?
オペレーションメトリクスを定義し、キャプチャし、分析することで、オーペレーションイベントの可視性を高め、適切なアクションがとれるようになります。 - OPS8. ワークロードと運用イベントはどのように管理しますか?
イベントに対応するための手順を準備、検証してワークロードの中断を最小限にします。 - OPS9. オペレーションを進化させる方法
漸進的な継続的改善に時間とリソースを費やすことで、オペレーションを効果的かつ効率的に進化させることができます。
セキュリティ
- SEC1. 認証情報と認証をどのように管理していますか?
認証情報と認証メカニズムには、ワークロードにおいてアクセス権を直接的または間接的に付与するパスワード、トークン、キーなどが含まれます。適切なメカニズムで認証情報を保護することで、不注意または悪意による不正利用のリスクを減らすことができます。 - SEC2. 人為的なアクセスをどのように制御していますか?
定義されたビジネス要件に合致するコントロールを実装することで人為的なアクセスを制御し、リスクと不正アクセスの影響を軽減します。これは特権ユーザーと AWS アカウントの管理者に適用されます。また、アプリケーションのエンドユーザーにも適用されます。 - SEC3. プログラムによるアクセスをどのように制御していますか?
適切に定義、制限、分離されたアクセス権によってプログラムによるアクセス、または自動アクセスを制御することにより、不正アクセスのリスクを軽減します。プログラムによるアクセスには、ワークロード内部でのアクセスや、AWS 関連リソースへのアクセスが含まれます。 - SEC4. セキュリティイベントをどのように検出し、調査していますか？
ログやメトリクスからイベントを可視化して把握し、分析します。セキュリティイベントや潜在的な脅威に対して措置をとることで、ワークロードを保護します。 - SEC5. 新しいセキュリティ脅威に対してどのように防御していますか?
AWS と業界のベストプラクティスおよび脅威インテリジェンスに関する最新情報を入手すれば、新しいリスクを認識するのに役立ちます。これにより、脅威モデルを作成し、ワークロードの保護に役立つ適切なコントロールを特定、優先順位付け、および実装することが可能になります。 - SEC6. ネットワークをどのように保護していますか?
パブリックおよびプライベートネットワークでは、内部および外部のネットワークベースの脅威から保護するために複数の防御レイヤーが必要です。 - SEC7. コンピューティングリソースをどのように保護していますか?
ワークロード内のコンピューティングリソースを内外の脅威から守るには、複数の防御レイヤーを設ける必要があります。コンピューティングリソースには、EC2 インスタンス、コンテナ、AWS Lambda 関数、データベースサービス、IoT デバイスなどがあります。 - SEC8. データをどのように分類していますか?
分類とは、機密レベルに応じてデータを分けることです。これにより、どのような管理手法を用いてデータを保護および保持すべきかを判断できます。 - SEC9. 保管中のデータをどのように保護していますか?
要件を定義して暗号化などのコントロールを実装することで、保管中のデータを保護し、不正アクセスや喪失のリスクを軽減できます。 - SEC10. 伝送中のデータをどのように保護していますか?
要件を定義し、暗号化などのコントロールを実装して伝送中のデータを保護すれば、不正アクセスや漏洩のリスクを軽減できます。 - SEC11. セキュリティインシデントにどのように対応していますか?
セキュリティインシデントを適切なタイミングで調査および対応し、組織の中断を最小限に抑えられるようにするには、準備が重要です。
信頼性
- REL1. サービス制限をどのように管理していますか？
必要以上のリソースが偶発的にプロビジョニングされることを防止するため、デフォルトのサービス制限が設けられています。また、不正利用などからサービスを保護するため、API オペレーションを呼びだす頻度も制限されています。AWS Direct Connect を使用している場合、接続ごとに転送できるデータの量にも制限があります。AWS Marketplace のアプリケーションを使用している場合、アプリケーションの制限を理解する必要があります。サードパーティーのウェブサービスやサービスとしてのソフトウェアを使用している場合も、これらのサービスに設けられている制限を認識しておく必要があります。 - REL2. ネットワークトポロジをどのように管理していますか?
アプリケーションは、既存のデータセンターインフラストラクチャ、公開されているパブリッククラウドインフラストラクチャ、またはプライベートアドレスが割り当てられたパブリッククラウドインフラストラクチャなど、1 つまたは複数の環境に存在可能です。システム内およびシステム間の接続性、パブリック IP アドレスの管理、プライベートアドレスの管理、名前解決などのネットワークの考慮点は、クラウド上のリソースを利用する上で基本的なものです。 - REL3. システムが需要の変化にどのように対応していますか？
スケーラブルなシステムはリソースを自動的に追加したり削除したりできる伸縮性を備えているため、いつでも最新の需要に厳密に適合します。 - REL4. リソースをどのようにモニタリングしていますか？
ログとメトリクスは、ワークロードの状態に関する洞察を得るための強力なツールです。ワークロードは、しきい値を超えたり重大なイベントが発生したりしたときに、ログとメトリクスがモニタリングされて通知が送信されるように構成できます。ワークロードは、低パフォーマンスのしきい値を超えたり障害が発生したりしたときに、自動的に自己回復したり、スケールするように設計されているのが理想です。 - REL5. 変更をどのように実施していますか？
環境の変更を管理しないと、変更の影響を予測することが難しくなります。プロビジョニングされた AWS リソースとアプリケーションの変更制御は、アプリケーションと運用環境で既知のソフトウェアが実行されており、予測できる方法でパッチを適用または置換できることを確認するために必要です。 - REL6. データをどうバックアップするか?
データ、アプリケーション、動作環境 (アプリケーションで設定したオペレーティングシステムとして定義) をバックアップして、平均復旧時間 (MTTR) と目標復旧地点 (RPO) の要件を満たします。 - REL7. どのようにしてシステムがコンポーネントのエラーに耐えるか?
ワークロードに関して顕在または潜在する条件として、高い可用性と短い平均復旧時間 (MTTR) を必要とする場合は、ワークロードを弾力性のある設計にし、障害に耐えるようワークロードを分散します。 - REL8. 弾⼒性をどのようにテストしていますか?
ワークロードの弾⼒性をテストして、本番環境でしか表面化しない潜伏バグを見つけられるようにします。こういったテストを定期的に行います。 - REL9. 災害対策をどのように計画していますか?
災害対策 (DR) は、バックアップからデータを復元する際に不可欠です。RTO と RPO の目標と一致するように目標、リソース、場所、復元するデータの機能を定義し、実行する必要があります。
パフォーマンス効率
- PERF1. 最も良いパフォーマンスのアーキテクチャをどのように選択していますか？
多くの場合、ワークロード全体で最適なパフォーマンスを得るには、複数のアプローチが必要です。Well-architected のシステムでは複数のソリューションが使用され、さまざまな機能によってパフォーマンスが改善されます。 - PERF2. コンピューティングソリューションをどのように選択していますか?
システムにとって最適なコンピューティングソリューションは、アプリケーションの設計、使用パターン、設定に応じて異なります。各アーキテクチャでは、コンポーネントごとに異なるコンピューティングソリューションが使用される可能性があるため、パフォーマンスを向上させるための機能も異なります。アーキテクチャで使用されるコンピューティングソリューションを正しく選択しないと、パフォーマンス効率が低下するおそれがあります。 - PERF3. ストレージソリューションをどのように選択していますか?
システムにとって最適なストレージソリューションは、アクセス方法 (ブロック、ファイル、オブジェクト)、アクセスパターン (ランダム、シーケンシャル)、必要なスループットやアクセス頻度 (オンライン、オフライン、アーカイブ)、更新頻度 (WORM、動的)、可用性と耐久性に関する制約によって異なります。優れた設計のシステムでは、複数のストレージソリューションを使用し、さまざまな機能を有効にしてパフォーマンスとリソースの使用効率を高めています。 - PERF4. データベースソリューションをどのように選択していますか。
システムにとって最適なデータベースソリューションは、可用性、整合性、分断耐性、レイテンシー、耐久性、スケーラビリティ、クエリ機能などの要件に応じて異なります。多くのシステムでは、サブシステムごとに異なるデータベースソリューションを使用しているため、パフォーマンスを向上させるための機能も異なります。システムに対して適切でないデータベースソリューションや機能を選択すると、パフォーマンス効率が低下する場合があります。 - PERF5. ネットワークソリューションをどのように選択していますか？
システムにとって最適なネットワークソリューションは、レイテンシー、スループット要件などによって異なります。場所のオプションはユーザーリソースやオンプレミスリソースなどの物理的な制約の影響を受けますが、エッジ技術やリソースプレイスメントを使うことでカバーできます。 - PERF6. ワークロードを進化させるためにどのように新機能を取り込んでいますか？
ワークロードを設計する際に選択できるオプションには限りがありますが、時間が経つにつれ、ワークロードのパフォーマンスの向上に役立つ新しいテクノロジーやアプローチを利用できるようになります。 - PERF7. リソースが正常に動作していることを確認するためにどのようにモニタリングしていますか？
システムのパフォーマンスは徐々に低下することがあります。システムのパフォーマンスをモニタリングして低下の兆候を見つけ、オペレーティングシステムやアプリケーション負荷などの内部的および外部的な要素を修正します。 - PERF8. パフォーマンスを向上させるために、トレードオフをどのように利用していますか？
アーキテクチャの設計にあたって、最適なアプローチとなるトレードオフについて積極的に考慮します。多くの場合、整合性、耐久性、時間とレイテンシーと引き換えに、パフォーマンスを向上することが可能です。
コスト最適化
- COST1. 使用状況をどのように管理しますか?
発生コストを適正な範囲内に抑えつつ、目的を確実に達成するためのポリシーとメカニズムを設定します。チェックアンドバランスのアプローチを採用することで、無駄なコストを費やすことなくイノベーションが可能です。 - COST2. 使用状況とコストをどのようにモニタリングしますか?
コストをモニタリングし、適切に配分するためのポリシー手順を定めます。これにより、ワークロードのコスト効率を測定し、向上させることができます。 - COST3. 不要なリソースをどのように削除しますか？
プロジェクトの開始から終了まで変更管理とリソース管理を実装します。これにより、使用されていないリソースをシャットダウンまたは終了して、無駄を減らします。 - COST4. サービスを選択するとき、どのようにコストを評価しますか?
Amazon EC2、Amazon EBS、Amazon S3 は、基盤となる AWS のサービスです。Amazon RDS や Amazon DynamoDB などのマネージドサービスは、高レベルまたはアプリケーションレベルの AWS のサービスです。基盤となるサービスやマネージドサービスを適切に選択することで、このワークロードのコストを最適化できます。例えば、マネージドサービスを使用することで、管理や運用によって発生するオーバーヘッドを削減またはゼロにでき、アプリケーション開発やビジネス上の他の活動に注力できるようになります。 - COST5. リソースタイプとサイズを選択する際、どうすればコスト目標を達成できるでしょうか?
目の前にあるタスクに合わせて適切なリソースのサイズを選択するようにします。最もコスト効率の高いタイプとサイズを選択することで、無駄を最小限に抑えます。 - COST6. コストを削減するには、料金モデルをどのように使用したらよいでしょうか?
リソースのコストを最小限に抑えるのに最も適した料金モデルを使用します。 - COST7. データ転送料金についてどのように計画していますか？
データ転送料金を計画し、モニタリングすることで、これらのコストを最小化するためのアーキテクチャ上の決定を下すことができます。小規模でも効果的なアーキテクチャ変更により、長期的な運用コストを大幅に削減できる場合があります。 - COST8. リソースの供給と顧客の需要をどのように一致させていますか?
費用とパフォーマンスのバランスが取れたワークロードを作成するには、費用を掛けたすべてのものが活用されるようにし、使用率が著しく低いインスタンスが生じるのを回避します。利用が過剰でも過少でも偏りが生じると、運用コスト (利用過剰によるパフォーマンスの低下) または無駄な AWS 費用 (過剰なプロビジョニング) のいずれかで、組織に悪影響が及びます。 - COST9. 新しいサービスをどのように評価していますか？
AWS では新しいサービスと機能がリリースされるため、既存のアーキテクチャの選択をレビューし、現在でもコスト効率が最も優れているかどうかを確認することがベストプラクティスです。
各項目に対して説明がサイドバーに表示されたりするけど、まだ日本語翻訳が曖昧だったり、
一体何のどこについて回答してほしいのかがちょっとわかりにくい
**これらの問に答えられる知識レベルがあるのであれば、このサービスはそもそも使わないんじゃないか？**という気がしないでもない
レビュー結果
レビューが完了するとワークロード画面に戻され、レビュー結果が反映されている
レビュー結果より各設問に対する項目を見ていくと
どの設問に対して AWS側が危機感を持っているかがわかる
ん？
特に具体的な意見やなにかがあるわけではない
使ってみての感想
最初レビューのところに「要件定義みたい」と書いたが、まさにそうなのだろう
AWS Well-Architected Tool は AWS のナレッジから幾つか検討するべき項目をピックアップし、提示し、
それに対するユーザーの回答や要件を取り纏め、それを AWS 上に残し、改善、評価していく 要件定義書作成ツールのようなものなのかな
上記でレビューした結果は PDF 出力もでき
その時々の回答内容、レビュー結果を「マイルストーン」という形で保持出来るようにしている
上記の機能からもこのツールは要件定義のサポートツールとして使い、システム要件を定義し、検討が甘い内容を指摘・改善に向けて推し進めていくツールと思う
てっきり「あなたが考えるWebサービスにおすすめのアーキテクチャ、AWSサービスはこれ！」って教えてくれるサービスかと思ってたよ
