HighLoad Cup＃2。 バックエンド開発者がサービスを再開するためのチャンピオンシップ

新たな挑戦の準備はできていますか？ 高負荷のサービスHighLoad Cup＃2の設計と管理のために、すべてのアマチュアとプロをチャンピオンシップに招待します！

競争は昨年開始されました。 そして、HighLoad Cupは、多くのMail.Ru Groupプロジェクトで欠けていたチャンピオンシップであることを知っていました。 最初のパイロット競技には449人が参加しました。 主催者と参加者の両方に多くのコードと多くの汗がありました（8789の異なるソリューション）。 技術的な実装には微妙な違いがありましたが、最も重要なことは、誰もがそれを気に入っていたことです！ オーガナイザーはデータセンターで何晩も過ごし、オフィスで数日間休みました。 再び準備ができました！ 記事の最後に、私たちと参加者からの有用な資料があります。これは、メカニズムを理解し、ベストプラクティスのソリューションを見つけるのに役立ちます。

今回、彼らはあなたのために、より困難なビジネスを準備しようとしました。 さらに、視聴者を拡大し、英語を話すユーザーがコンテストに参加できるようになりました。 Telegramでロシア語を話すコミュニティに参加してください。 そこでは、競争に関する多くの洞察が得られます:)



さあ、ようこそ！

力学

昨年と比較して、コンペティションでは概念的に何も変わっていません。

参加者には、特定の構造のデータを処理し、このデータのAPIを実装する小さなWebサービスを作成するタスクが与えられます。 実装されたサービスを持つコンテナ（Docker）がサーバーにアップロードされ、そこでサーバーを起動してHTTPリクエストでシェルを開始します。

ソリューションは、特別なリポジトリにローカルにインストールされたDockerクライアントを使用して送信されます（各クライアントには独自のリポジトリがあります）。 その後、送信されたサービスは、Mail.Ru Group Technopark Laboratoryのスタッフが開発したCodeHub-CodeRunnerシステムによって自動的にチェックされます。

次に、Intel Core i7プロセッサを搭載したテストマシンでコンテナを「ハンマー」で打ち始めます。 このソリューションには、2.4 GHzの4つのコア、2 GBのRAM、および10 GBのハードディスク領域が割り当てられます。 要するに、「タンク」はファントムエンジンで起動され、線形に成長する負荷プロファイルで複数のストリームで起動します。 シェル処理の前に、ユーザーのソリューションは、受信したJSONファイルからデータを処理するために数分かかります（正確な量はタスクによって異なります）。 これらのデータを正しく処理することは、勝利に必要な条件です。 ショートとロングの2つだけを砲撃します。

このような攻撃の結果に基づいて、正解と不正解の数、RPS、および応答速度を計算し、特定のメトリックの評価表を作成します。 最速かつ最も耐障害性の高いサービスの作成者が勝者になります。



見つけたり思いついたりできるウェブ技術を使用してください。 独自のプログラミング言語とフレームワークを選択してください。 C ++、Java + Tomcat、Python + Django、Ruby + RoR、GoLang、JavaScript + NodeJs、Haskell、さらにはアセンブラーなどを自由に選択できます。 データストレージの場合：MySQL、PostgreSQL、Redis、MongoDB、キャッシュ。 完全な自由！

シェル化の結果として、ログとメトリックが取得され、決定ページにグラフ形式で参加者に表示されます。 個別に追跡：

• 基本的な指標;
• 正解。
• リクエストへの応答速度。
• 1秒あたりの応答数。

ソリューションの評価は次のように計算されます：シェル処理中にAPIが管理できたすべての正しい回答の時間を取り、応答を受信できなかった不正な回答またはリクエストごとにペナルティ時間を追加します（ペナルティ時間は常に合計リクエストタイムアウトに等しくなります）。 合計時間が他の人よりも短い参加者は、リーダーボードで上位にあり、チャンピオンシップの勝者になるチャンスがあります。

挑戦する

私たちのチームは、今年、どのような仕事をすべきかを長い間考えていました。 彼らは、大多数の可能性を平準化するものを望んでいました（C / C ++の一部の自作自転車が勝てないように）。

文言は次のとおりです。

別の現実では、人類は「後半」のグローバル検索システムを作成して起動することにしました。 これは、世界中の独身者の数を減らし、強い家族を作るのに役立つように設計されています。

テストとさまざまな砲撃の「戦闘」データの両方で、1つのエンティティ：アカウントに関するエントリがあります。 ユーザーに関するすべての既知の情報-彼の名前、連絡先、興味、他のユーザーへの同情を明らかにします。 提供されるデータの精度は、以下に示す種類と制限に従って保証されます。 すべてのデータは、特定の法律に従って当社によって生成および発明されました。

次の個人データは、1つのアカウントレコードに含まれています。

• id-ユーザーの一意の外部識別子。 テストシステムによってインストールされ、サーバーの応答を確認するために使用されます。 タイプは32ビット整数です。
• email-ユーザーのメールアドレス。 タイプは、最大100文字のUnicode文字列です。 一意性が保証されます。
• fnameとsname-それぞれ名と姓。 タイプ-最大50文字のUnicode文字列。 フィールドはオプションであり、特定のレコードに存在しない場合があります。
• 電話 -携帯電話番号。 タイプは、最大16文字のUnicode文字列です。 フィールドはオプションですが、指定された値に対して一意性が保証されます。 まれにしか満たされません。
• sexはユニコード文字列で、「m」は男性、「f」は女性を意味します。
• birth-生年月日 。UTCでUNIX時代の初めからの秒数として記録されます（つまり、これはタイムスタンプです）。 2005年1月1日より上、1950年1月1日より下に限定。
• 国 -居住国。 タイプは、最大50文字のUnicode文字列です。 フィールドはオプションです。
• city-居住都市。 タイプは、最大50文字のUnicode文字列です。 フィールドはオプションであり、めったに指定されません。 各都市は特定の国にあります。

