ユーザーのニーズを満たすためのサービスのチューニング

デフォルトのサービスプロパティの値が、ユーザーのニーズに適していない場合があります。ユーザーの数が非常に多い場合や、ユーザーが ArcGIS Server サイトに対して多数のリクエストを行っている場合に当てはまります。このトピックでは、サービスを最適に構成するための概念、プロパティ、手法について簡単に説明します。

サービスインスタンスの理解

ArcGIS Server サイト内のサービスをリクエストすると (マップの画面移動、住所への移動、レンダリングルールを使用した画像の表示など)、サーバーコンピューター上で実行されている公開済みサービスのインスタンスでそのリクエストが処理されます。サービスインスタンスは、ArcSOC プロセスと呼ばれる Esri に所有権のあるサーバープロセスを使用しています。各 ArcSOC プロセスの実行には、一定量のコンピューターメモリーが必要となります。

ArcGIS Server サイトに多数のサービスがあり、サービスごとに 1 つ以上のサービスインスタンスが常に実行されていると、利用可能なコンピューターメモリーが限界に達することがあります。また、組織でサービスインスタンスを実行する場合にはエネルギーコストがかかり、ArcGIS Server をクラウドインフラストラクチャーにデプロイすると、実行する各サービスインスタンスに直接、金銭的コストがかかります。

このため、サイトで実行されているインスタンスの数を監視し、メモリー使用量によってパフォーマンスが抑止された場合に実行するインスタンスを制限することが ArcGIS Server 管理者の重要な役割になります。

ユーザーは、サービス (Web マップや Web アプリなど、サービス上に構築された製品を含む) を扱う際に迅速な結果を期待します。サービスが受け取る通信量を処理するには、適切な ArcSOC プロセスが必要となります。ただし、サービスに必要な数よりも多くのサーバーリソースをプロビジョニングすると、コンピューターメモリー、エネルギー、コストが無駄に消費されることになります。管理者にとっての適切な目標は、パフォーマンスを損なわずに、実行するサービスインスタンスの数をサービスに必要な数にまで削減することです。

共有インスタンスと専有インスタンス

ArcGIS Server では、ArcGIS Pro から ArcGIS Server サイトに公開された互換性のあるマップまたはイメージサービスごとに、共有インスタンスまたは専用インスタンスを使用できます。共有インスタンスを使用すると、複数のサービスで使用されるアクティブなサーバープロセスをいくつかプールできるため、メモリー使用量が節約されます。一方、専用インスタンスは、常にサービスで 1 つ以上のサーバープロセスを使用してリクエストを処理できるようになるため、絶え間なくリクエストを受け取るサービスや特に計算負荷の高いリクエストを受け取るサービスに使用することが最適です。

ArcGIS Server の新しいデプロイメントでは、共有インスタンスがデフォルトです。管理者はいつでも、デフォルトのインスタンスタイプを選択する (互換性のあるマップサービスが共有インスタンスまたは専用インスタンスを使用するかどうか) ことも、個々のサービスのインスタンスタイプを変更することもできます。

ヒント:

どのアプリケーションからサービスが公開されたかを特定するには、ArcGIS Server Manager アプリの各サービスのサービスランタイムおよびインスタンスタイププロパティを確認してください。

次の制約によって、共有インスタンスプールを使用できるサービスが決まります。

マップおよびイメージサービスに限り、共有インスタンスプールを使用するように構成できます。それ以外のタイプのサービス (ジオプロセシングサービスなど) はサポートされていません。
有効にできる機能は、マッピング、イメージング、フィーチャアクセス、WFS、WMS、KML のみです。専用サービスを共有サービスに変換する前に、他のすべての機能を無効にします。

