ArcGIS のマップ サービスまたはイメージ サービスのキャッシュを Amazon EC2 (Elastic Compute Cloud) に作成するのは、クラウドの外部でキャッシュを作成する場合と比較して次の点で異なります。
- インスタンスは、多くのサイズと料金の中から自由に選択できます。
- キャッシュを配置できるインスタンスにボリュームを追加できます。
このトピックでは、これらの要素について詳しく説明します。
インスタンスのサイズと料金の選択
Amazon EC2 は、さまざまなインスタンス サイズと仕様を提供しています。それぞれのインスタンスは、使用時間あたりの料金が異なります。インスタンスが大きいほど、特に多くのメモリを使用できるほど、タイルを高速に生成できます。インスタンスが小さいほどタイルの生成に時間がかかりますが、コストは低くなります。
高性能なインスタンスを使用して、アタッチされた Amazon EBS (Elastic Block Store) ボリューム上にキャッシュを作成できます。キャッシュの作成が完了したら、EBS ボリュームをデタッチして、通常の (小さくて料金の低い) インスタンスにアタッチできます。その後、キャッシュの作成に使用した高性能なインスタンスを終了できます。このようにすると、比較的高価なインスタンスを必要以上に使用せずに、クラウドの能力を利用してキャッシュを作成することができます。
経済性と速度を考えて決定しなければならない場合があります。時間あたりの料金が安い、性能の低いインスタンスを使用することが、最も経済的な選択であるとは限りません。キャッシュの総コストは、タイルの作成に要した時間に依存するためです。一方、最も高性能なインスタンスを使用しても、キャッシュの総コストは高くなる可能性があります。キャッシュの作成に要する時間が短くても、時間あたりの料金は高いためです。
小さなテスト キャッシュ (中都市のサイズなど) とカスタム AMI (Amazon Machine Image) またはサイト テンプレートを使用すると、比較的料金の低いテストをさまざまなインスタンス タイプで実施して、キャッシュに最も経済的なタイプを見つけることができます。
高性能な EC2 インスタンス タイプは、多くの更新ワークフローを短時間で処理しなければならないスケジュールされたキャッシュ更新に適しています。
キャッシュ作成時に使用するマップ サービスのインスタンス数の選択
EC2 の各インスタンスでは、仮想 CPU コアの数が決まっています。この数値は、アマゾン ウェブ サービス マネジメント コンソールでインスタンス タイプを選択するときに表示されます。コアの数は、キャッシュの作成に投入する CachingTools のジオプロセシング サービスのインスタンス数を決定する際に役立ちます。使用するサービス インスタンスが多すぎると CPU が過負荷になり、サービス インスタンスが少なすぎすると CPU を十分に活用できません。
最適な数は試行錯誤を繰り返せばわかりますが、まず CachingTools サービスの最大インスタンス数を n + 1 にして試してください。ここで、n はサイト内の 1 つの EC2 インスタンス上にある仮想コアの数です。
自動スケーリング
大きなキャッシュを構築する場合、CPU の使用量が増えるのにともなって、キャッシュ上で機能する EC2 インスタンスの数を自動で増やす自動スケーリング トリガーを設定したいと考えるかもしれません。しかし、自動スケーリングは、予想外のトラフィックの増加を処理する場合により適しています。キャッシュを作成する場合、大幅な処理能力が必要であることはすでにご存じでしょう。したがって、自動スケーリング トリガーを介して順次インスタンスが起動するのを待つよりも、キャッシュを作成する前に必要なインスタンスをすべて起動するほうがより合理的です。
キャッシュを配置する場所の決定
「アマゾン ウェブ サービスへのデータの転送方法」で説明したように、データを配置できる場所にはさまざまなタイプがあります。キャッシュは最初に作成されるとき、EC2 インスタンスにアタッチされた EBS ボリュームに書き込まれます。このボリュームは、サイトを構築するときにアタッチされます。このボリュームの大きさが十分である場合、キャッシュをここに配置して問題ありません。このボリュームが小さすぎる場合は、既存のデータ ボリュームのスナップショットから作成したより大きなボリュームに置き換えてから、そのボリュームにサーバー キャッシュ ディレクトリを登録できます。
EC2 インスタンスの C またはルート ドライブには、キャッシュを構築しないでください。インスタンスが終了すると、キャッシュが失われてしまいます。
ローカル ディスク上に既存のキャッシュが存在し、Amazon Simple Storage Service (S3) バケットを使用するのが便利である場合は、CompactV2 キャッシュを Amazon S3 内のバケットにコピーし、そこにマップ キャッシュを格納することができます。キャッシュ ディレクトリとして登録されたクラウド ストアを使用してキャッシュを作成したり、管理することはできません。キャッシュの利用がサポートされている場合、キャッシュの格納形式は、CompactV2 である必要があります。この形式は、最高のパフォーマンスを実現するように最適化されています。既存のキャッシュがさらに古い格納形式を使用している場合は、[マップ キャッシュ格納形式のアップグレード (Upgrade Map Cache Storage Format)] ジオプロセシング ツールを使用して CompactV2 形式にアップグレードします。
- CompactV2 形式でキャッシュを作成するには、この形式を使用している新しいキャッシュされたマップ サービスまたはイメージ サービスを公開するか、[マップ キャッシュ格納形式のアップグレード (Upgrade Map Cache Storage Format)] ジオプロセシング ツールを使用して既存のキャッシュを CompactV2 形式に変換します。
- Amazon S3 バケットを AWS 上の ArcGIS Server サイトと同じリージョン内に作成します。
- サービス キャッシュをローカル ドライブから AWS 上の ArcGIS Server サイトにコピーし、それらを Amazon S3 バケット内の arcgiscache というフォルダーに配置します。
コンテンツを S3 バケットにコピーする例については、AWS のドキュメントをご参照ください。なお、キャッシュが非常に大きい場合 (たとえば、数テラバイトのサイズ)、キャッシュをディスクで Amazon に送付して、アップロードしてもらうことが必要な場合があります。
- キャッシュされたサービスが実行されているサイトの ArcGIS Server Manager にサイン インし、S3 バケットをクラウド ストアおよびキャッシュ ディレクトリとして、AWS 上の ArcGIS Server サイトに登録します。
- ArcGIS Server Manager にログインしたまま、以下のいずれかを実行します。
- 既存のサービスを停止し、S3 バケット内の新しいクラウド ストア キャッシュ ディレクトリを指すように、サービスのキャッシュ ディレクトリを変更します。
- ステップ 3 で S3 バケットに配置したキャッシュを提供する新しいサービスを公開します。
- サービスを再起動します。
注意:
マップ サービスのキャッシュを更新した場合、更新されたキャッシュは、ArcGIS Server サイトのローカル ドライブ上に生成されます。サービスのユーザーが更新されたキャッシュのコンテンツを利用できるように、そのキャッシュを S3 バケットに再びコピーする必要があります。