[セッションレポート] 一緒にAWS Well-Architectedレビューをやってみよう #jawsdays2022 #jawsdays #jawsug

つくぼし

2022.10.20

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、つくぼし(tsukuboshi0755)です！

2022/10/8にJAWS-DAYS 2022 - Satellitesが開催され、私も試聴させて頂いたのですが、個人的にとても面白いと感じたセッションがありました。

AWS Well-Architectedについて非常に勉強になったので、ぜひ他の方にも知って頂きたいなと思い、セッションレポートを行います！

セッション情報

概要

AWS Well-Architected Frameworkを用いたアーキテクチャレビューは非常に便利なものではありますが、レビューに時間がかかったり、またスキルのあるレビューアをアサインすること自体にハードルがあることから、現場であまり活用されていないのが現状です。本セッションではフレームワークの単なる解説ではなく、実際に現場で活用できる勘所やレビュー時の判断基準など、実践で活用できるノウハウ※を伝授します。またより現場で活用しやすいよう（後日公開される動画が再利用できるよう）、セッションは疑似レビュー形式で実施し、資料はレビューでそのまま活用できるバージョンもあわせて公開します。

公式サイトはこちら

登壇者

大竹孝昌さん

動画

セッションレポート

AWS Well-Architected Frameworkのおさらい
- ベストプラクティス集ではなく、リスク評価の質問集
- 使用形式はWeb版がオススメ
質問①：PJの方針や条件(制約)は明確になってますか？
- システムやチームにおける優先順位を定義しているか
  - 重要視する項目をランキング形式(1位~3位くらいまで)で表現できているか
  - 全ステークホルダーと共有できているか
  - チーム内の優先順位を定義し共有できているか
- 準拠しなければならないルールを確認しているか
  - 法令や業界ガイドラインを確認しているか
  - 社内ルールを確認しているか
質問②：あらゆる障害や失敗にどのように備えていますか？
- ワークロードの正常性をモニタリングしているか
  - 正常性を定義しているか
    - 異常の検知ではない事に注意
    - 正常性の範囲から外れたものを異常として扱う
  - 正常性がモニタリングできる仕組みを実装しているか
  - モニタリングを実施し、分析も行っているか
- RPO/RTO(またはSLAやSLO)を定義しているか
  - リスクシナリオの具体化と自動復旧のサポート範囲をしっかり定義しているか
  - バックアップを自動化しているか
  - 障害の復旧を自動化しているか
    - オートヒーリングによる自動復旧
    - シングルAZ構成の自動復旧
    - DRサイトへの自動切り替え
    - 上記以外の自動復旧全般
- AWSのスケーラビリティを活かした構成や冗長化で可用性を高めているか
  - 高負荷時に自動でスケールしているか
  - マルチAZ構成にしているか
  - マルチリージョン構成にしているか
質問③：セキュリティリスクはどのようにコントロールしていますか？
- システムが保持する情報資産を把握しているか
  - その情報はどんな形式で存在するのか
  - どのサービスで管理すべきか
  - どのようにコントロールできるか
- 具体的なセキュリティリスクについて把握しているか
  - セキュリティ脅威のトレンドを把握しているか
  - AWSのセキュリティのトレンドを把握しているか
  - セキュリティリスクを特定し、優先順位付けしているか
- セキュリティリスクを定常的にモニタリングしているか
- 全レイヤーでセキュリティリスクの対策を実施している
  - マネージドサービス活用でリスクを低減しているか
  - 付与するアクセス権は最小限に絞っているか
  - ネットワークレイヤーで保護を自動化しているか
  - ネットワークアクセスは必要なものに絞っているか
  - 人とデータを遠ざける仕組みを実装しているか
  - データを暗号化しているか
  - コンピュート系サービスの保護を自動化しているか
  - 脆弱性管理を実施しているか
質問④：運用はどのように効率化していますか？
- 運用タスクを整理し、手順書を作成しているか
  - ランブック(平常時の対応手順)を作成しているか
  - プレイブック(障害時の対応手順)を作成しているか
- 自動化が必要な範囲を特定し、実装しているか
  - 自動化のモチベーションは何か
    - 工数削減
    - ヒューマンエラー防止
    - 時間短縮
  - 通知を自動化しているか
  - デプロイを自動化しているか
  - タスクを自動化しているか
- システム運用の正常性をモニタリングしているか
  - 正常性を定義しているか
    - 作業ミスの有無
    - 許容できる作業時間の範囲
    - 許容できる運用コストの範囲
    - 運用プロセスの整備状況
  - モニタリングを実施し、分析も行っているか
質問⑤：パフォーマンスはどのように管理していますか？
- パフォーマンス要件を指標化し、テストをしているか
  - 本番環境と同じ構成でテストしているか
  - 指標を超える高負荷を想定し、アラートを設定しているか
  - サービスクォータに余裕があることを確認しているか
  - 高負荷を想定したテストはある程度長時間で実行しているか
質問⑥：コストはどのように管理していますか？
- コスト要件を定義しているか
- コスト状況をモニタリングしているか
- コストの構造や特性を把握しているか
- アラートを設定しているか
質問⑦：改善や進化はメカニズム化していますか？
- 実績データをベースに分析や振り返りを行っているか
- 継続的な実践を目的としたプロセス化を行っているか
おまけ①：コストは最適化しないの？
- コスト改善が必要なタイミングで実施すればOK
- コストを改善するための視点(低減 or 最適化)の違いに注意
  - 単にコストをとことん下げたい(最小化したい)
    - サーバレスアーキテクチャが採用できるか検討する
  - コストを最適化したい
    - マネージドサービスを適材適所でうまく活用する
    - コストパフォーマンスのいいオプションを選択する
    - コスト改善のプロセスを継続的に実践する
おまけ②：持続可能性のことは考えないの？
- 炭素排出量に配慮が必要なタイミングで実施すればOK
  - Customer Carbon Footprint Tool
  - 「持続可能性≒コスト最適化」であり、視点が違うだけであるため
    - コスト最適化：PJや組織(企業)規模の視点で実施
    - 持続可能性：地球規模の視点で実践、『MOTTAINAI』精神が大事
  - 最もコスパの良いリソースを全リージョンから選択する
    - 他のリージョンを使う場合は転送料に注意
  - 課金の有無に関係なく不要リソースは積極的に削除する
- コスパの良いアーキテクチャは地球に優しい！