まとめ
Contoso Shoes は、靴を扱うオンライン ストアで、近々予定されている新製品のリリース時に高可用性を実現したいと考えています。 2 年前にオンプレミスのデプロイをクラウドに移行し、OpEx モデルを採用することでメリットを得ました。 過去 6 か月間に可用性に関する問題が発生していますが、オペレーターは問題のトラブルシューティングを迅速に行うことができないでいます。 組織は、ワークロードをミッション クリティカルにすることに投資し、システムの全体的な信頼性と監視を向上させることに重点を置きたいと考えています。
以前のアーキテクチャでは、アプリケーションは 1 つのリージョンにデプロイされ、リージョンの障害に耐えられませんでした。 Azure App Service と外部監視ツールには、アプリケーション自体の正常性状態をチェックする方法がありません。 このギャップにより、トラフィックが異常な App Service インスタンスにルーティングされ、要求が失敗しました。 チームは API コンポーネントがプラットフォームの依存関係に影響を与えるという問題の連鎖的な影響を確認できませんでした。
この課題に取り組むことで、ミッション クリティカルな設計を高いレベルで考察してきました。 演習を通して学習した事柄を適用することで、Contoso のニーズを満たしてきました。
改善された設計では、正常性モデルを使用して 1 つ以上のコンポーネントのパフォーマンスの低下を検出します。 SRE チームは、完全な停止につながる前に、問題をすばやく特定して解決できるようになりました。 アクティブ/アクティブ モデル内の複数のリージョンにソリューションがデプロイされたので、オペレーターにより多くのシステムの正常性に関する分析情報を提供しながら、リージョン全体の障害にも耐えることができるようになりました。 Contoso では、地理的により近いリージョンで、より迅速にクライアントにサービスを提供することで、カスタマー エクスペリエンスを向上したいとも考えています。
お疲れさまでした。このチャレンジ プロジェクトを完了しました。 既存のサンプル ソリューションを分析し、改善されたアーキテクチャを設計できるスキルを実証してきました。
推奨される次の手順
これらの演習を完了することで、素晴らしいスタートを切ることができましたが、これらの演習はミッション クリティカルなワークロードのすべての側面を網羅しているわけではありません。 適切に設計されたミッション クリティカルなワークロードに関するページで提供される設計の原則と分野について、学習し続けてください。 以下の重要な価値ある分野をお勧めします。
継続的な検証とテスト
アプリケーション コードとインフラストラクチャの両方の正常性を完全に検証する必要があります。 スコープは、信頼性、パフォーマンス、可用性、セキュリティ、品質、スケールに関する要件セットをカバーする必要があります。
詳細情報: 継続的な検証とテスト
複数のアプリケーション環境を使用する
開発/テスト環境では、運用環境とリソースを共有しないことを強くお勧めします。 それぞれの環境には、信頼性、容量、セキュリティに関する独自の要件セットがあります。 環境間で共有されるこのアーキテクチャのサービスを特定できますか。 この推奨事項に合わせて設計をどのように変更しますか。
詳細情報: アプリケーション環境
拡張されたデプロイ環境
ミッション クリティカルなシステムには、厳格なプレリリース テストと、強固なソフトウェア開発ライフサイクル (SDLC) プラクティスが必要です。 単一の共有開発環境の代わりに、ステージングと運用でよく調整された複数の一時的な環境を使用します。 負荷およびパフォーマンス テスト、カオス テスト、ユーザー受け入れテスト (UAT)、セキュリティ テストには専用のステージング環境を使用する必要があります。
詳細情報: 一時的なブルー/グリーン デプロイ
メッセージ ブローカーを使用して回復性を追加する
複数のエンドポイントとの調整が必要な複雑なトランザクションを支援するメッセージ ブローカーを導入します。 単一コンポーネントの障害によって販売機会が失われるリスクを抱えるのではなく、処理のために要求をキューに入れることができます。
詳細情報: 疎結合のイベント ドリブン アーキテクチャ
詳細情報
Azure でのソリューションの設計の詳細については、Azure Well-Architected Framework のガイドを参照してください。
設計を拡張する方法として、Azure アーキテクチャ センターで次の参照アーキテクチャについて調べてください。