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


## はじめに
[Well-Architectedフレームワーク ホワイトペーパー](https://d1.awsstatic.com/International/ja_JP/Whitepapers/AWS_Well-Architected_Framework_2018_JA_final.pdf)、皆さんご覧になったことはありますでしょうか？AWSのソリューションアーキテクトになるのであれば、一度は目を通しておきましょう、というアレです。

ただ、私にとっては、

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

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

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

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

#### 連載目次
[AWS Well-Architected Framework ホワイトペーパーまとめ 1 【導入編】 → 本記事
[AWS Well-Architected Framework ホワイトペーパーまとめ 2 【運用上の優秀性】](https://qiita.com/Catetin0310/items/179f9c587a6b8b540a8a)
[AWS Well-Architected Framework ホワイトペーパーまとめ 3 【セキュリティ】](https://qiita.com/Catetin0310/items/08e1c4843cc5571cd3a5)
[AWS Well-Architected Framework ホワイトペーパーまとめ 4 【信頼性】](https://qiita.com/Catetin0310/items/c973552de5098fdda795)
[AWS Well-Architected Framework ホワイトペーパーまとめ 5 【パフォーマンス効率】](https://qiita.com/Catetin0310/items/12837377ab2d1c8f6c77)
[AWS Well-Architected Framework ホワイトペーパーまとめ 6 【コスト最適化】](https://qiita.com/Catetin0310/items/cc57d8018a3392dd9f73)

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

### 依頼者目線で
あなたは家を建てたいとしましょう。
そんな時、きっとこんなことを考えます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

![AWS study - frame.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/363781/9b021b7a-13e8-1ca4-412e-ae148c1cbbc5.jpeg)

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

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


## 参考リンク
[オフィシャル W-Aホワイトペーパー](https://d1.awsstatic.com/International/ja_JP/Whitepapers/AWS_Well-Architected_Framework_2018_JA_final.pdf)