サービスのチューニングと構成

ArcGIS Server は、さまざまなサービス プロパティのデフォルト値を自動的に設定することにより、サービスを簡単にすばやく公開できるようにします。ただし、サービスにアクセスするユーザの数が非常に多い場合、またはユーザがサービスの編集といったステートフルな操作を実行する場合には、導入環境に合わせてサービス プロパティをデフォルト値から適切に変更する必要があります。このトピックでは、サービスを最適に構成するためのプロパティと手法について簡単に説明します。

プールの設定

サービスのプロパティを変更して、プールされるサービスまたはプールされないサービスのいずれかにすることができます。プールされるサービスのインスタンスは、複数のアプリケーション セッション間で共有することができます。アプリケーション セッションがプールされるサービスのインスタンスをサーバに返すと、他のアプリケーション セッションでそのインスタンスを使用できるようになります。したがって、プールされるサービスは、ステートレスな操作でのみ使用する必要があります。

これに対し、プールされないサービスのインスタンスは 1 つのアプリケーション セッションに割り当てられます。プールされないサービスのインスタンスは、アプリケーション セッションによってサーバに返されたときに削除されます。プールされないサービスは、元に戻す/やり直し操作が利用できる編集といったステートフルな操作をアプリケーションで実行する必要がある場合に使用されます。

サービスを追加する際には、プールするかどうかに関係なく、インスタンスの最大値と最小値を指定する必要があります。サービスを開始すると、GIS サーバが最小数のインスタンスを作成し、初期化します。アプリケーションがそのサービスの SOM（Server Object Manager）にインスタンスを要求すると、いずれかのインスタンスへの参照が返されます。すべてのインスタンスが使用されている場合、サーバは新しいインスタンスを作成します。それ以降、コンフィグレーションに指定されているインスタンスの最大数に達するか、またはすべての SOC コンピュータの最大容量に達するまで、リクエストが送信されるたびにこの作業を繰り返します。

プールされるサービス

プールされるサービスのインスタンスを使用するアプリケーションは、1 つのリクエスト（マップの描画、アドレスのジオコーディングなど）が完了するまで、そのインスタンスのみを使用します。リクエストが完了した後、アプリケーションはサービス インスタンスへの参照を解放し、それを利用可能なインスタンスのプールに直接戻します。このようなアプリケーションのユーザは、アプリケーションを操作する過程で、プールの複数のインスタンスを操作する可能性があります。プールのインスタンスの状態はすべて同じなので、ユーザがそれを意識することはありません。

たとえば、マップの特定範囲を描画するステートレス アプリケーションは、プールからマップ サービスのインスタンスへの参照を取得し、マップ サービスのメソッドを実行してマップを描画した後、インスタンスへの参照を解放してプールに戻します。次回、アプリケーションでマップを描画する必要が生じた場合は、これを繰り返します。マップを描画するたびに、プールされるサービスの異なるインスタンスが使用される可能性があります。このため、インスタンスはそれぞれ同じでなければなりません（同じレイヤで構成され、各レイヤのレンダラが同じであるなど）。レイヤを追加したり、レイヤのレンダラを変更するなど、インスタンスの状態を変更した場合、マップの画面移動やズームの際に矛盾する結果が表示されます。これは、状態が変更されたインスタンスがプールに返され、サービスをリクエストするたびにそのインスタンスがプールから返されるという保証がないためです。開発者は、アプリケーションがインスタンスの状態を変更しないことと、インスタンスが適宜にプールに戻されることを保証しなければなりません。

サービスがプールされる場合、GIS サーバは特定のサービスに割り当てるリソースを抑えた上で、より多くのユーザをサポートすることができます。アプリケーションはインスタンスのプールを共有できるので、各ユーザが専用のインスタンスへの参照を保持する場合よりも、システム上の同時ユーザの数を増やすことができます。

