編集

Azure の Windows N 層アプリケーション

Blob Storage
DNS
Load Balancer
Virtual Network
Virtual Machines

この参照アーキテクチャでは、Windows 上の SQL Server をデータ層に使用して、N 層アプリケーション用に構成された仮想マシン (VM) と仮想ネットワークをデプロイする方法を示します。

Architecture

Microsoft Azure を使用した N 層アーキテクチャ

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

ワークフロー

このアーキテクチャには次のコンポーネントがあります。

全般

  • リソース グループ。 リソース グループは、Azure リソースをグループ化して、有効期間、所有者、またはその他の条件別に管理できるようにするために使用されます。

  • 可用性ゾーン。 可用性ゾーンは、Azure リージョン内の物理的な場所です。 それぞれのゾーンは、独立した電源、冷却手段、ネットワークを備えた 1 つまたは複数のデータセンターで構成されています。 複数のゾーンに VM を配置することで、アプリケーションは 1 つのゾーン内の障害に対する回復性が高くなります。

ネットワークと負荷分散

  • 仮想ネットワークとサブネット。 すべての Azure VM が、サブネットにセグメント化できる仮想ネットワーク内にデプロイされます。 階層ごとに個別のサブネットを作成します。

  • Application Gateway。 Application Gateway はレイヤー 7 のロード バランサーです。 このアーキテクチャでは、これによって HTTP 要求が Web フロント エンドにルーティングされます。 Application Gateway には、一般的な脆弱性やその悪用からアプリケーションを保護する Web アプリケーション ファイアウォール (WAF) も用意されています。

  • ロード バランサー。 Azure Standard Load Balancer は、Web 層からビジネス層へ、ビジネス層から SQL Server へとネットワーク トラフィックを分散するために使用します。

  • ネットワーク セキュリティ グループ (NSG)。 NSG を使用して、仮想ネットワーク内のネットワーク トラフィックを制限します。 たとえば、ここに示されている 3 層アーキテクチャでは、データベース層は Web フロントエンドからのトラフィックを受信せず、ビジネス層と管理サブネットからのトラフィックのみ受信します。

  • DDoS Protection。 Azure プラットフォームには分散型サービス拒否 (DDoS) 攻撃に対する基本的な保護が用意されていますが、DDoS 攻撃を軽減する機能が強化されている Azure DDoS ネットワーク保護を使用することをお勧めします。 「セキュリティに関する考慮事項」を参照してください。

  • Azure DNS。 Azure DNS は DNS ドメインのホスティング サービスです。 これは Microsoft Azure インフラストラクチャを使用した名前解決を提供します。 Azure でドメインをホストすることで、その他の Azure サービスと同じ資格情報、API、ツール、課金情報を使用して DNS レコードを管理できます。

仮想マシン

  • SQL Server Always On 可用性グループ。 レプリケーションとフェールオーバーを有効にすることで、データ層で高い可用性を提供します。 これは、Windows Server フェールオーバー クラスター (WSFC) テクノロジを使用してフェールオーバーを行います。

  • Active Directory Domain Services (AD DS) サーバー。 フェールオーバー クラスターと、これに関連するクラスター化されたロールを表すコンピューター オブジェクトは、Active Directory Domain Services (AD DS) に作成されます。

  • クラウド監視。 フェールオーバー クラスターでは、そのノードの半数以上が実行されている必要があり、"クォーラムに達している" と呼びます。 クラスターにノードが 2 つしかない場合は、ネットワークのパーティションにより、各ノードは自身がプライマリ ノードであると認識する可能性があります。 この場合、"監視" によって優先順位を決定し、クォーラムを確立する必要があります。 監視は、クォーラムを確立する際の優先順位決定者として動作可能な、共有ディスクなどのリソースです。 クラウド監視は、Azure Blob Storage を使用する一種の監視です。 クォーラムの概念の詳細については、「Understanding cluster and pool quorum (クラスターとプール クォーラムについて)」を参照してください。 クラウド監視の詳細については、「Deploy a cloud witness for a Failover Cluster (フェールオーバー クラスター用にクラウド監視をデプロイする)」を参照してください。

  • Jumpbox。 要塞ホストとも呼ばれます。 元々、管理者が他の VM に接続するために使用するネットワーク上にある、セキュリティで保護された VM です。 jumpbox の NSG は、セーフ リストにあるパブリック IP アドレスからのリモート トラフィックのみを許可します。 NSG は、リモート デスクトップ プロトコル (RDP) トラフィックを許可する必要があります。 このニーズを満たすために、Azure にはマネージド ソリューション Azure Bastion が用意されています。

推奨事項

実際の要件は、ここで説明するアーキテクチャとは異なる場合があります。 これらの推奨事項を開始点として使用してください。

仮想マシン

VM の構成に関する推奨事項については、「Azure での Windows VM の実行」を参照してください。

仮想ネットワーク

仮想ネットワークを作成するときに、各サブネット内のリソースが要求する IP アドレスの数を決定します。 CIDR 表記を使用して、必要な IP アドレスにとって十分な規模のサブネット マスクとネットワーク アドレス範囲を指定します。 標準的なプライベート IP アドレス ブロック (10.0.0.0/8、172.16.0.0/12、192.168.0.0/16) の範囲内にあるアドレス空間を使用します。

後で仮想ネットワークとオンプレミスのネットワークとの間にゲートウェイを設定する必要がある場合は、オンプレミスのネットワークと重複しないアドレス範囲を選択します。 仮想ネットワークを作成した後に、アドレス範囲を変更することはできません。

機能とセキュリティの要件を念頭に置いてサブネットを設計します。 同じ層または同じロール内のすべての VM は、同じサブネットに入れる必要があります。これがセキュリティ境界になります。 仮想ネットワークとサブネットの設計の詳細については、Azure Virtual Network の計画と設計に関するページを参照してください。

Application Gateway

Application Gateway の構成の詳細については、「アプリケーション ゲートウェイ構成の概要」を参照してください。

ロード バランサー

VM は直接インターネットに公開せず、代わりに各 VM にプライベート IP アドレスを付与します。 クライアントでは、Application Gateway に関連付けられているパブリック IP アドレスを使用して接続します。

ロード バランサー規則を定義して、ネットワーク トラフィックを VM に転送します。 たとえば、HTTP トラフィックを有効にするには、フロントエンド構成からのポート 80 をバックエンド アドレス プールのポート 80 にマップします。 クライアントがポート 80 に HTTP 要求を送信するときに、ロード バランサーは、発信元 IP アドレスを含むハッシュ アルゴリズムを使用して、バックエンド IP アドレスを選択します。 クライアント要求が、バックエンド アドレス プールのすべての VM に分散されます。

ネットワーク セキュリティ グループ

NSG ルールを使用して階層間のトラフィックを制限します。 上記の 3 層アーキテクチャでは、Web 層はデータベース層と直接通信しません。 この規則を適用するには、データベース層が Web 層のサブネットからの着信トラフィックをブロックする必要があります。

  1. 仮想ネットワークからのすべての受信トラフィックを拒否します。 (ルール内で VIRTUAL_NETWORK タグを使用します。)
  2. ビジネス層のサブネットからの受信トラフィックを許可します。
  3. データベース層のサブネットからの受信トラフィックを許可します。 このルールにより、データベースのレプリケーションやフェールオーバーに必要な、データベース VM 間の通信が可能になります。
  4. ジャンプボックスのサブネットからの RDP トラフィック (ポート 3389) を許可します。 このルールによって、管理者がジャンプボックスからデータベース層に接続できるようにします。

最初のルールよりも高い優先順位を設定してルール 2 から 4 を作成し、最初のルールをオーバーライドします。

SQL Server Always On 可用性グループ

SQL Server の高可用性のために Always On 可用性グループの使用をお勧めします。 Windows Server 2016 に先立って、Always On 可用性グループはドメイン コントローラーを必要とし、可用性グループ内のすべてのノードが同じ AD ドメイン内にある必要があります。

他の層は可用性グループ リスナーを使用してデータベースに接続します。 リスナーを使用することで、SQL クライアントは SQL Server の物理インスタンスの名前を知らなくても接続できます。 データベースにアクセスする VM はドメインに参加している必要があります。 クライアント (ここでは、別の層) は、DNS を使用してリスナーの仮想ネットワーク名を IP アドレスに解決します。

SQL Server Always On 可用性グループを構成する手順は、次のとおりです。

  1. Windows Server フェールオーバー クラスタリング (WSFC) クラスター、SQL Server Always On 可用性グループ、プライマリ レプリカを作成します。 詳細については、「AlwaysOn 可用性グループの概要」を参照してください。

  2. 静的プライベート IP アドレスを持つ内部ロード バランサーを作成します。

  3. 可用性グループ リスナーを作成し、リスナーの DNS 名を内部ロード バランサーの IP アドレスにマッピングします。

  4. SQL Server リスニング ポート (既定ではTCP ポート 1433) に対するロード バランサーのルールを作成します。 ロード バランサーのルールでは Floating IP (Direct Server Return とも呼ばれます) を有効にする必要があります。 これにより VM が直接クライアントに応答でき、プライマリ レプリカへの直接接続が可能になります。

    注意

    Floating IP が有効になっている場合は、フロントエンド ポート番号を、ロード バランサーのルール内のバックエンド ポート番号と同じにする必要があります。

SQL クライアントが接続を試みると、ロード バランサーがプライマリ レプリカに接続要求をルーティングします。 別のレプリカへのフェールオーバーが発生した場合は、ロード バランサーは新しい要求を自動的に新しいプライマリ レプリカにルーティングします。 詳細については、SQL Server Always On 可用性グループの ILB リスナーの構成に関するページを参照してください。

フェールオーバー中は、既存のクライアント接続は閉じられます。 フェールオーバーが完了すると、新しい接続は新しいプライマリ レプリカにルーティングされます。

アプリケーションが書き込みよりもはるかに多くの読み取りを行う場合は、読み取り専用クエリの一部をセカンダリ レプリカにオフロードできます。 「リスナーを使用した読み取り専用セカンダリ レプリカへの接続 (読み取り専用ルーティング)」を参照してください。

可用性グループの手動フェールオーバーの強制によってデプロイをテストします。

Jumpbox

このアーキテクチャで実行するのと同じように、プライベート仮想ネットワークで仮想マシンを実行する場合は、ソフトウェアのインストールやパッチの適用などのために仮想マシンにアクセスする必要があります。 ただし、これらのマシンをパブリック インターネットにアクセス可能にすることは、攻撃対象が大幅に拡大するため、お勧めできません。 代わりに、ジャンプボックスが中間アクセス層として使用されます。

以前は、顧客によって管理されている VM がジャンプボックスとして使用される可能性がありました。 そのシナリオでは、次の推奨事項が適用されます。

  • アプリケーション ワークロードが実行されている VM へのパブリック インターネットからの RDP アクセスを許可しないでください。 代わりに、これらの VM へのすべての RDP アクセスは、ジャンプ ボックスを経由するようにします。 管理者はジャンプボックスにログインした後、そのジャンプボックスから他の VM にログインします。 ジャンプボックスは、既知の安全な IP アドレスからのみ、インターネットからの RDP トラフィックを許可します。
  • ジャンプボックスのパフォーマンス要件は最小限に抑えられているので、小さな VM サイズを選択します。 ジャンプボックス用にパブリック IP アドレスを作成します。 ジャンプ ボックスを、他の VM と同じ仮想ネットワーク内の、個別の管理サブネット内に配置します。
  • ジャンプボックスをセキュリティで保護するには、安全な一連のパブリック IP アドレスからのみ RDP 接続を許可する NSG ルールを追加します。 他のサブネットに対しても NSG を構成して、管理サブネットからの RDP トラフィックを許可します。

カスタマー マネージド VM の場合は、これらすべてのルールが適用されます。 ただし、現時点では、Azure AD で保護されていない RDP または SSH への HTML5 アクセスを許可しているマネージド ジャンプボックス ソリューションである Azure Bastion の使用をお勧めします。 これは、顧客の総保有コスト (TCO) を最終的に低く抑えることができる、非常に簡単なソリューションです。

考慮事項

スケーラビリティ

スケール セット

Web 層とビジネス層については、個別の VM をデプロイするのではなく、Virtual Machine Scale Sets を使用することを検討してください。 スケール セットにより、同一の VM のセットを簡単にデプロイおよび管理し、パフォーマンス メトリックに基づいて VM を自動スケーリングできるようになります。 VM の負荷が増えると、追加の VM が自動的にロード バランサーに追加されます。 VM をすばやくスケール アウトしたり、自動スケールしたりする必要がある場合は、スケール セットを検討してください。

スケール セットにデプロイされる VM を構成するには、2 つの基本的な方法があります。

  • デプロイ後に、拡張機能を使用して VM を構成します。 この方法では、新しい VM インスタンスは、拡張機能なしの VM よりも起動に時間がかかる場合があります。

  • カスタム ディスク イメージと共にマネージド ディスクをデプロイします。 このオプションの方が早くデプロイできる場合があります。 ただし、イメージを最新の状態に保つ必要があります。

詳細については、「スケール セットの設計上の考慮事項」を参照してください。

ヒント

自動スケールのソリューションを使用する場合は、十分前もって実稼働レベルのワークロードでテストしてください。

サブスクリプションの制限

各 Azure サブスクリプションには、リージョンごとの VM の最大数などの、既定の制限があります。 サポート リクエストを提出することで、制限値を上げることができます。 詳細については、「Azure サブスクリプションとサービスの制限、クォータ、制約」をご覧ください。

Application Gateway

Application Gateway は、固定容量モードまたは自動スケール モードをサポートしています。 固定容量モードは、ワークロードが一定で予測可能なシナリオに便利です。 トラフィックが変動するワークロードには自動スケール モードを使用することを検討してください。 詳細については、「自動スケーリングとゾーン冗長 Application Gateway v2」を参照してください。

可用性

可用性ゾーンは、1 つのリージョン内で最適な回復性を実現します。 さらに高い可用性が必要な場合は、フェールオーバーのために Azure Traffic Manager を使用して 2 つのリージョン間でアプリケーションをレプリケートすることを検討してください。 詳細については、「高可用性のためのマルチリージョン n 層アプリケーション」を参照してください。

すべてのリージョンが可用性ゾーンをサポートするわけではありません。また、すべての VM サイズがすべてのゾーンでサポートされるわけではありません。 次の Azure CLI コマンドを実行して、リージョン内の各 VM サイズでサポートされているゾーンを検索してください。

az vm list-skus --resource-type virtualMachines --zone false --location <location> \
    --query "[].{Name:name, Zones:locationInfo[].zones[] | join(','@)}" -o table

可用性ゾーンをサポートしていないリージョンにこのアーキテクチャをデプロイする場合は、可用性セット内に各層の VM を配置します。 同じ可用性セット内の VM は、冗長性のために複数の物理サーバー、コンピューティング ラック、ストレージ ユニット、およびネットワーク スイッチに展開されます。 スケール セットでは "配置グループ" が自動的に使用されます。これは、暗黙的な可用性セットとして機能します。

可用性ゾーンにデプロイする場合は、Azure Load Balancer の Standard SKU と Application Gateway の v2 SKU を使用します。 これらの SKU は、ゾーン間の冗長性をサポートします。 詳細については、次を参照してください。

1 つの Application Gateway のデプロイでは、ゲートウェイの複数のインスタンスを実行できます。 運用環境のワークロードの場合は、少なくとも 2 つのインスタンスを実行します。

正常性プローブ

Application Gateway と Load Balancer はどちらも正常性プローブを使用して、VM インスタンスの可用性を監視します。

  • Application Gateway は常に HTTP プローブを使用します。
  • Load Balancer は、HTTP または TCP のいずれかをテストできます。 一般に、VM で HTTP サーバーが実行されている場合は、HTTP プローブを使用します。 それ以外の場合は、TCP を使用します。

タイムアウト期間内にプローブがインスタンスに到達できなかった場合、ゲートウェイまたはロード バランサーはその VM へのトラフィックの送信を停止します。 プローブでは引き続きチェックが行われ、VM を再び使用できるようになった場合は、VM がバックエンド プールに戻されます。

HTTP プローブでは、指定されたパスに HTTP GET 要求が送信され、HTTP 200 応答がリッスンされます。 このパスには、ルート パス ("/")、またはアプリケーションの正常性をチェックするためのカスタム ロジックを実装した正常性監視エンドポイントを指定できます。 エンドポイントでは、匿名の HTTP 要求を許可する必要があります。

正常性プローブの詳細については、以下を参照してください。

正常性プローブ エンドポイントの設計の考慮事項については、「正常性エンドポイントの監視パターン」を参照してください。

コスト最適化

コストを見積もるには、Azure 料金計算ツールを使用します。 その他の考慮事項のいくつかを次に示します。

仮想マシン スケール セット

仮想マシン スケール セットは、Windows VM のすべてのサイズで使用できます。 デプロイする Azure VM や、消費したその他の基になるインフラストラクチャ リソース (ストレージやネットワークなど) に対してのみ課金されます。 Virtual Machine Scale Sets サービスに対する増分料金は発生しません。

単一の VM の価格オプションについては、Windows VM の料金に関するページを参照してください。

[データベースのインポート]

Azure SQL DBaas を選択した場合は、Always On 可用性グループやドメイン コントローラー マシンを構成する必要がないため、コストを節約できます。 単一データベースからマネージド インスタンスまたはエラスティック プールまで、いくつかのデプロイ オプションがあります。 詳細については、Azure SQL の料金に関するページを参照してください。

SQL Server VM の価格オプションについては、SQL VM の料金に関するページを参照してください。

ロード バランサー

構成された負荷分散およびアウトバウンド規則の数に対してのみ課金されます。 インバウンド NAT 規則は無料です。 規則が構成されていない場合、Standard Load Balancer に対する 1 時間あたりの料金は発生しません。

詳細については、「Microsoft Azure Well-Architected Framework」のコストのセクションを参照してください。

セキュリティ

