AWS Well-Architectedフレームワーク #AWS

Well-Architected フレームワークとは

AWSでシステムを構築する際に行う決定の長所と短所を理解するのに役立ちます。このフレームワークを利用すると、安全で信頼性が高く、効率的で、費用対効果が高く、持続可能なワークロードをAWSクラウドで設計および運用するための、アーキテクチャに関するベストプラクティスを学ぶことができます。
AWSホワイトペーパー

Well_Architected フレームワークとはAWSが提唱するAWSクラウドの設計や運用のベストプラクティスにおける指針のようなものです。これを学ぶことで優れた設計・運用の基準を理解することができます。

またAWS認定試験では、「最適なものを選べ」という問題が出題されます。試験は選択形式で、出題される要件を満たす選択肢を選ぶのですが、要件を満たす選択肢が複数存在する場合があります。そういった際に選択肢を比べる指針となるのがWell-Architected フレームワークです。このフレームワークにより適している選択肢が正解となります。

6つの柱

Well-Architected フレームワークは 運用上の優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性 の6つの柱に基づいており、柱にはそれぞれ設計原則があります。実際にワークロードを設計する時には、ビジネスの状況に応じて各柱の間でトレードオフを行います。開発環境では信頼性を犠牲にしてコストを削減するために最適化することでしょう。またミッションクリティカルなソリューションでは、コストと持続可能性を犠牲にして信頼性を最適化させるかもしれません。このように、６つの柱を理解した上で、実際に設計・運用する際に最適な決定をすることが重要です。

運用上の優秀性

概要

運用上の優秀性の柱には、開発をサポートし、ワークロードを効率的に実行し、運用に関するインサイトを得て、ビジネス価値をもたらすサポートプロセスと手順を継続的に改善する能力が含まれます。

この柱では運用上の人為的なミスを減らしたり、人的コストを抑えることを求めます。具体的にはCI/CDなどをイメージしていただければ理解しやすいでしょう。インフラを手動で構築するのではなくコードで立ち上げたり、デプロイ作業を自動化することによって、目的を達成することができます。

設計原則

運用をコードとして実行する: ワークロード全体（アプリケーション、インフラストラクチャ）をコードとして定義し、運用することで人為的なミスを抑制し、イベントへの一貫性のある対応を実現できます。
小規模かつ可逆的な変更を頻繁に行う: コンポーネントを定期的に更新できるようにワークロードを設計します。変更は、失敗した場合に元に戻すことができるように小規模に行います (可能な場合は、顧客に影響がないようにします)。
運用手順を頻繁に改善する: 運用手順を使用する際に、それらを改善する機会を探します。ワークロードを改良するときに、手順もそれに応じて改良します。定期的なゲームデーを計画し、すべての手順が効果的で、チームがその手順を熟知していることを確認および検証します。
障害を予想する: 「プレモータム」演習を実施して、潜在的な障害の原因を特定して排除または軽減できるようにします。障害シナリオをテストし、その影響に関する理解を検証します。対応手順をテストし、手順が効果的で、チームが手順の実行を十分に理解していることを確認します。定期的なゲームデーを計画し、ワークロードと、シミュレートされたイベントに対するチームの応答をテストします。
運用上の障害すべてから学ぶ: すべての運用イベントと障害から学んだ教訓を通じて、改善を促進します。チーム間と組織全体で教訓を共有します。

例題

あなたはソリューションアーキテクトとして、AWS上でのアプリケーションの開発とテストを実施しています。あなたはできる限り、AWSでの環境構成のデプロイを自動化することで労力を削減する必要があります。そのために、テスト環境を迅速にプロビジョニングし、かつ簡単に削除できるようにしたいと考えています。

この要件を満たすため最適なAWSサービスの設定を選択してください。

AWS CodePipelineを設定して、コードを展開するパイプラインを構成することで迅速な環境設定と削除を可能とする。
CloudFormationによりテスト環境用のテンプレートを作成する。このテンプレートを利用してテスト環境のデプロイを実施できるようにする。
EC2インスタンスのAMIとBashスクリプトを利用して、テスト環境構築を設定する。スクリプトを実行することで、テスト環境のデプロイを実施できるようにする。
Amazon ECRにイメージを作成して、テスト環境構築を設定する。このイメージを利用して、テスト環境のデプロイを実施できるようにする。

