От ошибок на уровне 13% запросов во время акции Black Friday до полного отсутствия сбоев в работе системы: благодаря контейнеризованному развертыванию мы сэкономили 60% затрат на серверы.

В прошлом году во время праздника Black Friday наша система разрешения адресов просто обрушилась: 13% запросов получили ошибку 429, в службу поддержки поступило более 300 жалоб от продавцов, и трем серверам пришлось работать без остановки в течение 24 часов, чтобы преодолеть пик нагрузки. В то время наш сервис работал на двух оборудованных постоянным образом облачных серверах, а масштабирование происходило вручную путем изменения настроек; к тому моменту, когда появились новые инстансы, пик трафика уже прошел.

Сначала давайте разберемся, что такое контейнеризованное развертывание.

Проще говоря, это о том, что ваш код, зависимости и конфигурационные файлы собираются в один стандартизированный “контейнер” размером от нескольких МБ до нескольких сотен МБ. Независимо от того, на каком сервере программа запускается, среда выполнения всегда будет идентичной. Первоначально размер образа сервиса разрешения адресов, который мы запаковали, составлял…187MBЗагрузка и запуск всего процесса занимают не более 10 секунд.

Три основных преимущества, которые мы действительно получили:

• Автоматическое масштабирование действительно спасло ситуацию: в этом году во время праздника Черной пятницы трафик увеличился в три раза, система автоматически запустила 27 контейнерных экземпляров, а после достижения пика количество контейнеров было сокращено до трех. Весь процесс прошел без вмешательства человека, и уровень ошибок снизился ниже 0,1%.
• Баги, связанные с несоответствием окружающей среды, полностью исчезли: проблемы, которые раньше нормально работали на локальной версии программы, но сразу же вылетали при запуске в сети и составляли 40% от общего числа ошибок, больше не встречаются после переноса программы в контейнер.
• Стоимость обслуживания серверов сокращена вдвое: раньше мы постоянно арендовали 8 высокопроизводительных серверов для обработки пиковых нагрузок, при этом их использование в обычное время составляло всего 15%. Теперь мы платим только за фактическое использование, и в году это позволяет сэкономить 60% на расходах на серверы.

Не смотрите только на преимущества, мы уже неоднократно сталкивались с этими проблемами.

Когда мы только начали использовать контейнеры, чтобы сэкономить время, мы хранили все логи и временные файлы прямо внутри контейнера. В результате однажды инстанция автоматически была уничтожена, и все логи запросов за последние 3 дня пропали. Восстановление данных заняло целых два дня. Еще один раз в образ контейнера было добавлено слишком много ненужных зависимостей, из-за чего время запуска увеличилось с 10 секунд до 2 минут. Когда внезапно возник большой объем трафика, мы не успели расширить ресурсы контейнера, и чуть не произошел сбой.

Наиболее легко игнорировать проблемы с правами доступа: изначально мы предоставили контейнерам права root, после чего майнеры воспользовались этим уязвимостью и заняли 30% ресурсов процессора. Только спустя неделю мы заметили это через систему мониторинга.

Сначала хорошо подумайте, действительно ли вам стоит это делать.

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

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

Три конкретных совета для тех, кто впервые берется за это дело

• Не начинайте сразу с кластеров Kubernetes (K8S) – сначала опробуйте развертывание на одном узле с использованием Docker Compose. Поняв, как происходит упаковка, запуск приложений и монтирование логов, вы сможете эффективно работать с этими процессами. Мы сами прошли через этот этап в первые три месяца работы, и это оказалось более чем достаточно.
• При первом создании образа соблюдался принцип “минимизма”: включались только необходимые для работы зависимости. Использование базового образа Alpine позволило сократить его размер более чем вдвое.
• Все генерируемые данные и логи должны быть сохранены на внешнем диске или томе хранения, ни в коем случае не внутри самого контейнера. Это правило должно стоять в самом начале операционных инструкций вашей команды.

Ответы на распространенные вопросы

Вопрос: В нашей команде никто не разбирается в контейнерах, не будет ли слишком высокой стоимость обучения?
Ответ: Для основного использования достаточно двух дней, чтобы ознакомиться с официальной документацией по началу работы, и тогда вы сможете запустить первый сервис. Более сложные настройки кластера можно изучить позже, когда они вам понадобятся.

Вопрос: Будет ли сложно перенести существующие сервисы в контейнеры?
Ответ: На перенос всех трех наших бэкенд-сервисов у нас ушел один недельный период времени; большая часть этого времени была потрачена на разбор зависимостей между компонентами системы. На сам процесс написания Dockerfile ушло менее одного дня.