プールされるサービスでより多くのユーザをサポートできるのは、アプリケーション セッションがプールの一連のサービスを共有するためです。

プールされないサービス

プールされないサービスのインスタンスを利用するアプリケーションは、一般に、アプリケーションのセッションが終了するまでインスタンスへの参照を保持します。アプリケーションがインスタンスを解放すると、そのインスタンスは削除され、GIS サーバは利用可能なインスタンス数を維持するために新しいインスタンスを作成します。このため、プールされないサービスのユーザは、サービスの元のデータを変更することができます。

プールされないサービスでは、システム上のユーザ数を、実行されているサービス インスタンス数との比が 1 対 1 を超える数に増やすことができません。したがって、GIS サーバがサポートできる同時ユーザの数は、実質的に、GIS サーバが常にサポートできるプールされないインスタンスの数と等しくなります。

GIS サーバがサポートできる最大数の同時ユーザを得るためには、バージョン対応のデータの Web 編集のようなステートフルな操作に必要としないのであれば、プールされないサービスを使用しないことです。プールされないサービスを使用してアプリケーションを開発する場合、必要がなくなったサービス インスタンスは必ず削除するようにしてください。Manager で、プールされないサービスを使用する Web 編集のアプリケーションを構築する場合、[閉じる] リンクをクリックしてアプリケーションを終了するようユーザに推奨してください。これによりプールされないサービスのインスタンスは、タイムアウト時ではなく、直ちに削除されます。

注意注意:

ArcGIS Server Internet 接続で、プールされないサービスを使用しないでください。その代わりに、ArcGIS Server Local 接続を使用してください。

リサイクル

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

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

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

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

サービスを停止および開始するためのコード例をご参照ください。

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

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

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

サービスの元のデータを変更した場合、その変更はリサイクルの後に自動的に反映されます。たとえば、マップ サービスを実行していて、このサービスに関連付けられたマップ ドキュメントを変更した場合は、リサイクル後に変更内容が表示されます（変更内容を直ちに表示するには、サービスを手動で停止し、開始します）。

分離

サービスを作成する際には、利用可能にするインスタンスの最小数と最大数を指定します。これらのインスタンスは、プロセス内のコンテナ コンピュータで実行されます。分離レベルは、これらのインスタンスを別々のプロセスで実行するのか、プロセスを共有するのかを決定します。

高い分離レベルでは、各インスタンスが専用のプロセスで実行されます。何らかの原因でプロセスが異常終了したとしても、その影響を受けるのはそのプロセスで実行されているインスタンス 1 つです。

分離レベルの高いサービスは GIS サーバ上の専用のプロセスで実行されます。

これに対し、レベルを低分離性に設定すると、複数のサービス インスタンスが 1 つのプロセスを共有できるようになります。したがって、4 つの同時リクエストを実行することができます。これはよくマルチスレッディングと呼ばれます。

低い分離レベルでは、プロセスを共有できる同じサービス構成のインスタンスの数は、デフォルトで 8、最大で 256 です。プロセスあたりのインスタンスの数は、[サービス プロパティ] ダイアログ ボックスの [プロセス] タブで設定することができます。特定のサービスのインスタンスがこの数に達すると、サーバが次のインスタンス グループに対する追加プロセスを開始します。そして、インスタンスがその数に達するたびに、同じ操作が繰り返されます。インスタンスが作成されると実行中のプロセスのスペースが埋まり、インスタンスが削除されるとスペースが空きます。

低分離性の利点は、1 つのプロセスによってサポートされる同時インスタンスの数が増えることです。低分離性を使用すると、サーバ上でのメモリ消費を大幅に改善することができます。ただし、この改善にはリスクが伴います。プロセスが終了またはクラッシュした場合、そのプロセスを共有するインスタンスはすべて削除されます。また、低分離性は プールの縮小 の効果を低下させます。これは、プロセス内のすべてのインスタンスが使用されなくなるまで、プールの縮小によりプロセスを削除することができないからです。