正解

2. CloudFormationによりテスト環境用のテンプレートを作成する。このテンプレートを利用してテスト環境のデプロイを実施できるようにする。

セキュリティ

概要

このセキュリティの柱では、データ、システム、資産を保護して、クラウドテクノロジーを活用してセキュリティを強化する能力について説明します

設計原則

強力なアイデンティティ基盤を実装: 最小特権の原則を実装し、各 AWS リソースとの各インタラクションに適切な権限を付与して役割分担を実施します。ID 管理を一元化し、長期間にわたって一つの認証情報を使用し続けないようにします。
トレーサビリティの実現: 環境に対して、リアルタイムでモニタリング、アラート、監査のアクションと変更を行います。ログとメトリクスの収集をシステムに統合して、自動的に調査しアクションを実行します。
全レイヤーでセキュリティを適用する: 複数のセキュリティコントロールを使用して多層防御アプローチを適用します。ネットワークのエッジ、VPC、ロードバランシング、すべてのインスタンスとコンピューティングサービス、オペレーティングシステム、アプリケーション、コードなど、すべてのレイヤーに適用します。
セキュリティのベストプラクティスを自動化する: 自動化されたソフトウェアベースのセキュリティメカニズムにより、安全でより高速かつ費用対効果の高いスケーリングが可能になります。バージョン管理されているテンプレートにおいてコードとして定義および管理されるコントロールを実装するなど、セキュアなアーキテクチャを作成します。
伝送中および保管中のデータを保護する: データを機密性レベルに分類し、暗号化、トークン分割、アクセスコントロールなどのメカニズムを適宜使用します。
データに人の手を入れない: データへの直接アクセスや、手作業による処理の必要性を低減または排除するためのメカニズムやツールを使用します。これにより、機密性の高いデータを扱う際の誤処理、改変、ヒューマンエラーのリスクを軽減します。

例題

ある会社はWEBアプリケーションをAWS上にホストしています。このアプリケーションは、Amazon RDS MySQLのマルチAZ配置構成のDBインスタンスとEC2インスタンスベースのWEBサーバーで構成されています。ソリューションアーキテクトは現在のDB認証方式が安全ではないため、セキュリティ設定を向上させるように依頼されました。ユーザー認証情報を頻繁にローテーションして、WEBサーバーによるデータベース接続をセキュアにする必要があります。

この要件を満たすために、ソリューションアーキテクトはどうするべきでしょうか。

ユーザー認証情報をAWS Secrets Managerに保存する。IAMアクセス許可を付与して、EC２インスタンスによるAWS Secrets Managerへのアクセスを許可する。
データベースユーザー認証機能をAWS Systems Manager OpsCenterに保存する。IAMアクセス許可を付与して、EC2インスタンスによるOpsCenterへのアクセスを許可する。
データベースユーザー認証情報をAWS Secrets Manager Parameter Storeに保存する。IAMアクセス許可を付与して、EC2インスタンスによるOpsCenterへのアクセスを許可する。
ユーザー認証情報をAWS Systems Manager OpsCenterに保存する。IAMアクセス許可を付与して、EC2インスタンスによるParamater Storeへのアクセスを許可する。

正解

1. ユーザー認証情報をAWS Secrets Managerに保存する。IAMアクセス許可を付与して、EC２インスタンスによるAWS Secrets Managerへのアクセスを許可する。

信頼性

概要

信頼性の柱には、意図した機能を期待通りに正しく一貫して実行するワークロードの能力が含まれます。これには、ワークロードのライフサイクル全体を通じてワークロードを運用およびテストする能力が含まれます。

信頼性とはどのような場合でもサービスを提供し続けることです。具体的には災害発生時や予期せぬアクセスの急増などです。AWSで信頼性を確保するためには、マルチAZ構成で一つのAZに障害が起きても問題がないように設計したり、スケーリングを自動化させておくなどの手段があります。

設計原則

