Я работаю программистом в игровой студии IT Territory, а с недавних пор перешел на направление экспериментальных проектов, где мы проверяем на прототипах различные геймплейные гипотезы. И работая над одним из прототипов мы столкнулись с задачей генерации случайных чисел. Я хотел бы поделиться с вами полученным опытом: расскажу о псевдогенераторах случайных чисел, об альтернативе в виде хеш-функции, покажу, как её можно оптимизировать, и опишу комбинированные подходы, которые мы применяли в проекте.

Антиспам Почты Mail.ru — это симбиоз продуктовой логики и инфраструктурных технологий, про который мы решили более подробно рассказать. В основе конечно же лежит инфраструктура, с помощью которой мы получаем возможности для развития моделей машинного обучения, а также платформа ядра, которая обеспечивает работу антиспама в онлайне. Продуктовая логика представлена в виде большого количества эвристик (куда без них) и ручных правил. На вершине продуктовой пирамиды пребывает стек моделей машинного обучения, хотя положение на вершине в данном случае достаточно условно.

В этой статье мы заберемся на эту вершину, где в последнее время часто вбивают новые колышки текстовые модели. Мы спроецируем мир текстовых ML-моделей на наш сервис, поговорим про эволюцию и решение задач Почты, связанных с текстами. Запасайтесь кислородом и свободным временем.

Вряд ли сейчас можно встретить разработчика, который ничего не слышал об очередях сообщений. Самые известные брокеры сообщений это: Apache Kafka, RabbitMQ и IBM MQ. Все также наверняка знают об облачных решениях, предлагаемых Amazon. Есть у них и стандартизованные API для работы с очередями.

Одно из них, Simple Queue Service, мы взяли за основу и разработали распределенную очередь для запуска в облаке Mail.ru. SQS это стандартный API для облаков, его широко используют многие компании, от BMW до NASA.

В статье описано, что такое распределенные очереди и зачем они могут понадобиться, какие в них есть особенности, и о том, какое у нас получилось распределенное решение на базе Tarantool.

Думаю, во многих компаниях есть свои R&D-команды, которые ищут новые продукты. Такую решили организовать и в нашей студии, и меня туда пригласили. Конечно же, поначалу мы все были окрылены идеей, что сейчас мы в команде экспериментальных проектов и будем писать ПРОТОТИПЫ. Звучит-то как! Мы будем экспериментировать с новыми библиотеками, так сказать «щупать» новые технологии и вообще делать что-то новое почти каждый месяц! Значит, нам не только не надоест какой-то проект, но и можно не заботиться о долгосрочной поддержке кода. Ведь это начальство разрешает забить на качество написания кода в угоду скорости разработки, ведь всё потом полетит в мусорку и будет переписываться с нуля. Но так ли всё радужно? 

Меня зовут Андрей, я программист в студии IT Territory/My.Games, работаю в команде экспериментальных проектов. И хочу рассказать вам об особенностях нашего прототипирования игр. 

В предыдущей статье "Несколько примеров успешного изобретения велосипеда" мы поделились рядом решений, полученных путем комбинирования наших плагинов для Atlassian, таких как MyGroovy, JSIncluder и MyCalendar. На этот раз мы рассмотрим еще один плагин из нашей коллекции — Custom Select List.

Меня зовут Дмитрий, я специалист по тестированию в студии IT Territory. За 17 лет мы выпустили более 15 успешных игровых проектов с общей аудиторией около 100 млн игроков по всему миру. Вы можете быть знакомы с нами по таким проектам, как Аллоды Онлайн, Hawk, Space Justice, World Above, Rush Royale. И в этом посте я расскажу о том, как мы проводим нагрузочное тестирование игровых серверов.

