СТО компании Никита Обухов и директор по маркетингу Ирина Фёдорова рассказали об инциденте, который стал одним из аргументов всерьёз задуматься об инфраструктурных переменах, переезде на K8s и найме команды DevOps.
Что внутри:
- потеря контроля над Facebook,
- внезапный наплыв трафика в пятницу вечером,
- грант от Microsoft Azure, переезд между облаками и сложности трансформации.
Поехали!
Geecko
— DevRel компания. Помогает выстраивать взаимоотношения IT-компаний с разработчиками, но делает это необычными способами: создаёт игры с задачами для программистов, кодинг баттлы, организует митапы и другие онлайн-форматы.
Что под капотом у игр Geecko
На каком движке сделаны игры, что они из себя представляют технически?
Никита: Наши игры исключительно браузерные. Мы используем собственные наработки и проверенные библиотеки для работы с Canvas, картами, изометрией. Используем JS/TS, фреймворк Vue.js для типичного web UI.
Под мобильные платформы мы пока не пишем — в лучшем случае поддерживаем мобильное разрешения. Но это нужно нечасто — в большинстве наших игр требуется писать код, а писать код с мобилы — такое себе удобство.
Насколько игры требовательны к CPU и памяти?
Никита: В наших играх требуется писать код, и нам этот код надо исполнять.
Мы поддерживаем 12 языков: и компилируемые, и интерпретируемые в разных средах. Код исполняем на наших серверных ресурсах: нагрузка на процессор и память интенсивная.
Также мы запускаем LSP-сервисы, которые обеспечивают autocomplete кода для нашей онлайн IDE. Они тоже требуют CPU и особенно памяти: когда игроков много, нагрузка значительно растёт.
Где хостятся игры?
Никита: Это всегда были облака. Сейчас основной провайдер — Azure (Geecko получила грант от Microsoft на бесплатное использование облака — ред.). Все новые проекты мы запускаем там — и, что для нас важно, запускаем в Kubernetes. Вся новая инфраструктура — на основе Kubernetes и Docker.
У какого провайдера вы были до и почему решили перейти?
Никита: Мы были и до сих пор представлены и в DigitalOcean, и в Yandex.Cloud. Это хорошие провайдеры, но наиболее подходящая программа гранта для нас оказалась у Microsoft.
Сколько вы тратили на серверы раньше и тратить теперь?
Никита: Ещё полгода назад мы тратили около 30 тысяч рублей в месяц, сейчас эта цифра подбирается к 100 тысячам. Рост связан с количеством проектов: старые мы не останавливаем, они продолжают работать и получать органические регистрации. Регулярно запускаем новые активности: в один месяц можем зарелизить три проекта — например, один баттл, одну игру и митап.
Грант от Microsoft покрывает все расходы?
Никита: Наши расходы на инфраструктуру не стали нулевыми: мы не можем перевезти всё за раз, это и экономически нецелесообразно. Поэтому у нас продолжает работать еще два облачных провайдера, просто их доля сокращается.
Бэкапы в других географических зонах, аварийное восстановление ресурсов в другом облаке — всё это важно.
В целом общие затраты сокращаются. Самое большое потребление ресурсов у сервиса исполнения кода, а благодаря гранту затраты на него в ближайший год будут нулевыми. При выполнение ряда условий грант продлят на второй год.
Пятничный наплыв трафика из Facebook
У вас были ситуации, когда наплыв пользователей ронял продакшн?
Никита: Да, однажды случился близкий к этому инцидент. У нас была задача от международной компании: найти много англоязычных разработчиков.
По замыслу игроки должны коллективно выполнить миссию, находясь на одной карте. Карта имеет конечные размеры, так что расположить на ней всех желающих нельзя. Мы делили пользователей на кластеры по 100 человек, каждый из которых живёт не больше пяти дней — таков игровой цикл выполнения миссии. За это время участники либо выигрывают, либо проигрывают.
Мы рассчитывали, что одновременно будут активны до 10 таких карт, то есть до 1000 игроков. Но по факту на пике было больше 2000 игроков или 20 карт.
Почему так произошло? Почему в игру внезапно пришло столько пользователей?
Ирина: История случилась в начале марта, когда Facebook стал массово и стихийно блокировать рекламные кабинеты за несоответствие политике для рекламодателей. Очень многие компании тогда лишились рекламных кабинетов, в том числе и мы: у нас упали и основной, и оба резервных кабинета. И всё это как раз в тот момент, когда нам надо было продвигать игру.
Facebook — один из основных каналов продвижения, потому что там достаточно легко подбирать аудиторию и сегментировать её с учетом имеющихся данных. И на целых 12 дней мы лишились доступа к этому каналу. Когда же мы потом, кровью и слезами его вернули, нам нужно было догнать KPI — 4500 ликвидных регистраций по определённым геолокациям, в основном в Европе.
Не было никакого выбора, кроме как поднажать с бюджетом: мы подразогнали рекламные кампании.
Что значит «поднажать с бюджетом»?
Ирина: Если мы изначально тратили 300–500 долларов в день, то тут перешли за 1000.
Надо понимать, что обычно рекламные кампании несколько дней обучаются, а потом начинают работать максимально профитно. Но у нас рекламный бюджет был больше обычного, поэтому кампания обучилась быстрее и уже на второй день начала откручивать действительно очень крутые показатели. В какой-то момент мы потеряли над ней контроль.
Мы рассчитывали на определённый коэффициент конверсии, а он оказался больше просто за счёт того, что Facebook разогнался. Если в среднем у нас конверсия в таких играх около 8%, то здесь в пиковый момент она дошла до 15%.
Круто!
Ирина: Да, тут-то мы и поняли, что значит большой рекламный бюджет. Правда, работает это только в случае с Западом — в России просто нет аудитории, чтобы потратить столько денег.
Ну и, конечно же, всё это произошло в пятницу. Классика! В пятницу вечером мне приходит сообщение от Никиты, что у нас такой большой трафик, что нужно что-то с этим сделать.
Откуда Никита об этом узнал? Откуда пришел этот сигнал?
Никита: У нас есть автоматические оповещения о загрузке серверов. Вот как оно выглядело:
Приходит алерт, что виртуальная машина (8 ядер, 32 ГБ памяти) загружена на 90% по CPU при пороговом значении 50%.
Это не критично, так как сервис продолжает работу. Для игроков это значит, что они нажимают кнопку «Запустить код» и ждут выполнения раза в два дольше. Но также это значит, что если новые игроки продолжат приходить, ситуация ухудшится, вплоть до даунтайма.
В итоге самого плохого исхода удалось избежать — сервис не лёг окончательно?
Никита: К счастью, все закончилось хорошо.
Конечно, если бы ситуация возникла в середине рабочего дня, мы бы вообще не переживали — там можно оперативно реагировать. Но не в пятницу вечером. В пятницу вечером ты отправляешься в бар и получаешь такое сообщение на телефон. Но чтобы всё починить, на телефоне быть недостаточно.
Как вы разрулили ситуацию?
Ирина: Мы просто снизили расход рекламных кампаний почти на 70%.
Позже вы вернули обороты?
Ирина: Нет, до того же состояния не стали доводить, потому что ситуация была непредсказуемая: Facebook с каждым днём наращивал и наращивал конверсию. Если бы мы крутили на тех же оборотах ещё неделю, возможно, конверсия была бы ещё выше. Но героических побед не требовалось, поэтому мы восстановили комфортный уровень. Получалось где-то 10 загруженных карт, и при этом сервис работал спокойно.
Никита: Надо отметить, что есть и другие стороны вопроса: мы стараемся оперативно реагировать на сообщения игроков. Чем больше игроков, тем больше запросов в поддержку они генерируют. Мы хотели сохранить высокий уровень сервиса, и так спешно нарастить объёмы поддержки были не готовы. Решили, что разумнее делать всё более плавно и прогнозируемо, чем выходить на пик в выходные.
В этот раз вы решили придушить рекламную кампанию и тем самым спасли ситуацию. А как вы обычно решаете задачу с масштабированием с технической точки зрения?
Никита: Мы масштабируемся через запуск дополнительных инстансов сервиса.
В данном случае это не Kubernetes и нет автоскейла. Надо в полуручном режиме запустить клон виртуальной машины — приходится подождать до получаса, пока ВМ воссоздастся из образа. После этого надо проверить, что ВМ работает как ожидается и все сервисы на ней поднялись: LSP-серверы, код-раннеры. После этого балансируем трафик на новые машины и продолжаем наблюдать за загруженностью и статус-кодами.
Выводы и планы
Как вы перестроили работу после этого случая?
Никита: Поняли, как лучше планировать маркетинг: какой объем вложений какой объем регистраций даёт.
На техническом уровне укрепились во мнении, что нам нужен новый способ масштабирования сервиса исполнения кода, в идеале — автоскейл.
Сервис исполнения кода делаем stateless (независимым от системы хранения), вносим небольшие архитектурные изменения и меняем инфраструктуру — внедряем тот самый Kubernetes, на котором работают другие сервисы.
Но в случае с сервисом исполнения кода схема более сложная — перевести его не так просто, как остальные. Мы пока проверяем, что всё работает как надо.
Прямо сейчас код выполняется в DigitalOcean, а будет выполняться в облаке Azure. В Kubernetes.
Там вы используете Kubernetes как сервис (Azure Kubernetes Service)?
Никита: Да. Мы используем Kubernetes как сервис и ещё рассматриваем вариант Cloud Functions.
Как AWS Lambda?
Никита: Да, у всех основных провайдеров они есть. Они позволяют платить ровно столько, сколько ты делаешь запусков кода. Но есть технические ограничения в возможностях сред выполнения.
Кто сейчас занимается инфраструктурой?
Никита: Моей квалификации и квалификации бэкенд-разработчиков не всегда хватает, потому что DevOps, SRE — это очень широкая область. Да и оставлять на дежурство по инцидентам бэкенд-разработчиков не очень правильно. Поэтому в начале года у нас появилась аутсорс-команда DevOps — ребята, с которыми мы раньше работали в других бизнесах.
Почему вы начали сотрудничать с командой, которая занимается инфраструктурой и DevOps?
Никита: Инцидент с игрой стал катализатором изменений, которые мы давно осознавали, но не имели возможности воплотить.
Компания выросла, стали происходить подобные случаи, которые подтверждали: да, ребята, вам нужны DevOps-инженеры, вам нужно сделать такую инфраструктуру, которую будет проще масштабировать.
Полноценно задачей занялись два месяца назад, когда получили грант от Azure. К настоящему моменту много сервисов перевезли в новое облако.
Почему решили брать людей на аутсорс, а не нанимать?
Никита: По собственному опыту знаем, что DevOps — сложное направление для найма. А тут сложилось так, что есть проверенные ребята, и форма работы с подрядчиком для нас весьма удобна.
Ну и главное: мы приобрели не одного инженера, а целую команду, которая круглосуточно мониторит доступность сервисов и готова прореагировать на инцидент до того, как он будет обнаружен пользователями.
Команда DevOps настраивают всё с нуля или используют то, что было, включая мониторинг?
Никита: Мы пошли по пути вытеснения. Новые проекты начинаем в новой инфраструктуре, core-сервисы мигрируем туда же, а проекты в стадии поддержки оставляем в старой. Для новых проектов все новое, включая мониторинг.
Особенность трансформации заключается в том, что приходится переосмысливать архитектуру сервиса. Мы поняли, как ее можно изменить, чтобы получить новые качества.
Поэтому работа происходит и на стороне бэкенда: мы рефакторим код, обновляем архитектуру, но в достаточно умеренном объеме.
Получается, вы сейчас настраиваете новые процессы CI/CD?
В первую очередь мы перестраиваемся организационно. У нас появилась новая роль, соответствующая выделенной команде, и способы коммуникации, постановки задач изменились.
Процессы CI/CD у нас были, просто они стали перекатываться на новую инфраструктуру. Конечно, они совершенствуются, но принципиально не меняются.
Какой глобальный вывод вы для себя сделали?
На разных этапах жизни проекта хорошо разное. Полгода назад к DevOps-команде мы были бы и сами не готовы. Зато сейчас можем общаться с ними гораздо предметнее. Мы чётко понимаем свои боли и пришли к ребятам со списком вопросов и предложений, как что-то сделать. Получилась хорошая коллаборация: совместно мы пришли к качественным и обоснованным решениям.
Впереди много работы. Сервис исполнения кода в процессе миграции, и как самый сложный из наших сервисов, потребует много участия. Какое-то время мы будем иметь обе версии сервиса в продакшене и балансировать трафик между ними. Когда поймём, что всё отлично, полностью переключимся на Azure.
Так повелось, что в большинстве компаний задумываются над инфраструктурными вопросами уже после разработки продукта. Можно считать этот подход единственно верным, а можно поступить иначе.
Например, ещё на этапе разработки отправить ребят из бэкенда посмотреть на то, какие метрики стоит навесить и как спланировать пайплайн, чтобы в продакшене было не так больно.
12 ноября в «Слёрме» стартует интенсив как раз для тех, кто планирует или уже поддерживает высоконагруженные системы.
В программе:
— мониторинг,
— управление инцидентами,
— решение проблем с окружением,
— решение проблем с инфраструктурой,
— канареечные релизы и управление трафиком.
Интенсив подготовили и проведут опытные инженеры из Booking, Databricks, Mail.ru Cloud Solutions и TangoMe.
Узнать больше и записаться
