Skip to content

MS_AzureGatewayAndLB

Jump to bottom
nishi_74322014 edited this page Sep 1, 2026 · 1 revision

AzureのGW / LB的なモノ。

概要

インバウンドをコントロールする系

  • GW：Gateway
  • LB：Load Balancer

アウトバウンドをコントロールする系はコチラ

詳細

主要なGW / LB

Azure Load Balancer

  • ILB(Internal Load Balancer)
  • ELB(External Load Balancer)

Azure Application Gateway

補足（この 2 つの使い分けが最初の判断）: Azure の負荷分散は
OSI 参照モデルのどの層で分散するかで選ぶ。

Load Balancer Application Gateway
層 L4（TCP / UDP） L7（HTTP / HTTPS）
分散の基準 5-tuple のハッシュ URL パス、ホスト名、ヘッダー
SSL 終端 できない できる（証明書を持てる）
Cookie アフィニティ 無し（IP ベースのみ） あり
WAF 無し あり（WAF SKU）
非 HTTP 扱える（SQL、SMTP 等） 扱えない
性能 非常に高い（パススルー） 処理が入る分だけ低い

判断は単純で、

  • HTTP(S) 以外（DB、独自プロトコル、SMTP） → Load Balancer
  • HTTP(S) で、パスによる振り分けや WAF が要る → Application Gateway
  • HTTP(S) だが単純に分散するだけ → どちらでも可（LB の方が安い）

なお、Load Balancer はパススルー（宛先 IP を書き換えるだけ）で
あるため、Network Security Group (NSG)で述べたとおり
NSG の宛先に LB の IP を書いても一致しない。

その他のGW / LB

Azure Traffic Manager

Azure API Management

補足（負荷分散サービスの全体像）: 本ページに挙がっているものを
範囲（グローバル / リージョン内）と層で整理すると、
4 つの象限に収まる。

L4（TCP/UDP） L7（HTTP/HTTPS）
グローバル Traffic Manager（DNS ベース） Azure Front Door
リージョン内 Load Balancer Application Gateway

Azure Front Door は本ページの執筆時点では
一般的でなかったが、現在は

  • CDN ＋ WAF ＋ グローバル負荷分散を兼ねる、
  • Anycast で最寄りのエッジに引き込む（Traffic Manager の DNS 方式より速い）

ため、インターネット公開の Web サービスでは第一候補になっている。

Traffic Manager が DNS ベースであることの限界も押さえておきたい。

制約 内容
DNS キャッシュ フェイル オーバーが TTL 分だけ遅れる
トラフィックは通らない 名前解決するだけ。通信内容には関与しない
正常性判定 プローブによる（切り替えに数十秒〜数分）

逆に、非 HTTP を含む任意のエンドポイントを
グローバルに振り分けられるのは Traffic Manager だけである。

兼務（アウトバウンド）

（Azureのプロキシ的なモノ。）

Azure Firewall

Network Security Group (NSG)

Azure Private Endpoint

AKSのGW / LB

AKSと言うか、K8s の GW / LB

Service

ゲートウェイ

Ingress

  • ロードバランサ機能を持つ。
  • WAF 機能を仲介して提供する。
    • Pod 側に構築した WAF の機能を使用する場合（nginx-ingress）
    • 外部サービスを使用する場合（Azure だと AGIC）
    • 上記 2 つの仲介の構成は、どちらも面倒なので、外に置いてしまうのも手。

補足（Kubernetes の Service と Ingress の関係）: 名前が独特なので
Azure のリソースとの対応を整理しておく。

K8s の概念 層 AKS での実体
Service (ClusterIP) L4 クラスタ内部のみ。実体なし（iptables / IPVS）
Service (LoadBalancer) L4 Azure Load Balancer が自動生成される
Ingress L7 Ingress コントローラー（nginx / AGIC 等）が必要

重要なのは、Ingress は「定義」でしかないという点である。
Ingress リソースを作っただけでは何も起きず、
Ingress コントローラーを別途デプロイして初めて機能する。

