内容
AWSのベストプラクティス環境構築の指針としてWell-Architectedがあります。これらはホワイトペーパーにまとめられていますが、技術的な要素だけではなく、ビジネス的な観点、組織や運用プロセスに関する項目もあり、AWSの資格試験などを通して学習しただけでは内容も分かりづらい箇所があったため、一度体系的に学習を行い、内容を図解化して何が書いてあるかをざっくりとまとめました。
資料
Well-Architectedは６つの柱がありますが、下記2つの資料に分けて解説を行っています。
両方ともJAWS-UG朝会で発表させて頂いたものですが合わせて100ページ程度の内容となっています。
-
信頼性の柱・パフォーマンス効率の柱・コスト最適化の柱・持続可能性の柱
-
運用上の優秀性の柱・セキュリティの柱
資料の見方
各柱の概要確認
各柱に「こういうポイントを意識して設計しましょう」という設計原則と「設計原則を実現するために具体的に何をやればいいか（ベストプラクティス）」の記載がある定義があります。本資料の中では「具体的に何をやればいいか（ベストプラクティス）」の定義について解説しています。
下記は信頼性の柱の例になりますが、基盤・ワークロードアーキテクチャ・変更管理・障害の管理の4つが定義されているのでここを詳しく見ていく形になります。
各柱の定義確認
下記は信頼性の柱の基盤の例になります。基盤という定義の中で考慮する点は大きくサービスクォータ管理・ネットワークトポロジー計画の2つがあります。
下記は上記の中のネットワークトポロジー計画の箇所になります。この中でさらに青丸で記載の考慮点があり、それを表す簡単なアーキテクチャ図があります。各柱のどの定義を説明しているか（今どこにいるのか??）は、右上のオレンジ色の箇所を見ることで分かります。なお本資料は概要のみを記載していますので、各項目の詳細に関してはホワイトペーパーを参照下さい。
各柱のまとめ
最後に各柱のまとめがあります。各定義毎にざっくりと具体的に何をやればよいかをまとめたものになっています。
Well-Architectedの導入について
IT部門以外との連携
Well-Architectedの導入については「技術的な視点」が必要になるもの以外にも「ビジネス的視点」・「組織的な視点」が必要になるものなど、様々な観点から考える必要があります。下記は運用上の優秀性の柱の組織の箇所になりますが、「外部環境、内部環境を分析して組織としての優先順位を決める」、「それを実現していくための最適な組織モデルを選択して責任範囲を定義する」というフェーズになります。その他コスト最適化の柱の中では最適なコストモデルの選択やコスト配分決定のため、ファイナンス部門との連携や事業部制組織の場合は各事業部門との連携が必要になることがあります。
全てを教科書通りにやらなくてよい
ベストプラクティスであるため、全てを書いてある通りに実施する必要は無いかと思います。これはWell-Architectedに限らずITILやSREなど他のフレームワークと同様です。ただし、例えば「ベストプラクティスA」というものがあって、それを実装していない場合、下記の2つのパターンでは大きく意味合いが異なります。
- 「ベストプラクティスA」を知らなくて実装していない
- 「ベストプラクティスA」を検討をしたが、要件・環境などから不要と判断し実装していない
上の場合はただ実装していないだけですが、下の場合は「実装しないという設計がされた」ことになります。
また、検討のフェーズや結果を文章化していくことの積み重ねが会社として大きなナレッジを形成していくと思います。
このような観点からWell-Architectedなどのフレームワークを学習するこは無意味では無いと感じております。