ArcGIS Server の特長は、さまざまな場所にいる多数のユーザーに GIS 機能を提供できることにあります。 ArcGIS Server の計画を立てる際には、システムを使用するユーザーの数と、その数のユーザーに対応するのに必要なハードウェア量を算出します。 また、使用が集中するかどうかといったその他の要因も考慮に入れる必要があります。 ハードウェアを増設するという選択肢がない場合は、サービス構成を調整することで、より多くのユーザーに対処できる可能性があります。
サイト内のコンピューターの数の調整
ArcGIS Server サイトは、同等の条件で参加している 1 つ以上のコンピューターの組み合わせです。 処理の負荷が高い時間帯は、一般に、ArcGIS Server コンピューターの CPU 使用率が Web サーバーよりも先に 100% に達します。このため、配置する ArcGIS Server コンピューターの数を決定することは、ユーザーに対応するための重要な決断の 1 つです。
システムの運用を開始した後は、ログとサーバーの統計情報に基づいて、サーバーの実行状況を評価できます。 Windows パフォーマンス モニターなどのオペレーティング システム ツールを使用して、リクエストに対応しているサーバーにどれだけ負荷がかかっているかを評価することもできます。 さらに、サードパーティ製のツールとサービスでもシステム パフォーマンスを監視することができます。 Amazon EC2 プラットフォームの Amazon Cloud Watch は、クラウド環境でシステム パフォーマンスを監視する Web サービスの一例です。
システムのピーク時に ArcGIS Server への標準的なリクエストがタイムアウトになることが判明し、一定の期間に CPU の使用率が 100% に達している場合は、ArcGIS Server 層でコンピューターを増設することで効果がもたらされる場合があります。 新しいコンピューターを手動で追加するか、仮想コンピューターを使用した自動化プロセスで追加します。 たとえば、CPU の使用率が 15 分以上にわたって 70% を超えたときに新しい ArcGIS Server コンピューターを追加するスクリプトを作成できます。
マップ キャッシュやジオプロセシングなどのプロシージャは、比較的多くの CPU リソースを消費します。 これらのジョブの実行時期を予測できる場合は、一時的にいくつかの ArcGIS Server コンピューターを作成し、該当するジョブが終了した時点でこれらのコンピューターを削除することが可能です。 そうしたシナリオでは、仮想コンピューターとクラウド コンピューティング プラットフォームを使用すると、追加ハードウェアをすばやく取得し、使用後はすぐに解放できるため便利です。
サービス インスタンスの理解
ArcGIS Server サイト内のサービスをリクエストすると (マップの画面移動や住所への移動など)、サーバー コンピューター上で実行されている公開済みサービスのインスタンスでそのリクエストが処理されます。 サービス インスタンスは、ArcSOC プロセスと呼ばれる Esri に所有権のあるサーバー プロセスを使用しています。 各 ArcSOC プロセスの実行には、一定量のコンピューター メモリが必要となります。
サーバー サイトが多数のサービスをホストしている場合は特に、リクエストをまれにしか受け取らないサービスに共有インスタンスを使用することをお勧めします。 一方、専用インスタンスは、常にサービスで 1 つ以上のサーバー プロセスを使用してリクエストを処理できるようになるため、絶え間なくリクエストを受け取るサービスや特に計算負荷の高いリクエストを受け取るサービスに使用することが最適です。
共有インスタンス プールは、次のような互換性のあるマップ サービスに適しています。
- 使用頻度の低いサービス。 これは配置によって異なりますが、ほとんどの配置では、平均で 1 分あたり 1 つ未満のサービス リクエスト数を意味します。
- すでに専有インスタンスの最小数がゼロに設定されているサービス。
- ほとんどのキャッシュ マップ サービス。
レガシー:
10.8.1 より前のバージョンでは、サーバー オブジェクト エクステンション (SOE) またはサーバー オブジェクト インターセプター (SOI) を使用するサービスで共有インスタンス プールを使用できませんでした。
ArcGIS Server では、ArcGIS Server から ArcGIS Pro サイトに公開された互換性のあるマップ サービスごとに共有インスタンスまたは専有インスタンスを使用できます。 共有インスタンスを使用すると、複数のサービスで使用されるアクティブなサーバー プロセスをいくつかプールできるため、メモリ使用量が節約されます。 これにより、リクエストを頻繁に処理していないサービスにメモリが使用されなくなります。
インスタンス タイプの選択
サーバー サイトが多数のサービスをホストしている場合は特に、リクエストをまれにしか受け取らないサービスに共有インスタンスを使用することをお勧めします。 一方、専用インスタンスは、常にサービスで 1 つ以上のサーバー プロセスを使用してリクエストを処理できるようになるため、絶え間なくリクエストを受け取るサービスや特に計算負荷の高いリクエストを受け取るサービスに使用することが最適です。
管理者はいつでも、デフォルトのインスタンス タイプを選択する (互換性のあるマップ サービスが共有インスタンスまたは専用インスタンスを使用するかどうか) ことも、個々のサービスのインスタンス タイプを変更することもできます。 交通量に基づいてこれらの決定を行います (現在の交通量に対応するか、予想される交通量の変化に備えるかのいずれか)。
すべてのサービスが共有インスタンス プールを使用するわけではありません。 次の制限が適用されます。
- ArcGIS Pro から公開されたマップ サービスに限り、共有インスタンス プールを使用するように構成できます。 それ以外のタイプのサービス (ジオプロセシング サービスなど) はサポートされていません。
- マップ サービスの特定の機能のみ (フィーチャ アクセス、WFS、WMS、および KML)、有効にすることができます。 それ以外の機能はすべて、処理を進める前に無効にしておきます。
- ArcGIS Pro から公開されたキャッシュ マップ サービスのうち、上記の要件を満たしているものは共有インスタンスを使用できます。
共有インスタンス プールは、次のような互換性のあるマップ サービスに適しています。
- 使用頻度の低いサービス。 これは配置によって異なりますが、ほとんどの配置では、平均で 1 分あたり 1 つ未満のサービス リクエスト数を意味します。
- すでに専有インスタンスの最小数がゼロに設定されているサービス。
- ほとんどのキャッシュ マップ サービス。
専用のインスタンス プールの調整
サービスが専用のインスタンスを使用している場合、コンピューターごとに許容されるインスタンスの最小数と最大数を調整できます。 これらのパラメーターは、交通量の変動に対応するために使用できます。
インスタンスの最大数を設定するプロパティは、特定の ArcGIS Server コンピューターで実行されるサービスのインスタンスの最大数を表します。 管理者として、適切なレベルのパフォーマンスで予想されるユーザー要求を満たすサービス構成のインスタンス数を算出します。 これは、クライアントによるサービスの平均使用時間、予想されるクライアントの数、クライアントのリクエストの頻度、およびリクエストに必要な処理の負荷からなる、複合的な評価です。
あるサービス構成に必要なインスタンスの数を割り出すとしたら、時系列的にサーバーを監視するのが最善の方法です。 クライアントの待機時間が長すぎてリクエストがタイムアウトする場合は、利用可能なインスタンスの数やアプリケーションによるインスタンスの使用方法を調整する必要があるでしょう。 クライアントをサポートするインスタンスの数を算出したら、その数を配置されている ArcGIS Server コンピューターの数で割ります。この結果として求められた数がサービス構成のインスタンスの最大数になります。 たとえば、リクエストを同時に処理できる最大 10 個のサービス インスタンスが必要であり、利用可能な ArcGIS Server コンピューターが 2 台ある場合、インスタンスの最大数は 5 に設定されます。
インスタンスの最小数を設定するプロパティは、すでに作成されていて、各 ArcGIS Server コンピューターでサービスに利用可能な専用のインスタンスの数を表します。 多くのユーザーがサービスを同時に使用するのでなければ、インスタンスの最小数を下げることを検討してください。
インスタンスの最小数を 0 に設定することもできます。 ただし、これによって、アクティブなインスタンスがないサービスが次回リクエストを受信するときに、パフォーマンスにわずかな遅延が生じます。 このタイム ラグは「コールド スタート」と呼ばれます。
ユーザーがサービスを使用する時間の長さも検討する必要があります。 サーバーへのリクエストの中には、他のリクエストよりも負荷の高いものがあります。 サービスに負荷の低いリクエストが大量に送信された場合よりも、負荷の高いリクエストがいくつか送信された場合のほうが、サービスのパフォーマンスを低下させることがあります。 各サービスには、最大待機時間と最大使用時間を設定するプロパティがあります。 サービスへのリクエストがタイムアウトを繰り返している場合は、サービスの最大待機時間または利用可能なサービス インスタンスの数を増やすことを検討してください。
ログとサーバーの統計情報を使用して、タイムアウトになるリクエストの数が多いかどうか、サービスの使用時間が最大使用時間を超えているかどうかを判断します。 Server Manager を使用して、利用可能なサービス インスタンスの数、サービスの最大待機時間、およびサービスの最大使用時間を調整します。