プールされないサービスは常に別個のプロセスで実行されるため、分離レベルが適用されないことに注意してください。

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

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

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

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

追加情報追加情報:

デフォルトで ArcGIS Server は、データ接続の有効性チェックおよび修復を行うために、負荷の高いサービスのチェックをすでに実行しています。5 分おきに、サービスによるチェックの結果によって、次のリクエストを受け取ります。ConnectionCheckInterval タグをサービスの構成ファイルの [プロパティ] セクションに追加することによって、間隔を変更するか、またはこの振舞いを無効にすることができます。ConnectionCheckInterval に関する追加情報については、サービスの構成ファイルをご参照ください。

ConnectionCheckInterval は、アイドル状態のサービスに対して、データ接続の有効性チェックを実行することはできません。

タイムアウト

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

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

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

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

サーバを起動した結果として、またはクライアントからサーバへのリクエストへのレスポンスとして、GIS サーバでサービスが作成されるときに、サービスを初期化するためにかかる時間を「作成時間」と呼びます。GIS サーバは、サービスの開始に時間がかかりすぎていることの目安となる開始タイムアウトを管理し、そのタイムアウトを過ぎた時点で、サービスの作成を取り消します。このプロパティは、サービス構成 ファイルの手動編集 でのみ設定することができます。

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

最大容量によるサーバの負荷の制限

最大容量は、SOC コンピュータで実行できるサービス インスタンスの数を制限します。デフォルトでは、最大容量は無制限になっています。ただし、コンピュータのメモリが制限されている場合、最大容量を設定して、実行中のインスタンスの容量がコンピュータを圧迫させることがないように確認することができます。

SOC コンピュータで実行されているサービス インスタンスの数が最大容量に達すると、サーバはその SOC コンピュータで新しいインスタンスを作成しなくなります。すべての SOC コンピュータが最大容量に達した場合は、プールの縮小が開始されます。

最大容量値を選択する場合には、実行中のインスタンスを「使用中」のインスタンスと取り違えないように注意する必要があります。実行中のインスタンスはメモリを消費しますが、CPU の性能は消費しません。使用中のインスタンスは、メモリと CPU を消費します。一度に 4 つの使用中インスタンスのみをサポート可能なサーバは、十分な RAM があれば 4 つよりもはるかに多い実行中インスタンスをサポートすることが可能になります。これらのインスタンスは、実行されればいつでもすぐに使用することができるため、実行中であることが望ましいかもしれません。

コンピュータに十分なメモリがある場合、最大容量を [無制限] のままに設定しておくべきでしょう。

追加情報追加情報:

サーバは、サーバ ディレクトリの使用を管理する追加のバックグラウンド ArcSOC.exe プロセスを、常に実行します。このプロセスは、最大容量のカウントに含まれません。

プールの縮小による調整プールの縮小

GIS サーバのすべての SOC コンピュータが最大容量に達した場合はどうなるでしょうか。ArcGIS Server では、プールの縮小という概念を採用しています。これは、需要の低いサービスのインスタンスを削除し、それらを需要の高いサービスのインスタンスに置き換えるというものです。

プールの縮小は、実行中のサービス インスタンスの数が各 SOC コンピュータの最大容量に達したときに開始されます。プールの縮小が有効な状態で SOM コンピュータがサービスへのリクエストを受信すると、サーバはリクエストされたインスタンスを作成し、最後に使用されてから最も時間が経っている構成のインスタンスを 1 つ削除します。次に、プールの縮小の機能および制限を詳しくまとめてみましょう。

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

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

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

（[GIS リソースの公開] ウィザードではなく）[新規サービスを追加] ウィザードを使ってサービスを作成する場合は、許可するオペレーションをサービスの作成時に選択することができます。サービスを作成した方法がどちらであっても、サービスのプロパティを編集することにより、既存のサービスで許可されるオペレーションを変更することができます。利用可能なオペレーションは、[サービス プロパティ] ダイアログ ボックスの [ケーパビリティ] タブに表示されます。

