ロード バランサーとリバース プロキシー

ロード バランサーとリバース プロキシーは、どちらも最新の Web ベースのアプリケーションやアーキテクチャーで一般的なテクノロジーであり、単独でデプロイすることも、組み合わせて構成することもできます。 このセクションでは、これらのテクノロジーの概要と、ArcGIS システムに関連するユース ケースに加え、これらのテクノロジーが提供する関連機能について説明します。

• ロード バランサーとは、一般的に、クライアント リクエストやワークロードを複数のコンピューティング リソース (物理サーバー、仮想サーバー、クラスターなど) に分散するハードウェアまたはソフトウェア コンポーネントを指します。 負荷分散は、システム使用率のバランスを取り、リスクを軽減し、サービスの提供と成長を円滑にし、バックエンド サーバーのセキュリティーを強化するのに役立ちます。
• リバース プロキシーは、外部クライアントなどからの HTTPS リクエストを受け入れ、それらのリクエストを適切な内部リソース、URL、またはサービスにルーティングするソフトウェアまたはハードウェア コンポーネントです。 リバース プロキシーは、ある URL に到着した外部リクエストを、別の内部 URL またはシステム (他の方法では外部クライアントはアクセスできない) にルーティングするためによく使用されます。 リバース プロキシーは、既知のフロントエンド ネットワーク ポートのトラフィック (ポート 443 への HTTPS リクエストなど) を、バックエンド システム上の他のプライベート ポートに転送するためにもよく使われます。 リバース プロキシーは、リクエストを行うクライアントと、そのリクエストに応答するバックエンド サーバーとの間に、セキュリティー、不明確化、場合によってはリクエスト フィルター ロジックのレイヤーを確保します。

実装パターン

多くの ArcGIS システムでは、リバース プロキシーの使用と併せて負荷分散が実装されています。 一般的な実装パターンには、次のものがあります。

• ArcGIS Enterprise ポータルやフェデレートされた ArcGIS Server サイト (例: ArcGIS Image Server、Workflow Manager Server) など、ArcGIS Enterprise のユーザー向けコンポーネントに送信されるクライアント リクエストを負荷分散する
• Web アプリケーションの HTML、JavaScript、CSS リソースなどの静的アプリケーション コンテンツに対するユーザー リクエストを、複数の Web サーバー間で負荷分散する
• HTTPS 経由で受信され、ポート 443 に送信されるリクエストを、ポート 6443 で HTTPS リクエストを待機しているバックエンド サービス (ArcGIS Server など) に負荷分散する

Esri は、ArcGIS Enterprise のデプロイメントで負荷分散とリバース プロキシー機能を提供するために、インストール可能な ArcGIS ソフトウェア コンポーネントである ArcGIS Web Adaptor を提供しています。 Web Adaptor は、ロード バランサーとリバース プロキシーを使用する ArcGIS Enterprise システムを構築するための唯一の方法ではないものの、一般的なパターンとして使われており、Esri テクニカル サポートがサポートするソリューションを提供します。 外部ハードウェアまたはソフトウェアのロード バランサーも、好みや技術的な要件に応じて使用できます。 ワークロードのタイプと要求の頻度によって、ニーズに適したロード バランサーの種類がわかります。 特定の ArcGIS バージョンとオペレーティング システムに関連するガイダンスについては、「サードパーティ製ロード バランサーを使用した複数コンピューターの配置」をご参照ください。

高可用性構成を実現するには、Web Adaptor を高可用性サイト内の 1 台のコンピューターで構成して、サイト内の他のコンピューターを検出し、そのステータスを監視して、それらのコンピューターが正常な場合にリクエストを転送するロジックが含まれています。 このロジックは、ArcGIS Web Adaptor をシステム設計に組み込む際の実装上の大きな利点です。それは、手動で構成したヘルス チェックやロード バランサーの設定よりも、ArcGIS Enterprise デプロイメントに対する変更の方がより簡単に処理できるからです。

外部実装

Web Adaptor は、多くのシナリオで負荷分散とリバース プロキシー機能を提供できますが、ArcGIS で構築された多くのエンタープライズ システムでは、これら 2 つのテクノロジーの機能目標を達成するために、追加の外部ソフトウェアまたはハードウェア コンポーネントも実装しています。 例を以下に示します。

