AWSが公開している『AWS Well-Architected』ホワイトペーパーをメモをとりながらよんだので、自分なりの解釈でまとめてみました。

はじめに

AWS Well-Architectedとは？

• ６つの概念領域（柱）における一般的な設計の原則とベストプラクティスをまとめたもの
  • 運用上の優秀性
  • セキュリティ
  • 信頼性
  • パフォーマンス効率
  • コスト最適化
  • 持続可能性（2021年12月に追加）
• ワークロードを設計する時は６本の柱の間でトレードオフが行われる。セキュリティと運用性は、トレードオフされることはほぼない。
  • たしかにセキュリティがトレードオフされることは本番運用ではほぼない。
• AWSは職能分散型チームを推奨。複数のチームを内部標準に準拠させる点についてリスクがあるが、それを２つの方法で解決しようとしている。
  • １つ目は、各チームに準拠させる為のプラクティスを用意する
  • ２つ目は、基準を確実に満たすための自動チェックを実行するメカニズム

一般的な設計の原則

• 必要キャパシティの推測が不要
  • 必要なキャパシティを使用し自動でスケールアップ/ダウン
• 本番環境と同じスケールでシステムをテストする
  • 本番環境と同じスケールのテストをオンデマンドで作成し、テスト完了後にリソースを解放することで、本番環境をシュミレートする
• 自動化によってアーキテクチャでの実験を容易に
  • 構築を自動化することで簡単にシステムを構築・ロールバックする
• 発展するアーキテクチャ
  • ビジネスとその状況変化に対応するアーキテクチャの変更に柔軟に対応する（そのためにも自動化が必要）
• データに基づいてアーキテクチャを進化させる
  • アーキテクチャに関する選択がワークロードの改善について事実に基づいて意思決定ができる
• ゲームデーを利用して改善する
  • 本番環境のイベントをシュミレートすることで、アーキテクチャとプロセスのパフォーマンスをテストする

フレームワーク６本の柱

運用上の優秀性

ワークロードの開発と効率的な実行をサポートし、運用状況を把握しながら、ビジネス価値を提供するためのプロセスと手順を継続的に改善する。

設計原則

• ビジネス成果を中心にチームを編成する
  • リーダーシップのビジョンと、ビジネスに沿った運用モデルによって、チームがビジネス成果を出せるようにする
• オブザーバビリティを実装して実用的なインサイトを得る
  • KPIを設定し、テレメトリをもとに意思決定と対処をおこなう
• 可能な場合は安全に自動化する
  • 運用をコード化し、人為的なミスの抑制とイベントに対する一貫性のある対応を実現する
  • レート制御、エラーしきい値、承認などのガードレールを設けて、自動化そのものを安全にする
• 定期的に、小規模な、元に戻すことができる変更を適用する
  • 変更をこまめにおこなうことで、失敗した場合にすぐ元に戻せるようにする
• 運用手順を定期的に改善する
  • 運用手順を改善し続ける
• 障害を予想する
  • 障害シナリオをテストし、その影響に関する理解を検証する。そして対応手順をテストする。
• 運用上のイベントとメトリクスから学ぶ
  • 運用上の全てのイベントと障害から教訓を学び、改善を促進する
  • これを実現するためには、運用の中で発生した障害を記録し続ける必要がある。
• マネージドサービスを使用する
  • 可能な限りAWSのマネージドサービスを使い、運用上の負担を減らす

ベストプラクティス

• 組織
  • 優先順位、チームの役割と責任、運用モデルを明確にする
• 準備
  • AWS Configを使用して本番環境に適用する前にそれが標準ルールに準拠しているかを確認できる
• 運用
  • Cloud Watchで、ワークロードの運用状態をモニタリングできる
• 進化
  • Amazon OpenSearch Service（旧 Amazon Elasticsearch Service）を使うとログデータを分析して実用的な分析を素早く行うことができる。

セキュリティ

設計原則

• 強力なアイデンティティ基盤の実装
  • 最小権限の原則を守る
  • 権限の管理を一元化する
