自動スケーリング設定の調整

オートスケーリング機能により、サービスの使用状況に応じて適切な数のインスタンスが確保されます。 ただし、より良い結果を得るためには、環境の使用状況を監視し、その挙動を観察することで設定を調整する必要があります。

自動スケーリング設定の調整は、 目標平均使用率値 を設定することから始まります。

自動スケーリング動作

Liferay CloudはKubernetes Horizontal Pod Autoscaler (HPA)アルゴリズムを使ってインスタンス数を計算します。 CPUとメモリの使用率は、このアルゴリズムを使用して評価されます。

サービスは、現在の利用状況が設定された目標利用率値 と比較してどうなっているかに基づいてスケーリングされます。

1. インスタンス数は、現在の利用率と目標利用率の比率に基づいて比例的に調整され、次の整数に切り上げられます。

   CPUとメモリは別々に評価されます。 サービスは、結果として得られるインスタンス数が多い方を使用します。

2. スケーリング動作は、 currentUtilization / targetUtilization の比率が以下のしきい値を超えた場合にのみ発生します。

   • 比率が ≥ 1.1 の場合にスケールアップが発生します。
   • スケールダウンは、比率が 0.9 または (currentInstances - 1) / currentInstances の小さい方以下である場合に発生します。

   これらのしきい値により、負荷の軽減によってインスタンスを削除することが正当化される場合にのみ、スケールダウンが行われることが保証されます。

3. スケーリングアクションは以下のルールに従います。

   • 閾値に達すると、直ちに規模拡大が行われる。
   • 過去5分以内にスケーリングイベントが発生していない限り、しきい値に達するとすぐにスケールダウンが発生します。 その場合、縮小処理はスキップされます。 5分間の猶予時間が経過すると、しきい値に達した時点でサービスは直ちに縮小されます。

例えば、サービスが 2 つのインスタンスで実行されている場合、(2 - 1) / 2 = 0.5 であるため、利用率が 0.5 以下になった場合にのみ、1 にダウンスケールされます。 この場合、0.5は0.9よりも小さいため、0.5が有効なスケールダウンの閾値となる。

目標平均利用率の設定

システム管理者は、 目標平均使用率 を指定できます。 この値は、Liferay DXPサービス全体におけるメモリとCPUの使用量の平均値です。 オートスケーリングが開始される前に、その値のしきい値を超えなければなりません。

例えば、3つのサービスインスタンスがそれぞれメモリの70%、90%、95%を使用している場合、平均メモリ使用率は85%になります。 目標平均使用率が90に設定されている場合、アップスケーリングは不要です。この場合、平均メモリ使用率が目標値を超えた場合にのみアップスケーリングが発生します。

注

デフォルトの目標利用率は80%です。 大量のメモリを使用するサービス（例えば、 liferay サービス）は、デプロイ直後であっても、この目標使用率値をすぐに超えてしまう可能性があります。

使用可能なメモリの合計は、 LCP.json のメモリ プロパティによって指定され、 LCP.json による構成 で参照されます。

サービスの LCP.jsonの autoscale プロパティでターゲットの平均使用率を指定します：

"autoscale": {
   "cpu": 80,
   "memory": 90
}

最も効率的なオートスケーリングを実現するには、アプリケーション固有のニーズに合わせて目標平均利用率を調整してください。 例えば、この構成ではCPU使用率が非常に優先されます。

"autoscale": {
   "cpu": 60,
   "memory": 95
}

autoscale プロパティが設定されていない場合、CPUとメモリの両方の使用率の目標平均使用率はデフォルトで80になります。

JVMベースの自動スケーリング

ほとんどの場合、目標とする利用率の値を調整するだけで、望ましい自動スケーリング動作を実現できます。 しかし、JVMから未使用メモリが積極的に再割り当てされないため、一部の環境では期待どおりにダウンスケールしない場合があります。 これは、オペレーティングシステムがアプリケーションのパフォーマンスを最適化するために、ページキャッシュにメモリを保持することを優先する場合に発生する可能性があります。