Добрый день, коллеги! Доказывать, что нужно использовать систему контроля версий, уже давно не нужно. И Git занял тут лидирующую позицию, стремительно вытеснив SVN. Но это инструмент, а инструментом нужно уметь пользоваться, чтобы добиться лучших результатов. Как топором, один человек сможет просто срубить дерево а другой из этого дерева сможет сделать великолепную скульптуру. Так и с помощью Git, один человек сможет просто не потерять результаты своего труда за день, а другие смогут организовать совместную работу над проектом нескольких сотен человек. Да так, что о любой строчке кода можно будет и через пять лет сказать, откуда она взялась и для чего нужна.

Постараюсь рассказать для начинающих и не очень разработчиков, как оформлять свои коммиты, чтобы их максимально быстро и без претензий принимали в любые проекты, как опенсорсные так и коммерческие.

Два года назад мы уже рассказывали вам, что такое Cartridge и как с его помощью разрабатывать распределенные приложения. Это полноценный фреймворк, в который входит CLI-интерфейс, который сильно упрощает разработку и эксплуатацию приложений на Tarantool Cartridge.

Я расскажу вам, как можно использовать Cartridge CLI для эффективного использования ваших локальных приложений, и об интересных фичах самого CLI. Статья больше ориентирована на тех, кто уже использует Cartridge или хочет начать им пользоваться. Поехали!

Flying Ships Harbour by annewipf

Отсутствие встроенного инструмента наблюдаемости — один из наиболее серьезных недостатков Kubernetes. Команда Kubernetes aaS Mail.ru Cloud Solutions перевела статью о четырех инструментах с открытым исходным кодом, которые подойдут для мониторинга событий.

Kubernetes — платформа с открытым исходным кодом, с ее помощью удобно управлять процессами контейнеризации и автоматизации. Но есть оборотная сторона медали: хотя в Kubernetes встречаются разные проблемы, одна из самых распространенных — наблюдаемость.

События Kubernetes показывают, что происходит в кластере при изменении состояния или ошибках, вызванных другими ресурсами системы. Благодаря событиям вы поймете, почему система не может вытянуть Docker-образ или почему некоторые поды были выселены из кластера. События — это тип ресурса, который автоматически создается всеми основными компонентами и расширениями в кластере через API-сервер.

Системы аутентификации есть везде. Пока вы скучаете в лифте по пути с седьмого этажа на первый, можно успеть проверить баланс в приложении банка, поставить пару лайков в Instagram, а потом проверить почту. Это минимум три системы аутентификации.

Меня зовут Александр, я программист в отделе архитектуры и пресейла в Mail.ru Group. Я расскажу, как построить систему аутентификации на основе Tarantool и Java. Нам в пресейле очень часто приходится делать именно такие системы. Способов аутентификации очень много: по паролю, биометрическим данным, SMS и т.п. Для наглядности я покажу, как сделать аутентификацию по паролю.

Статья будет полезна тем, кто хочет разобраться в устройстве систем аутентификации. На доступном примере я покажу все основные части архитектуры, как они связаны между собой и как работают в целом.

Concept Art: Airship Acres by ExitMothership

Недавно мы рассказывали, что Kubernetes в формате self-hosted — не всегда самая лучшая идея. Альтернатива — Managed-решения типа Kubernetes as a Service (KaaS), которые помогают запускать контейнерные рабочие нагрузки без необходимости погружаться во все тонкости управления кластером и беспокоиться об обновлениях и патчах K8s.

Но вот сам переход на Managed Kubernetes неизбежно ставит клиентов перед вопросом: как организовать переход с текущего технологического стека правильно, с наименьшими затратами и влиянием на пользователей?

Я Павел Селиванов, ведущий DevOps-инженер платформы Mail.ru Cloud Solutions, которая как раз-таки является провайдером Managed Kubernetes :)

В статье расскажу:

• какие стратегии миграции на Managed Kubernetes существуют,
• от чего зависит сложность и длительность миграции,
• из каких этапов она состоит,
• какие проблемы могут возникнуть в ходе миграции и как с ними справиться.

Database by Julian-Faylona