• トレーサビリティの維持
  • リアルタイムで監視、アラート、監査のアクションと変更をおこなう
• 全レイヤーへのセキュリティの適用
  • 外部接続のある単一レイヤーのみを保護するだけではなく、全てのレイヤーでセキュリティを意識する
• セキュリティのベストプラクティスの自動化
  • セキュリティをソフトウェアで自動化する
• データの保護
  • 保存あるいは伝送するデータの暗号化、トークン分割、アクセスコントロールを適切におこなう
• データに人の手を入れない
  • データに直接アクセスしたり手動で処理したりする必要を減らす、あるいはなくすメカニズムとツールを作成する
  • 機密性の高いデータを扱う際のデータの損失、変更、ヒューマンエラーのリスクを軽減する
• セキュリティイベントへの備え
  • インシデント対応のシミュレーションを実行
  • 自動化されたツールを使用して、検出・調査・復旧のスピードをあげる

ベストプラクティス

• セキュリティ基盤
  • ワークロードを安全に運用するための、アカウント管理やガバナンスなどの土台
• アイデンティティ管理とアクセス管理
  • AWS OrganizationsによるAWSアカウントのポリシーの一元管理・強制
  • AWS IAMによる認可
  • ロール、インスタンスプロファイル、IDフェデレーション、一時認証情報を使用したセキュアなアクセスを実現できる
  • ユーザやシステムは認証情報を共有してはいけない
  • ユーザアクセスは、パスワード要件やMFAの強制などのベストプラクティスを実践した上で、最小権限で与えられるべき
• 検出（旧: 発見的統制）
  • CloudTrail,CloudWatchでモニタリングとアラーム、AWS Configで設定履歴を確認、GuardDutyで脅威検出
• インフラストラクチャ保護
  • ネットワークをどう保護するか
  • 全ての環境で複数レイヤーで防御するべき
    • VPC
    • WAF
• データ保護
  • 機密レベルに応じてデータの保護方法を分ける
  • 保管中のデータに対しても、必要であれば暗号化などのコントロールをおこなう
  • 伝送中のデータも必要であれば暗号化する
    • ELB -> App の間の通信を暗号化するか否か
• インシデント対応
• アプリケーションセキュリティ
  • 設計・開発・デプロイのライフサイクル全体で、脅威モデリングや自動テストなどによりアプリケーションのセキュリティを作り込み、検証する

信頼性

設計原則

• 復旧手順をテストする
  • クラウドではシステム障害を簡単に検証できるので、実際の障害発生時の復旧手順を検証できる
• 障害から自動的に復旧する
  • MTTRを極小化するため
• 水平方向にスケールしてシステム全体の可用性を高める
  • 単一の障害がシステム全体に与える影響を軽減する
• キャパシティを予測しない
  • 需要と使用率をモニタリングして、リソースの追加・削除を自動化し、需要を満たす為に最適なレベルを維持する
• オートメーションで変更を管理する
  • インフラへの変更はコード化したうえで自動でおこなう。

ベストプラクティス

• 基盤
  • オンプレでは信頼性に影響を与える基本的な要件（ネットワーク帯域など）を事前に満たしておくがあったが、クラウドでは必要に応じて変更できる
  • サービスの利用制限には気をつける
• ワークロードアーキテクチャ
  • サービス指向アーキテクチャやマイクロサービスでワークロードを設計し、分散システムとして障害を防ぐ・障害に耐える作りにする
• 変更管理
  • 需要の変動に応じてリソースの追加や削除を自動でおこなうシステム（オートスケール）
  • 信頼性が高まり、ビジネスの成功が負担に変わることを防ぐ
• 障害管理
  • 障害への自動対応を仕組み化できる
  • 定期的にデータをバックアップし、バックアップリカバリをテストすることで、論理的及び物理的エラーから確実に復旧できる
  • 大切なのは、システムに対して自動化されたテストを頻繁に発生させ、どのように復旧するかを確認すること

パフォーマンス効率

設計原則

• 最新テクノロジーの標準化
  • 新しいテクノロジーを実行する方法を学習せずに、サービスとして利用できる
• 数分でグローバルに展開
  • わずか数回のクリックで、世界中の複数のリージョンのシステムを簡単にデプロイできる
• サーバレスアーキテクチャ
  • サーバの運用・管理をおこなう必要がない
• より頻繁に実験可能
  • 異なるタイプのインスタンス、ストレージ、設定を使用した比較テストを簡単に実施できる
• システムを深く理解
  • 実現しようとすることに最も適した技術アプローチを使用する

ベストプラクティス

• アーキテクチャの選択
  • AWSでは様々なリソースが仮想化され、様々な種類や設定を持つリソースを使用できるので、適切なものを選択し組み合わせる
  • データ駆動型のアプローチが必要
  • トレードオフを評価する
    • より高いパフォーマンスを実現する為に、整合性・耐久性・容量を重視するのか
    • 時間またはレイテンシを重視するのか
• コンピューティングとハードウェア
• データ管理（ストレージ、データベース）
• ネットワークとコンテンツ配信
• プロセスと文化
  • AWSは凄いスピードで進化する。絶えずレビューを欠かさないこと
  • 正常に動作していることを常にモニタリングすること

コスト最適化

設計原則

• クラウド財務管理を実装する
  • クラウドのコスト管理とコスト最適化のための知識、プロセス、体制に投資する
• 消費モデルを導入する
  • 使ってない時はリソースを使わないようにする
• 全体的な効率を測定する
  • ワークロードのビジネス成果とその実現にかかったコストを測定する
• 差別化につながらない手間のかかる作業にコストをかけるのをやめる
  • サーバ設置にかかるお金がいらなくなる
  • マネージドサービスを使えば、メール送信やDBの管理といったタスクの為にサーバを維持する運用負担がなくなる
• 費用を分析し、帰属させる
  • システムの使用状況とコストを正確に特定し、ITコストと各ワークロードの所有者との帰属関係を簡単に透明にできる

ベストプラクティス

• クラウド財務管理を実践する
• 費用認識
  • 事実上無限のオンデマンドキャパシティを活かすには、費用に対する新しい考え方が必要になる
    • リソースのコストをそれぞれの組織やオーナーに帰属させることで、無駄を削減する
    • コストの帰属を明確にすることで、利益率の高い製品を把握し、予算の配分先についてより多くの情報に基づいて決定できる
    • タグを使ってAWSの使用量とコストの分類や追跡ができる
• 費用対効果の高いリソース
  • コンピューティングリソースの高いインスタンスを使って短時間で処理した方が安いケース
  • マネージドサービス
  • リザーブドインスタンス、Savings Plans
  • スポットインスタンス
• 需要と供給を一致させる
  • 需要に合わせてリソースをプロビジョニングする
• 長期的な最適化
  • 既存のアーキテクチャを定期的にレビューし、現在でもコスト効率が優れているかどうかを確認する必要がある

持続可能性

2021年12月に6本目の柱として追加された。エネルギー消費を減らし、リソースの効率を上げることで、ワークロードが環境に与える影響を継続的に小さくする。

設計原則

• 影響を理解する
• 持続可能性の目標を設定する
• 使用率を最大化する
• より効率的なハードウェアやソフトウェアの新製品を予測して採用する
• マネージドサービスを使用する
• クラウドワークロードのダウンストリームの影響を軽減する

ベストプラクティス

• リージョンの選択
• 需要に合わせた調整
• ソフトウェアとアーキテクチャ
• データ管理
• ハードウェアとサービス
• プロセスと文化

まとめ

常に以下のポイントを意識しておく必要があると理解しました。

• あらゆる所で自動化を推進する
• データ（ファクト）ドリブンで改善する。その為に必要なのは計測（モニタリング）
• キャパシティプランニングをせず、需要と供給に応じてコンピューティングリソースを割り当てる
• 一方で無限にコストが増える可能性があるので、消費モデルを導入し「必要な時だけ使う」を徹底する