障害から自動的に復旧する: ワークロードで主要業績評価指標 (KPI、key performance indicator) をモニタリングすることで、しきい値を超えた場合にオートメーションをトリガーできます。この場合の KPIは、サービスの運用の技術的側面ではなく、ビジネス価値に関する指標であるべきです。これによって障害発生時の自動通知と追跡が可能になり、障害に対処する、または障害を修正するための復旧プロセスを自動化できます。より複雑な自動化を使用すると、障害が発生する前に修正を予期できます。
復旧手順をテストする: オンプレミス環境では、ワークロードが特定のシナリオで動作することを実証するためのテストを行うことがよくあります。復旧戦略を検証するためにテストを実施することはあまりありません。クラウドでは、どのようにシステム障害が発生するかをテストでき、復旧の手順も検証できます。自動化により、さまざまな障害のシミュレーションや過去の障害シナリオの再現を行うことができます。このアプローチでは、実際の障害シナリオが発生する前にテストおよび修正できる障害経路が公開されるため、リスクが軽減されます。
水平方向にスケールしてワークロード全体の可用性を高める: 1つの大規模なリソースを複数の小規模なリソースに置き換えることで、単一の障害がワークロード全体に与える影響を軽減します。リクエストを複数の小規模なリソースに分散することで、一般的な障害点を共有しないようにします。
キャパシティーを推測することをやめる: オンプレミスのワークロードにおける障害の一般的な原因はリソースの飽和状態で、ワークロードに対する需要がそのワークロードのキャパシティーを超えたときに発生します (サービス妨害攻撃の目標となることがよくあります)。クラウドでは、需要とワークロード使用率をモニタリングし、リソースの追加と削除を自動化することで、プロビジョ二ングが過剰にも過小にもならない、需要を満たせる最適なレベルを維持できます。制限はまだありますが、いくつかのクォータは制御でき、そのほかのクォーターも管理できます (Service Quotasと制約の管理を参照してください)。
オートメーションで変更を管理する: インフラストラクチャに対する変更は、オートメーションを使用して実行する必要があります。管理する必要がある変更には、自動化に対する変更が含まれており、それを追跡して確認することができます。

例題

あなたは、AWS上にトランザクション処理をしつつ、コンテンツを配信する2層Webアプリケーションを構築しています。データ層では、オンライントランザクション処理（OLTP）データベースを利用しています。 WEB層では柔軟でスケーラブルなアーキテクチャ構成を実現する必要があります。

この要件を満たすための最適な方法を選択してください。

EC2インスタンスをマルチAZに展開してRoute53によるフェイルオーバールーティングを実施する
EC2インスタンスを予測キャパシティよりも多く設置する
RDSのマルチAZ構成を設定する
EC2インスタンスにELBとAuto Scalingグループを設定する

正解

4. EC2インスタンスにELBとAuto Scalingグループを設定する

パフォーマンス効率

概要

パフォーマンス効率の柱には、システムの要件を満たすためにコンピューティングリソースを効率的に使用し、要求の変化とテクノロジーの進化に対してその効率性を維持する能力が含まれます。

AWSではEC2に使うインスタンスファミリーに最適なものを選択したり、数多く存在するAWSのサービスの中から要件を満たすものを選択することでパフォーマンス効率を上げることができます。

設計原則