• Apache Tomcat、Apache httpd、Nginx などの Web サーバー ソフトウェアを使用して、クライアントからのプロキシー リクエストを ArcGIS エンドポイントにリバースする。
• Azure Application Gateway、Amazon Elastic Load Balancer または Application Load Balancer、Google Cloud Load Balancer などのクラウドネイティブ ロード バランサーを使用する。
• その他の専用の負荷分散およびプロキシー システム (F5 BIG-IP、Citrix NetScaler、Barracuda など) のほとんどは、さまざまなアプリケーションに負荷分散やリバース プロキシー サービスを提供するハードウェア アプライアンスであり、認証、侵入検知、Web アプリケーション ファイアウォールのような機能や、その他のユース ケースのサポートも提供します。

従来のオンプレミス アーキテクチャーでは、DMZ (非武装地帯) を利用してインターネットベースのクライアントにサービスやエンドポイントへのアクセスを提供していましたが、今はクラウド アーキテクチャーに移行しつつあります。クラウド アーキテクチャーでは、クラウドネイティブのサービスがこの機能を提供することがほとんどで、リバース プロキシーや負荷分散に伴う考慮事項やアーキテクチャーの実践も変化しています。

メリット

これらのテクノロジーには、スケーラビリティー、高可用性、セキュリティーなどの利点があります。

スケーラビリティ

ArcGIS システムは、大小のデプロイメントの両方をサポートするように拡張できます。 デプロイメントの規模の拡大に対応するために、ArcGIS では多くの負荷分散手法とテクノロジーを活用できます。 クライアント リクエストのディスパッチに使用される負荷分散アルゴリズムは、単純なラウンドロビン方式から、現在の接続数、ホスト使用率、実際の応答時間などの要素を考慮したより複雑なアルゴリズムまで、さまざまなものがあります。

ロード バランサーは、複数のコンピューターと適切なリソースに負荷を分散することで、パフォーマンスの向上に貢献します。 高可用性の例では、ArcGIS Web Adaptor のロード バランサーが 2 つの ArcGIS Enterprise ホスティング サーバー間で GIS サーバーのリクエストを分散します。 システムに多数のユーザーがいて、大量の処理を必要とする類似のワークフローを実行している場合 (プロセッサーに負荷がかかる、長時間にわたる処理を必要とする編集ワークフローなど)、ロード バランサーを使うことで、利用可能なハードウェア全体にこれらのリクエストをバランスよく分散させることができます。一方で、処理要件が大きく変動するワークフローでは、負荷分散ではなくワークロードの分離の方がメリットがある場合があります。

高可用性

負荷分散は、同じロールを共有するサイトまたはコンピューターのクラスター全体にリクエストを分散させることで、ArcGIS の高可用性構成も可能にします。 たとえば、複数のコンピューターの ArcGIS Enterprise デプロイメントで高可用性が構成されている場合、ロード バランサー (ArcGIS Web Adaptor) は、以下の図に示すように、プライマリー ArcGIS ホスティング サーバーとセカンダリー ArcGIS ホスティング サーバーにリクエストを交互に送信します。

この場合のリバース プロキシーは、単一のエントリー ポイント、つまりエンド ユーザーからシステムをわかりにくくする単一の IP アドレスを提供します リバース プロキシーは、アルゴリズムに従ってトラフィックを ArcGIS Web Adaptor に転送します。アルゴリズムは通常はラウンド ロビンですが、より堅牢な方式も使用できます。 ArcGIS Web Adaptor と同様に、多くのロード バランサーはサーバーの状態や可用性を監視し、問題のあるコンピューターや利用できないコンピューターを配布リストから削除して、システムに耐障害性を与えます。

この機能の方法と効率は、ロード バランサーによって異なります。 一部のハードウェア ロード バランサーは、負荷や応答時間に応じてその場で調整できる豊富なアルゴリズムを備えています。 また、単純なラウンド ロビン リストで動作するものもあります。ラウンド ロビン方式では、正常なコンピューターのみを反映するよう、定期的にリストが更新できます。

セキュリティーの強化

リバース プロキシーは通常、特定のシステムのインターネットまたはイントラネットに単一の IP アドレスを公開し、リクエストを適切なリソースに分散します。 これにより、ネットワークとシステムの内部トポロジーが隠され、攻撃が発生した場合に侵入ポイントの数が減少するため、セキュリティー リスクが大幅に軽減されます。 また、この方法では、システムへの単一のアクセス ポイントを提供することで、サービスの提供と利用も簡素化されます。 ほとんどの組織が、サイトが直接クライアントに公開されないようにするためにプロキシー サーバーを設定します。

リバース プロキシー サーバーは、ArcGIS Server と直接通信するように構成することも、プロキシー ディレクティブに対応する URL を追加することで ArcGIS Web Adaptor を介して通信するように構成することもできます。

詳細については、「ArcGIS Server でのリバース プロキシー サーバーの構成」をご参照ください。

