この記事では、Azure App Service を使用してミッション クリティカルな Web アプリケーションをデプロイする方法について説明します。 このアーキテクチャでは、信頼性の高い Web アプリ パターンを始点として使用します。 レガシ ワークロードがあり、サービスとしてのプラットフォーム (PaaS) のサービスを導入したい場合は、このアーキテクチャを使用します。
.NET 用の信頼性の高い Web アプリ パターンは、クラウドに移行する Web アプリを更新またはリプラットフォームして、必要なコード変更を最小限に抑え、99.9% のサービス レベル目標 (SLO) を目指すためのガイダンスとして使用できます。 ミッション クリティカルなワークロードには、高い信頼性と可用性の要件があります。 99.95% や 99.99% 以上の SLO に到達するには、追加のミッション クリティカルな設計パターンや厳しい運用を適用する必要があります。 この記事では、主要な技術的領域と、ミッション クリティカルな設計手法を実装して導入する方法について説明します。
Note
この記事のガイダンスは、Well-Architected フレームワークのミッション クリティカルなワークロードのシリーズにおける設計手法とベスト プラクティスに基づいています。
以下のセクションでは、その方法について説明します。
- 既存のワークロードを確認して、そのコンポーネント、ユーザー フローとシステム フロー、可用性とスケーラビリティの要件を把握する。
- コンパートメント化を通じてエンドツーエンドのスケーラビリティを最適化し、容量を追加および削除するプロセスを標準化するためのスケール ユニット アーキテクチャを作成して実装する。
- スケーラビリティとダウンタイムなしのデプロイを実現するために、ステートレスなエフェメラル スケール ユニットまたはデプロイ スタンプを実装する。
- スケーラビリティに備えるためにワークロードを複数のコンポーネントに分割できるかどうかを判断する。 スケーラビリティと分離のフローには、個々のコンポーネントが必要。
- 複数の Azure リージョンにわたってワークロードをデプロイしてグローバル分散に備え、顧客との近接性を向上させて、潜在的なリージョンの停止に備える。
- コンポーネントを分離し、イベント ドリブン アーキテクチャを実装する。
Architecture
次の図では、信頼性の高い Web アプリ パターンに先ほどの考慮事項を適用しています。
このアーキテクチャの Visio ファイルをダウンロードします。
赤いボックスは、まとめてスケーリングするサービスを含むスケール ユニットを表しています。 それらをまとめて効果的にスケーリングするには、各サービスのサイズ、SKU、使用可能な IP アドレスを最適化します。 たとえば、Azure App Configuration によって提供される要求の最大数は、スケール ユニットによって提供される 1 秒あたりの要求数に関連付けられます。 リージョンで容量を追加する場合は、個々のスケール ユニットを追加する必要もあります。
これらの個々のスケール ユニットは相互依存関係を持たず、個々のスケール ユニットの外部にある共有サービスのみと通信します。 また、独立したスケール ユニットを事前にテストすることが可能です。 デプロイの他の領域に影響が及ばないようにするには、独立したスケール ユニットをロールアウトし、新しいリリースでサービスを置き換えるオプションを導入します。
ミッション クリティカルなワークロードの場合、独立したスケール ユニットは一時的なものです。これにより、ロールアウト プロセスが最適化され、リージョン内およびリージョン間でスケーラビリティが確保されます。 独立したスケール ユニットに状態を格納するのは避けてください。 スケール ユニット内のストレージに Azure Cache for Redis を使用し、データベースにも格納されている重要な状態やデータのみを格納することを検討してください。 スケール ユニットの停止が発生した場合、または別のスケール ユニットに切り替えた場合は、速度低下が発生したり、新規のサインインが必要になったりすることがありますが、Azure Cache for Redis は引き続き実行されます。
Application Insights はスケール ユニットから除外されます。 データを格納または監視するサービスを除外してください。 また、それらを固有のライフサイクルによって独自のリソース グループに分割します。
スケール ユニットを置き換えるか、新しいスケール ユニットをデプロイする場合は、履歴データを保持し、リージョンごとに 1 つのインスタンスを使用します。
詳細については、「Azure でのミッション クリティカルなワークロードのアプリケーション設計」を参照してください。
コンポーネント
このアーキテクチャでは、次のコンポーネントを使用します。
- アプリケーション ホスティング プラットフォームの App Service。
- 要求をキャッシュする Azure Cache for Redis。
- 構成設定を格納する App Configuration。
- バックエンド データベースの Azure SQL。
- アプリケーションから利用統計情報を取得する Application Insights。
代替
信頼性の高い Web アプリ パターンでは、次のことができます。
- App Service の代わりに Azure Kubernetes Service (AKS) を使用する。 このオプションは多数のマイクロサービスを持つ複雑なワークロードに適しており、 AKS では、基になるインフラストラクチャをより詳細に制御でき、複雑な多層セットアップが可能。
- ワークロードをコンテナー化する。 App Service ではコンテナー化がサポートされているものの、この例ではワークロードはコンテナー化されていない。 コンテナーを使用すると、信頼性と移植性が向上する。
詳細については、「Azure でのミッション クリティカルなワークロードに関するアプリケーション プラットフォームの考慮事項」を参照してください。
アプリケーション プラットフォームの選択
可用性のレベルは、アプリケーション プラットフォームの選択と構成に左右されます。 次のミッション クリティカルなガイダンスを検討してください。
- 可能な場合は可用性ゾーンを使用する。
- ワークロードに最適なプラットフォーム サービスを選択する。
- ワークロードをコンテナー化する。
可用性セットでは、データセンター内の複数の障害ドメインと更新ドメインにわたってデプロイを分散させます。 可用性ゾーンでは、Azure リージョン内の個々のデータセンターにわたってデプロイを分散させます。 可用性ゾーンには優先度が付けられることが多いですが、使用する戦略はワークロードによって異なります。 たとえば、待機時間の影響を受けやすいワークロードや頻繁に実行されるワークロードでは、可用性セットの優先度付けからメリットが得られる場合があります。 ワークロードを複数の可用性ゾーンにわたって分散させると、ゾーン間トラフィックの待機時間とコストが増加することがあります。 可用性ゾーンを使用する場合は、それらがスケール ユニット内のすべてのサービスによってサポートされていることを確認してください。 信頼性の高い Web アプリ パターン内のサービスはすべて、可用性ゾーンをサポートしています。
データ プラットフォームの選択
選択したデータベース プラットフォームは、ワークロード アーキテクチャ全体、特にプラットフォームのアクティブ/アクティブ構成またはアクティブ/パッシブ構成のサポートに影響を及ぼします。 信頼性の高い Web アプリ パターンでは、Azure SQL を使用します。これは、複数のインスタンスでの書き込み操作によるアクティブ/アクティブのデプロイをネイティブでサポートしていません。 そのため、データベース レベルはアクティブ/パッシブ戦略に制限されます。 読み取り専用レプリカがあり、1 つのリージョンのみに書き込む場合は、アプリケーション レベルでのアクティブ/アクティブ戦略を使用可能です。
このアーキテクチャの Visio ファイルをダウンロードします。
サービスごとにデータベースを持つマイクロサービス アーキテクチャなどの複雑なアーキテクチャでは、データベースが複数あるのが一般的です。 複数のデータベースを使用すると、Azure Cosmos DB などのマルチプライマリ書き込みデータベースの導入が可能になるため、高可用性と低遅延が強化されます。 リージョン間の待機時間によって、制限が生じる可能性があります。 非機能要件のほか、一貫性、操作性、コスト、複雑さなどの要素を考慮することが重要です。 個々のサービスで個別のデータ ストアと特殊なデータ テクノロジを使用して、独自の要件を満たせるようにしてください。 詳細については、「Azure でのミッション クリティカルなワークロードに関するデータ プラットフォームの考慮事項」を参照してください。
正常性モデルの定義
複数のデータセンターと地理的リージョンに分散されている複雑な多層ワークロードでは、正常性モデルを定義する必要があります。 ユーザー フローとシステム フローを定義し、サービス間の依存関係を指定および把握して、いずれかのサービスでの停止やパフォーマンスの低下がワークロード全体に与えうる影響を把握します。また、カスタマー エクスペリエンスを監視および視覚化して、適切な監視を実現し、手動アクションと自動アクションを改善します。
前の図は、App Configuration などの 1 つのコンポーネントの停止や低下により、どのようにして潜在的な顧客のパフォーマンスの低下が生じうるのかを示しています。
コンポーネントを複数のスケール ユニットに分散させると、影響を受けるスケール ユニットや完全なリージョンなど、アプリケーションの影響を受ける部分へのトラフィックの送信を停止できます。
詳細については、「Azure でのミッション クリティカルなワークロードの正常性モデリングと監視」を参照してください。
セキュリティとネットワーク
オンプレミスのエンタープライズ デプロイから移行するワークロードには、厳密なネットワークとセキュリティの要件があります。 すべての確立されたオンプレミス プロセスがクラウド環境に変換されるわけではありません。 クラウド環境において該当する場合は、これらの要件を評価してください。
ID は多くの場合、クラウドネイティブ パターンの主要なセキュリティ境界です。 企業顧客では、より大規模なセキュリティ対策が必要になる場合があります。 ネットワーク セキュリティ要件に対処するために、ほとんどの Azure PaaS サービスでは、Azure Private Link を使用してネットワークをセキュリティ境界として実装できます。 Private Link では、サービスに仮想ネットワーク内のみからアクセスできるようにすることが可能です。 すべてのサービスには、プライベート エンドポイント経由でのみアクセスできます。 次の図は、Azure Front Door がインターネットに接続する唯一のパブリック エンドポイントであることを示しています。
このアーキテクチャの Visio ファイルをダウンロードします。
信頼性の高い Web アプリ パターンでネットワークをセキュリティ境界として設定するには、次を使用する必要があります。
- Private Link をサポートするすべてのサービス用の Private Link。
- インターネットに接続する唯一のパブリック エンドポイントとしての Azure Front Door Premium。
- Azure Bastion 経由でサービスにアクセスするためのジャンプボックス。
- サービスにアクセスできるセルフホステッド ビルド エージェント。
ミッション クリティカルなアプリケーションのもう 1 つの一般的なネットワーク要件は、データ流出を防ぐためにエグレス トラフィックを制限することです。 適切なファイアウォール デバイスを介して Azure ファイアウォールをルーティングし、当該のデバイスでフィルター処理して、エグレス トラフィックを制限します。 ネットワーク制御を備えた Azure のミッション クリティカルなベースライン アーキテクチャでは、ファイアウォールと Private Link が使用されます。
デプロイとテスト
誤ったリリースまたは人的エラーによって引き起こされるダウンタイムは、常に使用可能である必要があるワークロードにとって問題になる可能性があります。 考慮すべき主な領域をいくつか以下に示します。
- ダウンタイムなしのデプロイ
- エフェメラル ブルー/グリーン デプロイ
- 個々のコンポーネントのライフサイクル分析とそれらのグループ化
- 継続的な検証
ダウンタイムなしのデプロイは、ミッション クリティカルなワークロードにとって重要です。 常に稼働している必要があるワークロードでは、より新しいバージョンをロールアウトするためのメンテナンス期間を設けることができません。 こうした制限を回避するために、Azure のミッション クリティカルなアーキテクチャでは、ダウンタイムなしのデプロイ パターンに従っています。 変更は、トラフィックが段階的にルーティングされる前にエンド ツー エンドでテストされる新しいスケール ユニットまたはスタンプとしてロールアウトされます。 すべてのトラフィックが新しいスタンプにルーティングされた後、古いスタンプは無効になり、削除されます。
詳細については、「Azure でのミッション クリティカルなワークロードのデプロイとテスト」を参照してください。
次のステップ
- ラーニング パス: Azure でミッション クリティカルなワークロードを構築する
- チャレンジ プロジェクト: ミッション クリティカルな Web アプリケーションを設計する
- Learn モジュール: ミッション クリティカルなワークロード用の正常性モデルを設計する