最新テクノロジーを誰もが利用できるようにする: 複雑なタスクをクラウドベンダーに委託することで、チームがより簡単に高度なテクノロジーを実装できるようにします。IT チームに新しいテクノロジーのホスティングと実行について学んでもらうのではなく、テクノロジーをサービスとして消費することを検討してください。たとえば、NoSQL データベース、メディアトランスコーディング、および機械学習などは、いずれも特化された専門知識を必要とするテクノロジーです。クラウドでは、これらのテクノロジーがチームによる消費が可能なサービスとなり、チームはリソースのプロビジョニングと管理ではなく、製品の開発に集中できるようになります。
わずか数分でグローバル展開する: 世界中の複数のAWS リージョンにワークロードをデプロイすることで、最小限のコストで、より低いレイテンシーとより優れたエクスペリエンスをお客様に提供できます。
サーバーレスアーキテクチャを使用する: サーバーレスアーキテクチャにより、従来のコンピューティングアクティビティのために物理的なサーバーを実行および維持する必要がなくなります。たとえば、サーバーレスストレージサービスは静的ウェブサイトとして機能させることができ (ウェブサーバーが不要になる)、イベントサービスはコードをホストできます。これによって物理サーバーを管理する運用上の負担が取り除かれます。また、マネージドサービスはクラウド規模で運用されることから、トランザクションコストも削減することができます。
より頻繁に実験する: 仮想および自動化できるリソースを使用すれば、さまざまなタイプのインスタンス、ストレージ、構成を使用して比較テストを迅速に実行できます。
メカニカルシンパシーを重視する: クラウドサービスの使用方法を理解し、常にワークロードの目標に最適なテクノロジーアプローチを使用します。例えば、データベースやストレージのアプローチを選択するときには、データアクセスパターンを考慮します。

例題

あなたはEC2インスタンスを利用したサーバー構成を検討しています。このサーバーはストレージに対するデータ処理が多発するため、ストレージに特化したインスタンスタイプが必要となります。そこで、SSDボリュームストレージを選択した上で、低レイテンシーと高いランダム I/O パフォーマンスを達成することができるインスタンスタイプを選択して、同時にコスト最適を実現したいと考えています。

この要件を満たす最もコスト効率が良いインスタンスタイプを選択してください。

T2インスタンス
I3enインスタンス
D2インスタンス
H1インスタンス

正解

2. I3enインスタンス

コスト最適化

概要

コスト最適化の柱には、最低価格でビジネス価値を実現するシステムを実行できる能力が含まれていま
す。

設計原則

クラウド財務管理を実装する: クラウドで財務面での成功を達成し、ビジネス価値の実現を加速するには、クラウド財務管理とコスト最適化に投資する必要があります。組織は、テクノロジーと使用状態の管理というこの新しい領域における能力を獲得するために、時間とリソースを投入する必要があります。コスト効率の高い組織にするには、セキュリティや優れた運用力と同様、知識の積み上げ、プログラム、リソース、プロセスを通じて能力を構築する必要があります。
消費モデルを導入する: 必要なコンピューティングリソースの使用分のみを支払い、ビジネス要件に応じて使用量を増減できます。複雑なコストの予測は必要ありません。たとえば、通常、1 週間の稼働日に開発環境とテスト環境を使用するのは、1 日あたり 8 時間程度です。未使用時にこのようなリソースを停止することで、コストを 75% 削減できる可能性があります (168 時間ではなく 40 時間になる)。
全体的な効率を測定する: ワークロードのビジネス成果とその実現に関連するコストを測定します。この測定値を使用して、生産性を向上し、コストを削減することで得られる利点を把握します。
差別化につながらない高負荷の作業に費用をかけるのをやめる: ラッキング、スタッキング、サーバーへの電源供給など、データセンターの運営に必要な重作業は AWS が行います。また、マネージドサービスを使用することで、オペレーティングシステムやアプリケーションの管理に伴う運用上の負担も解消されます。この結果、IT インフラストラクチャよりも顧客と組織のプロジェクトに集中できるようになります。
費用を分析し帰属関係を明らかにする: クラウドを使用すると、システムの使用状況とコストを正確に特定しやすくなり、IT コストを個々のワークロード所有者に透過的に帰属させることができます。これによって投資収益率 (ROI) を把握できるため、ワークロードの所有者はリソースを最適化してコストを削減する機会が得られます。

例題

AWSアカウントで各IAMユーザーが作成したリソースの料金を分析する必要があります。この要件を最小限の作業で満たすことができるの方法はどれですか。（２つ選択してください。）

AWS生成コスト配分タグのaws:createByを有効化する
ユーザー定義のコスト配分タグで独自のUser Byタグを有効化し、Amazon EventBridgeルールとAWS Lambda関数で定期的にCdoudTrailログを参照してAWSリソースに作成者のIAMユーザー名をタグ付けする
AWS Budgets Reportsで使用状況を分析する
AWS Cost Explorerで使用状況を分析する
AWS QuickSightで使用状況を分析する

