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

はじめに

AWS Well-Architectedとは？

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

一般的な設計の原則

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

フレームワーク５本の柱

運用上の優位性

ビジネス価値を提供し、サポートのプロセスと手順を継続的に向上させる。

設計原則

• 運用のコード化
  • 人為的なミスの抑制とイベントに対する一貫性のある対応
• ドキュメントに注釈をつける
  • 変更の度にドキュメントの作成を自動化することで、ドキュメントを同期する
• 定期的に、小規模な、元に戻すことができる変更を適用する
  • 変更をこまめにおこなうことで、失敗した場合にすぐ元に戻せるようにする
• 運用手順を定期的に改善する
  • 運用手順を改善し続ける
• 障害を予想する
  • 障害シナリオをテストし、その影響に関する理解を検証する。そして対応手順をテストする。
• 運用上の全ての障害から学ぶ
  • 運用上の全てのイベントと障害から教訓を学び、改善を促進する
  • これを実現するためには、運用の中で発生した障害を記録し続ける必要がある。

ベストプラクティス

• 準備
  • AWS Configを使用して本番環境に適用する前にそれが標準ルールに準拠しているかを確認できる
• 運用
  • Cloud Watchで、ワークロードの運用状態をモニタリングできる
• 進化
  • ElasticSeachを使うとログデータを分析して実用的な分析を素早く行うことができる。

セキュリティ

設計原則

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

ベストプラクティス

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

信頼性

設計原則

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

ベストプラクティス

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

パフォーマンス効率

設計原則

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

ベストプラクティス

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

コスト最適化

設計原則

• 消費モデルを導入する
  • 使ってない時はリソースを使わないようにする
• 全体的な効率を測定する
  • ワークロードのビジネス成果とその実現にかかったコストを測定する
• データセンター運用の為の費用を排除する
  • サーバ設置にかかるお金がいらなくなる
• 費用を分析し、帰結させる
  • システムの使用状況とコストを正確に特定し、ITコストと各ワークロードの所有者との帰属関係を簡単に透明にできる
• アプリケーションレベルのマネージドサービスを使用して所有コストを削減する
  • メール送信やDBの管理といったタスクの為にサーバを維持する運用負担がなくなる

ベストプラクティス

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

まとめ

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

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