Well-Architected

このレッスンを終えると、AWS Well-Architected フレームワークの6本の柱を挙げられ、要件の文がどの柱の話かを見分けられるようになります。

自分でサーバーを1台建てるなら

自分で建てたサーバーが動き始めた後、何を気にしてきたか思い出してください。おそらく次のようなことです。

• 手作業の設定を毎回間違えるので、手順を書いて自動化したい
• ポートを開けすぎていないか、鍵を誰が持っているかが気になる
• 1台しかないので、壊れたらサービスが止まる
• アクセスが増えると重くなるが、どこが遅いのか測っていない
• 使っていない開発用サーバーの電気代を払い続けている
• 台数を増やすほど電力を使うことに、そろそろ説明が必要になってきた

この6つの気がかりに、そのまま名前を付けたものが Well-Architected フレームワークの6本の柱です。設計を評価するときの観点を共通の言葉にしておくための枠組みで、AWS が公開しているベストプラクティス集でもあります。

6本の柱

持続可能性は後から追加された柱です。5本と書かれた古い教材が残っていますが、CLF-C02 では6本として扱われます。

柱を見分けるこつ

紛らわしいのは、信頼性とパフォーマンス効率、そしてコスト最適化と持続可能性です。次の切り分けで判断します。

• 止まらないようにする話なら信頼性です。速くする話ならパフォーマンス効率です
• 同じ「サーバーを増やす」でも、壊れても続けるためなら信頼性、遅いのを解消するためならパフォーマンス効率になります
• 「使っていない資源を止める」は、お金の文脈ならコスト最適化、環境負荷の文脈なら持続可能性です
• 「誰が何をしたか記録する」はセキュリティです。「運用手順を自動化する」は運用上の優秀性です

また、AWS Well-Architected Tool という無料のツールがあり、自分の構成を柱ごとの質問に答える形で点検できます。試験では「設計をベストプラクティスに照らして点検したい」という要件でこの名前が出ます。

全体に共通する設計原則

柱に加えて、全体に通じる設計原則もあります。キャパシティーの推測をやめること、本番と同じ規模でテストすること、自動化を進めること、構成を進化させ続けること、そして障害をあえて起こして備えを確かめること (ゲームデー) です。オンプレミスでは費用が高くつくために諦めていたことばかりで、クラウドだから実行できる、という並びになっています。

試験ではこう出る

• 「障害が起きても自動で復旧させたい」「単一障害点をなくしたい」→ 信頼性
• 「レスポンスを速くしたい」「インスタンスのサイズを見直したい」→ パフォーマンス効率
• 「使われていないリソースを削除して請求を下げたい」→ コスト最適化
• 「消費するエネルギーや資源を減らしたい」→ 持続可能性
• 「最小権限にしたい」「保管中のデータを暗号化したい」→ セキュリティ
• 「デプロイを自動化し、小さく変更したい」→ 運用上の優秀性

「6本の柱をすべて挙げよ」という直接の問いも出ます。頭文字ではなく、先ほどの気がかり6つの順で思い出すと落としにくくなります。

まとめ

• 6本の柱は、運用上の優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性です
• 止まらないためなら信頼性、速くするためならパフォーマンス効率で切り分けます
• 費用の文脈ならコスト最適化、環境の文脈なら持続可能性です
• AWS Well-Architected Tool で自分の構成を柱ごとに点検できます
• 持続可能性が加わって6本になっている点を古い教材と取り違えないようにします