Well-Architected 6つの柱を
やさしく読む

Well-Architected は、サービスではなく
「考え方をまとめた文書」です。

AWS を触り始めると、必ずどこかでこの言葉に出会います。EC2 や S3 のように画面から作って使うものではありません。AWS が公開している読みものです。

中身をひとことで言うと、「良いシステムとは何か」を6つの観点に整理したものです。良いシステムの条件を1人で考えると、どうしても偏ります。エンジニアはセキュリティばかり気にし、経営はコストばかり気にする、という具合です。見落としがちな観点をあらかじめ並べておけば、その偏りに気づけます。

もう1つ大事なのは、これは守るべき規則ではないという点です。「必ずこうしなさい」ではなく、「あなたの設計はこうなっていますか」と問いかける質問集だと思ってください。

先に全体を見ておきます。細かい話はこのあと1本ずつ扱うので、ここでは「何を心配している柱なのか」だけつかんでください。

人と手順の話

作った後、毎日どう回すか。

かみ砕くと

ほかの5本が「システムそのもの」の話なのに対して、この柱だけは働き方の話です。手順書が古いまま放置されていないか。デプロイを人が手で叩いていないか。障害のあとに振り返りをしているか。そういう観点だと思ってください。

目的は「価値を届け続け、運用のやり方を改善し続けること」です。作って終わりにしないための柱です。

AWS が大事だと言っていること

• 手作業でやらず、書いたとおりに自動で作らせる
  AWS でサーバーを借りるサービスを EC2 といいます。サーバーを1台用意するには、画面上で20か所ほど設定します。人がやれば、いつか必ずどこかを間違えます。そこで設定内容をあらかじめコードで書いておき、それを読み込ませて自動で作らせます。何度作っても同じものができます。これに使うのが CloudFormation で、この考え方を IaC と呼びます。
• 直すときは、少しずつ、何度も
  一度に100か所直すと、動かなくなったときにどこが原因か分かりません。切り戻しも大変です。1か所ずつ小分けに直せば、おかしくなってもすぐ気づけて、すぐ戻せます。
• 作業手順を定期的に見直す
  「毎週金曜にこの作業をする」という手順は、作った当時は正しくても、システムが変われば古くなります。誰も理由を説明できない作業が残っていないか、定期的に点検します。
• トラブルが起きる前に、起こして試しておく
  「サーバーが1台止まったらどうなるか」を、実際に止めて確かめておきます。本番で初めて経験するより、訓練しておいたほうが確実です。避難訓練と同じ発想です。
• トラブルを解決したら、そこから学ぶ
  直ったところで終わりにせず、なぜ起きたのかをチームで共有します（振り返り）。そして次は人が対応しなくても済むように、仕組みを改善します。

現場ではこう見える

「担当者しか手順を知らない作業がある」「リリースのたびに深夜作業になる」「同じ障害が3回起きている」。こうした状態は、どれもこの柱が弱いというサインです。技術の問題に見えて、実際にはチームの回し方の問題であることがほとんどです。

よく出るサービス

この言葉が出たらこの柱

鍵を誰に渡すか

データとシステムを守る。

かみ砕くと

セキュリティと聞くとファイアウォールを思い浮かべるかもしれませんが、この柱の中心は権限の管理です。壁を高くする話よりも、鍵を誰に何本渡すかの話が先に来ます。

責任共有モデルと合わせて覚えてください。AWS はクラウドのセキュリティ（建物やハードウェア）を守り、あなたはクラウドにおけるセキュリティ（権限設定、暗号化、OS の更新）を守ります。この柱が扱うのは後者、つまりあなたの担当範囲です。

AWS が大事だと言っていること

• 誰が何をできるかを、1つずつ決めておく
  AWS では利用者ごとにユーザーを作り、そのユーザーに「できること」を許可していきます。これを管理するのが IAM です。全員に何でもできる権限を渡すと、操作ミス1つでシステム全体が消えかねません。必要な人に、必要なことだけを許可します（最小権限）。さらに、パスワードに加えてスマホに出る確認コードも必要にしておけば（MFA）、パスワードが漏れても侵入されにくくなります。
  なお、AWS アカウントを作ったときに最初にできるルートユーザーは、あらゆる操作ができる特別な存在です。普段の作業には使わず、MFA をかけてしまっておきます。
• 誰が何をしたか、後から追えるようにする
  「先週あの設定を変えたのは誰か」が分からないと、事故が起きたときに原因も被害の範囲もつかめません。AWS では CloudTrail が操作の記録を自動で残します（監査ログ）。
• 入口だけを守らない
  玄関の鍵が立派でも、窓が開いていれば入られます。ネットワークの入口、サーバー、アプリ、データと、何段階にも分けて守ります。1つ破られても次で止める、という考え方です。
• 人の注意力に頼らない
  「気をつけましょう」で守れるのは最初の数週間です。危険な設定がないかを自動でチェックし、見つけたら自動で知らせる仕組みを用意します（GuardDuty など）。
