tl; dr多くのRailsアプリまたは1つのVertx / Play！アプリ？
Play！などの非同期アプリサーバーを使用することの長所と短所について、チームの他のメンバーと話し合っています。フレームワーク（Netty上に構築）とRailsアプリサーバーの複数のインスタンスの起動。
Nettyは非同期/非ブロッキングであることがわかっています。つまり、データベースクエリ、ネットワークリクエスト、または同様の非同期呼び出し中に、イベントループスレッドがブロックされたリクエストから処理/処理の準備ができている別のリクエストに切り替えることができます。これにより、CPUをブロックして待機するのではなく、ビジー状態に保つことができます。
私は賛成するか、Playのようなものを使用していると主張しています！フレームワークまたはVertx.io、非ブロッキングのもの...スケーラブル。一方、私のチームメンバーは、Railsアプリの複数のインスタンスを使用することで同じメリットを得ることができると言っています。Railsアプリは、箱から出して1つのスレッドしか付属しておらず、JVM上のアプリのように真の同時実行性はありません。 。彼らは、1つのPlayのパフォーマンスに匹敵するのに十分なアプリインスタンスを使用するだけだと言っています！アプリケーション（または私たちが使用する多くのPlay！アプリ）、およびRailsアプリがブロックすると、OSはプロセスを別のRailsアプリに切り替えます。結局、彼らはCPUが同じ量の仕事をし、私たちが同じパフォーマンスを得るだろうと言っています。
だからここに私の質問があります：
どちらのアプローチも機能し、機能しました。したがって、切り替えによって高い開発コストやスケジュールの打撃が発生する場合は、おそらく努力する価値はありません...まだ。コストが許容できないほど高くなったときに切り替えます。マイクロサービスを段階的な切り替え戦略として使用することを考えてください。
開発サイクルの早い段階で切り替えを行うのは理にかなっているかもしれません。書き直しは苦痛です。
または、切り替える必要がなく、レールがチャームのようにユースケースで機能する可能性があります。そして、あなたはあなたの顧客を幸せにすることに非常に成功しているので、現金はちょうど入っています。
単一サーバーをブロックするアプローチの欠点のいくつか：
メモリ使用量の増加。ソース：複数のプロセス、メモリリーク、共有データ構造の欠如（通信コストが増加し、一貫性の問題が発生します）。
並列処理の欠如。これには2つの結果があります：より多くのボックスとより多くのレイテンシー。同じ負荷を処理するには、はるかに多くのボックス数が必要になる可能性があります。したがって、拡張する必要があり、お金の問題がある場合、これは問題になる可能性があります。それが問題でなければ、それは問題ではありません。サーバーでは、レイテンシーの増加を意味します。これは、プロセスを増やすことでは改善できない一種のレイテンシーであり、アプリによってはキラーな議論になる可能性があります。
railsからnode.jsとgolangにそのような切り替えを行った人のいくつかの例：
LinkedInがRailsからノードに移行：27台のサーバーが最大20倍高速化：http：//highscalability.com/blog/2012/10/4/linkedin-moved-from-rails-to-node-27-servers-cut-および-up-to-2.html
TimehopがRailsアプリの置き換えを選択した理由：https：//medium.com/building-timehop/why-timehop-chose-go-to-replace-our-rails-app-2855ea1912d
APIをRubyからGoに移行し、健全性を維持する方法：http：//blog.parse.com/learn/how-we-moved-our-api-from-ruby-to-go-and-saved-our-正気/
30台のサーバーから2台に移行した方法：移動：http：//www.iron.io/blog/2013/03/how-we-went-from-30-servers-to-2-go.html
これらの投稿は、おそらくあなたのグループが経験していることを説明する議論を表しています。残念ながら、この決定は明白なものではありません。
それは、構築しているものの性質、チームの性質、リソースの性質、スキルの性質、目標の性質、およびすべての異なるトレードオフをどのように評価するかによって異なります。
コストは本当に下がるでしょうか？サーバーの数に関係なく、同じ量の計算が実行されませんか？
行われている作業の種類と規模によって異なります。通常、WebサービスはIOバウンドであり、データベース、キャッシュなどの他のサービスからの応答を待機します。
シングルスレッドサーバーを使用している場合、プロセスはIOで頻繁にブロックされるため、何も実行されません。対照的に、非ブロックサーバーは、シングルスレッドサーバーがブロックされている間、多くの要求を処理できます。プロセスを追加し続けることはできますが、1台のマシンで実行できるプロセスは非常に多くなります。ノンブロッキングサーバーは、要求を処理するためにCPUをビジー状態に保ちながら、同じ数のプロセスを持つことができます。ノンブロッキングサーバーを使用すると、より小型で安価なマシンでより高い負荷を処理できることがよくあります。
予想される要求率を許容可能な数のボックスで処理でき、大きなスパイクが予想されない場合は、シングルスレッドサーバーで問題ありません。ノンブロッキングサーバーは、必ずしもマシンを追加しなくても、負荷の急上昇を吸収するのに最適です。
応答の待ち時間が実際には問題にならないような作業である場合は、より少ないノードで処理できます。
ワークロードがCPUにバインドされている場合は、サーバーがIOでブロックしないため、並列処理の同じ機会がないため、とにかくより多くのボックスが必要になります。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加