最初のHighLoad Cup：どのように生き残ったのか

みなさんこんにちは！ 少し前に、 HighLoad Cupは終了しました。 多くの参加者は、内部からチャンピオンのデバイスについて多くの質問を受けました。 この記事では、Mail.Ru Groupのチャンピオンシップと教育プロジェクトの開発チームが、チャンピオンのデバイス、内部メカニズム、最初のHighLoad Cupの歴史について少し説明します！

まず、開発者を代表して、チャンピオンシップのすべての参加者に感謝します。 はい、これらはあなただけでなく、3週間の書き込みでした。 DCで数泊し、オフィスで数日休みました。 ファイアー！ ありがとう

チャンピオンシップのアイデアは、人生から、日常生活から生まれました。 ほとんどの（当社の）Web製品は、公開されている「パブリック」プロジェクトです。 インターネットでの生活は、開発者のコ​​ンピューターでの生活とは多少異なります。 検索エンジンがdr死し、群衆が群がる。

アプリケーションのサーバー側を開発するとき、アプリケーションのパフォーマンスを計算する必要があります。 何かが見落とされ、プロジェクトがサーバー容量の限界（または外部）にあることが起こります。 不十分な記述のアプリケーションを高価な機器に投入する-健康なアプリケーションを処理する方法は、最善の解決策ではありません。 適切な決定は、アプリケーションを正しく記述し、アーキテクチャとバックエンドを正しく実装することです。

ロシアコードカップ、MLBootCamp、ロシアAiカップ、ロシアデザインカップ、その他多くの選手権を開催しています。 それらのすべてが良いですが、本当のバックエンド開発者のその現実の生活は十分ではありません。 HighLoad Cupでは、まさにこの開発の現実を大衆に届けようとしました。

どのように機能しますか？

チャンピオンシップの開発における主な質問はこれでした：ソリューションをどこでどのようにひねるのか？ いくつかのオプションを検討しました。

1. 参加者は自分で鉄を見つけます。
2. 参加者にフルアクセスの仮想アクセスを提供します。
3. gitをコックし、ソリューションを起動するスクリプトの作成を依頼します。
4. Docker。
5. 放浪者。
6. 判断する。
7. メンバーはKVMまたはVirtualBoxイメージを提供します。
8. バージョン1〜7の誘導体とその組み合わせ。

実装を検討する際には、2つのポイントが重要でした。

1. すべての参加者に同じ条件。
2. セキュリティ。

結果が鉄に依存することは不可能です。 私たちの場合、まったく同じマシンですべてのソリューションをひねる必要があることがわかりました。 1つの方が良いですが、1日あたり48の決定（参加者）に十分です。 そのため、同一の車両を保有する必要があります。

はい、彼らはDockerを選択しました。 安全性を確保しながら、操作性、シンプルさ、利便性の妥協案として。 Dockerのないオプションは、開発者評議会での投票数が少なかった。 条件を満たしていないか、実装に多大な労力が必要であるか、過度に複雑でした。 docker自体はあまり透明ではありませんが、3つのdocker compose configオプションはすでに価値があります。

アーキテクチャは次のとおりです。

1. サイト Webアプリケーション。 （訪問者）ページを提供します。
2. 保管 docker-registry +特別なプロキシサーバーに基づきます。
3. ランナー。 特別な洗濯機には、タンク付きのコンテナが含まれます。
4. ハブ。 すべてのメカニズムを実装するアプリケーション。 サイトはハブを見ています。 ハブは、ストーリーとランナーを調べます。 必要な場所で必要なものを起動し、結果をサイトに提供します。

サイトに関するすべての質問の少なくとも。 登録、承認、タスク、ラウンド。 すべてが標準的かつ典型的です。

Storadzh。 Dockerレジストリはすぐに使用できますが、アクセス区分とストレージ制限は実装していません。 無制限に実行することは素晴らしいことですが、私たちはそれを買う余裕はありません。 ある参加者の決定を他の参加者が利用できないようにする必要があります。 アクセス制御とストレージ制限のためにストレージのプロキシを開発しました。

ハブ 実際、このコンポーネントは、発生するすべてのことを管理します。 「シェル化」のキューの形成から始まり、結果の処理で終わります。 彼女はすべてのランナーについて知っており、テストを実行して結果を求めます。 彼の要求に応じてサイトにそれらを与えます。

