MS_AzureWellArchitectedFramework

Azure Well-Architected Framework

• 戻る（アーキテクチャ設計）
  • アプリケーション・アーキテクチャ
  • Azure Well-Architected Framework
  • クラウド アプリケーション アーキテクチャ ガイド
  • 参照アーキテクチャ

概要

• W-AF と略される。
• ワークロードの品質向上に使用できる一連の基本原則

補足（位置付け）: W-AF は「Azure の使い方」ではなく、
設計判断の良し悪しを評価するための観点の集合である。
具体的な構成例が欲しい場合は参照アーキテクチャを、
アーキテクチャ スタイルの選択については
クラウド アプリケーション アーキテクチャ ガイドを参照する。

なお、同種のものは各クラウド ベンダが持っている
（AWS Well-Architected Framework、
Google Cloud Architecture Framework）。
5 本の柱という構成はほぼ共通であり、
クラウド固有というより設計レビューの共通言語として使える。

詳細

コストの最適化

もたらされる価値を最大化するためのコスト管理

補足: オンプレミスと決定的に違うのは、
コストが設計の結果として毎月変動する点である。
「余裕を持たせておく」がそのまま課金になるため、
従来は美徳だった過剰な余裕確保が、ここでは減点になる。

主な打ち手は次のとおり。

手段	内容
適切なサイズ設定	実測に基づく SKU 選択（パフォーマンス カウンタ）
自動スケール	需要に追随させ、待機分を持たない
予約インスタンス／Savings Plans	定常分を長期契約で割引
Azure Hybrid Benefit	保有する Windows Server / SQL Server ライセンスの持ち込み
サーバーレス	実行時間課金にして待機コストを消す
ライフサイクル管理	ストレージのアクセス層自動移行

オペレーショナル エクセレンス

運用環境でシステムを継続的に動作させる運用プロセス

補足: 要点は手作業を無くすことである。

• IaC（Bicep / ARM テンプレート / Terraform）による構成管理
• CI/CD による繰り返し可能なデプロイ
  （クラウドのインフラ自動化、
  Jenkins、GitLab）
• 監視・可観測性（Azure Monitor / Application Insights）
• 障害を前提とした演習と手順の整備
  （Azureの障害復旧）

パフォーマンス効率

負荷の変化に対応する（システムの能力）

移行メモ（体裁）: 原典は「負荷の変化に対応する（システムの能力」のように
閉じ括弧が欠落していたため補った（「信頼性」も同様）。

補足: クラウドでの性能設計は
**「速いサーバを買う」から「必要な時に必要なだけ並べる」**への転換である。

観点	内容
スケールアウト優先	スケールアップは上限が早く来る。ステートレス化が前提になる
自動スケール	指標（CPU・キュー長）に基づく増減
キャッシュ	Azure Cache for Redis、CDN
非同期化	キューによる負荷平準化
データ層の設計	多くの場合ここが上限を決める（SQL Server の Elastic Scale とプール、SQL Server のパーティション）

なお、性能は測らなければ評価できない。
設計段階の見積りは仮説にすぎないため、
負荷テストで検証する
（JmeterによるWebアプリの負荷テスト、
性能問題のポイント）。

信頼性

障害から回復して動作を続行する（システムの能力）

補足（クラウドでは「壊れる前提」で設計する）: オンプレミスでは
ハードウェアを冗長化して壊れないようにする発想が主だったが、
クラウドでは個々のインスタンスは壊れるものとして扱う。

手段	内容
可用性ゾーン／セット	障害ドメインを分けて配置
複数リージョン	リージョン障害への備え（Azureの障害復旧）
正常性プローブ	異常なインスタンスを自動で切り離す
再試行とサーキット ブレーカー	一過性障害（transient fault）を前提にした実装
バックアップと復旧演習	復旧できることを実際に確認する

クラウド特有の注意として、一過性の失敗が普通に起きる。
従来「起きたら異常」だった接続エラーやタイムアウトが、
正常な運用の一部として発生するため、
アプリ側に再試行を実装しておく必要がある。

また、RTO / RPO を先に決めること。
これを決めずに構成だけ冗長化しても、
どこまで守れているのかを説明できない
（SQL Server の障害復旧）。

Security

脅威からアプリケーションとデータを保護

補足: 現在はゼロ トラスト（明示的に検証する、
最小特権を与える、侵害を前提とする）が指針となっている。
実装面では

• マネージド ID による資格情報の排除
  （Azure Key Vault）
• ネットワーク分離（Private Link、NSG）
  （ネットワークの脆弱性対策）
• 保存時・転送時の暗号化
• アプリ層の対策
  （Webアプリの脆弱性対策）

が中心になる。

補足（最新化：6 本目の柱ではなく「5 本の柱」のまま）: 2023 年の改訂で
Well-Architected Framework は再編され、
各柱に設計原則・チェックリスト・トレードオフが
明示される構成になった。柱の数と名称は 5 本のままである。

重要なのは、5 つの柱は同時には最大化できないという点である。

トレードオフの例	内容
信頼性 ⇔ コスト	多重化・複数リージョンは費用に直結する
セキュリティ ⇔ 性能	検査・暗号化・分離は遅延を増やす
性能 ⇔ コスト	余裕を持った SKU は待機コストになる
運用 ⇔ 初期コスト	自動化は初期投資が要る

W-AF の実務上の価値は「全部満たす」ことではなく、
どれを優先し、何を諦めたかを説明可能にすることにある。

参考

https://docs.microsoft.com/ja-jp/azure/architecture/framework/

---

Tags: 移行, アーキテクチャ, クラウド系開発