LY Corporation отказывается от сильно кастомизированного OpenStack в пользу стандартной версии, чтобы избежать проблем с обновлениями. Новое облако Flava будет ближе к upstream-релизам. — theregister.com
LY Corporation, японский веб-гигант, доминирующий в сфере обмена сообщениями, электронной коммерции и платежей во многих странах Азии, объявила о замене сильно кастомизированного облака OpenStack на более стандартную версию стека с открытым исходным кодом, что сопровождается масштабной консолидацией.
LY Corp, образованная в 2023 году в результате слияния Yahoo! Japan и корейского гиганта обмена сообщениями LINE, пытается объединить свою инфраструктуру в новое унифицированное облако под названием «Flava» для поддержки своих сервисов. Это облако должно работать в значительном масштабе, поскольку такие сервисы, как приложение для обмена сообщениями LINE и портал Yahoo, насчитывают около 300 миллионов ежемесячных пользователей.
В конце прошлой недели компания сообщила, что внутреннее облако LINE под названием «Verda» включало 130 000 виртуальных машин, работающих на 11 000 хостах, распределенных по четырем кластерам OpenStack. Облако Yahoo! Japan «YNW» работало на 27 000 серверов и обслуживало более 160 000 виртуальных машин в более чем 160 кластерах OpenStack.
План компании по созданию нового облака «Flava» предусматривает 500 или более хостов, свыше 9 000 виртуальных машин и единый кластер OpenStack. Компания также использует прокси-сервер Envoy с открытым исходным кодом, Linux, расширенный фильтр пакетов Беркли (eBPF) и быструю передачу данных (XDP), FRRouting (FRR) и Ceph.
«В устаревшем облаке слишком много пользовательских модификаций OpenStack затрудняли обновления», — заявил Рютаро Иноуэ, руководитель подразделения облачной инфраструктуры LY. «Flava принимает архитектуру, которая остается согласованной с основным проектом OpenStack. Мы сводим пользовательские патчи к минимуму, а когда требуются функциональные изменения, мы проактивно вносим их в основной проект, чтобы они могли быть объединены в главный релиз».
«Устраняя барьеры для обновлений, мы обеспечиваем регулярный цикл обновлений и постоянно поддерживаем доступность как безопасности, так и новейших функций», — добавил он.
Иноуэ отметил, что LY также стремится «избежать чрезмерных инвестиций только в гарантии доступности на уровне инфраструктуры» и вместо этого предполагает, что сбой всегда возможен. Он сказал, что дизайн Flava пытается охватить это с помощью следующих трех «столпов»:
- Стремление к stateless-архитектуре — мы определяем данные, хранящиеся на корневом диске виртуальной машины (временном диске), как временные. Мы переносим постоянные данные во внешнее хранилище, чтобы минимизировать влияние на сервис в случае сбоя экземпляра.
- Доступность, управляемая приложениями — вместо того чтобы пытаться обеспечить идеальную доступность только за счет инфраструктуры, мы обеспечиваем надежность, сочетая инфраструктуру с архитектурой на стороне приложения, что снижает ненужную сложность инфраструктуры.
- Более быстрое восстановление — при инциденте приоритетом является не восстановление точного предыдущего состояния, а поддержание работы сервиса. Мы рекомендуем операционный подход, который быстро восстанавливает среды с использованием Инфраструктуры как Кода (IaC), вместо того чтобы тратить много времени на анализ первопричин.
Компания также уделяет большое внимание наблюдаемости (observability). Иноуэ сообщил, что его команда использует Prometheus, Grafana и внутренние панели мониторинга «для постоянного отслеживания общего состояния облака и тенденций для выявления ранних признаков аномалий». Если эти инструменты показывают признаки проблем, «мы углубляемся в детальные сигналы, такие как трассировки на уровне ядра и захват пакетов, чтобы точно определить причину».
Иноуэ заявил, что LY сталкивается с аппаратными сбоями «где-то каждый день», и обрабатывать их все вручную невозможно. «Сегодня мы автоматизировали большую часть процесса: от обнаружения сбоя до запроса работ в центре обработки данных на месте и повторной интеграции замененного оборудования в кластеры», — написал он. «Тем не менее, некоторые задачи и нерегулярные схемы сбоев по-прежнему требуют ручного вмешательства инженеров. В будущем мы планируем использовать большие языковые модели и для этих рабочих процессов, требующих принятия решений, что еще больше продвинет автоматизацию».
LY необходима эта работа, поскольку компания столкнулась со значительными проблемами информационной безопасности, которые привели к утечке пользовательских данных, в результате чего правительство Японии потребовало провести работы по улучшению безопасности и конфиденциальности ее технологического стека. ®
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Simon Sharwood