Well-Architected Framework
AWS Well-Architected フレームワークは、以下の5つの評価項目で構成されている。
- 必要なキャパシティを勘に頼らない
- 本番規模でシステムをテスト
- 自動化
- 発展的なアーキテクチャを受け入れる
- クラウドは自動化とテストが容易で設計変更のリスクを低減できる
- システムを継続して進化させる
- データ計測に基づいてアーキテクチャを決定する
- 本番で想定されるトラブルをあらかじめテストする
1. 運用上の優秀性
設計の原則
- 運用のコード化を行う
- ドキュメントに注釈を付ける
- 頻繁に小さく可逆的な変更を行う
- システムを小さく設計
- 失敗した場合に戻せるように
- 運用手順を頻繁に見直す
- 発生しうる障害を予想する
- 運用の失敗を改善に役立てる
ベストプラクティス
準備（本番環境への移行）
- チェックリストによる検証
- イベントと障害に対するテスト
- CloudFormationの利用
- CloudWatch等を利用した解析
- 運用の優先順位を決定する要因は明確ですか？
- リスクを評価して優先事項を決定することが重要である。
- ビジネスニーズを評価する
- 運用事項の決定には、ビジネスチームと開発チームの両方が参加する
- コンプライアンス要件を評価する
- 規制や業界標準のルールを考慮する
- 運用性を向上させるワークロード設計をしていますか？
- 設計標準を共有する
- システム設計に共通の設計標準を取り入れることで複雑性を軽減する
- 設計標準に対する変更や追加をリクエストする手順を作成し継続的に改善する
- クラウド運用に向けて設計する
- 伸縮性や従量課金制などのクラウドの特徴を活用して迅速な改善やテストなどの運用を実現する
- ワークロードの動作を深く理解する
- 計測ツールを用いてシステムで何が起こっているかを計測する
- 顧客の行動を深く理解する
- 計測ツールを用いてシステムの使用状況を計測する
- 障害を軽減しフローを改善するための手法を確立する
- フローを改善して品質向上やバグ修正を迅速に行えるアプローチを確立する
- デプロイのリスクを軽減する
- 頻度の高い変更、自動デプロイ、テスト、カナリアデプロイ、ワンボックスデプロイ、ブルーグリーンなどの手法を導入する
- ワークロードが運用可能であることをどのように確認していますか？
- 継続的改善の文化を育てる
- ビジネスに対する価値の理解を共有する
- ビジネスにとってシステムがどの程度重要であるのかをチーム全体で共有する
- 運用上の問題に対応するために必要なリソースを全てのチームが活用できる環境の提供
- 担当者の能力を確保
- トレーニングを受けた担当者を適切な人数配置する
- ガバナンスとガイダンスを文書化し共有する
- コンプライアンスについて理解しやすく評価可能な標準ルールを共有する
- 標準ルールの変更、追加をリクエストする手順を作成する
- チェックリストを使用する
- 運用手順書（ランブック）を使用する
- 障害対応手順書（プレイブック）を使用する
- 復旧演習を行う
運用
期待されている成果、およびその測定方法を決定し、システムと運用に関する測定基準（メトリクス）を特定する。システムとそのシステムに対する運用の正常性の双方を考慮する。イベント対応の優先度を定めて、影響の度合いに応じて追加の担当者を巻き込むエスカレーショントリガーも含める。計画外のイベントが発生した原因と影響範囲を確認し、今後の運用に反映させるとともに、計画外のイベントであっても自動的に処理されるようにシステムの設計を行う。デプロイやリリース管理、変更ロールバックなどはマニュアルで行なってはならない。
- 運用状態をどのように確認していますか？
- ビジネスと顧客について求められる成果を定義する
- 成功とはどのようなことを指すのか定義し文書化する
- 成功のメトリクスを特定し達成されているかどうかを確認する
- ワークロードのメトリクスを特定し達成されているかどうかを確認する
- 運用のメトリクスを特定し達成されているかどうかを確認する
- 基準値を定める
- メトリクスを収集および分析する
- 分析結果をレビューし対応を確認する
- 運用のビジネスレベルレビュー
- ビジネスの目標を達成するために改善が必要な分野を特定する
- 運用上のイベントをどのように管理していますか？
- ビジネスへの影響に基づいて運用イベントの優先順位を決定する
- イベントやインシデントを管理する方法を確立する
- アラートを設定したイベントごとの運用手順書（ランブック）を確立する
- 意思決定者を確立する
- 障害報告ルート（エスカレーションパス）を定義する
- プッシュ通知
- ダッシュボードを通じてステータスを通知
- 根本原因分析のためのプロセスの確立
進化
システムを継続的に少しずつ改善していくことが必要。システムと運用の両方に関して改善できる部分を洗い出し、優先順位を付ける。また、チームを超えて、運用から学んだ知見を共有する。
- 運用をどのように進化させていますか？
- 継続的な改善プロセス
- 改善の要因の定義
- フィードバックループを取り入れる
- 得られた知識を文書化して共有
- 運用メトリクスの評価を行う
AWSのサービス
AWS CloudFormationを用いてシステム構築を行う。またそれぞれのフェーズで以下のサービスを活用する。
| フェーズ | AWSサービス | 目的 |
|---|---|---|
| 準備 | AWS Config | システム標準を作成しそれに準拠しているか確認する |
| 運用 | Amazon CloudWatch | システムの運用状態をモニタリング |
| 進化 | Amazon Elasticsearch Service | ログデータを分析 |
2. セキュリティ
設計の原則
- 強固な認証基盤を整備する
- 追跡可能性を実現する
- 全てのレイヤーにセキュリティを適用する
- セキュリティのベストプラクティスを自動化する
- 転送中および保管中のデータを保護する
- データへの直接的なアクセスや手動処理を減らす
- セキュリティイベントに対して準備を行う
ベストプラクティス
アイデンティティとアクセス管理
権限を持つユーザのみが管理者の意図した方法でリソースにアクセスできるようにする。IAMを用いてきめ細やかなポリシーを適用し、ユーザやグループ、ロール、リソースにアクセス許可を割り当てる。認証情報はシステム間で共有しない。プログラムによるAPIアクセスなどには、STSを用いた一時的な認証情報の利用も検討する。
- ワークロードの認証情報をどのように管理していますか？
- MFAの導入
- パスワードの要件を決定
- 認証情報を定期的に更新
- 認証情報を定期的に監査
- 一元化されたIDプロバイダーを使用
- AWSサービスへの人為的なアクセスをどのように制御していますか？
- 認証情報を共有しない
- ユーザのライフサイクルポリシを定義
- 最小権限を付与
- アクセス要件を明確に定義
- ロールやフェデレーションを用いてアクセス権を付与
- AWSサービスへのプログラムによるアクセスをどのように制御していますか？
- 認証情報を共有しない
- 動的な認証
- 最小権限を付与
- アクセス要件を明確に定義
発見的統制
発見的統制には様々な手法があり、アセットとその詳細な属性の一覧を作成し、意思決定やライフサイクル管理を促進することで、運用の基準を確立する手法や、内部監査を使用して、実態がポリシーと一致しているかの確認を行う手法などが存在する。AWSにはこれらを実現するために、Cloud TrailやCloudWatch、AWS Config、AWS GuardDutyなどの様々なサービスが提供されている。
またログ管理も非常に重要である。また、潜在的なセキュリティインシデントを特定するためにログを分析することも重要である。
- ワークロードのセキュリティイベントをどのように検知していますか？
- 利用可能なロギングを有効化する
- AWS CloudTrailを分析する
- ログを一元的に収集し自動的に分析する
- 重要なメトリクスとイベントをモニタリングし、アラートを送信する
- AWS Marketplace や APNパートナーのソリューションを活用する
インフラストラクチャ保護
多層に渡る防御などによって組織や規則上の義務を果たす必要がある。AWSが提供しているサービスやパートナーが提供するサービスを利用して、境界保護の強化、出入口のモニタリング、広範囲のロギング、モニタリング、アラート等を行う必要がある。
- ネットワークをどのように保護していますか？
- VPCを使用してトラフィックを分離・制御する
- 境界でトラフィックを制御する
- 利用可能な機能を使用してトラフィックを制御する
- セキュリティグループ
- ネットワークACL
- サブネット
- AWS Marketplace や APNパートナーのソリューションを活用する
- AWSのセキュリティ機能と一般的なセキュリティ脅威に関する最新情報をどのように認識していますか？
- リリース毎に新しいセキュリティサービスを評価する
- セキュリティサービスを使用する
- コンピューティングリソースをどのように保護していますか？
- デフォルトの設定を強化する
- ファイルの整合性を確認する
- 侵入検知を利用する
- AWS Marketplace や APNパートナーのソリューションを活用する
- 設定管理ツールを使用する
- 定期的にパッチ適用と脆弱性スキャンを実行する
データ保護
AWSでは、データの暗号化やキーローテーション、ロギング、高い耐久性、バージョニングなどのデータを保護するための様々な機能を提供している。また、保管中と転送中の暗号化を複数の手段で実現できる。
- データをどのように分類していますか？
- データ分類スキーマを使用する
- データ分類を適用する
- データ保護メカニズムをどのように管理していますか？
- KMSやCloudHSMなどのキー管理サービスを使用する
- サービス内に存在する制御機能を利用する
- クライアントサイドのキー管理を使用する
- AWS Marketplace や APNパートナーのソリューションを活用する
- 保存中のデータをどのように保護していますか？
- データの暗号化
- 転送中のデータをどのように保護していますか？
- データの暗号化
インシデント対応
インシデント発生時に、システムの分離や影響範囲拡大の抑制、通常運用への復帰、フォレッジング（証拠保全）などの対応を行うことが可能な体制を確立しておく必要がある。
- インシデントに対してどのように備えていますか？
- セキュリティチームに事前にアクセス件を付与しておく
- ツールの準備
- ゲームデーの実施
AWSのサービス
| 内容 | AWSサービス | 備考 |
|---|---|---|
| アクセス管理 | IAM | リソースへのアクセス管理 |
| 発見的統制 | CloudTrail | APIコールの記録 |
| 発見的統制 | Config | リソース設定インベントリ |
| 発見的統制 | Guard Duty | 悪意のある動作や不正な動作の検出 |
| 発見的統制 | CloudWatch | リソースのモニタリング |
| インフラストラクチャの保護 | VPC | |
| インフラストラクチャの保護 | CloudFront | 安全な配信、DDoS攻撃を緩和するSieldとの結合 |
| インフラストラクチャの保護 | WAF | アプリケーションファイアウォール |
| データ保護 | KMS | 暗号化キーの作成と管理 |
| インシデント対応 | CloudFormation | クリーンルームの作成 |
3. 信頼性
高い信頼性を維持するためには、システム基盤を十分にモニタリングして、需要や要件の変更を処理するメカニズムを設けることが必要である。具体的には、インフラやサービスの障害からの復旧、必要に応じたリソースの動的な取得、設定ミスや一時的なネットワーク問題などの障害軽減などを検討する必要がある。
設計の原則
- 復旧手順をテストする
- 障害から自動的に復旧する
- 水平方向にスケールして統合的なシステムの可用性を向上させる
- キャパシティを勘に頼らない
- 自動化の変更を管理する
ベストプラクティス
基盤
システムのアーキテクチャを設計する前に、信頼性に影響を与える基盤についての要件が整っていることが重要で、AWSの場合はこれらの要件は最初から組み込まれているか、必要に応じて対処できるようになっている。一方で、AWSでは意図せずに過剰にリソースをプロビジョニングしてしまわないように、サービスの上限が設定されている。
- AWSサービスの制限をどのように管理していますか？
- 能動的にモニタリングし制限事項を管理する
- 制限のモニタリングを自動化する
- 変更できない制限に注意する
- フェールオーバに備えて十分余裕をもったリソースを確保しておく
- AWS上でのネットワーク構成をどのように設計していますか？
- オンプレミスと接続しない構成を検討する
- AWSとオンプレミス間に可溶性の高い接続を実装する
- 可用性の高いネットワーク接続を実装する
- 複数のVPCで重複しないプライベートIPアドレス範囲を使用する
- 拡張性と可用性を考慮してサブネットの割り当てを行う
変更管理
変更がシステムに及ぼす影響を把握し、KPIへの対応を自動化することができる。需要の変更に対応してリソースの追加や削除が自動的に行われるようシステムを設計しておくことで、信頼性が向上しビジネスの成功が運用の負担になることも避けられる。適切にモニタリングされていれば、KPIが予測された基準から逸脱したときにアラートを送ることができる。
- システムに対する需要の変化にはどのように対応していますか？
- 自動的にスケールするワークロードとする
- 負荷テストを実施する
- AWSリソースをどのようにモニタリングしていますか？
- 全ての階層でモニタリングする
- モニタリングに基づいて通知を行う
- イベント発生時にイベントに自動で対応する
- 定期的にレビューを実施する
- 変更をどのように実施していますか？
- 自動化する
障害管理
障害が発生した場合にそのまま本番環境で診断して修復するのではなく、本番環境外で新しいリソースに置き換えて分析することが重要である。論理エラーと物理エラーの両方から確実に復旧できるように、定期的にデータをバックアップし、バックアップファイルをテストしておく。目標復旧時間（RTO）や目標復旧時点（RPO）を定め、システムの回復性を事前に評価する。
- データをどのようにバックアップしていますか？
- 手動のバックアップ
- 自動化したバックアップ
- 復旧テストの実施
- バックアップの暗号化
- システムがコンポーネントのエラーに耐えるようにどのように設計していますか？
- 全ての階層でモニタリングを行いエラーを検知する
- 複数のAZにデプロイする
- 疎結合のシステムにする
- グレースフルデグラデーション
- 自動機能を使用して修復を行う
- 可用性に影響するイベント発生時に通知を行う
- 自動修復された後でも通知を送信する
- システムの弾力性をどのようにテストしていますか？
- 障害対応に備えた障害対応手順書（プレイブック）を用意する
- 障害注入テストを行う
- ゲームデーの実施
- RCA(Root Cause Analysis)の実施
- 災害時のリカバリプランはどうなっていますか？
- 目標復旧時間（RTO）や目標復旧時点（RPO）を定義する
- 上記を達成するために災害対策(DR)戦略を定義する
- 本番サイトとDRサイトのずれを管理する
- DRサイトへのフェイルオーバを定期的にテストする
- 復旧を自動化する
AWSのサービス
| 内容 | AWSサービス | 備考 |
|---|---|---|
| 基盤 | IAM | リソースへのアクセス管理 |
| 基盤 | Config | リソース設定インベントリ |
| 基盤 | Trusted Advisor | サービスの制限を把握 |
| 基盤 | Shield | DDoSからの保護 |
| 変更管理 | CloudTrail | APIコールの記録 |
| 変更管理 | Config | リソース設定インベントリ |
| 変更管理 | Auto Scaling | 需要管理の自動化 |
| 変更管理 | CloudWatch | リソースのモニタリング |
| 障害管理 | CloudFormation | リソースを規則的にプロビジョニング |
| 障害管理 | Glacier | 耐久性の高いアーカイブ |
4. パフォーマンス効率
需要や技術の進歩に合わせてパフォーマンスを維持することが重要である。
設計の原則
- 最新テクノロジーの標準化
- グローバル化を即時に実現
- サーバレスアーキテクチャの使用
- 実験の頻度の増加
- 適合したテクノロジーアプローチ
ベストプラクティス
選択
特定のシステムに最適なソリューションは、ワークロードの種類によって異なり、多くの場合は複数のアプローチを組み合わせたものとなる。複数のソリューションを使用して、様々な機能を有効化することで、パフォーマンスを向上させることができる。アーキテクチャを選択する際には、データ駆動型のアプローチを使用して判断を行う。
- 最も良いパフォーマンスのアーキテクチャをどのように選択していますか？
- テストの結果（ベンチマーク）を元に検討する
- 負荷テストの結果を元に検討する
- コンピューティングソリューションをどのように選択していますか？
- 複数のサービスの中から検討する
- インスタンスの設定オプションを検討する
- コンテナの設定オプションを検討する
- 関数の設定オプションを検討する
- 伸縮性を活用する
- ストレージソリューションをどのように選択していますか？
- ストレージ特性を検討する
- 設定オプションを検討する
- アクセスパターンを検討する
- データベースソリューションをどのように選択していますか？
- データベース特性を検討する
- 設定オプションを検討する
- アクセスパターンを検討する
- データベース以外の他のアプローチを検討する
- ネットワークソリューションをどのように選択していますか？
- ロケーションを検討する
- サービスを検討する
- ネットワーク機能を検討する
レビュー
システム導入から時間が経つと、新しい技術とアプローチが利用できるようになる。AWSの新たなサービスや機能を利用することで、パフォーマンスを大幅に改善できる可能性がある。アーキテクチャのパフォーマンスが何で制約されているかを把握しておくことで、その制約を解決するリリースに気づくことができる。
- 新しいサービスや機能をどのように取り入れていますか？
- 評価するプロセスを作成する
モニタリング
システムを実装したらパフォーマンスをモニタリングし、エンドユーザが認識する前に問題を解決する必要がある。モニタリングメトリクスを利用して、閾値を超えたときにアラームを送信するようにする。誤検出が大量に発生していないかや、データを処理しきれなくなっていないかなどを確認する。
- 期待通りのパフォーマンスを発揮しているかをどのようにモニタリングしていますか？
- モニタリング
- 安全な境界を超えた場合にアラートを送信する
- 問題の修正を自動化する
トレードオフ
ソリューションを構築する際にトレードオフを考慮することで最適なアプローチを選択できる。トレードオフによりアーキテクチャの複雑さが増す可能性があることに留意する。
- パフォーマンスを向上させるためにトレードオフをどのように利用していますか？
- AWSサービスを利用する
- パターンを使用する
- キャッシュ
- リードレプリカ
- シャーディング
- 圧縮
- バッファリング
AWSのサービス
| 内容 | AWSサービス | 備考 |
|---|---|---|
| レビュー | AWSブログ | 新しいサービス情報の取得 |
| モニタリング | CloudWatch | リソースのモニタリング |
5. コスト最適化
設計の原則
- 消費モデルを導入する
- 全体的な効率を評価する
- データセンターの運用費を排除する
- 支出を分析し帰属させる
- 所有コストを削減するためにマネージドサービスとアプリケーションサービスを利用する
ベストプラクティス
コスト効率に優れたリソース
適切なサービスを用いた優れた設計システムでは、最もコスト効率に優れたリソースが使用されており、優れたコスト効果が得られる。
- AWSサービス選択の際にコストをどのように評価していますか？
- サービスを選択する
- ライセンスコストを最適化する
- サーバレスとコンテナベースのアプローチを使用する
- 適切なストレージを使用する
- 適切なデータベースを使用する
- コスト目標を達成するためにインスタンスタイプとサイズをどのように選択していますか？
- メトリクスに基づいてリソースをサイジングする
- コスト削減のために料金モデルをどのように選択していますか？
- リザーブドインスタンスとリザーブドキャパシティ
- スポットインスタンス
- リージョンごとのコスト差を考慮
- データ転送料金についてどのように計画していますか？
- 最適化
- CDNの利用
- Direct Connectの利用
需要と供給の一致
需要と供給を最適に一致させることが最もコストが掛からないが、その一方で障害に備えて供給に十分な余力を残しておくことも重要である。AWSでは需要に応じて自動的にリソースをプロビジョニングできる。使用するパターンやプロビジョニングに掛かる時間についてもよく考慮する必要がある。
- リソースの供給と顧客の需要をどのように一致させていますか？
- Autoscalingの利用
- KinesisやSQSなどのバッファサービスの利用
- 時間ごとに調整する
費用の把握
それぞれのビジネスオーナまたは製品オーナに属するコストを明確にすることで、リソースを効率的に使用して無駄を削減できる。コストの帰属を明確化することが必要。コスト配分タグを使用してAWS使用料とコストを分類および追跡できる。
- AWS使用量とコストをどのようにモニタリングしていますか？
- リソースのタグ付け
- Cost Exploerの使用
- 予算超過の通知
- ビジネス成果に基づいてコストを配分
- AWS使用量をどのように管理していますか？
- グループとロールを定義
- プロジェクトのライフサイクルを追跡
- 不要なリソースをどのように排除していますか？
- 削除の自動化
- 削除プロセスを定義
継続した最適化
AWSによる新たなサービスや機能のリリース時に、既存の決定事項を見直すことで、よりコスト効率のよいシステムとすることができる。定期的にデプロイについてレビューする際には、コストを削減する上でどのサービスが役にたつか評価する。
- 新しいAWSサービスをどのように評価していますか？
- 定期的なレビュー
- コスト最適化を行う担当者を置く
- ワークロードのレビューと分析
| 内容 | AWSサービス | 備考 |
|---|---|---|
| コスト効率に優れたリソース | Cost Explorer | リザーブドインスタンス導入 |
| 需要と供給の一致 | Auto Scaling | 需要管理の自動化 |
| 費用の把握 | Cost Explorer | 使用状況の確認および追跡 |
| 継続した最適化 | AWSブログ | 新しいサービス情報の取得 |
