Node.jsの本番環境インフラストラクチャを最適化する方法：ベストプラクティス

序文

Forward Emailでは、Node.jsの本番環境構築に長年を費やし、完璧な環境づくりに努めてきました。この包括的なガイドでは、パフォーマンスの最適化、監視、そしてNode.jsアプリケーションをスケールアップして毎日数百万件ものトランザクションを処理する際に得られた教訓に焦点を当て、実戦で実証されたNode.jsの本番環境導入のベストプラクティスを共有します。

573% シングルコアパフォーマンス最適化革命

Intel プロセッサから AMD Ryzen プロセッサに移行した結果、Node.js アプリケーションで 573% のパフォーマンス向上 を達成しました。これは単なる小さな最適化ではなく、Node.js アプリケーションの運用環境におけるパフォーマンスを根本的に変えるものであり、あらゆる Node.js アプリケーションにおいてシングルコアパフォーマンスの最適化がいかに重要であるかを実証しています。

Tip

Node.jsの本番環境導入のベストプラクティスでは、ハードウェアの選択が非常に重要です。JavaScriptの実行はシングルスレッドであるため、Node.jsアプリケーションではシングルコアのパフォーマンスが不可欠であり、AMD Ryzenを利用できるという理由から、DataPacketホスティングを選択しました。

Node.js においてシングルコアパフォーマンスの最適化が重要な理由