専用インスタンスマップまたはイメージサービスは、指定された ArcSOC プロセスのプールを使用して実行されます。そのプール内のプロセスが、他のサービスに使用されることはありません。共有インスタンスのマップまたはイメージサービスは、他の任意の共有インスタンスサービスにも使用される ArcSOC プロセスのプールを使用して実行されます。デフォルトでは、各共有インスタンス ArcSOC は、リクエストを処理できるよう、最近使用された 50 件のサービスをキャッシュします。ユーザーが新しいサービスに対してリクエストを行った際に、共有インスタンス ArcSOC がすでに最大数のサービスをキャッシュしている場合、ArcSOC は使用されたサービスのうち最も古いサービスをアンロードし、新しいサービスを読み込みます。ユーザーが定期的に 50 件を超える共有インスタンスサービスに対してリクエストを行う場合は、共有インスタンスあたりのキャッシュサービスのデフォルト数を増やすことができます。

各インスタンスタイプを使用するタイミング

一般的に、専用インスタンスよりも共有インスタンスが推奨されます。共有インスタンスは、パフォーマンスとスループットの中央値が同じで、必要なシステムリソースが大幅に少なくて済むため、全体的な効率が向上します。

専用インスタンスが推奨される状況が 2 つあります。

ビジネス上の理由により、少数のサービスセットが他のサービスと比較して高いパフォーマンスとスケーラビリティーを持つ必要がある場合。
スレッドセーフではない SOE やユーティリティーネットワークなど、機能が共有インスタンスでサポートされていない場合。

サービスを専用に指定するだけでは、パフォーマンスは自動的には向上しません。専用インスタンスを使用してパフォーマンスを向上させるには、共有インスタンスに使用できるインスタンス数を減らし、専用サービスのインスタンス数を慎重に設定する必要があります。専用に指定するサービスが多すぎると、パフォーマンスが低下する可能性が高くなります。サイトあたりの専用マップまたはイメージサービスの数を可能な限り少なくすることをおすすめします。

マップおよびイメージサービスの CPU 負担は高くなります。通常、マップおよびイメージサービスを中心とした ArcGIS Server のスループットは、CPU コアの数によって制限されます。サーバーコンピューターに 8 つのコアがあり、すべてのサービスが共有インスタンスである場合、コンピューターが 8 つの同時リクエストを処理しているときに、最大スループットがピークに達する可能性が高くなります。 ArcGIS Server はさらに処理できますが、それらの追加のリクエストは CPU を共有することになります。共有インスタンスを使用するすべてのサービスは同じ優先度で扱われ、サーバーの CPU 性能を最大限に使用できます。

専用インスタンスは、他のサービスのパフォーマンスが低下したとしても、一貫したパフォーマンスを必要とするサービスに適しています。たとえば、8 つのコアがある場合、専用インスタンスの最小数と最大数を 4 に設定することで、そのうちの半分をこの 1 つのサービスのためだけに確保できます。この専用サービスのために常に 4 つ以上のコアを使用できるようにするには、共有インスタンスの数を 4 に減らし、共有インスタンスが 8 つのコアの残り半分を超えて使用しないようにすることができます。

ArcGIS Server では、インスタンスのオーバーアロケーションを行うことができます。つまり、コンピューターに 8 つのコアしかなくても、コア数よりも多くのインスタンスを割り当てることができます。オーバーアロケーションは可能になっていますが、パフォーマンスの予測や制御は困難になります。 10% 〜 20% のオーバーアロケーションを使用すると効率が向上する場合がありますが、オーバーアロケーションの係数が大きすぎるとパフォーマンスが低下する可能性が高くなります。専用インスタンスをオーバーアロケーションする代わりに、一部の専用サービスを共有インスタンスに変換することでパフォーマンス向上が期待できます。

サービスインスタンスの最小数と最大数

サービスが専用のインスタンスを使用している場合、コンピューターごとに許容されるインスタンスの最小数と最大数を調整できます。これらのパラメーターは、交通量の変動に対応するために使用できます。

インスタンスの最小数を設定するプロパティは、すでに作成されていて、各 ArcGIS Server コンピューターでサービスに使用できる専用のインスタンスの数を表します。たとえば、このパラメーターを 3 つのインスタンスに設定すると、該当するサービスがリクエストを受信していない場合でも、常に ArcSOC プロセスで 3 つ以上のインスタンスが実行されます。多くのユーザーがサービスを同時に使用するのでなければ、インスタンスの最小数を下げることを検討してください。

