はじめに
AWSには、AWS Well-Architected というフレームワークがあります。
オンプレミスの時代では、「アプリ担当」「インフラ担当」が明確に分かれていることが多いです。しかし、クラウドが主流の現在、ビジネス要件に応じて適切なサービスを「利用（構築じゃなくて）」するといった能力が求められるようになり、アプリ担当・インフラ担当という垣根があるままでは戦えなくなってきているようです。
という背景から、AWSのサービスを適切に利用すべく、AWS Well-Architectedフレームワークを勉強する機会があったので、簡単にまとめてみます。
AWS Well-Architected というフレームワーク
これを知らないとAWSが使えないというものではなく、「クラウドを使ってシステムを構築・運用する際のベストプラクティス集」のようなものです。
オンプレからAWSに移行するといっても、ゼロから考えると色々な観点が抜け落ちることが想定されます。そこで、今考えているものがベストプラクティス集に沿っているか？沿っていない場合、沿わないことに合理性があるのか？を比較しながら見ていくことで、アーキテクチャの精度を上げていくことができます。
フレームワークの中身
フレームワークの全体像は以下のようになっています。
- 基本編：6本の柱
- 設計原則
- ベストプラクティス集
- ベストプラクティスに沿っているかの質問項目
- 応用編：AWSレンズ
「柱」とは「観点」のようなものです。6本の柱の内訳は、
となっており、どんなシステムを扱うにも必要な観点が含まれています。
それぞれの柱に対して、「設計原則」「ベストプラクティス集」「ベストプラクティスに沿っているかの質問項目」が用意されています。
AWSレンズ(AWS Lens)は、基本的な観点に加えて、業界や利用技術に特化した観点が追加で確認できるようにしたものです。例：ゲーム業界Lens、機械学習Lens）。本記事では、AWSレンズは割愛し、6本の柱のみにフォーカスします。慣れてくればAWSレンズもできるようになるはず。
AWS Well-Architectedの使い方（レビュー）
自分の扱うシステムをAWS Well-Architectedを通してレビューする
「AWS Well-Architected」を理解することで、「自分の扱うシステムをAWS Well-Architectedを通してレビューする」ことができるようになります。
レビューする目的は、
「自分の扱うシステムが、自社の事業に貢献できるか。自社の事業を阻害する要因がないか。」を理解し、改善をする
ことです（個人的な理解）。AWS Well-Architectedの公式ページは物量も多く、私はAWS Well-Architectedのすべてを理解しているわけではありません。また、全員がAWS Well-Architectedのすべてを理解する必要もないかもしれません。
基本的な使い方を理解して、AWS Well-Architectedにしたがってレビューを繰り返すことで、理解と改善を少しずつ進めて良ければよいと思います。
レビューするにはここを見る
先ほど述べたように6本の柱には以下のコンテンツが用意されています。
- 基本編：6本の柱
- 設計原則
- ベストプラクティス集
- ベストプラクティスに沿っているかの質問項目
まずは、
「設計原則」を理解して「質問項目」に答えてみる。その過程でベストプラクティスを理解する。という流れが良いのではないかと思います。
設計原則を理解する
設計原則では、それぞれの柱について、「こんな原則に基づいて設計するとよい」ということがサマリで書かれています。
運用をコードとして実行する：クラウドでは、アプリケーションコードに使用しているものと同じエンジニアリング原理を環境全体に適用できます。ワークロード全体 (アプリケーション、コードとしてのインフラストラクチャなど) をコードとして定義し、コードによって更新することができます。運用手順のスクリプトを記述し、イベントに応答してそのスクリプトをトリガーすることで自動的に実行できます。オペレーションをコードとして実行することで、人為的なミスを抑制し、イベントへの一貫性のある対応を実現できます。
小規模かつ可逆的な変更を頻繁に行う：ワークロードへの有益な変更の流れを増やすため、コンポーネントを定期的に更新できるようにワークロードを設計します。環境に導入された問題の特定と解決に役立たない場合に元に戻すことができるように、変更は小規模に行います (可能な場合は、顧客に影響がないようにします)。
運用手順を頻繁に改善する：運用手順を実施するときに、改善の機会を探します。ワークロードを改良するときに、手順もそれに応じて改良します。定期的なゲームデーを計画し、すべての手順が効果的であり、チームがその手順を熟知していることを確認および検証します。
障害を予想する：障害が起こる可能性を特定して除去または軽減できるように、「プレモータム」演習を実施します。障害シナリオをテストし、その影響に関する理解を検証します。対応手順をテストし、手順が有効であること、チームが手順の実行を十分に理解していることを確認します。定期的にゲームデーを設定して、シミュレートされたイベントに対するワークロードとチームの反応をテストします。
運用上の障害すべてから学ぶ：運用上のイベントと障害すべてから教訓を学び、改善を促進します。チーム間と組織全体で 教訓を共有します。
これを見ると、AWSがどんな方針を推奨しているのかわかります。
設計原則を軽く読むだけでも、関わりのあるシステムについて思うことが出てくると思います。
- 運用はコードで実行。CloudFormationのことを言っているのかな。普段の作業も、手順書レビューとかすごく時間がかかっているけど、手作業がなくなれば実績が何よりの信頼につながるからレビューの時間が減って品質も上がるかな…
- 商用リリースは小規模にやれって言っているな。AWSは1年で2000回以上リリースしている（参考）と言っていて、すごいな。システムどうしが疎結合じゃないとできないな。ハードル高いな
- 障害訓練（ゲームデー）、やってみるか
ベストプラクティスに沿った質問項目に答えてみる
質問項目は、それぞれの柱の観点について、「質問」と「ベストプラクティス」がセットになっているものです。
自分がステークホルダーからこれらの質問をされたとして、どう答えるか？を考えてみる
例えば、以下のような質問があります。
OPS 8：ワークロードの正常性はどのように把握するのですか? https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/w44aac19b5b9b5.html
質問に対し、「本来どうあるべきか」のヒントとして、以下のようなベストプラクティスが複数用意されています。
希望するビジネス上の業績 (注文率、顧客定着率、営業費用に対する利益など) と顧客に関する成果 (顧客満足度など) に基づいて、主要業績評価指標 (KPI) を特定します。KPI を評価して、ワークロードの成功を判別します。 https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/ops_workload_health_define_workload_kpis.html
ビジネスに貢献できたらシステムは正常、できなければ正常ではないよね。という観点で見てみるとどうか。と考えます。
AWS Well-Architectedレビューする上で重要なこと
フレームワークを理解してビジネス的な判断を行う
AWS社Well-Architected リードの高山さんが、この営みで最も大事なことを以下のようにおっしゃっています。
- 必ずしも全てをベストプラクティスに合わせるのがゴールではなく「ベストプラクティスを理解した上で、ビジネス的な判断を行う」こと。
- 「ベストプラクティスに適合させないことによる、各種リスクや改善点を顕在化させて認識し、チーム内に共有する」こと。
AWS Well-Architectedのフレームワークでは、各所で「ビジネスにどう貢献するか」が重要視されていると感じます。
一番最初の質問事項は、「優先順位はどのように決定すればよいでしょうか？」です。ビジネスを成功せるためにシステムが行うことの優先順位を、誰が、どう決めるのですか？という点です。
先ほど例で挙げた「ワークロードの正常性はどのように把握するのですか？」の質問に対しても、「KPIをまず設定しよう」ということがベストプラクティスです。
システム構築には、「ビジネス的な判断」が必要。ビジネスをわかっている事業会社のシステム部門の役割は非常に重要だと感じました。 AWS Well-Architectedはあくまでフレームワークだということです。
短時間でも良いので、回数やる。早めにやる。みんなやる。
他にも以下のことを意識すると良いそうです。
- 数時間で終わらせる。
- 設計フェーズの後戻りできる段階でやる。
- 継続的にやる。
- チームの適切な担当者と、ステークホルダーを集める
- あるべき姿に対して、いつまでに何をやるかを決める
後戻りができる設計段階で、ステークホルダーも含めてレビューをするのが良いとのことです。あくまでレビューであり、監査ではないので、「早めに、小さく、何度も、気軽に」行なうことが良いとされています。
意思を持って引っ張る人がいないと、忘れてしまいそうです。。
Well-Architected ツール
AWSのマネジメントコンソールにツールが用意されています。このツールを使うことで、質問に答えながら、ベストプラクティスにどれだけあてはまるかを確認することができます。
過去の結果も保存できるので、継続的なレビューにも便利に使えそうです。
認定パートナー制度があるらしい
Well-Architectedについて、認定制度があるようです。
コンサルやSIerとして大きい企業が名を連ねています。
Well-Architected フレームワークを深く理解し、高品質ソリューションの構築、ベストプラクティスの適用、ワークロードの状態チェック、および AWS のお客様がサポートを必要とする時、改善を行うために必要な専門知識を持っている企業が認定されます。
とのことです。
おわりに
- AWS Well-Architectedは、クラウドを使ったシステムがビジネスに貢献するためのベストプラクティス集。
- ベストプラクティスを理解し、ビジネス上の判断をすることが必要。
- 質問集を使ってレビューするとやりやすい。継続的にレビューしていく。
自分のチームでも、試しに「運用上の優秀性」だけ、質問集を使って議論してみました。45分で絶対終わると決めてやってみましたが、盛り上がってよかったです。（1回やるのは簡単でも、継続が難しいのですが。）
ここ違うよ！などありましたらコメント頂ければ幸いです。
公式ドキュメントの場所まとめ
リンクの貼り方なのか、新旧資料が混在しているのか…
探している資料がすぐに出てこないので、見つけたものを以下に貼っておきます。
