Coupe HighLoad # 2. Championnat pour les développeurs backend de retour en service

Êtes-vous prêt à relever de nouveaux défis? Nous invitons tous les amateurs et professionnels au championnat pour la conception et l'administration de services hautement chargés HighLoad Cup # 2 !

La compétition a commencé l'année dernière. Ensuite, nous savions que la HighLoad Cup était exactement le championnat qui manquait dans un certain nombre de projets du Mail.Ru Group. Le premier concours pilote a réuni 449 personnes. Il y avait beaucoup de code et beaucoup de sueur de la part des organisateurs et des participants (8789 solutions différentes). Il y avait des nuances dans la mise en œuvre technique, mais surtout, tout le monde l'a aimé! Les organisateurs ont passé de nombreuses nuits dans le centre de données, plusieurs jours de congé au bureau. Prêt à recommencer! À la fin de l'article, vous trouverez des documents utiles de notre part et des participants, qui vous aideront à comprendre la mécanique et à trouver des solutions de meilleures pratiques.

Cette fois, ils ont essayé de vous préparer une entreprise plus difficile. De plus, nous avons élargi l'audience, maintenant les utilisateurs anglophones peuvent participer au concours. Rejoignez la communauté russophone dans Telegram . Là, vous obtiendrez beaucoup d'informations sur la concurrence :)



Alors bienvenue à bord!

La mécanique

Par rapport à l'année dernière, rien n'a conceptuellement changé dans la compétition.

Les participants sont chargés de créer un petit service Web qui fonctionne avec des données d'une certaine structure et implémente une API pour ces données. Un conteneur (Docker) avec le service implémenté est téléchargé sur nos serveurs, où nous le lançons et commençons à le bombarder avec des requêtes HTTP.

Les solutions nous sont envoyées à l'aide d'un client Docker installé localement dans un référentiel spécial (chacun a le sien). Ensuite, le service qui nous est envoyé est automatiquement vérifié par le système CodeHub-CodeRunner développé par le personnel du laboratoire Technopark de Mail.Ru Group.

Ensuite, nous commençons à «marteler» le conteneur sur une machine de test avec un processeur Intel Core i7. La solution se verra allouer 4 cœurs de 2,4 GHz, 2 Go de RAM et 10 Go d'espace disque dur. En bref, un «réservoir» est lancé avec le moteur fantôme, qui tire sur plusieurs flux avec un profil de charge à croissance linéaire. Avant le décorticage, la solution de l'utilisateur dispose de plusieurs minutes (le montant exact dépend de la tâche) pour traiter les données du fichier JSON reçu. Un travail correct avec ces données est une condition nécessaire à la victoire. Décorticage seulement deux, court et long.

Sur la base des résultats de ces attaques, nous calculons le nombre de réponses correctes et incorrectes, le RPS et la vitesse de réponse, et formons un tableau de notation pour une certaine métrique. L'auteur du service le plus rapide et le plus tolérant aux pannes sera le gagnant.



Utilisez n'importe quelle technologie Web que vous pouvez trouver ou trouver. Choisissez votre propre langage et framework de programmation. Il peut s'agir de C ++, Java + Tomcat, Python + Django, Ruby + RoR, GoLang, JavaScript + NodeJs, Haskell, au moins Assembleur ou autre, à votre discrétion. Pour le stockage de données: MySQL, PostgreSQL, Redis, MongoDB, caches. Liberté totale!

À la suite du bombardement, des journaux et des mesures sont obtenus, qui seront ensuite montrés aux participants sous forme de graphiques sur la page de décision. Suivi séparément:

• mesures de base;
• bonne réponse;
• rapidité de réponse à une demande;
• nombre de réponses par seconde.

La note de la solution est calculée comme suit: nous prenons le temps de toutes les bonnes réponses que l'API a réussi à donner lors du bombardement, nous ajoutons un temps de pénalité pour chaque réponse ou demande incorrecte pour laquelle nous n'avons pas pu recevoir de réponse (le temps de pénalité est toujours égal au délai total de demande). Le participant, dont le temps total est inférieur aux autres, est plus haut dans le classement et a une chance de devenir le vainqueur du championnat.

