Привет! Меня зовут Максим Гореликов, я Backend Tech Lead в М2. Несколько вещей, которые следует знать об этой статье, прежде чем углубляться в нее:
- эта статья является стенограммой мой отчет на конференции Yandex Scale 2021 с некоторыми изменениями;
- Мы собрали данные от разных участников переезда и нашли много интересной информации, но отчет был в слоте о Яндекс Платформе Данных, поэтому кейсы мы оставили только по этой теме;
- Материал носит скорее обзорный характер, чтобы понять, с чем вы можете столкнуться.
Жестких технических подробностей немного, ведь каждый ход будет свой.
Облака.
Когда мы переезжали, не все процессы в Яндекс.
Облаке были налажены, поэтому расскажу о самых ярких воспоминаниях — проблемах, с которыми мы столкнулись.
Хороших моментов тоже было немало, но проблемы всегда интереснее обсуждать.
Почему мы решили перейти в облако
Мы довольно молодая компания, и наша команда разработчиков растет быстрее, чем команда поддержки.Это совершенно стандартный подход, потому что бизнес в первую очередь стремится инвестировать в развитие.
Поэтому первой причиной переезда было то, что я хотел освободить нашу команду поддержки .
Инфраструктура сейчас Второй - возможность быстро экспериментировать с новой инфраструктурой и его последующее масштабирование.
PaaS-решения позволяют быстро развернуть хранилище или любую другую инфраструктуру и понять, подходит она для задач компании или нет. Это важно, потому что вы хотите расти, не страдая от ограничений.
Зачастую они связаны с тем, что никто в компании еще не развернул тот или иной компонент, который нам вполне обоснованно может понадобиться для нового проекта.
Третья причина сертификация персональных данных .
Яндекс Платформа Данных предоставляет готовые решения там, где большинство проблем уже решено.
Остаётся позаботиться о некоторых мелочах, а не проходить всё с нуля.
Как не сломать все сразу
Чтобы собрать все проблемы и не получить кучу недовольных пользователей в продакшене, мы решили попробовать всё на среде разработки.Если вдуматься, девелоперы — основные потребители инфраструктуры.
С большой вероятностью в процессе работы они соберут все проблемы, испытают все баги и не будут их терпеть, а будут говорить о них прямо и без скупости слов.
Кластеры хранения данных
До этого наша система выглядела так: для каждого сервиса была развернута виртуальная машина и на ней располагалось хранилище для этого сервиса.Это неуклюже, но просто и работает — то, что нужно на старте компании.
Но на момент перехода в Яндекс.
Облако и развертывания там нашей dev-среды у нас уже было около 150 сервисов и около 5 сред, от dev до prod. Получается 750 кластеров одного хранилища — если посчитать ценник на ресурсы, то получается довольно дорого.
Поэтому мы немного оптимизировали кластеры.
Мы выбрали единый подход для сред разработки и тестирования: один кластер для бэкенда, один для фронтенда и один для других нужд. Для prod, stage и perf все немного сложнее: мы выделили кластер для каждого бизнес-блока, кластер для общих сервисов и кластер для каждого критического сервиса, чтобы на них ничего не влияло.
Мы получили первый плюс — своеобразный пинок, который мотивирует задуматься о ресурсах и оптимизировать их.
Мы воссоздали необходимый набор кластеров и получили очередной набор проблем, связанных с работой приложений.
Несовместимость библиотек и версий
Для приложений мы используем библиотеку Mongock, которая отвечает за развертывание изменений в схемах данных, миграцию данных, создание индексов и т. д. После того, как мы реформировали кластеры, оказалось, что в один кластер входит несколько приложений и каждое приложение имеет свою базу данных..
Естественно, в этот момент мы сильно урезаем права приложения, оставив только readWrite для конкретной базы.
«Видимо, дело в разрешениях», — подумали мы, когда посмотрели на новую схему и получили в логах ошибки типа «не разрешено выполнять команду».
«Нам следует обновить Mongock».
«Не надо меня обновлять, мне эти права не нужны, — подумал Монгок, — лучше пойди разберись, зачем ты используешь заброшенные Монгоби" .
Оказалось, что пара наших сервисов уже давно используют Mongobee. Когда-то команд и сервисов было не так много и всё это жило вполне благополучно по принципам «работает, не трогай».
При миграции в облако все сервисы естественным образом перешли на единую версию MongoDB и исключили структуры, которые были помечены как устаревшие еще в MongoDB 4.2. Обновить Mongobee можно было, но, конечно, всем выгоднее перейти на общее решение в виде Mongock, а не решать одни и те же проблемы с двумя разными библиотеками параллельно.
В этой ситуации виноваты только мы, но мораль такова: как и в обычном переезде, «в углах и темных местах» можно найти то, что в обычных ситуациях не всегда удосужился бы искать и исправлять.
Да, пока это выглядит так, будто мы просто исправляли свои ошибки в процессе переезда, но это всегда полезно, и в будущем сценариев будет больше.
Немного похоже на предыдущее, но касается сервисов в Scala и связано не с нашей рассинхронизацией или ошибками, а с особенностями облака.
Для работы с Redis эти сервисы использовали клиент redis4cats. При запуске приложений стали получать Segmentation error (неприятная ошибка) и тратили много времени на отладку.
Проблема решилась просто — мы пошли искать подсказки в документации Яндекс.
Облака и нашли там список рекомендуемых клиентов для Redis. Среди них были джедаи.
Оно, конечно, на Java, но это все JVM-языки, и Jedis нам вполне подошел.
Вывод (очевиден, если вы уже нашли решение): на всякий случай перечитайте документацию перед переходом — возможно, вы поймете что-то нужное.
После того как нам удалось решить проблему с совместимостью библиотек и мы наконец смогли запустить все приложения, мы начали ловить проблемы в логах.
Хранилище, совместимое с S3 != Хранилище, совместимое с S3
Думайте о S3-совместимом хранилище как об иерархии кластера, сегмента, каталога и файлов.Надеюсь, у вас получится что-то похожее на изображение ниже.
Теперь, глядя на это, давайте посмотрим на проблемы, с которыми мы столкнулись.
Основные особенности, на которые стоит обратить внимание, чтобы понять проблему:
- В старом провайдере в одном бакете можно было создать ограниченное количество файлов, поэтому каждый наш сервис старался работать с несколькими бакетами.
В Яндекс.
Облаке таких ограничений нет.
- В старом провайдере у нас был доступ к нескольким кластерам S3, в Яндекс.
Облаке вы можете получить доступ только к одному кластеру и будете делиться им с другими клиентами Яндекс.
Облака.
Проблема с серверной частью
В момент нашего переезда при предоставлении прав на listBuckets приложение, которое его использует, неожиданно получило весь список бакетов, доступных нашей компании.Из-за этого всплыли некоторые артефакты.
Как забавный пример: файлы в корзинах начали хаотично шифроваться одним из приложений.
Логичным решением проблемы был переход на подход «Bucket per Service», поскольку никаких ограничений со стороны старого провайдера уже не было.
Нам пришлось немного подправить код некоторых приложений, но, с другой стороны, мы упростили процессы работы с S3.
Бэкэнд исправлен - интерфейс сломан
Наши проблемы были связаны с тем, что в Яндекс.Облаке для всех один кластер Object Storage. В рамках любого S3 Object Storage имя бакета уникально, поэтому существуют большие риски, связанные с тем, что при перемещении нужное имя бакета уже будет занято кем-то другим.
Так и произошло.
К моменту нашего переезда корзина с названием assets, откуда наши фронтенд-приложения брали много ресурсов (изображения, CSS и т. д.), уже была занята.
Ведь если вы посмотрите на сеть в браузере, то на большом количестве сайтов вы обнаружите использование активов в пути к ресурсу.
Проблема решилась просто: у нас был запущен CDN поверх Object Storage, в рамках которого мы могли настроить перезапись адресов.
Еще один промежуточный вывод: будьте готовы к тому, что при переезде вам придется не только адаптироваться к изменениям в самой инфраструктуре, но и исправлять свои приложения, иногда обновлять или заменять библиотеки.
Просто нужно учитывать, что в этом месте потребуются некоторые трудозатраты.
Обмен данными
Как минимум, для перемещения клиентских служб и данных требовалось перемещение MongoDB, PostgreSQL и Apache Kafka. На момент нашего переезда уже был доступен Yandex Data Transfer, но он работал в режиме предварительного просмотра и поддерживал только миграцию PostgreSQL, чего нам было недостаточно.Поэтому мы транспортировали наши данные стандартными средствами баз данных, поверх которых написали набор скриптов.
Насколько мне известно, Яндекс Передача Данных сейчас вышла из предварительной версии и имеет дополнительную поддержку MySQL и MongoDB. Кроме того, он имеет режим «Копировать и реплицировать», при котором сначала передаются старые данные, а затем включается постоянная репликация.
Это позволяет переключать приложения со старого кластера на новый практически без простоев.
В случае с Apache Kafka все было сложнее, поскольку Яндекс Передача Данных его не поддерживал.
Сейчас в режиме предварительного просмотра есть поддержка Кафки как источника при миграции, но это может помочь скорее при миграции базы данных, а не одного кластера Kafka на другой.
Кроме того, нам нужно было передать не только данные в топиках, но и смещение.
Мы не хотели, чтобы все данные из топиков перечитывались, если мы потеряли смещение (идемпотентность для нас все, но загрузку при перечитывании никто не отменял).
Для миграции мы использовали Mirror Maker 2.0 — вещь удобная и рекомендованная официальным руководством Яндекс.
Облака.
К моменту миграции он уже имел КИП для компенсации миграции и она еще уже удалось слиться с мастером , Но выпускать вышел после нашего переезда.
Поэтому из коробки мы не получили того, что нам было нужно.
В результате одной из самых сложных миграций для нас стала миграция Kafka. Решения оказались довольно корявыми, но работоспособными.
Мы переключили потребительские настройки в наших приложениях на чтение со offset=latest в момент их инициализации на новом кластере, чтобы не было повторного чтения.
В этом случае нам пришлось остановить всех производителей до тех пор, пока потребители не прочтут все сообщения, и только потом переключить приложения на новый кластер.
Естественно, это привело к увеличению недоступности во время процесса переезда.
Теперь это проще: Mirror Maker 2.0 поддерживает смещенную миграцию «из коробки».
Жизнь в Яндекс.
Облаке и использование PaaS Переезд завершился, но работа продолжалась.
Переход в облако принес нам некоторые преимущества.
Разработчик может быстро попробовать что-то новое
Раньше мы боялись пробовать ClickHouse, потому что его несколько сложнее поддерживать, чем другую нашу инфраструктуру.Мы ведь еще и старались экономить усилия наших инженеров-эксплуатационников — они сделали еще много всего необходимого.
Сейчас мы просто развернули его PaaS, протестировали и начали использовать.
Да, усилия по поддержке прилагаются, но гораздо меньше, чем для локальных решений.
Аналогичная ситуация и с PostgreSQL. Оно у нас было и раньше, но после переезда мы решили развернуть связку PostgreSQL + 1С.
Те, кто знаком с этой комбинацией, понимают, что нужно вкладываться в настройку параметров дисковой подсистемы, настройку оптимизаторов, установку дополнительных модулей и углубление в оптимизацию.
Но если вы живете в Яндекс.
Облаке, то вам доступны подготовленные образы определенных версий.
В нашем случае нам даже удалось получить сборку с нужной версией и перейти на нее.
Это решает большинство проблем.
Хотя все же стоит учитывать, что для малого бизнеса достаточно стандартной предустановки.
Если у вас большая нагрузка на 1С, вам потребуется дополнительная настройка, поскольку виртуализация все равно накладывает заметный отпечаток на производительность этой комбинации.
Вы живете по принципам «Инфраструктура как код»? Часть кода для вас уже подготовлена
Яндекс подготовил пакет ресурсов для terraform-провайдера.Вы можете просмотреть список здесь .
Существенным преимуществом является то, что вам не нужно после обновления конфигов прописывать базовые шаги типа корректного перезапуска кластера (когда мастер перезагружается последним, чтобы не прыгать по нодам) - все это уже реализовано, берите и делайте только те вещи, которые вам конкретно нужны.
Понятно, что PaaS для патчей и минорных версий обновляются автоматически и некоторые затраты времени потребуются только в случае необходимости обновления до мажорной версии.
Когда все хорошо, всегда где-то скрывается компромисс.
Переходя на решения PaaS и SaaS, вы снимаете бремя поддержки, но теряете некоторые возможности настройки и контроль над своей инфраструктурой.
Давайте посмотрим, как это проявляется на примере MongoDB. Некоторые части нашей системы используют потоки изменений Mongo. Вещь довольно удобная, когда нужно обновить данные и обязательно отправить событие куда-то еще.
Монго меняют потоки Вся эта связка довольно просто разворачивается и работает. Что вам нужно понимать о потоках изменений:
- Mongo Change Streams основан на OpLog;
- OpLog работает по принципу кольцевого буфера, новые события записываются поверх старых.
- Если вы планируете хранить небольшой объем данных в кластере MongoDB, вы, скорее всего, выберете меньший (более дешевый) диск;
- Размер OpLog в Яндекс.
Облаке определяется автоматически исходя из размера диска и не может быть задан отдельно.
Оплог небольшой, изменений много, данные не успевают прочитаться и часть событий начинаешь терять.
Вот с этим мы и столкнулись, и до сих пор нет возможности настроить этот параметр через интерфейс или что-то еще.
Но можно попробовать написать в поддержку и попросить дополнительные настройки.
Давайте рассмотрим еще один пример возможностей настройки комбинации ClickHouse и Kafka. 
ClickHouse Kafka Engine. Наша схема Как я писал выше, мы решили использовать ClickHouse только после переезда в Яндекс.
Облако.
Если вы собираете ClickHouse самостоятельно (не как PaaS), то бандл настраивается достаточно просто и поддерживает работу с Protobuf из коробки — достаточно положить протоконтракт в директорию ClickHouse и сделать пару настроек.
Наша система довольно широко использует gRPC с протоконтрактами, поэтому и здесь нам было бы удобно передавать данные в Protobuf. Проблема в том, что ни в UI, ни в API на тот момент, когда мы поднимали эту связку по PaaS-решениям, перенести протоконтракт не удалось.
Здесь тоже подойдет метод «написать в поддержку», но если контракт меняется довольно часто, то метод не очень удобен.
Хорошая новость в том, что спустя довольно небольшой промежуток времени после того, как мы подняли эту связку в Яндекс.
Облаке, перенести прото через API все же стало возможно.
Небольшой вывод из этого блока: сэкономленные усилия на поддержке PaaS-решений стоят ограничений кастомизации, но только в том случае, если они не блокируют развитие вашей системы и их можно обойти, а это необходимо проверить на практике.
Как все это поддерживается?
Для полноты картины — последний штрих: усилия по поддержке PaaS минимальны, но они все равно существуют.Резервные копии
Для PaaS-решений они существуют, делаются автоматически, восстановление запускается простым нажатием кнопки (или пары кнопок) в пользовательском интерфейсе.Небольшая ложка дегтя в том, что весь кластер заархивирован и восстановить его можно только целиком.
Если у вас несколько баз данных в одном кластере и вы не только потеряли кластер, но и, скажем, не очень хорошо выкатили DDL или ошибка в коде вдруг уничтожила часть критических данных, то, скорее всего, у вас будет поднимать другой кластер и восстанавливать в него данные, а затем переносить конкретную базу данных в исходный кластер не очень удобно, но схема работает в случае аварий.
Если немного отойти от платформы данных Яндекса и предположить, что вам не хватило какой-то инфраструктуры в PaaS и вы пошли разворачивать ее самостоятельно в Compute Cloud, то с резервными копиями все немного хуже.
Опять же, вы можете делать снимки с виртуальной машины, но вы не можете настроить это на периодической основе «из коробки».
Специальный человек должен периодически нажимать кнопку - шучу.
Специальный человек с прямыми руками (а у наших ребят в компании прямые руки) может быстро собрать систему с автоматическим резервным копированием, используя то, что есть в облаке: 
Очередь сообщений и облачные функции позволяют автоматизировать этот процесс.
Журналы
На момент переезда это была неприятная проблема: логи PaaS нельзя было просмотреть ни в UI, ни в CLI. И здесь снова пригодился стандартный метод «обратиться в поддержку».За последний год CLI сильно улучшился, и теперь эти самые логи от того или иного PaaS можно удобно получать.
Кроме того, Яндекс Cloud Logging стал доступен в режиме предварительного просмотра и в будущем вы можете попробовать перейти на него.
Пока вопрос в возможности и удобстве работы с логами приложений через этот инструмент.
Мониторинг и оповещения
Для PaaS они существуют. Плюсы:- подготовленный набор дашбордов достаточно удобен и поддается настройке;
- Есть оповещения по электронной почте и SMS;
- метрики для PaaS-решений можно скачать через API.
- в редких случаях экспортированного набора метрик недостаточно (добавить его самостоятельно нельзя);
- Нет возможности отправлять оповещения в мессенджеры (Telegram, Slack).
Оповещения также можно настроить через наш менеджер оповещений.
Дашборды в Яндекс.
Облаке иногда используются, но в основном для общения со службой поддержки и обсуждения проблем инфраструктуры.
Возможно, в будущем мы перейдём на встроенный в облако мониторинг, но всё будет зависеть от того, как он будет доработан.
Итог (возможно, очевидный, но только после завершения всего процесса): облачные инструменты были значительно улучшены с момента нашего переезда, поэтому, если вы переехали недавно, вы, вероятно, не столкнулись с большинством наших проблем.
Но прежде чем двигаться дальше, я все же рекомендую протестировать среду в вашей среде разработки, чтобы понять, какие функции и как можно обойти.
Теги: #инфраструктура #ИТ-инфраструктура #paas #облачные сервисы #DevOps #s3 #yandex.cloud #clickhouse #Яндекс.
Облако #миграция в облако #mongo #mongo
-
Проблемы Измерения Скорости Света
19 Oct, 24 -
Google Покупает Социальную Сеть Aardvark
19 Oct, 24 -
Новогоднее Настроение Из Ардуино И Палочек
19 Oct, 24 -
Удаление Рекламы На Новом Сайте Компьютерра
19 Oct, 24 -
Флеш Гамм Киев 2009!
19 Oct, 24
