こんにちは！
大変なご時世ですが、自宅のリプレイスを控えております中の人です。
大幅なスペックアップが見込める半面、利用料金の増加に耐えられるかが気になる今日この頃です。。。
弊社でも使えてたり使いきれてなかったりするAWSですが、この学習もかねて、
その設計原則である「Well-Architected Framework」について私なりにまとめてみました。
この記事のゴール
- AWS Well-Architected Frameworkがどんなものか知る
- AWS Well-Architected Frameworkの学習を通じて、クラウドにおける設計原則に触れてみる
- AWS設計で使える各種サービスの名前を知る
- 具体的にAWS Well-Architected Frameworkをどう活用するのか、活用できるのかを知る
簡単な目次
- はじめに ～クラウドの特徴って？～
- Well-Architected Framework (W-A)
- 概要等
- 一般的な設計原則
- 運用上の優秀性
- コスト最適化
- 信頼性
- パフォーマンス効率
- セキュリティ
- W-Aを実用するために便利なモノ・コト
- まとめ
はじめに ～クラウドの特徴って？～
集中型と分散型
ITシステムは、歴史上、集中型と分散型を繰り返してきました。
現在のパブリッククラウドは集中型で、オンプレは分散型と捉えることができます。
- 分散型 パーソナルコンピューター・サーバー(DC・オンプレ)
- 集中型 大型コンピューター(旧型)、パブリッククラウド(現在)
この「前提の違い」というのは、オンプレとクラウドでの勘所の大きなと違いとなってきます。
クラウドの使い方
使い方としては、
「使いたいとき」、「使う分だけ」、「従量課金」
が基本になります。
クラウドの使い方を電気に例えると、
- スイッチのオンオフで使える (オンプレだと自家発電から)
- どこからでも使える (発電機の場所にあまりとらわれない)
- 電柱・電線は共有 (自分で配線しない)
- 使用量はこっちが決める (準備した電気が余らない)
- 計測が容易 (利用料・量の計測基盤が提供されており、計測が簡単)
というようになるかなと思います。
Well-Architected Framework (W-A)
「違い」を踏まえた設計について
このように、オンプレとクラウドでは、そもそもの環境基盤からして違ってきますが、
「じゃ、設計の時どうすればいいのか」ということになります。
それの設計原則として、AWSでは、「Well-Architected Framework (W-A)」というものを公表しています。
W-Aの概要
W-Aとは、AWSのソリューションアーキテクトが、AWSユーザーの長年に渡る多く経験との声から作り上げた
「システム設計・運用の”大局的な”考え方とベストプラクティス集」と言えます。
今でも定期的に更新されており、時代の流れに沿ったものとなっています。
フレームワークの文章は、ホワイトペーパーとして公開されており、
そのフレームワークの中身は、『一般的な設計原則』と以下5つの『柱』から構成されています。
鬼滅みたい
- 運用上の優秀性：ビジネスの価値を提供するための監視、継続的なサポートプロセスの改善などについて
- コスト最適化：最も低価格でシステムを実行しビジネスの価値を提供などについて
- 信頼性：サービスの中断から回復、需要に対する動的なリソース調達、設定ミス等の軽減などについて
- パフォーマンス効率：リソースの効率的な利用、需要の変化やテクノロジーの進化に応じた対処などについて
- セキュリティ：リスクの評価と軽減を通したビジネス価値の提供、情報・システム・資産の保護なえどについて
それぞれの『柱』では、
- 設計原則
- 定義
- (定義に対する)ベストプラクティス
- 主要なAWSサービス
- リソース(参考資料)
の項目が設けられています。
実際にフレームワークを活用するときは、後述の通り「ヒアリング」を基にするのですが、
まずは各項目の内容について簡単に紹介したいと思います。
一般的な設計原則
5つの『柱』の前に、一般設計原則についてです。
これに関しては、オンプレミスでの考え方をそのまま適用しづらい部分に関してまとまっている項目だと思います。
設計原則の内容は以下の通りです。
実際に稼働して計測し、確実なキャパシティを設計
スペックの試算から始めるのではなく、実際に稼働させてスペックを決める
本番環境と同じスペックおよび構成でテスト
本番環境を簡単に複製・破棄できるため、それによるテストを行い、リリース後の障害を減らす
環境構築の自動化
システム複製を自動化で行えるため、再現性を高めて人為的ミスや工数を減らし、戻しやすくする
頻繁なデプロイによるリスク軽減
ビジネスに合わせた柔軟な対応ができ、設計変更による影響リスクを軽減できる
データを収集、データに基づく意思決定
様々なメトリクス・ログ収集基盤を用いたワークロード分析と改善を進める
ゲームデーを利用し、緊急事態に備える
障害を故意に起こす「ゲームデー」を定期開催し、訓練・改善点洗い出しを行う
運用上の優秀性
次に、各『柱』についてみていきたいと思います。
運用に関する内容が詳しく描かれているのがこの項目です。
本ブログでは、「原則」を紹介し、「ベストプラクティス定義とそれに対する対応」を抜粋するという形でまとめていきたいと思います。
原則
- 運用をコードで管理・実行
- ドキュメントをコードと一緒に管理
- 小規模なリリースを頻繁に実施、切り戻しの容易化
- 定期的な運用の改善
- 障害の予測と準備
- 運用上すべての障害イベントを元にした情報共有と改善促進
ベストプラクティス定義とそれに対する対応
以下3つが挙げられています。
準備
システムの正常化判断基準やコード化、運用フローの標準を行うこと。
サービスとしては以下あたりが挙げられています。
オペレーション
システムおよび運用の健全性の監視方法、イベントの管理を行うこと。
この『柱』に限らないのですが、特にCloudWatchが重要視されています。
進化
ログデータ等の分析を行うこと。
分析を行うので、以下のサービスが紹介されています。
コスト最適化
コスト面の設計について書かれています。
原則
- 使う時だけ使う、「消費モデル」の導入
- 全体的な費用効率の測定やアラート設定
- 費用の分析とリソースの最適化
- アプリケーションにおけるマネージドサービスの活用 (稼働時間の削減)・・・人とサーバーに対して
- DC廃止とマネージドサービスの活用 (リソース維持費の削減)・・・家賃、電力や管理費のイメージ
※ちょっとわかりづらかったので、勝手に改変した部分があります。
ベストプラクティス定義とそれに対する対応
費用認識
費用のモニタリング、使用状況の管理と不要リソースの削除を行う
コストにも「監視」があります。また、予算や随時管理できるようなサービスが紹介されています。
費用対効果の高いリソース
適切なマネージドサービス・タイプやサイズ・購入方法等の選択すること
各種マネージドサービスも紹介されていますが、購入方法ということでは以下のサービス(機能？)なんかが挙げられます。
需要と供給の一致
需要に合わせたスケールの利用
この場合のサービスはAuto Scalingになります。(種類色々ありますが)
長期的な最適化
新しいマネージドサービスの評価と検討、最適化の常時検討やレビューを行うこと。
サービスというより、AWS公式ブログやイベントなどで最新情報を仕入れ、しっかり検討することについて書かれています。
信頼性
どんなサービスも、可用性が低くては当然ダメなので、その点について書かれています。
原則
- 復旧手順のテスト
- 障害からの自動回復 (主要業績評価指標 (KPI) をモニタリング)
- ⽔平⽅向のスケールによるシステム全体の可⽤性向上
- キャパシティ推測の禁止
- 自動化による変更の管理
ベストプラクティス定義とそれに対する対応
基盤
サービス上限の管理、NW構成の管理を行う
上限管理ではTrusted Advisor, NWであればVPCなどが挙げられます。
変更管理
システム需要の変化およびリソースのモニタリング、変更プロセスの自動化と記録を行う。
ここでもモニタリングです。また、スケーリングも当然必要になってくるので、以下サービス等が紹介されています。
障害の管理
障害を想定した設計と自動化、KPIを元にしたバックアップとリストアのテスト
自動化に関してだとCloudFormation、バックアップに関してだとS3が挙げられます。
パフォーマンス効率
ちょっと特殊な構成で書かれている「柱」だと勝手に思っています。
他項目にはないのですが、「選択」では、わりと具体的にサービスの特徴と用途の違いを述べています。
そのサービスについては、今回は抜粋して紹介いたします。
原則
- 先進的なテクノロジーをサービスとして利用
- 数分でグローバルに展開
- サーバーレスアーキテクチャを使⽤
- 頻繁な実験の実施
- 特性を理解したサービスの選択
ベストプラクティス定義とそれに対する対応
選択
適切なサービス(コンピューティングリソース・ストレージ・DB・NW)の選択を行う。
大量の具体例が書かれていました。
例えば、
- コンピューティングでAuto Scalingの活用有無
- ストレージサービス使い分け (例. EBS or S3)
- DB(SQL or NoSQL)の使い分け (例. RDS or DynamoDB)
- NW機能の活用 (例. VPC, Route53)
のようなものです。
レビュー
新機能の取入れ検討を行う。
『コスト最適化の柱』でもあったように、AWS公式ブログやイベントなどで最新情報を仕入れようと書かれています。
モニタリング
パフォーマンスについての監視・検知、アクションの自動化を行う。
例のごとくCloudWatchが紹介されています。これをトリガーに、各種自動化ができます。
トレードオフ
「整合性、耐久性、 容量」に対する「時間と遅延（レイテンシー）」のトレードオフの検討を行う。
この定義は自分にとって若干分かりづらかったのですが、最終的に「整合性」「料金」「複雑性」に対しての「早さ」のトレードオフというイメージで無理やり腹落ちさせています。
例. CloudFrontを導入して、エッジロケーションを活用する(整合性は下がる。複雑性は増す。)
セキュリティ
最後の柱ですが、名前の通りセキュリティに関してです。
こちらも多くのサービスが紹介されていました。
原則
- 認証基盤の実装
- トレーサビリティの有効化
- 全レイヤーへのセキュリティの適⽤(多層防御)
- セキュリティのベストプラクティスの⾃動化
- 転送中および保存中のデータ保護
- データへの手入れ・アクセスの原則禁止
- セキュリティイベントに対する準備
ベストプラクティス定義とそれに対する対応
それぞれに対応するサービスが多数ありました。
アイデンティティ管理とアクセス管理
認証の管理、人・プログラムからのアクセス制御と証跡取得を行う。
認証とアクセス制御ではIAMが要になります。
発⾒的統制
セキュリティイベントの検知・検出、モニタリング、ログの管理と分析を行う。
以下のサービスが紹介されています。モニタリングだけでなく、ログでもCloudWatchは有効です。
インフラストラクチャ保護
ソリューションの活用、多層防御の実施。
VPCが例にはなりますが、それ以外にも、多層防御を実現するAWSの各種セキュリティサービスが存在します。
データ保護
通信中及び保管中の暗号化、耐久性に応じたストレージ種類の選択を行う。
以下が挙げられます。
インシデント対応
ログの記録、イベントに対するアクションの自動化、コード化による環境の再現
自動化・コード化という意味ではCloudFormationが挙げられます。
W-Aを実用するために便利なモノ・コト
先述の通り、実際にフレームワークを活用して設計するときは、ホワイトペーパーにもある「ヒアリング項目」に対して回答していくことで、どこまでベストプラクティスに沿っているかを確認することができます。
このヒアリングシートはExcelでも配布されておりますが、それ以外にも活用できるモノ・コトは多数あります。
AWSのソリューションアーキテクトやAWSのW-A認定パートナー
ざっくり言えば、「AWSの人」「AWS販売代理店等の人」に相談することかなと思います。
W-Aと、それを元にしたヒアリングシートにのっとったレビューを受けることができるようになっています。
レビューはソリューションアーキテクト職の人とディスカッション等を行うのですが、
実施プロセスは、W-A ホワイトペーパーの1項目として明確に規定されています。
W-Aパートナーに関しては、以下を参照ください。
https://aws.amazon.com/jp/blogs/psa/aws-well-architected-partner-program/
AWS Well-Architected Tool
AWS内にある、無料のW-Aのセルフチェックサービスです。
Excelで公開されているチェックシートとは別で、レビューの実施、バージョン管理、レポート出力までがセルフでできるようになったサービスです。
最近日本語対応されたので、よりレビューしやすくなりました。
AWS Trusted Advisor
すべてではないですが、W-Aのベストプラクティスに則っているか自動チェックしてくれるサービスです。
この「すべてではない」というのは、運用関連の部分で、ここは各々次第なのではさすがにチェックできません。
指摘の具体性が高く、このサービスを見るだけで、網羅的に状況を把握したり、管理の抜け漏れを探したりできます。
そうやって自動的に評価される内容を確認し、それに沿って改善・対処を行うことで、より「ベストプラクティス」に近い使い方を目指せます。
(参考) AWS認定試験
個人的な意見ですが、各種AWS認定も、ベストプラクティスを学んだり肌で感じたりするのにいい教材の一つだと考えています。
「〇〇の場合なら◇◇サービスを活用」のように、具体的な活用事例からW-Aを理解することもできると思います(ソリューションアーキテクトとか特に)。
※参考
https://aws.amazon.com/jp/certification/certification-prep/
https://aws.amazon.com/jp/certification/certified-solutions-architect-associate/
まとめ
- クラウドはオンプレと「勘所」が変わる
- その「勘所」として、AWSはWell-Architected Framework (W-A) を公開している
- W-Aには、「一般原則」と、以下5つの「柱」が存在する
- 運用上の優秀性：ビジネスの価値を提供するための監視、継続的なサポートプロセスの改善
- コスト最適化：最も低価格でシステムを実行しビジネスの価値を提供
- 信頼性：サービスの中断から回復、需要に対する動的なリソース調達、設定ミス等の軽減
- パフォーマンス効率：リソースの効率的な利用、需要の変化やテクノロジーの進化に応じた対処
- セキュリティ：リスクの評価と軽減を通したビジネス価値の提供、情報・システム・資産の保護
- W-Aを活用する場合は、レビューを行うツールや体制を知っておくと便利
長くなりましたが、以上となります。
正直60ページ近いホワイトペーパーまとめるのはブログ一本じゃ無理じゃんって途中で思いましたが、
せめて、なんとなーく概要だけ知ってもらえて、なんとなーく活用方法だけでも知ってもらえればと思います。
それでは皆様、くれぐれも健康にはお気を付けくださいね。
この文章が誰かのお役に立てれば幸いです。
参考資料
AWS資料
・Black Belt「AWS Well-Architected Framework」
AWS以外
作成にあたり、以下参考にさせていただきました。
クラスメソッド様ありがとうございます。
参考にさせていただいた記事
・Well-Architected Frameworkの柱「運用の優位性」を読み解いてみた
・Well-Architected Frameworkの柱「コスト最適化」を読み解いてみた
・Well-Architected Frameworkの柱「信頼性」を読み解いてみた
・Well-Architected Frameworkの柱「パフォーマンス効率」を読み解いてみた
・Well-Architected Frameworkの柱「セキュリティ」を読み解いてみた
・無料のAWS Well-Architected Toolでクラウド最適化への一歩を踏み出そう
書籍
菊池修治，加藤諒，城岸直希，甲木洋介，濱田孝治，藤井元貴，渡辺聖剛，臼田佳祐，江口佳記，千葉淳 著
「みんなのAWS 〜AWSの基本を最新アーキテクチャでまるごと理解！」 (2020) 技術評論社