前段

Well-Architected Framework自体はよく聞くワードですが、その分量の多さ（とAWSドキュメントあるあるの若干の読みにくさ）にしっかりと読む機会がなかなかなかったため、ここで改めて自分なりに落とし込もうと思いました。

　Well-Architected Frameworkを読んで、「直訳過ぎて、何を言っているかわからないなぁ」となった時に見ていただけるような記事を目指しています。

※解釈に誤りがある場合はご指摘ください。
※ドキュメント本文そのままではないため、個人の解釈が入っている部分があります。　

関連記事

・AWS Well-Architected Frameworkについて詳しく見てみる【パフォーマンス】

・AWS Well-Architected Frameworkについて詳しく見てみる【持続可能性の柱】

記事内でワークロードという言葉が頻繁に出てくるので、ここで解説を入れておきます。

ワークロードとは：
ビジネス価値をもたらすリソースとコード (顧客向けアプリケーションやバックエンドプロセスなど) の集合のことです。
引用元：ワークロード

設計原則

① ビジネス成果に基づいてチームを編成する

1. 上司やリーダがクラウドの運用方法に関してしっかりと理解することが大事

2. 正しいクラウドの運用方法を使うことで、チーム各人のスキルや技術を最大限に活用できる

3. 運用の優秀性は会社の長期ビジョンを実現するためのKPIとなりえる

② オブザーバビリティを実装して実用的なインサイトを取得する

1. ワークロード・パフォーマンス・信頼性・コスト・健全性などを可視化

2. 上記の項目に対してKPIを設定し、可視化した情報をもとに素早く対処

3. パフォーマンス・信頼性・コストに関しては積極的に改善

③ 可能な限り安全に自動化する

1. インフラ・設定等のコード化（IaC）

　いわゆるCloudFormationやSystemManager, ElasticBeanstalkなど、リソースの作成や設定管理をコードで行い、自動化することを推奨しています。

2. イベントベースでワークロードを自動化

　StepFunctionやEventBridgeのようなワークロードを自動化できるサービスを利用して、イベントに対する人的介入の余地をなくそうということです。
　AWS Configを用いて設定変更を追跡し、それに付随して自動で設定の修正等を実施することができます。
　レート制限に関しては、AWS API Gatewayを利用することでAPI呼び出しについて制限を行うことができます。

④ 小規模かつ可逆的な変更を頻繁に行う

★ サービスをスケーラブルで疎結合になるように設計

疎結合に設計することで、システムの変更のサイクルを迅速に、柔軟に行うことができます。
例えば、以下のようなサービスがあります。

疎結合を実現するサービス説明

Lamba サーバーインスタンスではなく、Lambaによるトリガー処理で連結すること。

SQS SQSのキューイングを通信でインスタンス間関連を結ぶこと。

ELB サーバー間のトラフィック量を調整と連結をELBを起点により疎結合化を実現すること。

SNS SNSのアプリケーション間でインスタンス間関連を結ぶこと。

引用元：AWSアーキテクチャー（疎結合化編）
ほかにもKinesisも疎結合の実現に寄与するサービスです。

また、疎結合のイメージは以下のようなものです。

引用元：AWS Black Belt Online Seminar 2016 クラウドのためのアーキテクチャ設計 -ベストプラクティス-

⑤ 運用手順を定期的に改善する

★運用手順は定期的に改善

⑥ 障害を想定する

1. 障害をシミュレートし、影響度を理解する

　AWSにはAWS Fault Injection Serviceという、障害をシミュレートできるサービスがあります。

2. 見つかったリスクに対して、どう対応をするかのリスク管理を行う

　いわゆるリスクマネジメントのことですね。

参考：リスクマネジメントとは

⑦ 運用上のあらゆるイベントやメトリクスから学ぶ

1. 運用していくうえで発生したイベントや生涯を通じて改善する

2. ノウハウをチーム間、組織内で共有する

3. 共有するノウハウについてはあくまでビジネスの成果にどう影響するか、貢献するかという点についてに焦点を当てる