インスタンスの最大数を設定するプロパティは、特定の ArcGIS Server コンピューターで実行されるサービスのインスタンスの最大数を表します。管理者として、適切なレベルのパフォーマンスで予想されるユーザー要求を満たすサービス構成のインスタンス数を算出します。

あるサービス構成に必要なインスタンスの数を割り出すとしたら、時系列的にサーバーを監視するのが最善の方法です。クライアントの待機時間が長すぎてリクエストがタイムアウトする場合は、利用可能なインスタンスの数やアプリケーションによるインスタンスの使用方法を調整する必要があるでしょう。

ユーザーがサービスを使用する時間の長さも検討する必要があります。サーバーへのリクエストの中には、他のリクエストよりも負荷の高いものがあります。サービスにとって、負荷の低いリクエストが大量に送信された場合よりも、負荷の高いリクエストがいくつか送信された場合のほうが困難な状況になることがあります。各サービスには、最大待機時間と最大使用時間を設定するプロパティがあります。サービスへのリクエストがタイムアウトを繰り返している場合は、サービスの最大待機時間または利用可能なサービスインスタンスの数を増やすことを検討してください。

クライアントをサポートするインスタンスの数を算出したら、その数をデプロイされている ArcGIS Server コンピューターの数で割ります。この結果として求められた数がサービス構成のインスタンスの最大数になります。たとえば、リクエストを同時に処理できる最大 10 個のサービスインスタンスが必要であり、使用できる ArcGIS Server コンピューターが 2 台ある場合、インスタンスの最大数は 5 に設定されます。

各インスタンスは、サービスが使用されていないときでもメモリーを消費します。コンピューターごとの最小インスタンス数をコンピューターごとの最大インスタンス数未満に設定すると、使用されていないときのメモリーを解放できます。この機能には通常、パフォーマンスへの小さな影響があります。新しいインスタンスを起動する必要がある場合に、リクエストに遅延が発生する可能性があります。このような遅延を防ぐには、コンピューターごとの最小インスタンス数をコンピューターごとの最大インスタンス数と同じになるように設定できます。

ログとサーバーの統計を使用して、タイムアウトになるリクエストの数が多いかどうか、サービスの使用時間が最大使用時間を超えているかどうかを判断します。 ArcGIS Server Manager を使用して、使用できるサービスインスタンスの数、サービスの最大待機時間、サービスの最大使用時間を調整します。

サービスインスタンスのプール

ArcGIS Server で公開されるすべてのサービスは、プールされます。つまり、サービスのインスタンスは、複数のアプリケーションセッション間で共有することができます。

プールされるサービスのインスタンスを使用するアプリケーションは、1 つのリクエスト (マップの描画、アドレスのジオコーディングなど) が完了するまで、そのインスタンスのみを使用します。リクエストが完了した後、アプリケーションはサービスインスタンスへの参照を解放し、それを利用可能なインスタンスのプールに直接戻します。

サービスインスタンスのリサイクル

サービスのリサイクルにより、利用不能になったサービスを削除して、新しいサービスと置き換えることができます。また、使用されなくなったサービスが確保していたリソースも回収されます。

サービスは一般に、複数のアプリケーションとアプリケーションのユーザーによって共有されます。サービスの再利用の過程で、サービスをアプリケーションで使用できなくなることがあります。たとえば、アプリケーションがサービスの状態を不正に変更したり、サービスへの参照を不正に保持したりして、他のアプリケーションのセッションで利用できない状態にすることがあるかもしれません。場合によっては、サービスが壊され、利用できなくなることもあります。リサイクルにより、サービスのプールを最新の状態に保ち、古くなったサービスや使用不能になったサービスを回収することができます。

リサイクルの過程で、サーバーはサービス構成内の各インスタンスを削除してから再作成します。リサイクルは、サーバー上でバックグラウンドプロセスとして実行されます。画面上には、リサイクルが実行されていることを示すものは何も表示されませんが、リサイクルに関連するイベントはログファイルに記録されます。