次の表に、各オペレーションに含まれるメソッドをまとめます。

マップ サービスのオペレーション

マップ

クエリ

データ

GetDocumentInfo

個別属性表示

検索

GetLegendInfo

QueryFeatureCount

QueryFeatureData

GetMapCount

QueryFeatureIDs

GetMapName

QueryHyperlinks

GetDefaultMapName

GetSQLSyntaxInfo

GetServerInfo

GetSupportedImageReturnType

ExportMapImage

IsFixedScaleMap

ToMapPoints

FromMapPoints

HasSingleFusedMapCache

GetTileCacheInfo

GetMapTile

HasLayerCache

GetLayerTile

GetVirtualCacheDirectory

GetCacheName

ComputeScale

ComputeDistance

マップ サービスにおいてデフォルトで許可されるオペレーションは、「マップ」、「検索」、「データ」です。

ジオコード サービスのオペレーション

ジオコード

リバース ジオコード（Reverse Geocode）

GeocodeAddress

ReverseGeocode

GeocodeAddresses

StandardizeAddress

FindAddressCandidates

GetAddressFields

GetCandidateFields

GetIntersectionCandidateFields

GetStandardizedFields

GetStandardizedIntersectionFields

GetResultFields

GetDefaultInputFieldMapping

GetLocatorProperties

ジオコード サービスにおいてデフォルトで許可されるオペレーションは、「ジオコード」と「Reverse Geocode」です。

ジオデータ サービスのオペレーション

クエリ

抽出

レプリケーション

Get_Versions

ExpandReplicaDatasets

CreateReplica

Get_DefaultWorkingVersion

ExtractData

ExportAcknowledgement

Get_DataElements

ExportReplicaDataChanges

Get_MaxRecordCount

ImportAcknowledgement

TableSearch

ImportReplicaDataChanges

GetNextResultPortion

ReExportReplicaDataChanges

Get_Replicas

UnregisterReplica

Get_WrappedWorkspaceType

ImportData

ジオデータ サービスにおいてデフォルトで許可されるオペレーションは、「検索」と「抽出」です。これらのオペレーションにより、データの検索と抽出でサポートされているメソッドがすべて有効になります。「レプリケーション」オペレーションでは、同期、データ変更、メッセージの承認、スキーマでサポートされているメソッドがすべて有効になります。

グローブ サービスのオペレーション

グローブ

アニメーション

クエリ

Get_Version

Get_Animation

個別属性表示

Get_LayerCount

検索

Get_LayerInfos

Get_LegendInfos

Get_Config

Get_MQT

Get_Configuration

Get_Tile

Get_Symbols

Get_Textures

Get_VirtualCacheDirectory

グローブ サービスにおいてデフォルトで許可されるオペレーションは、「グローブ」、「アニメーション」、「検索」です。マップ サービスとは異なり、「検索」オペレーションは Identify と Find の両方をカバーします。

イメージ サービスのオペレーション

画像

カタログ

ダウンロード

メタデータ

ピクセル

ExportImage

フィールド

ダウンロード

メタデータ

GetNativePixelBlock

ExportMapImage

GetCatalogItemCount

GetFile

GetRasterMetadata

GetPixelBlock

GenerateServiceInfo

GetCatalogItemIDs

GetImage

GetCatalogItems

個別属性表示

GetNativeRasterInfo

ServiceInfo

GetRasterInfo

Version

GetThumbnail

ラスタ データセット、コンパイル済みイメージ サービス定義、またはレイヤ ファイルのような、その他のいくつかのソースから公開した場合には、イメージおよびメタデータのケーパビリティのみが適用され有効になります。


Copyright © 1995-2011 Esri. All rights reserved.
3/6/2012