Help us understand the problem. What is going on with this article?

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

More than 1 year has passed since last update.

はじめに

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

ただ、私にとっては、

  • オンプレでのインフラ構築/運用経験がないので、情報量が多く、オーバーフローぎみ
  • フレームワークの重要性は、ウェビナーでも多く触れられてるものの、腑に落ちきれてない

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

  • ソリューションアーキテクト = 建築家
  • クラウドでの一般的な設計原則
  • 要件のトレードオフ

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

連載目次

[AWS Well-Architected Framework ホワイトペーパーまとめ 1 【導入編】 → 本記事
AWS Well-Architected Framework ホワイトペーパーまとめ 2 【運用上の優秀性】
AWS Well-Architected Framework ホワイトペーパーまとめ 3 【セキュリティ】
AWS Well-Architected Framework ホワイトペーパーまとめ 4 【信頼性】
AWS Well-Architected Framework ホワイトペーパーまとめ 5 【パフォーマンス効率】
AWS Well-Architected Framework ホワイトペーパーまとめ 6 【コスト最適化】

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

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

依頼者目線で

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

  • 部屋は何部屋欲しい?
  • 家族は何人? 将来家族が増えた場合も考える?
  • 災害が起こった場合はどうする?
  • 何年くらい住む?
  • 予算は?

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

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

建築家との共通点

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

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

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

  • 要件の優先順位をクライアントと一緒に洗い出し、
  • 物事の基盤を設計する

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

ASA試験の設問意図

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

  • 要件の全体像を把握したうえで、
  • 顧客とっての価値を最大化する

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

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

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

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

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

要件のトレードオフ

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

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

AWS study - frame.jpg

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

おわりに

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

参考リンク

オフィシャル W-Aホワイトペーパー

Catetin0310
備忘録を。ジャズとドラムが好き
knowledgecommunication-inc
クラウドインテグレーター、AI・VRの分野で様々なソリューションを展開
http://www.knowledgecommunication.jp/
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away