質問
Integrateサービスのスケーラビリティを変更した場合のメリット・デメリットと、JVM Non-Heap Memory枯渇の解消に有効かどうかを教えてください。
回答
スケーラビリティの数値はIntegrateサービスが使用するPod数に対応します。スケーラビリティを2に設定した場合、2つのPodが作成されます。
▼メリット
- ロードバランサーによりリクエスト（スクリプト実行）が各Podに負荷分散されます。
- 1つのPodが停止した場合でも、後続のリクエストは残りのPodで処理されるため、可用性が向上します。
▼デメリット
構成変更によって1Pod あたりのCPUおよびメモリが減少する場合、CPUやメモリ構成に対してデータ処理量が多いとCPUクレジットやネットワーク帯域幅に制限がかかり、スクリプト実行時間が長くなる事例が確認されています。
▼JVM Non-Heap Memory枯渇への有効性について
HULFT Square では、スクリプトの実行単位でPodに対してリクエストを行います。スケーラビリティを2にした場合、負荷分散や可用性には効果がありますが、1つのスクリプトが2つのPodに分散して処理されるわけではありません。そのため、スケーラビリティを増やす構成変更は「JVM Non-Heap Memoryの枯渇」の解消に対して有効性は低いと考えられます。
JVM Non-Heap Memory枯渇の解消には、1Pod あたりのリソースを増強するスケールアップのアプローチが推奨されます。
補足
【FAQ】Integrateサービスのスペックが原因で発生するエラーについて
コメント
0件のコメント
記事コメントは受け付けていません。