RIT ++の2日目が過ぎました。熱い追求の中で、私たちは全世界が私たちの投票投票を破ろうとしたことについて話したいと思います。 カットの下-コード、メトリック、勝者と最もアクティブな参加者の名前、およびその他の汚れた詳細。
RIT ++の少し前に、人々を楽しませる方法を考えましたか？ 最もクールなプログラミング言語に投票することにしました。 そして、リアルタイムの結果がダッシュボードに表示されるようにします。 投票手順は簡単になりました。任意のデバイスからODN.PW Webサイトにアクセスし、名前と電子メールを示し、任意の言語に投票することができました。 言語のリストは使用しませんでした。GitHubによると、最も人気のある9つの言語を使用し、「その他」という言語を10番目のポイントにしました。 サイコロの色もGitHubから取得しました。
しかし、私たちは不正行為は避けられないことを理解し、「重砲」を使用することで-高度な聴衆の皆さん、これはママのフォーラムでの投票ではありません。 そのため、可能な限りあらゆる方法でラッピングを歓迎することにしました。 さらに、彼らは私たちの投票に大きな負荷をかけるためにコミュニティを試みることを提案しました。 また、参加者がさらに簡単にするために、ボットを使用したマークアップ用のAPIへのリンクを投稿しました。 同時に、RPSの数が最も多い最初の3人の参加者にインセンティブ賞を与えることにしました。 単独で投票を破ることができる強者のために、別の指名が準備されました。
初日
投票の投票は、RIT ++の作業の最初からほぼ開始され、18時まで機能しました。 私たちのエンターテインメントは、RIT ++の訪問者と講演者に好まれました。 高性能のサービススペシャリストがRPSレースに積極的に関与しています。 ブースのゲストは、投票を行う方法を鮮やかに話し合いました。 ある言語または別の言語の支持者のチームが自発的に発生し、プロモーション戦略を思いつき始めました。 誰かがすぐに座って、投票に参加するためにマイクロサービスまたはボットを書き始めました。
RIT ++に参加し、安全なホスティングサービスを提供する一部の企業も当社の競争に参加しました。 一日の終わりまでに、共同の努力によって、参加者はまだしばらくの間システムを設置することができました。 まあ、彼らが言ったように、サービスはうまくいきました、私たちは同時に登録された票の数によって天井にぶつかりました。 したがって、18時までに投票を停止しました。そうしないと、結果が信頼できなくなります。
1日目の結果によると、1億6,000万票を獲得し、ピーク負荷は20,000 RPSに達しました。 この日は、RIT ++のアクティブな参加者が1位と2位を獲得したことに興味があります。
Nikolai Matsievsky（Airi）とスピーカーのOpenproviderのElena Grahovac。
夜、私たちは翌日、彼と完全に武装するための準備をしました。基地とのコミュニケーションを最適化し、各ワーカーのNode.jsアプリケーションの前にnginxを配置しました。
二日目
RPSをめぐる競争は魅力的な仕事であるため、投票を行うという私たちの提案に多くの人が興味を持ちました。 DNSを切り替えると、RPSの数は100,000に急増し、30分後には300,000 RPSになりました。
面白いのは、投票用紙の作成を始めたとき、「100,000 RPSをサポートできたらいい」と決めたことです。 念のため、最大パフォーマンスは100万RPSでしたが、同時にそのような指標に近づく可能性を真剣に検討しませんでした。 そして、2日目の半ばまでに、彼らは1秒あたり100万件のリクエストの上限を破るかどうかにほとんど賭けていました。 その結果、約500,000 RPSに達しました。
実装
RIT ++の直前に、プロジェクトを1.5日間一緒に見ました。 投票はGoogle Cloud Platformクラウドサービスに投稿されました。 3レベルのアーキテクチャ：
•上位レベル：要求のストリームが到着するフロントエンドとして機能するバランサー。 彼はサーバーに負荷をかけます。
•中間：Node.js 8.0のバックエンド。 関連するマシンの数は、現在の負荷に応じて調整されます。 これは、何も支払わないために、余裕をもってではなく、控えめに行われます。 ちなみに、プロジェクターは8,000ルーブルかかりました。
•下位レベル：3つのサーバー（1つのマスターと2つのスレーブ）で構成される、投票を保存するクラスター化されたMongoDB。
すべての投票コンポーネントはオープンソースであり、Githubで入手できます。
•バックエンド： https : //github.com/spukst3r/counter-store
•フロントエンド： https : //github.com/weglov/treechart
バックエンドの開発中に、投票をラッピングするためのすべてのリクエストをキャッシュし、それらを定期的にデータベースに送信するというアイデアがありました。 しかし、時間の不足、参加者の数の不確実性、怠baな怠dueのために、このアイデアを延期し、リクエストごとにデータベースにデータを送信することにしました。 同時に、このモードでのMongoDBのパフォーマンスがチェックされます。
さて、最初の日が示したように、すぐにキャッシュを固定する必要がありました。 各Node.jsワーカーは、POST on / pollごとに3000 RPSを超えずに発行し、MongoDBマスターはLA> 100で激しく咳をしました。 読み取りのスレーブを使用するように読み取り設定を変更することで、クエリの集計を最適化して統計情報を取得することすらサポートしていません。 さて、何もありません。カウンターをラップし、電子メールの有効性をチェックするためのキャッシュを実装するときです（ユーザーを削除しないため、単純な_.memoizeでラップされています）。 また、Google Compute Engineで新しいプロジェクトを使用し、割り当てを増やしました。
音声キャッシュをオンにした後、MongoDBは最高の気分で、ピーク負荷時でもLA <1を示しました。 そして、各労働者の生産性は50％増加しました-最大4500 RPS。 定期的なデータ送信の場合、 orderedパラメーターを無効にしてbulkWriteを使用し、ベース側でリクエストの実行順序を維持して速度を最適化しました。
初日、Node.jsサーバーは各ワーカーで動作し、クラスターモジュールを介して4つの子プロセスを作成し、それぞれがポート3000をリッスンしました。2日目は、そのようなサーバーを放棄し、「プロ」 実験では、unixソケットを介してアプリケーションと対話するnginxが約+500 RPSを提供することが示されました。 この設定は、worker_rlimit_nofileの増加、十分なworker_connections、tcp_nopushおよびtcp_nodelayを含む、多数の接続に対するかなり標準的なものです。 ちなみに、 Nagleアルゴリズムを無効にすると、 Node.jsのRPSが上がりました。 各仮想マシンでは、開いているファイルの数とバックログの最大サイズの制限を増やす必要がありました。
まとめ
2日間、参加者だけではサービスを提供できませんでした。 しかし、最初の日の終わりには、共通の努力により、システムにすべての着信要求を登録する時間がありませんでした。 2日目に、最大450,000 RPSの負荷を記録しました。 フロントでのRPS読み取り値（データベースの実際のエントリでRPSを計算および平均化）とGoogleの監視読み取り値の違いは謎のままです。
そして、私たちは小さな競争の勝者を発表できることを嬉しく思います。
1位-{"_id"： "ivan@buymov.ru"、 "count"：2107126721}
2位-{"_id"： "burik666@gmail.com"、 "count"：1453014107}
3位-{"_id"： "256@flant.com"、 "count"：626160912}
賞品については、 kosheleva_ingram_microにご連絡ください ！
UPD： 殿堂入りTOP50