道路を滑走する自転車乗り。
すべては効率性に関することです
ArcGIS Serverは、例えば私たちのArcGIS Enterpriseカーのエンジンやボックス入りのGISオフィスと考えることができます。どのオフィスでも、スタッフ数と需要とリソースのバランスを取ることは継続的な計算作業です。そして、それは私たちのボックス入りArcGISオフィスでも同様です。ほとんどのGISオフィスは、利用可能なワークステーション、ネットワーク帯域幅、または必須ソフトウェアのライセンスなどの要因によってスタッフのキャパシティが制限されています。分析者が使用できるデスクやコンピューターが不足すると、オフィスに分析者を追加できません。すべての分析者が何らかのタスクに取り組んでいる場合、新しいタスクを開始するよう依頼できません。スペースを拡張しインフラを追加しても、ArcGIS Proのライセンスを購入しなければ、その増加したキャパシティを利用できません。ArcGIS Serverでも同じ課題と制限に直面します。したがって、ArcGIS Serverで実行されるGISウェブサービス（services）を有限のリソースを効率的に使用しつつ、システムの最高のスループットと速度を確保するように構成することが非常に重要です。
ArcGIS Server内のすべての非ホスト型サービスには、ArcGIS Proで公開時に定義するか、公開後に管理用ウェブアプリケーションArcGIS Server Managerで設定できる一連の構成オプションがあります。サービスはArcGIS Server内で多くの状態で存在できます。まず公開されます。これはサービス定義ファイルが作成され、デフォルトではC:\arcgisserver\directories\arcgissystem\arcgisinputというサブフォルダー内にServerディレクトリとして存在することを意味します。次にサービスは実行中または停止中である可能性があります。デフォルトでは、公開されたサービスは公開時に開始されますが、停止も可能です。サービスが開始され実行中の場合、それは別のウェブアプリケーションArcGIS Server Services Directoryで「広告」されます。ここで管理者、発行者、および開発者は有用なプロパティやサポートされている操作を見つけてサービスを検査・使用できます。
ArcGIS Serverでサービスを開始すると、「オフィス」のマネージャーコンポーネントがそのサービスに設定された最小インスタンス数（デフォルトでは1）を起動します。技術的にはサービスのインスタンスとは単一の処理ユニットであり、通常ホストコンピューターのOS上で実行されるArcSOC.exeプロセスとして現れます。サービスのインスタンスは、必要なArcGIS Proプロジェクトが利用可能なデスクに座っている分析者として考えることができ、その分析者は広告されたGISリソースの定義された機能へのリクエストに応答できます。実行中のインスタンス数は、サービス「使用中」のアプリケーション数や人間とは直接関係ありません。この場合インスタンスは実行中でリクエスト待ち状態です。これをインスタンスのアイドル状態と呼びます。
ArcGIS Server ManagerとWindowsタスクマネージャーによるGISウェブサービスのインスタンス表示。
最小インスタンス数はサービス開始時に起動されるインスタンス数を定義します。この数値は0も含め任意に設定可能です。しかし、この数値を無茶に増やさないでください。GISサーバーには有限のリソースしかなく、おそらく他にもそのリソースを使う必要がある他サービスが稼働しています。しかしそれはあくまで最小値です。同時に最大インスタンス数も設定できます。この最大値は最小値以上でなければなりません。デフォルトではこの数値は2です。つまりデフォルト設定では、サービスがArcGIS Serverに公開された際、そのサービスへのリクエストに応答可能な仮想分析者（インスタンス）の最大数は2となります。それで十分でしょうか？おそらく違います。特に中〜高需要なサービスの場合。しかし繰り返しますが、この最大値はいくらでも設定可能ですが、システム全体が処理可能な容量以上にインスタンス生成を許可すると簡単にシステム過負荷になります。また他にも独自インスタンスを持つ複数サービスがArcGIS Server上で稼働しており、それらも有限リソースを消費します。
インスタンス構成設定画面付きArcGIS Server Manager。
ArcGIS 10.7までは、この方法だけが私たちのGISオフィス（ArcGIS Server）内に存在する分析者（インスタンス）の数を制御する唯一の手段でした。ArcGIS Server内に存在するすべてのインスタンスは各サービスごとに個別定義され、そのサービスへのリクエストのみ応答可能でした。この状況は、私たちのGISオフィス内の各分析者が一度に一つだけプロジェクトをArcGIS Proで開き、そのプロジェクトには一つだけマップやシーンやモデルなど単一のGISリソースが含まれていて、それによってリクエストへ応答しているようなものです。これらは専用インスタンス（dedicated instances）と呼ばれます。
そしてArcGIS 10.7で、新しい共有インスタンスプールという概念を導入しました。このプール内のインスタンスは割り当てられた任意のサービスへのリクエストへ応答可能ですが、割り当て可能なサービスタイプには一定制限があります。この共有インスタンスプールは、私たちのオフィス内で同じプロジェクトコピーを複数分析者が開いており、そのプロジェクトにはプール割り当て済み各サービス用マップ（それぞれ一つずつ）が多数含まれているようなものと考えられます。この利点は低需要サービスにも既存稼働中インスタンスがあり迅速対応できる一方で、未使用インスタンスによるコンピューター資源浪費が抑えられることです。
最後にサービスインスタンスについて考慮すべき点として、ユーザーアクセス可能なすべてのサービスが個別管理された独立したサービスとしてArcGIS Server上に存在しているわけではないことがあります。例えばマップサービス公開時には、そのマップサービス用管理画面（Server Manager）があり最小／最大インスタンス数などプロパティ管理可能です。そのマップサービスには独自URL（エンドポイント）がありクライアント通信経路となります。しかしマップサービスオブジェクトにはcapabilitiesプロパティもあります。このプロパティからfeature access capabilityなど追加機能有効化できます。有効化するとArcGIS Serverはfeature service用別URLも作成します。しかしこのfeature serviceやその他capability経由有効化された他サービスは独自インスタンス生成しません。元々関連付けられたマップサービス用作成済みインスタンス群がfeature serviceもサポートします。
マップサービスURL表示中のArcGIS Server Manager。
フィーチャーサービスURL表示中のArcGIS Server Manager。
この記事では、多くの方法で私たちが管理・制御できることによってArcGIS Serverによるパフォーマンス影響を与えられることをご紹介しました。しかしArcGIS Serverは地理情報システム資源作成・管理・共有プロセス全体の一部に過ぎません。ほとんどの場合、データ保存や資源作成時点で下す決定事項がこれら設定よりも大きな影響力を持ちます。Esri主催トレーニングカリキュラムでは、多くのコンテンツ固有最適化技術について議論し実装しています。当社コース target="_blank" rel="noopener nofollow noreferrer">ArcGIS Enterpriseへのコンテンツ共有. <\/P>
