Для чего они нам понадобились

• Сложно жить с монолитом. Быстро писать код мешали устаревание подходов, фреймворков и зависимостей, а также связанность логики.
• Совместная разработка. Долго решать конфликты, противоречивость изменений.
• Проблема с тестированием. Когда прилетали баги от других задач и команд, было непонятно, в чём причины.
• Развёртывание было зависимое и блокирующее.

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

Устройство проекта

• Основное старое приложение на AngularJS, к которому мы планируем подключать новые микроприложения.
• Dashboard-приложение на Angular 6, подключенное через iframe (но оно со временем разрослось и от описанных выше проблем не избавило). К нему подключаются приложения, здесь хранятся старые страницы.
• Приложения на VueJS, которые используют самописную библиотеку компонентов на VueJS.

• Разделение приложения на страницы по маршрутам.
• iframe.
• Микрофронтенды.

Что такое микрофронтенды

• micro-frontends.org
• www.youtube.com/watch?v=VJEi8_A3ZRc&t=2414s

Проблемы внедрения микрофронтендов

1. Ещё один iframe? Может, уже хватит?

• Неудобная навигация. Каждый раз для редиректа на внешнюю ссылку нужно использовать window.postMessage.
• Сложно верстать в iframe.

1. Написали скрипт, который добавляет ссылку на сборку микрофронтенда в разделе head страницы при переходе на соответствующий маршрут.
2. Добавили конфигурацию для микрофронтенда.
3. Добавили в window.customElements тег review-ui-app.
4. Подключили review-ui-app в dashboard-приложение.

2. А где стили?

• Первое: импортировать все стили в один файл и передать его во vue-wrapper (но это слишком топорно и пришлось бы добавлять вручную каждый новый файл со стилями).
• Второе: подключить стили с помощью CSS-модулей. Для этого пришлось подкрутить webcomponents-loader.js, чтобы он вшивал собранный CSS в shadow dom. Но это лучше, чем вручную добавлять новые CSS-файлы :)

3. Теперь про иконки забыли!

1. Сначала мы попытались подрубить спрайт так же, как и стили, через appendChild. Они подключились, но всё равно не отображались.
2. Затем мы решили подключить через sprite.mount(this.shadowRoot). Добавили в вебпаке в svg-sprite-loader опцию spriteModule: path.resolve(__dirname, './src/renderers/sprite.js). Внутри sprite.js экспортировали BrowserSprite, и иконки начали отображаться! Мы, счастливые, подумали, что победили, но не тут-то было. Да, иконки отображались, и мы даже выкатились с этой версией в прод. Но потом нашли один неприятный баг: иконки пропадали, если походить по вкладкам dashboard-приложения.
3. Наконец, во vue-wrapper мы подключили DcIconComponent (библиотечный компонент, позволяющий работать с библиотечными иконками) и в нём подключили иконки из нашего проекта. Получили отображение без багов :)

4. Без авторизации никуда!

• Токен с авторизацией передаём с помощью свойств веб-компонента.
• С помощью AuthRequestInterceptor подключаем токен-запросы для API.
• Используем токен, пока он не протухнет. После протухания ловим ошибку 401 и кидаем в dashboard-приложение событие обнови токен, пожалуйста (ошибка обрабатывается в AuthResponseInterceptor).
• Dashboard-приложение обновляет токен. Следим за его изменением внутри main-сервиса, и когда токен обновился, заворачиваем его в промис и подписываемся на обновления токена в AuthResponseInterceptor.
• Дождавшись обновления ещё раз повторяем упавший запрос, но уже с новым токеном.

5. Нас волнуют зависимости

• В микрофронтенд-приложении указываем в webpack.config.prod.js в разделе externals те зависимости, которые хотим вынести:
  
  

  module.exports = {externals: {vue: Vue},
  

  
  Здесь мы указываем, что под именем Vue в window можно будет найти зависимость vue.
• В рамках оболочки (в нашем случаем в dashboard-приложении) выполняем npm install vue (и другие npm install-зависимости).
• В dashboard-приложении импортируем все зависимости:
  
  

  import Vue from vue(window as any).Vue = Vue;
  

• Получаем удовольствие.

6. Разные окружения

1. Добавили в микрофронтенд файл, в котором определяем конфигурацию для приложения в runtime браузера. Также добавили в Docker системный пакет, который предоставляет команду envsubst. Она подставляет значения в env.js, который тянет микрофронтенд-приложение, и эти переменные пишутся в window['${APP_NAME}_envConfig'].
2. Добавили переменные окружения отдельно для прода и отдельно для тестового окружения.

• настроили локальные моки (раньше приходилось вручную включать их локально);
• настроили тестовое окружение без дополнительных ручных переключений на прод и обратно.

Выводы

Хабр, привет! Меня зовут Николай Бутенко, я руководитель Private Cloud в Mail.ru Cloud Solutions, и сегодня хочу обсудить с вами одно из самых больших заблуждений, с которыми я встречаюсь каждый день. Если вы когда-либо работали с облачными сервисами, то наверняка знаете о распространенном мнении, что перенос приложения в облако является панацеей от всех возможных с ним проблем. Я регулярно сталкиваюсь с такой позицией на встречах с самыми разнообразными заказчиками.

К сожалению, это мнение ошибочно. Часть ответственности лежит и на самом клиенте. Необходимо придерживаться определенных принципов в построении Cloud Native-приложений, чтобы обеспечить их отказоустойчивость, причем как на уровне программного кода, так и на уровне нижележащей инфраструктуры. При этом следует понимать, что даже соблюдение этих принципов не гарантирует полной защиты от всех рисков.

Поэтому если перед вами стоит задача построить на 100% отказоустойчивую и высокодоступную (High Availability, HA) систему, я рекомендую придерживаться подхода Multicloud Native Service, сочетающего лучшее в подходах Multicloud и Cloud Native. Такой подход не сводится только к использованию контейнеров: чтобы приложение могло пережить любой отказ, нужно подумать и об инфраструктуре, в частности использовать не одну, а минимум две независимые площадки, например провайдера публичного облака и частную инфраструктуру.

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

Принципы построения Cloud Native-приложений

Прежде чем рассматривать варианты построения Cloud Native-архитектур, необходимо, чтобы ваши приложения были готовы к переносу в облако. По мнению фонда Cloud Native Computing Foundation (CNCF), ставшего своего рода амбассадором в области развития облачных технологий, существует пять базовых принципов, которые выделяют Cloud Native-приложения из числа прочих.

1. Динамичность

Это возможность быстрого развертывания и конфигурирования вашей системы на любой новой площадке, что становится особенно актуальным при неожиданной смене облачного провайдера. К средствам достижения динамичности можно отнести CI/CD и подход Infrastructure As Code (IaC). Остановимся подробнее на втором.

Вся ваша инфраструктура должна быть декларативно описана в виде кода. Описание может включать перечень необходимых сервису виртуальных машин, требования к их конфигурации, топологию сети, DNS-имена и так далее. Стандартом де-факто для решения этой задачи в последнее время стал Terraform, однако существуют и альтернативы: Ansible, Salt, Cloudify, Foreman, Pulumi, AWS Cloud Formation.

Задача этих инструментов возможность быстрого развертывания, настройки инфраструктуры и контроль сохранения ее состояния, в том числе при смене провайдера. Если при небольшом количестве виртуальных машин их ручная настройка вполне возможна, то в том случае, когда это количество измеряется сотнями и дополняется сложной сетевой топологией, процесс переноса инфраструктуры может занять в лучшем случае несколько недель, а то и месяцев. Цель подхода IaC сократить это время. При наличии декларативных описаний все, что обычно требуется при переходе, это использовать другой Terraform-провайдер, изменить Environment-переменные и немного отформатировать код.

Хорошей практикой считается сочетание инструментов для декларативного описания с Post Install-скриптами, которые после запуска инфраструктуры конфигурируют информационную систему нужным образом, например устанавливают последние обновления используемого ПО и так далее. Для этой цели предназначены Ansible Playbooks, Puppet, Chef и другие инструменты, либо можно использовать cloud-unit.

2. Возможность эксплуатации

Это возможность управления жизненным циклом ваших систем в автоматизированном режиме. Это свойство тесно связано с динамичностью и включает в первую очередь применение пайплайнов CI/CD для автоматического развертывания приложений. У вас должна быть возможность оперативно выпускать новые сборки, отслеживать статус их выполнения на различных средах и выполнять откат в случае сбоев. Если вы строите приложение на основе микросервисов, для каждого сервиса рекомендуется настраивать независимый жизненный цикл (отдельную сборку). Обязательно учитывайте возможность отката обновлений или обновление только части ваших информационных систем (Rolling Update), это поможет избежать ошибок на уровне выкатки, которые могут привести к недоступности всего сервиса.

Современный IT-рынок предлагает множество решений для построения CI/CD: GitLab CI/CD, Jenkins, GoCD и другие.

3. Возможность наблюдения

Это мониторинг инфраструктуры и разнообразных бизнес-метрик ваших систем. Необходимость мониторинга для любого приложения, будь то Startup- или Enterprise-решение, сложно переоценить. Однако я регулярно сталкиваюсь с проектами, где мониторинг отсутствует, что в большинстве случаев приводит к серьезным проблемам. При переходе в облако мониторинг как минимум поможет проверять заявленный SLA провайдера и получать ретроспективу производительности при разборе спорных ситуаций, как максимум находить узкие места в архитектуре и исправлять их до того, как они станут влиять на пользователей.

В большинстве случаев облачные провайдеры поддерживают все стандартные инструменты мониторинга, такие как Prometheus, Grafana, Fluentd, OpenTracing, Jaeger, Zabbix и другие, а также могут предлагать собственный встроенный мониторинг.

4. Эластичность

Это возможность масштабирования ваших приложений в зависимости от изменяющейся нагрузки. Когда речь заходит об автоматическом масштабировании, первым из доступных инструментов на ум приходит, конечно же, Kubernetes, ставший своего рода стандартом оркестрации контейнерных приложений. И действительно, он поддерживает все необходимые уровни масштабирования, а у некоторых провайдеров в том числе даже автомасштабирование на уровне кластера из коробки. Однако отмечу, что его использование отнюдь не является обязательным: можно построить эластичное приложение на основе чистого IaaS (Infrastructure as a Service), используя мониторинг и преднастроенные хуки для обработки изменений нагрузки. Да, Kubernetes значительно упрощает этот процесс, но не стоит забывать, что он является всего лишь инструментом.

Чтобы соответствовать подходу Cloud Native, крайне важно планировать свою архитектуру так, чтобы в ней не было узлов, масштабируемых только вертикально (путем увеличения/уменьшения выделенных ресурсов), так как в конечном итоге вы будете ограничены мощностями нижележащего оборудования или гипервизоров в облаке. Постарайтесь обеспечить каждому узлу возможность горизонтального масштабирования за счет изменения числа экземпляров самого приложения.

Отдавайте предпочтение горизонтальному масштабированию

Также не стоит забывать оборотную сторону скейлинга возможные проблемы с DDoS-атаками. Нужно всегда тщательно подбирать границы для автомасштабирования (минимальное и максимальное число узлов) и использовать AntiDDos. В противном случае DDoS-атаки, не отличаемые системой автомасштабирования от полезной нагрузки, могут привести вас к серьезным финансовым потерям.

5. Отказоустойчивость

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

Приведу несколько основных рекомендаций:

1. Составьте план учений DRP (Disaster Recovery Plan) и регулярно проводите согласно нему стресс-тесты для выявления единых точек отказа в системе (Single Point Of Failure, SPOF). Очень важно учитывать все возможные домены отказа, в том числе проверяя поведение системы в боевом режиме при выходе из строя отдельных узлов или целого плеча системы. Конечно, обеспечивая возможность их быстрого включения обратно.
2. Используйте георепликацию для обеспечения высокой доступности ваших данных. Георепликация гарантирует хранение копий данных в нескольких дата-центрах. Но учитывайте, что геораспределенное хранилище имеет более высокие задержки отклика и не подходит для решений, требующих низкого Latency, например высоконагруженных баз данных.
3. Используйте балансировку нагрузки на всех уровнях вашего приложения: перед web-серверами, серверами приложений и серверами баз данных. Все сетевые вызовы должны направляться не на прямые адреса виртуальных машин, а на адреса балансировщиков во избежание создания дополнительных точек отказа. Большинство облачных провайдеров предлагает балансировку нагрузки как сервис (Load Balancer as a Service, LBaaS). Учитывайте возможность выхода из строя части узлов, чтобы перераспределенная нагрузка не убила оставшиеся экземпляры сервиса. Используйте также надежные GSLB для балансировки между разными провайдерами.
4. Используйте резервное копирование. Хотя я в своей практике сталкивался с примерами сервисов и информационных систем, где была построена правильная Cloud Native-архитектура и вовсе отказались от ведения бэкапов: они стали не актуальны. Так что ведение бэкапов желательно, но вовсе не обязательно но только если вы грамотно используете Multicloud Native-подход. Если вы сомневаетесь, всегда делайте бэкапы!
5. Проведите аудиты безопасности, например Penetration Test, на предмет уязвимостей и устойчивости к разным типам атак.

С другими рекомендациями по созданию отказоустойчивых приложений от Mail.ru Cloud Solutions можно ознакомиться по ссылке.

Виды рисков при работе с облаком

Предположим, ваш сервис или информационная система полностью соответствует описанным выше принципам Cloud Native-приложений. Вы выбрали подходящего провайдера и осуществили переход в облако с учетом всех рекомендаций. Означает ли это, что теперь вашим сервисам ничего не угрожает и возможность их недоступности полностью исключена? К сожалению, нет. Даже после переноса приложения в облако остаются определенные риски, которые условно можно разделить на три группы.

1. Географические риски

Любой, даже самый надежный облачный провайдер не застрахован от чрезвычайных ситуаций, будь то стихийные бедствия или аварии техногенного характера. Пожары, наводнения и даже банальная поломка кабеля это лишь неполный перечень того, что может надолго вывести ЦОДы из строя, а в худшем случае полностью их уничтожить.

Думаю, многие помнят пожар в московском дата-центре OST провайдера DataLine в июне 2019-го. Но тогда удалось обойтись малыми жертвами все клиенты были оперативно переведены на резервные площадки, да и урона машинному залу фактически нанесено не было: пострадали лишь кровля и система кондиционирования. К гораздо большим потерям привел недавний пожар в дата-центре SBG2 провайдера OVH в Страсбурге, обернувшийся падением множества сервисов по всему миру, полным уничтожением одного ЦОДа (SBG2) и вынужденной потерей второго ЦОДа, расположенного рядом и частично пострадавшего от пожара (SBG1). В этом как раз и состоит суть географических рисков: когда ЦОДы провайдера территориально расположены близко друг к другу, в случае катастрофы они не страхуют друг друга, а все оказываются под угрозой.

Поэтому при выборе провайдера обязательно обращайте внимание на два пункта:

1. У провайдера несколько ЦОДов.
2. ЦОДы расположены на достаточном расстоянии друг от друга, по возможности используют разные каналы связи, интернет-провайдеров и питаются от различных электростанций.

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

2. Government-риски

Сюда входят различные политические и законодательные решения, которые могут неожиданно потребовать смены провайдера. В качестве наиболее яркого примера последних лет можно назвать бан социальной сети Parler в январе 2021 года, когда Amazon отказал этой платформе в дальнейшем хранении данных и приложение фактически стало недоступным. В России можно вспомнить 152-ФЗ, запрещающий хранить персональные данные пользователей за пределами РФ, что автоматически ограничивает выбор провайдеров для определенных организаций (банковский сектор, медицинские организации и так далее).

Особенность Government-рисков в том, что выход законопроектов и иных политических решений, как правило, требует очень быстрой реакции, поэтому крайне важно всегда быть готовым к незапланированной смене провайдера.

3. Риски сбоев на стороне провайдера

Это технические сбои на уровне провайдера в целом, чаще всего связанные с человеческим фактором, например выходом неверных обновлений, ошибками в прогнозировании потребляемых ресурсов и так далее. Даже у таких общепризнанных облачных лидеров, как Amazon и Google, регулярно фиксируются сбои в сервисах. Например, в Google Cloud за последний год произошло свыше 100 инцидентов, в AWS сбои происходят минимум раз в год. В качестве примера можно вспомнить крупный сбой на стороне AWS в ноябре 2020 года, в результате которого возникли неполадки в работе множества сайтов и приложений, включая iRobot, Flickr, Roku и Adobe Spark.

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

Таким образом, мы рассмотрели три вида рисков, с которыми вы можете столкнуться после перевода своих приложений в облако. Но если первая группа рисков легко устраняется за счет выбора провайдера с географически разнесенными ЦОДами, то риски из второй и третьей групп, по моему мнению, можно исключить, только применив Multicloud Native Service-подход.

Для устранения всех возможных рисков при работе в облаке рекомендуется подход Multicloud Native Service

Multicloud Native Service и Multicloud: в чем разница?

В первую очередь следует различать подходы Multicloud и Multicloud Native Service.

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

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

Вариант применения подхода Multicloud: использование данных приложения, запущенного в одном облаке, для анализа в другом облаке

Вариант применения подхода Multicloud: хранение данных в нескольких облаках

Подход Multicloud Native Service подразумевает, что вы разрабатываете свой продукт таким образом, что он соответствует принципам Cloud Native и полностью абстрагируется от конкретного облачного провайдера. В первую очередь это достигается за счет отказа от проприетарных сервисов, о которых мы еще подробно поговорим. Такой подход позволяет одновременно развертывать ваши приложения в нескольких выбранных вами облаках и легко переносить их из одного облака в другое без простоев.

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

Подход Multicloud Native Service: развертывание и использование приложения в нескольких облаках одновременно

Таким образом, если Multicloud это про количество облачных провайдеров, то Multicloud Native Service это больше про сами приложения, их соответствие всем принципам Cloud Native и возможность развертывания на нескольких независимых площадках. Чаще всего Multicloud Native Service строится на основе Multicloud, но так происходит не всегда, так как в качестве площадок в этом случае могут выступать не только публичные облака или гибридные инфраструктуры, но и варианты с собственными ЦОДами компании.

В дальнейшем я буду говорить именно про подход Multicloud Native Service.

Варианты построения архитектур Multicloud Native Service

Существует два основных способа построения архитектур по подходу Multicloud Native Service:

1. Использование нескольких публичных провайдеров

В этом случае одно плечо инфраструктуры строится на стороне одного публичного провайдера, а второе на стороне другого провайдера. Например, можно комбинировать локального провайдера, действующего на территории РФ (Mail.ru, Яндекс, МТС, Ростелеком и другие), и глобального, действующего во всем мире (AWS, Google Cloud, Alibaba, Azure и другие), либо использовать двух локальных провайдеров одновременно.

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

2. Сочетание частной инфраструктуры и публичного провайдера

Это более распространенный вариант в российских реалиях, когда клиент продолжает использовать традиционную инфраструктуру на своей стороне (это может быть голое железо, виртуализированная среда или даже приватное облако) плюс добавляет к ней публичного облачного провайдера. Чаще всего получившуюся архитектуру называют гибридным облаком (Hybrid), но если ПО и инфраструктура в этом случае реализуют все принципы Cloud Native-приложений, то систему в целом можно называть Multicloud Native Service.

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

Упрощенная схема Multicloud Native Service-архитектуры: два плеча, в роли которых могут выступать два облачных провайдера либо один провайдер и частная инфраструктура

Возможные проблемы при переходе на Multicloud Native Service и как их избежать

Разумеется, у подхода Multicloud Native Service есть свои подводные камни. Ниже приведен перечень наиболее часто встречающихся проблем и описаны способы их решения:

1. Сетевые задержки

Если для вашей системы приоритетны низкие задержки, например требуются синхронные реплики БД, то, скорее всего, вам не подойдет вариант сочетания локального и глобального провайдеров в силу их территориальной удаленности. Следует выбирать провайдеров, которые смогут обеспечить минимальный Latency, например через выделенный канал Direct Connect. Это могут быть два локальных провайдера на территории РФ либо сочетание локального облачного провайдера и частной инфраструктуры. Также Direct Connect позволяют делать некоторые глобальные провайдеры.

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

2. Разница в производительности вычислительных ресурсов

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

3. Vendor lock-in

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

Пояснить проблему Vendor lock-in проще всего на примере референсных архитектур (Architecture Reference), предлагаемых большинством ведущих облачных провайдеров. Эти архитектуры описывают готовые решения (комбинации компонентов, их взаимосвязи и так далее) для типовых архитектурных задач, которые могут возникнуть при переходе в облако. Например, референсные архитектуры от Google и AWS.

На рисунке ниже приведен пример референсной архитектуры от AWS для обработки логов, которые впоследствии используются для построения мониторинга. Из рисунка очевидно, что для решения архитектурной задачи провайдер предлагает сразу несколько своих проприетарных сервисов: AWS Lambda, Amazon Kinesis Data Streams и так далее.

Пример референсной архитектуры от AWS. Источник

Предположим, вы воспользовались рекомендациями провайдера, построили красивое и быстрое решение на основе его сервисов. Но что будет, если в будущем вам потребуется сменить провайдера? Правильно, многое придется переписывать с нуля. Вы потеряете время и, по сути, будет вынуждены делать двойную работу. А кроме этого, можете уступить конкурентам, которые, оказавшись в похожей ситуации, выполнят смену провайдера быстрее, если они не использовали проприетарные сервисы.

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

Какому провайдеру отдать предпочтение

В предыдущих разделах мы определились, что для построения отказоустойчивых приложений лучше всего использовать пару различных облачных провайдеров. Но как сделать правильный выбор из множества доступных на современном IT-рынке вариантов, какие возможности предлагает идеальный провайдер? А также на какие сервисы стоит ориентироваться, чтобы не попасть в ловушку Vendor lock-in?

По моему мнению, джентльменский набор современного облачного провайдера должен выглядеть примерно так:

1. Реализация подхода IaC (Infrastructure as Code). В большинстве случаев это подразумевает поддержку Terraform, но не обязательно. В Mail.ru Cloud Solutions работает стандартный Terraform-провайдер, также можно использовать для управления инфраструктурой наш собственный Terraform-провайдер, доработанный под нашу платформу. Также сюда обязательно входит управление жизненным циклом виртуальных машин (Virtual Machine Lifecycle Management).
2. Наличие хорошо документированных CLI и API. Необходимо для быстрого и удобного управления облачными ресурсами.
3. Возможность подключения DC (Direct Connect). Это установка выделенного сетевого соединения между облаком и своим собственным ЦОДом или офисом с целью изолированного сетевого соединения, а также увеличения пропускной способности и обеспечения более устойчивой работы, чем через подключение по интернету. При этом уровень, на котором настраивается соединение, не принципиален (L2, L3).
4. Поддержка CDN (Content Delivery Network). Использование географически распределенной сетевой инфраструктуры, лежащей в основе CDN, позволяет быстро раздавать контент по всему миру с задержкой в считаные миллисекунды даже во время пиковых нагрузок.
5. Наличие DNS и балансировщиков сетевой нагрузки. Это важная часть настройки любых виртуальных сетей.
6. Соответствие местному законодательству и наличие прочих сертификатов. Например PCI DSS, ISO 27*, GPDR для Европы, ФСТЭК для России и так далее. Это поможет избежать дополнительной головной боли при локализации.
7. Технологическое соответствие между провайдерами. Если, например, ваша исходная инфраструктуру использует VMWare, логично выбрать провайдера предоставляющего гипервизор ESXi, желательно той же версии. Это сильно упростит миграцию. Тоже справедливо и для других платформ и гипервизоров. Требование не является обязательным, можно разместиться и на разных платформах.
8. Поддержка основного пула сервисов:
   
   • контейнеризация/оркестрация (общепризнанный стандарт K8s или OpenShift);
   • базы данных как сервис;
   • S3 объектное хранилище для хранения больших объемов данных и статического контента;
   • очереди сообщений (Simple Queue Service, SQS);
   • Big Data с этим сервисом стоит быть аккуратным, чтобы не получить Vendor lock-in, так как некоторые провайдеры реализуют его по-своему;
   • мониторинг инфраструктуры и бизнес-метрик, в идеале сервис мониторинга должен быть независимым;
   • бессерверные вычисления (Function as a Service, FaaS). Незаменимы для обработки непрогнозируемой нагрузки без сохранения состояния (чат-боты, социальные сети и так далее);
   • аудит как сервис;
   • стандартные функции вида биллинга, сервисов ИБ (такие как WAF, AntiDDOS, возможность проведения аудитов ИБ), возможности использовать idP, RBAC;
   • выбирайте надежный Global Server Load Balancer, не надейтесь только на балансировку на уровне облачного провайдера, так как она подвержена тем же рискам.

Выводы

Кто-то скажет, что это давно известно, и будет прав. Однако встречаемое мною каждый день среди совсем разных бизнесов, компаний и IT-специалистов ошибочное мнение, что облако должно обеспечивать доступность вашего приложения, побудило во мне желание еще раз напомнить, что отказоустойчивость и доступность приложения это общая задача.

Если для ваших приложений приоритет отказоустойчивость и высокая доступность, лучшим решением будет использовать подход Multicloud Native Service. Да, это сложно, дорого, требует новых подходов к разработке, применимо не ко всем типам сервисов и чаще всего доступно исключительно крупному бизнесу. Но это позволяет исключить все виды возможных рисков.

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

Также важно понимать, что подходы Cloud Native и построенный на его основе Multicloud Native Service это в большей степени не про используемые вами программные инструменты. Например, они не требуют от вас жесткого использования контейнеров и Kubernetes, как принято считать. Применение этих подходов в первую очередь означает, что вы полностью продумали инфраструктуру и проверили все возможные домены отказа. И в случае сбоев вы не возлагаете всю ответственность на своего провайдера, осознавая, что успешная работа приложений в облаке во многом определяется и вашими действиями тоже.

Любите облака, и они ответят вам взаимностью.

Что еще почитать:

1. VMware и OpenStack: сравниваем две платформы для развертывания инфраструктуры.
2. Как правильно посчитать TCO инфраструктуры.
3. Наш канал в Телеграм о цифровой трансформации и IT-бизнесе.

Castle in the sky by PiotrDura

Публичное и частное облако одного провайдера два разных продукта или одна и та же платформа, просто развернутая на разном оборудовании? На примере решения для Х5 Retail Group я, Илья Болучевский, технический директор Mail.ru Private Cloud, расскажу, в чем отличия и как построен процесс внедрения облака вендора в корпоративную инфраструктуру.

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

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

В Х5 частное облако одну из самых дорогих инфраструктур выбрали, чтобы в три раза ускорить вывод новых продуктов на рынок и получить доступ к новым технологиям, не нарушая стандартов корпоративной безопасности.

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

• Почему Х5 Retail Group пошли в частное облако и каких результатов достигли
• Почему так сложно развернуть частное облако
• Какую инфраструктуру мы построили для Х5 Retail Group
• Основные этапы внедрения частного облака
• Подготовительные этапы к внедрению частного облака
• Как происходит развертывание приватного облака
• Кастомные доработки PaaS
• Маркетплейс приложений
• Кастомные интеграции платформы
• Самое сложное: переделка сетевой топологии
• Технологические ограничения, которые пришлось учесть в процессе внедрения
• Итоги

Почему Х5 пошли в частное облако и каких результатов достигли

Компания столкнулась с необходимостью обеспечить быстрое выделение ресурсов под внутренние проекты, а также запустить новые процессы: микросервисную разработку в новом формате, CI/CD-пайплайны на базе облака и Managed-сервисов, автоматизацию на уровне IaC.

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

Для решения этих проблем нам нужно было в сжатые сроки развернуть гибкую управляемую инфраструктуру вместе с командой Х5 Retail Group, организовать внедрение, а потом частично взять на себя эксплуатацию продукта, кастомизации, возникающие в процессе, и интеграцию новых сервисов под требования клиента.

Результаты. После внедрения облака значительно улучшились KPI: раньше ресурсы виртуализации выдавались внутренним заказчикам в течение нескольких дней, теперь за минуты. Командам компании стало удобнее запускать пилоты, среды разработки, пересоздавать их.

Также компания интегрировала с платформой собственную разработку, которая автоматизирует доступ к ресурсам для внутренних клиентов. Благодаря ей внутренние клиенты разработчики, тестировщики, проектные менеджеры получили больше прав для самостоятельной работы с сервисами. Раньше с задачами они шли в службу поддержки и заводили там заявку, которая двигалась по очереди между несколькими командами. Сейчас все работает как Self-Service: автоматически, без ручного труда. Внутренние заказчики могут выбирать сервисы, смотреть демо, рассчитывать стоимость инфраструктуры под проект, что значительно ускорило процесс согласования.

Кроме того, выгоднее стала платформа контейнеризации за счет особенностей лицензирования решения: компания внедрила Kubernetes как сервис, который построен на Open-Source-технологии. Он дает возможность внутренним заказчикам получать полноценные кластеры с возможностью автомасштабирования, что помогает гибко управлять ресурсами. Также для ряда задач в качестве платформы контейнеризации продолжают использовать OpenShift и ванильный Kubernetes.

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

В итоге внедрение частного облака позволило нашему клиенту ускорить Time-to-Market IT-продуктов компании. Однако достичь этого было непросто: ниже разберу, какие проблемы возникают в процессе и как мы их решаем.

Почему так сложно развернуть частное облако

Создание частного облака в существующем IT-ландшафте это как стыковка Союз Аполлон: нужно соединить две совершенно разные системы сложившуюся корпоративную и внешнюю, которую приносит провайдер частного облака. Даже имея готовые компоненты, нельзя взять публичное облако и развернуть такое же во внутреннем контуре компании, ничего не меняя. У каждой компании свои требования, требуются сложные кастомизации, интеграции и доработки.

Например, у нас в Mail.ru Cloud Solutions есть готовый Kubernetes aaS. Для Х5 Retail Group мы полностью переписали его под другую топологию сети не потому, что он чем-то плох, а потому, что корпоративное частное облако иначе работает. Фактически публичное облако приходится каждый раз частично пересоздавать под каждого клиента.

По мере наработки клиентской базы мы стали лучше работать с запросами клиентов. Большинству нужны одни и те же доработки: интеграция с ADFS, кастомизация образов, в том числе для баз данных, свои ролевые модели, SSO-интеграции. Есть уникальные требования вроде RBAC-модели по сетевым портам.

Сейчас мы понимаем, какие запросы повторяются, и добавляем в платформу новые опции. Но не все запросы имеет смысл автоматизировать то, что будет узкоспециализированным для существующих ITSM-процессов клиента, остается в обычном режиме. Такие ручные кастомизации усложняют процесс внедрения. Бывают и доработки публичного облака на основе работы с клиентом приватного так, RBAC пришел из приватного облака в наше публичное.

Другая сложность взаимодействие команд. Нужно сработать вместе: наша команда обладает компетенцией в своем продукте, Х5 компетенцией в своих системах. Нужно объединить компетенции, договариваться, чтобы достичь результата. В Х5 Retail Group работает квалифицированная команда, которая на равных участвовала в процессе интеграции и выстроила процессы работы изнутри.

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

Также мы используем сильно кастомизированную платформу OpenStack, а большой энтерпрайз часто привык к VMware и похожим решениям, то есть сотрудникам надо быть готовыми администрировать новый тип платформы. OpenStack администрируется через пользовательский интерфейс иначе, чем VMware: много командной строки, конфигурационных файлов и параметров. Иногда это встречает сопротивление у компаний, которые годами использовали другие технологии. Для решения этой проблемы у нас есть обучающий курс, а также наши сотрудники постоянно в контакте с менеджерской командой клиента.

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

Какую инфраструктуру мы построили для Х5

В Х5 Retail Group сейчас развернута облачная инфраструктура с единой консолью администрирования, маркетплейсом приложений и порталом самообслуживания для внутренних заказчиков. Им доступны платформенные сервисы, в которых у компании была потребность в момент внедрения, аналогичные таким же из нашего публичного облака. Компания получила наш Kubernetes как сервис и облачные базы данных, которые прошлые платформы не предоставляли: ранее их запускали в IaaS руками, на внутренней системе виртуализации.

В состав платформы входят следующие наши сервисы:

• инфраструктурные сервисы (IaaS) виртуальные машины в различных конфигурациях, диски, балансировщики нагрузки, настройки Firewall;
• PaaS кластеры Kubernetes как базовая платформа контейнеризации, набор баз данных PostgreSQL, Redis, MongoDB, MySQL, чтобы внутренние заказчики могли выбрать СУБД под потребности проекта/продукта. Все сервисы адаптированы под требования информационной безопасности компании;
• отказоустойчивые хранилища на базе CEPH с тройной репликацией данных и интеграцией с СХД клиента;
• маркетплейс, который в X5 используют для размещения нужных внутренним заказчикам приложений.

В нашем публичном облаке реализован биллинг потребляемых ресурсов/сервисов по модели pay-as-you-go на базе платформы in-memory вычислений Tarantool. Для Х5 в него внесены изменения: в частном облаке это не биллинг оплаты провайдера, а система внутренней отчетности и планирования ресурсов. Она нужна, чтобы мониторить мощности, которые использует каждый проект, контролировать соблюдение лимитов по квотам ресурсов, формировать финансовую отчетность для точной оценки расходов по каждому проекту. Это в том числе требуется и для финансового планирования на старте проекта: использование внутренней инфраструктуры не бесплатно, подсчет расходов на нее позволяет точнее оценить ROI проекта. В такой форме решение может быть адаптировано и для других клиентов MCS.

Также у нас есть отдельный инструмент маркетплейс, это витрина с SaaS-приложениями, которые можно использовать внутри платформы. Х5 применяют его как витрину приложений для внутренних клиентов: там размещены приложения для разработки и DevOps.

Мы провели обучение для команды компании, как паковать приложения с помощью Git. Теперь специалисты Х5 Retail Group сами его наполняют приложениями, которые нужны внутренним заказчикам. По сути, идут в SaaS-историю, используя платформу как оркестратор и витрину, ориентируясь на востребованность сервисов, добавляя то, что будет использовано продуктовыми командами.

С платформой интегрирована внутренняя разработка X5, созданная инженерами компании и позволяющая автоматизировать доступ к ресурсам для внутренних клиентов. Благодаря ей и возможностям облака разработчики, тестировщики, проектные менеджеры получили больше прав для самостоятельной работы с сервисами. Раньше с задачами они шли в службу поддержки и заводили там заявку, которая двигалась по очереди между несколькими командами. Сейчас все работает как Self-Service: автоматически, без ручного труда. Где-то процессы доступа были упразднены, а где-то согласование осталось, но было автоматизировано. Внутренние заказчики могут выбирать сервисы, смотреть демо, рассчитывать стоимость инфраструктуры под проект, что значительно ускорило процесс согласования.

Чтобы получить готовое к работе частное облако, нужно пройти как минимум 10 шагов.

Какие этапы надо пройти, чтобы внедрить частное облако

Работа над проектом Х5 Retail Group до приема в эксплуатацию заняла у нас около трех месяцев: два месяца на установку и месяц на основные кастомные интеграции. На этом работа еще не закончена, мы делаем дальнейшие кастомизации. Но остальные доработки это уже работа на эксплуатируемой инфраструктуре.

Вот из каких этапов состоит процесс внедрения частного облака:

1. Определяем бизнес-задачи первый шаг с нашей стороны: понять, что нужно бизнесу от облака, от этого зависят дальнейшие действия.
2. Определяем ограничения они могут быть по технологиям, которые компания может использовать или нет, по информационной безопасности и по бюджету.
3. Разрабатываем общую архитектуру решения из каких компонентов будет состоять, какие сервисы будут использованы.
4. Выясняем специфику реализации сервисов сетевая архитектура, потребность в информационной безопасности.
5. Прорабатываем интеграции по архитектуре интеграция состоит из двух частей: на стороне облака и на стороне целевой корпоративной системы. Здесь большая часть связана с ролевыми моделями и правами пользователей.
6. Составляем финансовую модель биллинг, что и как считается, как это учитывать при планировании проектов.
7. Устанавливаем и настраиваем оборудование подготовка инфраструктуры для облака. В отличие от многих провайдеров мы можем развернуть облако на оборудовании клиента, если оно подходит по параметрам. Это позволяет переиспользовать оборудование, которое освобождается после ухода от традиционной инфраструктуры.
8. Реализуем кастомные доработки и разворачиваем решение тут, как правило, проявляется все, что не учли на предыдущих этапах, вплоть до возврата назад и переработки архитектуры решения.
9. Проходим приемо-сдаточные испытания (ПСИ) решения и вводим его в эксплуатацию.
10. Дорабатываем в процессе использования.

Далее расскажу про некоторые этапы подробнее. Начнем с того, как мы вместе с Х5 готовили инфраструктуру к внедрению нашей облачной платформы.

Как мы с Х5 готовились к внедрению частного облака

На этапе пресейла мы либо получаем от клиента готовое ТЗ, либо выясняем, какие у него потребности, чтобы формализовать их в рамках ТЗ. Уточняется, какая инфраструктура в наличии, какое подходящее оборудование уже есть от старой инфраструктуры, что нужно дозакупить или поставить. Вместе с клиентом рисуем Best Practice-инфраструктуру. После чего все требования формализуются в рамках ТЗ, из которого выписывается ЧТЗ частное техническое задание, то есть как будет выглядеть реализация по ТЗ.

Когда мы все согласовали и подписали контракт, начинается этап предподготовки инфраструктуры, которым занимаемся мы или клиент по нашим требованиям. В последнем случае мы тесно взаимодействуем с командой компании, как это было на проекте Х5.

Инженеры Х5 Retail Group готовили оборудование, проводили необходимую коммутацию, настраивали сеть, создавали структуры в AD, DNS, предустанавливали операционные системы под гипервизоры, выдавали деплой-ноды, создавали необходимые технические учетные записи, согласовывали доступы, настраивали интеграцию с системами ИБ, проводили кастомизацию портала самообслуживания платформы.

Команда инженеров Х5 очень оперативно сработала и создала окружение, в котором могло работать наше решение. Примерно за две недели они подготовили инфраструктуру для начала деплоя.

Теперь мы могли приступить к развертыванию нашей платформы.

Как происходило развертывание приватного облака

После того как команда Х5 подготовила инфраструктуру, в дело вступили наши инженеры.

Процесс развертывания выглядит так:

1. Сначала мы создаем деплой-ноду это нода, с которой устанавливается все остальное облако и распределяются роли по всем остальным серверам и серверам хранения.
2. Затем начинается деплой IaaS-части, которая позволяет запускать виртуальные машины: она включает менеджмент, гипервизоры, подсистемы хранения.
3. Поверх нее разворачиваем PaaS: Kubernetes, базы данных, большие данные в зависимости от требования клиента по ТЗ какие-то сервисы могут быть не нужны. В Х5 мы разворачивали Kubernetes aaS и облачные СУБД.

Сейчас у нас идет речь о модульном подходе: все компоненты готовы, отработаны на публичном облаке и мы можем их передать клиенту. Такая работа по деплою IaaS и PaaS заняла у нас 45 недель.

При этом, как правило, мы не можем развернуть наши готовые сервисы в том виде, в котором они используются в публичном облаке. Их нужно доработать под потребности клиента, а это непростая задача.

Как мы дорабатываем PaaS под требования клиента

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

Например, у нас есть готовый запакованный сервис баз данных, который мы можем просто поставить, но внутренняя служба DB, отвечающая за эксплуатацию баз данных, просит соблюдать корпоративные стандарты. База данных должна автоматически регистрироваться в Zabbix, должен быть организован доступ для инженеров компании, на нее нужно поставить специальные версии и использовать внутренние репозитории. В этом случае наша команда PaaS полностью пересобирает исходные образы согласно требованиям это нетривиальная работа.

Другой яркий пример: PaaS при скачивании репозиториев используют наши сервисные сети, которые связаны с интернетом. В большинстве приватных облаков интернета нет, поэтому приходится переделывать сервисы так, чтобы они обращались к внутренним репозиториям. При этом надо поддерживать и обеспечивать внутренний репозиторий актуальными версиями.

К Kubernetes как сервису могут быть разные требования со стороны клиентов. Например, заранее прописанный Docker Registry или устаревшая версия Kubernetes: в публичном облаке самая младшая версия 16, можно взять 14, если компания ее использует. Для Х5 мы серьезно переделали KaaS, что было связано с особенностями топологии сети частного облака.

Такие требования к кастомизации PaaS возникают почти всегда. Когда клиент берет сервис в приватное облако, он может попросить добавить любые опции в соответствии с корпоративными требованиями.

И это не единственные доработки нашей платформы: кроме доработки PaaS, требуются и другие кастомные интеграции, которые приходится реализовать.

Какие кастомные интеграции облачной платформы необходимы для On-premises

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

Я уже говорил, что требования корпоративных клиентов редко совпадают с коробочным решением. На этом этапе мы проводим интеграции с существующими ITSM-процессами и технологиями компании: попадание виртуальных машин в DNS, интеграция с AD, кастомная пересборка образов для авторизации через их AD, кастомная сборка образов под базы данных, интеграция с CMDB, S3-хранилищем, настройка резервного копирования на наш менеджмент.

Такие интеграции отличаются у разных клиентов это кастомная работа, автоматизировать ее в большинстве случаев нельзя. В случае Х5 Retail Group также были существующие системы типа AD, CMDB, DNS и так далее, со всем этим пришлось интегрироваться.

Также был запрос по работе биллинга: публичное облако заточено под мультитенантную модель, а приватные облака сделаны так, что один отдел отвечает за утилизацию облака; нужны были специальные типовые отчеты сразу по всем тенантам, то есть проектам. Из-за этого пришлось дописывать кусок биллинга, который бы учитывал требования. То же самое связано с некоторыми лицензиями сторонних вендоров: наш биллинг заточен на одни лицензии, в Х5 используют свои виды лицензий, пришлось эту логику также переделать.

Интеграцию команда Х5 делала по принципу вызовов через API: на нашей платформе для интеграции делается вызов по определенному формату, дальше обработку вызова и реализацию специалисты компании реализуют самостоятельно, что позволяет им использовать нужные сервисы более гибко.

Эти кастомные доработки стандартные и не слишком сложные, однако на любом проекте возникают настоящие вызовы. В Х5 Retail Group таким вызовом для нас стала переделка всей сетевой топологии, частично затронувшая PaaS.

Самое сложное: переделка сетевой топологии

Для Х5 Retail Group нам пришлось переделывать всю сетевую топологию приватного облака на лету это катастрофически сложная кастомизация. В компании сеть сделана по энтерпрайз-формату, архитектура такой сети не вполне совместима с инсталляцией публичного облака.

В публичном облаке используется топология сети, позволяющая применять internal-сети внутри проектов и публикации в интернете через external-сеть, используя для этого floating IP (белые адреса).

В приватном облаке сеть выглядит иначе: она плоская, поделена на сегменты, которых нет в публичном облаке, архитектурно реализована по-другому. Любая виртуальная машина сразу попадает во Vlan, нет никаких floating IP и серых адресов, есть только блок плоских адресов.

Из-за этой топологии нам пришлось переделывать половину сервисов и половину фронта. Исчезло такое понятие, как виртуальный роутер, пришлось переделывать логику работы балансировщика как сервиса, исключать некоторые сервисы типа VPN и так далее. То есть такая простая вещь, как переделка топологии сети, повлекла за собой переделку почти половины сервисов внутри облака.

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

С сетевой топологией была связана и самая большая переделка нашего Kubernetes aaS. По дефолту мы создавали его во внутренних сетях с балансировкой через наш балансировщик в публичном облаке MCS, имеющий выход во внешнюю сеть. Пришлось переделать всю логику работы, потому что Kubernetes надо было создавать в плоской сети и завязывать работу балансировщика, находящегося в частной сети.

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

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

Как мы выполнили требования информационной безопасности клиента

Приватное облако в Х5 отчасти выбрали из-за внутренних правил ИБ. Для компании мы выполнили интеграцию с ArcSight. Это SIEM-система: управление информацией о безопасности и событиями о безопасности. Все действия, которые происходят в инфраструктуре, должны регистрироваться в ней.

Например, произошел ресайз или удаление виртуальной машины SIEM фиксирует, во сколько была удалена ВМ и каким пользователем. Такую интеграцию с ArcSight используют многие клиенты. Некоторые используют другие SIEM-системы, но у всех крупных компаний они есть.

Также мы настраивали EFK и Zabbix это базовые системы, их ставим всегда, но в этом случае накатывали не наши стандартные, а специальные шаблоны, которые требовали наши коллеги. Они покрывают более широкий охват того, что должно логироваться и мониториться.

Также сотрудники службы безопасности Х5 провели несколько раундов пентестов нашей информационной системы проверяли, как и с помощью каких обходных решений можно проникнуть в нее, какие версии ПО используются, какие порты открыты и так далее. После этого обновили все доступы по двухфакторной авторизации.

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

В проверки ПМИ входят тесты: высокая доступность (High Availability, HA), тесты отказоустойчивости, стресс-тесты выхода той или иной ноды или группы узлов, при которых все должно сохранить рабочее состояние. HA достаточно капризная, ее нам приходится долго и тонко настраивать с учетом всех кастомизаций.

Эти процессы заняли у нас много времени: месяц подготовки и проверок, потом доработки и устранение замечаний. В итоге через 2 месяца смогли предложить Х5 Retail Group решение, которое компания смогла взять в эксплуатацию, часть улучшений еще находится в процессе доработки.

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

Технологические ограничения, которые пришлось учесть в процессе внедрения

Технологические ограничения в проекте для Х5 Retail Group были разнообразные, расскажу про пару примеров.

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

Также в инфраструктуре Х5 есть ограничения по количеству используемых сетей, так как нет приватных сетей и создание любого сервиса приводит к созданию новых сетевых портов. Сильно утилизируется сеть, периодически кончаются адреса, внутренняя команда вынуждена расширять сеть либо вычищать порты.

Такие некритичные ограничения достаточно легко преодолеваются, но требуют времени, экспертности и совместной работы команд.

Итоги

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

Что еще почитать:

1. Как реализуется отказоустойчивая веб-архитектура в платформе Mail.ru Cloud Solutions.
2. Как выбрать облачную систему хранения данных, чтобы получить лучшую производительность и оптимизировать стоимость.
3. Наш телеграм-канал об IT-бизнесе и цифровой трансформации.

Как было раньше

• Изменить визуальный стиль главной страницы, опираясь на новую дизайн систему Mail.ru;
• Сделать доступ ко всем сервисам удобным и быстрым;
• Добавить навигации по странице развлекательный характер за счет индивидуальных рекомендаций материалов и способов их оформления;
• Сохранить видимость всех продуктов и учесть интересы тех, на которые пользователи чаще всего переходят с главной страницы Почты,Поиска и Новостей;
• Адаптировать изменения под устройства с маленькими экранами, чтобы каждому пользователю было комфортно.

С чего начали

Изменение UX страницы

• Поиск разместили сверху, так как он означает начало изучения страницы, и такое расположение в целом более привычное для пользователя;
• Почту расположили под Поиском в виде виджета, чтобы человек не тянулся постоянно наверх. В дальнейшем мы будем выводить не только виджет Почты, но и календарь, Облако и социальные сети. Так пользователь сможет быстро и удобно переключаться между задачами и продуктами. Ниже расположили основную информацию на день: погоду, котировки и новости;
• В процессе работы Погоду и котировки мы меняли местами с виджетом Почты. По итогам тестирования выбрали вариант, когда погода была ниже и не разделяла Поиск и Почту. Поменяли расположение рекламы;
• Убрали акцентный цвет и сделали страницу максимально чистой.

• Наверху расположен навигационный блок с меню, геолокацией и профилем;
• Поиск выше Почты, а Погода рядом с Новостями;
• Меньше акцентного цвета (синими остались только логотип и Поиск).

Финальные штрихи

Как новая главная живет и процветает

Мы всегда раскатываем обновление постепенно, чтобы не сломать привычные сценарии пользователей. Пользователи положительно воспринимали новый дизайн, что подтвердил рост конверсии и переходов, говорит Вячеслав Яшков.

• +12% к переходам на медиапроекты, включая погоду и ковид;
• +4% к переходам в Поиск;
• +5% к переходам в Почту.

• Алена Китабова менеджер продукта.
• Вячеслав Яшков руководитель команды дизайна Search & AI.
• Елена Джуга дизайнер Search & AI.
• Игорь Фролов руководитель группы frontend-разработки главной страницы и портальной навигации.
• Владимир Францкевич программист группы frontend-разработки главной.
• Денис Стасьев младший программист группы frontend-разработки главной.
• Александр Буки программист группы frontend-разработки главной.
• Анастасия Краснова ведущий инженер по тестированию.

Как работают файберы?

final class Fiber{    public function __construct(callable $callback) {}    public function start(mixed ...$args): mixed {}    public function resume(mixed $value = null): mixed {}    public function throw(Throwable $exception): mixed {}    public function isStarted(): bool {}    public function isSuspended(): bool {}    public function isRunning(): bool {}    public function isTerminated(): bool {}    public function getReturn(): mixed {}    public static function this(): ?self {}    public static function suspend(mixed $value = null): mixed {}}

$fiber = new Fiber(function() : void {  echo "I'm running a Fiber, yay!";});$fiber->start(); // I'm running a Fiber, yay!

$fiber = new Fiber(function() : void {  Fiber::suspend();  echo "I'm running a Fiber, yay!";});$fiber->start(); // [Nothing happens]

$fiber = new Fiber(function() : void {   Fiber::suspend();   echo "I'm running a Fiber, yay!";});$fiber->start(); // [Nothing happened]$fiber->resume(); // I'm running a Fiber, yay!

• Метод start() передаёт аргументы вызываемому объекту и возвращает всё, что принимает метод suspend().
• Метод suspend() возвращает любое значение, которое принял метод resume().
• Метод resume() возвращает всё, что принято при следующем вызове suspend().

• resume() используется для помещения в файбер значений, принятых suspend(),
• а suspend() используется для отправки значений, принятых resume().

$fiber = new Fiber(function (): void {    $value = Fiber::suspend('fiber');    echo "Value used to resume fiber: ", $value, "\n";});$value = $fiber->start();echo "Value from fiber suspending: ", $value, "\n";$fiber->resume('test');

Value from fiber suspending: fiberValue used to resume fiber: test

Скоро у нас будет свой полноценный веб-сервер

Вы не будете пользоваться файберами напрямую

По одному файберу за раз

Поскольку одновременно может выполняться только один файбер, у вас не возникнет чего-то вроде состояния гонки, когда к памяти обращается сразу два потока.

При этом никаких каналов

Новичок на районе

names := make(chan string)go doFoo(names)go doBar(names)

int g(int);int f(int x) {    __attribute__((musttail)) return g(x);}

Основы хвостовых вызовов

Проблема с циклами интерпретатора

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

Улучшаем циклы интерпретатора с помощью хвостовых вызовов

#include <stdint.h>#include <stddef.h>#include <string.h>typedef void *upb_msg;struct upb_decstate;typedef struct upb_decstate upb_decstate;// The standard set of arguments passed to each parsing function.// Thanks to x86-64 calling conventions, these will be passed in registers.#define UPB_PARSE_PARAMS                                          \  upb_decstate *d, const char *ptr, upb_msg *msg, intptr_t table, \      uint64_t hasbits, uint64_t data#define UPB_PARSE_ARGS d, ptr, msg, table, hasbits, data#define UNLIKELY(x) __builtin_expect(x, 0)#define MUSTTAIL __attribute__((musttail))const char *fallback(UPB_PARSE_PARAMS);const char *dispatch(UPB_PARSE_PARAMS);// Code to parse a 4-byte fixed field that uses a 1-byte tag (field 1-15).const char *upb_pf32_1bt(UPB_PARSE_PARAMS) {  // Decode "data", which contains information about this field.  uint8_t hasbit_index = data >> 24;  size_t ofs = data >> 48;  if (UNLIKELY(data & 0xff)) {    // Wire type mismatch (the dispatch function xor's the expected wire type    // with the actual wire type, so data & 0xff == 0 indicates a match).    MUSTTAIL return fallback(UPB_PARSE_ARGS);  }  ptr += 1;  // Advance past tag.  // Store data to message.  hasbits |= 1ull << hasbit_index;  memcpy((char*)msg + ofs, ptr, 4);  ptr += 4;  // Advance past data.  // Call dispatch function, which will read the next tag and branch to the  // correct field parser function.  MUSTTAIL return dispatch(UPB_PARSE_ARGS);}

upb_pf32_1bt:                           # @upb_pf32_1bt        mov     rax, r9        shr     rax, 24        bts     r8, rax        test    r9b, r9b        jne     .LBB0_1        mov     r10, r9        shr     r10, 48        mov     eax, dword ptr [rsi + 1]        mov     dword ptr [rdx + r10], eax        add     rsi, 5        jmp     dispatch                        # TAILCALL.LBB0_1:        jmp     fallback                        # TAILCALL

#define PARAMS unsigned RA, void *table, unsigned inst, \               int *op_p, double *consts, double *regs#define ARGS RA, table, inst, op_p, consts, regstypedef void (*op_func)(PARAMS);void fallback(PARAMS);#define UNLIKELY(x) __builtin_expect(x, 0)#define MUSTTAIL __attribute__((musttail))void ADDVN(PARAMS) {    op_func *op_table = table;    unsigned RC = inst & 0xff;    unsigned RB = (inst >> 8) & 0xff;    unsigned type;    memcpy(&type, (char*)&regs[RB] + 4, 4);    if (UNLIKELY(type > -13)) {        return fallback(ARGS);    }    regs[RA] += consts[RC];    inst = *op_p++;    unsigned op = inst & 0xff;    RA = (inst >> 8) & 0xff;    inst >>= 16;    MUSTTAIL return op_table[op](ARGS);}

ADDVN:                                  # @ADDVN        movzx   eax, dh        cmp     dword ptr [r9 + 8*rax + 4], -12        jae     .LBB0_1        movzx   eax, dl        movsd   xmm0, qword ptr [r8 + 8*rax]    # xmm0 = mem[0],zero        mov     eax, edi        addsd   xmm0, qword ptr [r9 + 8*rax]        movsd   qword ptr [r9 + 8*rax], xmm0        mov     edx, dword ptr [rcx]        add     rcx, 4        movzx   eax, dl        movzx   edi, dh        shr     edx, 16        mov     rax, qword ptr [rsi + 8*rax]        jmp     rax                             # TAILCALL.LBB0_1:        jmp     fallback

Ограничения

#define PARAMS unsigned RA, void *table, unsigned inst, \               int *op_p, double *consts, double *regs#define ARGS RA, table, inst, op_p, consts, regstypedef void (*op_func)(PARAMS);void fallback(PARAMS);#define UNLIKELY(x) __builtin_expect(x, 0)#define MUSTTAIL __attribute__((musttail))void ADDVN(PARAMS) {    op_func *op_table = table;    unsigned RC = inst & 0xff;    unsigned RB = (inst >> 8) & 0xff;    unsigned type;    memcpy(&type, (char*)&regs[RB] + 4, 4);    if (UNLIKELY(type > -13)) {        // When we leave off "return", things get real bad.        fallback(ARGS);    }    regs[RA] += consts[RC];    inst = *op_p++;    unsigned op = inst & 0xff;    RA = (inst >> 8) & 0xff;    inst >>= 16;    MUSTTAIL return op_table[op](ARGS);}

ADDVN:                                  # @ADDVN        push    rbp        push    r15        push    r14        push    r13        push    r12        push    rbx        push    rax        mov     r15, r9        mov     r14, r8        mov     rbx, rcx        mov     r12, rsi        mov     ebp, edi        movzx   eax, dh        cmp     dword ptr [r9 + 8*rax + 4], -12        jae     .LBB0_1.LBB0_2:        movzx   eax, dl        movsd   xmm0, qword ptr [r14 + 8*rax]   # xmm0 = mem[0],zero        mov     eax, ebp        addsd   xmm0, qword ptr [r15 + 8*rax]        movsd   qword ptr [r15 + 8*rax], xmm0        mov     edx, dword ptr [rbx]        add     rbx, 4        movzx   eax, dl        movzx   edi, dh        shr     edx, 16        mov     rax, qword ptr [r12 + 8*rax]        mov     rsi, r12        mov     rcx, rbx        mov     r8, r14        mov     r9, r15        add     rsp, 8        pop     rbx        pop     r12        pop     r13        pop     r14        pop     r15        pop     rbp        jmp     rax                             # TAILCALL.LBB0_1:        mov     edi, ebp        mov     rsi, r12        mov     r13d, edx        mov     rcx, rbx        mov     r8, r14        mov     r9, r15        call    fallback        mov     edx, r13d        jmp     .LBB0_2

TeamUP Online как найти лучшую команду

Умные визуальные эффекты к фотографиям

Сервис Рабочее место

• Телеграм-бот ассистент для календаря Mail.ru
• Ежедневник для самозанятых
• Конструктор системы лояльности для кафе
• Мобильное приложение для взаимодействия клиента с кафе/рестораном
• Платформа для ведения спортивных чемпионатов
• Приложение для заказа еды из столовых МГТУ.

• Фитнес-приложение для создания персональных тренировок
• Приложение учета и мониторинга районной инфраструктуры, сохранения памятников наследия и улучшения благосостояния города.

Бизнес-модель работы Delivery Club

• ДДК (доставка Деливери Клаб): мы передаем заказ в ресторан и доставляем его клиенту, то есть ресторану остается только приготовить заказ к определенному времени, когда придет курьер.
• МП (маркетплейс): мы передаем заказ в ресторан, а он своими силами доставляет заказ в пределах своей согласованной зоны.

Рисуем зону доставки ресторана

Как процесс выглядел раньше

Проблемы ручной отрисовки зон:

• непостоянство результата;
• непрозрачная логика;
• субъективизм в принятии решений о форме зоны и ее характеристиках;
• однообразный подход без учета индивидуальных особенностей партнера;
• крайне низкая скорость построения зон;
• ручной труд менеджеров;
• отсутствие гибкости в управлении характеристиками зон доставки (зона представляла собой единую нераздельную сущность, внутри которой нельзя было установить разную стоимость доставки в зависимости от расстояния между клиентом и рестораном).

Baseline

• артефакты в зонах доставки (стандартный случай с переходом через реку);
• единообразный подход к партнерам (не учитываются индивидуальные KPI партнеров).

Преимущества технологии H3

1. Существует хорошая библиотека для работы с H3, которую и выбрала наша команда в качестве основного инструмента. Библиотека поддерживает многие языки программирования (Python, Go и другие), в которых уже реализованы основные функции для работы с гексагонами.
2. Наша реляционная аналитическая база Postgres поддерживает работу с нативными функциями H3.
3. При использовании гексагональной сетки благодаря ряду алгоритмов, работающих с индексами, можно очень быстро получить точную информацию о признаках в соседних ячейках, например, определить вхождение точки в гексагон.
4. Преимуществом гексагонов является возможность хранить информацию о признаках не только в конкретных точках, но и в целых областях.

Алгоритм построения зон доставки

1. Вокруг ресторана строим лучи, вдоль которых создаем набор точек, а затем с помощью маршрутизатора рассчитываем расстояние от ресторана до каждой из точек.
   
   
   
   
   
2. Убираем точки-выбросы. Анализируем все постройки и сразу отбрасываем те, которые нас не интересуют. Например, какие-то мелкие нежилые объекты. Далее с помощью DBSCAN формируем кластеры точек и отбрасываем те, которые для нас не являются важными: например, если кластер находится далеко от ресторана или нам экономически невыгодно доставлять туда.
   
   
   
   
   
3. Далее на основе очищенного набора точек применяем триангуляцию Делоне.
   
   
   
   
   
4. Создаем сетку гексагонов H3.
   
   
   
   
   
5. Определяем, к какому треугольнику принадлежит каждый гексагон H3, и для этого гексагона определяем расстояние от ресторана с помощью аппроксимации по трем вершинам треугольника (кто хочет чуть больше разобраться в геоматематике и понять рациональность использования тех или иных геоформ, вот ссылка на оригинал статьи Uber).
   
   
   
   
   
6. Далее оптимизируем функцию ошибки, которая зависит от нашей задачи, постепенно удаляя с внешней стороны зоны по одному гексагону. При этом мы следим за формой нашей зоны, она должна оставаться цельной.
   
   
   
   
   
   В текущей версии алгоритма мы используем следующие функции ошибок:
   
   
   • минимизацию времени доставки при фиксированном покрытии;
   • максимизацию охвата пользователей при фиксированном времени доставки.
   
   Пример функции ошибки для минимизации времени доставки:
   

   

   
   где функция ошибки минимизации времени доставки с фиксированным покрытием,
   время от ресторана i до клиента,
   количество клиентов в зоне доставки.
   
   
7. Далее строим временной градиент в получившихся зонах (с очищенными выбросами) и с заранее определенными интервалами (например, по 10-минутным отрезкам пешего пути).
   
   
   
   
   

Внедрение

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

Оценка

Текущая ситуация и планы

Для чего замедлять старение?

Голые землекопы

Кровь молодых и мёртвых

Анализ данных

Возраст и ЗОЖ

Перенаселение и социум

Как попасть в отрасль?

Прогноз на будущее

Интересные ссылки

• Черви-сверхдолгожители помогли ученым найти препараты от старости среди аптечных лекарств
• Публикации по долголетию на сайте Gero

Патчим libc с помощью /proc/self/mem

#include <fstream>#include <iostream>#include <sys/mman.h>/* Write @len bytes at @ptr to @addr in this address space using * /proc/self/mem. */void memwrite(void *addr, char *ptr, size_t len) {  std::ofstream ff("/proc/self/mem");  ff.seekp(reinterpret_cast<size_t>(addr));  ff.write(ptr, len);  ff.flush();}int main(int argc, char **argv) {  // Map an unwritable page. (read-only)  auto mymap =      (int *)mmap(NULL, 0x9000,                  PROT_READ, // <<<<<<<<<<<<<<<<<<<<< READ ONLY <<<<<<<<                  MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);  if (mymap == MAP_FAILED) {    std::cout << "FAILED\n";    return 1;  }  std::cout << "Allocated PROT_READ only memory: " << mymap << "\n";  getchar();  // Try to write to the unwritable page.  memwrite(mymap, "\x40\x41\x41\x41", 4);  std::cout << "did mymap[0] = 0x41414140 via proc self mem..";  getchar();  std::cout << "mymap[0] = 0x" << std::hex << mymap[0] << "\n";  getchar();  // Try to writ to the text segment (executable code) of libc.  auto getchar_ptr = (char *)getchar;  memwrite(getchar_ptr, "\xcc", 1);  // Run the libc function whose code we modified. If the write worked,  // we will get a SIGTRAP when the 0xcc executes.  getchar();}

Оборудование

Защита от записи (16-й бит CR0). Если задана, он не даёт процедурам уровня супервизора записывать в защищённые от записи страницы. Если бит пуст, то процедуры уровня супервизора могут записывать в защищённые от записи страницы (вне зависимости от настроек бита U/S; см. раздел 4.1.3 и 4.6).

Как работает /proc/*/mem

• Вызывает get_user_pages_remote(), чтобы найти физический фрейм, соответствующий целевому виртуальному адресу.
• Вызывает kmap(), чтобы пометить этот фрейм доступный для записи в виртуальном адресном пространстве ядра.
• Вызывает copy_to_user_page() для финального выполнения операций записи.

static int check_vma_flags(struct vm_area_struct *vma, unsigned long gup_flags){        [...]        if (write) { // If performing a write..                if (!(vm_flags & VM_WRITE)) { // And the page is unwritable..                        if (!(gup_flags & FOLL_FORCE)) // *Unless* FOLL_FORCE..                                return -EFAULT; // Return an error        [...]        return 0; // Otherwise, proceed with lookup}

Обсуждение

Заключение

Для чего они нужны и как устроены

Применение

Рекомендательные системы

Комбинаторная оптимизация

Компьютерное зрение

Физика и химия

Разработка лекарств

Когда графовые нейросети стали трендом

Являются ли они трендом и в России тоже

Мимолетная или долгосрочная тенденция?

Структура памяти JVM

Куча (heap)

• Молодое поколение, или новое пространство: область, в которой живут новые объекты. Она делится на рай (Eden Space) и область выживших (Survivor Space). Областью молодого поколения управляет младший сборщик мусора (Minor GC), который также называют молодым (Young GC).
  
  • Рай: здесь выделяется память, когда мы создаём новые объекты.
  • Область выживших: здесь хранятся объекты, которые остались после работы младшего сборщика мусора. Область делится на две половины, S0 и S1.
• Старое поколение, или хранилище (Tenured Space): сюда попадают объекты, которые достигли максимального порога хранения в ходе жизни младшего сборщика мусора. Этим пространством управляет старший сборщик (Major GC).

Стеки потоков исполнения

Метапространство

Кеш кода

Общие библиотеки

Использование памяти JVM: стек и куча

class Employee {    String name;    Integer salary;    Integer sales;    Integer bonus;    public Employee(String name, Integer salary, Integer sales) {        this.name = name;        this.salary = salary;        this.sales = sales;    }}public class Test {    static int BONUS_PERCENTAGE = 10;    static int getBonusPercentage(int salary) {        int percentage = salary * BONUS_PERCENTAGE / 100;        return percentage;    }    static int findEmployeeBonus(int salary, int noOfSales) {        int bonusPercentage = getBonusPercentage(salary);        int bonus = bonusPercentage * noOfSales;        return bonus;    }    public static void main(String[] args) {        Employee john = new Employee("John", 5000, 5);        john.bonus = findEmployeeBonus(john.salary, john.sales);        System.out.println(john.bonus);    }}

• Каждый вызов функции добавляется в стек потока исполнения в качестве фреймового блока.
• Все локальные переменные, включая аргументы и возвращаемые значения, сохраняются в стеке внутри фреймовых блоков функций.
• Все примитивные типы вроде int хранятся прямо в стеке.
• Все типы объектов вроде Employee, Integer или String создаются в куче, а затем на них ссылаются с помощью стековых указателей. Это верно и для статичных данных.
• Функции, которые вызываются из текущей функции, попадают наверх стека.
• Когда функция возвращает данные, её фрейм удаляется из стека.
• После завершения основного процесса объекты в куче больше не имеют стековых указателей и становятся потерянными (сиротами).
• Пока вы явно не сделаете копию, все ссылки на объекты внутри других объектов делаются с помощью указателей.

Управление памятью JVM: сборка мусора

• Получение памяти от ОС и возвращение её ОС.
• Передачу выделенной памяти приложению по его запросу.
• Определение, какие части выделенной памяти ещё используются приложением.
• Затребование неиспользованной памяти для использования приложением.

Сборщик мусора Mark & Sweep

• Разметка: сначала сборщик определяет, какие объекты используются, а какие нет. Те, что используются или доступны для стековых указателей, рекурсивно помечаются как живые.
• Удаление: сборщик проходит по куче и убирает все объекты, которые не помечены как живые. Эти места в памяти помечаются как свободные.
• Сжатие: после удаления неиспользуемых объектов все выжившие объекты перемещают, чтобы они были вместе. Это уменьшает фрагментацию и повышает скорость выделения памяти для новых объектов.

• Пропускная способность: время, затраченное на сборку мусора, а не работу приложения. В идеале, пропускная способность должна быть высокой, то есть паузы на сборку мусора короткие.
• Длительность пауз: насколько долго сборщик мусора мешает исполнению приложения. В идеале, паузы должны быть очень короткими.
• Размер кучи: в идеале, должен быть маленьким.

Сборщики в JDK 11

• Серийный сборщик: использует один поток, эффективен для приложений с небольшим количеством данных, наиболее удобен для однопроцессорных машин. Его можно выбрать с помощью -XX:+UseSerialGC.
• Параллельный сборщик: нацелен на высокую пропускную способность и использует несколько потоков, чтобы ускорить процесс сборки. Предназначен для приложений со средним или большим количеством данных, исполняемых на многопоточном/многопроцессорном оборудовании. Его можно выбрать с помощью -XX:+UseParallelGC.
• Сборщик Garbage-First (G1): работает по большей части многопоточно (то есть многопоточно выполняются только объёмные задачи). Предназначен для многопроцессорных машин с большим объёмом памяти, по умолчанию используется на большинстве современных компьютеров и ОС. Нацелен на короткие паузы и высокую пропускную способность. Его можно выбрать с помощью -XX:+UseG1GC.
• Сборщик Z: новый, экспериментальный, появился в JDK11. Это масштабируемый сборщик с низкой задержкой. Многопоточный и не останавливает исполнение потоков приложения, то есть не относится к stop-the-world. Предназначен для приложений, которым необходима низкая задержка и/или очень большая куча (на несколько терабайтов). го можно выбрать с помощью -XX:+UseZGC.

Процесс сборки мусора

Младший сборщик

1. Допустим, в раю уже есть объекты (блоки с 01 по 06 помечены как используемые).
2. Приложение создаёт новый объект (07).
3. JVM пытается получить необходимую память в раю, но там уже нет места для размещения нового объекта, поэтому JVM запускает младший сборщик.
4. Он рекурсивно проходит по графу объектов начиная со стековых указателей и помечает используемые объекты как (используемая память), остальные как мусор (потерянные).
5. JVM случайно выбирает один блок из S0 и S1 в качестве целевого пространства (To Space), пусть это будет S0. Теперь сборщик перемещает все живые объекты в целевое пространство, которое было пустым, когда мы начали работу, и повышает их возраст на единицу.
6. Затем сборщик очищает рай, и в нём выделяется память для нового объекта.
7. Допустим, прошло какое-то время, и в раю стало больше объектов (блоки с 07 по 13 помечены как используемые).
8. Приложение создаёт новый объект (14).
9. JVM пытается получить в раю нужную память, но там нет свободного места для нового объекта, поэтому JVM снова запускает младший сборщик.
10. Повторяется этап разметки, который охватывает и те объекты, что находятся в пространстве выживших в целевом пространстве.
11. Теперь JVM выбирает в качестве целевого свободный блок S1, а S0 становится исходным. Сборщик перемещает все живые объекты из рая и исходного в целевое (S1), которое было пустым, и повысил возраст объектов на единицу. Поскольку некоторые объекты сюда не поместились, сборщик переносит их в хранилище, ведь область выживших не может увеличиваться, и этот процесс называют преждевременным продвижением (premature promotion). Такое может происходить, даже если свободна одна из областей выживших.
12. Теперь сборщик очищает рай и исходное пространство (S0), а новый объект размещается в раю.
13. Так повторяется при каждой сессии младшего сборщика, выжившие перемещаются между S0 и S1, а их возраст увеличивается. Когда он достигает заданного максимального порога, по умолчанию это 15, объект перемещается в хранилище.

Старший сборщик

• Разработчик вызывает в программе System.gc() или Runtime.getRunTime().gc().
• JVM решает, что в хранилище недостаточно памяти, потому что оно заполнено в результате прошлых сессий младшего сборщика.
• Если во время работы младшего сборщика JVM не может получить достаточно памяти в раю или области выживших.
• Если мы задали в JVM параметр MaxMetaspaceSize и для загрузки новых классов не хватает памяти.

1. Допустим, прошло уже много сессий младшего сборщика и хранилище почти заполнено. JVM решает запустить старший сборщик.
2. В хранилище он рекурсивно проходит по графу объектов начиная со стековых указателей и помечает используемые объекты как (используемая память), остальные как мусор (потерянные). Если старший сборщик запустили в ходе работы младшего сборщика, то его работа охватывает пространство молодого поколения (рай и область выживших) и хранилище.
3. Сборщик убирает все потерянные объекты и возвращает память.
4. Если в ходе работы старшего сборщика в куче не осталось объектов, JVM также возвращает память из метапространства, убирая из него загруженные классы, если это относится к полной сборке мусора.

Заключение

Ссылки

• docs.oracle.com
• pythontutor.com/java.html
• www.journaldev.com
• www.yourkit.com
• dzone.com
• www.infoq.com

С выходом Apache Spark 3.1 в марте 2021-го проект Spark on Kubernetes официально перешел в статус общедоступного и готового к эксплуатации. Это стало результатом трехлетней работы быстрорастущего сообщества, участники которого помогали в разработке и внедрении (изначально поддержка Spark on Kubernetes появилась в Spark 2.3 в феврале 2018 года). Команда Kubernetes aaS от Mail.ru Cloud Solutions перевела самое важное из статьи об основных возможностях Spark 3.1, в которой автор подробно остановился на улучшениях в Spark on Kubernetes.

Полезные источники информации:

• Введение в использование Kubernetes в качестве менеджера ресурсов для Spark (вместо YARN): Pros & Cons of Running Spark on Kubernetes.
• Техническое руководство по успешной работе со Spark on Kubernetes: Setting Up, Managing & Monitoring Spark on Kubernetes.
• Про Data Mechanics: Spark on Kubernetes Made Easy: How Data Mechanics Improves On The Open-Source Version.

Путь Spark on Kubernetes: от бета-поддержки в 2.3 до нового стандарта в 3.1

С выходом Spark 2.3 в начале 2018 года Kubernetes стал новым диспетчером для Spark (помимо YARN, Mesos и автономного режима) в крупных компаниях, возглавляющих проект: RedHat, Palantir, Google, Bloomberg и Lyft. Сначала поддержка имела статус экспериментальной, функций было мало, стабильность и производительность были невысокими.

С тех пор сообщество проекта получило поддержку многочисленных крупных и маленьких компаний, которых заинтересовали преимущества Kubernetes:

1. Нативная контейнеризация. Упаковывайте зависимости (и сам Spark) с помощью Docker.
2. Эффективное совместное использование ресурсов и ускорение запуска приложений.
3. Обширная Open Source-экосистема уменьшает зависимость от облачных провайдеров и вендоров.

В проект было внесено несколько нововведений: от базовых требований вроде поддержки PySpark и R, клиентского режима и монтирования томов в версии 2.4 до мощных оптимизаций вроде динамического выделения (в 3.0) и улучшения обработки выключения нод (в 3.1). За последние три года вышло больше 500 патчей, сильно повысивших надежность и производительность Spark on Kubernetes.

График внесения улучшений в Spark с 2018 по 2021 годы

В результате в новых Spark-проектах в 2021 году Kubernetes все чаще рассматривается в роли стандартного менеджера ресурсов: это следует из популярности Open Source-проекта оператора Spark on Kubernetes и объявлений крупных вендоров, внедряющих Kubernetes вместо Hadoop YARN.

С выходом Spark 3.1 проект Spark on Kubernetes получил статус общедоступного и готового к эксплуатации. В этом релизе было внесено больше 70 исправлений и улучшений производительности. Давайте рассмотрим самые важные функции, которых с нетерпением ждали заказчики.

Улучшенная обработка выключения нод: постепенное отключение исполнителя (новая функция в Spark 3.1)

Эту функцию (SPARK-20624) реализовал Holden Karau, и пока что она доступна только для автономных развертываний и в Kubernetes. Называется функция улучшенная обработка выключения нод, хотя еще одно подходящее название постепенное отключение исполнителя (Graceful Executor Decommissioning).

Эта функция повышает надежность и производительность Spark при использовании Spot-нод (вытесняемые ноды в GCP). Перед остановкой спота с него перемещаются shuffle-данные и содержимое кэша, поэтому влияние на работу Spark-приложения оказывается минимальное. Раньше, когда система убивала спот, все shuffle-файлы терялись, поэтому их приходилось вычислять заново (снова выполнять потенциально очень долгие задачи). Новая фича не требует настройки внешнего shuffle-сервиса, для которого нужно по запросу запускать дорогие ноды хранения и который совместим с Kubernetes.

Новая функция Spark предотвращает внезапное уничтожение спотов и постепенно выключает исполнитель без потери драгоценных данных!

Что делает эта функция?

• Исполнитель, который нужно выключить, вносится в черный список: драйвер Spark не будет назначать ему новые задачи. Те задачи, которые сейчас исполняются, не будут принудительно прерваны, но если они сбоят из-за остановки исполнителя, то перезапустятся в другом исполнителе, как и сейчас, а их сбой не будет учитываться в максимальном количестве сбоев (новинка).
• Shuffle-файлы и кэшированные данные мигрируют из выключаемого исполнителя в другой. Если другого нет, например, мы выключаем единственный исполнитель, то можно настроить объектное хранилище (вроде S3) в качестве запасного.
• После завершения миграции исполнитель умирает, а Spark-приложение продолжает работать как ни в чем не бывало.

Когда работает эта функция?

• При использовании Spot / вытесняемых нод облачный провайдер уведомляет о выключении за 60120 секунд. Spark может использовать это время для сохранения важных shuffle-файлов. Этот механизм используется и в тех случаях, когда экземпляр на стороне провайдера по каким-то причинам выключают, допустим, при обслуживании EC2.
• Когда нода Kubernetes пустеет, например для технического обслуживания, или когда вытесняется под исполнителя Spark, например более высокоприоритетным подом.
• Когда убранный исполнитель является частью динамического выделения при уменьшении размера системы из-за простоя исполнителя. В этом случае тоже будут сохранены кэш и shuffle-файлы.

Как включить функцию?

• С помощью конфигурационных флагов. Нужно включить четыре основных флага Spark:

  
  
  • spark.decommission.enabled;
  • spark.storage.decommission.rddBlocks.enabled;
  • spark.storage.decommission.shuffleBlocks.enabled;
  • spark.storage.decommission.enabled.
  
  

  Другие доступные настройки рекомендую поискать прямо в исходном коде.

  
  

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

  
  

Новые опции с томами в Spark on Kubernetes

Начиная со Spark 2.4 при использовании Spark on Kubernetes можно монтировать три типа томов:

1. emptyDir: изначально пустая директория, существующая, пока работает под. Полезна для временного хранения. Можно поддерживать ее с помощью диска ноды, SSD или сетевого хранилища.
2. hostpath: в ваш под монтируется директория прямо из текущей ноды.
3. Заранее статически создаваемый PersistentVolumeClaim. Это Kubernetes-абстракция для разных типов персистентного хранилища. Пользователь должен создать PersistentVolumeClaim заранее, существование тома не привязано к поду.

В Spark 3.1 появилось два новых варианта: NFS и динамически создаваемый PersistentVolumeClaims.

NFS это том, который могут одновременно использовать несколько подов и который можно заранее наполнить данными. Это один из способов обмена информацией, кодом и конфигурациями между Spark-приложениями либо между драйвером и исполнителем внутри какого-нибудь Spark-приложения. В Kubernetes нет NFS-сервера, вы можете запустить его самостоятельно или использовать облачный сервис.

После создания NFS вы можете легко монтировать этот том в Spark-приложение с помощью таких настроек:

spark.kubernetes.driver.volumes.nfs.myshare.mount.path=/sharedspark.kubernetes.driver.volumes.nfs.myshare.mount.readOnly=falsespark.kubernetes.driver.volumes.nfs.myshare.options.server=nfs.example.comspark.kubernetes.driver.volumes.nfs.myshare.options.path=/storage/shared

NFS (Network File System) популярный способ обмена данными между любыми Spark-приложениями. Теперь он работает и поверх Kubernetes

Второй новый вариант динамический PVC. Это более удобный способ использования персистентных томов. Раньше нужно было сначала создавать PVC, а затем монтировать их. Но при использовании динамического выделения вы не знаете, сколько можно создать исполнителей в ходе работы вашего приложения, поэтому старый способ был неудобен. К тому же приходилось самостоятельно вычищать ненужные PersistentVolumeClaims либо смиряться с потерей места в хранилище.

Со Spark 3.1 все стало динамическим и автоматизированным. Когда вы инициализируете Spark-приложение или в ходе динамического выделения запрашиваете новые исполнители, в Kubernetes динамически создается PersistentVolumeClaims, который автоматически предоставляет новый PersistentVolumes запрошенного вами класса хранилища. При удалении пода ассоциированные с ним ресурсы автоматически удаляются.

Другие функции Spark 3.1: PySpark UX, стейджинговая диспетчеризация, повышение производительности

В Spark 3.1 появилось два крупных улучшения в UX для разработчиков на PySpark:

• Документация PySpark полностью переделана, теперь она больше соответствует Python и удобна для использования.
• Теперь поддерживаются подсказки типов: получение в IDE бесплатного автозавершения кода и обнаружения статических ошибок.

Автозавершение кода в PySpark с выходом Apache Spark 3.1

Spark History Server, который отображает интерфейс Spark после завершения вашего приложения, теперь может показывать статистику выполненных вами запросов на Structured Streaming.

Стейджинговая диспетчеризация (SPARK-27495) применима только для YARN- и Kubernetes-развертываний при включенном динамическом выделении. Она позволяет вам управлять в коде количеством и типом запрашиваемых для исполнителя ресурсов с точностью на уровне стадий. В частности, вы можете настроить приложение под использование исполнителей с процессорными ресурсами в ходе первой стадии (например, при выполнении ETL или подготовке данных), а в ходе второй стадии на использование видеокарт (скажем, для моделей машинного обучения).

В Spark 3.1 улучшили производительность shuffle хеш-соединения, добавили новые правила для прерывания подвыражений и в оптимизатор Catalyst. Для пользователей PySpark будет полезно то, что в Spark теперь применяется колоночный формат in-memory хранения Apache Arrow 2.0.0 вместо 1.0.2. Это повысит скорость работы приложений, особенно если вам нужно преобразовывать данные между Spark и фреймами данных Pandas. Причем все эти улучшения производительности не потребуют от вас менять код или конфигурацию.

Что еще почитать по теме:

1. Как и зачем разворачивать приложение на Apache Spark в Kubernetes.
2. Наш телеграм-канал Вокруг Kubernetes в Mail.ru Group.
3. MLOps без боли в облаке: как развернуть Kubeflow в production-кластере Kubernetes.

Идея самостоятельно развернуть кластер Kubernetes на собственных серверах или в облаке выглядит привлекательной: кажется, что это дешевле, чем платить за Managed-решение от провайдера. На самом деле все не так однозначно: на практике можно обнаружить скрытые расходы и подводные камни.

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

Я Дмитрий Лазаренко, директор по продукту облачной платформы Mail.ru Cloud Solutions (MCS). В статье расскажу, в чем особенности развертывания Self-Hosted-кластера Kubernetes и о чем нужно знать перед запуском.

Для старта понадобятся время, деньги и администраторы, разбирающиеся в Kubernetes

Первая статья расходов на специалистов, которые умеют работать с этой системой и смогут обслуживать кластер. Это дорогие ребята, на рынке их немного, и нанять трудно.

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

В реальности развернуть кластер только половина дела. В таком виде он будет работать до первой проблемы, которая неизбежно возникнет через неделю или месяц. Например, перестанут создаваться поды из-за неверной конфигурации ресурсов на controller-manager. Или кластер начнет работать нестабильно из-за проблем с дисками у etcd. Или запущенные СronJob из-за ошибок controller-manager начнут бесконечно плодить новые поды. Или в кластере будут возникать сетевые ошибки из-за неправильного выбора конфигурации DNS.

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

Кроме того, вместе с Kubernetes в компании появляются новые потребности, например мониторинг для выявления ошибок, система хранения данных, сбор логов. Кластер нужно развивать, чтобы получить от технологии ожидаемый профит. Это требует времени, поэтому даже опытному администратору не получится выделить неделю для настройки кластера и какие-то часы для администрирования.

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

Конечно, если запускать Kubernetes только ради деплоя контейнеров, то можно не разбираться и не развивать кластер. Но тогда возникает вопрос: зачем вам Kubernetes? Можно взять более простой в настройке и поддержке инструмент, тот же Docker Swarm. Если вы хотите от Kubernetes что-то простое, просто его не используйте. Нет смысла тратить время на развертывание кластера лишь ради запуска простого кода. Эта технология предназначена для проектов, где постоянно идет разработка, часто запускаются новые релизы и нужно выдерживать требования HighLoad.

По этой причине Self-Hosted Kubernetes в большинстве случаев могут успешно запустить только крупные компании, где есть возможность выделить сотрудников для обслуживания кластера и нет потребности экономить ресурсы.

Кроме того, самостоятельное развертывание кластера дело небыстрое. Если понадобится запустить кластер в короткие сроки для проекта или тестовых сред, то на Self-Hosted это не выйдет: развертывание займет несколько часов, а то и недель. К этому стоит быть готовыми. Для сравнения: в облаке вы запустите кластер KaaS за 10 минут и сможете сразу его использовать, но это получается потому, что над инфраструктурной частью уже заранее поработали специалисты провайдера.

Kubernetes требует прокачки: он не работает сам по себе

Как я уже говорил выше, Kubernetes отдельная экосистема, которой нужно заниматься и подключать к ней дополнительные инструменты. Если брать Self-Hosted, то все это придется делать самостоятельно.

Все инструменты, дополняющие Kubernetes, Open Source-решения, которые нужно настраивать. В кластер потребуется установить систему мониторинга, реализовать балансировку нагрузки, сбор и хранение логов, настройки безопасности и авторизации пользователей, сети и многое другое.

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

С логами аналогичная ситуация: из коробки вы получите только историю логов для уже запущенных приложений, при передеплое она исчезнет. Вручную собирать логи с Kubernetes не получится, нужно подключать сборщики логов вроде Fluentd и систему хранения, например Elasticsearch или Loki. Отдельно придется заниматься балансировкой нагрузки: понадобится отказоустойчивый балансер вроде MetalLB.

Системы хранения для Self-Hosted Kubernetes еще одна головная боль

Kubernetes изначально разработан для Stateless-приложений они ничего не хранят внутри контейнеров. При работе со Stateful-приложениями, хранящими данные, встает вопрос подключения внешних хранилищ.

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

Для нормальной работы приложения без изменения его логики понадобятся Persistent Volumes хранилища, связанные с подами. Они подключаются внутрь контейнеров как локальные директории, позволяя приложению хранить данные под собой. Среди рабочих вариантов CephFS, Glusterfs, FC (Fiber Channel), полный список СХД можно посмотреть в официальной документации.

Интеграция Kubernetes c Persistent Volumes нетривиальная задача. Чтобы развернуть тот же Ceph, недостаточно взять мануал с Хабра и выполнить ряд команд. Плюс в дальнейшем СХД должен кто-то заниматься опять нужен отдельный инженер, а то и несколько.

Если же Self-Hosted-кластер развернут не на железе, а на виртуальных машинах в облаке, то все немного проще собственный кластер Ceph поднимать не нужно. Можно взять кластер хранилища у провайдера и научить его работать с кластером K8s, если провайдер готов предоставить вам API к своей системе хранения данных, что есть не везде. Писать интеграцию при этом придется самостоятельно.

Правда, у провайдеров, предоставляющих IaaS, можно арендовать объектное хранилище или облачную СУБД, но только если логика приложения позволяет их использовать. А в Managed-решениях Kubernetes уже из коробки есть интегрированные Persistent Volumes.

Отказоустойчивость кластера отдельная проблема

С Kubernetes проще обеспечить отказоустойчивость приложений, однако потребуется еще и реализовать отказоустойчивость кластера.

В Kubernetes есть мастер-нода, непосредственно управляющая кластером и содержащая его конфигурацию, метаданные и статусы объектов Kubernetes. Отказоустойчивый кластер включает три мастер-ноды, отдельные от самого кластера и дублирующие друг друга. Каждая нода отдельный сервер или виртуальная машина, их не могут использовать бизнес-приложения. То есть их нужно отдельно подключать и обслуживать либо оплачивать аренду в облаке.

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

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

Резерв зависит от того, какое количество вышедших из строя нод вероятно в вашем случае:

• Если у вас одна стойка с серверами в одном дата-центре, то одномоментно, скорее всего, выйдет из строя максимум одна нода на одном сервере, например из-за ошибок ОС. Значит, нужен резерв на одну ноду. Конечно, может сломаться стойка, но тут уже нужно резервирование не средствами Kubernetes.
• Если у вас несколько стоек с серверами, то есть вероятность потери одной стойки, например из-за проблем со свичем, когда все серверы в ней станут недоступны. Значит, нужен резерв в размере количества серверов в одной стойке.
• Если у вас несколько дата-центров, то в каждом нужно держать резерв по размеру другого дата-центра, чтобы приложения работали в случае его выхода из строя.

Если проще, то это выглядит так: когда в кластере 10 нод и вы хотите без проблем пережить потерю одной ноды, то вам потребуется 10-процентный запас ресурсов. Если же приложения должны работать даже при потере 50% кластера, значит, на всех нодах нужен запас в 50%.

При этом лучше, если ноды в кластере небольшие по объему, но их много. Допустим, у вас есть пул ресурсов 100 ГБ оперативной памяти и 100 ядер CPU. Такой объем позволяет запустить 10 виртуалок и 10 нод кластера Kubernetes. И в случае выхода из строя одной ноды вы теряете только 10% кластера.

На железных серверах такую конфигурацию не создашь. Например, используя 300 ГБ оперативной памяти и 50 ядер CPU, вы развернете всего 23 ноды кластера. И в случае выхода из строя одной ноды рискуете сразу потерять 3050% кластера.

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

Автомасштабирование кластера нетривиальная задача

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

Автоскейлинг приложений в кластере возможен на любой инфраструктуре это делается средствами Kubernetes. А вот автоскейлинг кластера, который позволяет автоматически подключать и отключать ноды при изменении нагрузки, на Bare Metal реализуется только покупкой дополнительных серверов. Значит, заказываем их и ждем сразу масштабироваться не выйдет.

Плюс если мы говорим о Self-Hosted на Bare Metal, то все серверы, необходимые для работы приложений на случай нагрузки, придется держать в рабочем состоянии и постоянно за них платить.

Если Self-Hosted-кластер развернут на IaaS, то схема похожая: инженер добавляет новую виртуальную машину и вносит ее в кластер. Другой вариант взять API провайдера, если он его предоставляет, подключить через него кластер Kubernetes, научить его запускать для себя новые серверы и так реализовать автомасштабирование. Но потребуется разрабатывать отдельное решение это сложная задача, предполагающая высокий уровень экспертности в Kubernetes и облаках.

Кроме того, для быстрого масштабирования Self-Hosted-кластера на IaaS придется резервировать нужное количество ресурсов провайдера и создавать из них новые виртуальные машины по мере надобности. И за эти зарезервированные ресурсы придется платить: практика брать плату за выключенные ресурсы бывает у реселлеров VMware. На нашей платформе в случае отключенных ВМ вы не платите за ресурсы, только за диски. В некоторых Managed-решениях автоскейлинг включается по кнопке, уточните эту возможность у вашего провайдера.

Подводные камни Self-Hosted Kubernetes

1. Для самостоятельной эксплуатации кластера нужен специалист на фултайм, который хорошо знает технологию и понимает, как все работает внутри Kubernetes.
2. В кластере потребуется настроить мониторинг, сбор логов, балансировку нагрузки и многое другое.
3. Отдельная проблема развернуть и интегрировать с кластером систему хранения данных.
4. Чтобы обеспечить отказоустойчивость кластера, потребуются дополнительные серверы или виртуалки это дополнительные затраты.
5. Для масштабирования кластера под нагрузкой нужен запас серверов или виртуалок это еще одна статья дополнительных расходов.

Рассчитывайте ваши возможности при старте проекта. То, какие ресурсы есть у вашей компании, ваш бэкграунд, навыки и другие детали сильно влияют на выбор решения, насколько вам будет выгодно разворачивать Kubernetes самостоятельно или лучше это сделать в облаке с помощью готового сервиса. И не забываем главный вопрос всего Kubernetes: нужна ли вообще эта технология на вашем проекте, как и для чего вы собираетесь ее использовать?

Тут можно почитать, как устроен наш Kubernetes aaS на платформе Mail.ru Cloud Solutions: что у него под капотом и что в него еще входит, кроме собственно Kubernetes.

• Вначале посмотрим глазами новичка. Что такое БД в памяти? Какие задачи они решают лучше дисковых БД?
• Потом посмотрим архитектурно. Как обстоит вопрос с производительностью, надёжностью, масштабированием?
• В третьей части лезем в технические вещи поглубже. Типы данных, итераторы, индексы, транзакции, ЯП, репликация, коннекторы.

Содержание

1. Вводная часть
   
   • Что такое БД в памяти
   • Зачем нужны решения в памяти
   • Что такое Redis
   • Что такое Tarantool
2. Архитектурная часть
   
   • Производительность
     
   • Надёжность
   • Масштабируемость
   • Валидация схемы данных
3. Технические особенности
   
   • Какие типы данных можно хранить
   • Вытеснение данных
   • Итерация по ключам
   • Вторичные индексы
   • Транзакции
   • Персистентность
   • Язык программирования для хранимых процедур
   • Репликация
   • Коннекторы из других языков программирования
   • Под какие задачи плохо подходят
   • Экосистема
   • Чем Redis лучше
   • Чем Tarantool лучше
4. Вывод
5. Ссылки

1. Вводная часть

Что такое БД в памяти

Зачем нужны решения в памяти

• Персистентность кеши сохраняют данные на диск. После перезагрузки восстанавливаем своё состояние без обращений к основному хранилищу. Если этого не делать, то обращение к холодному кешу будет очень долгим или даже положит основную БД.
• Резервирование кеши содержат функции репликации данных. Если упал один узел, то второй возьмёт на себя запросы. Основное хранилище не упадёт от перегруза, нас спасает резервная нода.
• Шардирование если горячие данные не помещаются в оперативную память одного узла, мы используем несколько узлов параллельно. Это горизонтальное масштабирование.

Что такое Redis

• Redis называет себя in-memory хранилище структур данных.
• Redis это key-value.
• Больше всего известен по кешированию дисковых баз. Если вы будете искать по ключевым словам кеширование баз данных, то в каждой статье найдёте упоминания Redis.
• Redis поддерживает первичные индексы, не поддерживает вторичные.
• Redis содержит в себе механизм хранимых процедур на Lua.

Что такое Tarantool

• Tarantool называет себя платформа для in-memory вычислений.
• Tarantool умеет в key-value. А еще в документы и реляционную модель данных.
• Создан для горячих данных кеширования MySQL в соцсети. С течением времени развился в полноценную базу данных.
• Tarantool может строить произвольное количество индексов по данным.
• В Tarantool тоже можно написать хранимую процедуру и тоже на Lua.

2. Архитектурная часть

Производительность

MacBook Pro 2,9 GHz Quad-Core Intel Core i7Redis version=6.0.9, bits=64Tarantool 2.6.2

redis_test.gopackage mainimport (    "context"    "fmt"    "log"    "math/rand"    "testing"    "github.com/go-redis/redis")func BenchmarkSetRandomRedisParallel(b *testing.B) {    client2 := redis.NewClient(&redis.Options{Addr: "127.0.0.1:6379", Password: "", DB: 0})    if _, err := client2.Ping(context.Background()).Result(); err != nil {        log.Fatal(err)    }    b.RunParallel(func(pb *testing.PB) {        for pb.Next() {            key := fmt.Sprintf("bench-%d", rand.Int31())            _, err := client2.Set(context.Background(), key, rand.Int31(), 0).Result()            if err != nil {                b.Fatal(err)            }        }    })}

tarantool>box.cfg{listen='127.0.0.1:3301', wal_mode='none', memtx_memory=2*1024*1024*1024}box.schema.user.grant('guest', 'super', nil, nil, {if_not_exists=true,})box.schema.space.create('kv', {if_not_exists=true,})box.space.kv:create_index('pkey', {type='TREE', parts={{field=1, type='str'}},                                   if_not_exists=true,})

tarantool_test.gopackage mainimport (    "fmt"    "math/rand"    "testing"    "github.com/tarantool/go-tarantool")type Tuple struct {    _msgpack struct{} `msgpack:",asArray"`    Key      string    Value    int32}func BenchmarkSetRandomTntParallel(b *testing.B) {    opts := tarantool.Opts{        User: "guest",    }    pconn2, err := tarantool.Connect("127.0.0.1:3301", opts)    if err != nil {        b.Fatal(err)    }    b.RunParallel(func(pb *testing.PB) {        var tuple Tuple        for pb.Next() {            tuple.Key = fmt.Sprintf("bench-%d", rand.Int31())            tuple.Value = rand.Int31()            _, err := pconn2.Replace("kv", tuple)            if err != nil {                b.Fatal(err)            }        }    })}

go test -cpu 12 -test.bench . -test.benchtime 10sgoos: darwingoarch: amd64BenchmarkSetRandomRedisParallel-12          929368         15839 ns/opBenchmarkSetRandomTntParallel-12            972978         12749 ns/op

Надёжность

• Персистентность. При перезагрузке БД загрузит свои данные с диска, не будет запросов в сторонние системы.
• Репликация. Если упал один узел, то есть копия на втором. Бывает асинхронная и синхронная.

Масштабируемость

• Зарезервировать дополнительные узлы, которые могут заменять друг друга в случае, если сосед вышел из строя.
• Данные не помещаются на один узел, и их необходимо распределить на несколько.

• Мониторинг узлов в группе: живой или мертвый.
• Уведомление администратора или какой-то системы, если что-то случилось в группе.
• Автоматическое переключение мастера.
• Провайдер конфигурации для внешних клиентов, чтобы они знали, к кому подключиться.

• Администрирование Redis Cluster с помощью скриптов и команд.
• В Tarantool Cartridge администрирование с помощью web-интерфейса или через API.

• Количество корзин шардирования в Redis фиксированное, 16 тыс.
• Количество корзин шардирования Tarantool Cartridge (vshard) произвольное. Указывается один раз при создании кластера.

• В Redis Cluster настройка и запуск вручную.
• В Tarantool Cartridge (vshard) автоматически.

• Маршрутизация запросов в Redis Cluster происходит на стороне клиентского приложения.
• В Tarantool Cartridge маршрутизация запросов происходит на узлах-роутерах кластера.

• Tarantool Cartridge также содержит:
  
  
  • механизм map/reduce запросов;
  • утилиту по упаковке приложения в пакеты rpm, dep и tar.gz;
  • Аnsible-роль для автоматического развёртывания приложения;
  • экспорт параметров мониторинга кластера.
  
  

Валидация схемы данных

• с помощью встроенной валидации box.space.format, которая затрагивает только верхний уровень полей;
• с помощью установленного расширения avro-schema.

3. Технические особенности

Какие типы данных можно хранить

• строки;
• списки строк;
• неупорядоченные множества строк;
• хешмапы или просто строковые пары ключ-значение;
• упорядоченные множества строк;
• Bitmap и HyperLogLog.

• Атомарными:
  
  • строки;
  • логический тип (истина, ложь);
  • целочисленный;
  • с плавающей запятой;
  • с десятичной плавающей запятой;
  • UUID.
  
  
• Комплексными:
  
  • массивы;
  • хешмапы.
  
  

Вытеснение данных

• TTL вытеснение объектов по завершении срока жизни;
• LRU вытеснение давно использованных данных;
• RANDOM вытеснение случайно попавшихся под руку объектов;
• LFU вытеснение редко используемых данных.

Итерация по ключам

• SCAN;
• итерация по ключам.

results = {}for _, tuple in box.space.pairs('key', 'GE') do    if tuple['value'] > 10 then        table.insert(results, tuple)  endendreturn results

Вторичные индексы

• В упорядоченных множествах можно использовать порядковый номер элемента как вторичный ключ.
• Использовать хешмапы, ключ которых является, в некотором смысле, индексом данных.

• Вторичные ключи могут состоять из нескольких полей.
• Для вторичных индексов можно использовать типы HASH, TREE, RTREE, BITSET.
• Вторичные индексы могут содержать уникальные и не уникальные ключи.
• У любых индексов можно использовать настройки локали, например, для регистронезависимых строковых значений.
• Вторичные индексы могут строиться по полям с массивом значений (иногда их называют мультииндексы).

Транзакции

> MULTIOK> INCR fooQUEUED> INCR barQUEUED> EXEC1) (integer) 12) (integer) 1

do  box.begin()  box.space.kv:update('foo', {{'+', 'value', 1}})  box.space.kv:update('bar', {{'+', 'value', 1}})  box.commit()end

Персистентность

• периодическим сбросом in-memory данных на диск snapshoting;
• последовательной упреждающей записью всех приходящих операций в файл transaction journal.

• Снапшот в Redis называется RDB (redis database).
• Журнал операций в Redis называется AOF (append only file).

• Механизм персистентности взят из архитектур баз данных.
• Он является целостным снапшоты и журналирование.
• Этот же механизм позволяет существовать надежной WAL-based репликации.

• Снапшот в Tarantool называется snap (snapshot). Можно делать с произвольной частотой.
• Журнал транзакций в Tarantool называется WAL (write ahead log).

redis-check-aof --fix

tarantool> box.cfg{force_recovery=true}

Язык программирования для хранимых процедур

• Lua это язык, который легко встраивается в существующее приложение.
• Он просто интегрируется с объектами и процессами приложения.
• Lua имеет динамическую типизацию и автоматическое управление памятью.
• Язык имеет сборщик мусора incremental Mark&Sweep.

• В Redis используется ванильная реализация PUC-Rio.
• В Tarantool используется LuaJIT.

• В Redis можно задать таймаут, после которого выполнение хранимой процедуры прервётся.
• В Tarantool хранимые процедуры компилируются и выполняются быстрее, но в этом механизме нет возможности выставить таймаут. Для прерывания хранимой процедуры пользователь должен предусмотреть механизм проверки флага прерывания.

• В Redis используется однозадачность: задачи выполняются по одной и целиком.
• В Tarantool используется кооперативная многозадачность. Задачи выполняются по одной, но при этом задача отдаёт управление на операциях ввода-вывода или явно с помощью yield.

• В Redis Lua это просто хранимые процедуры.
• В Tarantool это кооперативный runtime, в котором можно взаимодействовать со внешними системами.

Репликация

• Асинхронная репликация: при вставке объекта на один узел мы не дожидаемся, когда этот же объект будет отреплицирован на второй узел.
• Синхронная репликация: при вставке объекта мы дожидаемся, когда он будет сохранён на первом и втором узлах.

• В Redis это команда wait. Она принимает два параметра:
  
  • сколько реплик должны получить объект;
  • сколько ждать, пока это произойдёт.
  
  
• В Tarantool это можно сделать фрагментом кода:

local netbox = require('net.box')local replica = netbox.connect(...)local replica_vclock, err = replica.eval([[    return box.info().vclock]])while not vclock_compare(box.info().vclock, replica_vclock) do    fiber.sleep(0.1)end

Коннекторы из других языков программирования

• Go;
• Python;
• NodeJS;
• Java.

• https://redis.io/clients
• https://tarantool.io/ru/download/connectors

Под какие задачи плохо подходят

Экосистема

• Enterprise;
• проверенные и сертифицированные для Enterprise и Open source;
• непроверенные.

• полнотекстовый поиск;
• хранение и поиск по bloom-фильтрам;
• хранение временных рядов.

• хранение графов и запросы к ним;
• хранение JSON и запросы к нему;
• хранение и работа с моделями машинного обучения.

• Встроенные: https://www.tarantool.io/en/doc/latest/reference/
• Enterprise: https://www.tarantool.io/en/enterprise_doc/rocksref/#closed-source-modules

Чем Redis лучше

• Проще.
• В интернете представлено больше информации, 20 тыс. вопросов на Stackoverflow (из них 7 тыс. без ответов).
• Ниже порог входа.
• Как следствие, проще найти людей, которые умеют работать с Redis.

Чем Tarantool лучше

• Русскоязычная бесплатная поддержка в Telegram от разработчиков.
• Есть вторичные индексы.
• Есть итерация по индексу.
• Есть UI для администрирования кластера.
• Предлагает механику сервера приложений с кооперативной многозадачностью. Эта механика похожа на однопоточный Go.

4. Вывод

• Реляционную модель хранения с SQL.
• Распределённое NoSQL-хранилище.
• Создание продвинутых кешей.
• Создание брокера очередей.

5. Ссылки

1. Архитектура S3: три года эволюции Mail.ru Cloud Storage
2. Синхронная репликация в Tarantool
3. Скачать Tarantool можно на официальном сайте, а получить помощь в Telegram-чате.

Саша:
У меня есть свой небольшой проект словесно-карточная игра Кто из нас? На одном из очередных разборов игры родилась мысль, что можно внутри игры спрятать ещё одну игру. Люди найдут её и скажут: Ого, я играл в одну, а сейчас играю в совершенно другую. Но игра, которую я делаю, не настолько популярна, поэтому если туда прятать ещё одну игру, то её просто никто не увидит. Возникла вторая идея. Я работаю в Delivery Club, и у нас миллионы пользователей, у которых есть общая проблема время ожидания заказа. Нужно либо сокращать время доставки, либо как-то развлечь пользователя, пока он ожидает. И я пошёл по второму пути: придумал решение в виде небольшой игры внутри основного приложения.

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

Сахей:
Очень понравился этот режим стартапа. Обычно на работе есть все спецификации и документация протоптанная тропинка, по которой ты идёшь. А тут был полный полёт мысли. Мы ещё хотели изначально поменять рендеринг на SwiftUI или на UIKit, но не стали так извращаться, SpriteKit отлично подходил для нашей задачи. Он оптимизирован под отрисовку спрайтов. Если в UIKit 100-200 вьюшек, то FPS очень сильно проседает, а в SpriteKit нет. Но мы фана ради хотели попробовать.

Саша:
Когда Лера показала свой дизайн, у нас с Сахеем загорелись глаза. Мы такие: Вау! Можно же настолько красиво и современно всё сделать! У нас появилась куча новых идей. Можно нарабатывать опыт у змейки с каждой игрой и набирать очки, за них покупать змейке какой-то апгрейд, типа шапочки или щита, чтобы она врезалась в стенку, а у неё на одну жизнь больше было. Но всё-таки история со змейкой должна была где-то кончиться, чтобы дойти до релиза. И мы решили упростить игру, чтобы не смещать фокус с основного функционала Delivery Club.

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

Георгий:
После того, как ребята реализовали версию под iOS, мы принялись адаптировать приложение под Android. Разработка велась на Kotlin, всё сделали нативно, без использования сторонних библиотек. В конечном итоге версию под Android получилось написать всего за четыре дня. Идея была творческой и разнообразила череду рутинных задач.