ArcGIS では、アプリ、マップ、レイヤー、サービス、データなど、さまざまなリソースをユーザーが利用可能にすることができます。 リソースにアクセスしているユーザーに最適なパフォーマンスを提供するには、リソースのタイプに応じて最適化の方法が異なることを理解することが重要です。 使用できるオプションは、バックエンド データ ソース、地理空間サービスのタイプ、またはその他の要因によって異なる場合があります。 さまざまなタイプの最適化を理解することは、有益で効果的なユーザー エクスペリエンスを確保するうえで重要な部分です。
このセクションでは、ユーザーのニーズ、ネットワーク設計、およびキャッシュ オプションを評価するための一般的な戦略について説明します。 特定の最適化戦略の詳細については、「Web マップとアプリの最適化」および「データ ソースとストレージの最適化」をご参照ください。
最適化とは、単に HTTP リクエストの応答時間を最小限に抑えるだけではありません。 迅速で低遅延ではあるが役に立たないレスポンスを送信するサービスは、必ずしも最適化されているとは限りません。 リソースまたはサービスを使用するユーザーとその理由を確認します。 ユーザーがリソースを操作することで回答を得たい質問を理解します。 構造化テストを使用して、ユーザーがリソースにアクセスするさまざまなクライアント デバイスでリソースが適切に機能することを確認します。 開発時およびリソースが一般に使用できるようになった後の両方で、リソースの有用性に関するユーザーからのフィードバックを取り入れます。
ユーザーのニーズは、実装する価値があるパフォーマンス最適化の種類を知るのにも役立ちます。 小さな内部グループによってリソースが 1 日に数回しか使用されない場合、毎秒数千ものリクエストにスケーリングするまで最適化することはそれほど重要ではありません。 ただし、その同じ最適化は、世界中の一般の視聴者が使用するリソースに対して不可欠である可能性があります。
ArcGIS コンポーネントがデプロイされるネットワークの設計は、パフォーマンスに影響する主要な要因です (パフォーマンスが良くなることも、悪くなることもあります)。 エンタープライズ システムの多くは本質的にグローバルであり、広範なネットワークの条件と接続性でユーザーにサービスを提供しており、ArcGIS コンポーネントとワークフローとの間には、ネットワーク接続への依存性という点で重要な違いがあります。 ArcGIS ワークフローに関するネットワークの考慮事項は、このトピックの範囲を超える内容になりますが、最初の推奨事項と検討事項として次のようなものがあります。
リソースに対するリクエストが繰り返されると、それらのリソースを生成する際にかなりの計算オーバーヘッドが必要になる場合があります。 キャッシュされたレスポンスを提供すると、そのオーバーヘッドを回避し、システム リソースの使用量と応答時間の両方を削減できます。 キャッシュを最大限に活用すれば、ArcGIS リソースのパフォーマンスが大幅に向上します。
ArcGIS で使用できるさまざまな Web アプリケーションやサービスでキャッシュを使用するための万能なアプローチはありませんが、代わりに、検討と計画に基づいて使用する必要があるさまざまなパターンがあります。 一般的なキャッシュの方法には次のようなものがあります:
ラスター タイルとベクター タイルのキャッシュは、マップ、フィーチャ、またはイメージ サービスを介して動的にアクセスされる可能性もある入力データを取得して、タイルにキャッシュします。 これらのタイルは、レンダリングされたデータを表示する定義済みの標準化された画像です。 キャッシュされたタイルを使用すると、クライアントは特定の縮尺で事前にレンダリングされた複数のタイルを同時にリクエストできるため、サーバーがバックエンドデータにアクセスして描画するまで待ち時間があります。 ラスター タイル キャッシュとベクター タイル キャッシュはどちらも、タイル レイヤーを作成することで有効になりますが、フィーチャ タイル キャッシュでは、サービスのプロパティの追加構成が必要です。
これらの各キャッシュ戦略では、サービスの最適化時に、さまざまな構成、オプション、および選択を行う必要があります。 これらの領域に関する追加の手引きについては、Esri のドキュメント、リソース、および会議録をご参照ください。
関連リソース:
マップ イメージ レイヤー タイルは、データが事前にレンダリングされたビューを表示するラスター画像で、表示範囲ごとに複数の結合されたタイルのセットとしてクライアントで描画されます。 ラスター タイルは、マップ サービス、ホスト フィーチャ サービス、またはイメージ サービスから作成できますが、それぞれについて若干異なる考慮事項があります。
ラスター タイル キャッシュは、1 つの主要なカートグラフィック表現で表示する必要がある、比較的静的なデータを配信する際に効果的な方法です。 マップ キャッシュの作成は、時間と計算リソースの両方が大量に必要になる可能性があるため、更新頻度の低いデータに最適です。 ラスター タイルは優れたパフォーマンスとスケーラビリティーを備えていますが、ユーザーは属性のクエリー、フィーチャの識別、シンボルの変更、ラベリング レイヤーの無効化などの機能を使用できません。
ラスター タイルは、長年にわたってカートグラフィック ベースマップの配信に使用されてきましたが、これらのサービスは、パフォーマンス、マップの品質、および柔軟性のさまざまな理由から、今日ではベクター ベースマップを最も多く使用しています。 ラスター タイルは、衛星写真や正射投影撮影に基づく多くの画像ベースマップやサービスを提供するため、今でも使用されています。これらのサービスは、アプリケーションやツールの背景として、バランスの取れた 1 枚のイメージ レイヤーを表示することを目的としています。
マップ イメージ レイヤー キャッシュの詳細については、次のリソースをご参照ください:
ベクター タイル キャッシュは概念的にラスター タイル キャッシュに似ていますが、タイルは、ベクター フィーチャをジオメトリーおよび属性として格納する (プロトコル バッファーに基づいた) 圧縮バイナリー ファイルであり、個々のタイルに切り取られてから、クライアントで個別のスタイル定義に従って再度組み立てられてレンダリングされます。
ベクター タイル キャッシュは、ラスター タイルがその他の理由で制限的であるか、不適切である場合に適しています。 ベクター タイルはラスター タイルよりも高速に生成でき、サイズも小さいため、タイル セットの保存や、ネットワーク経由でクライアントに転送される際の速度面でも利点があります。
また、ベクター タイルでは、ベクター タイル スタイルを使用して動的レンダリングを行うこともできます。ベクター タイル スタイルは、ブラウザーやネイティブ アプリケーションなどのクライアントで完全に構成や更新を行え、同じ単一のベクター タイル レイヤーを使用して、各レイヤーを動的に表示または非表示にでき、属性に基づくフィルタリングが可能で、同じデータについて複数の異なるカートグラフィック バージョンを表示できます。
ベクター タイルやラスター タイルとは異なり、フィーチャ タイルは計画されたプロセスによって事前に生成されません。 代わりに、標準ズーム レベルの標準化されたデータ範囲をリクエストする機能対応クライアントによって生成されます。 別のクライアント間でも、これらのリクエストは同一なので、これらのフィーチャをキャッシュし、別のクライアントで再利用したり、別のクライアントに送信し直したりできます。 この機能は、この機能を使用するように設計されたクライアントのみが使用でき、主に ArcGIS Maps SDK for JavaScript で使用され、ArcGIS Pro や、ArcGIS Maps SDK で構築されたネイティブ アプリケーションからも使用されます。
フィーチャ タイルの使用は、次の 2 つの重要な前提に基づいています:
ArcGIS Online のホスト フィーチャ サービスには、レイヤーの描画の最適化を有効にするオプションが含まれています。これにより、より小さい (縮小された) 縮尺の表示に使用される低解像度のデータをデータベース内に生成できます。 この低解像度のデータは、小さい縮尺を使用するときにフィーチャ タイル生成プロセスによって自動的にクエリーされるため、レスポンスのパフォーマンスが向上します。
フィーチャ タイル キャッシュの詳細については、次のリソースをご参照ください:
ArcGIS Enterprise では、マップ サービスとフィーチャ サービスの両方を構成して、ユーザーのブラウザーが Etag 値に基づいてレスポンス コンテンツのキャッシュを利用できるようにする Cache-Control ヘッダーを返すことができます。
クライアントが ArcGIS Server にリクエストを送信して、この設定を適用してマップのエクスポートをリクエストしたり、フィーチャ サービスにクエリーを実行したりすると、通常、サーバーからのレスポンスは、ブラウザーによってキャッシュされ、一定期間再利用できるようになります。 ただし、アプリケーションでのマップまたはフィーチャ サービスとその関連データの使用方法に応じて、ブラウザーがキャッシュ内のレスポンスを使用する期間を調整することを検討してください。 これを行うには、cacheControlMaxAge というプロパティをサービスの JSON (JavaScript Object Notation) 定義に追加します。
コンテンツ配信ネットワーク (CDN) は、ユーザーに地理的に近いエッジ サーバーにコンテンツをキャッシュします。 CDN は、データベース クエリーの必要性をなくし、ネットワーク移動の延長による遅延を短縮することで、リクエストの応答時間を短縮します。
パブリックに共有されているホスト フィーチャ レイヤーと ArcGIS Online でホストされている Web アプリケーションの静的アセットは、フィーチャ タイルと静的アプリのレスポンスのキャッシュにグローバル CDN を自動的に利用します。 ArcGIS Online でのホスト フィーチャ レイヤーの CDN キャッシュの制御について詳細をご覧ください。 ArcGIS Online CDN は、パブリック キャッシュ マップ イメージ レイヤー (ラスター タイル) とベクター タイル レイヤーのほか、さまざまな ArcGIS Online ベースマップ サービスのレスポンスを高速化するためにも使用されます。
CDN は ArcGIS Enterprise でホストされている Web アプリケーションでも使用できますが、CDN でのキャッシュに適した静的アセット (HTML、CSS、JavaScript ファイルなど) と、予期しないユーザーの動作を避けるためにキャッシュを行わない動的 REST API レスポンスを注意して区別する必要があります。 また、アップグレードに関連する CDN の使用は特に注意して検討してください。 CDN キャッシュは、ArcGIS Enterprise がアップグレードされたとき、またはアプリケーションが変更されたときに強制的に無効化して、ユーザーが古い情報を受け取らないようにする必要があります。
ブログ記事「AWS CloudFront を使用した ArcGIS Enterprise へのコンテンツ配信ネットワーク (CDN) アプローチ」では、ArcGIS Enterprise で CDN を使用する例の 1 つが紹介されています。