Intel から AMD Ryzen への移行の結果、次のようになりました。

  • リクエスト処理におけるパフォーマンスが573%向上 (ステータスページのGitHub Issue #1519)
  • 処理遅延を解消し、ほぼ瞬時の応答を実現(GitHub Issue #298)
  • Node.jsの本番環境における価格性能比の向上
  • すべてのアプリケーションエンドポイントにおける応答時間の改善

パフォーマンスの向上は非常に大きく、Webアプリケーション、API、マイクロサービス、その他のNode.jsワークロードを実行する場合でも、本格的なNode.jsの本番環境展開にはAMD Ryzenプロセッサーが不可欠であると考えています。

関連コンテンツ

当社のインフラストラクチャの選択に関する詳細は、以下をご覧ください。

Node.js本番環境のセットアップ: 当社のテクノロジースタック

Node.jsの本番環境へのデプロイにおけるベストプラクティスには、長年の運用経験に基づいた慎重なテクノロジー選択が含まれています。以下では、私たちが使用しているテクノロジーと、これらの選択があらゆるNode.jsアプリケーションに適用される理由についてご説明します。

パッケージマネージャー: 生産効率のためのpnpm

使用方法: pnpm (固定バージョン)

私たちが Node.js の実稼働環境のセットアップに npm と yarn ではなく pnpm を選択したのは、次の理由からです。

  • CI/CDパイプラインでのインストール時間の短縮
  • ハードリンクによるディスク容量の効率化
  • ファントム依存関係を防ぐ厳密な依存関係解決
  • 本番環境デプロイメントでのパフォーマンス向上

Note

Node.jsの本番環境デプロイメントのベストプラクティスの一環として、pnpmなどの重要なツールの正確なバージョンを固定することで、すべての環境とチームメンバーのマシン間で一貫した動作を確保しています。

実装の詳細:

Webフレームワーク: 最新のNode.jsプロダクション向けKoa

私たちが使用するもの:

Node.jsの本番環境インフラとして、ExpressではなくKoaを選択しました。その理由は、最新のasync/awaitサポートと、よりクリーンなミドルウェア構成です。当社の創設者であるNick Baughは、ExpressとKoaの両方に貢献し、本番環境における両フレームワークの深い知見を私たちに与えてくれました。

これらのパターンは、REST API、GraphQL サーバー、Web アプリケーション、マイクロサービスなどを構築する場合に適用されます。

当社の実装例:

バックグラウンドジョブ処理: 実稼働環境の信頼性を高める Bree

使用方法: bree スケジューラ

Bree を開発・保守しているのは、既存のジョブスケジューラが、本番環境の Node.js におけるワーカースレッドのサポートと最新の JavaScript 機能のニーズを満たしていなかったためです。これは、バックグラウンド処理、スケジュールされたタスク、またはワーカースレッドを必要とするあらゆる Node.js アプリケーションに当てはまります。

当社の実装例:

エラー処理: 実稼働環境の信頼性のための @hapi/boom

使用するもの: @hapi/boom

私たちのNode.js製品版アプリケーションでは、構造化されたエラーレスポンスのために@hapi/boomを使用しています。このパターンは、一貫したエラー処理が必要なあらゆるNode.jsアプリケーションで有効です。

当社の実装例:

本番環境でのNode.jsアプリケーションの監視方法

本番環境におけるNode.jsアプリケーションの監視に対する当社のアプローチは、長年にわたる大規模アプリケーション運用を通じて進化してきました。あらゆる種類のNode.jsアプリケーションの信頼性とパフォーマンスを確保するために、複数のレイヤーで監視を実装しています。

システムレベルの Node.js 運用監視

コア実装: helpers/monitor-server.js

使用するもの: node-os-utils

当社の本番環境監視しきい値（実際の本番環境コードより）:

  • ヒープサイズ制限2GB（自動アラート）
  • メモリ使用量25%（警告しきい値）
  • CPU使用量80%（警告しきい値）
  • ディスク使用量75%（警告しきい値）

Warning

これらのしきい値は、弊社の特定のハードウェア構成で機能します。Node.jsの本番環境監視を実装する際は、monitor-server.jsの実装を確認して正確なロジックを理解し、設定に合わせて値を調整してください。

Node.js本番環境向けアプリケーションレベル監視

エラー分類: helpers/is-code-bug.js

このヘルパーは次のものを区別します:

  • 実際のコードバグ はすぐに対処する必要があります
  • ユーザーエラー は想定内の動作です
  • 外部サービスの障害 は制御できません

このパターンは、Web アプリ、API、マイクロサービス、バックグラウンド サービスなど、あらゆる Node.js アプリケーションに適用されます。

ログ記録の実装: helpers/logger.js

当社では、Node.js 実稼働環境で便利なデバッグ機能を維持しながら機密情報を保護するために、包括的なフィールド編集を実装しています。

アプリケーション固有の監視

当社のサーバー実装:

キュー監視： リソース枯渇を防ぐため、リクエスト処理には5GBのキュー制限と180秒のタイムアウトを実装しています。これらのパターンは、キューまたはバックグラウンド処理を使用するすべてのNode.jsアプリケーションに適用されます。

PM2ヘルスチェックによるNode.js本番環境監視

長年の運用経験に基づき、PM2を活用したNode.js本番環境のセットアップを改良してきました。PM2ヘルスチェックは、あらゆるNode.jsアプリケーションの信頼性維持に不可欠です。

PM2ヘルスチェックシステム

コア実装: jobs/check-pm2.js

PM2 ヘルスチェックによる Node.js の本番環境監視には次のものが含まれます。

  • 20分ごとに実行 cronスケジュールにより実行
  • プロセスが正常と判断されるには、最低15分の稼働時間が必要
  • プロセスの状態とメモリ使用量を検証
  • 失敗したプロセスを自動的に再起動
  • インテリジェントなヘルスチェックにより、再起動ループを防止

Caution

Node.jsの本番環境デプロイのベストプラクティスでは、再起動ループを回避するため、プロセスが正常であると判断するまでに15分以上の稼働時間が必要です。これにより、プロセスがメモリ不足などの問題を抱えている場合に、連鎖的な障害が発生するのを防ぎます。

PM2プロダクション構成

エコシステムのセットアップ: Node.js の実稼働環境のセットアップについては、サーバー起動ファイルを参照してください。

これらのパターンは、Express アプリ、Koa サーバー、GraphQL API、またはその他の Node.js アプリケーションを実行している場合に適用されます。

自動 PM2 展開

PM2 デプロイメント: ansible/playbooks/node.yml

当社では、すべてのサーバーにわたって一貫した Node.js の本番環境の展開を確保するために、Ansible を通じて PM2 のセットアップ全体を自動化しています。

生産エラー処理および分類システム

Node.js の本番環境展開における最も重要なベスト プラクティスの 1 つは、あらゆる Node.js アプリケーションに適用されるインテリジェントなエラー分類です。

本番環境向けisCodeBug実装

ソース: helpers/is-code-bug.js

このヘルパーは、運用中の Node.js アプリケーションに対してインテリジェントなエラー分類を提供し、次のことを実現します。

  • 実際のバグをユーザーエラーよりも優先する
  • 実際の問題に焦点を当てることで、インシデント対応を改善する
  • 想定されるユーザーエラーによるアラート疲れを軽減する
  • アプリケーションが原因の問題とユーザーが原因の問題をより深く理解する**

このパターンは、eコマース サイト、SaaS プラットフォーム、API、マイクロサービスなど、あらゆる Node.js アプリケーションで機能します。

弊社のプロダクションログとの統合

ロガー統合: helpers/logger.js

私たちのロガーは isCodeBug を使用してアラート レベルとフィールド編集を決定し、Node.js 実稼働環境のノイズを除去しながら実際の問題について通知を受けられるようにします。

関連コンテンツ

エラー処理パターンの詳細については、以下をご覧ください。

v8-profiler-nextとcpuproを使用した高度なパフォーマンスデバッグ

当社では、高度なプロファイリングツールを使用してヒープスナップショットを分析し、OOM（Out of Memory）問題、パフォーマンスボトルネック、そして本番環境におけるNode.jsのメモリ問題をデバッグしています。これらのツールは、メモリリークやパフォーマンス問題が発生しているNode.jsアプリケーションにとって不可欠です。

Node.jsプロダクション向けのプロファイリングアプローチ

推奨ツール:

  • v8-profiler-next - ヒープスナップショットとCPUプロファイルの生成用
  • cpupro - CPUプロファイルとヒープスナップショットの分析用

Tip

v8-profiler-next と cpupro を組み合わせて使用することで、Node.js アプリケーションの包括的なパフォーマンスデバッグワークフローを構築しています。この組み合わせにより、メモリリークやパフォーマンスのボトルネックを特定し、本番環境のコードを最適化できます。

ヒープスナップショット分析の実装方法

当社の監視実装: helpers/monitor-server.js

当社の本番環境監視機能には、メモリしきい値を超えた際に自動的にヒープスナップショットを生成する機能が含まれています。これにより、OOM（メモリ使用量制限）の問題がアプリケーションクラッシュを引き起こす前にデバッグすることが可能になります。

主な実装パターン:

  • ヒープサイズが2GBのしきい値を超えた場合の自動スナップショット
  • 本番環境でのオンデマンド分析のためのシグナルベースのプロファイリング
  • スナップショットストレージを管理するための保持ポリシー
  • 自動メンテナンスのためのクリーンアップジョブとの統合

パフォーマンスデバッグワークフロー

実際の実装を研究してください:

ヒープスナップショット分析の場合:

  1. スナップショット生成用に v8-profiler-next をインストール
  2. 生成されたスナップショットを分析するために cpupro を使用
  3. monitor-server.js と同様の 監視しきい値を実装
  4. スナップショットストレージを管理するために 自動クリーンアップを設定
  5. 本番環境でオンデマンドプロファイリングを行うために シグナルハンドラーを作成

CPUプロファイリングの場合:

  1. 高負荷時にCPUプロファイルを生成する
  2. cpuproで分析し、ボトルネックを特定する
  3. ホットパスと最適化の機会に焦点を当てる
  4. パフォーマンス改善前後をモニタリングする

Warning

ヒープスナップショットとCPUプロファイルの生成はパフォーマンスに影響を与える可能性があります。スロットリングを実装し、特定の問題を調査する場合やメンテナンス期間中のみプロファイリングを有効にすることを推奨します。

生産監視との統合

当社のプロファイリング ツールは、より広範な監視戦略と統合されています。

  • メモリ/CPUしきい値に基づく自動トリガー
  • パフォーマンス問題検出時のアラート統合
  • パフォーマンス傾向の経時的な追跡のための履歴分析
  • 包括的なデバッグのためのアプリケーションメトリクスとの相関分析

このアプローチは、メモリ リークを特定して解決し、ホット コード パスを最適化し、Node.js 実稼働環境で安定したパフォーマンスを維持するのに役立ちました。

Node.js 本番環境インフラストラクチャのセキュリティ

Ansibleの自動化により、Node.jsの本番環境インフラストラクチャに包括的なセキュリティを実装しています。これらのプラクティスは、あらゆるNode.jsアプリケーションに適用されます。

Node.js本番環境向けシステムレベルセキュリティ

Ansible 実装: ansible/playbooks/security.yml

Node.js 実稼働環境における主要なセキュリティ対策:

  • スワップを無効化 し、機密データがディスクに書き込まれるのを防止
  • コアダンプを無効化 し、機密情報を含むメモリダンプを防止
  • USBストレージをブロック し、不正なデータアクセスを防止
  • カーネルパラメータのチューニング し、セキュリティとパフォーマンスの両方を実現

Warning

Node.jsの本番環境デプロイのベストプラクティスを実装する際に、スワップを無効にすると、アプリケーションが利用可能なRAM容量を超えた場合にメモリ不足による強制終了が発生する可能性があります。私たちはメモリ使用量を注意深く監視し、サーバーのサイズを適切に調整しています。

Node.jsアプリケーションのアプリケーションセキュリティ

ログフィールドの編集: helpers/logger.js

パスワード、トークン、APIキー、個人情報といった機密性の高いフィールドをログから削除します。これにより、ユーザーのプライバシーを保護しながら、あらゆるNode.js本番環境におけるデバッグ機能を維持できます。

インフラストラクチャセキュリティ自動化

Node.js 本番環境向けの完全な Ansible セットアップ:

セキュリティコンテンツ

当社のセキュリティアプローチの詳細については、以下をご覧ください。

Node.jsアプリケーション向けデータベースアーキテクチャ

私たちは、Node.jsアプリケーション向けに最適化されたハイブリッドデータベースアプローチを採用しています。これらのパターンは、あらゆるNode.jsアプリケーションに適用できます。

Node.jsプロダクション向けSQLite実装

私たちが使用するもの:

当社の構成: ansible/playbooks/sqlite.yml

Node.js アプリケーションでは、ユーザー固有のデータに SQLite を使用します。SQLite には次の機能があるためです。

  • ユーザー/テナントごとのデータ分離
  • 単一ユーザークエリのパフォーマンス向上
  • バックアップと移行の簡素化
  • 共有データベースに比べて複雑さの軽減

このパターンは、SaaS アプリケーション、マルチテナント システム、またはデータ分離が必要な Node.js アプリケーションに適しています。

Node.jsプロダクション向けMongoDB実装

私たちが使用するもの:

セットアップ実装: helpers/setup-mongoose.js

当社の構成: config/mongoose.js

Node.js 実稼働環境でのアプリケーション データに MongoDB を使用する理由は、次のとおりです。

  • 進化するデータ構造に対応する柔軟なスキーマ
  • 複雑なクエリに対する優れたパフォーマンス
  • 水平スケーリング機能
  • 豊富なクエリ言語

Note

当社のハイブリッドアプローチは、特定のユースケースに合わせて最適化されています。コードベースにおける実際のデータベース使用パターンを調査し、このアプローチがお客様のNode.jsアプリケーションのニーズに適合するかどうかをご確認ください。

Node.js 本番環境バックグラウンドジョブ処理

Breeをベースにバックグラウンドジョブアーキテクチャを構築することで、信頼性の高いNode.jsの本番環境へのデプロイを実現しました。これは、バックグラウンド処理を必要とするあらゆるNode.jsアプリケーションに当てはまります。

本番環境向け Bree サーバーのセットアップ

主な実装: bree.js

Ansible のデプロイメント: ansible/playbooks/bree.yml

実稼働ジョブの例

ヘルスモニタリング: jobs/check-pm2.js

クリーンアップの自動化: jobs/cleanup-tmp.js

すべての求人: 求人情報一覧を閲覧する

これらのパターンは、以下を必要とするあらゆる Node.js アプリケーションに適用されます。

  • スケジュールされたタスク（データ処理、レポート作成、クリーンアップ）
  • バックグラウンド処理（画像のサイズ変更、メール送信、データのインポート）
  • ヘルスモニタリングとメンテナンス
  • CPU負荷の高いタスクにおけるワーカースレッドの利用

Node.jsプロダクション向けのジョブスケジューリングパターン

次の点を理解するために、ジョブ ディレクトリで実際のジョブ スケジューリング パターンを調べてください。

  • Node.jsの本番環境でcronのようなスケジューリングを実装する方法
  • エラー処理と再試行ロジック
  • CPU負荷の高いタスクでワーカースレッドを使用する方法

本番環境 Node.js アプリケーションの自動メンテナンス

Node.jsの本番環境でよくある問題を防ぐため、プロアクティブなメンテナンスを実施しています。以下のパターンは、あらゆるNode.jsアプリケーションに適用されます。

クリーンアップ実装

ソース: jobs/cleanup-tmp.js

Node.js の本番アプリケーションに対する自動メンテナンスのターゲット:

  • 一時ファイル 24時間以上経過
  • ログファイル 保存期間の制限を超えたもの
  • キャッシュファイル と一時データ
  • アップロード済みファイル のうち不要になったもの
  • パフォーマンスデバッグからのヒープスナップショット

これらのパターンは、一時ファイル、ログ、またはキャッシュされたデータを生成するすべての Node.js アプリケーションに適用されます。

Node.jsプロダクションのディスクスペース管理

監視しきい値: helpers/monitor-server.js

  • バックグラウンド処理のキュー制限
  • ディスク使用率75%の警告しきい値
  • しきい値を超えた場合の自動クリーンアップ

インフラストラクチャメンテナンス自動化

Node.js プロダクション向けの Ansible 自動化:

Node.js 本番環境導入実装ガイド

実際のコードで本番環境のベストプラクティスを学ぶ

Node.js の本番環境のセットアップには、次の主要ファイルから始めます:

  1. 構成: config/index.js
  2. 監視: helpers/monitor-server.js
  3. エラー処理: helpers/is-code-bug.js
  4. ログ記録: helpers/logger.js
  5. プロセス状態: jobs/check-pm2.js

ブログ投稿から学ぶ

Node.js 制作のための技術実装ガイド:

Node.js本番環境向けインフラストラクチャ自動化

Node.js の本番環境への展開を学習するための Ansible プレイブック:

事例紹介

当社のエンタープライズ実装:

結論: Node.js の本番環境デプロイメントのベストプラクティス

当社の Node.js 実稼働インフラストラクチャは、以下の機能を通じて Node.js アプリケーションがエンタープライズ グレードの信頼性を実現できることを実証しています。

  • 実績のあるハードウェア (AMD Ryzenでシングルコアパフォーマンスを573%向上)
  • 実績のあるNode.js本番環境監視 (特定のしきい値と自動応答機能付き)
  • スマートなエラー分類 (本番環境におけるインシデント対応を向上)
  • v8-profiler-nextとcpuproによる高度なパフォーマンスデバッグ (OOM防止)
  • Ansible自動化による包括的なセキュリティ強化 (Ansible自動化による)
  • ハイブリッドデータベースアーキテクチャ (アプリケーションのニーズに合わせて最適化)
  • 自動メンテナンス (Node.js本番環境でよくある問題を防ぐ)

重要なポイント: 一般的なベストプラクティスに従うのではなく、実際の実装ファイルとブログ記事を研究してください。私たちのコードベースは、Node.jsの本番環境へのデプロイメントに実用的なパターンを提供しており、Webアプリ、API、マイクロサービス、バックグラウンドサービスなど、あらゆるNode.jsアプリケーションに適用できます。

Node.jsプロダクション用の完全なリソースリスト

コア実装ファイル

当社のサーバー実装

インフラストラクチャ自動化

弊社の技術ブログ投稿

エンタープライズケーススタディ