AKS での選択肢は主に 3 つある。

方式 実体 特徴
nginx-ingress Pod として動く K8s 内で完結。設定は K8s のマニフェスト
AGIC（App Gateway Ingress Controller） Application Gateway を操作する WAF が使える。Azure リソース側に設定が反映される
外に置く Front Door / App Gateway を手前に 本文の推奨。構成が単純

本文が「どちらも面倒なので、外に置いてしまうのも手」と述べるのは
実務的な判断である。理由は、

  • nginx-ingress：WAF を自前で維持する必要がある（ModSecurity 等）、
  • AGIC：K8s の状態と Azure リソースの同期が絡み、
    トラブル時の切り分けが難しい（どちらが正か分からなくなる）

ためで、「WAF は Azure 側、ルーティングは K8s 側」と
責務を分けてしまう方が運用は楽になる。
現在は Application Gateway for Containers が
AGIC の後継として提供されている。

パターン

FgCF

AKS

  • Deploy：通常通りだと、
    自動的に ELB(External Load Balancer) が出来てしまう。
  • 抑止する方法は以下のモノがある。
    • K8s のアドミッション・コントロール
    • Azure Policy for AKS（今後を予定）
  • 色々なパターンが考えられるが、以下のパターンがベターユース。
    全パターンで、ILB(Internal Load Balancer) を使用する。

補足（「自動的に ELB が出来てしまう」が閉域構成の落とし穴）: これは
AKS で閉域構成を組む際に必ず遭遇する問題である。

apiVersion: v1
kind: Service
spec:
  type: LoadBalancer   # ← これだけで

と書くと、AKS はパブリック IP を持つ Load Balancer を
勝手に作成する。閉域のつもりの環境が、
開発者のマニフェスト 1 行でインターネットに露出する。

防ぐ手段は次のとおり。

手段 内容
annotation で ILB を強制 後掲。ただし書き忘れたら意味が無い
Azure Policy for AKS クラスタ全体で type: LoadBalancer を禁止（Gatekeeper ベース）。本文の「今後を予定」は現在は一般提供済み
アドミッション コントロール OPA / Gatekeeper で自前のポリシー
アウトバウンド専用の LB を指定 クラスタ作成時の設定

人の注意力に頼らず、ポリシーで機械的に禁止するのが正しい。
本文が「今後を予定」としていた Azure Policy for AKS は
現在利用可能であり、これを使うべきである。

外部公開

VNET内部

オンプレミス

※ Azure Private Linkサービスを設定していると、
　Service を削除しようとしたときに ILB の消込が出来ないので、
　Azure Private Link サービスを削除してから、Service を削除する。

補足（3 パターンに共通する設計思想）: 3 つとも
**「Ingress は不要」「必ず ILB」**という結論になっている点が要点である。

【外部公開】  Internet → Application Gateway(WAF) → ILB → Service → Pod
【VNET 内部】             VNET 内の他 VM         → ILB → Service → Pod
【オンプレ】  オンプレ → Private Link → ILB → Service → Pod

つまり、

  • AKS クラスタ自体は常に閉じている（ILB のみ）、
  • 公開の可否は、その手前に何を置くかで決める

という構造になっている。
これにより、

利点 内容
一貫性 AKS 側の構成は 3 パターンで共通
責務の分離 WAF・SSL・認証は Azure 側、ルーティングは K8s 側
事故が起きにくい K8s のマニフェストから公開範囲を変えられない

前掲の「外に置いてしまうのも手」という判断が、
この 3 パターンでは設計原則として徹底されている。

なお、末尾の注意書き（Private Link サービスがあると ILB を消せない）は
依存関係の順序の問題である。
IaC で管理する場合も、削除の順序を明示する必要がある
（Azure Private Linkの「ILB は依存関係」）。

参考

Tags: 移行, インフラストラクチャ, クラウド, Azure, セキュリティ, 通信技術

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally