この記事では、Azure VMware Solution ワークロードのアプリケーション プラットフォーム設計領域について説明します。 この領域では、Azure VMware Solution 環境でホストするアプリケーションのデプロイ、構成、保守に関連する特定のタスクと責任について説明します。 アプリケーション所有者は、Azure VMware Solution 環境のアプリケーションを担当します。 この個人またはチームは、アプリケーションのデプロイ、構成、監視、およびメンテナンスに関連する側面を管理します。
適切に設計されたアプリケーションの主な目的は次のとおりです。
- スケールの設計。 低下やサービスの中断なしに、より高いユーザー要求と同時トランザクションを適切に処理します。
- パフォーマンス。 迅速で待機時間の短い応答時間を実現し、リソース使用率を効率的に管理します。
- 信頼性と回復性。 アプリケーションの応答性を維持し、障害から迅速に回復できるように、冗長でフォールト トレラントなパターンを設計します。
この記事では、開発者、アーキテクト、アプリケーション所有者に、Azure VMware Solution に固有のベスト プラクティスを提供することを目的としています。 これらのプラクティスは、堅牢で、セキュリティで保護され、スケーラブルで、ライフサイクル全体を通じて保守可能なアプリケーションを構築するのに役立ちます。
スケーラビリティと効率的なリソース分散のための設計
影響:信頼性、パフォーマンス効率、セキュリティ
このセクションでは、Azure VMware Solution プライベート クラウド内の仮想マシン (VM) とワークロード間でのコンピューティング リソースの効果的な割り当てと使用率について説明します。 これらのリソースには、CPU、メモリ、ストレージ、ネットワーク リソースを含めることができます。 このセクションでは、レスポンシブ スケーリング手法の実装についても説明します。 これらの手法を使用して、需要の変動に対応するようにリソース プロビジョニングを動的に調整できます。 主な目的は、非効率性とコストのエスカレートにつながる可能性のある過小使用と過剰プロビジョニングを軽減することで、最適なリソース使用率を実現することです。
障害ドメインを使用する
Azure VMware Solution の障害ドメインは、ストレッチ クラスター内のリソースの論理的なグループを表します。 これらのリソースは、共通の物理障害ドメインを共有します。 障害ドメインは、さまざまな障害シナリオでの可用性の向上に役立ちます。 リソースを障害ドメインに整理すると、アプリケーションの重要なコンポーネントが複数の障害ドメインに分散されます。
VM やその他のリソースを別々の障害ドメインに配置することで、アプリケーション チームは、データセンターまたはインフラストラクチャの障害時にアプリケーションを引き続き使用できるように支援します。 たとえば、VM を、地理的に分散されたデータセンターに分散された障害ドメインに分割できます。 その後、1 つのデータセンターで完全な障害が発生した場合、アプリケーションは引き続き運用できます。
アプリケーション チームは、障害ドメインに基づく VM-VM アフィニティルールとアンチアフィニティルールの定義を検討する必要があります。 VM-VM アフィニティ ルールでは、重要な VM が同じ障害ドメインに配置され、複数のデータセンターに分散されないようにします。 アンチアフィニティ ルールを使用すると、関連する VM が同じ障害ドメイン内にまとめて配置されるのを防ぐことができます。 この方法は、冗長性を確保するのに役立ちます。
3 層アプリケーションで VM-VM アンチアフィニティ ポリシーを使用する
Azure VMware Solution では、VM-VM のアフィニティ対策ポリシーのユース ケースには、3 層アプリケーションが含まれます。 目標は、各アプリケーション層の高可用性、フォールト トレランス、回復性を強化することです。 この目標を達成するには、アフィニティ対策ポリシーを使用して、Azure VMware Solution プライベート クラウド内の異なるホスト間で階層を分散できます。
このユース ケースを実装するには、3 つの層にまたがるアンチアフィニティ ポリシー VM-VM 使用して、分散型のフォールト トレラント アーキテクチャを作成します。 このセットアップにより、アプリケーション全体の可用性が向上し、1 つのホストの障害によって階層全体またはアプリケーション全体が中断されないようにすることができます。
たとえば、ユーザー要求を処理するフロントエンド Web 層では、VM-VM アンチアフィニティ ポリシーを適用して、異なる物理ホストに Web サーバーを分散させることができます。 このアプローチは、高可用性とフォールト トレランスの向上に役立ちます。 同様に、アフィニティ対策を使用して、ビジネス 層内のアプリケーション サーバーを保護し、データベース層内のデータの回復性を強化できます。
推奨事項
- VM の相互依存関係、通信、および使用パターンを示すマップを作成して、近接性が要件であることを確認します。
- 配置ポリシー VM-VM アフィニティがパフォーマンス メトリックまたはサービス レベル アグリーメント (SLA) を満たすのに役立つかどうかを判断します。
- 高可用性を実現するために、ホストの障害から保護し、アプリケーションを複数のホストに分散させる「VM-VM アンチアフィニティポリシー」を導入するよう設計します。
- オーバープロビジョニングを回避するには、少数の大規模な VM ではなく、小規模な VM にワークロードを分散します。
- アフィニティ ポリシーを定期的に監視、確認、および微調整して、リソースの競合の可能性を特定します。 必要に応じて、これらのポリシーを時間の経過と同時に調整します。
パフォーマンスの分離に VM ホスト アフィニティ ポリシーを使用する
異なるアプリケーション層で VM を実行する一部のワークロードは、併置時にパフォーマンスが向上します。 このユース ケースは、多くの場合、アプリケーションで次のものが必要な場合に発生します。
- リソースを集中的に使用し、高パフォーマンスのコンピューティング ワークロードのパフォーマンスを分離します。
- ライセンス契約への準拠。 たとえば、システム仕様では、Windows または SQL Server のライセンスへの準拠を維持するために、VM を特定のコア セットに関連付けるマッピングが必要になる場合があります。
- 特定のセキュリティ ドメインまたはデータ分類に属する VM が、クラスター内の特定のホストまたはホストのサブセットに限定されるようにするための規制コンプライアンスとデータ整合性。
- VM を同じホストに配置する 簡略化されたネットワーク構成 。 この場合、層間のネットワーク構成が簡略化されます。 層は同じネットワーク接続を共有し、追加のネットワーク ホップは必要ありません。
アプリケーション層のコロケーションを維持することが不可欠な場合は、 VM ホスト アフィニティ ポリシーを選択して、同じホストと同じ可用性ゾーン内に階層がデプロイされるようにすることができます。
注
プラットフォーム チームは、VM の配置、ホスト アフィニティルール、およびリソース プールの設定を担当します。 ただし、アプリケーション チームは、アプリケーションのニーズが満たされていることを確認するために、各アプリケーションのパフォーマンス要件を理解する必要があります。
アプリケーション チームは、VM の配置を包括的に評価し、細心の計画に取り組む必要があります。 VM の配置は、リソースの不均衡や不均等なワークロード分散などの潜在的な課題を提示する可能性があります。 このような状況は、パフォーマンスとリソースの最適化に悪影響を及ぼす可能性があります。 また、すべてのワークロードを 1 つの可用性ゾーンに配置すると、障害が発生した場合に単一障害点が発生する可能性があります。 障害発生時のデータセンターの回復性を高めるために、複数の可用性ゾーン間で構成をレプリケートすることを検討してください。
推奨事項
- 配置ポリシー VM ホスト アフィニティ ポリシーの使用方法を慎重に計画します。 負荷分散、VMware vSphere のリソース プール、分散データベース、コンテナー化、可用性ゾーンなど、可能な場合は別のソリューションを検討してください。
- リソースの使用率とパフォーマンスを定期的に監視して、不均衡や問題を特定します。
- バランスのとれた柔軟な VM 配置戦略を選択します。 このアプローチは、高可用性を維持し、ライセンス要件に確実に準拠しながら、リソース使用率を最大化するのに役立ちます。
- 配置ポリシーの VM とホストのアフィニティ構成をテストして検証し、アプリケーションの特定の要件に合わせ、全体的なパフォーマンスと回復性に悪影響を与えないようにします。
アプリケーションまたはネットワーク ロード バランサーを使用してトラフィックを分散する
配置ポリシーの使用に加えて、負荷分散は、次のことを保証するための最新のアプリケーションの重要なコンポーネントでもあります。
- 効率的なリソース分散。
- アプリケーションの可用性の向上。
- 最適なアプリケーション パフォーマンス。
負荷分散は、ワークロードのスケーリングと管理の柔軟性を維持しながら、これらの条件を満たしています。
VM にアプリケーションをデプロイした後は、Azure Application Gateway などの負荷分散ツールを使用してバックエンド プールを作成することを検討してください。 Application Gateway は、Web アプリケーションへの受信 HTTP および HTTPS トラフィックを管理および最適化できる、マネージド Web トラフィック ロード バランサーおよびアプリケーション配信サービスです。 Application Gateway は、Web トラフィックのエントリ ポイントとして、さまざまな種類の機能を提供します。 たとえば、TLS/SSL 終了、URL ベースのルーティング、セッション アフィニティ、Web アプリケーション ファイアウォール機能などがあります。
バックエンド プール内のリソースを使用できるようになったら、リスナーを作成して、受信要求のポートとルーティング規則を指定します。 その後、正常性プローブを作成して VM の正常性を監視し、異常なバックエンド リソースをローテーションから削除するタイミングを示すことができます。
TLS/SSL 終了と証明書管理を実装する
アプリケーションとユーザーのブラウザー間のすべての通信に対して TLS/SSL 暗号化を適用する必要があります。 この暗号化は、傍受や中間者攻撃からセッション データを保護するのに役立ちます。 アプリケーションで TLS/SSL 終了が必要な場合は、バックエンド VM から TLS/SSL 処理をオフロードするために、Application Gateway で必要な TLS/SSL 証明書を構成します。
TLS/SSL 証明書を生成したら、それらを安全に格納してアクセスするのに役立つ Azure Key Vault などのサービスに配置します。 PowerShell、Azure CLI、または Azure Automation などのツールを使用して、証明書を更新します。
API を管理する
Azure API Management は、内部および外部にデプロイされた API エンドポイントを安全に発行するのに役立ちます。 エンドポイントの例として、ロード バランサーまたは Application Gateway の背後にある Azure VMware Solution プライベート クラウド内にあるバックエンド API があります。 API Management は、セキュリティ ポリシーを適用して認証と承認を適用するなど、API のメソッドと動作を管理するのに役立ちます。 API Management では、Application Gateway を介してバックエンド サービスに API 要求をルーティングすることもできます。
次の図では、コンシューマーからのトラフィックは API Management パブリック エンドポイントに送信されます。 その後、トラフィックは、Azure VMware Solution で実行されるバックエンド API に転送されます。
推奨事項
- Azure VMware Solution アプリケーションのセキュリティとパフォーマンスを強化するには、Application Gateway と Azure VMware Solution バックエンドを使用して、アプリケーション エンドポイントにトラフィックを分散します。
- Azure VMware Solution をホストするバックエンド セグメントと、Application Gateway またはロード バランサーを含むサブネットの間に接続があることを確認します。
- バックエンド インスタンスの正常性を監視するように正常性プローブを構成します。
- バックエンド VM の処理オーバーヘッドを軽減するために、TLS/SSL 終了を Application Gateway にオフロードします。
- TLS/SSL キーをコンテナーに安全に格納します。
- 証明書の更新や更新などのタスクを自動化することで、プロセスを効率化します。
ストレッチ クラスターを最適化してビジネス継続性とディザスター リカバリーの準備を強化する
影響:信頼性
ストレッチ クラスターは、複数の地理的に分散されたデータセンター間で高可用性とディザスター リカバリー機能を備えた VMware クラスターを提供します。
次のセットアップでは、アクティブ/アクティブ アーキテクチャがサポートされています。 仮想記憶域ネットワーク (vSAN) は、2 つのデータセンターにまたがる。 3 つ目の可用性ゾーンは vSAN 監視にマップされ、スプリット ブレイン シナリオのクォーラムとして機能します。
複数の可用性ゾーンとリージョンにアプリケーションを分散することで、データセンターの障害時に継続的な可用性を確保できます。 両方のデータセンターにアプリケーション層とデータ層をデプロイし、同期レプリケーションを有効にします。
障害許容と許容障害 (FTT) ポリシーを構成する
アプリケーションの使用可能な合計容量は、複数の変数によって異なります。 たとえば、冗長ディスクアレイ（RAID）構成、failures to tolerate 属性の値、ストレージシステムが許容できる障害の数を制御する許容障害数（FTT）ポリシーなどがあります。 アプリケーション チームは、アプリケーションに必要な冗長性のレベルを決定する必要があります。 また、FTT 値が高いほどデータの回復性は向上しますが、ストレージのオーバーヘッドが増加します。
推奨事項
- ストレッチ クラスター全体で VM データの一貫性が維持されるように、共有ストレージ間でアプリケーションをデプロイします。 同期レプリケーションを有効にします。
- 障害ドメインを構成して、障害シナリオでのストレッチ クラスターの応答方法を定義します。
- 自動フェールオーバーとフェールバックを実装して、フェールオーバーおよび復旧イベント中の手動介入を最小限に抑えます。
データ同期とストレージ ポリシーを構成する
データ同期方法は、アプリケーションが障害発生時に整合性と可用性を確保するためにステートフル データとデータベースに依存する場合に重要です。 データ同期は、アプリケーションを実行する重要な VM の高可用性とフォールト トレランスを提供するのに役立ちます。
アプリケーション所有者は、次のことを確実に行うためにストレージ ポリシーを定義できます。
- アプリケーションを実行する重要な VM は、必要なレベルのデータ冗長性とパフォーマンスを受け取ります。
- VM は、Azure VMware Solution のストレッチ クラスターの高可用性機能を利用するように配置されています。
ポリシーの例には、次の要因が含まれる場合があります。
- vSAN 構成。 VMware vSAN と、複数の可用性ゾーンにまたがるストレッチ クラスターを使用します。
- 許容するエラーの数。 少なくとも 1 つ以上の障害を許容するようにポリシーを設定します。 たとえば、RAID-1 レイアウトを使用します。
- 性能 重要な VM の IOPS と待機時間を最適化するために、パフォーマンス関連の設定を構成します。
- アフィニティ ルール。 データセンターの障害発生時に可用性を最大化するために、VM または VM のグループがストレッチ クラスター内の個別のホストまたは障害ドメインに配置されるように、アフィニティ ルールを設定します。
- バックアップとレプリケーション。 バックアップおよびレプリケーション ソリューションとの統合を指定して、追加のデータ保護のために VM データが定期的にバックアップされ、セカンダリの場所にレプリケートされるようにします。
推奨事項
- vSAN でデータ ストレージ ポリシーを定義して、さまざまな VM ディスクに必要な冗長性とパフォーマンスを指定します。
- データセンターの障害時に重要なアプリケーション コンポーネントが失敗するように、アクティブ/アクティブまたはアクティブ/パッシブ構成で実行するようにアプリケーションを構成します。
- 各アプリケーションのネットワーク要件を理解します。 可用性ゾーン間で実行されるアプリケーションでは、可用性ゾーン内のトラフィックを含むアプリケーションよりも待機時間が長くなる可能性があります。 この待機時間を許容するようにアプリケーションを設計します。
- 配置ポリシーでパフォーマンス テストを実行して、アプリケーションへの影響を評価します。
次のステップ
アプリケーション プラットフォームを確認したので、接続を確立し、ワークロードの境界を作成し、アプリケーション ワークロードにトラフィックを均等に分散する方法を確認します。
評価ツールを使用して、設計の選択を評価します。