はじめに
このモジュールでは、ある架空の会社の高可用性シナリオをサポートするために、既存のアーキテクチャに基づいて構築します。 アプリケーション設計、インフラストラクチャの選択、データ モデル、および全体的な監視に関する高度な仕様が提供されます。 演習の最後に、あなたの設計を類似のアーキテクチャの設計と比較して、作業内容を確認します。 将来の機能強化に備えて、どんなギャップがあるかをメモしておいてください。
シナリオ例
Contoso Shoes は、2 年前にオンプレミスのデプロイをクラウドに移行しました。 運用の改善は見られましたが、サービス レベル アグリーメント (SLA) 内で可用性とアップタイムを維持することは困難でした。 トラフィックの急増が予想される、新製品の発売も予定されています。 以前のリリースでは、システムが負荷の増加に対応できなかったためにサービス停止が発生し、大きな金銭的損失となりました。
その経験に基づいて、組織は現在、システムの全体的な信頼性を高め、監視を強化することに取り組んでいます。 既存アプリケーションの "可用性のターゲットを更新" し、これを "ミッション クリティカル" としました。
アーキテクチャ内の "1 つ以上のコンポーネントの失敗に耐える" ことができるのみならず、"リージョンの完全な停止にも耐える" ことができ、その一方で運用に対してシステム正常性に関する分析情報をさらに提供することができるような設計の改善を組織は必要としています。 もう 1 つリージョンを追加できるか可能性を検討しました。 Contoso では、地理的により近いリージョンでより迅速にクライアントにサービスを提供することで、カスタマー エクスペリエンスを向上したいとも考えています。
チームは、"コストと複雑さが増すというトレードオフ" を理解しています。 ただし、長期間ダウンした場合のコスト (実際のコストと評判を損なうことによるコスト) は、2 番目のリージョンで稼働させるコストよりも大きくなります。 リード クラウド アーキテクトとして、これらの目標を念頭に置いて、現在のアーキテクチャを評価して改善するよう求められました。
既存のアプリケーションは、Azure Well-Architected Framework の品質の柱に従って既に設計されています。 最初の手順として、Well-Architected のミッション クリティカルなワークロードに関するガイダンスを読みました。 信頼性に関して最も強い影響をシステムに与え得る重点分野として、システムの回復性と監視の強化に優先順位を置いています。
学習内容
- アプリケーションで正常性エンドポイントを設計し、API レベルとその依存関係で正常性を確認する
- ソリューションを複数のリージョンに拡張し、1 つのリージョンの障害に耐える
- 正常性モデルを構築し、運用ダッシュボードを使用して監視データを視覚化する
重要
この演習では、ミッション クリティカルなワークロードのすべての設計領域をカバーしているわけではありません。 この課題を完了した後も、引き続き Well-Architected のミッション クリティカルなワークロードに関するページで提供されるミッション クリティカルな原則を調べ、独自の設計に対するさまざまな分析観点を習得することをお勧めします。
主な目標
このモジュールの終わりまでに、ミッション クリティカルな設計原則を "サンプル" シナリオに適用する能力を実証できるでしょう。 学習に基づいて、同様の設計を評価し、最終的には独自の運用対応のミッション クリティカルなソリューションを作成できます。