Многие облачные платформы предлагают базы данных как сервис (Database as a Service, DBaaS). Базу можно создать в облаке в несколько кликов, не тратя время на настройку и поддержку. Но не всем приложениям облачные базы данных подходят.

Мы расскажем, как на старте проекта не ошибиться с выбором облачной СУБД. Эта статья — вольная переработка нашего вебинара (видео тут).

Мы разберем, когда стоит и не стоит использовать DBaaS, какие особенности нужно учесть при работе с ними и как выбрать подходящую базу данных с учетом особенностей ИТ-инфраструктуры, объема и специфики задач. В конце посмотрим, как устроено создание базы данных в облаке и какие операции с ней доступны, на примере DBaaS Mail.ru Cloud Solutions.

Известный профессор МТИ Гарольд Абельсон сказал: «Программы нужно писать для того, чтобы их читали люди, и лишь случайно — чтобы их исполняли машины». Хотя он намеренно преуменьшил важность исполнения кода, однако подчёркивает, что у программ две важные аудитории. Компиляторы и интерпретаторы игнорируют комментарии и с одинаковой лёгкостью воспринимают все синтаксически корректные программы. У людей всё иначе. Одни программы нам воспринимать легче, чем другие, и мы ищем комментарии, которые помогут нам разобраться.

Есть множество источников информации, помогающих программистам писать более качественный код — книги, сайты, статические анализаторы. Но гораздо меньше источников посвящено повышению качества комментариев. Легко измерить их количество в программе, но качество оценить сложно, и два этих параметра не обязательно взаимосвязаны. Плохой комментарий хуже отсутствия комментария. Вот несколько правил, которые помогут вам найти золотую середину.

Источник

Команда Kubernetes as a Service в Mail.ru Cloud Solutions перевела статью, в которой автор помогает найти причины ошибок в Kubernetes, если вы совсем не понимаете, куда нужно смотреть. Далее текст от лица автора.

Kubernetes — непростая платформа, особенно когда что-то пошло не так и нужно срочно найти и устранить возникшую проблему. В основном трудности объясняются сложностью самой системы и отсутствием подробных сообщений об ошибках. Ситуация усугубляется еще и огромным количеством «шестеренок» в потоке оркестрации контейнеров — при том что для представления этого потока используется всего лишь несколько состояний. Например, есть как минимум шесть возможных причин, по которым под может зависнуть в состоянии ContainerCreating или CrashLoppBackOff.

Мы активно работаем с Kubernetes уже более трех лет и за это время составили длинный список сложных и в то же время трудно диагностируемых проблем. Большинство из них можно отнести к одной из трех категорий:

1. Зависание пода в состоянии ContainerCreating.
2. Ошибка CrashLoopBackOff и периодический перезапуск контейнера.
3. Проблемы с сетью.

У Kubernetes высокий порог входа, не все готовы использовать его в своих проектах. Это достаточно сложная для внедрения технология, особенно если конфигурированием кластера заниматься самостоятельно. Но я попробую упростить для вас эту задачу.

Я Павел Селиванов, ведущий DevOps-инженер облачной платформы Mail.ru Cloud Solutions. Я расскажу про альтернативный способ развертывания Kubernetes — использование Managed-варианта от облачного провайдера. Мы запустим реальный API-сервис на примере нашего облака и пройдем основные шаги развертывания приложений в K8s, включая подготовку инфраструктуры, настройку CI/CD-конвейера и всех необходимых объектов Kubernetes: Deployment, Service, Ingress и так далее.

В результате попробуем убедиться, что 60 минут — вполне достаточное время для освоения азов работы с K8s при условии использования его в виде aaS.

Пытливый читатель при желании может повторить все мои действия с помощью бонусных рублей, которые выдаются на тестирование новым пользователям при регистрации.

Практикум в видеоформате можно посмотреть по ссылке.

Source

