オンデマンドでのマップ キャッシュ

ArcGIS Server には、ユーザのアクセスに応じてマップ キャッシュ タイルをオンデマンドで作成するオプションがあります。キャッシュされていないエリアに最初にアクセスしたユーザは、該当する部分のタイルがサーバによって描画されるまで待つ必要があります。これらのタイルはサービスのキャッシュ フォルダに追加され、サーバ管理者によって更新または削除されるまでサーバ上に残ります。したがって、後からそのエリアにアクセスしたユーザは、タイルが作成されるのを待たずに済みます。

オンデマンド キャッシュをうまく利用すれば、時間とディスク容量をかなり節約することができます。ほとんどのマップは、マップの縮尺が大きい(拡大表示されている)場合は特に、マップ ユーザにとって意味のない、使い道のない、あるいは興味のないエリアを表示します。オンデマンド キャッシュは、こうした必要のないタイルを作成して格納する作業を不要にすると同時に、ユーザに必要なエリアのみを表示できるオプションを提供します。

オンデマンド キャッシュは便利な機能ですが、使い方を誤ったりむやみに使用したりすると、パフォーマンスを低下させることがあります。ここでは、オンデマンド キャッシュを最も効果的に使用するためのヒントを示します。

パフォーマンスの最適化

完全なマップ キャッシュの利点の 1 つは、きれいで複雑なマップを非常にすばやく提供できることです。これは、サーバがマップのタイル イメージを配布するだけで済み、リクエストのたびにマップを描画する必要がないためです。一方、オンデマンド キャッシュを使用する場合は、ユーザがキャッシュされていないエリアにアクセスしたときに、サーバがタイルを動的に描画する必要があります。サーバは一連のタイルを一度に作成するため、実際には、この動的な描画には通常のリクエストよりも時間がかかります。この一連のタイルの寸法は、アンチエイリアスが使用されている場合は 2048 x 2048 ピクセル、アンチエイリアスが使用されていない場合は 4096 x 4096 ピクセルになります。

サーバがタイルを 1 つずつ作成しないのはなぜでしょうか。そのようにすると、ラベリング エンジンが隣接タイルに存在するラベルを見分ける方法がないので、重複するラベルが多数作成されてしまうからです。サーバが一連のタイルを一度に作成するのはそのためです。サーバ管理者は広いエリアを適度な時間内に描画できるようにマップを作成しておく必要があります。このセクションでは、オンデマンド キャッシュのパフォーマンス コストを削減するための方法をいくつか紹介します。

オンデマンド キャッシュを使用する場所の決定

オンデマンド キャッシュを構築する際には、オンデマンドで作成するエリアと、事前にキャッシュしておくエリアを決定することが最も重要です。オンデマンド キャッシュを使ってキャッシュ全体を構築することは避けてください。最も需要が高いと予想されるエリアのタイルは常にあらかじめ作成しておき、ユーザがタイルをオンデマンドでリクエストすることによるサーバ リソースの消費を最小限に抑えてください。

マップにおいて最も需要が高いエリアを判断するにはどうすればよいでしょうか。これは主に、マップの目的とユーザ層によって決まります。一般的なベースマップでは、地名、道路、海岸線、公園などの主要エリアに、他のエリアよりもアクセスが集中する可能性があります。Microsoft Hotmap は、オンライン ベースマップにおいて需要が高いタイルを複数の縮尺で示す、興味深いケース スタディです。縮尺が大きいほど、未使用のタイルの割合が高くなることがわかります。

主題マップでは、需要の高い場所の傾向が異なるかもしれません。たとえば、炭鉱会社が使用するマップの場合は、鉱物資源が最も豊富なエリアの需要が最も高い可能性があります。これは、一般の人にとって重要でない非居住エリアや山岳エリアにも当てはまります。

事前にキャッシュしておくエリアを決定するためには、オンラインまたはデスクトップ上で、現在のマップの使用パターンを調べる必要があります。ユーザのアクセス傾向とユーザが検索するフィーチャをざっと調べてみるだけでも、さまざまな情報が得られます。

また、データの可用性と解像度も重要です。特定エリアのデータが不足している、または存在しない場合は、そうしたエリアのキャッシュを省略することができます。ユーザがオンデマンド タイルをリクエストしたとしても、表示するものがなければ、描画にそれほど時間はかかりません。

また、データがマップの目的に深く結び付いていることも考えられます。たとえば、輸送部門に勤務していて、道路や鉄道が密集しているエリアを事前にキャッシュしておくとします。[カーネル密度(Kernel Density)] などの空間解析ツールは、関心の高いフィーチャが集中しているエリアを特定するのに役立ちます。

ユーザが最も頻繁にアクセスするエリアを割り出した後、それらのエリアを分離するフィーチャクラスを作成する必要があります。[マップ サービス キャッシュのタイルを管理(Manage Map Server Cache Tiles)] ツールを実行するときに、このフィーチャクラスを参照して、フィーチャクラスの境界内のタイルだけが作成されるようにします。

