GIS サービスでトラフィック パターンとユーザーの要求が変化するのに合わせて、サービスで利用可能なリソースを調整することができます。
サービスのスケーリング 例
組織で使用されるリソースを維持しながら、パフォーマンスの要求を満たすには、サービスで利用可能なリソースをいつどのようにしてスケールするかを理解することが重要です。 次の例は、組織の管理者がリソースのスケーリングを検討するために必要な仮説シナリオです。
- 公共機関の Web マップが突然、大量のトラフィックを受信するようになり、パフォーマンスの遅延が生じています。 組織の管理者がシステム ログを表示し、Web マップが使用しているマップ サービスに過度な負荷がかかっていることを確認します。 はじめに、共有リソースの使用から専用リソースの使用へサービス モードを変更できます。 次に、そのサービスの配置で Pod レプリカを増やすことができます。 マップ サービスに専用リソースを提供することで、管理者はサービスの大量のトラフィックがパフォーマンスの問題なしに処理されることを保証できます。
- ある測量会社が、組織内で何百ものフィーチャ サービスを蓄積してきました。 それらすべてのサービスが共有モードに設定されているため、1 つのサービス配置でそれらのサービスをサポートしています。 どのサービスも大量のトラフィックを受信しませんが、組織の GIS コンテンツの全体的な使用がサービス配置に負荷をかけています。 組織の管理者は、サービスデプロイメント内の Pod レプリカの数を増やします。 動作する共有インスタンスが増えたことで、組織の多くのフィーチャ サービスへのトラフィックが適切に処理されます。
- コンテンツ移行プロジェクト中に、市役所の GIS 組織がこの会社の組織に多くの Web マップと Web レイヤーを再公開する予定です。 時間的な制約のため、短時間でこれを完了する必要があります。 Web マップと Web レイヤーの基になるサービスの公開は、PublishingTools ユーティリティ サービスによって実行されるため、そのユーティリティ サービスが使用できるコンピューター リソースによって、どれだけ早く公開できるかが決まります。 組織の管理者は、PublishingTools サービスデプロイメントで Pod レプリカを一時的に増やし、プロジェクト中の公開効率を向上させます。 プロジェクトの完了後、サービスデプロイメントで Pod レプリカを減らし、コンピューター リソースを節約します。
サービスのスケーリングオプション
サービスをスケールするには、次の 2 つの主要なオプションを使用できます。
サービス モードの調整
共有リソースを使用しているマップ サービスまたはフィーチャ サービスが一定のトラフィックを受信している場合、専用リソースを使用するようにそのインスタンス タイプを切り替えることができます。 これにより、そのサービスに専用の新しいサービス リソース プールが開きます。
システム リソースの再割り当て
ArcGIS Enterprise Manager を使用して、サービス配置に割り当てられている Pod の数をスケールすることができます。 このオプションは、サービスを提供している専用リソースの数が不十分で、パフォーマンスの遅延が生じている場合に便利です。
これにより、その配置で Pod レプリカの数を増やすことができます。 サービスに使用できる Pod の数を増やすと、Kubernetes クラスターがサービス配置の既存の Pod の追加のレプリカ (サービス構成およびサービス インスタンスを含む) を生成します。
これにより、サービスのインスタンスの可用性と合計スループットが向上すると同時に、サービスのメモリと CPU の消費量も増えます。 Kubernetes インフラストラクチャがスケールされることになるため、このオプションには耐障害性があります。障害が発生した Pod は、他の Pod に影響することなく自動的に復元されます。
注意:
組織が配置される Kubernetes クラスターのコンピューター ノード数には限りがあります。 多くの GIS サービスをスケーリングすることで、組織が ArcGIS Enterprise on Kubernetes に割り当てられているコンピューター リソースの制限に達することがあります。 その場合は、IT 管理者に連絡して、Kubernetes クラスターにノードを追加してください。