最近、habrでivi.ruでの分析の実装方法に関する出版物がありました。読んだ後、1つの大きなサイトで行った分析についてお話ししたかったのです。残念ながら、顧客は記事内のサイトへのリンクを公開できませんでした。 Alexa Rankを信じている場合、分析を行ったサイトのトラフィックはivi.ruの10倍です。

分析を作成する理由と目標

サイトへのアクセス数が多いため、ある時点でGoogleからサービスの使用を停止するか、リクエストの数を減らすようにとの手紙が届き、一部のデータはGoogleアナリティクスから取得できませんでした。

ユーザーについて収集した情報：

ページビュー（参照、IP、UAgent、画面サイズ）;
アクティブ/パッシブ;
バッファリング;
巻き戻します。

再生の約70％はビデオプレーヤーのあるページで、主なタスクはこれらのページから情報を収集することでした。アクティブ/パッシブに関する情報を取得する必要がありました-ユーザーがページでアクティブだった秒数、および非アクティブであった秒数-タブとして開かれました。バッファリングに関する情報（ビデオがスローダウンするかどうか、ユーザーがダウンロードするのにかかる時間）、巻き戻しの回数、および2番目のユーザーが巻き戻す元の情報も興味深いものでした。これを行うために、すべてのページにJavaScriptコードが配置され、ブラウザで開いたページからサーバー情報に30秒ごとにタップされました。

クライアント部

このスクリプトは非常に単純で、分析サーバーから2つの1ピクセル画像を取得し、これらの画像のURLにパラメーターを渡します。なぜそう私たちの意見では、最も信頼できるソリューションは、どのブラウザーとプラットフォームでも完全に機能します。 AJAXを使用した場合は、さまざまなブラウザーのクロスドメインとパフォーマンスの問題を解決する必要があります。 stat.gifとp.gifの2つの画像があります。最初の画像はページの読み込み時に使用され、ユーザーに関する基本情報を送信します。2番目の画像は15秒ごとに動き、時間とともに変化する情報（アクティブ/パッシブ、バッファリング、巻き戻し）を転送します。

この画像は、最初にページを開いたときに動揺します。

/stat.gif?pid=p0oGejy139055323022216801050bny0&l=http%3A%2F%2Fsite.ru%2F8637994&r=http%3A%2F%2Fsite.ru%2F&w=1680&h=1050&a=Mozilla%2F5.0%20(Windows%20NT%206.1%3B%20rv%3A26.0)%20Gecko%2F20100101%20Firefox%2F26.0&k=1390553230222&i=30000&vr=3.0

この写真は30秒ごとにひきつります：

 /p.gif?pid=p0oGejy139055323022216801050bny0&rand=6752416&b=1&time=2-188x190-57x50-349x251-83x0-235x&pl=29&fpl=46&ld=552&efsc=true&tfsc=19&tac=89&tpas=70&vr=3.0

トラフィックを減らすために、パラメータ名は省略されています。 PID-ページを表示するための一意の識別子は、stat.gifおよびp.gifからのデータと一致するように機能します。

サーバー側

私たちはすぐにデータベースを決定し、MongoDBを使用することにしました（クイックインサート、データはドキュメントに格納され、非リレーショナル構造）。最初の実装はphpで書かれており、重い負荷の下での最初のテストは深刻な問題を示しました。

php-fpm自体は、nginxと組み合わせて、リクエストを処理するために多くのリソースを消費しました。
stat.gifがMongoDBにロードされると、新しいドキュメントが挿入され、15秒ごとにp.gifイメージに付属するデータが更新されました。

stat.gifとp.gifからのデータを集約してmonguに挿入する必要があるのは、要求がp.gifへの送信を停止した後にのみ明らかになった。これにより、MongoDBの呼び出し回数を1桁減らすことができ、呼び出し自体は挿入時のみ（更新なし）になりました。 PHPの問題を解決できないため、新しいプラットフォームを選択することに関して疑問が生じました。 Webサーバーレベルでリクエストを処理する機能が必要だったため、NodeJSがすぐに選択されました。理由：非同期性、約束、馴染みのある構文（JavaScriptの豊富な経験）、コードの記述の比較的容易さ。 NodeJSを支持する選択に大きな影響を与えたのは、ashtuchkinによる出版物「Node.jsでの百万の同時接続」でした。サーバーで説明した実験を繰り返しました。

トラフィックとリクエストの性質について少し：開いているすべてのページにそのようなスクリプトがあり、15秒ごとにサーバーにデータをタップします。 1人のユーザーがそのようなページを一度に複数開くことができ、ユーザーがこのページを開いているかどうかに関係なく、すべてのページがデータを送信します。それだけで1日あたり約4,000万回の視聴があります。

NodeJS上のサーバーデバイス