リサイクルは、サービスの実行中のインスタンスが指定された最小数を超えているかどうかに関係なく、それらをすべて削除して再作成します。実行中のインスタンス数を指定された最小数に定期的に戻すには、サービスを停止して再開する必要があります。このプロセスを自動化するには、ArcGIS Server の管理 API を使用して、カスタムのコマンドライン実行可能ファイルを実行する Python スクリプト、シェルスクリプト、Windows バッチスクリプトのいずれかを作成することをおすすめします。このカスタム実行可能ファイルは、コマンドライン引数として、サーバー名、サービス名、サービスタイプ、サービスの開始または停止を示すフラグを受け取ります。

リサイクルイベントが発生する間隔は、リサイクル間隔と呼ばれています。デフォルトのリサイクル間隔は 24 時間ですが、サービスエディター ダイアログボックスで変更することができます。また、最初にリサイクルする時刻を選択することもできます。最初のリサイクルが行われた後は、リサイクル間隔を経過するごとにリサイクルが開始されます。

サービスのリサイクルは、インスタンスを利用可能な状態に保ち、各サービスのインスタンスを新規作成することによるパフォーマンスへの影響を分散させるために、1 インスタンスずつ実行されます。リサイクルの順序は決まっていませんが、クライアントによって使用されているサービスのインスタンスは解放されるまでリサイクルされません。このようにして、サービスを利用するユーザーの作業に支障を与えないようにリサイクルが実行されます。

リサイクル中に利用可能なインスタンスが不足した場合、リクエストはインスタンスが利用可能になるまで待機状態になります。その間に最大待機時間に達した場合は、通常と同じメッセージがログに記録されます。

無効なデータ接続の有無の確認

サービスインスタンスがアイドル状態にあるとき、ソースデータへの接続が正常に維持されているかを判断するのは、サーバー管理者にとって難しい場合があります。 ArcGIS Server には、エンタープライズジオデータベースへの無効な接続をチェックするための組み込み機能があります。これらのチェックによって、データベースへの接続が切断または中断された後にサービスが応答しなくなるのを回避することができます。

注意:

ファイルジオデータベースは無効なデータ接続チェックのサポート対象外です。

ArcGIS Server Manager で、サービスエディター ダイアログボックスの プロセス タブを開き、使用されていないインスタンスのデータ接続を定期的にチェックして修復 チェックボックスをオンにすることで、データ接続の有効性のチェックを有効化することができます。また、サービス接続が自動的に有効性チェック (および必要に応じて修復) されるために、分単位での間隔も指定する必要があります。通常は、デフォルトの 30 分を指定するのが適切です。

これらのチェックを有効にすると、サービスが一定期間アイドル状態にあった後にファイアウォールがエンタープライズデータベースへのポートを閉じている場合にも役立ちます。この状況では、時間間隔の選択は、ファイアウォールのタイムアウト設定に左右されるかもしれません。

タイムアウト

使用可能な各種のサービスタイムアウト値を理解すると、サービスを継続して実行し、常に使用できるようにしておくのに役立ちます。これらの値は サービスエディター ダイアログボックスの プール タブで選択できます。

クライアントは、サービスへの参照を取得すると、サービスをある期間にわたって使用してから解放します。クライアントがサービスへの参照を取得してから参照を解放するまでにかかる時間を「使用時間」と呼びます。クライアントがサービスへの参照をいつまでも保持することがないよう (つまり、サービスを適宜に解放するよう)、各サービスに最大使用時間を設定することができます。クライアントが最大使用時間を超えてサービスを保持していた場合、そのサービスは自動的に解放され、クライアントはサービスへの参照を失います。

詳細:

新しいサービスを作成したときの最大使用時間のデフォルト値は 600 秒 (10 分) です。ただし、ArcGIS Server の各サイトで提供される事前生成済みの PublishingTools サービスでは、最大使用時間が 3600 秒 (60 分) に設定されています。これは、大量のデータをサーバーにコピーする公開ジョブに対応するためです。

