Node.js アプリのスケーリングとオートスケーリング

Node.js アプリのスケーリングと自動スケーリング

オートスケーリングは、CPU負荷の変化に応じて Node.js アプリを実行するインスタンス数を増減させます。忙しい時間帯ではより多くのキャパシティが確保され、静かな時間帯ではコストが低くなります。このガイドでは KPanel タブ、すべての設定、課金対象、およびアプリを安全にスケーリングする方法を説明します。

KPanel におけるスケーリングの場所

1. KPanel にサインインします。
2. 左側のサイドバーで ウェブサイト をクリックし、サイトをクリックします。
3. サイトのタブストリップで 詳細設定 を開き、スケーリング をクリックします。

直接アドレスは /websites/<site-id>/autoscale です。古い /websites/<site-id>/scaling アドレスもまだ機能し、同じ場所に移動します。

1 つのタブ、1 つの構成

KPanel は以前、このセクションに スケーリング と オートスケール の 2 つのタブを持っていました。どちらも同じ構成の 2 つのビューでしたが、迷いやすかったため、現在は単一の スケーリング タブになっています。ライブステータス、設定、最近のスケールイベント、および現在の課金期間の使用量とコストパネルがすべて 1 か所にあります。

動作原理

アプリはプロセスクラスタとして実行されます。オートスケーリングは実行中のインスタンス全体の平均 CPU を監視し、設定したしきい値に応じてインスタンスを追加または削除します。

クラスタモードが必要です。アプリがまだクラスタモードで実行されていない場合、オートスケーリングを有効にするとクラスタモードに切り替わります。これには簡単な再起動が伴います。ページがそれを通知します。

ライブステータスの読み方

ステータスカードは 3 つのことを表示します：

• インスタンス: 現在実行中の数。
• 平均 CPU: これらのインスタンス全体の平均 CPU。
• クラスタ: アプリがクラスタモードにあるかどうか。いいえと表示される場合、オートスケーリングを有効にするとクラスタモードに切り替わります。

アプリが実行されていない場合、カードはゼロを表示する代わりにそう表示します。

タブは 最後のスケール も表示し、最新のスケールイベントの時間、または なし を表示します。

設定

マスタースイッチは設定カードヘッダーのトグルです。オートスケーリングが off の場合、設定は淡色表示され、アプリは現在のインスタンス数で実行されたままになります。

適切な開始値：

• 最小インスタンス 1 または 2。 単一インスタンスの再起動によってアプリがオフラインになることに対応できない場合は 2。
• 最大インスタンス をピーク時に支払う用意がある数に設定します。上限ではありません。
• スケールアップを約 70 % で設定します。 使用しないヘッドルームに対して料金を払わないほど十分に高く、リクエストがキューイングを開始する前にキャパシティを追加するための時間がある程度低い。
• スケールダウンを約 30 % で設定します。 2 つのしきい値の間に大きな差を保つ。
• 数分のクールダウン。 これは最も過小評価される設定です。

スケールイベント

タブは最新のものから順に最近のスケールイベントを一覧表示し、各イベントは方向、前後のインスタンス数、トリガーとなった CPU 読み取り値、および時刻を示します。

これはアプリの動作がおかしかったときに読むログです。数分以内に上下のイベントが連続するのは、しきい値が近すぎるか、クールダウンが短すぎることを意味します。単一のスケールアップがそのまま戻らないのは、負荷が高いままであることを意味し、これは構成の問題ではなく容量の問題です。予想されたときにイベントが全くないのは、CPU がしきい値を超えなかったか、オートスケーリングが off になっていることを意味します。

オートスケーリングのコスト

プランの基本割り当てを超えるインスタンスは秒単位で計測され、課金されます。タブは現在の期間について以下を表示します：

• インスタンス時間使用, 時間と分で、下に生のインスタンス秒数。
• この期間に支払った額。
• 月末の予測, これまでの使用状況から外挿。
• トラッキング, 記録された合計のうち課金されたウィンドウの数。
• 期間の進行状況, 月の日数のうち経過した日数。

秒単位のレートは同じパネルの上部に表示されるため、課金対象の数値は常にそれが適用される使用量の次に表示されます。

最小値にスケールダウンすると計測が停止します。オートスケーリングを完全に off にすると、アプリは現在のインスタンス数で実行されたままになるため、コストが理由で off に切り替える場合は最初に最小値に戻してください。

アプリを安全にスケーリングする

ページには警告があり、それはその上で最も重要なことです。Node.js アプリはインスタンス全体で安全にスケーリングするためにクラスタセーフである必要があります。

実際には、これは以下を意味します：

メモリ内セッションステートなし。 サインインしたユーザーのセッションが 1 つのインスタンスのメモリに存在する場合、リクエストが別のインスタンスに到達するたびにサインアウトされます。セッションを共有ストアに移動させます。

正確性に依存する場合、メモリ内キャッシュなし。 各インスタンスは独自のキャッシュを持ちます。一貫している必要があるキャッシュは共有である必要があります。

読み戻すことを期待する場合、ローカルファイルシステムへの書き込みなし。 1 つのインスタンスによってローカルディスクに書き込まれたアップロードは、他のインスタンスには見えません。共有ストレージに書き込みます。

保護されていないスケジュール済み作業なし。 タイマーがアプリ内で実行される場合、すべてのインスタンスがそれを実行するため、4 つのインスタンスでの毎夜のジョブは 4 回実行されます。スケジュール済み作業を cron ジョブに移動するか、ロックで保護してください。Cron Jobs を参照してください。

インスタンス数が安定している場合の想定なし。 インスタンスインデックスで作業を分割する何かは、数が変わった瞬間に壊れます。

これらのいずれかがアプリに当てはまる場合は、オートスケーリングを有効にする前に修正してください。クラスタセーフでないアプリは、どのインスタンスがどのリクエストを処理したかによって異なる断続的で再現が難しい方法で失敗します。

トラブルシューティング

トグルを有効にできません。 有効にするにはサイトの書き込み権限が必要です。読み取り専用ロールでは、コントロールは無効になります。

オートスケーリングを有効にしたときにアプリが再起動されました。 予想されることです。クラスタモードへの切り替えには再起動が必要であり、それは 1 回発生します。

ユーザーがランダムにサインアウトされています。 クラスタセーフではない典型的な症状。セッションはメモリ内にあり、リクエストは異なるインスタンスに到達しています。

インスタンスがスケールアップされ、降りてきませんでした。 負荷がスケールダウンしきい値を上回ったままであるか、トラフィックとは独立して CPU を高く保っているものがあります。イベントリストを確認し、アプリが実際に何をしているのか確認してください。

スケジュール済みジョブが数回実行されました。 すべてのインスタンスがそれを実行しました。cron ジョブに移動するか、ロックを追加してください。

何もスケールしていません。 トグルが on、アプリが実行中、クラスタモードが有効であることを確認します。次に、CPU がイベントリストのスケールアップしきい値を実際に超えたかどうかを確認してください。

コストが予想より高いです。 イベントリストでフラッピングを確認し、最大インスタンス数を下げてください。

関連ページ

• Site Performance and APM CPU が実際のボトルネックであるかどうかを確認するため。
• Site Uptime Monitoring スケーリングが実際に可用性を改善しているかどうかを確認するため。
• Cron Jobs 正確に 1 回実行する必要があるスケジュール済み作業用。
• Resizing a Cloud Server より多くのインスタンスではなく、より大きなマシンが必要な場合。