Планировщик распределенных ресурсов (Distributed Resource Scheduler, DRS) — необходимый компонент любой виртуализированной среды, за исключением редких случаев с небольшой и ненагруженной инфраструктурой. Основная цель DRS — выровнять нагрузку на хостах, находящихся внутри вычислительного кластера, таким образом, чтобы виртуальные машины (ВМ) и развернутые на них приложения всегда получали ресурсы в нужном объеме и работали с максимальной эффективностью, а количество задействованных физических серверов при этом оставалось минимальным.

В облаке Mail.ru Cloud Solutions используется собственная реализация механизма DRS. Я Артем Карамышев, руководитель команды системного администрирования, расскажу о базовых принципах, на которых строится работа DRS у нас в облаке.

Источник

Arenadata DB — мощная распределенная аналитическая база данных для высоконагруженных проектов. Эта СУБД может в короткие сроки обслуживать огромное количество аналитических запросов к данным, но такой режим работы делает ее требовательной к производительности дисков: она должна быть высокой, чтобы обеспечить быстрый отклик системы. Из-за этого Arenadata DB не так просто развернуть в облаке: «под капотом»‎ должны быть быстрые диски и возможность выбора их типа с учетом нагрузки проекта — для достижения нужной скорости работы.

Обычно облака не гарантируют скорости отклика, подходящей для работы со сверхнагруженными системами. Но на платформе Mail.ru Cloud Solutions запущена полностью управляемая Arenadata DB Cloud и есть быстрые диски для ее работы High IOPS SSD. Их производительности вполне достаточно для большинства приложений. А для систем с особо высокими нагрузками, где критически важно минимизировать время отклика до десятых долей миллисекунды, теперь можно подключить и сверхбыстрые диски Low Latency NVMe — они предназначены для задач, где скорость отклика выходит на первый план.

Меня зовут Дмитрий Яценко, я являюсь преподавателем-исследователем в Южном федеральном университете, тренером по продуктам в Arenadata, а также по совместительству разработчиком и системным интегратором в других организациях. В этой статье я покажу результаты тестирования Arenadata DB c Low Latency NVMe, которые помогли улучшить производительность СУБД при по-настоящему высоких нагрузках.

Почти все любят Git. Я тоже. Он работает, он эффективен, в нём изумительная модель данных, и в нём есть все возможные инструменты. За 13 лет использования не было случая, чтобы я не находил в Git нужный мне инструмент. До недавнего времени. Но сначала давайте поговорим о GitHub.

Space Station by Kaioshen

Современный ритейл уже не может обходиться без построения прогнозных и рекомендательных систем на основе Big Data. Но при больших объемах данных, таких как у «Ашана», работа с большими данными на локальных мощностях неэффективна: это дорого, сложно в эксплуатации и может привести к гонке за ресурсы между подразделениями.

Поэтому некоторые компании приходят к облачной Big Data-платформе как к инструменту, который дает простую масштабируемость и управляемость для систем, работающих с Big Data. Переход на такую платформу не будет простым: недостаточно перенести рабочие системы в облако как они есть. Потребуется глобальная перестройка — причем не только в плане архитектуры и технологий, но и на уровне корпоративной культуры. Пользователям отчетов придется учить SQL, а разработке, тестированию и эксплуатации — дружить под флагом DevOps.

Я — Александр Дорофеев, ex Head of Big Data в компании «Ашан Ритейл Россия», в статье расскажу:

• почему для наших задач самым подходящим решением оказалась специализированная единая Big Data-платформа и какую целевую архитектуру мы выбрали;
• почему ее понадобилось делать на базе публичного облака и почему мы для этого выбрали облачную платформу Mail.ru Cloud Solutions;
• как происходил переезд в облако, с какими трудностями мы столкнулись и каких результатов удалось достичь.

Любая технология, ставшая популярной, чему-то этим обязана. Одной из причин популярности голосовых помощников стали так называемые игровые навыки — умение играть с пользователями. Давайте поговорим о современном состоянии этой отрасли, чем интересны голосовые навыки и как они могут развиваться в ближайшем будущем.