GIS サービスを公開したら、ベスト プラクティスとして、サービス使用状況の統計情報を表示するなどしてサービスを監視し、利用パターンを理解して、それに応じて観測したトラフィックに基づきリソースを調整する方法を把握します。 サービスでトラフィック パターンとユーザーの要求が変化するのに合わせて、いくつかの方法で対応することができます。 要求とパフォーマンスの期待に応えるために、次の方法でサービスのリソースを最適化することを検討してください。
- サービス モードを調整して、サービスの専用リソースを最大化します。
- サービスに割り当てられるポッド数を指定することで、サービスを手動でスケーリングします。
- サービスにポッドが自動的に割り当てられる閾値を指定することで、自動スケーリングを有効化します。
どのオプションを選択するかを決めるには、これらのシナリオを検討してください。
スケーリングのタイプ
サービスは、手動でスケーリングするか、自動スケーリング機能を使用して自動でスケーリングすることができます。 どちらの場合も、サービスをスケーリングする方法には、水平方向 (イン/アウト) のスケーリングと垂直方向 (アップ/ダウン) のスケーリングがあります。 サービスは、構成されているモードに関係なく、共有と専用のどちらでもスケーリングできます。
- 水平方向のスケーリング - サービスデプロイメントにポッドを追加します。 たとえば、1 つのポッドから多数のポッドにスケーリングします。 手動および自動スケーリングでサポートされています。
- 垂直方向のスケーリング - デプロイメント内にある現在のポッド セットに CPU またはメモリを追加します。 手動スケーリングでサポートされています。
サービスに使用できるポッドの数を増やすと、Kubernetes クラスターがサービスデプロイメントの既存のポッドの追加のレプリカ (サービス構成およびサービス インスタンスを含む) をポッド内に生成します。
スケーリングにより、サービスのインスタンスの可用性と合計スループットが向上すると同時に、サービスのメモリと CPU の消費量も増えます。 Kubernetes インフラストラクチャがスケールされることになるため、このオプションには耐障害性があります。障害が発生した Pod は、他の Pod に影響することなく自動的に復元されます。 また、システム内の他のサービスや他のコンポーネントに影響しない独立および分離したスケーリングが可能です。
注意:
組織が配置される Kubernetes クラスターのコンピューター ノード数には限りがあります。 多くの GIS サービスを手動または自動でスケーリングすることで、組織が ArcGIS Enterprise on Kubernetes に割り当てられているコンピューター リソースの制限に達することがあります。 その場合は、IT 管理者に連絡して、Kubernetes クラスターにノードを追加してください。 これに対するお使いの環境での解決策として、Cluster Autoscaler の使用を検討してください。
水平方向のスケーリング
水平方向のスケーリングでは、サービスデプロイメントにポッドを追加します。 たとえば、1 つのポッドから多数のポッドにスケーリングします。 これは、手動および自動スケーリングでサポートされています。
上の例は、専用モードで実行中のジオプロセシング サービスに対する水平方向のスケーリングを示しています。 ポッドの追加が必要になると、それに応じてサービスデプロイメントが手動または自動で調整されます。 この例では、サービスデプロイメントにポッド レプリカが追加されます。
次の例では、デプロイメントにポッド レプリカを追加することで、共有フィーチャ サービスデプロイメントが水平方向にスケーリングされています。 共有リソースの初期セットでは、3 つのフィーチャ サービスが 4 つのポッドでサポートされています。 要求が着実に増加するのに伴い、サービスデプロイメント内のポッドは 8 つに増えました。
垂直方向のスケーリング
垂直方向のスケーリングは、デプロイメント内にある現在のポッド セットに CPU またはメモリを追加します。これは、手動スケーリングでサポートされています。
上の例は、専用モードで実行中のイメージ サービスに対する垂直方向のスケーリングを示しています。 能力の追加が必要になると、それに応じて専用ポッドを手動または自動で調整できます。 この場合、増強されたリソース (CPU やメモリ) がポッドに割り当てられます。
別の例では、専用モードのマップ サービスに追加リソースが必要なくなったときに、そのリソースが垂直方向にスケール ダウンされます。
次の例では、共有マップ サービスデプロイメントに垂直方向のスケーリングが使用されています。 CPU やメモリが必要になると、それに応じて専用ポッドを調整できます。 この場合、増強された CPU またはメモリのリソースが、属している 3 つのポッドに割り当てられます。
シナリオ
組織で使用されるリソースを維持しながら、パフォーマンスの要求を満たすには、サービスで利用可能なリソースをいつどのようにしてスケールするかを理解することが重要です。 次の例は、組織の管理者がリソースをスケーリングする際に検討する必要がある仮説シナリオです。
- 公共機関の Web マップが突然、大量のトラフィックを受信するようになり、パフォーマンスの遅延が生じています。 組織の管理者がシステム ログを表示し、Web マップが使用しているマップ サービスに過度な負荷がかかっていることを確認します。 はじめに、共有リソースの使用から専用リソースの使用へサービス モードを変更できます。 次に、そのサービスのデプロイメントで Pod レプリカを増やすことができます。 マップ サービスに専用リソースを提供することで、管理者はサービスの大量のトラフィックがパフォーマンスの問題なしに処理されることを保証できます。
- ある測量会社が、組織内で何百ものフィーチャ サービスを蓄積してきました。 それらすべてのサービスが共有モードに設定されているため、1 つのサービス デプロイメントでそれらのサービスをサポートしています。 どのサービスも大量のトラフィックを受信しませんが、組織の GIS コンテンツの全体的な使用がサービス デプロイメントに負荷をかけています。 組織の管理者は、サービスデプロイメント内のポッド レプリカの数を増やすことで、サービスを手動でスケーリングすることにします。 動作する共有インスタンスが増えたことで、組織の多くのフィーチャ サービスへのトラフィックが適切に処理されます。
- コンテンツ移行プロジェクト中に、市役所の GIS 組織がこの会社の組織に多くの Web マップと Web レイヤーを再公開する予定です。 時間的な制約のため、短時間でこれを完了する必要があります。 Web マップと Web レイヤーの基になるサービスの公開は、PublishingTools ユーティリティ サービスによって実行されるため、そのユーティリティ サービスが使用できるコンピューター リソースによって、どれだけ早く公開できるかが決まります。 組織の管理者は、PublishingTools サービスデプロイメントで Pod レプリカを一時的に増やし、プロジェクト中の公開効率を向上させます。 プロジェクトの完了後、サービスデプロイメントで Pod レプリカを減らし、コンピューター リソースを節約します。
上の最初の 2 つのシナリオを見ると、過度な負荷がかかっているマップ サービスまたは多数のフィーチャ サービスの同時使用によって過度な負荷がかかっているシステムがあり、専用マップ サービスまたは共有フィーチャ サービスデプロイメントの手動スケーリングは、最も現実的な方法ではない可能性があります。 手動スケーリングには、スケーリングするポッド数を決定するために、負荷の常時監視と負荷パターンの理解が必要です。 負荷が断続的で予測不能な場合、多数のポッドを手動で追加すると、システムの負荷が大きくないときはリソースの浪費となります。 反対に、負荷が高くなりポッドの追加が必要になるときは、システムがスケール アウトできる必要があります。
これは、管理者が自動スケーリングを活用するのに最適な場合となります。 自動スケーリングを使用すると、ポッドの最小数を維持しながら、設定した CPU の閾値に基づいて、システムがスケール アウトできるポッドの最大数を設定できます。 この方法は、負荷の変化に応じてポッドを増減させるタイミングを自動的に検出できます。 これにより、システムを常時監視する必要がなくなり、システムのリソースを節約できます。
サービス モードの調整
共有リソースを使用しているマップ サービスまたはフィーチャ サービスが一定のトラフィックを受信している場合、専用リソースを使用するようにサービス モードを調整することができます。 これにより、そのサービスに専用の新しいサービス リソース プールが開きます。
手動スケーリング
サービスの要求が予測可能または安定している場合は、サービスに割り当てられるポッドの数を指定するか、サービスに使用できるリソース (CPU/メモリ) を増やすことで、手動でサービスデプロイメントをスケーリングできます。 このオプションは、サービスを提供している専用リソースの数が不十分で、パフォーマンスの遅延が生じている場合に便利です。
サービスの監視後に要求の増加を確認した場合や、サービスのパフォーマンス上の問題が報告された場合は、必要に応じてポッド数を増やすことができます。 要求が下がり始めたら、ポッド数を減らすことができます。
自動スケーリング
サービスの要求が予測不能または断続的である場合、自動スケーリングを有効化して、システム リソース全体の効率性を最大化できます。
サービスの自動スケーリングを有効化すると、サービスデプロイメント内のポッド レプリカは、要求に応じて自動的に増減します。 サービスデプロイメントは、CPU やメモリなどのあらかじめ定義された条件を使用して、ポッドの増減の要求を計算し、それに応じて調整します。
サービス インスタンスの役割
マップ、イメージ、ジオプロセシング、ジオコーディングのような、ホストされていないサービスデプロイメントには、サービスのデプロイメントの各ポッド内で実行されるサービス インスタンスが含まれています。 これらは、各ポッドの能力を表し、これらのサービスの要求を処理するために使用される基になるプロセスです。 これらのプロセスの調整とスケーリングがサポートされています。ただし、ポッド レベルで調整およびスケーリングして、Kubernetes の利点 (フォールト トレランス、分離、レジリエンス、自動スケーリングなど) を活用することをお勧めします。