ArcGIS Desktop では、多くのデフォルト サービス プロパティが設定されるため、迅速かつ簡単にサービスを公開できます。 ただし、多くのユーザーがサービスにアクセスすると、配置環境に合わせてサービス プロパティ値をデフォルト値から変更する必要があります。 このトピックでは、サービスを最適に構成するためのプロパティと手法について簡単に説明します。
プール
ArcGIS Server で公開されるすべてのサービスは、プールされます。 つまり、サービスのインスタンスは、複数のアプリケーション セッション間で共有することができます。
プールされるサービスのインスタンスを使用するアプリケーションは、1 つのリクエスト (マップの描画、アドレスのジオコーディングなど) が完了するまで、そのインスタンスのみを使用します。 リクエストが完了した後、アプリケーションはサービス インスタンスへの参照を解放し、それを利用可能なインスタンスのプールに直接戻します。
リサイクル
サービスのリサイクルにより、利用不能になったサービスを削除して、新しいサービスと置き換えることができます。また、使用されなくなったサービスが確保していたリソースも回収されます。
サービスは一般に、複数のアプリケーションとアプリケーションのユーザーによって共有されます。 サービスの再利用の過程で、サービスをアプリケーションで使用できなくなることがあります。 たとえば、アプリケーションがサービスの状態を不正に変更したり、サービスへの参照を不正に保持したりして、他のアプリケーションのセッションで利用できない状態にすることがあるかもしれません。 場合によっては、サービスが壊され、利用できなくなることもあります。 リサイクルにより、サービスのプールを最新の状態に保ち、古くなったサービスや使用不能になったサービスを回収することができます。
リサイクルの過程で、サーバーはサービス構成内の各インスタンスを削除してから再作成します。 リサイクルは、サーバー上でバックグラウンド プロセスとして実行されます。 画面上には、リサイクルが実行されていることを示すものは何も表示されませんが、リサイクルに関連するイベントはログ ファイルに記録されます。
リサイクルは、サービスの実行中のインスタンスが指定された最小数を超えているかどうかに関係なく、それらをすべて削除して再作成します。 実行中のインスタンス数を指定された最小数に定期的に戻すには、サービスを停止して再開する必要があります。 このプロセスを自動化するよい方法は、ArcGIS Server の管理 API を使用して、カスタムのコマンド ライン実行可能ファイルを実行する Python スクリプト、シェル スクリプト、Windows バッチ スクリプトのいずれかを作成することです。 このカスタム実行可能ファイルは、コマンド ライン引数として、サーバー名、サービス名、サービス タイプ、サービスの開始または停止を示すフラグを受け取ります。
リサイクル イベントが発生する間隔は、リサイクル間隔と呼ばれています。 デフォルトのリサイクル間隔は 24 時間ですが、[サービス エディター] ダイアログ ボックスで変更することができます。 また、最初にリサイクルする時刻を選択することもできます。 最初のリサイクルが行われた後は、リサイクル間隔を経過するごとにリサイクルが開始されます。
サービスのリサイクルは、インスタンスを利用可能な状態に保ち、各サービスのインスタンスを新規作成することによるパフォーマンスへの影響を分散させるために、1 インスタンスずつ実行されます。 リサイクルの順序は決まっていませんが、クライアントによって使用されているサービスのインスタンスは解放されるまでリサイクルされません。 このようにして、サービスを利用するユーザーの作業に支障を与えないようにリサイクルが実行されます。
リサイクル中に利用可能なインスタンスが不足した場合、リクエストはインスタンスが利用可能になるまで待機状態になります。 その間に最大待機時間に達した場合は、通常と同じメッセージがログに記録されます。
無効なデータ接続の有無の確認
サービス インスタンスがアイドル状態にあるとき、ソース データへの接続が正常に維持されているかを判断するのは、サーバー管理者にとって難しい場合があります。 ArcGIS Server には、エンタープライズ ジオデータベースへの無効な接続をチェックするための組み込み機能があります。 これらのチェックによって、データベースへの接続が切断または中断された後にサービスが応答しなくなるのを回避することができます。
注意:
ファイル ジオデータベースは無効なデータ接続チェックのサポート対象外です。
ArcGIS Desktop または 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 Desktop の [サービス エディター] ダイアログ ボックスの [フィーチャ アクセス] タブで有効または無効にすることができます。 所有権ベースのアクセス制御を適用することにより、ユーザーが自分で作成していないフィーチャは編集できないようにすることもできます。
さまざまなサービスに対して可能なオペレーションについては、このヘルプの「サービスの種類」のセクションをご参照ください。