最大使用時間には、管理者の想定を超える量の作業にサービスが使用されるのを防ぐ効果もあります。たとえば、あるアプリケーションがジオデータベースのチェックアウトを実行するために使用するサービスには、最大使用時間として 10 分を設定するかもしれません。これに対し、アプリケーションでマップの描画にのみ使用する 1 レイヤーを含むサービスには、最大使用時間として 1 分を設定するかもしれません。

サービスの最大数のインスタンスが使用中である場合、サービスをリクエストしているクライアントは、別のクライアントがサービスの 1 つを解放するまでキューに配置されます。クライアントがサービスをリクエストしてからサービスを取得するまでにかかる時間を「待機時間」と呼びます。各サービスには、最大待機時間を設定することができます。クライアントがサービスの最大待機時間よりも長く待機した場合、そのリクエストはタイムアウトします。

3 つ目のタイムアウトは、使用されていないインスタンスが実行を継続できる最大時間です。サービスは使用されなくなった後も、別のクライアントがインスタンスを必要とするまで、サーバー上で実行し続けます。使用されていない実行中のインスタンスもサーバー上のメモリーを消費します。実行中のサービスの数を最小限に抑え、このアイドル状態のタイムアウトを短くすると、メモリーを節約することができます。このタイムアウト値はデフォルトで 1,800 秒 (30 分) に設定されます。アイドル状態のタイムアウトを短くすることには、実行中のサービスがすべてタイムアウトした後、新しいインスタンスが作成されるまでクライアントが待機しなければならないという欠点があります。

サーバーを起動した結果として、またはクライアントからサーバーへのリクエストのレスポンスとして、GIS サーバーでサービスインスタンスが作成される場合に、サービスインスタンスを初期化するのにかかる時間を作成時間と呼びます。 GIS サーバーは、サービスインスタンスの開始に時間がかかりすぎていることの目安となる開始タイムアウトを管理し、そのタイムアウトを過ぎた時点で、サービスインスタンスの作成を取り消します。デフォルト値は 300 秒 (5 分) です。

GIS サーバーは、待機時間、使用時間、サーバー上で発生するその他のイベントに関する統計情報を、メモリー内およびログに記録します。サーバー管理者は、これらの統計情報に基づいて、サービスの待機時間が長すぎるかどうかを判断することができます。その場合は、そのサービスのインスタンスの最大数を増やす必要があるでしょう。

お使いのアーキテクチャーでは、上記以外にもタイムアウトが発生し、指定したサービスタイムアウト値とクライアント側で実際に発生するタイムアウトとの間に差異が生じる場合もあります。たとえば、ArcGIS Web Adaptor またはネットワークロードバランサーをホストしている Web サーバーによって、サービスに影響を与えるタイムアウト処理が実行される場合があります。

注意:

サイトに非常に高い負荷がかかる場合、指定したタイムアウト値とクライアント側で発生するタイムアウトに差異が生じることを想定してください。

サービスで実行できるオペレーションの制限

Web サービスの使用方法を管理しやすくするために、サービスの種類ごとに許可されるオペレーションがあります。各操作は、グループとして有効または無効にできる一連のメソッドで構成されています。 Web サービスのクライアントは、許可されているオペレーションのメソッドのみを呼び出すことができます。

たとえば、マッピング Web サービスのユーザーにマップの描画を許可し、マップレイヤーのデータソースのクエリーを許可したくないとします。この場合は、「データ」オペレーションを無効にし、「マップ」オペレーションを有効にする必要があります。

ここで特にフィーチャサービスを取り上げるのは、フィーチャサービスが GIS データの Web ベースでの編集に使用されるからです。フィーチャサービスには、編集機能の制限に使用できる 1 組の追加オペレーションがあります。これらのオペレーションは、ArcGIS Server Manager の サービスエディター ダイアログボックスの フィーチャアクセス タブで有効または無効にすることができます。所有権ベースのアクセス制御を適用することにより、ユーザーが自分で作成していないフィーチャは編集できないようにすることもできます。

