Azure Well-Architected Framework入門

Azure Well-Architected Framework入門]
Japan Azure User Group 15周年イベント
https://jazug.connpass.com/event/364233/

Transcript

1. Azure Well-Architected Framework入門 FutureOne株式会社 草場 友光 Japan Azure User Group 15周年イベント
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. ビジネス要件における信頼性設計 • 選択した、サービスの制限・クォーターなどの制限事項を考慮 • 依存関係があるサービス・APIなどの影響を考慮 • システムの重要度に応じた稼働率・稼働とみなす要件の設定 • 障害発生時にどの程度の時間で復旧するか • データーリストアが必要な場合どの程度の時間で復旧するか
11. 信頼性の設計 • すべてのコンポーネントが同等に信頼性を持つ必要はない →一般に信頼性を担保しようとすると課金に影響します • 重要なコンポーネントにリソースを割り当てる • 設計パターンを正しく使用する →リトライ・サーキットブレーカー →イベントソーシング →レート制限 • 様々なアプリケーション層での冗長性と回復性を構築する
12. 代表的な設計パターン パターン 概要 イベントソーシング 状態変更を一連のイベントとして扱う。ビジネスプロセスで信頼性の高い変更履歴が重要な 場合に使用できる。 イベントソーシング＋CQRS(パフォーマンスのデザインパターン)のフレームワークとして Sekibanが有名です (https://github.com/J-Tech-Japan/Sekiban) サーキットブレーカー このパターンを使用して、ワークロードの正常な低下をトリガーすることもできます。 サー キット ブレーカーは、多くの場合、自己保存と自己復旧の両方を提供するために自動回復と 組み合わせています。 再試行 特定の操作を制御された方法で再試行することで、一時的または断続的な障害に対処しま す。 分散システムの一時的な障害を軽減することは、ワークロードの回復性を向上させる重 要な手法です。 レート制限 無制限の再試行オンエラー シナリオを回避するために、クライアント要求の速度を制御しま す。 この戦術では、サービスが指定された制限に達しないように設計されている場合に、 サービスとの通信の制限とコストを確認することで、クライアントを保護します。 正常性エンドポイント その目的のために特別に設計されたエンドポイントを公開することで、システムの正常性ま たは状態を監視する方法を提供します。
13. イベントソーシング（コンテキストと問題） • 通常、アプリケーションがデータを更新しようとするときデータを ロックするトランザクションを使用してデータを読み取り変更を加 え新しい値で状態を更新するのが一般的なプロセス • 負荷の高いシステムではリソースの競合とロックによってパフォー マンスが低下する • データの最新の状態のみが格納される。各操作の詳細を個別にロ グ記録する監査メカニズム（REDOログのような）がない限り履歴 は失われます。
14. イベントソーシング（解決策）
15. 再試行 • クラウドでは一時的な障害が予想できるため一定の遅延時間・一 定の回数呼び出すことが一般的です。 • 一定回数のエラーののちエラーとして扱う。
16. 再試行戦略 • アプリケーションがリモートサービスに要求を送信しようとして障害が検出さ れた場合次の方法を使用して障害を処理できます。 1. キャンセルする 障害が一時的でないか操作を繰り返しても成功する可能性が低い場合操 作をキャンセルして例外を報告する必要があります。 ４２３以外の４ｘｘの場合など 2. すぐに再試行 報告された障害が、ネットワークパケットの破損など異常またはまれなもの である場合は要求をすぐに再試行することが最善である場合があります。 3. 時間をおいて再試行する 障害の原因がよい一般的な接続またはビジー状態の障害いずれかである 場合は時間をおいて再試行することでうまくいく場合が多いです。 ５ｘｘのステータスコードの多くがこれに該当します。
17. Container Appsの再試行戦略(Preview) • Container Appsから行われた要求ではなくそのContainer Appsに対して行われた要求に対してルールが適用される
18. サーキット ブレーカー パターン • 再試行パターンは一時的な障害から回復するのに有効な手段で す。 • しかしながら、インフラの状態によっては再試行することでリソー スを使い果たす可能性がありほかの関係のないところで失敗する 可能性があります。 • これを避けるために一時的に再試行を一時停止することをサー キットブレーカーパターンと呼びます。
19. 正常性エンドポイント • Webアプリケーションが正しく動作しているのか監視するために 監視用のエンドポイントを設置する • 監視用のエンドポイントにアクセスすることでアプリケーション側 はデータベース・ストレージなどの構成要素が正しく動作している ことのチェックをしてその状態を返す。 https://learn.microsoft.com/ja-jp/azure/architecture/patterns/health-endpoint-monitoring
20. セキュリティと信頼性のトレードオフ • ワークロードの攻撃可能領域の増加 • 信頼性確保のために地理的な分散 • リカバリーソリューションのために攻撃可能ポイントが増加 • 信頼性確保のために追加のコンポーネントが必要になり攻撃可能な領域 が増える • 信頼性パターンを確保するために追加のコードとライブラリーが必要にな る
21. コストと信頼性のトレードオフ • 実装の冗長性の増加 • 信頼性を確保するにはレプリカ数を増やす • 地理的な分散をする • ディザスターリカバリーソリューション
22. コスト最適化とは？ • アーキテクチャー設計は常にビジネス目標に基づくものであり ROIと財務上の制約に基づくものである。 • 一般的に、セキュリティ・スケーラビリティ・回復性・運用性などと はトレードオフが発生する。 • ビジネス要件の利点を正当化できない場合より安価なソリュー ションを選ぶという危険な選択をしてしまい、組織のビジネス目標 を達成できないまたはその評判に影響を与えてしまう結果になる。 • ※コスト最適化とは安いソリューションを選択することではない
23. コスト効率を考えた設計 • 投資に対する最高の収益を達成するために必要なものだけに費 やします。 • 最適なサイジング • 最適な機能レベル • 運用環境と非運用環境に求められる機能差
24. 使用レベルに合わせた設計 • リソースの使用を最大化します。 • 不要な機能を含むSKUを選択することを避けます • 動的にスケールさせる
25. レート最適化の設計 • 機能要件または非機能要件を犠牲にすることなく効率を向上させ る • ハイブリッド特典 • 非運用環境において低コストのSKUを検討 • コスト効率が高い場合は従量課金ベースも検討
26. 主なデザインパターン パターン コンピューティングリソース統合 密度を高めることでコンピューティング リソースを最適化および統合します。 このパ ターンは、共有インフラストラクチャ上でワークロードの複数のアプリケーションまたは コンポーネントを組み合わせます。 そうすることで、プールされたインフラストラクチャ 上のコンポーネントまたはワークロード全体を集約して、使用されていないプロビジョ ニングされた容量を回避し、コンピューティング リソースの利用率を最大限に高めます。 App Service PlanにApp Serviceを複数集約するなど。 静的コンテンツホスティング その目的のために設計されたホスティング プラットフォームを使用して、ワークロード クライアントへの静的コンテンツの配信を最適化します。 動的アプリケーション ホストは、 通常、コード化されたビジネス ロジックを実行できるため、静的ホストよりもコストが高 くなります。 静的コンテンツの配信にアプリケーション プラットフォームを使用すること は、コスト効率が良くありません。 Static Web Appsなど
27. コンピューティングリソース統合 • 複数のアプリケーションを1つのコンピューティングリソースに統 合します。 • たとえば、1つのApp Service Planに複数のApp Serviceを ホストします。 • スケーラビリティやセキュリティなどの問題が考慮事項として存在 します。
28. 静的コンテンツホスティング • 静的コンテンツのみを配信する目的であれば高額なコンピュー ティングインスタンスをもつリソースを使う必要がありません。 • Static Web Appsなどを使用することが最適なソリューション です。
29. コスト最適化と信頼性のトレードオフ • システムが停止することでの損失するコストと頻度と信頼性設計 のためのコストを比較します。 • サービス中断することでの損失コストが上回る場合はさらに信頼 性設計のために投資する必要があります。 • 一般に冗長性とコストはトレードオフの関係にあります。
30. コスト最適化とパフォーマンス効率のト レードオフ • コスト最適化とパフォーマンス効率は両方ともワークロードの最大 化に優先順位を付けます。 • ただし、コスト制限をするとパフォーマンス不足になります。 • また、コストを優先するためにスケーリングを制限したり遅延した りすると需要を満たすのに十分なリソースが得られないことがあ ります。
31. まとめ • Azure Well-Architected Frameworkではワークロードを より高品質にするための設計原則を提供します。 • しかしながら、ビジネス的な制約、それぞれのトレードオフをみな がらそれぞれのビジネス目標にあった選択をすることが重要に なってきます。
32. 宣伝 おしまい
33. .NETラボ10月(10/25)
34. Microsoft MVPとMicrosoft Ignite の日に徹夜するバー(11/18)
35. .NETラボ11月 (11/22)
36. Microsoft MVPを語るバー(11/23)
37. おしまい おしまい