Yahoo находится в самом разгаре многолетнего процесса миграции своего знаменитого приложения Yahoo Mail в Google Cloud. В приложении задействовано более 100 сервисов и компонентов промежуточного ПО, поэтому Yahoo Mail в первую очередь использует подход «переноса и переноса» для своей локальной инфраструктуры, стратегически трансформируя и перенастраивая ключевые компоненты и промежуточное ПО для использования возможностей облачной инфраструктуры.
Чтобы обеспечить успешную миграцию, команды Google и Yahoo Mail активно сотрудничали, собирая информацию о текущей архитектуре и принимая решения относительно границ проекта, сетевой архитектуры и настройки кластеров Google Kubernetes Engine (GKE). Эти решения были критически важны ввиду глобального характера приложения, которое должно быть высокодоступным и избыточным для обеспечения бесперебойной работы пользователей по всему миру.
По мере того, как Yahoo Mail продвигается к миграции
первой волны рабочих нагрузок в производственную среду, мы выделяем ключевые элементы архитектуры, в частности, многопользовательскую платформу GKE, которая сыграла ключевую роль в создании прочной основы для миграции. Благодаря многопользовательской поддержке приложение Yahoo Mail может эффективно работать в Google Cloud, помогая удовлетворять разнообразные требования различных арендаторов приложений.
Процесс проектирования
Организация Google по предоставлению профессиональных услуг (PSO) начала процесс проектирования с детального анализа текущего использования системы и требований к емкости. Это включало проведение бенчмарков, сбор исходных данных о существующих рабочих нагрузках и оценку необходимого количества узлов на основе типов машин, которые наилучшим образом соответствовали бы требованиям к производительности и ресурсам для этих рабочих нагрузок. Одновременно мы обсуждали оптимальное количество кластеров GKE и их типы, а также наилучшее размещение и организацию рабочих нагрузок в кластерах. Другим аспектом процесса проектирования было определение количества сред (помимо производственной среды). Мы стремились найти баланс между сложностью эксплуатации, ростом зависимости от локальных сервисов при развёртывании и снижением потенциальных рисков, связанных с дефектами и ошибками приложений.
Но прежде чем принимать решения о кластерах GKE, нам необходимо было определить количество проектов и VPC. На эти решения влияли различные факторы, включая требования заказчика к рабочей нагрузке и масштабируемости, а также ограничения сервисов и квот Google Cloud. В то же время мы хотели минимизировать эксплуатационные расходы. Анализ количества кластеров GKE, VPC и т.д. был довольно простым: достаточно было задокументировать плюсы и минусы каждого подхода. Тем не менее, мы тщательно следовали обширному процессу, учитывая значительное и далеко идущее влияние этих решений на общую архитектуру.
Мы использовали несколько критериев для определения необходимого количества кластеров GKE и организации рабочих нагрузок в них. Основными характеристиками, которые мы учитывали, были требования к потреблению ресурсов различными рабочими нагрузками, схемы межсервисного взаимодействия и баланс между эксплуатационной эффективностью и минимизацией радиуса воздействия сбоя.
Архитектурная схема
Ниже представлено упрощенное представление текущей архитектуры. Основная архитектура состоит из
четырёх кластеров GKE на каждую группу регионов (например, в регионах «Восток США» — один VPC) и на каждую среду. Архитектура охватывает несколько регионов, обеспечивая отказоустойчивость и высокую доступность на уровне сервисов. Существует четыре группы регионов, и, следовательно, четыре VPC. Внешний пользовательский трафик направляется в ближайший регион с помощью политики геолокации, настроенной в публичных зонах Cloud DNS. Внутри трафик маршрутизируется между группами регионов через прокси-приложение, а трафик между кластерами GKE — через внутренний балансировщик нагрузки (ILB), где каждый ILB имеет собственную запись DNS.
Характеристики многопользовательской платформы GKE
Как указано в общедоступной документации Google, при запуске и эксплуатации кластера GKE необходимо учитывать ряд факторов. Команда платформы усердно работала над решением следующих вопросов и удовлетворением требований различных команд арендаторов:
- Размещение рабочей нагрузки: команда платформы назначает метки пулам узлов для поддержки соответствия рабочей нагрузки, а арендаторы используют комбинацию маркеров и допусков, чтобы гарантировать распределение рабочих нагрузок по правильным пулам узлов. Это необходимо, поскольку каждый пул узлов предъявляет особые требования к межсетевому экрану в зависимости от типа обрабатываемого трафика (HTTPS, POPS и т.д.). Кроме того, теги диспетчера ресурсов используются для управления правилами межсетевого экрана и связывания пула узлов с соответствующим правилом межсетевого экрана.
- Управление доступом: управление доступом на основе ролей (RBAC) в Kubernetes — основной способ управления и ограничения доступа пользователей к ресурсам кластера. У каждого арендатора есть одно или несколько пространств имён в кластере, и кластер загружается со стандартными политиками в процессе подключения арендатора.
- Сетевые политики: все кластеры организованы на основе dataplane v2, а Yahoo Mail использует стандартную сетевую политику Kubernetes для управления потоками трафика. В основе лежит Cilium — решение с открытым исходным кодом для обеспечения, защиты и мониторинга сетевого соединения между рабочими нагрузками.
- Квоты ресурсов: для оптимизации использования ресурсов и предотвращения чрезмерного потребления команда платформы применяет квоты ресурсов для ЦП/памяти в пределах пространства имен.
- Масштабирование: определяется командой платформы на основе запросов квот, поданных арендатором при подключении. Из-за определённых ограничений функций, связанных с автоматической подготовкой узлов, связанных с использованием безопасных тегов для правил брандмауэра и определением определённого типа и формы машины, это не удалось реализовать, но мы совместно с командой инженеров разработали запросы функций для устранения этого пробела.
Проблемы
В ходе этой миграции как Yahoo Mail, так и Google столкнулись с техническими ограничениями и проблемами. Ниже мы описываем некоторые из основных проблем и подходы, принятые для их решения:
- Подключение к плоскости управления: Как и большинство корпоративных клиентов, Yahoo Mail предоставила частные кластеры GKE и нуждалась в подключении между плоскостью управления и инструментом CI/CD (отвёрткой) извне сети VPC. Команда платформы развернула хосты-бастионы, которые использовались для проксирования подключения к плоскости управления, но столкнулась с проблемами масштабируемости. Google совместно с клиентом протестировала два решения, использующие шлюз Connect и конечную точку на основе DNS, чтобы исключить необходимость в хосте-бастионе.
- Сквозной mTLS: одним из ключевых принципов безопасности Yahoo Mail было обеспечение сквозного mTLS, который должен быть реализован как в архитектуре в целом, так и в базовых сервисах Google Cloud. Это привело к серьёзным проблемам, поскольку один из ключевых продуктов балансировки нагрузки ( Application Load Balancer ) на тот момент не поддерживал сквозной mTLS. Мы исследовали альтернативные решения, такие как внедрение специализированного прокси-приложения и использование балансировщиков нагрузки уровня 4 во всём стеке. Профессиональные сервисы также сотрудничали с инженерами Google Cloud для определения требований к поддержке mTLS в рамках Application Load Balancer.
- Интеграция с Athenz: Yahoo Mail использовала внутренний инструмент управления идентификацией и доступом Athenz, с которым должны были интегрироваться все сервисы Google Cloud для реализации федерации идентификационных данных рабочей нагрузки. В контексте Kubernetes это означало, что пользователям по-прежнему требовалась аутентификация через Athenz, но федерация идентификационных данных рабочей нагрузки использовалась в качестве посредника. Поскольку федерация идентификационных данных рабочей нагрузки также была относительно новой функцией, для успешного внедрения в среду Yahoo Mail нам потребовалось тесное сотрудничество с инженерами Google Cloud.
- Kubernetes externalTrafficPolicy: Одной из отличительных функций, о которой Yahoo Mail горячо и с нетерпением рассуждала, была взвешенная маршрутизация для балансировщиков нагрузки. Эта функция позволяла оптимально направлять входящий трафик к бэкендам. Хотя эта функция поддерживалась для управляемых групп экземпляров, на тот момент встроенной интеграции с GKE не было. В связи с её отсутствием команде платформы пришлось исследовать и экспериментировать с режимами externalTrafficPolicy, такими как локальный и кластерный режимы, чтобы определить влияние на производительность и ограничения.
- Планирование ресурсов: Наконец, что не менее важно, специалисты Google Professional Services выполнили планирование ресурсов – краеугольный камень успешной миграции в облако. В данном случае это включало в себя совместную работу нескольких команд разработчиков приложений для определения базового уровня потребностей в ресурсах, формирования ключевых предположений и оценки ресурсов, необходимых для удовлетворения текущих и будущих потребностей. Планирование ресурсов – это высоко итеративный процесс, который должен меняться по мере изменения рабочих нагрузок и требований. Поэтому регулярные проверки и поддержание четкой коммуникации с Google имели первостепенное значение для обеспечения адаптации поставщика облачных услуг к потребностям клиента.
Следующая веха Yahoo Mail
Миграция такого большого приложения, как Yahoo Mail, — это сложнейшая задача. Благодаря двуединому подходу — «поднятию и переносу» для большинства сервисов и стратегической перестройке архитектуры для некоторых — Yahoo уверенно движется к настройке своей почтовой системы для следующего поколения клиентов. Хотя небольшая часть системы Yahoo Mail уже находится в эксплуатации, ожидается, что большинство её сервисов будут запущены в течение следующего года. Подробнее о том, как Google PSO может помочь с другими аналогичными сервисами, см. на этой странице.
cloud.google.com/consulting/portfolio