このような場合、デフォルトのスケーリング動作ではなく、 JVM ベースのスケーリングを使用した方が、より良い自動スケーリング結果が得られる場合があります。 このグラフは、その動作の一例を示しています。緑色の線は、ガベージコレクションが発生する際のJVMのヒープ使用量を示し、青色の線は、サービスのコンテナ内でアプリケーションに割り当てられたメモリの合計量を示しています。

JVM ベースのスケーリングは、 自動スケーリングの動作と同じですが、オペレーティングシステムによって割り当てられたメモリ量ではなく、JVM のヒープ メモリの使用状況を尊重します。 環境によっては、JVM ベースのスケーリングの方がパフォーマンスが向上する可能性があります。

• アプリケーションは、メモリを積極的に解放するようにガベージコレクションを設定しています。

• アプリケーションはデフォルトで大量のメモリを割り当てるため、自然とオートスケーリングのしきい値に近い状態になります。

• アプリケーションの総メモリ割り当て量は、トラフィックが少ない時間帯でも高いままです。

LCP.json ファイルの autoscale オブジェクトで、JVM ベースの自動スケーリングを有効にします。

1. メモリ プロパティを高い値に設定します (例: 1000)。

2. prometheus.googleapis.com|jvm_memory_pool_used_bytes|gauge プロパティを追加し、JVM のヒープ内の合計バイト数に比例する値を設定します。

例えば、この LCP.json 設定では、JVM ヒープの使用しきい値を 12 GB の約 80% に設定しています。

"autoscale": {
   "cpu": 90,
   "memory": 1000,
   "prometheus.googleapis.com|jvm_memory_pool_used_bytes|gauge": "10307921510"
}

極めて高い メモリ しきい値は、コンテナ メトリクスに基づく自動スケーリングの標準メカニズムを事実上無効にし、JVM ベースのスケーリングを優先します。

その代わりに、このサービスは設定されたバイト数を目標メモリしきい値として使用します。これにより、一部のアプリケーションでは、オートスケーリングがサービスのメモリ使用量をより正確に測定できるようになります。

指標と目標値の選択

オートスケーリングは自動的に行われますが、その動作は設定したメトリクスと目標値によって異なります。 カスタムメトリクスを使用するとより詳細な制御が可能になりますが、実際の使用状況に基づいて調整する必要があります。

指標の選択

CPUとメモリの使用率は、ほとんどの環境において十分です。 カスタムメトリクスは、アプリケーションのボトルネックをより的確に反映する場合にのみ使用してください。

アプリケーションのボトルネックを反映する指標を選択してください。 サポートされているメトリクスについては、 代替スケーリングメトリクス を参照してください。

LCP.jsonでは、メトリクスは prometheus.googleapis.com|<metric_name>|<type> の形式を使用します。

• メモリ負荷: prometheus.googleapis.com|jvm_memory_used_bytes|gauge、 prometheus.googleapis.com|jvm_memory_pool_used_bytes|gauge (例については JVM ベースの自動スケーリング を参照)
• 高並行性: prometheus.googleapis.com|catalina_threadpool_currentthreadsbusy|<type>、 prometheus.googleapis.com|jvm_threads_current|gauge
• データベース制限: prometheus.googleapis.com|com_zaxxer_hikari_pool_hikaripool_{1,2,3...}_activeconnections|<type>

注

<type> を Prometheus で定義されているメトリック タイプ (例えば、 gauge または counter) に置き換えてください。

ヒント

矛盾するシグナルを避けるため、単一の主要指標を使用してください。

