MS_ARR - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki

Application Request Routing (ARR)

概要

Microsoft Application Request Routing for IIS

HTTP ヘッダー、サーバー変数、および負荷分散アルゴリズムに基づいて
HTTP 要求をコンテンツ サーバーに転送するプロキシ ベースのルーティング モジュール

  • アプリケーションの可用性とスケーラビリティを向上させる。
  • コンテンツ サーバーのリソースを効果的に活用する。
  • パイロット管理および A/B テストを含め、アプリケーションの展開を容易にする。
  • 管理コストを削減し、共有ホストに機会を創出する。

負荷分散クラスタからフェイルオーバークラスタのクラスタリングが可能。

補足（NLBとの決定的な違い）: ARR は L7（アプリケーション層） で
動作する。NLBは L4（トランスポート層） である。

NLB ARR
層 L4（TCP/IP） L7（HTTP）
振り分けの根拠 送信元 IP のハッシュ URL・ヘッダー・Cookie
ヘルス チェック 無い（OS の生死のみ） ある（URL を叩いて判定）
SSL 終端 不可 可能
追加機能 － キャッシュ、書き換え、A/B テスト
単一障害点 無い ARR 自身がなる

NLBの最大の弱点だった
「アプリが落ちていても振り分け続ける」問題を ARR は解決できる。
ただし最後の行のとおり、ARR 自身が単一障害点になる
（後述の組み合わせで対処する）。

モジュール

ルーティングの決定を行うための受信 HTTP 要求の検査を
URL 書き換えモジュールに依存しているため、
ARR の機能を有効にするには URL 書き換えモジュール（URL Rewrite）が必要。

機能

HTTP に基づくルーティングの決定

  • ルーティングの決定がアプリケーション レベルで行われる。
  • URL 書き換えモジュールとの連携により、
    HTTP ヘッダーおよびサーバー変数に基づいて強力なルーティング規則を作成できる。

負荷分散アルゴリズム

アルゴリズム 分散の基準
ラウンド ロビンの重み付け 要求の数と標準化された重み
トラフィックの加重合計 要求と応答のバイト単位のサイズ
最小の要求 ARR と各サーバー間の現在の HTTP 要求数
最小限のレスポンスタイム 最も高速なサーバーからのレスポンス・タイム
サーバー変数のハッシュ サーバー変数のハッシュ値
クエリ文字列のハッシュ クエリ文字列の値のハッシュ値
要求のハッシュ サーバー変数または URL のハッシュ値

移行メモ（項目数）: 元ページは「6 つのアルゴリズムが提供される」と
記した上で 7 項目を列挙している。
実際の ARR が提供するのは上表の7 種類である。

健常性の監視

コンテンツ サーバーの健常性を判定する際に、

  • 現状のトラフィックと特定の URL テストの両方が使用される。
  • 使用しない場合、RSCA API を呼び出してサーバーの健常性を設定する
    カスタムの健常性監視プロバイダーを使用することもできる。

補足（ヘルス チェックの設計）: URL テストで叩く先には、
クラウド設計パターンの
「正常性エンドポイント監視」 を実装しておく。

// ASP.NET Core のヘルス チェック
builder.Services.AddHealthChecks()
    .AddSqlServer(connectionString)
    .AddUrlGroup(new Uri("https://api.example.com/health"));
app.MapHealthChecks("/health");

単に 200 を返すだけの静的ページではなく、
DB 接続や依存サービスまで確認することが重要である。
そうしないと「Web は生きているが DB が落ちている」ノードに
振り分け続けてしまう。

クライアント アフィニティ

Cookie を使用して、クライアントからコンテンツ サーバーへの
すべての要求をアフィニティ化。
これにより、NAT の背後にあるクライアントを識別し、各クライアントは個別に扱われる。

補足（NLB の弱点を補う）: NLBのアフィニティは
送信元 IP に基づくため、大企業のプロキシ配下では
全員が同じノードに寄ってしまう（偏りが発生する）。
ARR は Cookie を使うため、この問題が起きない。

ただし、そもそもセッションを外部化して
アフィニティを不要にする方が望ましい
（ASP.NET Sessionを参照）。

その他

  • ホスト名アフィニティ: 共有ホスト提供者向けの特別な機能。
  • 複数のサーバー グループ: 環境内のコンテンツ サーバーの論理グループを管理。
  • UI を使用した管理および監視: IIS マネージャーから管理・表示。
  • 失敗した要求トレース規則: トラブルシューティングおよび診断用のトレース。

クラスタの組合せ

高い可用性とスケーラビリティの実現 — ARR および NLB

ARR では、コンテンツ サーバーに対して高い可用性とスケーラビリティを
提供していますが、展開全体の可用性とスケーラビリティは高くありません。

これには、次の理由がある。

  • ARR は単一障害点である。
  • コンテンツ サーバーのスケーラビリティが、
    単一の ARR サーバーの最大容量によって制限されている。

上記の課題を克服するために、管理者は NLBと組み合わせた
複数の ARR サーバーの使用を検討することができる。

[クライアント]
      │
   [NLB]  ← ARR サーバー群を L4 で冗長化
   ├── [ARR #1] ─┐
   └── [ARR #2] ─┼─> [コンテンツ サーバー群]  ← ARR が L7 で振り分け
                 │
  • ARR は
    • アクティブ/パッシブモードで展開して、高可用性のみ実現できる。
    • アクティブ/アクティブモードで展開して、
      高い可用性とスケーラビリティの両方を実現できる。

補足（2 段構成になる理由）: 「L4 の NLBで ARR を束ね、
ARR が L7 で振り分ける」という 2 段構成は、
クラウドのロードバランサでも同じ形である。

層 オンプレ Azure
L4 NLB Azure Load Balancer
L7 ARR Application Gateway / Front Door

クラウドではこの 2 段構成がマネージドで提供されるため、
自分で組む必要が無い。
ARR を採用するのは、既存の IIS資産を活かしたい
オンプレ環境に限られてきている
（新規なら Nginx / HAProxy の方が情報も多い）。

参考

Tags: 移行, Windows, IIS, 冗長化

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

⚠️ **GitHub.com Fallback** ⚠️