AWS Well-Architectedとは
AWS Well-Architectedは、AWSを活用する際に参考となるベストプラクティス集です。
AWS Well-Architectedの構成
AWS Well-Architectedは、以下の「6つの柱」で構成されています。
- 運用上の優秀性
- セキュリティ
- 信頼性
- パフォーマンス効率
- コスト最適化
- 持続可能性
6つの柱には、それぞれの設計原則とベストプラクティスを考えるうえで必要な観点に関する定義があります。
6つの柱
AWS Well-Architectedの6つの柱を参照して、効果的で安定したシステムを構築することができます。ここでは設計原則のみ紹介します。
運用上の優秀性
1つ目の柱は運用上の優秀性です。ワークロードを効率的に実行し、ビジネス価値をもたらすために、システムの実行とモニタリング、継続的な改善にフォーカスしています。
設計原則
以下は、運用上の優秀性を実現するための設計原則です。
- 運用をコードとして実行する
クラウドでは、アプリケーションコードに使用しているものと同じエンジニアリング原理を環境全体に適用します。ワークロード全体 (アプリケーション、コードとしてのインフラストラクチャなど) をコードとして定義し、コードによって更新することができます。運用手順のスクリプトを記述し、イベントに応答してそのスクリプトをトリガーすることで自動的に実行できます。オペレーションをコードとして実行することで、人為的なミスを抑制し、イベントへの一貫性のある対応を実現できます。 - 小規模かつ可逆的な変更を頻繁に行う
ワークロードへの有益な変更のフローを増やすため、コンポーネントを定期的に更新できるようにワークロードを設計します。環境に導入された問題の特定と解決に役立たない場合に元に戻すことができるように、変更は小規模に行います (可能な場合は、顧客に影響がないようにします)。 - 運用手順を頻繁に改善する
運用手順を実施しながら、改善の機会を探します。ワークロードを改良するときに、手順もそれに応じて改良します。定期的なゲームデーを計画し、全ての手順が効果的であり、チームがその手順を熟知していることを確認および検証します。 - 障害を予想する
「プレモータム」演習を実施し、潜在的な障害の原因を特定して、障害を排除または軽減します。障害シナリオをテストし、その影響に関する理解を検証します。対応手順をテストし、手順が有効であること、チームが手順の実行を十分に理解していることを確認します。定期的にゲームデーを設定して、シミュレートされたイベントに対するワークロードとチームの反応をテストします。 - 運用上のあらゆる障害から学ぶ
運用のあらゆるイベントや障害から学んだ教訓を通じて、改善を推進します。チーム間と組織全体で教訓を共有します。
セキュリティ
2つ目の柱はセキュリティです。データとシステムを保護する方法、データの機密性の確保、ユーザーの管理、インシデント検出など、安全なクラウド環境を構築するための方法が取り上げられます。
設計原則
クラウドには、ワークロードのセキュリティ強化に役立つ多くの原則があります。
-
強力なアイデンティティ基盤を実装する
AWS最小特権の原則を適用し、 リソースとのそれぞれのやり取りに対する適切な認証により、職務分掌を徹底します。ID管理を一元化し、長期間にわたって一つの認証情報を使用し続けないようにします。 -
トレーサビリティを実現する
環境に対するアクションおよび変更をリアルタイムでモニタリング、警告、監査します。ログとメトリクスの収集をシステムに統合して、自動的に調査しアクションを実行します。 -
全てのレイヤーでセキュリティを適用する
複数のセキュリティコントロールを使用して深層防御アプローチを適用します。ネットワークのエッジ、VPC、ロードバランシング、全てのインスタンスとコンピューティングサービス、オペレーティングシステム、アプリケーション、コードなど、全てのレイヤーに適用します。 -
セキュリティのベストプラクティスを自動化する
ソフトウェアベースのセキュリティメカニズムの自動化によって、より迅速かつコスト効率の良い方法で、安全にスケールできるようになります。バージョン管理されているテンプレートにおいてコードとして定義および管理されるコントロールを実装するなど、セキュアなアーキテクチャを作成します。 -
転送中および保管中のデータを保護する
機密度レベルでデータを分類し、必要に応じて暗号化、トークン分割、アクセスコントロールなどのメカニズムを使用します。 -
データに人を近づけない
データに対する直接的なアクセスや手動処理の必要性を低減または排除するためのメカニズムとツールを使用します。これにより、機密性の高いデータを扱う際の誤処理、改変、ヒューマンエラーのリスクを軽減します。 -
セキュリティイベントに備える
組織の要件に合わせたインシデント管理および調査のポリシーとプロセスを導入し、インシデントに備えます。インシデント対応シミュレーションを実行し、ツールとオートメーションにより、検出、調査、復旧のスピードを上げます。
信頼性
3つ目の柱は信頼性です。期待通りの性能を発揮するワークロードや、要求に応えられない場合の迅速な回復にフォーカスしています。
設計原則
クラウドには、信頼性の向上に役立ついくつかの原則があります。
-
障害から自動的に復旧する
重要業績評価指標 (KPI) に関わるワークロードをモニタリングすることで、しきい値を超えた場合に自動操作をトリガーできます。この場合のKPIは、サービスの運用の技術的側面ではなく、ビジネス価値に関する指標である必要があります。これによって障害発生時の自動通知と追跡が可能になり、障害に対処する、または障害を修正するための復旧プロセスを自動化できます。より複雑な自動化を使用すると、障害が発生する前に修正を予期できます。 -
復旧手順をテストする
オンプレミス環境では、多くの場合、ワークロードが特定のシナリオで動作することを実証するために、テストを実施します。復旧戦略を検証するためにテストを実施することはあまりありません。クラウドでは、どのようにシステム障害が発生するかをテストでき、復旧の手順も検証できます。オートメーションにより、さまざまな障害のシミュレーションや過去の障害シナリオの再現を行うことができます。このアプローチでは、実際の障害シナリオが発生する前にテストおよび修正できる障害経路が公開されるため、リスクが軽減されます。 -
水平方向にスケールして集合的なワークロードの可用性を向上する
単一の大規模なリソースを複数の小規模なリソースに置き換えることで、単一の障害がワークロード全体に及ぼす影響を軽減します。リクエストを複数の小規模なリソースに分散することで、一般的な障害点を共有しないようにします。 -
キャパシティーを勘に頼らない
オンプレミスのワークロードにおける障害の一般的な原因はリソースの飽和状態で、ワークロードに対する需要がそのワークロードのキャパシティーを超えたときに発生します (これは頻繁にサービス妨害攻撃のターゲットとなる)。クラウドでは、需要とワークロード使用率をモニタリングし、リソースの追加と削除を自動化することで、プロビジョ二ングが過剰にも過小にもならない、需要を満たせる最適なレベルを維持できます。それでも制限はありますが、一部のクォータは制御でき、その他のクォータは管理可能です。 -
オートメーションで変更を管理する
インフラストラクチャの変更はオートメーションを利用して行う必要があります。管理する必要がある変更には、自動化に対する変更が含まれており、それを追跡して確認することができます。
パフォーマンス効率
4つ目の柱はパフォーマンス効率です。長期的かつ持続的なパフォーマンスを実現するためのコンピューティングリソースの最適化にフォーカスしています。
設計原則
以下の設計原則は、クラウド内で効率的なワークロードを実現し、維持するために役立ちます。
-
高度なテクノロジーの民主化
複雑なタスクをクラウドベンダーに委託し、チームがより簡単に高度なテクノロジーを実装できるようにします。ITチームに新しいテクノロジーのホスティングと実行について学んでもらうのではなく、テクノロジーをサービスとして消費することを検討してください。例えば、NoSQLデータベース、メディアトランスコーディング、および機械学習などは、いずれも特化された専門知識を必要とするテクノロジーです。クラウドでは、これらのテクノロジーがチームによる消費が可能なサービスとなり、チームはリソースのプロビジョニングと管理ではなく、製品の開発に集中できるようになります。 -
わずか数分でグローバル展開する
世界中の複数のAWSリージョンにワークロードをデプロイすることで、最小限のコストで、より低いレイテンシーとより優れたエクスペリエンスを提供できます。 -
サーバーレスアーキテクチャを使用する
サーバーレスアーキテクチャは、従来のコンピューティングアクティビティのために物理的なサーバーを実行して維持する必要性を取り除きます。例えば、サーバーレスストレージサービスは静的ウェブサイトとして機能させることができ (ウェブサイトサーバーが不要になる)、イベントサービスはコードをホストできます。これによって物理サーバーを管理する運用上の負担が取り除かれます。また、マネージドサービスはクラウド規模で運用されることから、トランザクションコストも削減することができます。 -
より頻繁に実験する
仮想的で自動化できるリソースを使うことで、異なるタイプのインスタンス、ストレージ、設定を使用した比較テストを簡単に実施できます。 -
メカニカルシンパシーを重視する
目標に最適なテクノロジーアプローチを使用します。例えば、データベースやストレージのアプローチを選択するときには、データアクセスパターンを考慮します。
コスト最適化
5つ目の柱はコスト最適化です。継続的にコストを抑えながら最新のアーキテクチャを構築する方法が解説されています。
設計原則
コスト最適化のため、以下の設計原則を検討します。
-
クラウド財務管理を実装する
クラウドで財務面での成功を実現し、ビジネス価値の実現を加速するには、クラウドの財務管理に投資する必要があります。組織は、テクノロジーと使用量管理の新たなドメインで機能を構築するために必要な時間とリソースを投入する必要があります。コスト効率の高い組織になるためには、セキュリティまたはオペレーショの能力と同様、知識の積み上げ、プログラム、リソース、プロセスを通じて能力を構築する必要があります。 -
消費モデルを導入する
コンピューティングリソースの使用分のみを支払い、ビジネス要件に応じて使用量を増減することができます。例えば、通常、1週間の稼働日に開発環境とテスト環境を使用するのは、1日あたり8時間程度です。未使用時にこのようなリソースを停止することで、コストを75% 削減できる可能性があります (168時間から40時間に減少)。全体的な効率を測定する: ワークロードのビジネス成果と、提供にかかったコストを測定します。このデータを利用すると、生産性および機能性の向上とコスト削減から得られるメリットを理解することができます。 -
差別化につながらない高負荷の作業に費用をかけるのをやめる
サーバーラックの準備や機器の設置、電源確保などの面倒なデータセンター運用作業はAWSが行います。また、マネージドサービスを使用することで、オペレーティングシステムやアプリケーションの管理に伴う運用上の負担も解消されます。この結果、ITインフラストラクチャよりも顧客と組織のプロジェクトに集中できるようになります。 -
費用を分析し帰属関係を明らかにする
クラウドを使用すると、ワークロードの使用量とコストを正確に特定しやすくなり、ITコストと収益ストリームや、個別のワークロードの所有者との帰属関係が明瞭になります。これによって投資収益率 (ROI) を把握できるため、ワークロードの所有者はリソースを最適化してコストを削減する機会が得られます。
持続可能性
最後の柱は持続可能性です。環境への影響、エネルギー消費、効率に着目し、リソース消費を削減するアプローチを示しています。
設計原則
クラウドワークロードを構築する際には、これらの設計原則を適用して、持続可能性を最大化して、影響を最小限に抑えます。
-
影響を理解する
クラウドワークロードの影響を計測し、ワークロードの将来の影響をモデル化します。顧客がお客様の製品を使用することによる影響、および最終的に製品を廃止および使用停止する際の影響などを含む、全ての影響源を含めます。作業単位ごとに必要なリソースと排出量を確認し、生産量と、クラウドワークロードの全影響を比較します。このデータを利用して重要業績評価指標 (KPI) を作成し、影響を抑えながら生産性を向上させる方法を評価して、提案された変更による影響を経時的に見積もります。 -
持続可能性の目標を設定する
クラウドワークロードごとに、持続可能性の長期目標を立てます。トランザクションごとのコンピューティングリソースやストレージリソースの削減などです。既存のワークロードに対する持続可能性向上のための投資のリターンをモデル化し、持続可能性目標に必要な投資のリソースを所有者に与えます。成長計画を立て、その成長により、ユーザー単位やトランザクション単位など適した単位に対して計測される影響の大きさが結果的に削減できるようにワークロードを構築します。目標により、ビジネスや組織のより大きな持続可能性目標の支援、回帰の特定、改善できる可能性のある分野の優先順位付けが可能になります。 -
使用率を最大化する
ワークロードのサイズを適正化し効率的な設計を実装して、使用率を高く保ち、基盤となるハードウェアのエネルギー効率を最大化します。ホスト単位のベースライン電力消費量があるため、使用率30% のホスト2つは、使用率60% のホスト1つよりも効率が悪くなります。同時に、アイドル状態のリソース、処理、ストレージをなくすか、最小化して、ワークロードに必要な合計エネルギー量を削減します。 -
より効率的なハードウェアやソフトウェアの新製品を予測して採用する
パートナーやサプライヤーが行っているアップストリームの改善をサポートし、お客様のクラウドワークロードへの影響の軽減に役立てます。より効率的なハードウェアやソフトウェアの新製品を継続的にモニターし評価します。新しい効率的なテクノロジーを迅速に採用できるように、設計に柔軟性を持たせます。 -
マネージドサービスを使用する
広範な顧客ベースでサービスを共有することで、リソースの使用率を最大化できます。こうすることで、クラウドワークロードをサポートするために必要なインフラストラクチャ数を削減できます。例えば、ワークロードをAWSクラウドに移行し、サーバーレスコンテナにAWS Fargateなどのマネージドサービスを採用することで、電力やネットワークなど、データセンターに共通するコンポーネントの影響を顧客間で共有できます。マネージドサービスは、AWSが大規模に運用し、効率的なオペレーションについて責任を持ちます。お客様の影響を最小化できるマネージドサービスを使用します。例えば、Amazon S3ライフサイクル設定を使用して、あまり頻繁にアクセスされていないデータを自動的にコールドストレージに移動したり、Amazon EC2 Auto Scalingを使用して容量を需要に合わせたりできます。 -
クラウドワークロードのダウンストリームの影響を軽減する
お客様のサービスを使用するために必要なエネルギーやリソースの量を削減します。お客様のサービスを使用するために顧客がデバイスをアップグレードしなければならない必要性を削減または排除します。Device Farmを使用したテストで予想される影響を理解し、顧客とともにテストしてお客様のサービスを使用することによる実際の影響を理解します。
参考
Ryusei Kakujo
Focusing on data science for mobility
Bench Press 100kg!