考慮事項と推奨事項

負荷分散とリバース プロキシーの実装に関する一般的な推奨事項は次のとおりです。

• 負荷分散を実装して、クライアント ワークロードのトラフィックを複数のコンピューティング リソースに分散し、ArcGIS のスケーラビリティーと高可用性を実現します。
• ほとんどの ArcGIS Enterprise デプロイメントでは、ArcGIS Web Adaptor は推奨されるアーキテクチャー コンポーネントで、多くの場合は必須となります。このコンポーネントは、デプロイしやすい 1 つのアプリケーションでロード バランサーとリバース プロキシーの両方の機能を提供します。 ArcGIS Web Adaptor は、ArcGIS Enterprise の Web 層認証を実装するための簡単な手段も提供します。
• 高度な負荷分散要件がある場合は、ArcGIS Web Adaptor に加えて、必要な機能を提供する外部ロード バランサーの実装を検討してください。
• 一般公開用のシステムをデプロイする場合は、対応するリバース プロキシーを使用して、ArcGIS デプロイメントのセキュリティーを強化します。

負荷分散に関する推奨事項

ArcGIS システムで負荷分散テクノロジーを実装する場合は、次の戦略を検討してください。

• ArcGIS ソフトウェア コンポーネントには、さまざまな「状態チェック」URL が含まれています。これは、サーバーをロード バランサーの「ターゲット プール」に保持するかどうかを識別するために、ほとんどのロード バランサーから送信される状態チェック リクエストで使われます。healthCheck リクエストは、システムが適切に実行され、リクエストを受信できる場合にのみ、肯定的に応答する必要があります。
• ほとんどのロード バランサーは、利用可能なバックエンドのプール内のサーバーに、ランダムにリクエストを送信するラウンドロビン モードなど、複数の異なるモードで動作できます。 より「インテリジェント」なその他の負荷分散アプローチでは、リクエストの種類やサイズ、コンピューティングやネットワーク トラフィックに基づくサーバーの負荷、その他の要因が考慮される場合があります。
• ユーザー リクエストがサーバーに与える影響を理解することは、複雑で主観的なテーマとなることがあります。 通常のラウンド ロビン方式から逸脱する場合は、よりインテリジェントな負荷分散アプローチの利点を慎重に検討してください。
• セッション スティッキネスは、同じユーザー (ロード バランサーが認識する) からのリクエストが同じサーバーに送信されるようにするために、ソース IP アドレスまたはクライアント Cookie のいずれかを使用する一般的なロード バランサー設定です。 この機能は、複数のサイロ化された ArcGIS Server サイトまたは機能が同じロード バランサーの背後に配置されているシナリオにおいて便利です。また、ユーザー リクエストが同じサーバーに返されるようにすると、機能面とパフォーマンス面でメリットがあります。

リバース プロキシーの推奨事項

ほとんどのリバース プロキシーはロード バランサーの一部として実装されます。これは、多くのロード バランサーが、フロントエンド リクエストの発信元とは異なるバックエンド ポートまたはサービスにリクエストを送信するためです。 リバース プロキシーを実装する場合 (ロード バランサーと併用する場合、またはロード バランサーとは別に実装する場合) は、次の設計上の推奨事項を考慮してください。

• 一貫性のある URL を使用します。 ArcGIS システムは、アプリケーション、マップ、サービスなどのコンテンツが、アイテム、サービス、またはその他のコンポーネントへの URL を使用してシステムの一部を参照する、自己参照性の高いシステムです。 これらの URL は構成に保存されるため、一貫性のある URL を使用することで、システムの安定性とコンテンツの移植性が向上します。 システムの外部 URL を変更することは、現在のソフトウェアではサポートされていない、破壊的プロセスです。

• 一部のリバース プロキシーでは、複数の URL パーツを使用して ArcGIS システムを参照することがデフォルトとなっている場合があります。例:

  • https://centralhost.domain.com/systems/gis/rest/services

このようなマルチパート URL の使用は、ArcGIS Enterprise コンポーネントではサポートされていないことに注意してください。「Web コンテキスト」または Web Adaptor 名は、URL のホスト名に続く最初の URL コンポーネントでなくてはなりません。

• ArcGIS は、リクエストが検査や認証または検証のレイヤーを介さずにバックエンドに送信される、透過的なリバース プロキシー構成で効果的に機能します。 トラフィックをインターセプト、調整する、またはトラフィックに影響を与える他のリバース プロキシー方式は、ArcGIS システムに機能的およびパフォーマンス上の問題を引き起こす可能性があるため、実装する前に慎重に検討する必要があります。