最初に、テスト用にサーバーのシングルスレッドバージョンを作成しました。このスクリプトは非常に単純で、stat.gifおよびp.gifの画像のリクエストを受信し、このデータを配列に書き込みます。

 Array ( [PID] => Array ( [stat] =>    stat.gif     [pgif] =>     p.gif (  15 ) [time] =>   ,       PID ) )

さらにタイマーで、ハンドラーが起動され、PIDを使用してアレイ全体を反復処理し、このPIDによる最後のデータ変更の時刻をチェックします（Array [PID] [time]）。最後の変更から90秒以上が経過した場合（データが15秒ごとにユーザーから届かないため、ユーザーがページを閉じるか、インターネットが消えたことを意味するため）、レコードはMongoDBに挿入され、アレイ自体から削除されます。シングルスレッドバージョンをテストした後、マルチスレッドバージョンを実装することが決定されました（すべてのプロセッサ機能を最大限に活用するため）。

NodeJSでは、素晴らしいClusterモジュールのおかげでマルチスレッドが非常に簡単に実装されます。この記事のフレームワークでは、マルチスレッドコードの詳細には触れません（これについてはあまり説明していません）、このモジュールを使用すると、異なるスレッドの複数のインスタンスでコードの一部を実行でき、メッセージを使用してメインスレッドと子スレッドをやり取りするためのツールを提供します。

シングルスレッドアプリケーションのロジックは、ヘッドスレッドと子スレッドに分けられました。

子ストリームはhttpリクエストを受信し、1ピクセルの画像を返し、getリクエストの画像とともに受信したデータはヘッドストリームに送信されました。

worker-（子ストリーム）のコード例：

 //        server.on('request', function(req, res) { -  GET    var url_parts = url.parse(req.url, true); var query = url_parts.query; var url_string = url_parts.pathname.slice(1); var cookies = {}; switch(url_string){ //           /p.gif  /stat.gif case 'p.gif': process.send({ routeType: 'p.gif', params: url_parts.query}); //      if(image == undefined){ //                    --   fs.stat('p.gif', function(err, stat) { if (!err){ image = fs.readFileSync('p.gif'); res.end(image); } else res.end(); }); }else res.end(image); break; case 'stat.gif': url_parts.query.ip = req.connection.remoteAddress; process.send({ routeType: 'stat.gif', params: url_parts.query}); //      if(image == undefined){ //                    --   fs.stat('p.gif', function(err, stat) { if (!err){ image = fs.readFileSync('p.gif'); res.end(image); } else res.end(); }); }else res.end(image); break; default: // res.end('No file'); break; } });

データは、 process.send（{}）を使用してヘッドストリームに送信されます。

ヘッドストリームでは、子ストリームからのデータは

worker.on（ 'message'、function（data）{}）そして配列に書き込まれます。