また、1つのアカウントレコードには、後半の検索エンジンに固有のフィールドがあります。

• 参加 -システムへの登録日。 タイプ-制限付きのタイムスタンプ：2011年1月1日より下、2018年1月1日より上。
• status-システム内のユーザーの現在のステータス。 タイプ-次のオプションの1行：「無料」、「ビジー」、「すべてが複雑です。」 奇妙な結末に注意しないでください:)
• 関心 -日常生活におけるユーザーの関心。 タイプ-Unicode文字列の配列。空の場合もあります。 行の長さは100文字を超えません。
• プレミアム -システムのプレミアム期間の開始と終了（ユーザーが本当に「ソウルメイト」を見つけたいと思ったときに、サービスの代金を支払いました）。 JSONでは、このフィールドは、開始フィールドと終了フィールドを持つネストされたオブジェクトで表されます。下限を持つタイムスタンプは、2018年1月1日に記録されます。
• likes-既知のユーザーの「 いいね！」の配列。空の場合もあります。 すべての同情は異なって行き、それぞれは次のフィールドからのオブジェクトを表します：
  
  • id-ユーザーが気に入っている別のアカウントの識別子。 アカウントは、常にIDによってソースデータで見つけることができます。 データには同じIDのいいね！が複数ある場合があることに注意してください。
  • ts-共感がシステムに記録された時間、つまりタイムスタンプ。

APIを実装する必要があります。

1. ユーザーのリストの取得： /アカウント/フィルター/
   
   このAPIメソッドは、既知のフィールドまたは目的のフィールドでユーザーを検索するために使用する予定です。 たとえば、特定の都市に住んでいる特定の年齢と性別のすべての人を見たいと思った人がいました。
2. ユーザーのグループ化： /アカウント/グループ/
   
   このAPIメソッドは、システムの動作に関するレポートを作成するために使用される予定です。 グループ化に使用されるフィールドは、コンマで区切られたキーGETパラメーターで渡されます。 それらは、ユーザーフィルタリング要求ほど多くありません。 グループ化するフィールドは、性別、ステータス、興味、国、都市の5つだけです。
3. 互換性の推奨事項： /アカウント/ ID /推奨/
   
   このクエリは、指定されたユーザーデータの「後半」を検索するために使用されます。 リクエストは、ステータス、年齢、興味によって最適なユーザーが検索されるユーザーのIDを渡します。 決定は、異性との互換性のみをチェックする必要があります（性的マイノリティに反対して差別を非難するのではなく、たまたま起こっただけです）。 それぞれ国キーと都市キーを持つ国または都市がGETリクエストで送信された場合、指定した場所に住んでいる人だけを検索する必要があります。
4. 同様のいいねの選択：/ アカウント/ ID /提案/
   
   このタイプのクエリは、「ソウルメイト」の検索に関するものでもあるという点で、前のクエリと似ています。 ソウルメイトを探しているユーザーのIDも送信され、制限GETパラメーターが使用されます。 実装の違い：私たちは、同じ性別で似た「好き」な人を探しており、最近自分が好きな人を提供しています。 リクエストが国または都市のGETパラメータを受け取った場合、特定の場所でのみ「同様の同情」を探す必要があります。

1つの記事ですべてを伝えることは不可能です。 詳細なルールは、発売日（今日）にチャンピオンシップWebサイトとGitHubリポジトリに公開されますが、これで何が待っているかがわかります。

スケジュール

はい、私たちは休日が来ることを知っていますので、選手権は非常に長くなります:)

1. ベータテスト（結果は考慮されません）：12月13日19:00に開始し、12月21日19:00に終了します。
2. 予選ラウンド：12月21日19:00から1月31日19:00まで。
3. 最終ラウンド：2月5日まで。

ベータテスト中に、タスクのルールと条件が変更される場合があります（バグが存在する場合、およびその他の理由により）。

予選ラウンド-ルールは変わりません。

最終ラウンドは完全に自動化されていますが、その前にファイナリスト（予選ラウンドの結果を通過したN人のユーザーと少なくとも50人）が、いくつかの波で掻き集められるソリューションを選択します。 結果は、すべての波の最良の結果によって形成されます。

プレゼント

1位は真新しいMacBook Airです。
2位および3位-Apple iPad。
4、5、6位-Samsung Gear S3。

参加者は、見返りに同等の価値の別の贈り物を求める権利があります。 決勝に出場したすべての参加者には、チャンピオンシップのブランドTシャツが贈られます。

コミュニティ

Telegramチャットルームにアクセスする場合、すでに退室することはほとんどありません。 私たちはあなたを待っています、そして幸運を！

謝辞

この記事では、システムアップデートの問題については説明しません。 インフラストラクチャのバグを排除するために多くの作業を行い、GitHubの参加者からのすべての問題を確認し、既に何かを実装して来年のTODOリストに入れました。 Maxim @ xammi- Kislenko、Ilya @liofz Lebedev、Evgeny @gunicorn Ivanov、Irina @aithelle Lukyanova、Vasily @vasidmi Dmitriev、およびチャンピオンシップコミュニティ全体を含むチーム全体に深く感謝したいと思います。 よろしくお願いします！