⑧ マネージドサービスを使用する

マネージドサービスは運用の負荷を下げるという目的において特に優秀です。クラウドを利用する際にはこれによるコストメリットを推すことが多いかと思います。

ベストプラクティス領域

この章では、運用上の優秀性を確保するために、チェックしたい領域について記載されています。
また、それぞれに対してベストプラクティスが記載されています。

① 組織

(1) 組織の優先順位

　運用上の優秀性≒ビジネスの成功を目指すにあたって、組織が何を基準に動いたらよいか、について以下の６つが上げられています。

・顧客ニーズ
・内部顧客のニーズ
・ガバナンス要件
・コンプライアンス要件
・様々な脅威のリスク情報
・メリットとリスクのトレードオフ

(2) 運用モデル

よくある運用モデルとそのメリットを提示しています

1. アプリ開発＋運用/インフラ開発

メリット
　・アプリ開発と運用が一体化することで、強力なフィードバックループが生まれる
　・インフラ側は標準化されたサービス群（開発/モニタリング/バックアップツール、ネットワーク等）で構築できる（アプリ側に提示する）

2. アプリ開発＋運用/ インフラ一部マネージドサービス利用

メリット
　・アプリ開発と運用が一体化することで、強力なフィードバックループが生まれる
　・インフラ側でもビジネスの差別化につながらない部分はAWSマネージドサービスに任せることで、効率的な労力の投資ができる

3. アプリ開発 + 運用 /運用サポートAWS専門家チーム/ インフラ開発

メリット
　・AWSの専門家（図中のクラウドセンターオブイネーブルメント（CCoE, COPE）を設置してアプリケーションの運用をサポートすることで、DevOpsの定着をより良い形で目指せる。最終的にはCOPEはフェードアウトする。

4. アプリ開発＋運用＋プラットフォーム開発/ プラットフォーム開発

メリット
　・アプリケーション開発にプラットフォーム開発を含めることで、開発の制限を減らし設計の幅が増える
デメリット
　・高度なスキルを持った人材が必要

(3) 運用者（と責任単位）の関係性

以下の所有者≒責任者です。
責任者よりすべてを把握している、という意味合いで所有者という単語を使用していると考えています。

1. リソースの所有者が明確

　誰が責任者か明確で、問題が発生したときに対処が迅速に行える。

2. プロセスと手順に専任の所有者

　手順が統一され、異なるチームも同じ方法で作業を進めやすくなる。

3. アクティビティに専任の所有者

　責任の所在が明確で、問題が生じた際の対応が早く行える。

4. 責任と所有権が特定の基準で設定

　チームメンバーが自主的に行動しやすく、何をすべきかがはっきりする。

5. 変更リクエストのメカニズム

　必要に応じてプロセスやリソースを柔軟に調整できる。

6. チーム間の責任分界点が明確

　協力しやすく、支援の方法がはっきりしている。

(4) 組織文化

運用の優秀性を実行するにあたって重要な組織文化について記載されています。

1. 評価する人がいる

　チームへの期待と方向性が理解できる。

2. チームメンバーに、リスクを把握したときにアクションする権限がある

　・意思決定の権限を分散させ、チームが重要な意思決定を行えるようにすると、成功率を向上しながらより迅速に問題に対処できるようになる。
　・失敗を受け入れるチームになる。

3. エスカレーションが奨励されている

　複雑な問題や重大な問題が、ビジネスに影響を及ぼす前に対処できる。

4. タイムリーで明確、かつ実用的なコミュニケーションができる状態

組織間の多様性を活用して、複数の独自の視点での意見を聞ける状態になることで、イノベーションを高め、確証バイアスに傾くリスクを軽減できる。

5. 実験が推奨されている

　・実験は、学習を加速し、チームメンバーが関心と当事者意識を持ち続けることの一助となる。
　・イノベーションが促進される。

6. 技術スキルを強化できる状態、またはそれが推奨されている

