導入シナリオ
このトピックでは、さまざまな容量および可用性の要件に合わせて ArcGIS Server サイトを設計できるいくつかの方法を説明します。
それぞれの導入シナリオを説明するために次の用語が使用されます。
- サイト: サイトは、GIS サーバや ArcGIS Web Adaptor などの複数のコンポーネントから構成されています。これらは、処理性能と冗長性を向上させるために、オプションで複数のコンピュータに分散することができます。詳細な説明については、「ArcGIS Server サイトの詳細」をご参照ください。
- GIS サーバ: GIS Web サービスに発行されたリクエストに対する処理を実行するサイトの主要コンポーネント。GIS サーバは、マップの描画、ツールの実行、画像の配信、および ArcGIS が提供するその他多くの処理を実行できます。
- ArcGIS Web Adaptor: サイトへの Web エントリ ポイントを構成できるオプションのコンポーネント。Web サーバに統合され、受信したリクエストを GIS サーバ間に分散します。詳細については、「ArcGIS Web Adaptor について」をご参照ください。
- サーバ ディレクトリ: サービスをサポートする特定の種類のファイルを含む一連のディレクトリ。キャッシュ、検索インデックス、ジオプロセシング ジョブの結果などのファイルがあります。詳細については、「サーバ ディレクトリについて」をご参照ください。
- 構成ストア: サイトに参加している GIS サーバのリストなどの構成情報が格納されている場所。サイトが機能するには、構成ストアが利用可能でなければなりません。詳細については、「構成ストアについて」をご参照ください。
- データ:フィーチャクラス、ツール、画像、ロケータなどの Web サービスをサポートするデータ。詳細については、「データを ArcGIS Server でアクセス可能にする」をご参照ください。
次に示すシナリオは、ArcGIS Server システムを構築するときに参考にすべきガイドラインになります。いずれかのシナリオに示されている通りにサイトを構成することができますが、これらの構成は柔軟であり、特殊なニーズやハードウェア リソースに合わせて調整することができます。
開発者サンドボックス サイト
ArcGIS Server で開発または実験的に試しているだけなら、Web サーバまたは Web Adaptor をインストールせずに GIS サーバだけをインストールすることができます。
![]() |
1 台の GIS サーバを含む開発者サンドボックス サイト。データ、サーバ ディレクトリ、および構成ストアは GIS サーバにローカルに配置されます。 |
このシナリオでは、サイトは 1 台の GIS サーバで構成されます。データ、サーバ ディレクトリ、および構成ストアは GIS サーバにローカルに配置されます。 PostgreSQL データベースは、GIS サーバ上に小さいジオデータベースのインスタンスを設定するための優れたオプションです。
クライアントは、ポート 6080 で HTTP を使用して GIS サーバに直接接続し、開発者サンドボックスにアクセスします。たとえば、サイトの URL は http://myserver:6080 のようになります。GIS サーバはサービスのみをホストします。この構成では、Web アプリケーションをホストする Web サーバは存在しません。
開発者サンドボックス サイトの使用事例と利点
この構成は、サービスのプロトタイプの作成と独立したサンドボックスのテストに適しています。そのインストールと管理は比較的簡単です。
開発者サンドボックス サイトの欠点
この構成では、ArcGIS Server Manager と ArcGIS Server Administrator Directory が、他のすべてのユーザがサービスにアクセスするために使用するのと同じポートを通じて公開されるため、十分なセキュリティが確保されません。また、この構成は Web アプリケーションをホストできず、GIS サーバがオフラインになった場合のフェイルオーバー オプションがありません。
単一コンピュータのサイト
本番環境サイトに使用できる最も単純な構成は、Web Adaptor を通じて 1 台の GIS サーバを公開するものです。
Web Adaptor が推奨されるのは、受信したリクエストが既存の Web サーバを通過するようにできるためです。これにより、セキュリティのオプションが増え、Web アプリケーションをホストする能力が向上します。リソースが不足している場合、または多くの同時リクエストに対応する必要がない場合は、GIS サーバと Web Adaptor を同じコンピュータにインストールできます。このコンピュータには必ず Web サーバもインストールする必要があります。
たとえば、下の図のサイトは、ポート 80 に Web Adaptor が設定され、URL http://myserver を使用してアクセスされます。Web Adaptor は受信したクライアント リクエストをポート 6080 で GIS サーバに転送します。サーバ管理者は、ポート 6080 を通じて Manager または Administrator Directory にログインする必要があります。
![]() |
Web Adaptor が GIS サーバにインストールされた単一コンピュータのサイト。 |
組織の既存の IT インフラストラクチャの一部を使用するようにサイトを設計することができます。下の図では、Web Adaptor の負荷が別のコンピュータの Web サーバに分散されています。同様に、データ、サーバ ディレクトリ、および構成ストアが専用のデータ サーバに配置されています。これは、「単一コンピュータのサイト」という語句は実質的に「単一 GIS サーバのサイト」を意味することを示しています。
![]() |
Web Adaptor がインストールされ、データの負荷が別のコンピュータに分散された単一 GIS サーバのサイト。 |
Web サーバと GIS サーバで担当管理者またはアクセス ポリシーが異なる組織では、Web サーバを独自のコンピュータに配置することが推奨されます。
データを別のコンピュータに配置すると、データ パスの設定を変えることなく、GIS サーバをサイトに追加したり、サイトから削除することができます。サーバ ディレクトリと構成ストアを冗長性のあるネットワーク ストレージ デバイスに格納すると、それらのリソースのバックアップおよび復元能力が向上します。
単一コンピュータのサイトの使用事例と利点
上の図のような Web Adaptor を導入した単一コンピュータのサイトは、少数の同時ユーザに対応するのに最適です。また、高いセキュリティや Web アプリケーションのホスト機能が期待される開発またはプロトタイプのシナリオにおいても有効です。単一コンピュータのサイトは比較的構成が簡単であり、既存の Web サーバやデータ格納アーキテクチャに統合することができます。
単一コンピュータのサイトの欠点
単一コンピュータのサイトには、GIS サーバがオフラインになった場合のフェイルオーバー機能がありません。また、GIS サーバの容量は、単一のコンピュータの物理的なハードウェア特性によって制限されます。
複数台のコンピュータのサイト
サイトに複数の GIS サーバを導入して、増加するトラフィックに対処し、いずれかの GIS サーバがオフラインになった場合のバックアップを用意することができます。次の図は、複数の GIS サーバを使用してサイトを構成する最も簡単な方法を示しています。Web Adaptor は、サイトに参加している GIS サーバを検出し、ラウンドロビン方式で各サーバにリクエストを転送します。GIS サーバも、GIS サーバ間である程度のリクエスト配布を実行します。
![]() |
可用性の高いデータ サーバにデータを配置した複数の GIS サーバで構成されるサイト。 |
複数の GIS サーバを使用するときのデータの格納には 2 つの方法を採用できます。上に示した方法は、各 GIS サーバが認識できる一元化された場所にデータを保有します。データを一箇所だけで管理すればよく、この構成は良好なイントラネット コネクションが確保されている場合に推奨されます。
下に示しているデータ格納のもう 1 つの方法では、各 GIS サーバ コンピュータの同じパスにデータのローカル コピーを置きます。この方法では、ネットワーク呼び出しが削減され、イントラネット接続の速度が遅い場合にパフォーマンスを改善できます。ただし、このアーキテクチャでは大きな、頻繁に変更されるデータセットを管理するのが困難です。
![]() |
各 GIS サーバにデータをローカルに格納した複数の GIS サーバで構成されるサイト。 |
上記のいずれかのシナリオで需要が増加した場合は、手動か、(スクリプトによって)自動的に GIS サーバ コンピュータをサイトに追加することができます。このアーキテクチャは、任意の GIS サーバをいつでもサイトに追加し、サイトから削除できるクラウド コンピューティングに適しています。
クラスタの利用
2 台以上の GIS サーバが導入された大きいサイトでは、クラスタを利用できます。クラスタは、サービスの特定のサブセットを実行するように構成された GIS サーバのグループです。下の図では、クラスタ A はマップ サービスを実行するように構成することができ、(処理能力の高い)クラスタ B はジオプロセシング サービスを実行するように構成できます。
![]() |
クラスタを使用した複数コンピュータのサイト。各クラスタは、独自のサービスのサブセットを実行します。 |
バッチ ジオコーディングなどの一部のサーバ処理は CPU を集中的に使用します。この種の処理にクラスタ化されたサーバを使用すると、サイト内の他のコンピュータが解放され、残りのサービスは邪魔されることなく、オンライン状態を維持できます。
クラスタ化は、異なる種類のハードウェア リソースがある場合にも有効です。たとえば、古いサーバや遅いサーバを独自のクラスタに配置して、優先順位の低いジョブを実行することができます。
詳細については、「GIS サーバ クラスタについて」をご参照ください。
複数の Web サーバの使用
サイトの可用性を高く保つために、Web サーバ層に冗長性を持たせることもできます。下の図では、Web Adaptor がインストールされた 2 つの Web サーバが、ポート 80 でサイトへの同一エントリ ポイントとして機能しています。これにより、いずれかの Web サーバで予定外の停止が発生したときに、サイトを継続的に稼働させることができます。最初の Web サーバ コンピュータの負荷を減らすためにも有効です。
![]() |
Web サーバ層に冗長性があるサイト。クラスタはオプションです。 |
複数コンピュータのサイトの使用事例と利点
複数コンピュータのサイトは、単一のコンピュータでは処理できない数のユーザに対応する必要があるエンタープライズ環境に最適です。このアーキテクチャでは、コンピュータを必要なだけ追加し、サイトの処理能力を何倍にもできます。ユーザの要求に応じて GIS サーバを追加することもできます。これが役立つのは、使用統計に基づく自動スケーリングを提供している Amazon EC2 のようなクラウド環境です。
複数コンピュータのサイトは、ダウンタイムが許されないサイトにも向いています。1 台の GIS サーバがオフラインになっても、他の GIS サーバがサイトを継続的に稼働させることができます。
複数コンピュータのサイトの欠点
複数コンピュータのサイトでは、高度なセットアップが要求され、明らかにより多くのハードウェア リソースが必要になります。このサイトは GIS サーバがオフラインになっても問題なく稼働できるため、サーバ管理者は、コンピュータが利用できなくなっていないか把握するために、独自の監視または警告スケジュールを立てる必要があります。
まとめ
ArcGIS Server は、大規模な環境と小規模な環境の両方に対応できるように設計されています。サイトの構築に着手したときには、小さく始めて、1 台のコンピュータにすべてのコンポーネントをインストールすることができます。本番環境のサイトを導入する準備が整ったとき、または対応する必要のあるユーザが増えたときには、GIS サーバを追加できます。エンタープライズ Web サーバ(Web Adaptor 経由)またはデータ サーバを使用して、サイトを既存の IT インフラストラクチャに統合することもできます。最後に、ArcGIS Server アーキテクチャの多くのコンポーネントを二重化するか、並列に実行し、単一障害点を避けることができます。