はじめに
Well-Architectedフレームワーク ホワイトペーパー 、皆さんご覧になったことはありますでしょうか？AWSのソリューションアーキテクトになるのであれば、一度は目を通しておきましょう、というアレです。
ただ、私にとっては、
・オンプレでのインフラ構築/運用経験がないので、情報量が多く、オーバーフローぎみ
・フレームワークの重要性は、ウェビナーでも多く触れられてるけど、いまいちその理由が腑に落ちない
だったので、ホワイトペーパーを参考にしつつ、自分が理解しやすいように整理してみようと思います。
今回は導入部として、
・ソリューションアーキテクト = 建築家
・クラウドでの一般的な設計原則
・要件のトレードオフ
という観点で書いてみます。
ソリューションアーキテクト = 建築家
AWSソリューションアーキテクト。
建築家というからには、施主の立場で考えるのが良さそう、ということで例をあげます。
依頼者目線で
あなたは家を建てたいとしましょう。
そんな時、きっとこんなことを考えます。
・部屋は何部屋欲しい?
・家族は何人? 将来家族が増えた場合も考える?
・災害が起こった場合はどうする?
・何年くらい住む？
・予算は?
悩んだ末、要件が固まってきました。
誰かに設計を依頼することにします。
図面の引き方を知っていて、建材について知っている、それだけの建築家は避けたいですね。
やっぱり経験豊富な人にお願いしたいところです。
建築家との共通点
AWSソリューションアーキテクトと建築家、共通する点があるはず。
AWSソリューションアーキテクトと建築家、共通する点があるはず。
それぞれ何をする人なのかざっくり書いてみましょう。
という点で、本質的に通底しているように思います。
ASA試験の設問意図
ASA試験の受講レベルの目安の一つに、実務経験の長さがあります。
難しい試験になるほど、
要件の全体像を把握したうえで、
顧客とっての価値を最大化する
ようなアーキテクチャを選択させるような設問が多く出題されます。
いわば、建築家としての総合力が試される形ですね。非常に合理的。
AWSが蓄積している優れた建築家のノウハウの集合体がWell-Architectedフレームワークです。
クラウドでの一般的な設計の原則
さて、クラウドを利用するなら、その利点をしっかりと認識しておくべきです。
クラウドの一般的な設計原則を見てみましょう。
要件のトレードオフ
要件のすべて満たすアーキテクチャ設計は困難です。
例えば、サーバーを助長化することで信頼性を上げることはできるけど、それでは予算オーバー、というような場合。
よって、要件のトレードオフが必要になってきます。
トレードオフをするためには、要件の優先順位をつけなくてはいけません。
トレードオフをするためには、要件の優先順位をつけなくてはいけません。
フレームワーク各柱の間の関係性は下図の通り。
信頼性、パフォーマンス効率、コスト最適化は三すくみの関係になります。
セキュリティと運用上の優秀性は、通常はトレードオフになることはないそうです。
おわりに
次回からはフレームワークの柱、それぞれについて、ホワイトペーパーからtipsをお届けします！
参考リンク
