Ruby on Rails: アプリをスケーリングして急成長させる

アプリの成長をスケーリングすることは、今日では非常に恐ろしいテーマになっています。インターネット リソースやブログ投稿のほとんどは、Ruby アプリケーションのスケーリングを中心に展開しています。アプリケーションの急速な成長に対して Ruby on Rails がどの程度の上限を達成できるのかを知ることは非常に興味深いです。 スケーリングは速度ではなくスループットによって増加します ホストのスケーリングは、リクエストがアプリケーションによる処理の待機に多くの時間を費やしている場合にのみ、応答時間を高速化します。サービスを待っている既存のリクエストがない場合、スケーリングは単なるお金の無駄になります。 Ruby on Rails はアプリケーションを 1 分あたり 1 リクエストから最大 1,000 リクエストまで正確にスケーリングします。このスケーリング プロセスについて知っておく必要がある重要なことは、HTTP ルーティングとアプリケーション サーバーが実際にどのように動作しているかということです。 リクエストはどのようにアプリサーバーにルーティングされますか? Ruby を使用して Web アプリケーションをスケーリングする際に行う重要な決定の 1 つは、選択する必要があるアプリケーション サーバーの種類です。過去 5 年間に起こった劇的な変化と昨年のめまぐるしい変化のため、Ruby のスケーリングに関する投稿のほとんどは時代遅れになっている可能性があります。それにもかかわらず、私たちはアプリケーション サーバーのそれぞれの選択による既存の利点を依然として理解しています。私たちは、これらのリクエストがどのようにアプリケーション サーバーにルーティングされるのかについて、より詳しく知る必要があります。多くの開発者は、これらのリクエストがどのようにキューに入れられ、ルーティングされるのかという正確なプロセスをまだほとんど理解していません。 リクエストのライフサイクル リクエストが Heroku アプリに到着すると、最初に停止するのはロード バランサーです。ロード バランサーの役割は、Heraku のルーター間の負荷が均等に分散されるようにすることです。このロード バランサーは、それに最適なルーターのいずれかにリクエストを渡します。非公開の Heroku ルーターは膨大な数あり、現時点ではその数は約 100 を超えるかなり大きいと推測できます。ルーターの仕事はアプリケーションの dyno に対して行われ、リクエストを特定の dyno に渡します。 dyno を見つけるには 1 ～ 5 分かかる場合があり、ルーターはアプリケーション内のランダムな dyno との接続を試行します。 Heroku がすでに 1 つのランダムな dyno を選択している場合、その dyno がリクエストを要求し、開いた接続を確立するまで 5 秒間待機します。リクエストは待機中、ルーターのリクエストのキューに入れられます。 アプリケーションサーバーの選択

• ウェブリック
• 薄い
• ユニコーン
• フューシオン パッセンジャー 5
• プーマ (ネジ付き)
• ピューマ (クラスター化)

これらのサーバーはそれぞれ速度の点で異なりますが、すべてのサーバーが毎分数千のリクエストを処理できます。アプリケーションのスケーリングは、応答時間だけに基づいているわけではありません。リクエストキューが増加すると、アプリケーションの速度が低下する可能性があります。リクエスト キューが空の場合、お金と時間の無駄になるため、最初にリクエスト キューを確認する必要があります。これはワーカーホストにも当てはまります。これらは、深いジョブ キューに基づいてスケールされます。