AWS Well-Architected Framework ホワイトペーパーまとめ 1 【導入編】 #AWS

はじめに

Well-Architectedフレームワークホワイトペーパー、皆さんご覧になったことはありますでしょうか？AWSのソリューションアーキテクトになるのであれば、一度は目を通しておきましょう、というアレです。

ただ、私にとっては、

だったので、ホワイトペーパーを参考にしつつ、
自分が理解しやすいように整理してみようと思います。
今回は導入部として、

という観点で書いてみます。

AWSソリューションアーキテクト。
建築家というからには、施主の立場で考えるのが良さそう、ということで例をあげます。

あなたは家を建てたいとしましょう。
そんな時、きっとこんなことを考えます。

悩んだ末、要件が固まってきました。
誰かに設計を依頼することにします。

図面の引き方を知っていて、建材について知っている、それだけの建築家は避けたいですね。
やっぱり経験豊富な人にお願いしたいところです。

AWSソリューションアーキテクトと建築家、共通する点があるはず。
それぞれ何をする人なのかざっくり書いてみましょう。

	AWSソリューションアーキテクト	建築家 (= アーキテクト)
設計対象	ITインフラの基盤	生活の基盤
必要な知識	ネットワークの知識、各AWSサービスの利用方法、などなど	建材の知識、図面の引き方、などなど

設計対象と必要な知識は違いますが、

という点で、本質的に通底しているように思います。

ASA試験の受講レベルの目安の一つに、実務経験の長さがあります。
難しい試験になるほど、

ようなアーキテクチャを選択させるような設問が多く出題されます。
いわば、建築家としての総合力が試される形ですね。非常に合理的。

AWSが蓄積している優れた建築家のノウハウの集合体がWell-Architectedフレームワークです。

さて、クラウドを利用するなら、その利点をしっかりと認識しておくべきです。
クラウドの一般的な設計原則を見てみましょう。

項目	原則	なぜならクラウドであれば...
キャパシティー	必要なキャパシティーを勘に頼らない	必要に応じて*自動的にスケールアップおよびスケールダウン*できる
テスト	本番規模でシステムをテスト	*オンデマンドで作成*でき、テスト完了後、すぐにリソースの使用を終了できる
自動化	自動化でアーキテクチャ上の実験を容易にする	システムの*構築と複製が低コストで可能で、手作業によるコストも回避*できる。変更を追跡、監査、必要に応じて以前のパラメータに戻すことができる
技術革新	発展的なアーキテクチャを受け入れる	自動化とオンデマンドなテストが可能で、設計変更のリスクを低減できる。これにより、システムを*継続的に進化*させることができる
データ計測	データ計測に基づいてアーキテクチャを決定する	アーキテクチャの選択が、システムの動作にどのように影響を与えるかを示す*データを容易に収集*できる
トラブル対策	本番で想定されるトラブルをあらかじめテストし、対策する	本番環境のシミュレーションによる、*改善可能な箇所の把握が容易*だから

要件のすべて満たすアーキテクチャ設計は困難です。
例えば、サーバーを助長化することで信頼性を上げることはできるけど、それでは予算オーバー、というような場合。

よって、要件のトレードオフが必要になってきます。
トレードオフをするためには、要件の優先順位をつけなくてはいけません。
フレームワーク各柱の間の関係性は下図の通り。

信頼性、パフォーマンス効率、コスト最適化は三すくみの関係になります。
セキュリティと運用上の優秀性は、通常はトレードオフになることはないそうです。

次回からはフレームワークの柱、それぞれについて、ホワイトペーパーからtipsをお届けします！