サンプルヘッドストリームコード：

  ,         worker.on('message', function(data) { switch(data.routeType){ case 'p.gif': counter++; if(data.params.pid != undefined && dataObject[data.params.pid] != undefined){ //   PID,         dataObject[data.params.pid]['pgif'] = data.params; //   ,   dataObject[data.params.pid]['time'] = Math.ceil(new Date().getTime()/1000); //    } break; case 'stat.gif': counter++; if(data.params.pid != undefined){ if(dataObject[data.params.pid] == undefined) //   ,   dataObject[data.params.pid] = []; dataObject[data.params.pid]['stat'] = data.params; //     dataObject[data.params.pid]['time'] = Math.ceil(new Date().getTime()/1000); //      ,   ,     ,     } break; default: break; } });

また、タイマーがメインスレッドで起動され、配列内のエントリが分析され、90秒以上変更がなかったものがMongoDBデータベースに挿入されます。

データ保存

データストレージにも独自の微妙な違いがあるため、さまざまな実験中に、すべてのデータを1つのコレクション（MySQLのテーブルの類似物）に格納するのは悪い考えであるという結論に達しました。毎日新しいコレクションを作成することが決定されました-MongoDBの利点は簡単です。コレクションが存在せず、何かを書き込もうとすると、自動的に作成されます。その作業の過程で、サーバー側は名前に日付を含むデータをコレクションに書き込みます：stat20141102、stat20141103、stat20141104。

データベース構造：

1つのドキュメントの構造（1つのドキュメントは1つのビューに対応します）：

1日のデータの重量はかなり適切です-約500メガバイトは1/10がサンプリングされたときです（訪問者の10％のみが統計です）。サンプリングなしで実行された場合、コレクションの重量は1日に5ギガバイトになります。生データを含むコレクションは5日間のみ保存され、その後不要に削除されます。これは、クラウンで実行され、生データを処理し、それらをよりコンパクトな計算された形式で既に他のコレクションに書き込むスクリプトアグリゲーターが存在するためです。

レポート作成

最初に、レポートはfind（）およびMap-Reduceを使用して作成されました。 collection.find（）メソッドは単純な選択に使用され、より複雑なものはMap-Reduceを使用して構築されました。 2番目の方法は最も複雑で、分散コンピューティングメカニズムと実際の経験を完全に理解する必要があります。 MySQLでAVG、SUM、ORDER BY演算子によって解決されたタスクは、結果を取得するためにMap-Reduceで特定のトリックを必要としました。そのときの良い贈り物は、MongoDB 2.2の安定バージョンのリリースでした。AggregationFrameworkが登場し、データベースから複雑なサンプルを非常に簡単かつ迅速に作成できました。Map-Reduceには頼りませんでした。

集約によるリクエストの例（IDビデオでデータをグループ化し、要約|インジケーターで平均を取得）：

  db.stat20141103.aggregate([ { $match : { $nor : [{ ap : {$gt: 20}, loaded :0 }]} } , { $group: { _id:"$video_id", sum:{$sum:1}, active:{$sum:"$active" }, passive:{$sum:"$passive" }, buffer:{$sum:"$buffer" }, rewind:{$avg:"$rewindn" }, played:{$sum:"$played" } } } ]);

展開とデバッグ

これらすべてが高負荷下で適切に機能するためには、オペレーティングシステムとデータベースを少し構成する必要があります。

OS自体では、記述子の数を増やす必要がありました。 Ubuntuの場合、これは次のとおりです。

 #/etc/security/limits.conf #     (     ). * - nofile 1048576

他のLinuxシステムでは、/ etc / sysctl.confファイルの設定。

MongoDBを高速化するために、データベースファイルはSSDに配置されました。また、データベース構成を修正する必要がありました：ジャーナリンをオフにして、ディスクのフラッシュと情報の時間を操作しました（storage.syncPeriodSecs-このパラメーターは、MongoDBがRAMからディスクにデータをアンロードする頻度を示します）。

 /etc/mongodb.conf journal: enabled: false

PSコメントの質問への回答で記事を補足することにしました：

MongoDBベースを選択する理由は何ですか？

MongoDBデータベースの選択は、それを使った作業で既に肯定的な経験があったという事実によるものでした。PostgreSQLはこのタスクも処理できると思います-より良い結果が得られる可能性もあります

PIDはどのように、どこで生成されましたか？

PID-一意のフィールド。一意のビューを識別する必要があります。一意のユーザーID（IPおよびその他の情報に基づいて生成されます）+現在のUnixラベル、UAgent、画面解像度、およびランダム変数に基づいて生成されます。

彼らはページを開き、PIDが作成され、すぐに同じページを更新しました。まったく異なるPIDがあります。

ユーザーページのJavaScriptで生成された一意のユーザーIDは、Cookieを介してサーバーから取得されます。

ジャーナリングは有効になっていますか？バックアップ、耐障害性？そして、ノードレベルでのフォールトトレランス？

ジャーナル-オフ-数分でこれらの統計からのデータの損失は、このプロジェクトにとって重要ではありません

フォールトトレランスノード-使用した場合、子ストリームの軽微なエラーがこのストリームを停止させ、ヘッドストリームの場合はWebサーバー全体を停止させることがわかります。

ヘッドストリームで次のように決定しました。娘の流れが監視され、転倒した場合は再開されました。

ヘッドストリームが低下した場合、永久に使用されました-サーバーがクラッシュした場合、すぐに再起動し、エラーがログに書き込まれました

レポート受信の通常の遅延とは何ですか？最終日の集計または可能な限りリアルタイムに近い？

内部統計があり、彼女はトラフィックに関するいくつかの基本的なことを書いており、リアルタイムで利用できます。記事で説明したものは1時間の間隔で集約されています-これで十分です

同じGoogleアナリティクス（またはYandexMetrica）で満足しなかったものは何ですか？あなたが書いたものから、すべてがそれでできます

多くのトラフィック、グーグルなどがサンプリングを使用してレポートを作成し、サービスの負荷を減らすように依頼する手紙が届きました

Apache Storm-Hadoop / Sparkがこのクラスのタスクの標準ではないのはなぜですか？

Apache Storm / Hadoop / Sparkはそれらに精通していないため、JAVAで記述しません

最初は、php / MySQL / JS / HTMLでさまざまなコードを書く経験が豊富でした。

nodeJSでは、JS構文がほとんどの部分であるため、選択は彼女の方向に落ちました。

また、ハブでの議論中に、興味深いアイデアが浮上しました-NodeJSの一部をnginxに置き換え、必要な形式ですべてのデータをログに書き込み、一部のアプリケーションは挿入時にこのログを読み取り、データを処理してデータベースに挿入します。タスクの現在の状況では、これをうまく実装できます-このオプションの主な議論：nginxは、長年にわたって非常に信頼性が高く実績のあるソリューションです。

負荷の高いサイトの分析方法