最終更新日 2020年08月10日(月)

Node の別のコンテナサイズへのスケーリング機能は限られています。シングルスレッドであるため、追加の CPU コアを自動的に利用することはできません。

代わりに、Node.js アプリがその使用可能なリソースを最大化するには、複数のプロセスをフォークする必要があります。これは “クラスタリング” と呼ばれ、Node.js Cluster API​ でサポートされています。Cluster API をアプリで直接呼び出すか、またはこの API 経由で多数の抽象化のいずれかを使用することができます。ここでは、throng​ を使用します。

クラスターを使用すると、さまざまな dyno タイプにわたってアプリのパフォーマンスを最適化できます。Heroku Node.js buildpack には、役立つ環境変数が用意されています。

アプリでの並列性の有効化

すべてのアプリケーションでクラスタリングをサポートすることをお勧めします。並列性を使用すると、現在は複数のプロセスの実行を予測していない場合でも、将来のアプリのパフォーマンスに対する制御と柔軟性を向上させることができます。では例​を見てみましょう。

最初に、クラスタリングすべきプロセスの数を決定します。

var WORKERS = process.env.WEB_CONCURRENCY || 1;

2 番目に、新しくクラスタリングされた各プロセスのエントリポイントになる start​ 関数を定義します。

function start() {
  // ...
}

最後に、throng を使用して、アプリを複数のプロセスにクラスタリングします。ワーカーが停止した場合は再生成する必要があることを throng に通知するために、Infinity​ の有効期間を指定します。そのため、WORKERS​ プロセスは常に実行中の状態になります。

throng({
  workers: WORKERS,
  lifetime: Infinity
}, start);

ローカルでのテスト

次のように実行して、クラスターを観察できます。

$ npm start

> example-concurrency@1.0.0 start example-concurrency
> node server.js

Listening on 3000

$ WEB_CONCURRENCY=4

$ npm start

> example-concurrency@1.0.0 start example-concurrency
> node server.js

Listening on 3000
Listening on 3000
Listening on 3000
Listening on 3000

並列性レベルのチューニング

各アプリにはメモリ、CPU、I/O に関する固有の要件があるため、1 つのサイズですべてを満たすスケーリングソリューションはありません。Heroku buildpack には、WEB_MEMORY​ と WEB_CONCURRENCY​ の 2 つの環境変数による妥当なデフォルト値が用意されています。これらはどちらも、特定のアプリケーションに適合するように上書きできます。

• WEB_MEMORY​ は、アプリケーションのプロセスの予測されるメモリ要件 (MB 単位) を指定します。そのデフォルト値は 512 MB です。

• WEB_CONCURRENCY​ は、アプリケーションをクラスタリングするための推奨されるプロセス数を指定します。これは実質的に MEMORY_AVAILABLE / WEB_MEMORY​ です。

クラスタリング時のアプリケーションのメモリ使用の設定に関する詳細​を参照してください。

デフォルト値:

Common Runtime

Private Space

これらの値は、ほとんどのアプリにとって妥当なデフォルト値です。多くの場合、Standard-1X dyno 上での複数のワーカーのクラスタリングはパフォーマンスを向上させるのではなく、むしろ低下させます。ただし、WEB_CONCURRENCY​ と dyno サイズの任意の組み合わせを自由に試してみて、実際のワークロードにとって何が最適であるかを確認することができます。

WEB_MEMORY​ を減らすと、WEB_CONCURRENCY​ が増加します。WEB_MEMORY​ を増やすと、同様に、並列性が低下します。dyno のサイズが変更されると、使用可能なメモリがいっぱいになるように WEB_CONCURRENCY​ が自動的に再計算されます。

アクションでの確認

起動時に Node の並列性設定をログに記録するには、LOG_CONCURRENCY​ 環境設定を設定します。

$ heroku config:set LOG_CONCURRENCY=true

クラスターに対応したアプリを Heroku にデプロイしたら、そのログを末尾監視して、さまざまなコンテナサイズへのスケーリングを観察できます。

$ heroku logs --tail

$ heroku scale web=1:standard-1x

heroku[api]: Resize web to standard-1x
heroku[api]: Scale to web=1
heroku[web.1]: State changed from up to starting
heroku[web.1]: State changed from up to starting
heroku[web.1]: Starting process with command `npm start`
app[web.1]: Detected 512 MB available memory, 512 MB limit per process (WEB_MEMORY)
app[web.1]: Recommending WEB_CONCURRENCY=1
heroku[web.1]: Stopping all processes with SIGTERM
app[web.1]:
app[web.1]: > example-concurrency@1.0.0 start /app
app[web.1]: > node server.js
app[web.1]:
app[web.1]: Listening on 51077
heroku[web.1]: State changed from starting to up

$ heroku scale web=1:performance-l

heroku[api]: Resize web to performance-l
heroku[api]: Scale to web=1
heroku[web.1]: State changed from up to starting
heroku[web.1]: Starting process with command `npm start`
app[web.1]: Recommending WEB_CONCURRENCY=12
app[web.1]: Detected 6144 MB available memory, 512 MB limit per process (WEB_MEMORY)
heroku[web.1]: Stopping all processes with SIGTERM
app[web.1]:
app[web.1]: > example-concurrency@1.0.0 start /app
app[web.1]: > node server.js
app[web.1]:
app[web.1]: Listening on 50092
app[web.1]: Listening on 50092
app[web.1]: Listening on 50092
app[web.1]: Listening on 50092
app[web.1]: Listening on 50092
app[web.1]: Listening on 50092
app[web.1]: Listening on 50092
app[web.1]: Listening on 50092
app[web.1]: Listening on 50092
app[web.1]: Listening on 50092
app[web.1]: Listening on 50092
app[web.1]: Listening on 50092
heroku[web.1]: Process exited with status 143
heroku[web.1]: State changed from starting to up