ランナー。 ここでは、すべてが一緒に起動され、結果の収集と処理、それらの一時保管が行われます。 自立型車は、シャーシベンダーまで同じですが、全世界から切り離され、一方向に機能します。 はい、リクエストはハブにのみ送信できます。 B-セキュリティ。 単一コンポーネントは、データベースの複製とダウンロードとともに複製で起動されます。 について-耐障害性。 初期構成には2人のランナーがいます。

より詳細に。

開発側のランナーは、JSONの「ハブ」およびdocker-registryと対話するサーバーのセットです。 ハブのコマンドに従って、サーバーのセットがdocker-composeを形成し、必要なタンクとソリューションのペアを起動し、結果を処理して保存し、オンデマンドで提供します。 私たちの仕事は、すべての人に同じ条件を保証することです。 同一で高負荷に十分です。 これを行うには、次のことを行います。

• Intel TurboBoostを無効にします。
• プロセッサ周波数を公称値のすぐ下に修正します。
• プロセスを爪（vcpupin）で物理コアに釘付けし、タンクを溶液から分離します。
• コンテナを拡張するためにディスク上の別のパーティションを選択します。
• tyunim sysctl、ulimit;
• 風水を簡単にするために、プロセスをnumanodeに修正します。

これらの対策により、シェリング結果の安定性、生産性、ジッターが小さくなります。

この複合体を展開してテストすることにより、これらすべてをKVMコンテナーにラップすることにしました。 これにより、次の利益が得られます。

A.カーネルパニック（ホストではなく仮想マシンのリブート）、BIOS、機器のフラッシュの試行、ホスト上の何かの変更の試行などを防ぐため。

B.ディスクの読み取りと書き込みのkbpsを制限します。 2つの同一のディスクはありません。 それらは常に異なった働きをします。 iotune仮想ディスクの制限を使用して、均一性を確保できます。

B.コンテナをすばやく再輸送、移動、または傾けます。

D.さらに、上記から、ホストマシン上のネットワークを制限します。

このようなソリューションの利点はインフラストラクチャにあります。 参加者に追加のパンを提供することはありませんが、操作のためにいくつかの問題を簡素化します。 kvm仮想化のオーバーヘッドは、私たちの場合の損失ではありません。主なことは、条件が同じであることです。

Dockerコンテナでは、特権のないユーザーも再マップされました。 ルート権限でウェブサーバーを起動しませんよね？

開発時間はゆっくりですが、確実に終わりました。 チャンピオンシップへの関心がどのようなものになるのか、それ以上の努力が必要かどうかはまったくわかりませんでした。 タスクは、この選手権に加えて、馬車と小さなカートです。 私たちは決めました-立ち上げます。 最初のトライアルを開始しました。 静かにやってみます。 MVPの準備ができました。 動作します。 試してみましょう、そして表示されます。 たぶんこれはすべて無駄で面白くないでしょうか？

行こう

簡単なタスク、いくつかのデータを準備しています。 データジェネレーター。 発表し、いくつかの投稿を行います。 空の評価を見てください。 私たちは経験しています。 すべてを監視するのが大好きです。 ソケットの電圧からsmartctlパラメーターまで。 それが発表の日でした。

「何かが壊れている」という疑念を抱いて、私たちの決断を押し進め、それをトップで見て、勝つことを恐れています。 また心配です。 最初のメンバーが表示されます。 喜ぶ！ しかし、私たちのソリューションは依然としてトップです。 まだ心配です。

「離陸しない」ことを心配する必要はありませんでした。 技術はITチャンピオンシップでは比較的非標準であるため、参加者は積極的にテスト実行を試み始めました。 評価は1日に1回に制限され、30分かかります。テストの評価は決して制限されません。 それらを制限するのはどういうわけか不公平です。

テスト実行のキューが形成されました。 2人のランナーが行方不明でした。 すでに翌朝、私たちはより多くのランナーを展開するための機器を探していました。すでに翌日の夕方にDCに座って、それぞれの微妙な設定を見逃さないように2台の新しい車をセットアップしました。 サービス中の4台の車。 上記の2つを設定しているときに、8つ以上でなければならないことが明らかになりました。

物語の場所は終わりました。 推定条件の40人の参加者には200 GBで十分なはずです。 最初の5日間の参加者はさらに10倍になりました。 しかし、ローンチのほぼ前に、状況は変化しています。ソリューションへのクエリの数とデータの量が増加しました。 私たちは、数テラバイトが必要であることを理解しています、注文します。 その間、結果用のストレージスペースが流れました。 少しの株を証明しますが、これは短期間では十分ではありません。

