はじめに
組織はしばしば、ArcGIS Enterprise の展開に対して99パーセント以上のシステム稼働時間など、一定レベルのシステム稼働時間を要求します。これらの組織にとって、高可用性を確保するための戦略を実装することが重要です。
高可用性（HA）は災害復旧（DR）に関連していますが、別個の概念です。一般的に、HAはサービス提供のダウンタイム回避に焦点を当てているのに対し、DRは災害後にシステムを以前の許容可能な状態に復元するために必要なデータとリソースの保持に焦点を当てています。
本投稿では、高可用性のために単一ロケーションでローカルロードバランサー（Local Traffic Manager, LTM）を構成するベストプラクティスに焦点を当て、異なるロケーション間で自動フェイルオーバーを行うグローバルトラフィックマネージャー（GTM）の構成については含みません。
高可用性を達成するには、単一障害点を複製と負荷分散によって減らす必要があります。
ロードバランサーはリバースプロキシとして機能し、トラフィックをバックエンドサーバーに分散します。高可用な ArcGIS Enterprise 展開には、ソフトウェアの容量と信頼性を向上させるためにサードパーティ製ロードバランサーが必要です。これらはポータルおよびサーバーサイトへのクライアントトラフィックだけでなく、ソフトウェアコンポーネント間の内部トラフィックも処理します。
ArcGIS Web Adaptor
ArcGIS Web Adaptor はロードバランサーと見なされますが、高可用な展開で唯一のロードバランサーとして機能するには不十分です。なぜなら ArcGIS Web Adaptor 自体も高可用性を達成するためには冗長化が必要だからです。
ArcGIS Web Adaptor はオプションコンポーネントですが、ロードバランサーはリクエストを直接ポータルおよびサーバーサイトに転送できるものの推奨されるコンポーネントです。Web Adaptor を使用する利点は以下の通りです：
- システム全体で単一URLを簡単に構成できること
- portal、server、mapping など異なるシステムコンポーネントごとにコンテキスト名を選択できること
- 他の ArcGIS Enterprise ソフトウェアコンポーネント（ポータルおよびサーバーサイト）とネイティブ統合されており、自動的にヘルスチェックや構成タスク（例：新しいマシンのサーバーサイトへの追加）を処理すること
Web Context URL
Web Context URL はポータルの公開URLです。ポータル内のあらゆるアイテム（ファイル、レイヤー、マップ、アプリ）にはURLがあり、portal の WebContextURL プロパティはエンドユーザーへ送信されるすべてのリソース上で正しいURLを構築するのに役立ちます。
外部アクセスとDNS
ArcGIS Enterprise ポータルは公開ポータルURL（Web Context URL）として一つのDNSのみをサポートしており、現在Web Context URL を変更する際には管理タスク（例：サーバーサイトとのフェデレーション）をやり直す以外にサポートされた方法はありません。モバイルユーザー、契約者、パートナーまたは代理店などへのVPNなしでのアクセス許可など外部アクセスが必要な場合や将来的に外部アクセスが必要になる可能性がある場合は、ポータルのWeb Context URL に対して外部から解決可能なDNS名（例：https://gis.company.com/portal）を使用しなければなりません。
ArcGIS Enterprise への外部アクセスを保護するためには、DMZ にロードバランサーをホストし、Split Domain Name System (Split DNS) を実装することが一般的です。つまり ArcGIS Enterprise DNS (例：gis.company.com) への内部アクセスは内部ロードバランサーIPへ解決されるため内部ユーザーはファイアウォール内に留まり、一方外部アクセスは外部(DMZ)ロードバランサーIPへ解決されます。
フェデレーションで使用されるURL
高可用な ArcGIS Enterprise 展開ではいくつか異なるURLが使用されます。
サービスURL
これはユーザーおよびクライアントアプリケーションが ArcGIS Server サイトへアクセスするために使用するURLです。ArcGIS Server トラフィックを処理しリクエストをサーバーサイトの Web Adaptor または直接サーバーマシンへ渡すロードバランサーのURLです。
管理用URL
このURLは管理者および内部的にはポータルによって ArcGIS Server サイトへの管理操作時に使用されます。また、このURLは登録済みデータストア（例：SQL Server エンタープライズジオデータベース）への参照付き GIS サービス公開時にも使用されます。必ずロードバランサーへ向けられなければならず、もし管理用URLが単一マシンへ向けられていてそのマシンがオフラインの場合フェデレーションは機能しません。このURLはサービスURLと同じでもよいですし、それぞれのフェデレーションされたサーバーサイト管理用URL向けに第二のロードバランサー(VIP)としてポート6443経由で設定してもかまいません。各フェデレーションされたサーバーサイト管理用URL向け専用VIP設定では管理者およびパブリッシャー向けにこのポート開放が必要となり、Web Adaptor 経由での管理アクセス無効化も可能となり組織向け追加セキュリティ制御となります。
設定簡素化のためサービスURLと同じURL使用を推奨します。ArcGIS Server 管理アクセスは ArcGIS Enterprise 認証およびユーザーロールによって制御されます。これは portal の管理アクセス（例：ArcGIS Portal Directory (portaladmin)、組織設定）と同様です。管理用URLとして Web Adaptor URL を使う場合はサーバー Web Adaptor で管理アクセス有効化が必要です。
プライベートポータルURL
これはあなたのサーバーサイトがポータルと通信するために使用する内部URLです。これも必ずロードバランサーへ向けられ、フェデレーション前に定義されているべきです。もし privatePortalURL 設定前にサーバーサイトをフェデレーションした場合は、トピック 既存展開を高可用性対応へ構成する方法 のステップ8および9に従ってください。 高可用性を使用して、デプロイメント内のURLを更新します。管理用URLと同様に、これはポータルのパブリックURL（ポータルのWebコンテキストURL）と同じにすることもできますし、ポート7443経由の2番目のロードバランサー（VIP）にすることもできます。<\/P>
設定の簡素化のために、プライベートポータルURLにはポータルのパブリックURLを使用することをお勧めします。プライベートポータルURLに専用のロードバランサーVIP（ポート7443）を使用する場合は、ロードバランサーをポータルマシンのヘルスチェックを行うように設定してください。<\/P>
ロードバランサー構成<\/H1>ヘルスチェック設定 <\/H2>最も重要な機能はヘルスチェックです。ポータルのヘルスチェックドキュメントで説明されているように：<\/P> <\/P>「ヘルスチェックは、応答しているPortal for ArcGISマシンがリクエストを受信し処理できるかどうかを報告します。例えば、ポータル作成前は、ヘルスチェックURLがサイトが利用不可であると報告します。なぜならその時点でリクエストを受け付けられないからです。」<\/EM><\/BLOCKQUOTE> <\/P>ArcGIS Enterprise portalとserverにはヘルスチェックがあります。<\/P>ArcGIS Web Adaptorsを使用する場合、Web Adaptorsがポータルおよびサーバーに対するヘルスチェックを実行します。この場合、ロードバランサーは基本的なTCP/443ヘルスチェックまたは静的ページヘルスチェックを標準的なタイムアウト、失敗トリガー、ポーリング間隔、および正常閾値の設定で構成できます。<\/STRONG><\/P>ロードバランサーを使って直接ポータルやサーバーにアクセスするように構成する場合（例：アーキテクチャにWeb Adaptorsを含めない場合やプライベートポータルURL（ポート7443）やフェデレーテッドサーバー管理用URL（ポート6443）に専用ロードバランサーURLを使用する場合）、ロードバランサーはポータルおよびサーバーマシンのヘルスチェックを行うように設定すべきです。<\/P>ロードバランサーのヘルスチェック設定にはいくつか重要な考慮事項があります。多くの組織ではロードバランサーのヘルスチェックとして静的ページ（例：index.html）を使用し、ウェブサーバーが正常かどうか判断しています。これはディスクからの取得のみを必要とする静的ファイルです。また、多くのウェブサーバーはCPUよりもI/Oでボトルネックになる傾向があります。<\/P>しかしEsriのArcGIS Serverは異なり、当社のヘルスチェックは単なるディスク取得以上であり、一部プロセスが機能しているかどうか判断するため少量ながらCPU負荷がかかります。<\/P>ヘルスチェックにはポール時のタイムアウト値があります。多くのロードバランサー管理者はディスク取得が通常非常に高速であるためタイムアウト値を非常に低く設定します（ただしネットワーク遅延への余裕は残すことが多いです）。<\/P>ArcGIS Serverで低いタイムアウト値とマルチマシン構成を使う場合、一部マシンが低いタイムアウト値を超える可能性があり、正常なマシンが除外されることがあります。<\/P>Esriはより高いタイムアウト値、理想的には少なくとも5秒以上を推奨します。システムによってはさらに増やす必要があります。環境を監視し、この値を適宜調整してください。この数値はネットワーク管理者には高く感じられるかもしれません。通常単純なページへのヘルスチェックは10ms未満（ネットワーク遅延含む）だからです。<\/P>しかしロードバランサーがマシンが単に遅いだけなのか、本当に死んで応答しない状態なのか区別することが重要です。もしポータルやサーバーが完全にダウンしていて全くポートでリッスンしていない場合、多くのロードバランサーは5秒より早く検出しますので、このタイムアウトは「通常」の障害には影響しません。<\/P>次に考慮すべきは失敗トリガーです—何回失敗したらマシンをロードバランサーから除外するかという設定です。<\/P>一般的にネットワーク管理者は単一障害でシステム停止しないよう失敗トリガーを1回以上に設定します。前述したようにArcGIS ServerではCPU使用率の小さな急増（よくある）がタイムアウト原因となることがあり、単一マシンのCPU急増だけでマシン停止させることは望ましくありません。<\/P>Esriは内部テストで5回失敗設定が誤検知（偽陽性）を大幅に減らしつつ真の障害検出も可能と確認しました。一方3回ではまだ誤検知が多かったです。<\/P>3つ目はポーリング間隔です。Esriでは30秒間隔と5回失敗設定が真障害検出と誤検知無視の最適点でした。<\/P>この組み合わせでは統計用語でいう期待値または平均検出時間はダウンタイム1分15秒で、最悪ケースでも2分30秒です。より短い平均検出時間も可能ですが、その代わり誤検知が増えます。<\/P>短い平均検出時間を望む場合、容量増強して真障害と誤検知両方耐えられる十分なリソース確保が必要になるでしょう。<\/P>最後に健康閾値—ロードバランサーが再度リクエスト送信開始するまで連続して正常判定される回数についてです。Esriから特別な推奨はありませんし、この数値による差異もあまり観察されていませんが、通常3回連続正常判定後再参加となっています。<\/P>スロットリング <\/H2>スロットリング設定も考慮すべきです。ArcGIS ServerはCPU依存型であり、大部分のリクエスト時間はI/O待ちではなくCPU使用中です。<\/P>つまり8コアあれば実質的には8件以上同時リクエスト処理可能ですが、多数リクエスト来るとキューイングされ数百件待ちになり、その閾値超えると接続拒否します。長いバックログ発生時には待ち時間長くなりますが最終的には処理されます。<\/P>ArcGIS Serverにはこの動作制御設定がありますので放棄されたリクエスト減らせますが、ロードバランサーレベルでもスロットリング制御することがベストプラクティスです。<\/P>Esriから具体的数値推奨はありません。それぞれアーキテクチャやリクエスト種別によるためですが、多くの場合ネットワーク管理者がWebサーバー向けに設定するよりかなり低い値で制限しています。<\/P>これはネットワーク管理者側では制御困難ですが、クライアントアプリケーション側でスロットリングイベント対応し、再試行間隔徐々に増加させる実装（例：初回即再試行、2回目1秒待機、3回目5秒待機など）が望ましいです。<\/P>スティッキーセッション <\/H2>Esriでは非常に稀な状況以外ではスティッキーセッション推奨していません。理論上過負荷になる可能性があります。当社では負荷テスト実施済みで過負荷発生せず顧客苦情もありません。ただし当社ソフトウェアはステートレスなので価値見出せません。<\/P>レイヤ4 vs. レイヤ7 <\/H2>最後に言及すべき設定としてロードバランサーが「レベル7」方式か「レイヤ4」方式かがあります。この点についてネットワーク管理者間で議論ありますが以下簡潔な違いと利点まとめです。<\/P>レイヤ7ロードバランサーはhttpおよびhttps理解しhttpsコンテンツ復号化後再暗号化します。またhttp/https理解しているためコンテンツキャッシュできバックエンドへのリクエスト削減可能です。<\/P>レイヤ4ロードバランサーは全トラフィックTCPパケットとして扱いパケット内容不明（ftp, https, smtp等問わず）なのでhttpペイロード理解不要で高速化可能です。<\/P>ArcGIS Serverはいずれ方式でも動作可能でネットワーク管理者向け特別推奨なしですが管理者として知っておきたい情報があります。<\/P>ArcGIS ServerペイロードサイズはHTMLページやCSS, JSより大きいこと多く（実際サイズは顧客データ依存）、レイヤ7ロードバランサーでは各リクエストごとの復号・暗号化によるCPU負荷大きくなります。<\/P>またArcGIS Serverデータ多く動的頻繁変更されるためデフォルトキャッシュヘッダーではクライアント・ロードバランサー共キャッシュ禁止されています。データ変化少なくレイヤ7使いたい場合これらキャッシュ設定変更・制御可能です。<\/P>推奨事項まとめ<\/H2>ヘルスチェック<\/P>ArcGIS Web Adaptors付きロードバランサー構成の場合、基本TCP/443または静的ページによるウェブサーバーヘルスチェック構成可能ロードバランサー直接ポータルやサーバアクセス構成の場合（ポート6443, 7443経由）、 HTTPS ヘルスチェックエンドポイント:<\/SPAN>Portal:<\/SPAN>リクエスト: <\/SPAN>https:\/\/\/\/portaladmin\/healthCheck?f=json
または<\/SPAN>
<\/SPAN>https:\/\/:7443\/arcgis\/portaladmin\/healthCheck?f=json<\/A><\/SPAN><\/LI>レスポンス: {"status":"success"}<\/SPAN><\/LI><\/UL><\/LI>Server:<\/SPAN>リクエスト: <\/SPAN>https:\/\/\/\/rest\/info\/healthCheck?f=json
または<\/SPAN>
<\/SPAN>https:\/\/:6443\/arcgis\/rest\/info\/healthCheck?f=json<\/A><\/SPAN><\/LI>レスポンス: {"success":true}<\/SPAN><\/LI><\/UL><\/LI>ヘルスチェックのタイムアウト値は高めに設定し、少なくとも5秒にする<\/SPAN><\/LI>失敗トリガーの値は5を使用する<\/SPAN><\/LI>ポーリング間隔は30秒に設定する<\/SPAN><\/LI>再参加前に3回連続で正常なポーリングを行う<\/SPAN><\/LI><\/UL><\/LI><\/UL>スロットリング <\/SPAN><\/P>一般的なウェブサーバーよりもかなり低い値でスロットル設定を使用する<\/SPAN><\/LI><\/UL>スティッキーセッション<\/SPAN><\/P>スティッキーセッションは使用しない<\/SPAN><\/LI><\/UL>
証明書<\/SPAN><\/H1>ArcGIS Enterprise コンポーネントには自己署名サーバー証明書が事前構成されており、これによりソフトウェアを最初にテストし、インストールが成功したことを迅速に確認できます。しかし、ほとんどの場合、組織は信頼された証明機関(CA)から証明書を取得し、それを使用するようソフトウェアを構成すべきです。証明書は企業内(Corporate)または商用のCAによって署名されることがあります。商用CA(known-CA)は外部で解決可能なDNS（例：ロードバランサーVIP DNS）に使用し、内部ドメイン証明書は内部サーバーに使用できます。 <\/SPAN>
外部で解決可能なDNSを持つ ArcGIS Enterprise システムの場合、ロードバランサーのSSL方式がSSL-passthrough（ロードバランサーがhttpsコンテンツを復号化および再暗号化しない）であれば証明書は不要であり、商用CA証明書はマップされたサーバー（例：Web Adaptor がインストールされているWebサーバー）にインストールする必要があります。ロードバランサーのSSL方式がSSL再暗号化の場合は、商用CA証明書をロードバランサーにインストールする必要があります。<\/SPAN><\/SPAN><\/P>
.png)