• 保存中のデータも、通信中のデータも読めなくする
  暗号化しておけば、万一データを持ち出されても中身は読めません。保存するデータの鍵を管理するのが KMS、通信を暗号化するのが https でおなじみの TLS です。
• 本番のデータに人が直接触る機会を減らす
  作業のたびに人が本番のデータベースに接続していると、いつか誤って消します。人が手で触るのではなく、決められた処理に任せます。
• 事故が起きたときの動き方を、先に決めておく
  起きてから考え始めると対応が遅れます。誰に連絡し、何を止め、どう調べるのかをあらかじめ決めて、一度練習しておきます。

現場ではこう見える

「全員が管理者権限を持っている」「退職した人のアカウントが残っている」「アクセスキーがチャットに貼られている」。どれも実際によくある状態です。派手な攻撃を受けるより先に、こうした足元から事故が起きます。

よく出るサービス

この言葉が出たらこの柱

壊れる前提で組む

落ちない。落ちても戻る。

かみ砕くと

クラウドの大前提は「ハードウェアはいつか壊れる」です。壊れないように祈るのではなく、壊れることを前提に、壊れても止まらない構成にするのがこの柱です。

覚え方はこうです。1台の高性能なサーバーより、普通のサーバー2台を別々の場所に置くほうが強い。ここでいう別々の場所が アベイラビリティーゾーン で、同じリージョンの中にある、離れた場所のデータセンター群のことです。片方が停電しても、もう片方が生き残ります（マルチAZ）。

AWS が大事だと言っていること

• 壊れたら、人を待たずに自動で切り替える
  深夜にサーバーが止まったとき、担当者が起きて対応するのでは、復旧まで何時間もかかります。「反応がなくなったら自動で新しいサーバーに切り替える」仕組み（フェイルオーバー）を、あらかじめ作っておきます。
• バックアップは、戻せるか試して初めて意味がある
  毎日取っていても、いざ戻そうとしたら中身が壊れていた、手順が分からなかった、というのは実際によくある話です。定期的に本当に戻してみて、戻せることを確認します（バックアップ）。どこまで守るかを決める物差しが RTO と RPO です。
• 1台を大きくするのではなく、台数を増やす
  処理が増えたとき、サーバーを高性能なものに交換する方法（垂直スケール）と、同じサーバーを2台3台と増やす方法（水平スケール）があります。クラウドでは後者を選びます。1台が壊れても残りが動き続けるからです。増やした複数台に処理を振り分ける係が ELB です。「ここが止まると全部止まる」という箇所を 単一障害点 と呼び、これをなくすのが目的です。
• 必要な台数を、勘で決め打ちしない
  自社でサーバーを買う場合、「増えるかもしれない」と多めに買って結局使わない、ということが起きます。クラウドなら、アクセスが増えたら自動で台数を増やし、減ったら自動で減らせます（Auto Scaling）。
• 設定変更も自動化して、記録を残す
  人が手で設定を変えると、いつ誰が何を変えたのか分からなくなります。変更も自動で行う形にすれば、履歴が残り、同じ変更を別の環境にも正確に適用できます。

現場ではこう見える

「サーバーが1台しかない」「バックアップは取っているが戻したことがない」「復旧手順が担当者の頭の中にしかない」。どれも普段は問題なく動きます。問題になるのは、いちばん困るタイミングだけです。

よく出るサービス

この言葉が出たらこの柱

速さと選び方

必要なものを、必要な分だけ、賢く。

かみ砕くと

ポイントは効率という言葉です。速ければいいのではなく、用途に合ったものを選べているかを問います。CPU が余っている高価なインスタンスも、遅すぎる小さいインスタンスも、どちらも非効率です。

「クラウドは試すのが安い」という性質を活かして、選択肢を実際に比べて決めよう、という発想もこの柱に含まれます。

AWS が大事だと言っていること

• 難しい部分は AWS に任せる
  データベースを自分でサーバーに入れて運用するには、専門知識と経験が必要です。AWS が面倒を見てくれるマネージドサービス（データベースなら RDS）を使えば、専門家がいないチームでも扱えます。
• 利用者の近くに置く
  データが地球の裏側にあると、それだけで表示が遅くなります。AWS は世界各地にリージョンを持っていて、そこへ短時間で展開できます。利用者の近くから届ければ、待ち時間（レイテンシー）が減ります。画像や動画を近い場所から配信するサービスが CloudFront です。
• サーバーの世話そのものをやめる
  サーバーレスという選択肢があります。サーバーが存在しないという意味ではなく、サーバーの用意も管理も AWS に任せ、自分は処理の中身だけを用意する方式です（Lambda が代表例）。
• 勘で決めず、試してから決める
  自社でサーバーを買うなら、試すためにも機材が必要です。クラウドなら数分で作って、試して、消せます。費用も使った数時間分だけです。だから、2つの案を実際に動かして比べてから選べます。
• 道具を用途で選ぶ
  どんなデータでも同じ置き場所に入れるのではなく、扱うデータの性質に合ったサービスを選びます。よく読むデータはキャッシュに置く、といった使い分けもここに入ります。

