高可用性とスケーラビリティの実現 - ARR とハードウェア ロード バランサー
作成者: Won Yoo
高可用性とスケーラビリティの実現:
IIS 7.0 以降向けの Microsoft アプリケーション要求ルーティング処理 (ARR) とハードウェア ロード バランサー。
| Microsoft Corporation | F5 |
|---|---|
| 作成者: Won Yoo | 作成者: Ryan Korock |
| 公開日: 2008 年 11 月 13 日 |
要約
このドキュメントでは、高可用性とスケーラビリティを実現するために、アプリケーション要求ルーティング処理 (ARR) をハードウェア ロード バランサーと共に使用する方法に関する規範的なガイダンスを提供します。 このドキュメントのおいては、F5 BIG-IP ロード バランサーを使用して、ARR とハードウェア ロード バランサーの間の動作関係を示します。
概要
IIS 7.0 以降用 Microsoft アプリケーション要求ルーティング処理 (ARR) は、HTTP ヘッダー、サーバー変数、および負荷分散アルゴリズムに基づいて、コンテンツ サーバーに HTTP 要求を転送するプロキシ ベースのルーティング処理モジュールです。 次の図は、一般的な ARR の展開を示したものです。
ARR はコンテンツ サーバーの高可用性とスケーラビリティを提供しますが、次の理由で展開全体の可用性とスケーラビリティは高くありません。
- ARR が単一障害点になります。
- コンテンツ サーバーのスケーラビリティは、1 台の ARR サーバーの最大容量が上限となります。
これらの課題を克服するために、管理者は F5 BIG-IP などのハードウェア ロード バランサーで複数の ARR サーバーを使用することを検討できます。 ARR は、アクティブ/パッシブ モードで展開して高可用性のみを実現することも、アクティブ/アクティブ モードで展開して高可用性とスケーラビリティの両方を実現することもできます。 このホワイトペーパーでは、ARR と F5 BIG-IP を一緒に展開して、ARR のコア シナリオを実現しながら、全体的な高可用性とスケーラビリティを実現する方法について説明します。
アプリケーション要求ルーティング処理と F5 BIG-IP の使用
ARR は IIS の上にモジュールとして構築され、レイヤー 7 (アプリケーション) でルーティングの決定を行うように設計されています。 もっと正確に言えば、ARR は別の IIS モジュール (URL 書き換え) を利用し、受信 HTTP 要求のヘッダーとサーバー変数を検査してルーティングの決定を行います。 この設計を踏まえ、管理者は、次のようなアプリケーション レベルの情報に基づいてインテリジェントなルーティング規則を記述できます。
- ホスト名 (HTTP_HOST): ホスト名に基づいて異なるコンテンツ サーバーにトラフィックをルーティングします。
- 要求されたリソース (URL): ファイル拡張子に基づいて、要求されたリソースの対象が静的コンテンツであるか動的コンテンツであるかを判断し、それに応じて要求をルーティングします。
- クライアント情報 (HTTP_USER_AGENT): ブラウザーの種類とバージョンに基づいて、要求を適切なコンテンツ サーバーにルーティングします。
- カスタム ヘッダー (アプリケーションが Cookie として設定): ユーザー設定やユーザー ID など、アプリケーションによって設定された Cookie 情報に基づいてトラフィックをルーティングします。
上記は例の一部に過ぎません。 HTTP ヘッダーとサーバー変数の完全な一覧については、「付録 A」を参照してください。
F5 Big-IP のレイヤー 3 とレイヤー 4 の機能は、HTTP ヘッダーやサーバー変数など、レイヤー 7 に基づいてルーティングの決定を行う際の ARR の強度を補完します。 それに加えて、ARR 自体はフォールト トレラントな展開機能を備えていないため、ARR 層の高可用性を実現するには、以下に示すように、他の補完的なテクノロジやソリューションを利用する必要があります。
シナリオ 1: HTTP ベースのルーティングと負荷分散
HTTP ベースのルーティングと負荷分散のシナリオでは、次のような 3 層展開アーキテクチャが可能になります。
- 第 1 層 (Web): 静的コンテンツを処理すると共に、それ以外の動的要求を第 2 層サーバーにルーティングして負荷分散するという 2 つの目的を果たします。
- 第 2 層 (アプリケーション): ビジネス ロジックを利用する動的コンテンツを処理します。
- 第 3 層 (データ): データを格納します。
この 3 層展開の図を次に示します。
上の例は、静的コンテンツと動的コンテンツを区別するルーティング規則を示していますが、プレゼンテーション要求と Web サービス要求を区別するシナリオも一般的です。
オプション 1: アクティブ/パッシブ
アクティブ/パッシブ モードでは、通常、2 台の ARR サーバーがあり、一方のサーバーが要求を処理し、もう一方のサーバーはフェールオーバー サーバーとして待機します。 前述のように、この構成は単一障害点をなくすことで高可用性を実現しますが、コンテンツ サーバーの集計容量は 1 台の ARR サーバーの最大容量が上限となるため、スケールアウト ソリューションではありません。
このセットアップでは、2 台の ARR サーバーが同じ方法で構成されるため、共有構成が使用されます。 F5 BIG-IP は、すべての要求をアクティブな ARR サーバーにルーティングし、必要な場合にのみパッシブ ARR サーバーに要求をルーティングするように構成されます。
ARR のホスト名アフィニティ機能を除き、2 台の ARR サーバー間で共有する必要があるランタイム状態情報はありません。 そのため、このシナリオでは、ARR サーバーでも F5 BIG-IP でも特別な構成は必要ありません。 ARR でサーバー アフィニティ機能を使用する場合でも、アフィニタイズされた状態情報は、要求ヘッダーの Cookie を介してパッシブ サーバーで利用できるようになります (F5 BIG-IP によって、以前はパッシブだったがアクティブになったサーバーに要求がルーティングされる場合)。
このシナリオは、ARR バージョン 1 リリースで完全にサポートされます。
ARR の構成
手順 1: 2 台の ARR サーバーで共有構成を有効にします。
- こちらのドキュメントの手順に従って、IIS に共有構成を設定します。
手順 2: ARR を使用して 3 層展開アーキテクチャを構成します。
こちらのドキュメントの手順に従って、3 層展開アーキテクチャで ARR を構成します。
前述のドキュメントの概要は、次のとおりです。
- ARR サーバーで静的コンテンツを使用できるようにする方法。
- 静的コンテンツが ARR サーバーから直接提供されるように URL 書き換え規則を記述する方法。
- 動的コンテンツがアプリケーション サーバーに転送されるように URL 書き換えルールを記述する方法。
F5 BIG-IP の構成
このシナリオでは、2 つ (またはそれ以上) の ARR サーバーのプールに負荷分散する仮想サーバーを作成します。 選択する負荷分散方法は、プライマリ ARR サーバーにすべてのトラフィックを送信する必要がありますが、これはこのサーバーが利用できなくなるまでです。 その時点で、BIG-IP LTM はすべてのトラフィックをセカンダリ ARR サーバーに送信する必要があります。
手順 1: ARR サーバーのプールを構成します。
- [Local Traffic]\(ローカル トラフィック\) セクションで、[プール] をクリックします。 次に、[作成] ボタンをクリックして、プールを作成します。
- プールには、一意の名前が有効です。この例では、ARR_Pool を使用します。
- ヘルス モニターには、カスタム HTTP モニターまたは既定の HTTP モニターを使用できます。
- [負荷分散方法] は、[ラウンド ロビン] に設定したままで構いません。 このシナリオでは、アクティブかつパッシブな 1 台の ARR サーバーのみが存在するため、負荷分散は使用されません。
- 必ず、優先度グループのアクティブ化を有効にしてください。 これにより、優先度の値が最も高いサーバーにトラフィックを送信するように BIG-IP が構成されます。 これらのサーバーが利用できない場合、BIG-IP は、優先度の値が次に高い ARR サーバーにトラフィックを送信します。
- このシナリオでは、10.0.0.1 の ARR サーバーの優先度値は 1、10.0.0.2 の優先度値は 2 です。 すべてのトラフィックは 10.0.0.2 に送信され、それがダウンすると、トラフィックは 10.0.0.1 に送信されます。
手順 2: ARR サーバーのプールを構成します。
- [Local Traffic]\(ローカル トラフィック\) セクションで、[Virtual Servers]\(仮想サーバー\) をクリックします。 次に、[作成] ボタンをクリックして、仮想サーバーを作成します。
- 仮想サーバーには、一意の名前が有効です。この例では、ARR_VS を使用します。
- 宛先には、ユーザーがブラウザーに指示する IP アドレスを使用できます。 この特定の例では、65.197.145.23 を使用します。 サービス ポートには、「80」を使用します。
- 仮想サーバーの種類のセクションには、いくつかのオプションがあります。 ルーティングする ARR に依存しているため、最適なパフォーマンスを実現するために設計された [Performance HTTP]\(パフォーマンス HTTP\) を選択できます。
- [既定のプール] では、手順 1 で作成したプールを選択します。
- この時点で、この仮想サーバーに接続できるはずです。これにより、適切な ARR サーバーに送信されます。
オプション 2: アクティブ/アクティブ
アクティブ/アクティブ モードでは、2 台以上の ARR サーバーを使用できます。 この構成は、高可用性のみを実現するアクティブ/パッシブ モードとは異なり、高可用性とスケーラビリティの両方を実現します。 前述のように、複数の ARR サーバーが同じ方法で構成されるため、共有構成が使用されます。 F5 BIG-IP は、使用可能で正常な ARR サーバーすべてに受信要求を負荷分散するように構成されます。結果として、この ARR サーバーは要求をコンテンツ サーバーに転送します。 サーバー アフィニティ機能が F5 BIG-IP で使用されているかどうかに関係なく、ARR サーバーに対して特別な構成は必要ありません。 まず、ARR サーバーは同じ方法で構成されるため、1 つの共有構成を使用します。 また、ARR はクライアントの Cookie を使用して、独自の使用目的でサーバー アフィニティ情報を格納します。そのため、この情報は要求ごとに使用できるので、ARR サーバーをまたがって使用できます。 このシナリオは、ARR バージョン 1 リリースで完全にサポートされます。
ARR の構成
アクティブ/アクティブの ARR 構成は、アクティブ/パッシブの場合と同じです。 主な違いは、F5 の構成方法です。
手順 1: 2 台の ARR サーバーで共有構成を有効にします。
- こちらのドキュメントの手順に従って、IIS に共有構成を設定します。
手順 2: ARR を使用して 3 層展開アーキテクチャを構成します。
こちらのドキュメントの手順に従って、3 層展開アーキテクチャで ARR を構成します。
前述のドキュメントの概要は、次のとおりです。
- ARR サーバーで静的コンテンツを使用できるようにする方法。
- 静的コンテンツが ARR サーバーから直接提供されるように URL 書き換え規則を記述する方法。
- 動的コンテンツがアプリケーション サーバーに転送されるように URL 書き換えルールを記述する方法。
F5 BIG-IP の構成
このシナリオでは、使用可能なすべての ARR サーバーがアクティブであり、負荷分散されるトラフィックの候補であると見なされます。 BIG-IP LTM を使用して ARR フロントエンドの正常性とパフォーマンスを判断し、最もパフォーマンスが良いものにトラフィックを送信します。
手順 1: ARR サーバーのプールを構成します。
- [Local Traffic]\(ローカル トラフィック\) セクションで、[プール] をクリックします。 次に、[作成] ボタンをクリックして、プールを作成します。
- プールには、一意の名前が有効です。例では、ARR_Pool を使用します。 - ヘルス モニターには、カスタム HTTP モニターまたは既定の HTTP モニターを使用できます。 - トラフィックの分散先となる ARR サーバーが複数あるため、ニーズに最も適した負荷分散方法を選択する必要があります。 すべての ARR サーバーのハードウェア特性が似ていると仮定すると、最速、観測、予測などの動的負荷分散方法を使用すると、パフォーマンスベースの分散が実現します。
手順 2: 仮想サーバーを構成します。
- [Local Traffic]\(ローカル トラフィック\) セクションで、[Virtual Servers]\(仮想サーバー\) をクリックします。 次に、[作成] ボタンをクリックして、仮想サーバーを作成します。
- 仮想サーバーには、一意の名前が有効です。この例では、ARR_VS を使用します。 - 宛先には、ユーザーがブラウザーに指示する IP アドレスを使用できます。 この特定の例では、65.197.145.23 を使用します。 サービス ポートには、「80」を使用します。 - 仮想サーバーの種類のセクションには、いくつかのオプションがあります。 ルーティングする ARR に依存しているため、最適なパフォーマンスを実現するために設計された [Performance HTTP]\(パフォーマンス HTTP\) を選択できます。 - [既定のプール] では、手順 1 で作成したプールを選択します。
シナリオ 2: ホスト名アフィニティを使用した共有ホスティング
このシナリオでは、ARR のホスト名アフィニティ機能を利用して、共有ホスティング展開を有効にします。これにより、次のような効果があります。
- 従来の共有ホスティング展開に伴う手動での管理とメンテナンスの手間が軽減します。
- すべてのサーバー リソースが均等に利用されるようにしながら、既存のサーバー リソースを最大限に活用します。
- 環境を簡単にスケールアウトします。
- 追加容量を販売するビジネス機会が得られます。
共有ホスティングと ARR の詳細については、こちらのドキュメントを参照してください。
次の図は、ARR を使用した共有ホスティング環境を示しています: 
オプション 1: アクティブ/パッシブ
前述のように、アクティブ/パッシブ モードでは、通常、2 台の ARR サーバーがあり、一方のサーバーが要求を処理し、もう一方のサーバーはフェールオーバー サーバーとして待機します。 この構成は単一障害点をなくすことで高可用性を実現しますが、コンテンツ サーバーの集計容量は 1 台の ARR サーバーの最大容量が上限となるため、スケールアウト ソリューションではありません。
このセットアップでは、2 台の ARR サーバーが同じ方法で構成されるため、共有構成が使用されます。 F5 BIG-IP は、すべての要求をアクティブな ARR サーバーにルーティングし、必要な場合にのみパッシブ ARR サーバーに要求をルーティングするように構成されます。
ARR のホスト名アフィニティ機能は、ホスト名に基づいて特定のサーバー (または RC 内のサーバーのグループ) に対する要求をアフィニタイズします。 ホスト名とコンテンツ サーバー間のアフィニタイズ済みマッピングのランタイム状態情報は、ARR サーバーのインスタンス内のメモリに格納されます。 ARR バージョン 1 リリースでは、複数の ARR サーバー間でこのランタイム状態を共有および維持するために、IIS 用の Microsoft External Cache が利用されます。 このシナリオの詳細は、こちらのドキュメントでご覧いただけます。
このシナリオは、ARR バージョン 1 リリースで完全にサポートされます。
ARR の構成
手順 1: 2 台の ARR サーバーで共有構成を有効にします。
- こちらのドキュメントの手順に従って、IIS に共有構成を設定します。
手順 2: ARR を使用して 3 層展開アーキテクチャを構成します。
こちらのドキュメントの手順に従って、3 層展開アーキテクチャで ARR を構成します。
前述のドキュメントの概要は、次のとおりです。
- ARR サーバーで静的コンテンツを使用できるようにする方法。
- 静的コンテンツが ARR サーバーから直接提供されるように URL 書き換え規則を記述する方法。
- 動的コンテンツがアプリケーション サーバーに転送されるように URL 書き換えルールを記述する方法。
手順 3: 外部キャッシュを有効にして構成します。
- こちらのドキュメントの手順に従って、ARR で使用する外部キャッシュを有効にし、構成します。
F5 BIG-IP の構成
このシナリオでは、2 つ (またはそれ以上) の ARR サーバーのプールに負荷分散する仮想サーバーを作成します。 選択する負荷分散方法は、プライマリ ARR サーバーにすべてのトラフィックを送信する必要がありますが、これはこのサーバーが利用できなくなるまでです。 その時点で、BIG-IP LTM はすべてのトラフィックをセカンダリ ARR サーバーに送信する必要があります。
手順 1: ARR サーバーのプールを構成します。
- [Local Traffic]\(ローカル トラフィック\) セクションで、[プール] をクリックします。 次に、[作成] ボタンをクリックして、プールを作成します。
- プールには、一意の名前が有効です。この例では、ARR_Pool を使用します。 - ヘルス モニターには、カスタム HTTP モニターまたは既定の HTTP モニターを使用できます。 - [負荷分散方法] は、[ラウンド ロビン] に設定したままで構いません。 このシナリオでは、アクティブかつパッシブな 1 台の ARR サーバーのみが存在するため、負荷分散は使用されません。 - 必ず、優先度グループのアクティブ化を有効にしてください。 これにより、優先度の値が最も高いサーバーにトラフィックを送信するように BIG-IP が構成されます。 これらのサーバーが利用できない場合、BIG-IP は、優先度の値が次に高い ARR サーバーにトラフィックを送信します。 - このシナリオでは、10.0.0.1 の ARR サーバーの優先度値は 1、10.0.0.2 の優先度値は 2 です。 すべてのトラフィックは 10.0.0.2 に送信され、それがダウンすると、トラフィックは 10.0.0.1 に送信されます。
手順 2: 仮想サーバーを構成します。
- [Local Traffic]\(ローカル トラフィック\) セクションで、[Virtual Servers]\(仮想サーバー\) をクリックします。 次に、[作成] ボタンをクリックして、仮想サーバーを作成します。
- 仮想サーバーには、一意の名前が有効です。この例では、ARR_VS を使用します。 - 宛先には、ユーザーがブラウザーに指示する IP アドレスを使用できます。 この例では、 を使用します。 サービス ポートには、「80」を使用します。 - 仮想サーバーの種類のセクションには、いくつかのオプションがあります。 ルーティングする ARR に依存しているため、最適なパフォーマンスを実現するために設計された [Performance HTTP]\(パフォーマンス HTTP\) を選択できます。 - [既定のプール] では、手順 1 で作成したプールを選択します。
- この時点で、この仮想サーバーに接続できるはずです。これにより、適切な ARR サーバーに送信されます。
オプション 2: ARR のアクティブ/アクティブ
アクティブ/アクティブ モードでは、2 台以上の ARR サーバーを使用できます。 この構成は、高可用性のみを実現するアクティブ/パッシブ モードとは異なり、高可用性とスケーラビリティの両方を実現します。 複数の ARR サーバーが同じ方法で構成されるため、共有構成が使用されます。 F5 BIG-IP は、使用可能で正常な ARR サーバーすべてに受信要求を負荷分散するように構成されます。結果として、この ARR サーバーは要求をコンテンツ サーバーに転送します。
前述のように、ホスト名とコンテンツ サーバー間のアフィニタイズ済みマッピングのランタイム状態情報は、ARR サーバーのインスタンス内のメモリに格納されます。 この情報を複数の ARR サーバー間で共有するために、IIS 用の Microsoft External Cache が使用されます。 外部キャッシュの詳細については、こちらのドキュメントを参照してください。
ARR の構成
アクティブ/アクティブの ARR 構成は、アクティブ/パッシブの場合と同じです。 主な違いは、F5 の構成方法です。
手順 1: 2 台の ARR サーバーで共有構成を有効にします。
- こちらのドキュメントの手順に従って、IIS に共有構成を設定します。
手順 2: ARR を使用して 3 層展開アーキテクチャを構成します。
こちらのドキュメントの手順に従って、3 層展開アーキテクチャで ARR を構成します。
前述のドキュメントの概要は、次のとおりです。
- ARR サーバーで静的コンテンツを使用できるようにする方法。
- 静的コンテンツが ARR サーバーから直接提供されるように URL 書き換え規則を記述する方法。
- 動的コンテンツがアプリケーション サーバーに転送されるように URL 書き換えルールを記述する方法。
手順 3: 外部キャッシュを有効にして構成します。
- こちらのドキュメントの手順に従って、ARR で使用する外部キャッシュを有効にし、構成します。
F5 BIG-IP の構成
このシナリオでは、使用可能なすべての ARR サーバーがアクティブであり、負荷分散されるトラフィックの候補であると見なされます。 BIG-IP LTM を使用して ARR フロントエンドの正常性とパフォーマンスを判断し、最もパフォーマンスが良いものにトラフィックを送信します。
手順 1: ARR サーバーのプールを構成します。
- [Local Traffic]\(ローカル トラフィック\) セクションで、[プール] をクリックします。 次に、[作成] ボタンをクリックして、プールを作成します。
- プールには、一意の名前が有効です。この例では、ARR_Pool を使用します。 - ヘルス モニターには、カスタム HTTP モニターまたは既定の HTTP モニターを使用できます。 - トラフィックの分散先となる ARR サーバーが複数あるため、ニーズに最も適した負荷分散方法を選択する必要があります。 すべての ARR サーバーのハードウェア特性が似ていると仮定すると、最速、観測、予測などの動的負荷分散方法を使用すると、パフォーマンスベースの分散が実現します。
手順 2: 仮想サーバーを構成します。
- [Local Traffic]\(ローカル トラフィック\) セクションで、[Virtual Servers]\(仮想サーバー\) をクリックします。 次に、[作成] ボタンをクリックして、仮想サーバーを作成します。
- 仮想サーバーには、一意の名前が有効です。この例では、ARR_VS を使用します。 - 宛先には、ユーザーがブラウザーに指示する IP アドレスを使用できます。 この例では、 を使用します。 サービス ポートには、「80」を使用します。 - 仮想サーバーの種類のセクションには、いくつかのオプションがあります。 ルーティングする ARR に依存しているため、最適なパフォーマンスを実現するために設計された [Performance HTTP]\(パフォーマンス HTTP\) を選択できます。 - [既定のプール] では、手順 1 で作成したプールを選択します。
まとめ
このホワイト ペーパーでは、複数の ARR サーバーを展開して F5 BIG-IP を使用することで高可用性とスケーラビリティを実現する、2 つの主要な ARR シナリオを確認しました。
付録
付録 A: ルーティング決定規則の記述に使用できるすべての HTTP ヘッダーとサーバー変数。
| ALL_HTTP | ALL_RAW | APPL_MD_PATH |
|---|---|---|
| APPL_PHYSICAL_PATH | CERT_COOKIE | CERT_FLAGS |
| CERT_ISSUER | CERT_KEYSIZE | CERT_SECRETKEYSIZE |
| CERT_SERIALNUMBER | CERT_SERVER_ISSUER | CERT_SERVER_SUBJECT |
| CERT_SUBJECT | CONTENT_LENGTH | CONTENT_TYPE |
| DOCUMENT_ROOT | GATEWAY_INTERFACE | HTTP_ACCEPT |
| HTTP_ACCEPT_ENCODING | HTTP_ACCEPT_LANGUAGE | HTTP_CONNECTION |
| HTTP_CONTENT_LENGTH | HTTP_HOST | HTTP_IF_MODIFIED_SINCE |
| HTTP_IF_NONE_MATCH | HTTP_REFERER | HTTP_UA_CPU |
| HTTP_USER_AGENT | HTTPS | HTTPS_KEYSIZE |
| HTTPS_SECRETKEYSIZE | HTTPS_SERVER_ISSUER | HTTPS_SERVER_SUBJECT |
| INSTANCE_ID | INSTANCE_META_PATH | LOCAL_ADDR |
| PATH_INFO | PATH_TRANSLATED | QUERY_STRING |
| REMOTE_ADDR | REMOTE_HOST | REMOTE_PORT |
| REMOTE_USER | REQUEST_FILENAME | REQUEST_METHOD |
| REQUEST_URI | SCRIPT_FILENAME | SCRIPT_NAME |
| SERVER_ADDR | SERVER_NAME | SERVER_PORT |
| SERVER_PORT_SECURE | SERVER_PROTOCOL | SERVER_SOFTWARE |
| URL |
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示