App Service を使用したミッション クリティカルなベースライン

この記事では、Azure App Service を使用してミッション クリティカルな Web アプリケーションをデプロイする方法について説明します。 このアーキテクチャでは、信頼性の高い Web アプリ パターン を開始点として使用します。 従来のワークロードがあり、サービスとしてのプラットフォーム (PaaS) サービスを採用する場合は、このアーキテクチャを使用します。

.NET 用の Reliable Web アプリ パターンでは、クラウドに移行する Web アプリを更新または再プラットフォーム化するためのガイダンスが提供されます。 この方法は、必要なコード変更を最小限に抑え、サービス レベル目標 (SLO) を 99.9%に設定するのに役立ちます。 ミッション クリティカルなワークロードには、高い信頼性と可用性の要件があります。 99.95%、99.99%以上の SLO に到達するには、補助的なミッション クリティカルな設計パターンと運用の厳格さを適用する必要があります。 この記事では、主要な技術領域と、ミッション クリティカルな設計プラクティスを導入して実装する方法について説明します。

以下のセクションでは、次の方法について説明します。

• 既存のワークロードを確認して、そのコンポーネント、ユーザーとシステムのフロー、可用性とスケーラビリティの要件を理解します。
• コンパートメント化を通じてエンド ツー エンドのスケーラビリティを最適化し、容量の追加と削除のプロセスを標準化するための、スケール ユニット アーキテクチャの を開発して実装します。
• スケーラビリティとダウンタイムゼロのデプロイを可能にするために、ステートレスなエフェメラル スケール ユニットまたはデプロイ スタンプを実装します。
• スケーラビリティに備えてワークロードをコンポーネントに分割できるかどうかを判断します。 スケーラビリティと分離フローには、個々のコンポーネントが必要です。
• 複数の Azure リージョンにワークロードをデプロイしてグローバル分散 準備し、顧客との近接性を向上させ、潜在的なリージョンの停止に備えます。
• コンポーネントを分離し、イベント ドリブン アーキテクチャを実装します。

建築

次の図は、信頼性の高い Web アプリ パターンに前の考慮事項を適用します。

このアーキテクチャの Visio ファイル をダウンロードします。

赤いボックスは、一緒にスケーリングするサービスを含むスケール ユニットを表します。 それらを効果的にスケーリングするには、各サービスのサイズ、SKU、および使用可能な IP アドレスを最適化します。 たとえば、Azure App Configuration が提供する要求の最大数は、スケール ユニットが提供する 1 秒あたりの要求数に関連付けられます。 リージョンに容量を追加する場合は、個々のスケール ユニットを追加する必要もあります。

これらの個々のスケール ユニットは互いに依存関係を持たず、個々のスケール ユニットの外部にある共有サービスとのみ通信します。 これらのスケール ユニットは、新しいスケール ユニットをロールアウトし、それらが正しく機能することを検証し、運用トラフィックを徐々に移動することで、ブルーグリーン デプロイ で使用できます。

このシナリオでは、スケール ユニットを一時的なものとして検討します。これにより、ロールアウト プロセスが最適化され、リージョン内およびリージョン間でスケーラビリティが提供されます。 この方法を使用する場合は、データベースがセカンダリ リージョンにレプリケートされるため、データベースにのみデータを格納する必要があります。 スケール ユニットにデータを格納する必要がある場合は、スケール ユニットのストレージに 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 リージョン内の個々のデータセンターにデプロイを分散できます。 可用性ゾーンには優先順位が付けられますが、使用する戦略はワークロードによって異なります。 たとえば、待機時間の影響を受けやすいワークロードや、おしゃべりなワークロードでは、可用性セットの優先順位付けによってメリットが得られる場合があります。 ワークロードを複数の可用性ゾーンに分散すると、ゾーン間トラフィックの待機時間とコストが増加する可能性があります。 可用性ゾーンを使用する場合は、スケール ユニット内のすべてのサービスでサポートされていることを確認します。 Reliable Web アプリ パターン内のすべてのサービスで可用性ゾーンがサポートされます。

データ プラットフォームを選択する

選択したデータベース プラットフォームは、ワークロード アーキテクチャ全体、特にプラットフォームのアクティブ/アクティブまたはアクティブ/パッシブ構成のサポートに影響します。 信頼性の高い Web アプリ パターンでは Azure SQL が使用されます。これは、複数のインスタンスに書き込み操作があるアクティブ/アクティブデプロイをネイティブにサポートしていません。 この構成では、データ プラットフォームはアクティブ/パッシブ戦略に制限されます。 すべてのリージョンに読み取り専用レプリカがあり、1 つのリージョンにのみ書き込む場合は、アプリケーション レベルの (部分的な) アクティブ/アクティブ戦略が可能です。

サービスごとにデータベースを持つマイクロサービス アーキテクチャなど、複雑なアーキテクチャでは複数のデータベースが一般的です。 複数のデータベースを使用すると、Azure Cosmos DB などの複数プライマリ書き込みデータベースを採用できるため、高可用性と低待機時間が向上します。 リージョン間の待機時間では、制限が発生する可能性があります。 非機能的な要件と、一貫性、操作性、コスト、複雑さなどの要因を考慮することが重要です。 個々のサービスが個別のデータ ストアと特殊なデータ テクノロジを使用して、独自の要件を満たすことができるようにします。 詳細については、Azure 上のミッション クリティカルなワークロードのデータ プラットフォームに関する考慮事項参照してください。

正常性モデルを定義する

複数のデータセンターと地理的リージョンに分散する複雑な多層ワークロードでは、正常性モデルを定義する必要があります。

正常性モデルを定義するには:

• ユーザー フローとシステム フローを定義する
• サービス間の依存関係を指定して理解する
• サービスの 1 つに対する停止またはパフォーマンスの低下がワークロード全体に及ぼす影響を理解する
• カスタマー エクスペリエンスを監視および視覚化して、適切な監視を可能にし、手動および自動化されたアクションを改善します。

前の図は、App Configuration などの単一コンポーネントの停止または低下によって、お客様のパフォーマンスが低下する可能性がある原因を示しています。 コンポーネントをスケール ユニットに分割すると、影響を受けるスケール ユニットや完全なリージョンなど、アプリケーションの影響を受ける部分へのトラフィックの送信を停止できます。

スケール ユニットの正常性を決定するための基準は、正常性モデルで定義されます。 その後、このモデルはスケール ユニットの 正常性エンドポイント に接続されます。これにより、グローバル ロード バランサーはスケール ユニットの正常性状態を照会し、その情報を使用してルーティングの決定を行うことができます。

詳細については、Azure でのミッション クリティカルなワークロードの正常性モデリングと監視のに関するページを参照してください。

セキュリティとネットワーク

ミッション クリティカルなワークロードには、厳密なネットワークとセキュリティの要件があります。 特に、オンプレミス環境から移行されたワークロードに注意を払います。これは、確立されたすべてのオンプレミスのセキュリティ プラクティスがクラウド環境に変換されるわけではないためです。 アプリケーションの移行中にセキュリティ要件を再評価することをお勧めします。

ID は、多くの場合、クラウドネイティブ パターンの主要なセキュリティ境界です。 企業のお客様は、より大きなセキュリティ対策が必要になる場合があります。 Azure PaaS サービスは、ネットワーク のセキュリティ要件に対処するために、Azure Private Link を使用して、セキュリティ境界としてネットワークを実装できます。 Private Link を使用すると、仮想ネットワーク内からのみサービスにアクセスできるようになります。 その後、すべてのサービスにプライベート エンドポイント経由でのみアクセスできます。 次の図は、インターネットに接続するパブリック エンドポイントが Azure Front Door である方法を示しています。

信頼性の高い Web アプリ パターンでネットワークをセキュリティ境界として設定するには、次を使用する必要があります。

• それをサポートするすべてのサービスの Private Link。
• インターネットに接続する唯一のパブリック エンドポイントとしての Azure Front Door Premium。
• Azure Bastion 経由でサービスにアクセスするためのジャンプ ボックス。
• サービスにアクセスできるセルフホステッド ビルド エージェント。

ミッション クリティカルなアプリケーションのもう 1 つの一般的なネットワーク要件は、データ流出を防ぐためにエグレス トラフィックを制限することです。 適切なファイアウォール デバイスを介して Azure ファイアウォールをルーティングすることで、エグレス トラフィックを制限します。 次に、デバイスを使用してトラフィックをフィルター処理します。 ネットワーク制御 Azure ミッション クリティカルなベースライン アーキテクチャでは、ファイアウォールと Private Link が使用されます。

デプロイとテスト

誤ったリリースまたは人的エラーによって発生するダウンタイムは、常に使用可能である必要があるワークロードの問題になる可能性があります。 考慮すべき重要な領域を次に示します。

• ダウンタイムなしのデプロイ
• エフェメラルブルーグリーンデプロイ
• 個々のコンポーネントとグループ化されたコンポーネントのライフサイクル分析
• 継続的な検証

ダウンタイムゼロのデプロイ は、ミッション クリティカルなワークロードにとって重要です。 常に稼働している必要があるワークロードには、新しいバージョンをロールアウトするためのメンテナンス期間はありません。 この制限を回避するために、Azure ミッション クリティカルなアーキテクチャはダウンタイムなしのデプロイ パターンに従います。 変更は、トラフィックが段階的にルーティングされる前にエンド ツー エンドでテストされる新しいスケール ユニットまたはスタンプとしてロールアウトされます。 すべてのトラフィックが新しいスタンプにルーティングされると、古いスタンプが無効になり、削除されます。

詳細については、「Azureでのミッション クリティカルなワークロードのデプロイとテスト」を参照してください。

次の手順

• ラーニング パス: Azure でミッション クリティカルなワークロードを構築する
• チャレンジ プロジェクト: ミッション クリティカルな Web アプリケーション を設計する
• 学習モジュール: ミッション クリティカルなワークロード の正常性モデルを設計する

関連リソース

• Azure でのミッション クリティカルなベースライン アーキテクチャの
• ネットワーク制御 を使用したミッション クリティカルなベースライン アーキテクチャの
• Azure ランディング ゾーンのミッション クリティカルなベースライン アーキテクチャ
• Azure Load Testing と Azure Chaos Studio を使用した継続的な検証の