目次
はじめに
ArcGIS Enterprise の高可用性を確保するための負荷分散設定の計画を立てることは、組織にとって重要な要件です。例えば、99％ 以上のシステムのアップタイムを必要とする場合があります。
高可用性 (HA) は、災害復旧 (DR) と関連していますが、別々の概念です。一般的に、HA はサービス提供の停止時間を回避することに焦点を当てており、一方、DR は災害後にシステムを以前の受け入れ可能な状態に復元するために必要なデータとリソースの保持に焦点を当てています。
この記事では、高可用性を確保するために単一の場所でローカル負荷分散設定 (Local Traffic Manager、LTM) を行う際のベストプラクティスに焦点を当て、異なる場所間での自動フェール オーバーのためのグローバルトラフィックマネージャ (GTM) の設定については考慮しません。
高可用性を実現するためには、冗長化と負荷分散を通じて単一障害点を減らす必要があります。
ロード バランサーはリバース プロキシとして機能し、トラフィックをバック エンドサーバーに分散します。高可用性の ArcGIS Enterprise 展開では、サードパーティのロード バランサーが必要です。これにより、ソフトウェアの容量と信頼性が向上します。ロード バランサーは、ポータルとサーバーサイトへのクライアント トラフィック、およびソフトウェア コンポーネント間の内部トラフィックを処理します。
ArcGIS Web Adapter
ArcGIS Web Adaptor はロード バランサーと見なされていますが、高可用性展開において単独のロード バランサーとしては不十分です。なぜなら、ArcGIS Web Adaptor 自体も高可用性を実現するためには冗長性が必要だからです。
ArcGIS Web Adaptor はオプションのコンポーネントです。ロード バランサーは直接ポータルとサーバーサイトにリクエストを転送できるため、ArcGIS Web Adaptor は必須ではありませんが、運用環境によっては推奨されるコンポーネントです。Web アダプタの利点は以下の通りです。
- システムの単一の URL を簡単に設定する方法を提供します。
- ポータル、サーバー、マッピングなど、異なるシステムコンポーネントのコンテキスト名を選択できます。
- 他の ArcGIS Enterprise ソフトウェア コンポーネントであるポータルとサーバーサイトとネイティブに統合されており、ヘルスチェックや構成タスク (例：サーバー サイトへの新しいマシンの追加) を自動的に処理します。
Web Context URL
Web コンテキスト URL はポータルの公開 URL です。ポータル内のすべてのアイテム (ファイル、レイヤー、マップ、アプリなど) には URL がありますので、ポータルの WebContextURL プロパティは、エンド ユーザーに送信するすべてのリソースの正しい URL を構築するのに役立ちます。
外部アクセスと DNS
ArcGIS Enterprise ポータルは、公開ポータル URL (Web コンテキスト URL) に対して 1 つの DNS のみをサポートしており、現在は管理タスクをやり直すことなく Web コンテキスト URL を変更する方法はサポートされていません。たとえば、サーバーサイトをポータルにフェデレーションするなどの管理タスクをやり直す必要があります。ArcGIS Enterprise が外部アクセスを必要とする場合 (モバイルユーザーや契約業者、パートナー、機関へのアクセスを VPN なしで許可する必要がある場合)、または将来的に外部アクセスを許可する必要がある場合は、ポータルのWeb コンテキスト URL に外部から解決可能な DNS 名 (例：https://gis.company.com/portal) を使用する必要があります。
ArcGIS Enterprise への外部アクセスをセキュアにするためには、通常、DMZ にロード バランサーをホストし、Split Domain Name System (Split DNS) を実装します。つまり、ArcGIS Enterprise の内部アクセス用 DNS (例：gis.company.com) は内部のロードバランサーの IP に解決されるため、内部ユーザーはファイアウォールの内側にとどまり、ArcGIS Enterprise の外部アクセス用 DNS は外部 (DMZ) のロードバランサーの IP に解決されます。
フェデレーションで使用される URL
高可用性のある ArcGIS Enterprise 展開では、いくつかの異なる URL が使用されます。
サービス URL
これはユーザーとクライアント アプリケーションが ArcGIS Server サイトにアクセスするために使用する URL です。これは ArcGIS Server トラフィックを処理し、リクエストをサーバーサイトの Web アダプタまたは直接サーバーマシンに渡すロード バランサーの URL です。
管理 URL
この URL は管理者が使用し、ポータル内部でも使用され、管理操作を実行するために ArcGIS Server サイトにアクセスするために使用されます。この URL は、登録されたデータストア（たとえば SQL Server エンタープライズジオデータベース）を参照して GIS サービスを公開する際にも使用されます。この URL はロード バランサーに向ける必要があります。管理用 URL がサーバー サイトの単一のマシンを指しており、そのマシンがオフラインの場合、フェデレーションは機能しません。この URL はサービス URL と同じであるか、またはポート 6443 を介して各フェデレーションサーバーサイトの管理者 URL のための 2 番目のロード バランサー (VIP) となることができます。ポート 6443 を介した各フェデレーション サーバーサイトの管理者 URL に専用の VIP を設定するには、管理者とパブリッシャーのためにこのポートを開放する必要があり、また、Web アダプタを通じた管理アクセスを無効にすることで、組織に追加のセキュリティコントロールを提供することができます。
設定を簡略化するため、サービス URL と同じ URL を使用することを推奨します。ArcGIS Server の管理アクセスは、ArcGIS Enterprise の認証およびユーザー ロールによって制御されます。これは、ArcGIS Portal Directory (portaladmin) や組織設定など、ポータルへの管理アクセスと同様です。管理 URL に Web アダプタの URL を使用するには、サーバー Web アダプタで管理アクセスを有効にする必要があります。
プライベートポータル URL
これは、サーバーサイトがポータルと通信するために使用する内部 URL です。これもロードバランサーに向ける必要があり、フェデレーションする前に定義する必要があります。privatePortalURL を設定する前にサーバーサイトをフェデレーションする場合は、既存の展開を高可用性に設定するトピックのステップ 8 および 9 に従ってデプロイメント内の URL を更新してください。管理 URL と同様に、これはポータルの公開 URL (ポータルの Web コンテキスト URL) と同じであるか、またはポート 7443 を介した 2 番目のロードバランサー (VIP) であることができます。
設定の簡略化のために、プライベート ポータル URL にはポータルの公開URLを使用することをおすすめします。プライベートポータルURLに専用のロードバランサーVIPを使用する場合は、ロードバランサーにポータルマシンのヘルスチェックを設定する必要があります。
ロードバランサーの設定
ヘルスチェックの設定
最も重要な機能はヘルスチェックを使用することです。ポータルのヘルスチェックのドキュメントに記載されているように、以下の手順で実施します。
「ヘルスチェックは、応答しているPortal for ArcGISマシンがリクエストを受信および処理できるかどうかを報告します。たとえば、ポータルを作成する前に、ヘルスチェックの URL ではサイトが利用できないと報告されます。その時点ではリクエストを受け付けることができないためです。」
ArcGIS Enterprise のポータルとサーバーには、ヘルスチェックがあります。
ArcGIS Web Adaptors を使用する場合、Web アダプタはポータルとサーバーに対してヘルスチェックを実行します。この場合、ロード バランサーを基本的な TCP / 443 ヘルスチェックまたは静的ページのヘルスチェックと構成できます。タイムアウト、障害トリガ、ポーリング間隔、および正常なしきい値に関する標準的なヘルスチェック設定があります。
ロード バランサーを設定して、直接ポータルやサーバーにアクセスする場合、たとえばアーキテクチャに Web アダプタを含めない場合や、プライベートポータル URL (ポート 7443) またはフェデレートサーバー管理 URL (ポート6443) に専用のロード バランサー URLを使用する場合、ロード バランサーを設定してポータルとサーバーマシンのヘルスチェックを行う必要があります。
ロード バランサーのヘルスチェック設定にはいくつか重要な考慮事項があります。ロード バランサーを使用する多くの組織では、ウェブサーバーが正常であるかどうかを判断するために静的なページ (たとえばindex.html) をヘルスチェックとして使用しています。これはディスクのフェッチのみを必要とする静的なファイルです。また、ほとんどのウェブサーバーは CPU よりも I/O でボトルネックになる傾向があります。
ただし、Esri の ArcGIS Server は異なります。私たちのヘルスチェックはディスクのフェッチだけではなく、特定のプロセスが正常に動作しているかどうかを判断する必要があるため、非常に少量の CPU を必要とします。
ヘルスチェックでは、ポーリングのタイムアウト値があります。ほとんどのロード バランサーの管理者は、ディスクのフェッチは通常非常に速いため (ただし、ネットワークの遅延がある場合に備えていくらかのバッファを残すことがあります)、タイムアウト値を非常に低く設定します。
ArcGIS Server を使用し、低いタイムアウト値を設定して複数のマシンを使用する場合、低いタイムアウト値を超える可能性があり、正常なマシンが削除される可能性があります。
Esri は、できれば最低でも 5 秒以上の高いタイムアウト値を推奨しています。システムによっては、さらにこの値を増やす必要があるかもしれません。環境を監視し、この値を適切に調整する必要があります。これは、通常のヘルスチェックが通常 10ms 未満（ネットワークの遅延を含む）で完了するため、ネットワーク管理者には高い数値に見えるかもしれません。
ただし、ロード バランサーが、マシンが単に遅いのか、本当に停止して応答しないのかを区別することは重要です。ポータルやサーバーが本当にダウンしており、ポートに対してまったくリスニングしていない場合、ほとんどのロード バランサーは 5 秒よりも早くこれを検出します。したがって、このタイムアウトは、マシンが消えるような「通常の」障害には影響しません。
2 番目の考慮事項は、フェイルトリガーです。つまり、何回のポーリングの失敗後にマシンをロード バランサーから削除するかです。
通常、ネットワーク管理者は、システムをダウンさせないために、1 回の障害ではなく複数回の障害が発生するまでフェイルトリガーを設定します。前述のように、ArcGIS Server システムでは CPU 使用率のわずかな上昇 (これは一般的です) がタイムアウトを引き起こすことがあり、単一の CPU スパイクによって単一のマシンがダウンすることは望ましくありません。
Esri はロード バランサーに関して重要な内部テストを実施し、5 回の障害を設定することで、誤検知の数を劇的に減らしながら本当の障害を検出することができることを確認しました。3 回の設定では誤検知のリスクが非常に高いことがわかりました。
3 番目の考慮事項はポーリング間隔です。Esri は、30 秒のポーリング間隔と 5 回の障害設定が、真の障害を検出し、誤検知を無視するための最適な設定であることを見つけました。
この組み合わせでは、検出までの期待値（統計用語で言うところの平均検出時間）は、1 分 15 秒のダウンタイムで検出されることになり、最悪の場合は 2 分 30 秒かかります。検出までの平均時間を短縮することも可能ですが、その場合は誤検知が増えるというトレードオフがあります。
もし検出までの平均時間を短縮することが望まれるなら、十分なリソースを確保するために容量を増やす必要があります。これにより、マシンの真の障害や誤検知による負荷が残りのマシンに過負荷をかけることなく処理できるようになります。 健康チェックに関する最後の設定は、ロード バランサーが再びリクエストを送信し始めるためのヘルシーしきい値です。Esri ではこれについての推奨事項はありませんし、この数値による大きな違いも観察されていませんが、通常は連続して 3 回の正常なポーリングがあれば再接続されることが多いです。
スロットリング
スロットリングとは、システムの過負荷や特定利用者による資源の独占を回避するため、一定の制限値を超えた場合に意図的に性能を低下させたり、要求を拒否したりする制御のことです。
スロットリング設定は検討する価値があります。ArcGIS Server は CPU に制約されており、リクエストのほとんどの時間は I/O を待つのではなく、CPU を使用して処理されます。
これは、もし 8 つのコアがある場合、ArcGIS Server は実際的な観点から 8 以上の同時リクエストを処理できることを意味します。ArcGIS Server が忙しい場合、リクエストをキューに入れて、数百のリクエストが待ち状態になるまで処理を待ちます。そのしきい値を超えると、接続を拒否します。リクエストのバックログが長くなると、長い待ち時間が発生しますが、最終的にリクエストは処理されます。
ArcGIS Server には、この動作を制御するための設定があります。これにより、処理が行われていない放棄されたリクエストが少なくなります。ただし、スロットル機能を使用してロード バランサーレベルでこれを制御することもベストプラクティスです。
Esriは数値的な推奨事項を持っていません。それは特定のアーキテクチャと受信するリクエストの種類に大きく依存するためです。ただし、通常は Web サーバーに比べてかなり低い値でスロットル処理を行うことが一般的です。
これはネットワーク管理者の制御を超えたものですが、クライアント アプリケーションはスロットリングイベントに対応し、再試行を行うように設計する必要があります。再試行間隔を徐々に増やす形で (たとえば、最初の試行ではすぐに再試行し、2 回目の試行では 1 秒待ち、3 回目の試行では 5 秒待ちなど)、処理を行うようにしてください。
スティッキー セッション
Esri は、非常に稀なケースを除いて、スティッキー セッションを推奨していません。スティッキー セッションは理論的にはマシンを過負荷にする可能性があります。Esri はスティッキー セッションを使用して負荷テストを行い、GIS サーバーを過負荷にする結果は得られなかったと確認しています。また、お客様からの苦情も受けていません。ただし、当社のソフトウェアはステートレスであるため、スティッキー セッションの使用には価値がないと考えています。
レイヤー 4 vs レイヤー 7
最後に述べるべき設定は、ロード バランサーが「レベル 7」アプローチまたは「レイヤー 4」アプローチを行うかどうかです。これはネットワーク管理者の間で議論されることがありますが、以下にはそれぞれの違いと利点を簡潔にまとめた状況の説明があります。
レイヤー 7 のロード バランサーは、HTTP と HTTPS を理解するため、HTTPS のコンテンツを復号化してから再度暗号化します。HTTP と HTTPS を理解しているため、コンテンツをキャッシュし、バックエンド サーバーへのリクエストを節約することができます。
一方、レイヤー 4 のロード バランサーは、すべてのトラフィックを TCP パケットとして見るため、パケットの意味を理解しません。それは FTP、HTTPS、SMTP のどれかであっても問題ではありません。したがって、HTTP のペイロードを理解する必要がなく、より高速に動作することができます。
ArcGIS Server は、どちらのアプローチでも動作することができます。ネットワーク管理者に対してこの設定に関して推奨はありませんが、管理者が把握しておく必要がある情報がいくつかあります。
ArcGIS Server のペイロードは、HTML ページや CSS、JS コンテンツよりもはるかに大きくなる場合があります (実際の量は有用ですが、顧客が使用するデータに依存することが多いです)。そのため、レイヤー 7 のロード バランサーはリクエストごとに複合化と暗号化を行うため、より多くの CPU 負荷がかかります。
また、ArcGIS Server のデータの大部分は動的で頻繁に変更されるため、デフォルトではキャッシュ ヘッダーがクライアントとロード バランサーでキャッシュを禁止しています。データがあまり変更されず、顧客がレイヤー 7 のロード バランサーを使用したい場合は、これらのキャッシュ設定を変更して制御することができます。
推奨事項のサマリ
ヘルスチェック
ArcGIS Web Adaptors を使用してロードバランサーを設定する場合、基本的な TCP / 443 のヘルスチェックやウェブサーバーに対する静的なページのヘルスチェックをロードバランサーに設定することができます。
ポータルおよび/またはサーバーに直接アクセスするためにロードバランサーを設定する場合（ポート 6443 および 7443 を介して）、HTTPS のヘルスチェックエンドポイントを使用してください。
Portal リクエスト
https:////portaladmin/healthCheck?f=json
または、https://:7443/arcgis/portaladmin/healthCheck?f=json
リスポンス：{“status”:”success”}
Server リクエスト
https:////rest/info/healthCheck?f=json
または、https://:6443/arcgis/rest/info/healthCheck?f=json
リスポンス：{“success”:true}
ヘルスチェックのタイムアウト値を高めに設定し、少なくとも 5 秒にしてください。
障害トリガの値としては、5 を使用してください。
30 秒のポーリング間隔を使用してください。
再接続する前に、3 回連続で正常なポーリングを行ってください。
スロットリング
通常の Web サーバーと比較して、より低い値でスロットリング設定を使用してください。
スティッキー セッション
スティッキー セッションは使用しないでください。
証明書
ArcGIS Enterprise のコンポーネントは、自己証明書のサーバー証明書で事前に設定されています。これにより、ソフトウェアを初めてテストし、インストールが成功したことを素早く確認することができます。ただし、ほとんどの場合、組織は信頼された証明書機関 (CA) から証明書を要求し、ソフトウェアをそれに設定する必要があります。証明書は、企業 (内部) または商用の CA によって署名されることができます。商用の CA (既知の CA) は、外部で解決可能な DNS (たとえば、ロード バランサーの VIP DNS) に使用する必要があります。内部ドメイン証明書は、内部サーバーに使用することができます。
外部で解決可能な DNS を持つ ArcGIS Enterprise システムの場合、ロード バランサーの SSL メソッドが SSL パススルー (ロードバランサーが https コンテンツを復号化および再暗号化しない) である場合、証明書は必要ありません。代わりに、商用の CA 証明書をマップされたサーバー (たとえば、Web アダプタがインストールされている Web サーバー) にインストールする必要があります。ロード バランサーの SSL メソッドが SSL 再暗号化である場合、商用の CA 証明書をロード バランサーにインストールする必要があります。
ArcGIS Enterprise の配置パターンやロード バランサーの設定を理解することで、セキュリティに配慮した設計を進めていくことが可能になります。GIS 活用の中での DX 推進のヒントにしてみてください。