Skip Navigation
Show nav
Heroku Dev Center
  • Get Started
  • ドキュメント
  • Changelog
  • Search
  • Get Started
    • Node.js
    • Ruby on Rails
    • Ruby
    • Python
    • Java
    • PHP
    • Go
    • Scala
    • Clojure
  • ドキュメント
  • Changelog
  • More
    Additional Resources
    • Home
    • Elements
    • Products
    • Pricing
    • Careers
    • Help
    • Status
    • Events
    • Podcasts
    • Compliance Center
    Heroku Blog

    Heroku Blog

    Find out what's new with Heroku on our blog.

    Visit Blog
  • Log inorSign up
View categories

Categories

  • Heroku のアーキテクチャ
    • Dyno (アプリコンテナ)
    • スタック (オペレーティングシステムイメージ)
    • ネットワーキングと DNS
    • プラットフォームポリシー
    • プラットフォームの原則
  • コマンドライン
  • デプロイ
    • Git を使用したデプロイ
    • Docker によるデプロイ
    • デプロイ統合
  • 継続的デリバリー
    • 継続的統合
  • 言語サポート
    • Node.js
    • Ruby
      • Bundler の使用
      • Rails のサポート
    • Python
      • Python でのバックグランドジョブ
      • Django の使用
    • Java
      • Maven の使用
      • Java でのデータベース操作
      • Play Framework の使用
      • Spring Boot の使用
      • Java の高度なトピック
    • PHP
    • Go
      • Go の依存関係管理
    • Scala
    • Clojure
  • データベースとデータ管理
    • Heroku Postgres
      • Postgres の基礎
      • Postgres Getting Started
      • Postgres のパフォーマンス
      • Postgres のデータ転送と保持
      • Postgres の可用性
      • Postgres の特別なトピック
    • Heroku Redis
    • Apache Kafka on Heroku
    • その他のデータストア
  • モニタリングとメトリクス
    • ログ記録
  • アプリのパフォーマンス
  • アドオン
    • すべてのアドオン
  • 共同作業
  • セキュリティ
    • アプリのセキュリティ
    • ID と認証
    • コンプライアンス
  • Heroku Enterprise
    • Private Space
      • インフラストラクチャネットワーキング
    • Enterprise Accounts
    • Enterprise Team
    • Heroku Connect (Salesforce 同期)
      • Heroku Connect の管理
      • Heroku Connect のリファレンス
      • Heroku Connect のトラブルシューティング
    • シングルサインオン (SSO)
  • パターンとベストプラクティス
  • Heroku の拡張
    • Platform API
    • アプリの Webhook
    • Heroku Labs
    • アドオンのビルド
      • アドオン開発のタスク
      • アドオン API
      • アドオンのガイドラインと要件
    • CLI プラグインのビルド
    • 開発ビルドパック
    • Dev Center
  • アカウントと請求
  • トラブルシューティングとサポート
  • Integrating with Salesforce
  • 言語サポート
  • Node.js
  • Node.js アプリケーションの並列性の最適化

Node.js アプリケーションの並列性の最適化

日本語 — Switch to English

この記事の英語版に更新があります。ご覧の翻訳には含まれていない変更点があるかもしれません。

最終更新日 2021年12月09日(木)

Table of Contents

  • アプリでの並列性の有効化
  • ローカルでのテスト
  • 並列性レベルのチューニング
  • アクションでの確認

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

Node バージョン < 12​ は、追加のメモリを自動的に利用することができません。Node は、約 1.5 GB のハードメモリ制限がある V8 をベースに構築されているため、プロセスは同じものを割り当てます。

代わりに、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

​dyno タイプ​クラスターワーカーの数
​Free、Hobby、Standard-1x​1
​Standard-2x​2
​Performance-M​5
​Performance-L​28

Private Space

​dyno タイプ​クラスターワーカーの数
​Private-S​2
​Private-M​5
​Private-L​28

Performance-L dyno の場合、アプリケーションは、その 14 GB のメモリに推奨される 28 個のワーカーで適切に動作します。ただし、アプリケーションをテストして、それだけの数の並列プロセスを実際にサポートできるかどうかを確認することをお勧めします。

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

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

WEB_CONCURRENCY​ を直接設定することもできますが、これにより、dyno サイズが変更されたときにアプリが自動的に再クラスタリングできなくなります。

アクションでの確認

起動時に 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

関連カテゴリー

  • Node.js
Yarn 2 への移行 Node.js のメモリ使用のトラブルシューティング

Information & Support

  • Getting Started
  • Documentation
  • Changelog
  • Compliance Center
  • Training & Education
  • Blog
  • Podcasts
  • Support Channels
  • Status

Language Reference

  • Node.js
  • Ruby
  • Java
  • PHP
  • Python
  • Go
  • Scala
  • Clojure

Other Resources

  • Careers
  • Elements
  • Products
  • Pricing

Subscribe to our monthly newsletter

Your email address:

  • RSS
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku Blog
    • Heroku News Blog
    • Heroku Engineering Blog
  • Heroku Podcasts
  • Twitter
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku
    • Heroku Status
  • Facebook
  • Instagram
  • Github
  • LinkedIn
  • YouTube
Heroku is acompany

 © Salesforce.com

  • heroku.com
  • Terms of Service
  • Privacy
  • Cookies
  • Cookie Preferences