正解

1. AWS生成コスト配分タグのaws:createByを有効化する
4. AWS Cost Explorerで使用状況を分析する

サステナビリティ

概要

持続可能性の柱は、環境に対する影響、特にエネルギーの消費と効率性に焦点を当てています。これらは、アーキテクトにとって、リソースの使用量を削減するための直接的な対応がわかる重要な手段であるためです。

AWSを含むAmazonとして2019年にThe Climate Pledgeを発表し、パリ協定よりも10年早く、2040年までに炭素排出量を実質ゼロ化することに誓約しています。

この柱は2021年に新しく追加されました。古い記事だと持続可能性の柱を除いた５つの柱として紹介しているものもあるため注意してください。

設計原則

影響を理解する: クラウドワークロードの影響を計測し、ワークロードの将来の影響をモデル化します。顧客がお客様の製品を使用することによる影響、および最終的に製品を廃止および使用停止する際の影響などを含む、すべての影響源を含めます。作業単位ごとに必要なリソースと排出量を確認し、生産量と、クラウドワークロードの全影響を比較します。このデータを利用して重要業績評価指標 (KPI) を作成し、影響を抑えながら生産性を向上させる方法を評価して、提案された変更による影響を経時的に見積もります。
持続可能性の目標を設定する: クラウドワークロードごとに、持続可能性の長期目標を立てます。トランザクションごとのコンピューティングリソースやストレージリソースの削減などです。既存のワークロードに対する持続可能性向上のための投資のリターンをモデル化し、持続可能性目標に必要な投資のリソースを所有者に与えます。成長計画を立て、その成長により、ユーザー単位やトランザクション単位など適した単位に対して計測される影響の大きさが結果的に削減できるようにワークロードを構築します。目標により、ビジネスや組織のより大きな持続可能性目標の支援、回帰の特定、改善できる可能性のある分野の優先順位付けが可能になります。
使用率を最大化する: ワークロードのサイズを適正化し効率的な設計を実装して、使用率を高く保ち、基盤となるハードウェアのエネルギー効率を最大化します。ホスト単位のベースライン電力消費量があるため、使用率 30% のホスト 2 つは、使用率 60% のホスト 1 つよりも効率が悪くなります。同時に、アイドル状態のリソース、処理、ストレージをなくすか、最小化して、ワークロードに必要な合計エネルギー量を削減します。
より効率的なハードウェアやソフトウェアの新製品を予測して採用する: パートナーやサプライヤーが行っているアップストリームの改善をサポートし、お客様のクラウドワークロードへの影響の軽減に役立てます。より効率的なハードウェアやソフトウェアの新製品を継続的にモニターし評価します。新しい効率的なテクノロジーを迅速に採用できるように、設計に柔軟性を持たせます。
マネージドサービスを使用する: 広範な顧客ベースでサービスを共有することで、リソースの使用率を最大化できます。こうすることで、クラウドワークロードをサポートするために必要なインフラストラクチャ数を削減できます。例えば、ワークロードを AWS クラウドに移行し、サーバーレスコンテナに AWS Fargate などのマネージドサービスを採用することで、電力やネットワークなど、データセンターに共通するコンポーネントの影響を顧客間で共有できます。マネージドサービスは、AWS が大規模に運用し、効率的なオペレーションについて責任を持ちます。お客様の影響を最小化できるマネージドサービスを使用します。例えば、Simple Storage Service (Amazon S3) ライフサイクル設定を使用して、あまり頻繁にアクセスされていないデータを自動的にコールドストレージに移動したり、AmazonEC2 Auto Scaling を使用して容量を需要に合わせたりできます。
クラウドワークロードのダウンストリームの影響を軽減する: お客様のサービスを使用するために必要なエネルギーやリソースの量を削減します。お客様のサービスを使用するために顧客がデバイスをアップグレードしなければならない必要性を削減または排除します。Device Farm を使用したテストで予想される影響を理解し、顧客とともにテストしてお客様のサービスを使用することによる実際の影響を理解します。

Well-Architected フレームワーク AWSホワイトペーパー