ページ編集

スケーリング

アプリケーションに大量のトラフィックが集中することが見込まれる場合（または既に集中している場合）、アプリへのリクエストが増えるにつれてサーバーを追加できるスケーラブルなアーキテクチャを構築する必要があります。

パフォーマンス

本番環境では、Sails は Connect、Express、Socket.io アプリと同様に動作します（例）。独自のベンチマークを共有したい場合は、ブログ投稿または記事を作成し、@sailsjs にツイートしてください。ただし、ベンチマークはさておき、パフォーマンスとスケーラビリティの指標の大部分はアプリケーション固有であることに注意してください。アプリの実際のパフォーマンスは、ビジネスロジックの実装方法やモデル呼び出しの方法の方が、使用している基盤となるフレームワークよりもはるかに大きく影響します。

アーキテクチャ例

....
                    /  Sails.js server  \      /  Database (e.g. Mongo, Postgres, etc)
Load Balancer  <-->    Sails.js server    <-->    Socket.io message queue (Redis)
                    \  Sails.js server  /      \  Session store (Redis, Mongo, etc.)
                             ....

クラスタ化されたデプロイメントの準備

Node.js（そして結果的に Sails.js）アプリは水平方向にスケールします。これは強力で効率的なアプローチですが、少しの計画が必要です。大規模な場合、アプリを複数の Sails.js サーバーにコピーし、ロードバランサーの背後に配置できるようにする必要があります。

アプリケーションのスケーリングにおける大きな課題の1つは、クラスタ化されたこのようなデプロイメントでは、物理的に異なるマシン上にあるため、メモリを共有できないことです。さらに、ロードバランサーは利用可能なリソースが最も多い Sails サーバーに各リクエストをルーティングするため、ユーザーがリクエスト間（HTTPまたはソケットのいずれか）で同じサーバーに「固執」するという保証はありません。サーバーサイドアプリケーションのスケーリングについて最も重要なことは、**ステートレス**である必要があるということです。つまり、同じコードを_n_台の異なるサーバーにデプロイし、任意のサーバーによって処理される任意の受信リクエストを想定しても、すべてが正常に動作する必要があります。幸いなことに、Sails アプリは、この種のデプロイメントにほぼすぐに対応できます。ただし、アプリを複数のサーバーにデプロイする前に、いくつかの手順を実行する必要があります。

アプリで使用している可能性のある他の依存関係が共有メモリに依存していないことを確認します。
モデルのデータベース（例：MySQL、Postgres、Mongo）がスケーラブルであることを確認します（例：シャーディング/クラスタリング）。
アプリでセッションを使用する場合
- Redisなどの共有セッションストアを使用するようにアプリを構成し（config/session.jsのadapterオプションのコメントを外すだけです）、アプリの依存関係として「@sailshq/connect-redis」セッションアダプターをインストールします（例：npm install @sailshq/connect-redis --save）。
- 本番環境でのセッションストアの構成の詳細については、sails.config.session のドキュメントを参照してください。
アプリでソケットを使用する場合
- Socket.io メッセージの配信に共有メッセージキューとして Redis を使用するようにアプリを構成します。Socket.io（そして結果的に Sails.js）アプリはデフォルトでソケットに Redis をサポートしているので、リモート Redis pubsub サーバーを有効にするには、config/env/production.jsの関連行のコメントを外します。
- アプリの依存関係として「@sailshq/socket.io-redis」アダプターをインストールします（例：npm install @sailshq/socket.io-redis）。
クラスタが単一サーバー上にある場合（たとえば、pm2 クラスタモードを使用する場合）:
- Grunt タスクによるファイル競合の問題を回避するには、常にproduction環境でアプリを起動するか、Grunt を完全に無効にすることを検討してください。単一サーバークラスタにおける Grunt の問題の詳細については、ここを参照してください。
- config/bootstrap.js のコードでデータベースにデータを永続化する場合は、ブートストラップが複数回実行される（クラスタ内のノードごとに1回）場合の競合を回避するために注意してください。

Node/Sails アプリを PaaS にデプロイする

Heroku や Modulus などの PaaS にアプリをデプロイするのは簡単です！プラットフォーム固有の情報については、ホスティングをご覧ください。

独自のクラスタをデプロイする

ロードバランサー（例：nginx）の背後に複数のインスタンス（アプリのコピーを実行しているサーバー）をデプロイします。
ロードバランサーが SSL リクエストを終了するように構成します。
トラフィックは Sails に到達するまでに既に復号化されているため、Sails で SSL 構成を使用する必要はありません。
foreverやpm2などのデーモンを使用して、各インスタンスでアプリを起動します（デーモンに関する詳細については、https://sails.dokyumento.jp/documentation/concepts/deploymentを参照してください）。

最適化

Node/Sails アプリのエンドポイントの最適化は、他のサーバーサイドアプリケーションのエンドポイントの最適化とまったく同じです。たとえば、遅いクエリを特定して手動で最適化したり、クエリの数を減らしたりすることなどです。Node アプリの場合、CPU を大量に消費しているトラフィックの多いエンドポイントがあることがわかった場合は、ループまたは再帰的なダイブで繰り返し呼び出される可能性のある、同期（ブロッキング）モデルメソッド、サービス、またはマシンを探します。

しかし、覚えておいてください

早すぎる最適化はすべての悪の根源である。—Donald Knuth

どのようなツールを使用しているかにかかわらず、高品質で、よく文書化され、読みやすいコードを作成することに時間と労力を費やすことが重要です。そうすれば、アプリケーションのコードパスを最適化する必要が生じた場合に、はるかに簡単に実行できます。

備考

セッションに Redis を使用する必要はありません。実際には、Connect や Express と互換性のあるセッションストアを使用できます。詳細については、sails.config.session を参照してください。

一部のホストされている Redis プロバイダー（Redis To Goなど）は、アイドル接続のタイムアウトを設定します。ほとんどの場合、アプリで予期しない動作を回避するために、これをオフにすることをお勧めします。タイムアウトをオフにする方法はプロバイダーによって異なるため、サポートチームに問い合わせる必要がある場合があります。

何か不足していますか？

見逃しているものや改善できるものがあれば、このリンクに従って、Sails リポジトリにプルリクエストを送信してください。マージされると、次回のデプロイ時に変更がウェブサイトに反映されます。

ドキュメント

概念

愛情を込めて作成

Sailsフレームワークは、貢献者の方々の助けを借りて、テキサス州オースティンにあるウェブ＆モバイルショップによって開発されました。私たちは2012年にNode.jsプロジェクトを支援するためにSailsを作成し、当然ながらオープンソース化しました。皆さんの生活を少しでも楽にできれば幸いです！