サイトを備えた控えめな仮想マシンが喫煙を開始し、プロセスをノンストップで実行します。 その間、警備員用のディスクを入手します。 まったく交換できません。 提供されません。 スロットなし。 30分間のダウンタイムと過剰充填を求めて、新しい車を準備しています。

参加者はさらにデータを要求します。 はい。 わずか20 MBです。 まあ、これは何もありません。 1 GBが必要です。 簡単ですね。 実際、これは、処理に必要なリソースと結果を保存する場所の両方で、100倍の増加です。

8人のランナーはすでに少数であることを理解しています。 もっと探しています。 まったく同じ構成の別のプロジェクトから4台の車を取り外し、コックします。 十二人のランナー。 それだけです そのような車はもうありません。

数回、私たちはファウルの危機にonしています。 外出先で何度か自分を救います。 そして、より多くの参加者がいます。

ピーク

これはチャンピオンシップチャットで最も頻繁に使用される言葉のようです。 それらを重視しないことも可能です。 これは、アプリケーションの実装曲線が原因である可能性があります。 たとえば、同じGC。 一方、RPSは10Kに達し、そのような速度では、システム内の誰でもアプリケーションでマイクロバーストを引き起こす可能性があります。 ほとんどの人がピークを迎えました。

この段階で、私たちは（実際、参加者が私たちに言ったように）アーキテクチャの省略について覚えていました。タンクはディスクに書き込みます。 彼はたくさん書いています。 タンク自体によって実行されるディスク操作は、システムにくしゃみを引き起こす可能性が非常に高いです。 これを解決するオプションは何でしたか？ RAMディスクに入れる：

a）ランナーディスク全体。

b）タンクが書き込むセクション。

まず、テストマシンで、RAM内のランナーディスク全体を取り出しました。 これによりディスク操作は保証されませんでしたが、この構成のほとんどのソリューションはOOMから落ちました。 理由を見つけることができませんでした。 より多くのメモリがありました。 おそらく、ソリューションは何らかの形でマシンで使用可能なメモリの合計を参照しており、ソリューションの制限が変更されなかったときに4倍になりました。 これにより、メモリソリューションによる誤った消費と、それに続くOOM Killが発生する可能性があります。

並行して、RAMディスクのタンクセクションを取り外して実験を実施しました。 彼は管理し、トップ50は常に機能しました。 これが解決策でした。 この動きは、ピークに関するすべての問題を解決しませんでした。 彼らは小さくなり、それほど重要ではなくなりましたが、彼らの存在はまだ研究されていました。

その間、期限は切れます。 C / C ++のトップで、自転車、トップ25のPHPの目障り、1日の決勝戦、そして私たちは3週間寝ていませんでした。

ファイナル

当初、フィナーレは定期的なラウンドとして計画され、各決定が順番に開始され、最良のものが特定されました。 これは正義を保証するものではありませんでした。異なる起動での同じソリューションは、まともな結果の実行を示しました。 最良の決定を正直かつ公正に識別するために、参加者自身が提案した方法が採用され、最終決定を下しました。 結果を得るには、最善の（最小の）時間を費やします。 したがって、私たちは皆の機会を平等にします。 書く日、テストする夜。 始めます。 チャンピオンシップの中で最長の決勝戦でした。 ファイナリストの決定は1日半テストされました。

要約すると、次のことに注意してください。

1. コンピューティング（鉄）リソースの計画における多くの間違いは、私たちの生活をより楽しくしました。 私たちはもう少し経験を積んでいます。
2. 大きなRPSではピークは避けられません。 もちろん、それらを水平にする必要があります。
3. 最初に発明されたタスクは単純すぎました。 思う。

そして、実際には、これですべてです。 開発チームの目を通して、これらは3週間の激しいハードコアでした。 開発者を代表して、参加者に感謝したいと思います！ あなたがいなければ、私たちはそれほど多くのドライブを得られなかっただろう。 私たちはあなたと一緒に画面の反対側のチャンピオンシップに参加しました！ ありがとう マキシムxammi-1 Kislenko、Boris bkolganov Kolganov 、Yegor geoolekom Komarov、Ilya liofz Lebedev、Ilya sat2707 Stytsenkoが試しました 。