さまざまなサービスの種類に対して可能な操作については、サービスの種類をご参照ください。

サービスチューニングのシナリオ

以下のシナリオは、管理者がユーザーのニーズに合わせてサービスをチューニングする実例を示しています。

シナリオ: サービスの応答時間が遅い

組織内のユーザーから、特定のマップサービスで許容できないほどの表示時間がかかっているとの連絡を受けました。マップサービスについてテストを実施した後、そのマップサービス内にある特定のレイヤーの描画時間が長いことが判明します。さらに調査を進めるために、サーバーログを使用してマップサービスのパフォーマンスのトラブルシューティングを実行し、このマップサービスに関連する情報を切り分けます。

考えられる原因 1

ArcGIS Server Manager ログを確認したときに、サービス内の 1 つまたは複数のレイヤーの描画時間が過度に長いことが判明します。

1 の一般的解決策

次のベストプラクティスを使用して、パフォーマンスに関してマップを最適化します:

縮尺依存のレンダリングの利用。
使われていないレイヤーとデータフレームの削除。
フィルター設定の検証の使用。
レイヤーのシンボルの単純化
可能な場合 (データの変更頻度が少ない場合など)、キャッシュマップの使用を検討。

サービスを確認して、最適化のためのヒントを実装し、サービスを再公開すると、当該マップサービスの応答性が大幅に向上しているのがわかります。

考えられる原因 2

ArcGIS Server Manager ログに、サービス内のレイヤーへのネットワークアクセスの遅延がサービスのパフォーマンスを低下させている可能性があることが示されます。

2 の一般的解決策

データアクセスおよび管理のための次のベストプラクティスを使用して、ネットワークの遅延を最小限に抑え、サービスのパフォーマンスを最適化します。

クエリーレイヤーを最適化します。詳細については、「クエリーレイヤーとは」と「クエリーレイヤーの作成」をご参照ください。
この特定のサービスに最も適しているのはエンタープライズジオデータベースまたはファイルジオデータベースのいずれであるかを決定します。詳細については、サービスの公開に関するデータベースの注意事項をご参照ください。
公開のヒントについて「イメージサービスのデータストアのシナリオ」を確認します。

サービスを確認して、データアクセスおよび管理のためのヒントを実装し、サービスを再公開すると、当該マップサービスの応答性が大幅に向上しているのがわかります。

シナリオ: 十分なコンピューターリソースの確保

非常に評判の良い Web アプリを作成したので、公表された今週末の日付にそのアプリを幅広い利用者に公開しようと考えています。このアプリのサービスに対して大量のリクエストが送られると予測されるため、この使用状況に対応できる十分なコンピューターリソースを確保できるようにする必要があります。

この Web アプリの高い利用率に対応できる十分なサーバーコンピューターリソースを割り当てるには、ArcGIS Server 統計を確認して、ほとんど使用されないサービスを特定し、このアプリの利用者に対処できるようにそれらのサービスプロパティを適宜調整します。同様に、この Web アプリで使用されるサービスについても、サービスプロパティを適宜調整します。

考えられる解決策

サイト用のリソースを割り当てるサービスプロパティを管理して微調整します。たとえば、ユーザーがサービスを使用する時間の長さを検討します。サービスが、その最大使用時間を超えて使用されていますか？サービスに対するリクエストが過剰なため、エンドユーザーがタイムアウトになっていますか？

次の推奨事項をガイドとして使用して、エンドユーザー数を予測および対処できるようにサービスプロパティを調整します。

最もよく使用されるサービスを特定して、サービスごとの最小インスタンス数を低減します。これを行うと、エンドユーザーの待ち時間が減少します。
専用インスタンスを使用しているサービスを、代わりに共有インスタンスプールを使用できる形に移行します。
エンドユーザーのために遅延を緩和できるように、必要に応じて最小および最大インスタンス数、待ち時間、アイドル時間、使用時間を増加させます。
システムリソースを最も必要とするサービス用にそれらのリソースを解放できるように、必要に応じてインスタンス数、待ち時間、アイドル時間を減少させます。