・クラウドの導入と最適化の加速と拡大につながる。
・イノベーションを行う上での土台となる「運用能力」を向上できる。

7. リソースの適切な配置

　人的リソースでなくても、オートメーションなどのツールでもよい。

② 準備

「準備」とは運用の優秀性のベストプラクティスを適用するにあたって、実行する必要があることについてです。

(1) オブザーバビリティを実装する

1. KPIを設定してモニタリングする

2. アプリケーションの状態やパフォーマンスを収集するロジックを実装する

3. UXを可視化できるロジックを実装する

4. アプリケーションが使用する外部サービスのヘルスチェックやパフォーマンスを監視するロジックを実装する

5. 分散システム間のリクエスト監視を実装する

　AWS X-Rayで実現できます。

(2) 運用設計を行う

1. バージョン管理を使用する

2. 変更をテストする

　いわゆるステージングや開発環境を用意するということです。

3. 構成管理システムを使用する

　AWS Configで設定変更を管理
　AWS AppConfigで環境全体の設定、検証、デプロイ、モニタリング

4. 構築/デプロイ管理システムを使用する

　AWSではCode兄弟を使用してCI/CDを実現できます。

5. パッチ管理を実行する

　・AMIやDockerイメージパイプラインを使用してパッチ管理
　・AWS Systems Manager Patch Managerを使用してパッチ適用プロセスを自動化

6. 設計標準（ベストプラクティス）をチームで共有する

　設計標準を文書化し、適時最新化している状態であることが大事。

7. コード品質の向上の為にプラクティスを実装する

　プラクティスとは、「テスト駆動型デプロイ、コードレビュー、標準の導入、ペアプログラミング」など。

8. 複数環境を実装する

　いわゆるステージング、開発環境のこと

9. 小規模かつ可逆的な変更を頻繁に行う

　リリースをこまめに行うことで、変更の範囲と影響を減らして迅速にロールバックできる。

10. 統合とデプロイを完全自動化する

　ワークロードのビルド、デプロイ、テストを自動化することで、手動プロセスによるエラーや労力を減らせる。

(3) デプロイリスクを緩和する

1. 変更の失敗に備える

　変更の失敗からの復旧手順やトラフィックシフト/分離を想定しておく。

2. デプロイをテストする

　・リリース手順をテストし、すべての手順が問題なく完了することを確認する。
　・IaCを使用してテスト環境のデプロイを行い作業量を減らすことも可能。

3. 安全なデプロイ戦略を使用する

　安全なロールアウトには、機能フラグ、ワンボックス、ローリング (canary リリース)、イミュータブル、トラフィック分割、ブルー/グリーンデプロイなどがある。

4. テストとロールバックを自動化する

　CI/CDパイプラインに統合して含めてしまう。

(4) 運用準備状況と変更管理を行う

1. 十分な人材が確保されているか検証するメカニズムを実装する

　トレーニングの実施率やスキルをもった人材が配置されているか、といったところですかね。

2. 運用準備状況のを定期的に確認できる状態にする

　運用準備状況レビュー（ORR）を使用する。要件のチェックリストを使用したレビューおよび検証プロセスのこと。
　はじめはORR、時間とともにAWS ConfigやSecurityHub、Control Towerなどに移行して自動化する。

3. RunBookを使用して手順を実行する

　ランブックとは、文書化された、特定の目的を達成するための実行手順のこと。
　最終的にはランブックをシェルやスクリプト言語を使用して自動化する。StepFunctionも使えるかも。

4. PlayBookを使用して問題を調査する

プレイブックとは、インシデントの調査に使用するためのガイドが書かれた文書のこと。
　最終的には自動化する。AWS Systems Manager のランブックにもEC2にセッションマネージャーに接続できなかった場合の自動化されたプレイブックがありましたね。私のケースではあまり役に立ちませんでしたが...

5. システムや変更をデプロイするにあたってあらかじめ切り戻しや障害復旧手順を担保しておく

6. 本稼働用のサポートプランを有効にする

