Azure Well-Architected Framework入門

Azure Well-Architected Framework入門
.NETラボ 勉強会 2025年10月
https://dotnetlab.connpass.com/event/366516/

Transcript

1. Azure Well-Architected Framework入門 FutureOne株式会社 草場 友光 .NETラボ勉強会2025年10月
2. 自己紹介 • コミュニティ活動を通じて知識を アップデートしています。 • 2022/08-2026 Microsoft MVP (Developer Technologies) • tomo_kusaba • ドラクエ大好き ドラクエ10のプレイ時間→ 1キャラ目：2642時間 2キャラ目：914時間 3キャラ目：789時間 4キャラ目：190時間(配信用)
3. 注意 • 個人の見解・解釈が多分に入っています。 • 見解の相違・事実誤認などありましたらご指摘ください。
4. 今日の目的 • Azureのワークロードを設計するうえで重要なドキュメントの一 つがAzure Well-Architected Frameworkです。 • これを参照することで、信頼性・セキュリティ・コスト最適化・オペ レーショナルエクセレンス・パフォーマンス効率のそれぞれの目標 に最適化されます。 • これらはそれぞれトレードオフとビジネス要件による制約との間 で決定されるので実際のところどうなのかというところを探って いきたいと思います。
5. お断り • 今回のセッションはAzure Well-Architected Framework に基づいているものの、個人の経験・解釈が入っているところが 多分にあります。 • 原則論としてはドキュメントを参照して立ち返ってください。
6. Azure Well-Architected Frameworkとは？ • Azure Well-Architected Frameworkはワークロードの品 質を向上できる設計フレームワークです • 信頼性 • セキュリティ • コスト • オペレーショナルエクセレンス • パフォーマンス効率
7. フレームワークの要素 • フレームワークの柱それぞれに要素がある 要素 説明 設計原則 それぞれの目標をもつ優れた設計の基礎を提供します チェックリスト 主要な戦略と、Azureが推奨事項を達成するのにどのように役立つかについ て説明する推奨事項ガイドが含まれています。 設計パターン 関連するクラウド設計パターンが示されています。 トレードオフ それぞれのアーキテクチャーの決定には一連の考慮事項が伴います。また、ト レードオフもあります。 成熟度モデル 基本的な推奨事項から始めて、Azure Well-Architected Framework を採用するための段階的なアプローチについて説明します。
8. 評価レビューツール • https://learn.microsoft.com/ja- jp/assessments/azure-architecture-review/
9. プロジェクト計画作るときに考えること • どれだけの期間で • 時間的制約 • どんな体制で（誰が） • 技術的制約 • どれだけのお金を使って • コスト制約 • どんな成果物を作るのか？ • 機能要件 • 非機能要件 • 信頼性 • セキュリティ • 運用しやすさ • パフォーマンス
10. アプリケーションの特性評価 項目 内容 システム停止許容時間 そのシステムは一時的な障害から回復するのにどれだけの時間許容できるのか？ システム停止許容頻度 そのシステムは一時的な障害またはシステム障害の頻度はどれだけ許容できるのか？ システム復旧目標時間 システム障害からの回復に何らかの作業が必要な事柄に関してどれだけの時間を許容 できるのか？ データ復旧目標時間 データ破損が生じた場合（ランサムウェアやシステムの不良などの要因）データーリスト ラをしてシステム再開するのにどれだけの時間を許容できるのか？ 大規模災害の時の考慮 データセンターや社会インフラに深刻なダメージを与えるような自然災害・テロなどが 発生した場合でもそのシステムを必ず復旧する必要があるのか？ （一般に会社存続できなければそのアプリケーションを復旧する意味はないですよ ね？）
11. 信頼性とは？ • 意図した機能を常に提供し続ける • そのために許容できる期間内に障害を検出 • 許容できる期間内に障害を復旧する • その許容できる期間内とは？？ • システムの性格・重要度によって異なる • 障害が発生しないと考えるのは非現実的！
12. ビジネス要件における信頼性設計 • 選択した、サービスの制限・クォーターなどの制限事項を考慮 • 依存関係があるサービス・APIなどの影響を考慮 • システムの重要度に応じた稼働率・稼働とみなす要件の設定 • 障害発生時にどの程度の時間で復旧するか • データーリストアが必要な場合どの程度の時間で復旧するか
13. 信頼性の設計 • すべてのコンポーネントが同等に信頼性を持つ必要はない →一般に信頼性を担保しようとすると課金に影響します • 重要なコンポーネントにリソースを割り当てる • 設計パターンを正しく使用する →リトライ・サーキットブレーカー →イベントソーシング →レート制限 • 様々なアプリケーション層での冗長性と回復性を構築する
14. 代表的な設計パターン パターン 概要 イベントソーシング 状態変更を一連のイベントとして扱う。ビジネスプロセスで信頼性の高い変更履歴が重要な 場合に使用できる。 イベントソーシング＋CQRS(パフォーマンスのデザインパターン)のフレームワークとして Sekibanが有名です (https://github.com/J-Tech-Japan/Sekiban) サーキットブレーカー このパターンを使用して、ワークロードの正常な低下をトリガーすることもできます。 サー キット ブレーカーは、多くの場合、自己保存と自己復旧の両方を提供するために自動回復と 組み合わせています。 再試行 特定の操作を制御された方法で再試行することで、一時的または断続的な障害に対処しま す。 分散システムの一時的な障害を軽減することは、ワークロードの回復性を向上させる重 要な手法です。 レート制限 無制限の再試行オンエラー シナリオを回避するために、クライアント要求の速度を制御しま す。 この戦術では、サービスが指定された制限に達しないように設計されている場合に、 サービスとの通信の制限とコストを確認することで、クライアントを保護します。 正常性エンドポイント その目的のために特別に設計されたエンドポイントを公開することで、システムの正常性ま たは状態を監視する方法を提供します。
15. 再試行 • クラウドでは一時的な障害が予想できるため一定の遅延時間・一 定の回数呼び出すことが一般的です。 • 一定回数のエラーののちエラーとして扱う。
16. 再試行戦略 • アプリケーションがリモートサービスに要求を送信しようとして障害が検出さ れた場合次の方法を使用して障害を処理できます。 1. キャンセルする 障害が一時的でないか操作を繰り返しても成功する可能性が低い場合操 作をキャンセルして例外を報告する必要があります。 ４２９以外の４ｘｘの場合など 2. すぐに再試行 報告された障害が、ネットワークパケットの破損など異常またはまれなもの である場合は要求をすぐに再試行することが最善である場合があります。 3. 時間をおいて再試行する 障害の原因がよい一般的な接続またはビジー状態の障害いずれかである 場合は時間をおいて再試行することでうまくいく場合が多いです。 ５ｘｘのステータスコードの多くがこれに該当します。
17. サーキット ブレーカー パターン • 再試行パターンは一時的な障害から回復するのに有効な手段で す。 • しかしながら、インフラの状態によっては再試行することでリソー スを使い果たす可能性がありほかの関係のないところで失敗する 可能性があります。 • これを避けるために一時的に再試行を一時停止することをサー キットブレーカーパターンと呼びます。
18. コストと信頼性のトレードオフ • 実装の冗長性の増加 • 信頼性を確保するにはレプリカ数を増やす • 地理的な分散をする • ディザスターリカバリーソリューション
19. コスト最適化とは？ • アーキテクチャー設計は常にビジネス目標に基づくものであり ROIと財務上の制約に基づくものである。 • 一般的に、セキュリティ・スケーラビリティ・回復性・運用性などと はトレードオフが発生する。 • ビジネス要件の利点を正当化できない場合より安価なソリュー ションを選ぶという危険な選択をしてしまい、組織のビジネス目標 を達成できないまたはその評判に影響を与えてしまう結果になる。 • ※コスト最適化とは安いソリューションを選択することではない
20. コスト効率を考えた設計 • 投資に対する最高の収益を達成するために必要なものだけに費 やします。 • 最適なサイジング • 最適な機能レベル • 運用環境と非運用環境に求められる機能差
21. 使用レベルに合わせた設計 • リソースの使用を最大化します。 • 不要な機能を含むSKUを選択することを避けます • 動的にスケールさせる
22. レート最適化の設計 • 機能要件または非機能要件を犠牲にすることなく効率を向上させ る • ハイブリッド特典 • 非運用環境において低コストのSKUを検討 • コスト効率が高い場合は従量課金ベースも検討
23. 主なデザインパターン パターン コンピューティングリソース統合 密度を高めることでコンピューティング リソースを最適化および統合します。 このパ ターンは、共有インフラストラクチャ上でワークロードの複数のアプリケーションまたは コンポーネントを組み合わせます。 そうすることで、プールされたインフラストラクチャ 上のコンポーネントまたはワークロード全体を集約して、使用されていないプロビジョ ニングされた容量を回避し、コンピューティング リソースの利用率を最大限に高めます。 App Service PlanにApp Serviceを複数集約するなど。 静的コンテンツホスティング その目的のために設計されたホスティング プラットフォームを使用して、ワークロード クライアントへの静的コンテンツの配信を最適化します。 動的アプリケーション ホストは、 通常、コード化されたビジネス ロジックを実行できるため、静的ホストよりもコストが高 くなります。 静的コンテンツの配信にアプリケーション プラットフォームを使用すること は、コスト効率が良くありません。 Static Web Appsなど
24. コンピューティングリソース統合 • 複数のアプリケーションを1つのコンピューティングリソースに統 合します。 • たとえば、1つのApp Service Planに複数のApp Serviceを ホストします。 • スケーラビリティやセキュリティなどの問題が考慮事項として存在 します。
25. 静的コンテンツホスティング • 静的コンテンツのみを配信する目的であれば高額なコンピュー ティングインスタンスをもつリソースを使う必要がありません。 • Static Web Appsなどを使用することが最適なソリューション です。
26. コスト最適化と信頼性のトレードオフ • システムが停止することでの損失するコストと頻度と信頼性設計 のためのコストを比較します。 • サービス中断することでの損失コストが上回る場合はさらに信頼 性設計のために投資する必要があります。 • 一般に冗長性とコストはトレードオフの関係にあります。
27. コスト最適化とパフォーマンス効率のト レードオフ • コスト最適化とパフォーマンス効率は両方ともワークロードの最大 化に優先順位を付けます。 • ただし、コスト制限をするとパフォーマンス不足になります。 • また、コストを優先するためにスケーリングを制限したり遅延した りすると需要を満たすのに十分なリソースが得られないことがあ ります。
28. まとめ • Azure Well-Architected Frameworkではワークロードを より高品質にするための設計原則を提供します。 • しかしながら、ビジネス的な制約、それぞれのトレードオフをみな がらそれぞれのビジネス目標にあった選択をすることが重要に なってきます。
29. 宣伝 おしまい
30. Microsoft MVPとMicrosoft Ignite の日に徹夜するバー(11/18)
31. .NETラボ11月 (11/22)
32. Microsoft MVPを語るバー(11/23)
33. おしまい おしまい