Назад к кейсам

Playkey: как мы сэкономили 10% на хранении логов и автоматизировали поиск проблем

Компания
Playkey
Отрасль
SaaS
Количество пользователей
> 1 500 000
Алексей Лыков
технический директор Playkey

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

Как в Playkey нашли самое выгодное решение для хранения логов и как это повысило качество работы сервиса, расскажет Алексей Лыков, технический директор Playkey.

Playkey — облачный сервис для запуска игр

Playkey — облачный сервис, который позволяет запустить компьютерную игру, выбранную пользователем, в хорошем качестве на любом компьютере за счет переноса нагрузки с пользовательского ПК в облако. Нашим сервисом пользуется уже более 1 500 000 пользователей из 178 городов, в каталоге более 250 топовых игр.

Проблемы с логами и почему мы пришли в облака

Облака позволяют сфокусироваться на разработке продуктовых идей, а не на инфраструктуре. Это помогает любому стартапу двигаться быстрее и при этом гибко подходить к использованию ресурсов. Изначально сервис работал на выделенных (Dedicated) серверах, но мы решили перейти в облака, так как это удобнее и выгоднее.

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

  1. Логи клиентских и серверных приложений — это большое количество неструктурированных данных, с ростом нагрузки их объем увеличивается, а локальное хранение ограничивает возможности масштабирования.
  2. Сотрудники тратили много времени на работу с логами, поиск проблем вручную на разных серверах, также было сложно анализировать проблемы.
  3. Чтобы посмотреть логи, сотрудникам нужен был доступ к боевым серверам, а это небезопасно даже с точки зрения возможной человеческой ошибки.

Наконец, отсутствие централизации в принципе препятствует организации автоматизированной обработки логов. Так что главным толчком к переходу в облако стало наше стремление централизовать хранение логов. Это должно было упростить доступ для сотрудников, масштабирование и управление. Для централизованного хранения логов мы выбрали софт ELK, который мы собрались разместить на облачных виртуальных серверах.

Второй сервис, на который мы рассчитывали — управляемые облачные базы данных (DBaaS) для тестовых сред. Использование СУБД в в виде сервиса должно было снять с нас задачи администрирования баз данных, поскольку эта задача полностью уходит провайдеру.

Почему выбрали MCS и какие сервисы используем

Мы рассматривали два облачных решения: Mail.ru Cloud Solutions и Microsoft Azure. MCS по стоимости оказалось выгоднее, при том что дал нам нужный уровень надежности.

Понравилась техподдержка Mail.ru Cloud Solutions. Общение по текущим вопросам происходит в реальном времени: есть чат со специалистами, они оперативно отвечают, подробно консультируют по использованию решения. У других провайдеров с этим проблемы: общение идет через письма, которые регистрируются в тикетной системе, а переписка имеет тенденцию затягиваться. Причём на англоязычные платформы нужно отправлять сообщения на английском языке, а не всякий сисадмин может сформулировать вопрос так, чтобы его точно поняли «с той стороны».

Сейчас мы используем такие сервисы MCS:

  1. Cloud Servers — облачные серверы используем для развертывания ELK для централизованного хранения логов. У нас несколько виртуальных машин под Elastic Cluster, плюс виртуальные машины для Kibana и Logstash.
  2. PostgreSQL в облаке. Облачные базы данных используем для тестирования новых проектов.

Никаких проблем с сервисами в процессе эксплуатации нет.

Как мы переходили на облако

PostgreSQL мы мигрировали из нашей локальной СУБД в DBaaS на MCS. Без каких-либо проблем.

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

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

В облаке MCS мы получили надежность, удобное масштабирование и экономию на ресурсах

После перехода на ELK в облаке мы эффективно решаем задачу централизованного логирования. Мы можем не думать о масштабировании при росте нашего проекта: в пандемию вырос спрос на сервис, объем логов сильно увеличился, но благодаря облакам удалось нарастить мощности в сжатые сроки. Мы мониторим нагрузку и расширяемся по мере ее увеличения — это рутинное действие, сисадмин просто добавляет ресурсы через панель управления, буквально в один клик. Такая гибкость облака очень удобна. Причем если мы захотим выйти на новый уровень и автоматизировать масштабирование, в перспективе для нас доступны средства автомасштабирования контейнеров под управлением Kubernetes в этом же облаке.

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

Отдельный плюс — экономия. Во-первых, мы экономим на обслуживании баз данных, так как не нужно привлекать системного администратора к работе с ними. Во-вторых, стоимость решения по хранению логов в облаке MCS на 10% ниже, чем у аналогов — по итогам экспертной оценки затрат на инфраструктуру и работу сисадминов.

В итоге мы существенно улучшили качество работы нашего сервиса в продуктиве.

Планы на будущее

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

Основные результаты сотрудничества с MCS

  1. Существенное улучшение работы сервиса в продуктиве.
  2. Экономия 10% на хранении логов.
  3. Масштабирование проекта в короткие сроки, что особенно помогло в пандемию.
  4. Автоматизация поиска проблем — это сняло рутину с тестировщиков и повысило безопасность.
  5. Возможность не обслуживать базы данных и не привлекать для этого отдельного администратора.

Зарегистрируйтесь и попробуйте сервисы бесплатно

Если бонусов для тестирования не хватит - 

оставьте заявку, мы начислим еще или предложим полноценный пилот.
21 год
опыта поддержки высоконагруженных сервисов
100+ млн
пользователей по всему миру
7 лет
экспертизы развития облачной инфраструктуры