Microsoft AZ-104: Azure 負荷分散とトラフィック管理 — 学習ガイド

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

こちらの一部です： Microsoft Azure Administrator Associate AZ-104 — 学習ガイド. 検証済みの解答で練習： Microsoft試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

Azureは、トラフィックを分散および保護するための階層化されたポートフォリオを提供しています。これには、Azure Load Balancer (Layer 4, TCP/UDP)、Application Gateway (Layer 7, HTTP/S)、Azure Front Door (グローバルなLayer 7エッジ)、Azure Traffic Manager (DNSベース)、およびAzure CDN (エッジキャッシング) が含まれます。それぞれが、グローバルなDNSの意思決定やエッジPOPから、リージョン内のHTTPルーティング、プライベートなEast-Westトラフィックに至るまで、リクエストパスの特定のセグメントを対象としています。習熟するには、プロトコルと対象者に応じて適切なサービスを選択し、それらを適切に構成し、信頼性の高いフェイルオーバーを駆動するヘルスプローブとルールを設定することが重要です。

Azure Load Balancer (L4): SKU、構成要素、NAT/アウトバウンド、フローティングIP

Standard Load Balancerは、本番環境グレードのL4ロードバランサーです。ゾーン対応/ゾーン冗長であり、HAポート、高度な診断/メトリック、デフォルトでセキュア（ルールを定義しない限りインバウンドなし）、設定可能なアウトバウンドルール、大規模なバックエンドスケールをサポートします。Basicは、スケールや機能が限定され、ゾーン冗長性もないレガシーSKUです。新しいワークロードには選択すべきではなく、廃止予定です。

コアコンポーネントは、トラフィックフローを定義します:

フロントエンドIP: クライアントに公開されるVIP。外部LBはPublic IPまたはPublic IP Prefixを使用し、内部LBはサブネットからのプライベート静的IPを使用します。Standardは複数のフロントエンドとゾーン冗長パブリックIPをサポートします。
バックエンドプール: 同じリージョン/VNet内のNIC、NIC上のIP構成、またはVMスケールセットインスタンス。単一のプールが多くのルールにサービスを提供できます。Standardはリージョン内のクロスゾーンバックエンドをサポートします。
ヘルスプローブ: どのバックエンドインスタンスが正常かを判断します。TCPプローブはハンドシェイクを完了し、HTTP/HTTPSプローブはパスに対してGETを行い、200～399を成功と見なします。プロトコル、ポート、パス（HTTP/Sの場合）、間隔、および異常しきい値（ダウンとマークするまでの連続失敗回数）を制御します。
負荷分散ルール: フロントエンド（IP/ポート/プロトコル）をバックエンドプールとヘルスプローブに結びつけます。ルールの設定には、バックエンドポート、プロトコル（TCP/UDP）、セッション永続化、アイドルタイムアウト、Floating IP（Direct Server Return）が含まれます。

インバウンドNATルールは、特定のフロントエンドポートを単一のバックエンドNIC/ポートに転送するVMごとの変換です（例：負荷分散なしで1台のVMにRDPやSSHを公開する）。ヘルスプローブを使用せず、スケールアウトのメカニズムではありません。

アウトバウンドルールは、Standard Load BalancerのバックエンドがLBのパブリックフロントエンド経由でインターネットへの接続を開始する際のSNATの動作を定義します。これにより、どのフロントエンドがSNATポートを供給するか、およびバックエンドインスタンスごとに割り当てられるポート数を制御でき、高いアウトバウンド同時接続下でのSNATポート枯渇を回避するのに役立ちます。NAT Gatewayがサブネットにアタッチされている場合、それはLBのSNATを上書きします。一貫性のあるスケーラブルなアウトバウンドにはNAT Gatewayを推奨します。

Floating IP (Direct Server Return)は、宛先IP/ポートをエンドツーエンドで保持する必要がある場合に使用されるルールオプションです。SQL Server Always On可用性グループリスナーなどのクラスター化シナリオで必要です。SQL AGの場合、内部Standard Load Balancerを使用し、クラスターのプローブポートに対してTCPプローブ（HTTPではない）を設定し、LBルールでFloating IPを有効にします。SQLはHTTPワークロードではないため、ポート1433をHTTPでプローブしないでください。

内部ロードバランサーと外部ロードバランサーは、対象者とセキュリティ境界によって決まります。基幹業務アプリ、データベース、NVA向けにVNet内またはプライベート接続（VPN/ExpressRoute）経由でプライベートVIPを公開する場合は、内部LBを使用します。インターネットに面したL4サービスには、外部LBを使用します。内部LBの場合、ターゲットサブネットに静的なプライベートフロントエンドを割り当てます。外部LBの場合、Standard Public IPをバインドし、オプションで複数のフロントエンドを使用します。