　AWSのエンタープライズサポートプランなどに限らず、あらゆる依存ソフトウェア、サービスのサポートを有効にする。

③ 運用

実際に運用していく中で、何をしていけばよいかについて記載されています。

(1) ワークロードのオブザーバビリティの活用

1.メトリクスを分析する

　定期的に分析することで、技術的なパフォーマンスとビジネス成果の相関関係についてより詳しく把握できる。

2. ログを分析する

　運用上のボトルネック、セキュリティ脅威、その他問題を把握することができる。

3. トレースを分析する

　・パフォーマンスの問題を迅速に特定できる。
　・依存関係とその影響に関する知見が得られる。

4. KPIに関連したアラートを作成する

　受信した警告が直接的に業務や運用上の影響と関連付けられるようになり、積極的な対応の促進とパフォーマンス・信頼性の維持につながる。

5. ダッシュボードを作成する

　・あくまで視覚的インターフェースとして、アラームメカニズムの補完となるもの。
　・リアルタイムの情報をステークホルダーに提供することができる。

(2) 運用状態の把握

1. メトリクスを利用して業務目標とKPIを測定する

2. 運用の対応状況などのステータスを可視化する

　・運用リーダーは、チームがどのような種類のコール数に対応して業務を行っているのか、デプロイなど、どのような取り組みが進行中であるかを一目で把握できる
　・通常の運用に影響が及ぶ場合、アラートが関係者やユーザーコミュニティに配信して利用者が運用の状況を把握することができる。
　・運用者の対応ステータスを伝達する労力が削減される。

3. 運用の対応状況ステータスの定期レビューと改善の優先度付け

　サービスの提供、運用、メンテナンスのトレードオフが議論され、考慮に入れることができる。

(3) 発生したイベント（インシデント）への対応

1. イベント・インシデント・問題/課題の管理を行う

　文書化し適切に管理することで、対応と解決の効果的な戦略の策定に効果がある。

2. アラートごとに対応手順を用意する

　システムのアラートごとに明確な対応手順を定義しておくことで、具体的な対応をすぐ行うことができる。

3. ビジネスの影響に基づいて対応優先度を決定する

4. エスカレーション経路を確定する

　インシデント対応プロトコル内に明確なエスカレーションを確立することで、タイムリー、効率的に対応できるようにする。

5. サービスに影響するイベント発生時の顧客コミュニケーション計画（方法）を決めておく

6. ダッシュボードでステータスを知らせる。

　(2) の 5 でも記載があった通り、ダッシュボードを使用して、現在のシステム状態を一元的に伝えることで、意思決定の効率が向上する。

7. イベントへの対応を自動化する

④ 進化

学習、教育、改善

1. 継続的改善のプロセスを用意する

　ワークロードを社内外のアーキテクチャのベストプラクティスに対して評価する。
　Well-Architected レビューなどがそれにあたる感じですね。

2. インシデント後の分析を実行する

　インシデントの要因と予防措置を策定する。

3. フィードバックループを実装する

4. ナレッジ管理を実装する

　ただナレッジの置き場所を用意するだけではなく、その情報が古くならないよう管理する必要がある。

5. 改善の基準を定義する

　どういう状態になったら改善をするのかをシステム/ビジネス観点踏まえ具体的に定義する。それにより、感情的な投資を抑えデータドリブンな改善を実施することができる。前提としてデータが可視化され、適切なKPIが設定されている必要がある。

6. 知見（ノウハウ）を検証する

　定期的に得た知見を見直し、新たに得た知見を追加したり、フィードバックを求めたりする。
　知見を公開する。

7. 運用メトリクスのレビューを定期的に行う

　ビジネスに影響するメトリクスを頻繁に確認することで、改善の機械となるアクションを特定することができる

8. 教訓を文書化して共有する

最後に

各ベストプラクティスの中身については要点をピックアップしたものになります。
それぞれのベストプラクティスのアンチパターンが結構面白くて、ぐさっと来るものもあるので、ぜひ眺めてみてください。