リバース プロキシ サーバーまたはロード バランサーは、通常、境界ネットワーク (DMZ (DeMilitarized Zone) またはスクリーン サブネットとも呼ばれる) 内に配置されるアプライアンスであり、インターネットからのリクエストを処理して内部ネットワーク内のコンピューターに転送します。 リバース プロキシ サーバーの代理としてリクエストを転送することで、組織サイトのファイアウォールの内側にあるコンピューターのアイデンティティをマスクするため、インターネット ユーザーによる直接的な攻撃から内部のコンピューターを保護できます。 さらに進んでユーザーの内部ネットワークを外部ユーザーから保護するために、追加のセキュリティ機能をリバース プロキシ サーバーに実装できます。
リバース プロキシ サーバーまたはロード バランサーが状態チェック機能に対応している場合は、Portal for ArcGIS の状態チェック エンド ポイントを使用して、ポータルがリクエストを受け取れるかどうかを確認できます。 これは、サイトでソフトウェアまたはハードウェアの障害があるかどうかを迅速に確認する場合に便利です。 詳細については、「状態チェック」をご参照ください。
注意:
このトピックで説明する構成は、ArcGIS Server サイトをポータルとフェデレートする前に実行する必要があります。 ArcGIS Server サイトがポータルとフェデレートされた後に DNS エイリアスまたはリバース プロキシを追加する操作はサポートされていません。 組織の URL のホスト名を変更する必要がある場合は、Esri Professional Services または別の信頼できるコンサルティング パートナーにお問い合わせください。
ArcGIS Server サイトのフェデレーションの解除は、いくつかの大きな影響をもたらします。また、これを簡単に元に戻すことはできません。 詳細については、「フェデレーション サーバーの管理」をご参照ください。
ロード バランサーのタイプ
リバース プロキシは、ロード バランサーと呼ばれることもありますが、一般的に、受信メッセージをバックエンド ターゲットに単に分散させる以上の機能を提供します。 多くのリバース プロキシ サーバー実装は、構成に応じて、下記のいずれかの最大容量で動作できます。
多くの場合、負荷分散の操作は、操作が属する開放型システム間相互接続 (OSI) モデルの階層 (レイヤー) によって区別されます。 既存のロード バランサー テクノロジの統合に取り組んでいる場合は、どのタイプが実装されているかを識別することが重要です。ロード バランサーのタイプは配置のアーキテクチャ全体に影響を及ぼすためです。
レイヤー 3/4 ロード バランサーはネットワーク ロード バランサーまたはパケット レベル ロード バランサーと呼ばれることもあります。 この種のロード バランサーは、通常、受信トラフィックを調査することなく、受信した TCP/UDP パケットをバックエンド ターゲットにルーティングします。 新しい実装では、ロード バランサーでの SSL ターミネーションが可能になっていますが、クライアント SSL セッションは、一般にバックエンド ターゲット サーバーで確立されます。
レイヤー 7 ロード バランサーはアプリケーション ロード バランサーまたはアプリケーション対応ロード バランサーと呼ばれることもあります。 この種のロード バランサーは、受信メッセージを調査し、複数の要因に基づいてルーティングを決定できるほか、これらのメッセージの内容を修正してから、メッセージをバックエンド ターゲットにプロキシできます。 HTTPS を使用するレイヤー 7 ロード バランサーは、クライアントとの SSL 通信を終了し、そのトラフィックを再暗号化してから、リクエストをバックエンド HTTPS ターゲットにプロキシします。
リバース プロキシ サーバーまたはロード バランサーの準備
組織のリバース プロキシ サーバーに Portal for ArcGIS を追加する前に、次の操作を完了する必要があります。
- リバース プロキシ サーバーに HTTPS (HTTP および HTTPS、または HTTPS のみ) を構成します。 Portal for ArcGIS は、デフォルトで通信に HTTPS を使用します。 プロキシ サーバーの製品マニュアルで、HTTPS の設定方法を確認してください。
- ポータルで統合 Windows 認証を使用する場合、ArcGIS Web Adaptor をポータルに構成します。 このため、Portal for ArcGIS では ArcGIS Web Adaptor を使用する必要があります。これを使用することにより、リバース プロキシ サーバーがポータルと正常に通信できるようになります。 詳細な手順については、「ArcGIS Web Adaptor の構成」をご参照ください。
注意:
Portal for ArcGIS は、リバース プロキシ サーバー/ロード バランサーを通じた SSL オフロードをサポートしていません。 したがって、リバース プロキシ サーバーが構成で使用されている場合、HTTPS を介してトラフィックを ArcGIS Web Adaptor に転送するか、Portal for ArcGIS に直接転送する必要があります。
注意:
リバース プロキシ サーバーのコンテキスト名は 1 階層だけ下の URL レベルでなければなりません。 たとえば、https://proxy.domain.com/enterprise などのリバース プロキシの URL は使用できますが、https://proxy.domain.com/myorg/enterprise などのリバース プロキシの URL は使用できません。
プロキシ サーバーが gzip エンコーディングをサポートしていることと、Accept-Encoding ヘッダーを許可するように構成されていることを確認します。 このヘッダーによって、gzip エンコーディングを使用して HTTP 1.1 の応答を圧縮できるようになります。 たとえば、このヘッダーが許可されている場合、Map Viewer Classicを読み込むリクエストは、約 1.4 MB の圧縮された応答をブラウザーに返します。 このヘッダーが許可されていない場合や無視されている場合、リクエストは約 6.8 MB の圧縮されていない応答をブラウザーに返します。 ネットワーク速度が遅い場合、応答が圧縮されていないとMap Viewer Classicを読み込むのに時間がかかる可能性があります。 リバース プロキシ サーバー構成の一部として、このヘッダーを許可することをお勧めします。
レイヤー 3/4 ロード バランサー
このロード バランサーは、デフォルトの HTTPS ポートをリッスンして、トラフィックを ArcGIS Web Adaptor に渡すか、ポート 7443 の Portal for ArcGIS コンピューターに直接渡します。 Portal for ArcGIS の内部 Web サーバーでクライアント SSL セッションを終了するときは、証明書の信頼性の問題を避けるために、その Web サーバーで提示された SSL 証明書が、サイトのコンピューターの DNS エイリアスと FQDN の両方で有効であることを確認してください。 これを実行するには、通常、SSL 証明書のサブジェクトの別名を使用します。
注意:
ArcGIS Web Adaptor を使用していない場合は、サイトのデフォルトのコンテキスト (/arcgis) を使用する必要があります。 複数の Portal for ArcGIS および ArcGIS Server サイトを同じレイヤー 3/4 ロード バランサーで統合する場合は、サイトごとに固有の DNS レコードを使用する必要があり、SNI (Server Name Indication) を使用して、トラフィックを適切なバックエンド ターゲットにルーティングする必要があります。
レイヤー 7 ロード バランサー
このロード バランサー構成では、X-Forwarded-Host ヘッダーをサイトの DNS エイリアスのホスト名に設定する必要があります。 Portal for ArcGIS は、リバース プロキシ サーバーから送信されるヘッダー内に設定されているこのプロパティを確認して、リバース プロキシ サーバーの URL に一致するリクエストを返します。 ポータルで ArcGIS Web Adaptor を使用しない場合は、ロード バランサーによって設定された Host ヘッダーと、Portal for ArcGIS がインストールされたコンピューターのホスト名が一致することを確認します。
ヒント:
Portal Administrator Directory の machines エンドポイントを使用して、Portal for ArcGIS を実行しているコンピューターのホスト名を表示できます。
たとえば、ArcGIS Portal Directory (https://dnsalias.domain.com/arcgis/sharing/rest) に対するリクエストは、同じ URL としてクライアントに返されます。 このプロパティが設定されていない場合、Portal for ArcGIS は、リクエストが転送された内部コンピューターの URL を返すことがあります (たとえば、https://dnsalias.domain.com/arcgis/sharing/rest ではなく https://portal.domain.com/arcgis/sharing/rest)。 このような場合は、クライアントがこの URL にアクセスできなくなる (一般的に、ブラウザーの 404 エラーとして知られている) ため、問題が起こりがちになります。 また、これによって、内部コンピューターについての一部の情報へのアクセス権限がクライアントに付与されます。
ロード バランサーは、X-Forwarded-Host ヘッダーとともに、リダイレクト (HTTP 応答コード 301 または 302) を指示できる必要があります。 すべての Location ヘッダーをロード バランサーで書き換えて、応答の完全修飾ドメイン名 (FQDN) とコンテキストを、ポータルの WebContextURL 値と一致させる必要があります。
ポータルの追加
以下のセクションでは、Portal for ArcGIS を組織のリバース プロキシ サーバーに追加する方法について説明します。
レイヤー 3/4 ロード バランサー: ArcGIS Web Adaptor または Portal for ArcGIS コンピューターをロード バランサー構成に追加
バックエンド ターゲットへのトラフィックのプロキシは TCP を介して実行されるため、各サイトのコンピューターをロード バランサー構成に追加する必要があります。 ArcGIS Web Adaptor を使用している場合は、バックエンド ターゲットが Web Adaptor をホストしている Web サーバーのポート (通常 443 または 8443) をポイントする必要があります。 トラフィックを Portal for ArcGIS へ直接プロキシする場合は、バックエンド ターゲットがサイトの各コンピューター上のポート 7443 をポイントする必要があります。
レイヤー 7 ロード バランサー: ArcGIS Web Adaptor または Portal for ArcGIS コンピューターをプロキシ サーバー ディレクティブに追加
ArcGIS Web Adaptor を Portal for ArcGIS で構成した後、ArcGIS Web Adaptor を組織サイトのリバース プロキシ サーバーで使用するには、これらのコンポーネントをプロキシ サーバー ディレクティブに直接追加します。 たとえば、リバース プロキシとして Apache を使用している場合は、Apache Web サーバー構成ファイルの httpd.conf で、ProxyPass ディレクティブに ArcGIS Web Adaptor を追加する必要があります。
ProxyPass /webadaptorname https://webadaptorhost.domain.com/webadaptorname
ProxyPassReverse /webadaptorname https://webadaptorhost.domain.com/webadaptornameProxyPass ディレクティブは ArcGIS Web Adaptor に対して指定された名前と一致する必要があります (上の例では /webadaptorname)。 Portal for ArcGIS の前に ArcGIS Web Adaptor を使用していない場合は、/context が選択した最上位レベルの URL パスである次のディレクティブを追加します。
ProxyPass /context https://portal.domain.com:7443/arcgis
ProxyPassReverse /context https://portal.domain.com:7443/arcgisリバース プロキシまたはロード バランサーを使用するためのポータルの構成
以下のセクションでは、リバース プロキシ サーバーの URL を使用するようにポータルを構成する方法と、URL の構成後にやり直す必要がある管理タスクについて説明します。
WebContextURL プロパティの設定
ポータルは、WebContextURL プロパティにより、すべてのリソースで正しい URL を構築して、エンド ユーザーに送信することができます。 次の手順で、WebContextURL を変更します。
- Web ブラウザーを開き、組織のデフォルトの管理者ロールのメンバーとして、Portal Administrator Directory にサイン インします。 URL の形式は、https://portal.domain.com:7443/arcgis/portaladmin です。
- [System] > [Properties] > [Update Properties] の順にクリックします。
- [Update System Properties] ダイアログ ボックスに次の JSON を挿入し、ユーザーが組織のファイアウォールの外部から参照する際に使用する独自のリバース プロキシ サーバーまたは DNS エイリアス URL に置き換えてください。
{ "WebContextURL": "https://dnsalias.domain.com/portal" }注意:
Portal for ArcGIS がサポートする DNS は 1 つだけです。
注意:
WebContextURL プロパティを設定するときに、標準でないポート (443 以外のポート) は使用できません。
- [Update Properties] をクリックします。
管理タスクのやり直し
ポータルでリバース プロキシ サーバーの構成が完了した後は、ArcGIS Web Adaptor の URL の代わりに、リバース プロキシ サーバーの URL を介してポータルにアクセスします。 ポータルまたは Portal Administrator Directory にアクセスした場合、必ずリバース プロキシ サーバーの URL が返されます。
リバース プロキシ サーバーの URL を使用し、次の管理タスクをやり直す必要があります。
以前に、セキュリティで保護されたサービスをアイテムとしてポータルに追加している場合、元のアイテムを削除して、それらを再び追加する必要があります。 これは、元のアイテムが、リバース プロキシ サーバーの URL ではなく ArcGIS Web Adaptor の URL を使用しているためです。 手順については、「セキュリティで保護されたサービスへの接続」をご参照ください。
リバース プロキシ サーバーをポータルで構成したら、設定の調整が必要になることがあります。 たとえば、配置内での操作やリクエストが失敗し、接続がタイム アウトしたことを示すエラーが表示された場合、リバース プロキシ サーバーのタイムアウト値が短すぎることが問題である可能性があります。 このエラーを修正するには、サーバーのフェデレートなど、実行に時間がかかるリクエストが完了できるように、タイムアウト値を増やすことを検討します。