仮想ネットワークは、Azure のトラフィックの分離境界です。 既定では、ある仮想ネットワーク内の VM が、別の仮想ネットワーク内の VM と直接通信することはできません。 ただし、仮想ネットワーク ピアリングを使用して複数の仮想ネットワークを明示的に接続することができます。

NSG。 ネットワーク セキュリティ グループ (NSG) を使用して、インターネットとの間で送受信されるトラフィックを制限します。 詳細については、「Microsoft クラウド サービスとネットワーク セキュリティ」をご覧ください。

DMZ。 ネットワーク仮想アプライアンス (NVA) を追加してインターネットと Azure Virtual Network の間の DMZ を作成することを検討してください。 NVA とは、ネットワーク関連のタスク (ファイアウォール、パケット インスペクション、監査、カスタム ルーティングなど) を実行できる仮想アプライアンスの総称です。 詳細については、Azure とインターネットの間の DMZ の実装に関する記事を参照してください。

暗号化。 機密の保存データを暗号化し、Azure Key Vault を使用してデータベース暗号化キーを管理します。 Key Vault では、ハードウェア セキュリティ モジュール (HSM) に暗号化キーを格納することができます。 詳細については、 Azure VM 上の SQL Server に関する Azure Key Vault 統合の構成に関するページを参照してください。 データベース接続文字列などのアプリケーション シークレットも Key Vault に格納することをお勧めします。

DDoS 保護。 Azure プラットフォームには、基本的な DDoS 保護が既定で用意されています。 この基本的な保護は、Azure インフラストラクチャ全体を保護することを目的としています。 基本的な DDoS 保護は自動的に有効になっていますが、Azure DDoS ネットワーク保護を使用することをお勧めします。 ネットワーク保護では、アプリケーションのネットワーク トラフィック パターンに基づいて、アダプティブ チューニングが使用され、脅威が検出されます。 これにより、インフラストラクチャ全体の DDoS ポリシーで見落とされてしまう可能性のある DDoS 攻撃に対して、軽減策を適用することができます。 ネットワーク保護では、Azure Monitor 経由で、アラート、テレメトリ、および分析機能も提供されます。 詳細については、「Azure DDoS Protection:ベスト プラクティスと参照アーキテクチャ」をご覧ください。

オペレーショナル エクセレンス

このアーキテクチャではすべての主要なリソースとその依存関係が同じ仮想ネットワーク内にあるため、同じ基本的なワークロードに分離されます。 そのため、ワークロード固有のリソースをチームに容易に関連付けられるので、チームはこれらのリソースのあらゆる側面を個別に管理できます。 この分離により、DevOps で継続的インテグレーションと継続的デリバリー (CI/CD) を実行できるようになります。

また、各種デプロイ テンプレートを使用して、それを Azure DevOps Services と統合することで、さまざまな環境を数分でプロビジョニングし、必要なときにのみ、たとえば疑似運用シナリオをレプリケートしたりテスト環境を読み込んだりできるため、コストを節約できます。

このシナリオでは、マルウェア対策やセキュリティ エージェントなどの特定の追加ソフトウェアが仮想マシンにインストールされる可能性があるため、それらは仮想マシン拡張機能を使用して構成されています。 VM 拡張機能は、VM 作成時にのみインストールおよび実行されます。 つまり、後からオペレーティング システムの構成に問題が生じた場合、正しい状態に戻すには手動による介入が必要になります。

このアーキテクチャでは、構成管理ツール、具体的には Desired State Configuration (DSC) を使って、Active Directory および SQL Server Always On 可用性グループが構成されています。

Azure Monitor を使用して、インフラストラクチャのパフォーマンスを分析および最適化することを検討してください。仮想マシンにログインせずに、ネットワークの問題を監視および診断できます。 Application Insights は、実際には Azure Monitor のコンポーネントの 1 つであり、ご利用の Azure 環境全体の状態を検証するためのメトリックとログを豊富に提供します。 Azure Monitor は、インフラストラクチャの状態を追跡するのに役立ちます。

アプリケーション コードを支えるコンピューター要素だけでなく、ご自身の特定のデータベースで、データ プラットフォームも監視するようにしてください。アプリケーションのデータ層のパフォーマンスが低いと、深刻な結果を招く可能性があるからです。

アプリケーションが実行されている Azure 環境は、テストの目的で、アプリケーション コードと同じメカニズムを使用してバージョン管理およびデプロイされている必要があるため、DevOps テストパラダイムを使用してテストおよび検証することもできます。

詳細については、Azure Well-Architected Framework に関するページのオペレーショナル エクセレンスのセクションを参照してください。

次のステップ