Amazon EC2 でのキャッシュの作成
ArcGIS のマップ、イメージ、グローブの各サービスのキャッシュを Amazon EC2（Elastic Compute Cloud）に作成するのは、クラウドの外部でキャッシュを作成する場合と比較していくつかの点で異なります。
- インスタンスは、多くのサイズと料金の中から自由に選択できます。
- キャッシュは、クラウド内のさまざまな場所に配置できます。
このトピックでは、これらの要素について詳しく説明します。
インスタンスのサイズと料金の選択
Amazon EC2 は、さまざまなインスタンス サイズと仕様を提供しています。それぞれのインスタンスは、使用時間あたりの料金が異なります。インスタンスが大きいほど、特に多くのメモリを使用できるほど、タイルを高速に生成できます。インスタンスが小さいほどタイルの生成に時間がかかりますが、コストは低くなります。
高性能なインスタンスを使用して、アタッチされた Amazon EBS（Elastic Block Store）ボリューム上にキャッシュを作成できます。キャッシュの作成が完了したら、EBS ボリュームをデタッチして、通常の（小さくて料金の低い）インスタンスにアタッチできます。その後、キャッシュの作成に使用した高性能なインスタンスを終了できます。このようにすると、比較的高価なインスタンスを必要以上に使用せずに、クラウドの能力を利用してキャッシュを作成することができます。
経済性と速度を考えて決定しなければならない場合があります。時間あたりの料金が安い、性能の低いインスタンスを使用することが、最も経済的な選択であるとは限りません。キャッシュの総コストは、タイルの作成に要した時間に依存するからです。一方、最も高性能なインスタンスを使用しても、キャッシュの総コストは高くなる可能性があります。キャッシュの作成に要する時間が短くても、時間あたりの料金は高いからです。
小さなテスト キャッシュ（中都市のサイズなど）とカスタム AMI（Amazon Machine Image）またはサイト テンプレートを使用すると、比較的料金の低いテストをさまざまなインスタンス タイプで実施して、キャッシュに最も経済的なタイプを見つけることができます。
高性能な EC2 インスタンス タイプは、多くの更新ワークフローを短時間で処理しなければならないスケジュールされたキャッシュ更新に適しています。
キャッシュ作成時に使用するマップ サービスのインスタンス数の選択
EC2 の各インスタンスでは、仮想 CPU コアの数が決まっています。この数値は、Launch Instance ウィザードでインスタンス タイプを選択するときに表示されます。コアの数は、キャッシュの作成に投入する CachingTools のジオプロセシング サービスのインスタンス数を決定する際に役立ちます。使用するサービス インスタンスが多すぎると CPU が過負荷になり、サービス インスタンスが少なすぎすると CPU を十分に活用できません。
最適な数は試行錯誤を繰り返せばわかりますが、まず CachingTools サービスの最大インスタンス数を 2n + 1 にして試してください。ここで、n はサイト内の 1 つの EC2 インスタンス上にある仮想コアの数です。これは、n+1 のインスタンス数から開始することを推奨している社内環境用の ArcGIS Server ヘルプとは異なりますので注意してください。
手動スケーリングと自動スケーリング
大きなキャッシュを構築する場合、CPU の使用量が増えるのにともなって、キャッシュ上で機能する EC2 インスタンスの数を自動で増やす自動スケーリング トリガを設定したいと考えるかもしれません。しかし、自動スケーリングは、予想外のトラフィックの増加を処理する場合により適しています。キャッシュを作成する場合、大幅な処理能力が必要であることはすでにご存じでしょう。したがって、自動スケーリング トリガを介して順次インスタンスが起動するのを待つよりも、キャッシュを作成する前に必要なインスタンスをすべて起動するほうがより合理的です。
キャッシュを配置する場所の決定
「Amazon Web Services へのデータの転送方法」で説明したように、データを配置できる場所にはさまざまなタイプがあります。キャッシュは最初に作成されるとき、EC2 インスタンスにアタッチされた EBS ボリュームに書き込まれます。このボリュームは、サイトを構築するときにアタッチされます。このボリュームの大きさが十分である場合、キャッシュをここに配置して問題ありません。このボリュームが小さすぎる場合は、別のボリュームを作成およびアタッチして、そこにサーバ キャッシュ ディレクトリを登録する必要があります。
EC2 インスタンスの C ドライブには、キャッシュを構築しないでください。インスタンスが終了すると、キャッシュが失われてしまいます。
最終的に、Amazon S3（Amazon Simple Storage Service）上にキャッシュを移動またはコピーを配置したくなるかもしれません。Amazon S3 上にバックアップを保持する場合は、EBS スナップショットを作成できます。スナップショットを使用すると、Amazon S3 上のドライブにバックアップを効果的に作成できます。何らかの理由で既存のボリュームにエラーが発生した場合、このスナップショットを使用して新しい EBS ボリュームを迅速に作成できます。
また、Amazon S3 からタイルを提供して、JavaScript、Flex、または Silverlight アプリケーションから、それらのタイルにカスタム タイル レイヤとしてアクセスすることもできます。こうすることの利点は、タイルが実行中のサービスに依存しないことと、オプションの Amazon CloudFront を使用すると、インターネットを介して世界中にタイルを高速に配信できることです。この目的でタイルを Amazon S3 に移動する場合は、Amazon Web Services API またはサードパーティの Amazon S3 用フロンドエンド アプリケーションを使用して、タイルを EBS ボリュームから転送できます。また、クラウドの外部にキャッシュを作成した場合もこれを実行できます。