От переводчика: перед вами третий материал из цикла статей о технологической трансформации Mercado Libre.
Во второй части мы рассказали, как внутренняя платформа для разработчиков смогла справиться с ростом нагрузки и усложнением систем благодаря переходу на Kubernetes в качестве базового движка. Мы также показали, как Fury избавляет разработчиков (DevEx) от рутины управления инфраструктурой и позволяет целиком сфокусироваться на инновациях и создании ценности.
Эта часть посвящена углублённому анализу технических и стратегических аспектов, лежащих в основе нашего решения о переходе на Kubernetes. Мы проанализируем рассмотренные альтернативы, сложности, возникшие в процессе внедрения, а также то, как принятые решения продолжают поддерживать нашу мультиоблачную стратегию и операционную устойчивость. Процесс оценки продолжался около шести месяцев. Он завершился созданием многочисленных RFC (запросов на комментарии) и детализированных отчётов, содержащих метрики, которыми мы руководствовались при принятии решений.
Контекст
С ростом Mercado Libre всё весомее стали проявляться ограничения Standard — первой вычислительной модели нашей платформы Fury. Эта модель, построенная на отдельных инстансах, выступала связующим звеном между платформой и облачными провайдерами. Мы столкнулись с двумя серьёзными проблемами: низкой эффективностью из-за того, что на одну реплику приложения приходился один вычислительный инстанс, и недостаточным использованием встроенных возможностей облачных платформ.
Стало очевидно, что для оптимизации ресурсов и сокращения расходов нужно что-то помощнее. Так мы и пришли к Kubernetes.
Оцениваем альтернативы
В поисках наилучшего решения для инфраструктуры мы внимательно изучили несколько альтернатив:
Сначала рассмотрели рабочие нагрузки на основе задач (Job), затем изучили FaaS-варианты. Затем исследовали CaaS-модели и, наконец, добрались до оркестраторов, которые предлагают расширенные возможности по управлению контейнерами. У каждой альтернативы были свои сильные и слабые стороны. В результате мы выбрали Kubernetes как наиболее подходящее решение.
Первая альтернатива: рабочие нагрузки на основе задач
Оценку новых вариантов мы начали с рабочих нагрузок на основе задач (Job). Для этого типа нагрузки, где выполнение запускается по правилам Cron, неэффективность была особенно очевидна: инстансы работали круглосуточно, что приводило к лишним расходам, хотя задача могла запускаться, например, всего раз в неделю.
Решить проблему неэффективного использования ресурсов в инфраструктуре попробовали с помощью AWS Batch. Это управляемый сервис, созданный для масштабного запуска batch-нагрузок. AWS Batch динамически предоставляет вычислительные ресурсы в зависимости от требований задачи, что делает его подходящим для запланированных нагрузок, таких как те, что управляются Cron-задачами. С помощью AWS Batch можно было бы запускать задачи, не держа инстансы постоянно включёнными, тем самым снизив издержки на ресурсы для редко выполняемых задач (например, тех, которые запускаются раз в неделю или раз в месяц).
Увы. AWS Batch отлично подходил для классических batch-задач, но нашим потребностям удовлетворял лишь частично. В частности, он не подходил для рабочих нагрузок, требующих более динамического масштабирования или активации по событиям. Примером может служить BigQueue — наша внутренняя система обмена сообщениями, построенная на облачных сервисах. BigQueue обрабатывает сообщения, потребляемые различными приложениями, которые могут получать эти сообщения непредсказуемо, спорадически. Такой паттерн приводил к периодам простоя, когда потребители сообщений оставались неактивными до поступления новых данных.
Поскольку AWS Batch разработан для задач с предсказуемым временем начала и окончания, он не подходил для непредсказуемой нагрузки, специфичной для потребителей BigQueue, которые имеют дело со всплесками сообщений. В общем, AWS Batch не подошёл. Нам нужно было решение, способное справляться с нестабильным потоком сообщений, делать это с минимальной задержкой и уметь масштабироваться по необходимости.
Вторая альтернатива: FaaS
Следующей категорией, которую мы рассмотрели, была «Функции как услуга» (FaaS), ярким представителем которой является AWS Lambda. Хотя Lambda и предназначена для запуска кода по событиям, у неё есть ограничение на максимальное время выполнения в 15 минут. Из-за этого она не подходит для длительных задач, что было критически важным требованием для некоторых наших рабочих нагрузок. Lambda хорошо справляется с короткими stateless-задачами, запускаемыми по событиям, однако её ограничения по времени выполнения и управлению состоянием заставили нас искать другие варианты.
Кроме того, объединение AWS Lambda с AWS Batch привнесло бы значительную сложность. Каждый сервис оптимизирован под свои сценарии использования: Lambda управляется событиями и не хранит состояние (stateless), в то время как AWS Batch обрабатывает крупномасштабные batch-задачи. Внедрение двух разных систем и управление ими увеличили бы операционную нагрузку, особенно в части мониторинга, логирования и оркестрации воркфлоу. Такое усложнение ясно дало понять: нужно что-то более цельное.
Другой серьёзной проблемой стал бы масштабный рефакторинг кода, который было бы необходимо провести для адаптации существующих приложений под новые решения. С учётом того, что у нас работает более 30 000 микросервисов, это потребовало бы значительных усилий со стороны команд разработки. Так как архитектура была основана на контейнерах, мы решили сфокусироваться на моделях «Контейнер как услуга» (CaaS), чтобы упростить развёртывание и управление.
Третья альтернатива: CaaS
Оценивая CaaS-решения, мы рассмотрели AWS ECS, Google Cloud Run и Cloud Run for Anthos. У каждого были сильные стороны, но ни одно не устроило нас на сто процентов.
Сначала мы посмотрели на AWS ECS (Elastic Container Service) — сервис для развёртывания и масштабирования контейнеризованных приложений. ECS поддерживает контейнеры-сайдкары — они критически важны для нашей архитектуры: мы полагаемся на сайдкары при управлении вспомогательными сервисами вроде логирования и мониторинга. Несмотря на свою мощь, ECS не хватало гибкости, особенно для работы в нескольких облаках, и в нём отсутствовала часть нужных нам фич прямо «из коробки».
Затем настал черёд Google Cloud Run — полностью управляемой serverless-платформы, заточенной под stateless-контейнеры. Cloud Run автоматически масштабирует контейнеры по HTTP-запросам, что идеально для нагрузок, запускаемых по событиям. Однако тогда Cloud Run не поддерживал необходимые нам контейнеры-сайдкары, поэтому от него пришлось отказаться.
Ещё протестировали Cloud Run, интегрированный с Anthos. Эта связка позволяет запускать serverless-нагрузки Cloud Run в гибридных и мультиоблачных средах. Хотя такая интеграция давала гибкость и помогала обойти некоторые ограничения «чистого» Cloud Run, она добавляла сложностей в эксплуатации. Управлять одновременно выполнением контейнеров в Cloud Run и оркестрацией Anthos в разных облаках оказалось затруднительно. Дополнительные сложности и проблемы с интеграцией сделали это решение не самым лучшим для нас.
В итоге ни одно из CaaS-решений не подошло нам на сто процентов, особенно если учесть сложность управления насколько масштабной архитектурой, как наша.
Финальный выбор: оркестраторы
Далее мы присмотрелись к оркестраторам. Оценили Kubernetes (EKS и GKE), Nomad и решения вроде Knative. Последний строится поверх Kubernetes и добавляет фичи для serverless-нагрузок и тех, что запускаются по событиям. От Knative мы отказались довольно быстро: он не вписывался в операционные требования Fury и привносил функциональность, которая шла вразрез с нашей архитектурой. Нам нужен был оркестратор, который без проблем встроился бы в операционную модель Fury и при этом не заставил бы разработчиков переписывать приложения или тратить кучу времени на переделку кода.
Поскольку у нас уже был опыт с Nomad в других проектах, мы разбили команду на две части. Одна стала смотреть, как Kubernetes справляется с рабочими нагрузками Fury, другая — как Nomad. В обоих случаях результаты оказались хорошими. Но более глубокий анализ критических моментов — вроде управления кластерами и того, как предоставляется доступ к сервисам, — показал, что Kubernetes подходит больше. Понятная схема с IP-адресом на каждый под, продвинутое автомасштабирование и активная поддержка сообщества (и плагины для разных облачных провайдеров) — всё это давало ему серьёзное преимущество. С Nomad же управление кластерами оказалось сложнее, в основном потому, что нужны были дополнительные инструменты типа Consul. Кроме того, его не поддерживали облачные платформы, которые мы использовали.
Через несколько месяцев тщательных исследований, включавших POC, разработку RFC и проведение сравнительных анализов, мы остановили свой выбор на управляемых решениях Kubernetes: Elastic Kubernetes Service (EKS) и Google Kubernetes Engine (GKE). Эти платформы наилучшим образом отвечали операционным и техническим потребностям Fury, обеспечивая при этом масштабируемость и простоту интеграции с нашей экосистемой.
Извлечённые уроки
Анализируя пройденный путь, мы выделили несколько ключевых уроков, которые послужат практическими рекомендациями для тех, перед кем стоит похожая задача:
Оценивайте все варианты
Проводите всесторонний анализ различных платформ, принимая во внимание не только технические характеристики, но и соответствие операционным потребностям.Планируйте рефакторинг кода
Предусматривайте необходимость внесения изменений в код и учитывайте их потенциальное влияние на сроки разработки и требуемые ресурсы.Помните об интеграции
Отдавайте предпочтение решениям, которые легко встраиваются в существующую архитектуру. Так вы уменьшите перебои в работе и снизите нагрузку на разработчиков.Проверяйте идеи на практике
Создавайте прототипы (POC) для оценки работоспособности решений с учётом ваших нагрузок и операционных потребностей, прежде чем полностью на них переключиться.Используйте поддержку сообщества
Отдавайте предпочтение технологиям с развитой поддержкой сообщества. Так вы обеспечите себе доступ к ресурсам, плагинам и лучшим практикам, которые упростят процесс внедрения.Не гонитесь за хайпом
Анализируйте решения с точки зрения ваших конкретных нужд, а не модных трендов. То, что хорошо для других, не обязательно подойдет вам.
Учитывая эти уроки, организации смогут эффективнее ориентироваться в сложностях внедрения новых технологий оркестрации вроде Kubernetes и повысить свои шансы на успешную реализацию.
Заключение
Переход на Kubernetes существенно улучшил Fury, расширив возможности и повысив гибкость платформы. Переход на управляемые Kubernetes-решения вроде EKS и GKE решил проблемы операционной неэффективности и обеспечил гладкую интеграцию с существующей контейнерной архитектурой. Платформа стала лучше справляться с потребностями всех 30 000 микросервисов, а разработчики получили масштабируемую, оптимизированную среду, в которой основное внимание уделяется инновациям, а не сложностям эксплуатации.
Отличительной чертой нашего решения является его ориентированность на будущее. Выбрав Kubernetes, мы обеспечили адаптивность Fury к технологиям завтрашнего дня. Наша архитектура спроектирована таким образом, чтобы переход на альтернативный оркестратор или парадигму проходил с минимальными усилиями, что отражает стремление к гибкости и отказоустойчивости в постоянно меняющемся технологическом ландшафте.
Kubernetes улучшил операционные возможности Fury и упрочил её репутацию как платформы, ориентированной на устойчивый рост и инновации. Для компаний, которые планируют развивать свои внутренние платформы, наш опыт служит напоминанием о необходимости находить компромисс между сиюминутными преимуществами и долгосрочной гибкостью.
Хотя мы и говорим, что Kubernetes — наш финальный выбор, Mercado Libre живет в режиме «вечной беты». Мы постоянно ищем что-то новое. Кто знает, может, в будущем мы вернёмся к этой статье и дополним её очередным этапом развития или новым выбором. Что думаете?
Эта статья была написана в сотрудничестве с Маркосом Антонио Соузой Пиньейро (Marcos Antonio Souza Pinheiro) и Марсело Кордейро Де Квадросом (Marcelo Cordeiro De Quadros).
P. S.
Читайте также в нашем блоге: