Tactoom.com Inside-NodeJS / NoSQLソーシャルブログプラットフォーム

それでは、いくつかのカードを公開し、Tactoomがどのように機能するかについて完全に説明するときが来ました。



この記事では、以下を使用したWebサービスの開発と生産について説明します。

NodeJS（ファイバー）、MongoDB、Redis、ElasticSearch、Capistrano、Rackspace。

エントリー

3週間前、Davidと私（ DMiloshev ） は Tactoom.comインフォソーシャルネットワークを立ち上げました 。 それが何であるかについては、 ここで読むことができます 。



NodeJSで最近 発生したノイズの背景に対して、おそらく多くの人はこのテクノロジーが言葉ではなく実際にあることに興味を持っています。



NodeJSは万能薬ではありません。 これは実際には別の技術であり、他の技術よりも優れているわけではありません。 優れたパフォーマンスとスケーラビリティを実現するためには、他のどこでもそうであるように、たくさん汗をかかなければなりません。

アプリケーションアーキテクチャ

NodeJSアプリケーションは、2種類のプロセスに分けられます。

1. Webプロセス（http）

2.クラウドプロセス（キュー）



すべてのプロセスは相互に完全に独立しており、異なるサーバーに、さらには地球のさまざまな場所に配置することができます。 同時に、アプリケーションは、これらのプロセスの乗算によって正確にスケーリングされます。 それらの間の通信は、一元化されたメッセージサーバー（redis）を介して行われます。



Webプロセスは、ユーザーからの直接http要求を処理します。 各プロセスは一度に複数のリクエストを処理できます。 Eventloopの詳細を考慮すると、特定の各要求のCPU / IO比率に応じて、並列処理の制限は、ある時点での個々のプロセスに対して減少または増加する可能性があります。



クラウドプロセスは、ユーザーリクエストに直接関係しない操作を実行します。 例：電子メールの送信、データの非正規化、検索インデックス作成。 Webと同様に、1つのクラウドプロセスで同時に多くの異なる種類のタスクを処理できます。

ここでは、タスク/クエリの「原子性」が非常に重要であることは注目に値します。 つまり、容量のあるタスク/計算を多くの小さな部分に分割し、残りのプロセス全体に均等に分散させる必要があります。 これにより、タスクの速度、フォールトトレランスが向上し、各プロセスとサーバー全体のメモリ消費とブロッキング係数が削減されます。



Web→クラウド

私は、CPUに対する全体的なIO時間比率を増加させるような方法でWebプロセスを整理しようとします。つまり、高い競争力のあるリクエストでのHTTPの高速発行に焦点を合わせます。 これは、 Webが高CPUロジックをCloudに委任し、その実行を待ってから、計算の結果を受け取ることを意味します。 したがって、nodejsの非同期アーキテクチャにより、Webは待機中に他の要求を行うことができます。



クラスタリング

Webとクラウドのアーキテクチャは非常によく似ていますが、httpソケットの代わりにクラウドがredisキューをリッスンする点が異なります。



ノードプロセスのクラスタリングは、次の原則に従って行われます。

1.各物理サーバーで1つのスーパーバイザープロセス（ node-cluster ）が実行されています

2.スーパーバイザーの子プロセスはWebとクラウドであり、その数は常にサーバーコアの数に等しくなります。

3.スーパーバイザは、各子プロセスのメモリ消費を監視し、指定された基準を超えた場合、（このプロセスの現在の要求の完了を待って）再起動します。

繊維

アプリケーションの高レベルレイヤー全体は、 ノード同期（ファイバー）を使用して記述されていますが 、これがないと、一般にその開発についてはほとんどわかりません。 実際には、「公式な」コールバック駆動型のパラダイムで同じ静的アセンブリのような複雑なものを実装することは、愚かではないとしても非常に困難です。 同じnpmのコードをまだ見ていない人には、 それを見て 、そこで何が起こっているのか、そして最も重要なのはなぜかを理解することを強くお勧めします 。 そして、ほぼ毎日非同期nodejsパラダイムの周りで成長するホリバーとトローリングは、穏やかに言えば、私を困惑させます。



私の記事でノード同期の詳細を学ぶことができます：

node-sync-ファイバーを使用したnodejsでの擬似同期プログラミング

Web

Webアプリケーションの一般的なロジックは、「エクスプレス」スタイルでexpressjsフレームワークに実装されます。 各要求が個別のファイバーでラップされていることを除き、内部ではすべての操作が同期スタイルで実行されます。



expressjs機能の一部、特にルーティングをオーバーライドできないため、npmから削除し、メインプロジェクトリポジトリに含める必要がありました。 同じことが他の多くのモジュール（特にLearnBoostによって開発されたモジュール ）にも当てはまります。なぜなら、彼らのプロジェクトに貢献することは非常に難しく、通常は常に可能ではないからです。



CSSはスタイラスを介して生成されます 。 とても便利です。

テンプレートエンジン-ejs （サーバーとクライアントの両方）。

ファイルのアップロード-connect-form



すべてのモジュールと初期化が起動時にプロセスメモリにロードされるため、Webは非常に高速です。 任意のページでWebプロセスの平均応答時間を維持しようとしています-最大300ミリ秒（画像のアップロード、登録などを除く）。 プロファイリングの際、この時間の70％がmongoose（nodejsのmongodb ORM）に使用されていることに驚いた-詳細は以下をご覧ください。



国際化

長い間、私はnodejsでの国際化に適したソリューションを探していましたが、私の検索は少しのドピリバニーでnode-gettextに収束しました。 クロックのように機能し、ロケールファイルは更新中にサーバーのnodejsプロセスによって「オンザフライ」で取得されます。



キャッシュ

すべてのロジックを備えたキャッシング機能は、2つの画面のコードに収まります。 キャッシュバックエンドとして、redisが使用されます。



記憶

Webプロセスでは、メモリは川のように流れますが、後にマングースが原因で判明しました。 1つのプロセス（日中、平均負荷時）は、2時間で最大800MBを消費し、その後スーパーバイザーによって再起動されます。

興味深い方法を知っている場合、nodejsでメモリリークを検索するのは非常に困難です-お知らせください。

データ

実践により、スキーマレスmongodbパラダイムは Tactoomモデルに理想的であることが示されています。 データベース自体は適切に動作し（重量は376MB、そのうち122MBはインデックスです）、データはインデックスによってのみ選択されるため、クエリの結果は、高負荷（ほとんどのクエリは通常<1ms）でも30ms以下です。



興味深い場合は、第2部で、いくつかの重要なタスクについてmongodbを「飼いならした」方法（および失敗した方法）について詳しく説明します。



mongoosejs（nodejsのmongodb ORM）

彼については別に言いたい。 20人のユーザーのリストの選択：mongoでのデータの要求と選択には2ミリ秒かかり、データ転送には10ミリ秒かかります。その後、mongooseは他の200ミリ秒（既にメモリについては沈黙しています）を実行し、結果としてオブジェクトを取得します。 これを下位レベルのnode-mongodb-nativeに書き換えると、これにはすべて30ミリ秒かかります。

徐々に、システム全体の速度を10倍に高めながら、mongodb-nativeのほぼすべてを書き換えなければなりませんでした。

静力学

すべてのTactoom統計はRackspace Cloud Storageに保存されます。 その際、静的なcdnドメインX .infosocial.netを使用します（ Xは1..n）。 このドメインはDNSを介してCloud Storageのコンテナの内部ドメインに転送され、ブラウザが静的ファイルを並行してロードできるようにします。 各静的ファイルは2つのコピー（プレーンおよびgzip）に格納され、バージョンが接続される一意の名前を持ちます。 ファイルのバージョンが更新されると、アドレスが変更され、ブラウザが新しいファイルをダウンロードします。



アプリケーションの統計は、（git-logを介して）変更されたファイルを定義し、縮小し、gzipコピーを作成し、CDNにロードする自己記述メカニズムを通じて収集されます（クライアントjsおよびcss、写真）。 ビルドスクリプトは、変更されたイメージも監視し、対応するcssファイル内のアドレスを更新します。

すべてのファイルのアドレス統計のリスト（マッピング）がRedisに保存されます。 このリストは、起動時または静的バージョンの更新時にすべてのWebプロセスをメモリにロードします。

実際、静的に対する変更の展開解除は、すべてを単独で行う1つのチームによって行われます。 さらに、nodejsアプリケーションはredis pub / subを介してその場で静的ファイルの変更されたアドレスを取得するため、再起動は必要ありません。



ユーザー統計もRackspaceに保存されますが、アプリケーション静的とは異なり、バージョンはありませんが、特定の正規化を行うだけで、イメージのハッシュを使用してCDN上のすべてのサイズのアドレスを受信できます。



特定の静的ファイルが格納されるホスト定義（cdn X ）の場合、一貫したハッシュが使用されます。

サーバーアーキテクチャ

実際、Tactoomは3つのハーメチックゾーンに分散しています。

1. Rackspace-静的データの高速スケーリングとストレージのためのプラットフォーム

2.ヨーロッパのサイト -ここに物理サーバー

3.シークレット （ログはここでローテーションされ、バックグラウンド計算が行われ、統計が収集されます）



1つのサーバーだけが世界を探しています-nginx、ポート80および4000が開いています。後者はCOMET接続に使用されます。

残りのサーバーは、ダイレクトIPを介して相互に通信し、iptablesを介して世界中から閉じられます。



：80

nginxは、要求をアップストリーム構成を介してWebサーバーにプロキシします。 現時点では、2つのアップストリーム： tac_mainとtac_mediaがあります。 それぞれには、3000ポートでノードクラスターを実行しているWebサーバーのリストが含まれています。各Webサーバーには、リクエストの配信において独自の優先順位があります。

tac_mainは、データベースに近いWebサーバーのクラスターであり、ほとんどのWebページを登録済みのTactoomユーザーに配信します。

tac_media -CDNの近くにあるWebサーバーのクラスター。 それらを介して、画像のダウンロードとサイズ変更のすべての操作が行われます。



webNおよびcloudNサーバーは 、Habraエフェクトおよびその他の楽しいイベントでサーバーを追加する場所を示しています。

新しいサーバーは、CDNに保存されているイメージで10分以内に立ち上がります。



：4000

これは、nodejs COMET Besedaアプリケーションが実行されている彗星サーバーへの通常のプロキシパスです。これについては、第2部で説明します。



tac1、tac2、data1

主なTactoomサーバーは次のとおりです。XEONX3440 4x2.53 GHz 16 GB 2x1500 GB Raid1。

それぞれがMongodプロセスを実行し、それらのすべてがReplicaSetで結合され、自動フェイルオーバーとスレーブへの読み取り操作の分散が行われます。



メインWebクラスターであるtac1で、クラウドクラスターであるtac2で。 各クラスターには8つのnodejsプロセスがあります。



近い将来、検索クエリのみがルーティングされる別のアップストリームtac_searchを作成します。 これにはWebクラスターがあり、これをelasticsearch （第2部で説明）サーバーの隣に配置します。

結論

NodeJSの作成者のスローガンを引用：

「ブロックするものがないため、熟練していないプログラマでも高速システムを開発できます。」

「何もブロックされていないため、専門家以下の人でも高速システムを開発できます。」

1. これはデマです。 私はもう2年近くnodejsを使用していますが、私自身の経験から、「高速システム」を開発するには、他のどのテクノロジーよりも少ない（またはそれ以上の）経験が必要です。 実際には、nodejsのコールバック駆動型のパラダイムとjavascriptの一般的な機能を使用すると、パフォーマンスを向上させるよりも、ミスを犯す可能性が高くなります（そして、非常に長い間探します）。
2. 一方、「フィボナッチ数」の例は指から吸い出されるため、テッド・ジウバ氏のトローリングもまったくナンセンスです。 Eventloopがどのように機能し、なぜそれが必要なのかを理解していない人だけがこれを行います（これは、ポイント1によって証明されます）。

今春、 DevConfで講義した後、 NodeJSで新しいプロジェクトを作成するかどうかについてよく質問されます。 みんなへの私の答え：

多くの時間があり、新しい、生の、物議を醸す技術の開発に投資する準備ができているなら、先に進んでください。 しかし、タイムライン/顧客/投資家がいて、背後のサーバーサイドJSの経験があまりない場合は、 価値がありません 。



実践が示しているように、NodeJSでプロジェクトを作成するのは現実的です。 動作します。 しかし、それはかなりの費用がかかりました。 ノードのオープンソースコミュニティの価値は何ですか？

パート2

記事の2番目の部分は先日です。 以下は、私がそれについて書くことの短いリストです。

1.検索（elasticsearch）

2.メール（Google App Engine）

3.展開（capistrano、npm）

4.キュー（redis、kue）

5. COMETサーバー（beseda）



1つの記事の情報が多すぎます。

コメントに興味深い質問がある場合は、第2部で回答します。

PS

1. 食べ物はありません。 私は自分の業績に言及せずに批判を含むコメントを無視します。
2. フロントエンドの忍者を探しています 。詳細はこちら
3. Tactoomはベータテスト中です。 登録は制限されています。 メールを残すと、すぐに招待状が届く場合があります。

UPD 19.10：

2番目の部分は、多くの作業のために遅れています。