【AWS】Well-Architected Frameworkをホワイトペーパーから紐解く ~導入編~

はじめに

Well-Architectedフレームワーク ホワイトペーパー、皆さんご覧になったことはありますでしょうか?AWSのソリューションアーキテクトになるのであれば、一度は目を通しておきましょう、というアレです。
ただ、私にとっては、
・オンプレでのインフラ構築/運用経験がないので、情報量が多く、オーバーフローぎみ
・フレームワークの重要性は、ウェビナーでも多く触れられてるけど、いまいちその理由が腑に落ちない

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

・ソリューションアーキテクト = 建築家
・クラウドでの一般的な設計原則
・要件のトレードオフ
という観点で書いてみます。

ソリューションアーキテクト = 建築家

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

依頼者目線で

あなたは家を建てたいとしましょう。
そんな時、きっとこんなことを考えます。
・部屋は何部屋欲しい?
・家族は何人? 将来家族が増えた場合も考える?
・災害が起こった場合はどうする?
・何年くらい住む?
・予算は?
悩んだ末、要件が固まってきました。
誰かに設計を依頼することにします。
図面の引き方を知っていて、建材について知っている、それだけの建築家は避けたいですね。
やっぱり経験豊富な人にお願いしたいところです。

建築家との共通点

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

設計対象と必要な知識は違いますが、
要件の優先順位をクライアントと一緒に洗い出し、
物事の基盤を設計する
という点で、本質的に通底しているように思います。

ASA試験の設問意図

ASA試験の受講レベルの目安の一つに、実務経験の長さがあります。
難しい試験になるほど、
要件の全体像を把握したうえで、
顧客とっての価値を最大化する
ようなアーキテクチャを選択させるような設問が多く出題されます。
いわば、建築家としての総合力が試される形ですね。非常に合理的。
AWSが蓄積している優れた建築家のノウハウの集合体がWell-Architectedフレームワークです。

クラウドでの一般的な設計の原則

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

要件のトレードオフ

要件のすべて満たすアーキテクチャ設計は困難です。
例えば、サーバーを助長化することで信頼性を上げることはできるけど、それでは予算オーバー、というような場合。
よって、要件のトレードオフが必要になってきます。
トレードオフをするためには、要件の優先順位をつけなくてはいけません。
フレームワーク各柱の間の関係性は下図の通り。

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

おわりに

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

参考リンク
オフィシャル W-Aホワイトペーパー

この記事を書いた人

aws-recipe-user