カスタムメトリックを使用する場合は、競合するシグナルを避けるために、 メモリ または CPU の値を大きな数値 (たとえば、 1000に設定してください。

目標値の選択

目標値は実際の利用パターンを反映していなければならない。 通常負荷時とピーク負荷時の環境を監視し、パフォーマンスが低下し始める値を特定し、その値よりわずかに低い値を目標値として設定します。 その結果生じる挙動を観察し、必要に応じて値を少しずつ調整してください。

過去のデータがない場合は、JVM容量（例えばヒープ使用量）の70～80%程度の目標値から始め、観測された動作に基づいて調整してください。 この方法は、カスタムメトリクスを使用する場合に最も有効です。

規模縮小が確実に機能するようにする

オートスケーリングは、使用量が目標値を下回ったからといってすぐにダウンスケールするわけではありません。 その指標は大幅に低下しなければならない。

一般的に、インスタンス数が少ない場合、ダウンスケールは最も制約が厳しくなります。 例えば、2つのインスタンスを実行している場合、メトリックが目標値の約半分まで低下した場合にのみ、1つのインスタンスにスケールダウンします。

目標値が80で、2つのインスタンスを実行している場合、メトリックが40程度まで低下した場合にのみ、1つのインスタンスにスケールダウンする可能性があります。

インスタンス数が増えるほど、必要な削減幅は小さくなるため、ダウンスケーリングは目標値に近い値で行われる。 例えば、インスタンス数が10で目標値が100の場合、指標が80～90程度まで低下すると、インスタンス数を9に縮小する可能性があります。

指標が十分に低下しない限り、サービスはスケールダウンしない。 縮小が可能になるように目標値を上げる。

よくある落とし穴

• 縮小は行われません。目標値が、指標の最小値に比べて低すぎるためです。
• 頻繁なスケーリングイベント：ターゲットが通常の使用状況に近すぎます。
• 指標の競合：CPUまたはメモリのターゲットがカスタム指標と干渉します。
• 指標が間違っています：選択された指標は、実際のボトルネックを反映していません。

代替スケーリング指標

環境が CPU やメモリ以外のメトリックにより適している場合は、これらの Prometheus メトリックを LCP.json の autoscale プロパティで使用してください。 これらの値は、パーセンテージではなく、絶対的な閾値を使用しています。

Tomcat（リクエスト処理とスレッド）

アプリケーションサーバーにおけるリクエストのスループットとスレッドの使用状況を追跡します。

prometheus.googleapis.com|catalina_globalrequestprocessor_processingtime|unknown
prometheus.googleapis.com|catalina_globalrequestprocessor_requestcount|unknown
prometheus.googleapis.com|catalina_threadpool_currentthreadcount|unknown
prometheus.googleapis.com|catalina_threadpool_currentthreadsbusy|unknown

データベース接続プール（HikariCP）

データベース接続の使用状況と飽和状態を追跡する。

prometheus.googleapis.com|com_zaxxer_hikari_pool_hikaripool_{1,2,3...}_activeconnections|unknown
prometheus.googleapis.com|com_zaxxer_hikari_pool_hikaripool_{1,2,3...}_idleconnections|unknown

JVMメトリクス

メモリ使用量、ガベージコレクション、スレッドアクティビティを追跡します。

prometheus.googleapis.com|java_lang_threading_threadcount|unknown
prometheus.googleapis.com|jvm_buffer_pool_used_bytes|gauge
prometheus.googleapis.com|jvm_classes_currently_loaded|gauge
prometheus.googleapis.com|jvm_gc_collection_seconds_count|summary
prometheus.googleapis.com|jvm_memory_pool_used_bytes|gauge
prometheus.googleapis.com|jvm_memory_used_bytes|gauge
prometheus.googleapis.com|jvm_threads_current|gauge
prometheus.googleapis.com|jvm_threads_peak|gauge
prometheus.googleapis.com|jvm_threads_state|gauge

プロセス指標

システムレベルのリソース使用状況を追跡する。

prometheus.googleapis.com|process_cpu_seconds_total|counter
prometheus.googleapis.com|process_open_fds|gauge
prometheus.googleapis.com|process_resident_memory_bytes|gauge

関連トピック

• Liferayサービスの拡張