モデルまたはスクリプトで複数のツールを連結し、需要の高い場所のフィーチャクラスを取得することもできます。モデルでは、需要が高いことが予想されるさまざまなフィーチャを入力値として使用し、必要に応じてフィーチャをバッファリングするか、それらの密度を割り出します。最後に、出力で後処理を実行し、キャッシュ テンプレートに適したフィーチャクラスが得られるようにします。たとえば、キャッシュの境界として使用されるフィーチャクラスには、小さなフィーチャが無数に含まれることがないようにします。[ポリゴンの集約(Aggregate Polygons)] ツールを使用すると、小さいホールとポリゴンを削除できます。[ディゾルブ(Dissolve)] ツールを使用すると、複数のフィーチャからマルチパート フィーチャを作成できます。

マップにおいて需要の高いエリアを分離すればするほど、タイルをオンデマンドで作成するのではなく、キャッシュ済みのタイルで処理できるリクエストの数が増えていきます。たとえば、高い縮尺レベルでは、マップ エリアのほんの一部をキャッシュするだけで、ユーザ リクエストの 99% に対処することができます。他の縮尺レベルを戦略的にキャッシュとして保存するために、ディスク容量を使用することもできます。

マップのテストと最適化

多くの組織が所有する、もともとはデスクトップ上での GIS 操作に使用するためのものであったマップ ドキュメント(MXD)は複雑です。多くの場合、Web ユーザが期待するような応答時間を達成するためには、これらのマップを調整する必要があります。

マップを変更する前に、狭いエリアのテスト キャッシュを作成して、基準となる数字を割り出しておくとよいでしょう。都市部と農村部、平野部と山岳部など、マップ上で異なる地形がうまく組み合わされているエリアを選択します。テスト キャッシュを作成するのにかかった時間を記録してください。続いて、オンデマンド キャッシュを有効にし、キャッシュされていないエリアにズームします。さまざまな縮尺でタイルを表示するのにかかった時間を記録してください。この時点でパフォーマンスが許容レベルであれば、調整をする必要はありません。

オンデマンドでのタイル作成のパフォーマンスを向上させる、または全般的なキャッシュの作成速度を向上させるには、ArcMap で [マップ サービス公開] ツールバーを使用して、マップでパフォーマンスを低下させているボトルネックを特定し、修正する必要があります。このツールバーを使用してマップ サービス定義(MSD)ファイルを保存し、マップ サービスを公開するときにこのファイルをソース ドキュメントとして使用する必要があります。多くのマップ サービスにおいて、MXD ではなく MSD をソース ドキュメントとして使用すると、パフォーマンスが大幅に向上します。

より高度な方法でマップ サービスの非効率的なレイヤを検出するには、ArcGIS Server のログ レベルを「情報: 詳細」に設定します。ArcMap でブックマークにズームするなど、マップ サービスへの描画リクエストを 1 つ作成します。次に、ログで ExportMapImage リクエストを調べ、各レイヤの描画時間を確認します。描画に最も時間がかかっているレイヤはすぐに特定できます。マップ上のエリアを無作為に選択し、さまざまなキャッシュ縮尺でこの作業を繰り返すことをお勧めします。作業が完了したら、ログ レベルを「標準」に戻すことを忘れないでください。「情報: 詳細」レベルは、通常は必要とされない多くの情報を書き出します。

マップを最適化した後は、別のテスト キャッシュを作成し、タイルをオンデマンドで作成するのにかかった時間を記録します。パフォーマンスに依然として問題がある場合は、次のいずれかを実行することができます。

  • より大きなエリアを事前にキャッシュします。これにより、オンデマンド タイルが使用されることが少なくなります。最大縮尺では、オンデマンド キャッシュを最も需要の少ないエリアに限定することができます。そうすれば、一度に多くのフィーチャを描画する必要がなくなります。
  • 完全キャッシュを作成します。すべてのタイルを事前にキャッシュすれば、タイルをオンデマンドで作成する必要がなくなります。このオプションは、完全キャッシュを作成するための時間とディスク容量があり、キャッシュが頻繁に更新されない場合に最も適しています。キャッシュ作成のサーバのダウンタイムが心配である場合は、夜間や週末に実行するキャッシュ ジョブをプログラムとして作成し、キャッシュがいっぱいになるまで着実に構築することができます。また、1 つのサービス インスタンスをキャッシュに割り当て、他のインスタンスにユーザ リクエストを処理させることもできます。
  • ダイナミック サービスを使用します。完全キャッシュの構築が実現可能なオプションではなく、ダイナミック サービスのパフォーマンスが容認できるものである場合は、キャッシュの構築を完全に省略することもできます。このオプションでは、最適なパフォーマンスは提供されませんが、データは常に最新の状態に保たれます。

タイルの更新

ソース データベースを編集する際には、ユーザが変更データを参照できるようにする前に、キャッシュを更新する必要があります。フィーチャクラスに基づいてエリアを事前にキャッシュし、キャッシュの残りの部分は必要に応じて追加するという方法を採用する場合は、その更新に必要なエリアがすべて含まれるように注意する必要があります。

タイルをオンデマンドで作成している場合、キャッシュを更新するために選択できる手法として、次の 2 つがあります。

関連項目


7/10/2012