Cross-region Load Balancerは、リージョンをまたいでグローバルなエニーキャストのLayer 4負荷分散を提供します。各リージョンにStandard Public Load Balancer（リージョン層）をデプロイし、それらのパブリックフロントエンドを単一のグローバルLoad Balancer（グローバル層）のバックエンドに配置します。グローバルLBは、各リージョンLBへのヘルスプローブを使用して、5タプルハッシュに基づいたフロー対称性により、クライアントを最も近い（レイテンシで）正常なリージョンに誘導します。これはTCP/UDPのみで、TLS終端はなく、リージョンL7ゲートウェイを補完します。

Application Gateway (L7) と Azure Front Door (グローバル L7)

Application Gatewayは、WAF機能を備えたリージョン単位のレイヤー7リバースプロキシです。HTTP/HTTPSを終端し、ヘッダーとパスを検査して、プライベートまたはパブリックのバックエンドにルーティングします。

Application Gatewayの主要な構成要素:

リスナー: フロントエンドのIP/ポート/ホスト名とSSL設定をバインドして、トラフィックを受け入れます。SNIにより、IPごとに複数のTLSサイトを有効にできます。単一サイトには基本リスナー、ホストベースのルーティングにはマルチサイトリスナー、広範なカバレッジにはワイルドカードホストを使用します。
ルーティング規則とHTTP設定: 規則はリスナーをバックエンドプールにマッピングし、バックエンドに適用されるHTTP設定（プロトコル、ポート、ホストヘッダーの上書き、Cookieベースのアフィニティ、接続のドレイン、リクエストタイムアウト）を指定します。URLパスセグメントに基づいて、リダイレクト、ヘッダーの書き換え、またはルーティングが可能です。
バックエンドプール: ターゲットには、NICのIP、FQDN、App Service、または仮想マシンスケールセットを指定できます。カスタム正常性プローブは、特定のパス/ホストをチェックし、成功ステータスコードを尊重します。
WAF: OWASP Core Rule Setベースの保護を、検出モードまたは防止モードで提供し、v2ではカスタムルール、除外リスト、ルートごとの関連付けが可能です。v2では自動スケーリングとゾーン冗長性がサポートされています。

高度なL7パターン:

URLパスベースのルーティング: /api/* をマイクロサービスに、/images/* を静的オリジンまたはCDNにルーティングし、1つのVIPの背後でマイクロサービスのファンアウトを可能にします。
マルチサイトホスティング: SNIリスナーとホストヘッダーベースのルールを使用して、1つのゲートウェイでcontoso.comとfabrikam.comをホストします。サイトごとのWAFポリシーによる強力な分離を伴う統合に役立ちます。
SSL終端: ゲートウェイでTLSをオフロードし、証明書の一元管理とWAFによる検査を実現します。バックエンドが暗号化やクライアント証明書の検証を必要とする場合は、エンドツーエンドTLS（再暗号化）を使用します。

Azure Front Doorは、anycast、split TCP、POPからオリジンへの最適化を利用して、エッジでのグローバルなHTTP/HTTPS負荷分散と高速化を提供します。グローバルルーティング、エッジWAF、およびオプションのエッジキャッシュを必要とするインターネット向けアプリに最適です。

グローバル負荷分散: 複数のPOPからの正常性プローブを使用して、ユーザーを最も低遅延で正常なオリジンにルーティングします。オリジングループは、優先度および待機時間ベースのフェイルオーバーをサポートし、必要に応じてセッションアフィニティも利用できます。
WAF: ボット保護付きのマネージドルール、カスタムルール、geo/IPフィルター、レート制限、およびルートごとの関連付けが可能です。
キャッシュ: Front Door Standard/Premiumでは、エッジキャッシュが統合されており、パスごとにキャッシュ動作を定義し、クエリストリングのキャッシュとTTLを制御し、静的コンテンツをグローバルにオフロードします。
正常性プローブ: オリジングループごとに、多様なPOPからパス、間隔、プロトコルを設定可能なプローブ（HTTP/HTTPS）を実行します。ルーティングの決定は、正常性と待機時間を組み合わせて行われます。

リージョン内のL7ニーズ（プライベートバックエンド、東西トラフィック、複雑な書き換え）にはApplication Gatewayを、グローバルなL7、エッジセキュリティ、高速化にはFront Doorを使用します。これらは一般的に組み合わせて使用されます。エッジにFront Door、各リージョンにApplication Gateway、そしてゲートウェイの背後にあるL4サービスのために内部LBを配置します。

Traffic Manager (DNSベース) と Azure CDN

Traffic Managerは、DNSベースのグローバルなトラフィック分散サービスです。トラフィックをプロキシするのではなく、ポリシーと正常性に基づいてエンドポイントのDNS名/IPを返し、クライアントが直接接続するようにします。正常性は、分散されたプローブからHTTP/HTTPS/TCPエンドポイントに対してチェックされます。TTLを低く設定するとフェイルオーバーの待機時間は短縮されますが、DNSクエリの量が増加します。

優先度: アクティブ/パッシブのフェイルオーバー。プライマリを最初に配置します。Traffic Managerは、それが異常でない限りプライマリを提供し、異常な場合は次の優先度のエンドポイントにフェイルオーバーします。
重み付け: 重みに応じて分散し、段階的な切り替えやA/Bテストをサポートします。
パフォーマンス: ユーザーのリージョンからエンドポイントまでのネットワーク待機時間が最も短いエンドポイントを選択します。
地理的: データ主権やコンテンツのローカライズのために、ユーザーの地理的な場所に基づいてルーティングします。
複数値: 同じサービスに対して複数の正常なエンドポイントを返し、単純なクライアント側のフェイルオーバーをサポートします。プロファイルをネストして、ハイブリッドなポリシー（例：最上位で地理的ルーティング、その中で重み付け）を作成できます。HTTP以外のプロトコル、エッジプロキシの恩恵を受けないサービス、または異種のエンドポイント（Azure、オンプレミス、サードパーティ）にまたがるDNSレイヤーでの制御が必要な場合にTraffic Managerを使用します。

Azure CDNは、静的およびキャッシュ可能なコンテンツをエッジPOPにオフロードして、オリジンの負荷と待機時間を削減します。

プロファイル: プロバイダー/レベル（例：Microsoft、Akamai、Verizonファミリー）に紐づけられた1つ以上のエンドポイントのコンテナーです。プロファイルは、環境やコストセンターを分離するのに役立ちます。
エンドポイント: オリジンの詳細（ホスト名、オリジンホストヘッダー、プロトコル/ポート）とエッジホスト名を定義します。異なるアプリやコンテンツタイプのために、プロファイルごとに複数のエンドポイントを持つことができます。
キャッシュ規則: 既定の規則とカスタム規則で、TTL、パスベースの動作、クエリストリングの処理（転送、無視、または一意のクエリごとにキャッシュ）、および圧縮を制御します。規則を使用して、オリジンのTTLが短いアセットのキャッシュを強制したり、動的APIのキャッシュをバイパスしたりします。
カスタムドメイン: CDNが管理するTLSを使用して、わかりやすいホスト名をマッピングします。CNAMEを介してドメインの所有権を検証し、マネージド証明書でHTTPSを有効にします。必要に応じて、geoフィルタリングやルールエンジンと組み合わせます。

設計上の選択、リージョン間統合、および正常性プローブの動作

内部ロードバランサーと外部ロードバランサーは、利用者とルートの公開範囲によって選択されます。利用者がプライベートネットワーク内に限定される場合は、パブリックへの公開を避け、NSGの制御を簡素化するために内部LBを使用します。インターネットユーザーやパートナー向けには、パブリックフロントエンドを使用します。大規模なアウトバウンド接続には、LBのSNATよりもNAT Gatewayを優先します。アウトバウンド規則は、LBのフロントエンドがSNATを提供する必要がある場合に限定して使用します。

Cross-region Load Balancerは、リージョンごとのStandard Public Load Balancerと統合し、TCP/UDPサービスに対してアクティブ/アクティブ構成のグローバルなレイヤー4の回復性を実現します。リージョンLBのパブリックフロントエンドを、グローバルLBのバックエンドプールに配置します。グローバル層での正常性プローブは、リージョンの可用性を反映します。ルーティングは最もレイテンシーの低い正常なリージョンに誘導され、リージョン全体（またはそのリージョンLB）が異常になった場合に自動的にフェイルオーバーします。別々のVIPのもとで両方のプロトコルサポート（例：cross-region LB経由のTCPサービスとFront Door経由のHTTP/S）が必要な場合は、これをFront Doorと組み合わせます。

正常性プローブはフェイルオーバーの判断基準となる情報源です。

TCPプローブ: あらゆるTCPサービスで機能します。3ウェイハンドシェイクが完了すると成功と見なされます。SQL、SMTP、またはカスタムTCPプロトコルに適しています。
HTTP/HTTPSプローブ: パスにリクエストを送信し、200～399の応答を期待することで、アプリケーションレベルの正常性を検証します。ホスト/パスのカスタマイズが可能で、部分的なアプリの障害を識別できます。HTTPSプローブはTLSネゴシエーションを検証しますが、ハンドシェイクを超える証明書の有効性は検証しません。仮想ホストで運用されるアプリには、正しいホストヘッダーを使用してください。
異常のしきい値: Azure Load Balancerは、N回の連続したプローブ失敗（構成可能。デフォルトの間隔はフェイルオーバーを高速化するために短く設定）の後、バックエンドをダウンとマークします。Application GatewayとFront Doorは複数の監視拠点からプローブを行い、プローブセット全体で十分な数の連続した失敗が蓄積された場合にオリジンをダウンと見なします。復旧には連続した成功が必要です。感度とフラッピングのバランスを取るために間隔としきい値を調整し、プローブが軽量で依存関係を認識するエンドポイントに到達するようにしてください。

実践的な問題シナリオ

Adobeは、Webフロントエンド、マイクロサービス、SQL Server Always On 可用性グループで構成されるマルチリージョンSaaSを、厳格なセキュリティ、高速なフェイルオーバー、世界中のユーザーに対する低レイテンシーを確保してグローバルに公開する必要があります。また、レガシーなTCPベースのテレメトリ取り込みサービスも公開しています。

エッジにAzure Front Door Standardを配置し、www.adobe.comとapi.adobe.com用のWAFポリシーとルートを設定します。オリジンはEast USとWest EuropeにあるApplication Gatewayで、これらを待機時間ベースのルーティングと優先順位フェイルオーバーでグループ化します。

理由: Front Doorは、グローバルエニーキャスト、エッジでのWAF、オプションのキャッシュ機能を提供し、インターネットのHTTP/Sトラフィックを高速化・保護します。最も近い正常なリージョンを自動的に選択します。

各リージョンにWAF付きのApplication Gateway v2を展開します。両方のホスト名に対応するSNIを使用したマルチサイトリスナー、マイクロサービスへのURLパスベースのルーティング、各サービスの/healthzへのカスタム正常性プローブを構成します。バックエンドホストをサービスFQDNにオーバーライドして、エンドツーエンドSSLを有効にします。

理由: Application Gatewayは、リージョン内でのL7ルーティング、アプリに近い場所でのWAF検査、パスベースのファンアウト、ルートごとのポリシーを提供します。プライベートバックエンドに安全に接続し、ヘッダーの書き換え/リダイレクトを処理します。

各リージョンに、SQL AGリスナー用の内部Standard Load Balancerを展開します。静的なプライベートフロントエンド、Windows Failover ClusterのプローブポートへのTCP正常性プローブ、リスナーポートへのFloating IPを有効にした負荷分散規則を構成します。

理由: SQLリスナーはDirect Server Return (DSR)を伴うL4を必要とします。Floating IPは宛先のセマンティクスを維持し、TCPプローブはAGの所有権を正確に反映します。これは、ポート1433でのHTTPプローブが無効であるという既知の要件を反映しています。

Webの静的アセットは、/static/*に対して長いTTLと再検証を設定したAzure Front Doorのキャッシュ規則でサポートします。また、downloads.adobe.comでの大規模なメディアダウンロード用に、パス固有のキャッシュとクエリ文字列のバリエーションを持つAzure CDNプロファイルとエンドポイントを立ち上げます。

理由: Front Doorのキャッシュは、エッジルーティングと連携してコアなWeb静的コンテンツのレイテンシーを削減します。一方、専用のCDNエンドポイントは、ダウンロード用の大規模オブジェクト配信とキャッシュポリシーの独立性を最適化します。

レガシーなTCPテレメトリ取り込みサービスを、各リージョンのStandard Public Load Balancer経由で公開し、それらを単一のパブリックVIPとしてCross-region Load Balancerでフロントに配置します。各リージョンLBへのグローバルプローブを構成し、待機時間ベースのルーティングを使用します。

理由: このサービスはHTTPではなくTCPです。Cross-region Load Balancerは、自動フェイルオーバーと低レイテンシーのリージョン選択を備えた、グローバルなアクティブ/アクティブL4を提供します。

Azureの外部でホストされている外部パートナーのSFTPエンドポイント専用に、優先度ポリシーを持つAzure Traffic Managerを追加し、パートナーのプライマリエンドポイントとAzureでホストされているバックアップエンドポイントをリストします。

理由: Traffic ManagerはDNSベースであり、外部エンドポイントを含めることができます。プロキシが望ましくない非HTTPおよびサードパーティのターゲットに対して、シンプルなアクティブ/パッシブのフェイルオーバーを提供します。

アプリサブネットからのアウトバウンド接続には、NAT Gatewayをアタッチし、LBのアウトバウンドSNATへの依存をなくします。Azure Monitorでプローブの結果とLB/App Gateway/Front Doorのメトリックを監視し、フラッピングを排除するためにプローブ間隔/異常のしきい値を調整します。