現場ではこう見える

「とりあえず大きめのインスタンスにしておいた」「遅いと言われたので1つ上のサイズに変えた」。原因を測らずにサイズを上げるのは、この柱の観点では改善ではありません。まずどこで時間がかかっているかを測ります。

よく出るサービス

この言葉が出たらこの柱

無駄をなくす

最小のコストで、同じ価値を。

かみ砕くと

これは「安くする」柱ではなく「無駄をなくす」柱です。必要な投資まで削ってサービスを不安定にするのは、最適化とは呼びません。

オンプレミスのサーバーは買った時点で費用が確定しますが、クラウドは止めれば課金も止まります。ここがコスト最適化の一番の武器です（初期投資と運用費）。

AWS が大事だと言っていること

• 請求額を見る人と、見る手順を決める
  誰も請求額を確認していないと、使われていないサーバーが何か月も動き続けて課金され続けます。月に一度は誰が何を確認するのかを決めておきます（Cost Explorer、Budgets）。
• 使わない時間は止める
  AWS は基本的に、動かした時間の分だけ課金されます（オンデマンド）。開発用のサーバーを夜間と休日に止めれば、その時間は請求されません。買い切りのサーバーでは絶対にできない節約です。
  逆に、24時間ずっと動かし続けることが決まっているものは、1年や3年の利用を約束する代わりに割引を受ける買い方（Savings Plans やリザーブドインスタンス）を選ぶと安くなります。途中で止められても困らない処理なら、さらに安いスポットインスタンスも使えます。
• 金額だけでなく「1件あたりいくらか」で見る
  利用者が増えれば請求額が増えるのは当たり前です。売上や処理件数で割った金額を見ると、効率が良くなっているのか悪くなっているのかが分かります。
• 自社の価値にならない作業に人を使わない
  サーバーの設置や、壊れたディスクの交換は、どの会社がやっても結果は同じで、そこに競争力は生まれません。AWS に任せて、自社にしかできない仕事に人を回します。
• どの費用が誰のものか分かるようにする
  AWS で作ったものにはタグという名札を付けられます。「営業システム用」などと付けておけば、後から部門ごとやシステムごとの費用を集計できます。付けていないと、合計金額だけ見えて内訳が分かりません。

現場ではこう見える

検証で作ったサーバーの消し忘れが、いちばんよくある無駄です。誰のものか分からない資源が増えると、消していいのか判断できなくなり、そのまま残り続けます。タグ付けは、この判断を将来の自分に渡すための作業です。

よく出るサービス

この言葉が出たらこの柱

電力と資源

環境への負荷を減らす。2021年に追加された6本目。

かみ砕くと

電力の消費と二酸化炭素の排出（カーボンフットプリント）を減らす柱です。コスト最適化と似た施策が並びますが、見ている指標が「お金」ではなく「消費する資源の量そのもの」である点が違います。

AWS が大事だと言っていること

• まず、どれだけ使っているかを知る
  減らすには、今の状態を測るところからです。AWS の利用によって出た二酸化炭素の量は、Customer Carbon Footprint Tool で確認できます。
• どこまで減らすかを決める
  目標がないと「余裕があるときにやる」で終わり、いつまでも手が付きません。
• 遊んでいるサーバーをなくす
  ほとんど仕事をしていないサーバーも、電気は使い続けます。10台に薄く分散させているなら、2台にまとめたほうが無駄が少なくなります。
• 省エネな機材に乗り換える
  AWS が自社で開発した Graviton という CPU は、同じ処理をより少ない電力で行えます。
• 自分専用ではなく、共有されたサービスを使う
  自分だけのサーバーを立てるより、多くの利用者で基盤を分け合うマネージドサービスのほうが、全体として使う資源が少なくて済みます。
• 使わないデータをためこまない
  置いたまま誰も見ないデータも、ディスクを占有し、電気を使います。S3 のライフサイクルルールで、古いものを自動で安い置き場所に移したり、削除したりできます。
• 利用者側の負担も減らす
  アプリが重いと、利用者のスマホの電池を余計に消費し、古い端末では動かず買い替えを促すことになります。送るデータ量を減らせば、その負担も減らせます。

よく出るサービス・機能

この言葉が出たらこの柱

柱の名前を覚えたあと、必ずここで詰まります。同じサービスが複数の柱に出てくるからです。「何のためにやったか」で切り分けるのが唯一のコツです。

AWS Well-Architected Tool

マネジメントコンソール上のサービスで、質問に答えていくと6つの柱の観点でリスクと改善案を出してくれます。利用は無料です。

レンズ（Lenses）

業種や用途に特化した追加の観点セット。サーバーレス、機械学習、金融、SaaS などがあります。基本の6つの柱に足して使います。

Well-Architected レビュー

一度やって終わりではなく、システムの成長に合わせて定期的に繰り返すものだと押さえてください。作った直後に問題がなくても、利用者が増え、機能が増えれば、弱いところは変わります。

実際に問われるのはこの形です。シナリオを読んで、どの柱の話かを選んでください。