10

ユーザーの行動をキャプチャするための単純な分析バックエンドを構築する必要があります。これは、Google アナリティクスや Mixpanel のデータと同様に、Web ページの Javascript スニペットを介してキャプチャされます。

システムは、ほぼリアルタイムのブラウザー データ (ページのスクロール位置、マウスの位置など) をキャプチャする必要があります。ユーザーのページの状態を 5 秒ごとに記録します。各測定には 3 つの属性しかありませんが、頻繁に取得する必要があります。

データは必ずしも 5 秒ごとに送信する必要はありません。頻繁にバスを使用することはできませんが、ユーザーがページにアクセスしている間にすべてのデータを取得することが不可欠です。つまり、1 分間に 1 回バスを走らせることはできず、119 秒後に出て行った誰かの最後の 59 秒間のデータを失うことはありません。

可能であれば、近い将来に拡張できるシステムを構築したいと考えています。つまり、それぞれ 100 人の同時訪問者、つまり 100,000 人の同時ユーザーがそれぞれ 5 秒ごとに 1 つのイベントを送信する 10,000 サイトで動作するシステムを構築したいと考えています。

別のシステムを使用して実行できるデータのクエリについては心配していません。データ自体のキャプチャを処理する方法に最も興味があります。

要件

上記の予算に基づいて、システムは 100,000 ユーザーのプールから来る毎秒 20,000 イベントを処理する必要があります。

このサービスを Heroku でホストしたいのですが、Rails で多くの作業を行ってきましたが、高スループット システムについてはまったくの初心者です (Rails を使用して処理しないことを除けば)。

質問

  1. これを行うのに適した商用システムはありますか (Pusher のように、データのキャプチャと配布に適しています)?
  2. HTTP リクエストまたは WebSocket を使用してこれを行う必要がありますか?
  3. node.js はこれに適した選択ですか、それともトレンディですか?
  4. ソケットベースのソリューションを選択した場合、Heroku の dyno が Web サーバーごとに処理できるソケットの数
  5. ストレージ用にMongo / Reddisなどを選択する際の適切な考慮事項は何ですか
  6. これは、実際には 2 つの解決策が必要なタイプの問題でしょうか? 1 つ目は、適切な規模を迅速かつ安価に実現する方法であり、2 つ目は、より少ない増分コストでその規模を超えることができますが、前もってより多くの開発作業が必要になりますか?
4

2 に答える 2

8

あなたへの私の高レベルのコメントは、12 要素設計に従ってシステムを構築し、顧客が到着したときのスケーリングについて心配することです。私は Node.js と npm エコシステムにわくわくしていますが、Rails で完全に受け入れられるプラットフォームを構築できるとも思います。Node で 100,000 の同時ユーザーをサポートするのに 3 dyno が必要で、Rails でその 2 倍になったとしても、Rails を使ったほうがよいかもしれません。とにかく、あなたがノードを使うと仮定すると、ここに私の答えがあります：

  1. ここでは、Pusherの代替案と、 Pusher と Pubnubの比較について説明します。アブリーも参照してください。
  2. socket.ioを使用します。これは、利用可能な最適なトランスポートを使用し、WebSockets から HTTP メソッドにフォールバックするため、大部分が標準です。
  3. ノードは素晴らしい選択であり、トレンディでもあります (モジュールの成長率を参照してください)。Node、Rails、または他のいくつかのフレームワークでシステムを正常に動作させることができると思います。
  4. Heroku dyno は、RAM の効率にもよりますが、何万もの同時接続をサポートできるはずです。16 GB の RAM を搭載したサーバーは、100 万の同時接続をサポートできました。RAM が制限されていると仮定すると、512 MB の RAM を搭載した Heroku dyno は最大 30 K の接続をサポートできるはずです。
  5. 1 つはデータの保存と処理用、もう 1 つはキャッシュ用です。これは、Instagram の作成者によるコア データ プラットフォームの選択に関する素晴らしい投稿です。コア データについては、Sequelize ORM を使用した Postgres (Heroku 上) をお勧めします。しかし、検索用に SOLR を使用する Mongo もおそらく問題なく動作するでしょう。Postgres 9.2 は、必要に応じて NoSQL データストアとして使用できることに注意してください。キャッシング システムについては、Redis を強くお勧めします。
  6. いいえ、私はエンジニアリングを捨てないようにします。代わりに、機能するものを構築し、トラフィックが桁違いに増えるたびに、システムの一部が壊れて交換が必要になることを期待してください. ただし、12 ファクターの原則に従っている場合は、交換に投資している間に水平方向にスケーリングするのに適した状態にある必要があります。

幸運を。

于 2013-06-26T10:49:53.647 に答える
2
  1. ソケットには多くのサービスがありますが、Pusher と Pubnub がこの分野のマーケット リーダーのようです。何をするにしても、socket.io のような独自のものをホストしないでください。heroku はWebsocketを含めて 30 秒を超えるリクエストをタイムアウトするためです。したがって、数秒ごとにソケットを閉じて再度開くことを計画していない限り、ホストされたソケットは間違いなく問題外です。
  2. Pusher のようなソケット サービスを使用する場合は、サービスがデータを送信するために http エンドポイントを実装する必要があります。したがって、私は仲介者を切り捨てて、直接の http 要求を使用します。確かに、一定のユーザー インタラクションを収集する必要がありますが、それはすべて JavaScript クライアントで記録し、 CORS XHR または追跡画像を介して定期的にアプリに送り返すことができます。
  3. ノードは素晴らしい選択です。軽量で、セットアップが非常に簡単で、利用可能な npm ライブラリには、開始するために必要なものがすべて揃っています。特に必要のないものを切り取ると、Rails も非常に高速になります。この件に関しては、すばらしいRailscastがあります。重要なことは、できるだけシンプルに保つことです。2 つのアプリケーションに分割することもできます。1 つはデータ収集用、もう 1 つはデータの分析/処理用です。このようにして、ノードでデータを収集すると高速になり、レールで分析/処理すると簡単になります。
  4. 1. で述べたように、ソケットは heroku では機能しません。また、プッシャーを使用した場合でも、同じ数の http リクエストをサポートする必要があります。これは、プッシャーがデータを受信すると、データを直接送信するためです。あなたへ。必要な dyno の数については、簡単にテストできますが、私が見積もることはできません。データを収集するコードの効率に完全に依存します。予想される負荷と同時実行性を使用した単純な Apache AB テストを行うと、必要なものがよくわかります。ノードには独自の同時実行性がありますが、レールを使用してデータを収集する場合は、同時実行性をサポートしているため、ユニコーンまたはピューマをサーバーとして使用してください。また、Apache AB のテスト時にさまざまな構成を試してください。
  5. このスタックオーバーフロー スレッドは、redis の方が高速であり、データを収集するために必要なのは高速であることを示唆しています。ただし、それを収集した後は、おそらくそれを処理して、キー、バリュー ストア以外の場所に保存することをお勧めします。Mongo はそのための良いオプションですが、分析が持つ複雑な接続のため、neo4jのようなグラフ データベースを使用します。
  6. ここで新境地に足を踏み入れたとしても、最初からうまくいくわけではありません。最高のパフォーマンスと最も正確なデータを得るために何度も繰り返していることに気付くでしょう。最終的には、おそらくそれを削除して、新しいアーキテクチャでやり直すことになり、サイクルは継続します。データ収集と分析を別々に行うということは、各ビットを個別に正しく理解することに集中できることを意味します。

私が言及したいいくつかの追加ポイントは、JavaScript クライアントの配布に CDN を使用することです。または、さらに良いのは、ページから提供する完全な JS を提供することです。いずれにせよ、高速に読み込み、非同期に読み込みます。楽しいプロジェクトのようですね。幸運を！

編集herokuを使用する必要がない代替宇宙では、websocketsは素晴らしいソリューションになります。

于 2013-06-26T18:20:19.973 に答える