こんにちは。
今回は、Microsoft Azure Well-Architected Framework の 5 つの柱の概要をまとめてみました。
ちゃんとした整理資料作ればいいとは思うのですが、ちょっと時間がないなーって中で、5 つの柱についてもうちょっとどんなことしてるかを 1 ページで見たいなって思ったので、まとめてみたって感じです。
っていうか、ドキュメントのコピペですが何かw
ちなみに、WAF の概要的なのを知りたい方は、前にそんなのを書いてみたのでこちらもご覧下さい。
Microsoft Azure Well-Architected Framework について整理してみたメモ
こんにちは。今回は、「Microsoft Azure Well-Architected Framework」について。WAF って略したりしますけど、WAF って Web Application Firewall の方が先に頭に浮かんじゃう...
5 つの柱は、こちらですね。
重要な要素 | 説明 |
---|---|
信頼性 | 障害から回復して動作を続行するシステムの能力です。 |
Security | 脅威からアプリケーションとデータを保護することです。 |
コストの最適化 | もたらされる価値を最大化するためのコスト管理 |
オペレーショナル エクセレンス | 運用環境でシステムを継続的に動作させる運用プロセスです。 |
パフォーマンス効率 | 負荷の変化に対応するためのシステムの能力。 |
信頼性
トピック
信頼性に関するトピック | 説明 |
---|---|
信頼性についての原則 | これらの重要な原則は、Azure にデプロイされたアプリケーションの信頼性を評価するためにレンズとして使用されます。 |
信頼性を高めるための設計 | システムで Availability Zones を使用する方法、スケーラビリティを実現する方法、障害に対処する方法、およびアプリケーション設計における信頼性を最適化するその他の方法について検討してください。 |
特定の Azure サービスの回復性のチェックリスト | 各テクノロジには独自の障害モードがあり、アプリケーションの設計および実装の際に考慮する必要があります。 このチェックリストを使用して、個々の Azure サービスの回復性の考慮事項を確認します。 |
ターゲットと機能以外の要件 | 可用性目標や回復目標などの目標と機能以外の要件を使用すると、ワークロードのアップタイムとダウンタイムを測定できます。 明確に定義された目標を設定することは、作業や測定の対象となる目標を持つために非常に重要です。 |
回復性と依存関係 | 障害のリスクを回避するために、システムに障害復旧の機能を備えさせるには、初めからアーキテクチャと設計フェーズの一部に組み込む必要があります。 アプリケーションを完全に動作させるには、依存関係が欠かせません。 |
可用性ゾーン | Availability Zones を使用すると、ソリューションをリージョン内の複数のゾーンに分散させることができるので、1 つのゾーンで障害が発生しても、アプリケーションは機能し続けることができます。 |
サービスの可用性 | Azure リージョンをまたぐサービスの可用性は、リージョンの種類によって異なります。 特定リージョンでのサービスのデプロイに関する Azure の一般的なポリシーは、主にリージョンの種類、サービス カテゴリ、および顧客の要望によって決まります。 |
可用性ゾーンの用語 | 主な用語や概念を理解することは、Azure のリージョンと可用性ゾーンについて理解を深める上で役立ちます。 |
ベスト プラクティス | アーキテクチャ フェーズ中には、ビジネス要件を満たし、障害点を特定し、障害の範囲を最小限に抑えるプラクティスを実装することに専念します。 |
信頼性のテスト | 既存のしきい値、ターゲット、想定を検証するために、通常のテストを主要な変更の一部として実行する必要があります。 |
信頼性の監視 | アプリケーションの正常性の全体像を把握します。 何かが失敗した場合、失敗したこと、失敗したとき、失敗した理由を知る必要があります。 |
信頼性パターン | 可用性を最大限に高めるために、アプリケーションを設計および実装する必要があります。 |
信頼性パターン
可用性
Pattern | まとめ |
---|---|
デプロイ スタンプ | データ ストアなど、アプリケーション コンポーネントの複数の独立したコピーをデプロイします。 |
Geode | バックエンド サービスを一連の地理的ノードにデプロイします。各ノードが、任意のリージョンで任意のクライアント要求を処理できます。 |
正常性エンドポイント監視 | 公開されたエンドポイントを通じて外部ツールが定期的にアクセスできる機能チェックをアプリケーションに実装します。 |
キュー ベースの負荷平準化 | タスクとそのタスクが呼び出すサービスとの間でバッファーとして機能するキューを使用して、断続的な大きい負荷を平準化します。 |
調整 | アプリケーションのインスタンス、個々のテナント、またはサービス全体によってリソースの使用量を制御します。 |
高可用性
Pattern | まとめ |
---|---|
デプロイ スタンプ | データ ストアなど、アプリケーション コンポーネントの複数の独立したコピーをデプロイします。 |
Geode | バックエンド サービスを一連の地理的ノードにデプロイします。各ノードが、任意のリージョンで任意のクライアント要求を処理できます。 |
正常性エンドポイント監視 | 公開されたエンドポイントを通じて外部ツールが定期的にアクセスできる機能チェックをアプリケーションに実装します。 |
Bulkhead | アプリケーションの要素をプールに分離し、1 つの要素が失敗しても、他の要素が引き続き機能できるようにします。 |
Circuit Breaker | リモート サービスまたはリソースとの接続時の修正に要する時間が一定しないエラーを処理します。 |
回復性
Pattern | まとめ |
---|---|
Bulkhead | アプリケーションの要素をプールに分離し、1 つの要素が失敗しても、他の要素が引き続き機能できるようにします。 |
Circuit Breaker | リモート サービスまたはリソースとの接続時の修正に要する時間が一定しないエラーを処理します。 |
補正トランザクション | 最終的に整合性がある操作を定義する一連のステップで実行された作業を元に戻します。 |
正常性エンドポイント監視 | 公開されたエンドポイントを通じて外部ツールが定期的にアクセスできる機能チェックをアプリケーションに実装します。 |
リーダー選定 | 1 つのインスタンスを、他のインスタンスの管理を担当するリーダーとして選定することで、分散アプリケーション内で連携するタスク インスタンスのコレクションによって実行されるアクションを調整します。 |
キュー ベースの負荷平準化 | タスクとそのタスクが呼び出すサービスとの間でバッファーとして機能するキューを使用して、断続的な大きい負荷を平準化します。 |
Retry | 予測される一時的な障害をアプリケーションが処理できるようにします。アプリケーションがサービスまたはネットワーク リソースに接続しようとする際に、失敗した操作を透過的に再試行します。 |
Scheduler エージェント スーパーバイザー | 分散された一連のサービスやその他のリモート リソースにわたる一連のアクションを調整します。 |
セキュリティ
トピック
セキュリティに関するトピック | 説明 |
---|---|
セキュリティ設計原則 | これらの原則では、クラウドまたはオンプレミスのデータセンターでホストされる安全に設計されたシステム、またはその両方の組み合わせについて説明します。 |
ガバナンス、リスク、およびコンプライアンス | 組織のセキュリティはどのように監視、監査、報告される予定ですか。 個人を特定できる情報、知的財産 (IP)、財務情報を保護しようとしているときに、組織はどのような種類のリスクに直面するのでしょうか。 組織のセキュリティコントロールが満たす必要がある基準に関する推奨事項を決定または提供する特定の業界、政府、または規制要件はありますか? |
規制コンプライアンス | 政府やその他の組織は、セキュリティに関する怠慢を避けるために、適切なセキュリティ プラクティス (デュー デリジェンス) を定義するのに役立つ標準を頻繁に発行します。 |
管理 | 管理とは、ビジネスに必要なサービス レベルを満たすために、情報技術 (IT) システムの監視、保守、運用を実践することです。 これらのタスクを実行するには、これらのシステムとアプリケーションの広範なセットへの特権アクセスが必要であるため、管理によって最も影響が大きいセキュリティ リスクがいくつか導入されます。 |
アプリケーションとサービス | アプリケーションとそれらに関連付けられたデータは、クラウド プラットフォーム上で、最終的にはビジネス価値の主要なストアとして機能します。 |
ID 管理とアクセス管理 | ID がセキュリティ保証の大部分の基礎を提供します。 |
情報の保護とストレージ | 保存データの保護は、すべてのワークロードで機密性、整合性、および可用性の保証を維持するために必要です。 |
ネットワーク セキュリティと封じ込め | ネットワーク セキュリティは、企業のセキュリティ対策の伝統的な中心でした。 しかし、クラウド コンピューティングにより、ネットワークの境界の抜け道を多くする必要性が高まり、多くの攻撃者は ID システム要素に対する (ほとんど常にネットワーク制御を回避する) 攻撃技術を習得しています。 |
セキュリティ運用 | セキュリティ運用では、ライブの敵対者がシステムを攻撃したときにシステムのセキュリティ保証の維持と復旧を行います。 セキュリティ運用のタスクは、NIST Cybersecurity Framework の Detect、Respond、Recover の各機能によって適切に記述されます。 |
コストの最適化
トピック
コストのトピック | 説明 |
---|---|
コスト要件を捕捉する | 要件を慎重に列挙することで計画を開始します。 利害関係者のニーズに確実に対応してください。 ビジネス目標との整合性を高めるために、これらの領域は利害関係者が定義する必要があり、ベンダーから収集しないでください。 |
Azure リージョンのリソースのコスト | Azure サービスのコストは、需要とローカル インフラストラクチャのコストに基づいて、地域間で異なる可能性があります。 |
ガバナンス | ガバナンスをコスト管理に役立てる方法を理解します。 この作業は、継続的なコストの見直しプロセスに役立ち、新しいリソースにある程度の保護を提供します。 |
初期コストを見積もる | ワークロードをクラウドにデプロイする前にコストを把握することは困難です。 オンプレミスの見積もり用の方法を使用したり、オンプレミスの資産をクラウド リソースに直接マップしたりすると、見積もりは不正確になります。 |
PaaS | アーキテクチャの中で、サービスとしてのプラットフォーム (PaaS) オプションを採用するのが妥当である領域を探します。 これらのオプションには、キャッシュ、キュー、データ ストレージが含まれます。 PaaS により、サーバー、ストレージ、ネットワーク、およびその他のアプリケーション インフラストラクチャの管理にかかる時間とコストが削減されます。 |
従量課金プラン | コストを見積もる際は、一般的に、ピーク時のスループットのワークロードを考慮します。 使用率が一貫して高い場合、使用量ベースの価格体系でのベースライン コストは、同等のプロビジョニング価格体系の場合ほど手際よく見積もることができません。 |
クラウド リソースをプロビジョニングする | ワークロードのクラウド リソースをデプロイすると、コストを最適化できます。 |
コストを監視する | Azure Cost Management には警告機能があります。 使用量がしきい値に達した時にアラートが生成されます。 |
コストを最適化する | 適切なリソースとサイズを使用することで、ワークロードの監視と最適化を行います。 |
コストのトレードオフ | ワークロードを設計する際には、コストの最適化と、セキュリティ、スケーラビリティ、回復力、運用性など、設計のその他の側面とのトレードオフを考慮します。 |
オペレーショナル エクセレンス
トピック
オペレーショナル エクセレンスのトピック | 説明 |
---|---|
アプリケーションの設計 | DevOps の原則を考慮して、ワークロードを設計、構築、および調整する方法についてのガイダンスを提供します。 |
監視 | 監視と診断は、あらゆるワークロードにとって不可欠です。 特にリモート データセンターで実行されるクラウド アプリケーションでは、多くの場合、この規範がさらに重要になります。 |
アプリケーション パフォーマンス管理 | DevOps を通じたソフトウェア アプリケーションのパフォーマンスと可用性の監視と管理。 |
コードのデプロイ | アプリケーション コードをどのようにデプロイするかは、アプリケーションの安定性を決定する重要な要因の 1 つです。 |
インフラのプロビジョニング | この規範は、 デプロイオートメーション または インフラストラクチャをコードとしてよく知られており、アプリケーションが実行されるプラットフォームをデプロイするためのベスト プラクティスを指します。 |
テスト | テストは、予期せぬ事態に備え、ユーザーに影響を及ぼす前にミスを見つけるための基本です。 |
オペレーショナル エクセレンス パターン
Pattern | まとめ |
---|---|
Ambassador | コンシューマー サービスまたはアプリケーションの代わりにネットワーク要求を送信するヘルパー サービスを作成します。 |
破損対策レイヤー | 最新アプリケーションとレガシ システムの間にファサード、すなわちアダプター レイヤーを実装します。 |
外部構成ストア | アプリケーション展開パッケージから、一元管理される場所に構成情報を移動します。 |
ゲートウェイ集約 | ゲートウェイを使用して、複数の個々の要求を 1 つの要求に集約します。 |
ゲートウェイ オフロード | 共有または専用のサービス機能の負荷をゲートウェイ プロキシにオフロードします。 |
ゲートウェイ ルーティング | 単一のエンドポイントを使用して複数のサービスに要求をルーティングします。 |
正常性エンドポイント監視 | 公開されたエンドポイントを通じて外部ツールが定期的にアクセスできる機能チェックをアプリケーションに実装します。 |
Sidecar | アプリケーションのコンポーネントを別のプロセスまたはコンテナーにデプロイして、分離性とカプセル化を実現します。 |
ストラングラー | 機能の特定の部分を新しいアプリケーションやサービスに徐々に置き換えることで、レガシ システムを段階的に移行します。 |
パフォーマンス
トピック
パフォーマンス効率に関するトピック | 説明 |
---|---|
パフォーマンス効率のチェックリスト | アプリケーション アーキテクチャを確認して、ワークロードがスケーリングされ、ユーザーが設定した要求を効率的な方法で満たしていることを確認します。 |
パフォーマンスの原則 | パフォーマンス効率を向上させるための全体的な戦略をガイドするための原則。 |
パフォーマンスのための設計 | パフォーマンス設計の観点からアプリケーション アーキテクチャを見直します。 |
スケーラビリティを検討する | 現在のワークロードを理解することで、成長を計画します。 |
容量計画 | 需要に合わせてインフラストラクチャを追加することにより、アプリケーション層のスケーリングを計画します。 |
パフォーマンス監視チェックリスト | サービスを監視し、現在のワークロードの正常性状態を確認して、ワークロード全体のパフォーマンスを維持します。 |
パフォーマンス パターン | 設計パターンを実装して、よりパフォーマンスの高いワークロードを構築します。 |
トレードオフ | パフォーマンスの最適化と、信頼性、セキュリティ、コスト効率、運用性など、設計のその他の側面とのトレードオフを考慮します。 |
パフォーマンス効率パターン
Pattern | まとめ |
---|---|
キャッシュ アサイド | オンデマンドでデータをデータ ストアからキャッシュに読み込みます。 |
コレオグラフィ | 中央の制御ポイントに依存するのではなく、システムの各コンポーネントが、ビジネス トランザクションのワークフローに関する意思決定プロセスに参加するようにします。 |
CQRS | 個別のインターフェイスを使用して、データを更新する操作とデータを読み取る操作を分離します。 |
イベント ソーシング | 追加専用のストアを使用して、ドメイン内のデータに実行されるアクションを記述する一連のすべてのイベントを記録します。 |
デプロイ スタンプ | データ ストアなど、アプリケーション コンポーネントの複数の独立したコピーをデプロイします。 |
Geode | バックエンド サービスを一連の地理的ノードにデプロイします。各ノードが、任意のリージョンで任意のクライアント要求を処理できます。 |
テーブルのインデックス作成 | クエリによって頻繁に参照されるデータ ストア内のフィールドにインデックスを作成します。 |
具体化されたビュー | データの形式が必要なクエリ操作に適していない場合に、1 つ以上のデータ ストアのデータの事前設定されたビューを生成します。 |
優先順位キュー | サービスに送信される要求に優先順位を設定し、優先順位の高い要求から順番に受信および処理されるようにします。 |
キュー ベースの負荷平準化 | タスクとそのタスクが呼び出すサービスとの間でバッファーとして機能するキューを使用して、断続的な大きい負荷を平準化します。 |
シャーディング | データ ストアを水平方向のパーティションまたはシャードのセットに分割します。 |
静的コンテンツ ホスティング | 静的コンテンツを、クライアントに直接配信できるクラウド ベースのストレージ サービスにデプロイします。 |
調整 | アプリケーションのインスタンス、個々のテナント、またはサービス全体によって使用されるリソースの使用量を制御します。 |
コメント