Facebookのようなサイトのようにサーバーを追加して、Twitterを拡張できなかったのはなぜですか？
私はTwitterがミドルウェアの一部をRails=からScalaに移行しなければならなかった理由の説明を探していました。 。具体的には、Ruby/RailsテクノロジーがTwitterチームがこのアプローチをとることを妨げていたのはどうですか？
Railsがスケーリングしないわけではありませんが、Ruby（または任意のインタープリター言語）の「ライブ」データの要求はスケーリングされません。コンパイルされた言語の対応物よりもCPUとメモリの使用率の点で。
さて、Twitterは別のタイプのサービスであり、同じ巨大なユーザーベースを持ち、より頻繁に変更されないデータを提供するサービスでした。Railsはキャッシングによる実行可能なオプションです。つまり、Railsスタックへのライブリクエストを完全に回避し、フロントエンドサーバーやメモリ内DBキャッシュにオフロードします。このトピックに関する優れた記事：
ただし、Twitterはスケーリングの問題だけでRailsを捨てませんでした。Scalaは言語として、解釈された言語が提供できないアプリケーションの状態に関する特定の組み込みの保証を提供するため、切り替えを行いました。 、手指のタイプミス、不正なメソッド呼び出し、不正な型宣言などの時間を浪費するバグは存在しません。
Twitterでは、TDDは十分ではありませんでした。 Scalaでのプログラミングのダイクストラからの引用は、「テストはエラーの存在のみを証明でき、エラーがないことを証明できる」ことを示しています。アプリケーションが成長するにつれて、バグを追跡するのがますます難しくなりました。魔法のミステリーツアーは、パフォーマンスを超えた障害になりつつあったため、切り替えを行いました。すべてのアカウントが圧倒的な成功を収めているため、TwitterはScalaに、FacebookはPHPに（Facebookは独自の超高速C++プリプロセッサを使用しているため、少しごまかしています;-)）
要約すると、Twitterはパフォーマンスと信頼性の両方を切り替えました。もちろん、Railsはイノベーションの最前線にいる傾向があるため、99％の非Twitterレベルの世界のトラフィックアプリケーションは、インタープリター言語で問題なく取得できます（ただし、フェンスのコンパイルされた言語側、Scalaはあまりにも良いです！）
刻々と変化する複雑なデータセットを処理しながら、プラットフォームを無限にスケールアウトすることはできません。言語とインフラストラクチャは重要ですが、サイトの構築方法とデータアクセスパターンはより重要です。
Transport TycoonやSettlersのようなゲームをプレイしたことがある人は、リソースを移動する必要があります。使用量の増加に応じて、インフラストラクチャをアップグレードする必要があります。
FacebookやTwitterなどのプラットフォームのスケーリングは、終わりのないタスクです。ユーザーの数は増え続けており、より多くの機能を追加するよう求められています。これは1ビットを継続的にアップグレードするプロセスであり、別のビットにより大きなストレスをもたらします。
問題にサーバーを投げることは常に答えであるとは限らず、時にはより多くの問題を引き起こす可能性があります。
http://highscalability.com/scaling-Twitter-making-Twitter-10000-percent-faster 変更に関する一連の投稿へのリンク（時間の経過に伴う適切な履歴を含む）。
短いバージョンは、Ruby and Railsはサービスに必要なパフォーマンスと信頼性を提供しませんでした。規模を考えると、これは驚くことではありません。ほとんどのCOTSソリューションは、超大規模のスケールでは満足のいくものではありません。
高スケーラビリティは、他のサイトのトップエンドのアーキテクチャに関する多くの質問に対応しているため、この分野の幅広い質問に答えることができます。
彼らは問題に対してより多くのハードウェアを投げることができたかもしれませんが、それは単により効率的なコードを書くよりもかなり高価です。多くの高レベルフレームワークと同様に、Ruby on Railsは多くの点で優れていますが、高性能はそれらの1つではありません。コンパイルされた言語は常にインタプリタ言語よりも高速です。
Facebook（およびGoogle）は、サーバーを追加することで拡張しますが、同時にアプリケーションをさまざまなサービスに分割します。これらのサービスは、合意されたインターフェースとタイプを介して通信し、適切と思われる技術でこれらのサービスを自由に構築できます。 facebookがphpを使用していることを読んだからといって、そのすべてのバックエンドサービスがphpによって処理されているわけではありません（SOAで技術スタックを選択できるため） 。
このビデオはあなたの質問に対する最良の答えだと思います。
「From Ruby to the JVM」） https://www.youtube.com/watch?v=ohHdZXnsNi8
並列処理（複数サーバーとは）による線形ゲインは非常にまれであり、アプリケーションに大きく依存します。はい、それは存在します-それがGPUが彼らのほとんどの仕事をする方法です。セッション状態のない静的なページを提供している場合も同様です。
ただし、ほとんどの場合、サーバーを追加してもパフォーマンスは直線的に向上しません（つまり、10台のサーバーは1台のサーバーの10倍の速度ではありません）。that単一のサーバーで得られる利益は、単にサーバーを追加するよりもはるかに大きな影響があることを理解してください。 Twitterに多数のサーバーがないわけではありません。
ここで欠けている重要な点はプラットフォームだと思います。はい、コンパイルされた引数と解釈された引数、および他のいくつかの引数がありました。しかし、非常に重要な側面の1つは実際にプラットフォームでした。別のRuby VMがありますが、Twitterを喜ばせるものはありませんでしたが、かなり調整されています。しかし、scalaなぜ彼らがJRubyを試したり、選択したりしなかったのでしょうか？さて、上記の理由がここにあると思います。