Well Architected Frameworkとは
AWSの提案する「システム設計・運用の”大局的な”考え方とベストプラクティス集」がWell Arcitected Frameworkです。構成はいわゆる「５つの柱(運用・セキュリティ・信頼性・パフォーマンス・コスト)」からなり、それぞれの柱のなかにベストプラクティスやAWSを利用した際の実装パターンなどがまとめられています。
クラウドを用いたシステム設計を行う人は一度は目を通した方が良い内容になっています。
本記事の目的
Well Architected Frameworkの目指すところは組織の体制と制度も含めてアーキテクチャと捉えて組織レベルでの実践を求めています。そのレベルの実現をいきなり目指すことは簡単ではないため、本記事ではあくまでもクラウドを用いたシステム設計者に向けてWell Architected Frameworkの概要を理解しアーキテクチャ構築に対して一定の指針を持てるようになるところを目的としています。
Well Architected Frameworkの概要を理解しているだけでも、現在自分が構築もしくは運用しているアーキテクチャのリスクを可視化し、見直しを行うことでアーキテクチャを改善させることができるようになると思います。
Well Architected Frameworkの捉え方
まず抑えるべきなのは、Well Architected Frameworkは理想論です。
現実的なアーキテクチャは現実的な制約から取捨選択を行うことが一般的です。特にスタートアップではPMFを目的にスピーディに開発するために信頼性やパフォーマンスを犠牲にすることがあると思います。信頼性が求められる金融系のサービスでは過剰なコストをかけてセキュリティを重視した設計をすることもあるでしょう。
何かしらのリスクを引き受けた上で得たい恩恵や差別化を実現しています。
Well Architected Frameworkは取捨選択を行うというよりも、全ての要件を可能な限り満たすような内容になっています。つまり最終的な理想や向かうべきゴールだと捉えるべきで、その構築には時間・コスト・人員が多量に必要です。
なので間違っても、Well Architected Frameworkにこう書いてあるから絶対こうすべき、という風には捉えない方が良いかと思います。プロダクトの成長とともにこの理想に向かっていくのだという風に軽く捉えておくのが良いと思います。
総論(最悪ここだけ読めばOK)
Well Architected Frameworkの一般原則および５つの柱を一行でまとめました。
一般原則
クラウドの特性を利用して進化するアーキテクチャを実現させること
運用上の優秀性
障害発生時の早急な復旧できる運用チームを作る
セキュリティ
アーキテクチャでセキュリティ対応をすることで人的ミスによるインシデントを起こさない
信頼性
アーキテクチャで耐障害性を向上させつつ、障害時には人の介在を極力なくして早急な復旧を実現する
パフォーマンス効率
システムの最新化と継続的改善にフォーカスする
コスト最適化
コストに対する効果を把握し、不要なコストを極力なくす
各項目の概要
一般原則
① 必要キャパシティーの推測をしない
高価な余剰リソースを準備しない & キャパシティーの制約によるパフォーマンスへの影響を最小化
自動的にスケールアップまたはスケールダウン
② 本稼働スケールでシステムをテストする
本稼働スケールのテスト環境を作成
テスト完了後にリソースを解放
③ ⾃動化によってアーキテクチャでの実験を容易にする
手動オペレーションの支出を回避
⾃動化に対する変更を追跡し、影響を監査して、必要な場合は以前のパラメータに戻す
④ 発展するアーキテクチャが可能に
イノベーションを標準プラクティスとしてビジネスで活用
システムを時間とともに進化させる
⑤ ゲームデーを利用して改善する
ゲームデーを定期的にスケジュールする
本稼働環境のイベントをシミュレートすることで、アーキテクチャとプロセスのパフォーマンスをテストする。
改善できる箇所を把握し、組織がイベントに対応することを経験する。
運用の優秀性
① 運用をコードとして実行する
IaCでアプリケーションと環境を更新する
運用手順もコード化し、イベントに対応してそのコードを実行することで自動化する
② 小規模かつ可逆的な変更を頻繁に行う
コンポーネントを定期的に更新できるようにする
失敗した場合にすぐに元に戻せるように小規模に行う
③ 運用手順を定期的に改善する
定期的なゲームデーを開催し、運用手順の改善を行う
ワークロードを改良するときに運用手順を変更する
④ 障害を予測する
プレモータル演習を実施して障害シナリオをテストする。
定期的なゲームデーを計画し、シミュレートされたイベントに対するチームの応答をテストする
⑤ 運用上の全ての障害から学ぶ
運用上の全ての障害やイベントから教訓を学び、組織で共有する
セキュリティ
① 強力なアイデンティティ基盤の実装
最小権限の原則
役割分担を徹底させ、各AWSリソースとの通信において適切な認証を実装
アイデンティティ管理を一元化し、長期にわたる静的な認証情報に依存しないようにする
② 全レイヤーでセキュリティを適用する
複数のセキュリティコントロールを使用して深層防御アプローチを適用
全てのレイヤーで防御する
③ データに人の手を入れない
なるべくデータに直接アクセスしたりデータを手動で処理しないことで、機密性の高いデータを扱う際の誤処理、変更、ヒューマンエラーのリスクを軽減させる
④ セキュリティのベストプラクティスを自動化する
自動化されたソフトウェアベースのセキュリティメカニズムを採用
コードとして定義および管理されるコントロールを実装
⑤ セキュリティイベントに備える
組織の要件に合わせたインシデント管理および調査のポリシーとプロセスを導入
インシデント対応シミュレーションを実行し、自動化されたツールを使用して、検出、調査、復旧のスピードを上げる
信頼性
① 障害から自動的に復旧する
ワークロードでビジネス価値に関する主要業績評価指標 (KPI) をモニタリングする
事象が発生した時に自動復旧する
② 復旧手順をテストする
どのようにシステム障害が発生するかをテストして、復旧の手順も検証する
さまざまな障害のシミュレーションや過去の障害シナリオの再現を行う
③ 水平方向にスケールしてワークロード全体の可用性を高める
1つの大規模なリソースを複数の小規模なリソースに置き換える
リクエストを複数の小規模なリソースに分散させることで、共通の障害点を共有しない
④ キャパシティーを推測することをやめる
需要とワークロード使用率をモニタリングし、リソースの追加と削除を自動化する
プロビジョニングが過剰にも過小にもならない、需要を満たせる最適なレベルを維持する
⑤ オートメーションで変更を管理する
インフラストラクチャに対する変更は、オートメーションを使用して実行する
パフォーマンス効率
① 最新テクノロジーの標準化
マネージドサービスを利用することでより簡単に高度なテクノロジーを実装できる
テクノロジーをサービスとして消費することを検討する
チームはリソースのプロビジョニングと管理ではなく、製品の開発に集中する
② サーバーレスアーキテクチャを使用する
物理的なサーバーを実行して維持する必要性を取り除く
③ より頻繁に実験する
異なるタイプのインスタンス、ストレージ、設定を使用した比較テストを実施する
④ システムに対する精通の程度を考慮する
クラウドサービスの使用方法を理解し、常にワークロードの目標に最適なテクノロジーアプローチを使用する
⑤ グローバル展開する
世界各地のAWSリージョンでデプロイをすることで、より低いレイテンシーとより良いエクスペリエンスを実現
コストの最適化
① クラウド財務管理の実装
財務面の成功を達成するには、クラウド財務管理/コスト最適化に投資する必要がある
② 消費モデルを導入
必要な分、必要なだけ消費する
例えば開発環境・テスト環境を利用するのは平日の8時間のみであるため、それ以外の時間帯のリソースを停止することでコストを 75% 削減できる可能性がある
③ 全体的な効率を測定する
ビジネス成果とその実現にかかったコストを測定する。この測定値を元に生産性向上やコスト削減の効果を把握する。
④ 差別化につながらない高負荷作業に費用をかけるのをやめる
マネージドサービスを使うことでOSやアプリケーション管理のオペレーション管理の負担が解消される
もしマネージドサービス使わないのであればそれは何かしらの差別化に繋がる理由がなければならない。
⑤ 費用を分析および属性化する
システムの使用状況とコストを正確に把握し、IT コストと各ワークロードの所有者との帰属関係を明確にする
これによってROIの最適化につながる分析ができる
タグベースのコスト配分
まとめ
Well Architected Frameworkはアーキテクチャの理想なので、現実とすり合わせて現状を理解するために利用しましょう。
今回は５つの柱の設計原理について概要だけをさらっと読んでいきました。
より詳しい内容や実際にどうやって実装していくのかは公式ドキュメントをご参照ください。
https://wa.aws.amazon.com/index.ja.html