Défi

Notre équipe a longtemps réfléchi à la tâche à accomplir cette année. Ils voulaient quelque chose qui égaliserait les chances de la majorité (pour que certains vélos fabriqués en C / C ++ ne gagnent pas).

Le libellé est le suivant:

Dans une réalité alternative, l'humanité a décidé de créer et de lancer un système de recherche mondial pour le "second semestre". Il est conçu pour réduire le nombre de célibataires dans le monde et aider à créer des familles fortes.

Dans les données de test et de «combat» pour divers bombardements, il existe des entrées concernant une entité: le compte. Il décrit toutes les informations connues sur l'utilisateur - son nom, ses contacts, ses intérêts, sa sympathie pour les autres utilisateurs. L'exactitude des données fournies est garantie conformément aux types et limitations indiqués ci-dessous. Toutes les données ont été générées et inventées par nous conformément à certaines lois.

Les données personnelles suivantes sont contenues dans un enregistrement de compte:

• id - identifiant externe unique de l'utilisateur. Il est installé par le système de test, puis utilisé pour vérifier les réponses du serveur. Le type est un entier 32 bits.
• email - l'adresse e-mail de l'utilisateur. Type - chaîne unicode jusqu'à 100 caractères. Unicité garantie.
• fname et sname - prénom et nom de famille, respectivement. Type - chaînes unicode jusqu'à 50 caractères. Les champs sont facultatifs et peuvent ne pas être présents dans un enregistrement particulier.
• téléphone - numéro de téléphone portable. Le type est une chaîne unicode de 16 caractères maximum. Le champ est facultatif, mais l'unicité est garantie pour les valeurs spécifiées. Il est assez rarement rempli.
• le sexe est une chaîne unicode, «m» signifie mâle et «f» signifie femelle.
• birth - date de naissance, enregistrée comme le nombre de secondes depuis le début de l'ère UNIX en UTC (en d'autres termes, il s'agit d'un horodatage). Limitée du dessous du 01/01/1950, du dessus du 01/01/2005.
• pays - pays de résidence. Le type est une chaîne unicode de 50 caractères maximum. Le champ est facultatif.
• ville - ville de résidence. Le type est une chaîne unicode de 50 caractères maximum. Le champ est facultatif et est rarement spécifié. Chaque ville est située dans un pays particulier.

De plus, dans un enregistrement de compte, il existe des champs spécifiques au moteur de recherche pour la seconde moitié:

• rejoint - date d'enregistrement dans le système. Type - horodatage avec restrictions: en dessous du 01.01.2011, en haut du 01.01.2018.
• status - l'état actuel de l'utilisateur dans le système. Tapez - une ligne des options suivantes: "gratuit", "occupé", "tout est compliqué". Ne faites pas attention aux fins étranges :)
• intérêts - intérêts de l'utilisateur dans la vie quotidienne. Type - un tableau de chaînes unicode, éventuellement vide. Les lignes ne dépassent pas 100 caractères.
• premium - le début et la fin de la période de prime dans le système (lorsque les utilisateurs voulaient vraiment trouver un «âme sœur» et qu'ils ont payé pour le service). En JSON, ce champ est représenté par un objet imbriqué avec les champs de début et de fin, où les horodatages avec une limite inférieure sont enregistrés le 01/01/2018.
• likes - un tableau des likes connus de l'utilisateur, éventuellement vides. Toutes les sympathies vont différemment et chacune représente un objet des champs suivants:
  
  • id - l'identifiant d'un autre compte que l'utilisateur aime. Le compte peut toujours être trouvé dans les données source par id. Veuillez noter que dans les données, il peut y avoir plusieurs likes avec le même identifiant.
  • ts - heure, c'est-à-dire horodatage, lorsque la sympathie a été enregistrée dans le système.

Vous devez implémenter l'API.

1. Obtenir une liste d'utilisateurs: / comptes / filtre /
   
   Cette méthode API devrait être utilisée pour rechercher des utilisateurs dans des domaines précédemment connus ou souhaités. Par exemple, quelqu'un voulait voir toutes les personnes d'un certain âge et sexe vivant dans une ville particulière.
2. Regroupement d'utilisateurs: / comptes / groupe /
   
   Cette méthode API devrait être utilisée pour créer des rapports sur le fonctionnement du système. Les champs utilisés pour le regroupement sont transmis dans les clés de paramètres GET séparées par des virgules. Ils ne sont pas aussi nombreux que dans la demande de filtrage des utilisateurs. Il n'y a que cinq champs pour le regroupement - sexe, statut, intérêts, pays, ville.
3. Recommandations de compatibilité: / accounts / id / recommend /
   
   Cette requête est utilisée pour rechercher la "seconde moitié" dans les données utilisateur spécifiées. La demande transmet l'identifiant de l'utilisateur pour lequel ceux qui sont les mieux adaptés par statut, âge et intérêts sont recherchés. La décision devrait vérifier la compatibilité uniquement avec le sexe opposé (nous ne sommes pas contre les minorités sexuelles et condamnons la discrimination, c'est juste arrivé :)). Si le pays ou la ville avec les clés de pays et de ville, respectivement, est transmis dans la demande GET, vous devez rechercher uniquement parmi ceux qui vivent dans le lieu spécifié.
4. Correspondance avec des mentions similaires: / accounts / id / suggest /
   
   Ce type de requête est similaire à la précédente dans la mesure où il concerne également la recherche des "âmes sœurs". L'identifiant de l'utilisateur pour lequel nous recherchons une âme sœur est également envoyé, le paramètre GET limite est utilisé. Différences dans la mise en œuvre: nous recherchons des personnes comme le même sexe avec des «likes» similaires et proposons à ceux qu'ils ont récemment aimé eux-mêmes. Si la demande reçoit le paramètre GET du pays ou de la ville, vous devez rechercher des «sympathies similaires» uniquement dans un certain endroit.

Tout dire dans un seul article n'est pas possible. Les règles détaillées seront publiées le jour du lancement (aujourd'hui) sur le site Web du championnat et dans le référentiel GitHub , mais vous savez maintenant ce qui vous attend.

Horaire

Oui, nous savons que les vacances (avec les prochaines), donc le championnat sera très long :)

1. Test bêta (les résultats ne sont pas pris en compte): début le 13 décembre à 19h00, fin le 21 décembre à 19h00.
2. Phase de qualification: du 21 décembre 19h00 au 31 janvier 19h00.
3. Phase finale: jusqu'au 5 février.

Pendant les tests bêta, les règles et conditions de la tâche peuvent changer (en présence de bugs et pour d'autres raisons).

Tour de qualification - les règles ne changent pas.

Le tour final est entièrement automatique, mais avant lui les finalistes (N utilisateurs qui ont passé les résultats du tour de qualification et au moins 50 personnes) choisissent une solution qui sera tirée en plusieurs vagues. Le résultat est formé par le meilleur résultat pour toutes les vagues.

Présente

La première place est le tout nouveau MacBook Air.
Deuxième et troisième place - Apple iPad.
Quatrième, cinquième et sixième places - Samsung Gear S3.

Le participant a le droit de demander en retour un autre cadeau de valeur équivalente. Tous les participants qui se sont qualifiés pour la finale recevront des T-shirts de marque de notre championnat.

Communauté

Si vous allez dans notre salon de discussion Telegram , il est peu probable que vous le quittiez déjà. Nous vous attendons et bonne chance!

Remerciements

Cet article ne traite pas des problèmes de mise à jour du système. Nous avons fait beaucoup de travail pour éliminer les bogues d'infrastructure, examiné tous les problèmes des participants sur GitHub, déjà implémenté quelque chose et l'avons mis dans la liste TODO pour l'année prochaine. Je tiens à exprimer ma profonde gratitude à Maxim @ xammi- Kislenko, Ilya @liofz Lebedev, Eugene @gunicorn Ivanov, Irina @aithelle Lukyanova, Vasily @vasidmi Dmitriev et à toute l'équipe qui a participé à la compétition, y compris toute la communauté du championnat. Je vous remercie!