Про Битрикс24: облачный хостинг в России и процесс деплоя

Rate this post

В связи со вступлением в силу 242-ФЗ, персональные данные клиентов сервиса Битрикс должны храниться в России. Варианты выполнения закона:n

Проигнорировать — бизнес клиентов зависит от проекта, игнорировать нельзя.
Условно выполнить закон, используя прокси — вызывает сложности с отказоустойчивостью.
Деперсонализировать данные в удаленных дата-центрах, а персональные хранить в России — была опасность потерять сетевую связанность.
Перенести российских клиентов в Россию – решает проблемы сетевой связанности.

nСравнение RTT (Round Trip Time) в зависимости от региона для российских клиентов:n

США – 130 мс
Европа – 70 мс
Россия – 5-10 мс

Был выбран вариант переноса клиентов в Россию полностью. Появилась задача сделать это незаметно для клиентов, без downtime.n

Реализация

Первый шаг: свой балансировщик.

В связи с тем, что нужно было связать российский и не российский сегмент Битрикс24 в единой архитектуре, появилась необходимость написать свой балансировщик. Для этого выделили один физический сервер, размещенный в России. На нем был прописан back-end как в амазоне, и это решило несколько задач. ELB балансировщик Amazon очень простой. А здесь появилась возможность балансировать запросы как угодно.nnНовые преимущества:n

Первое соединение клиента идет локально.
За счет установленного keep alive соединения на back-end, он работает быстрее.
Более умно сделано кэширование и для клиента стало выглядеть всё быстрее.
Распределять по-портально клиентов, не меняя записей в DNS.

Это позволила плавно по одному клиенту переносить в Россию без downtime.n

Второй шаг: выбор облака.

В сервиса Битрикс24 установлены серьезные требования по безопасности и отказоустойчивости. К тому времени был хороший опыт работы с Amazon. Инфраструктура должна была быть связана в единое целое. По этим причинам и не только для российского сегмента так же был выбран облачный хостинг.nnВ России не было провайдеров, аналогичных Amazon. Пришлось выбирать того, возможности которого были максимально близки:n

Гибкая тарификация
Провайдер присутствовал как минимум в двух дата-центрах — для резервирования на уровне дата-центра.
Наличие и коммерческих, и некоммерческих гипервизоров.
Список сервисов и возможности как у Amazon.

Для Битрикс24 был выбран облачный хостинг CorpSoft24.nnПри переносе возникли некоторые сложности с провайдером. В связи с ростом нагрузки провайдер не успевал докупать и настраивать ресурсы, но он справился. Сегодня при планируемой штатной нагрузке работа идет хорошо.n

Третий шаг: свой сервис scaling сервис

Для Битрикс24 свой балансировщик был установлен даже на амазоновском хостинге. Пришло время реализовать свой сервис автомасштабирования. В основе работы мониторинг load average cистемными утилитами типа top или atop и сбор метрик. Используем API гипервизор на VMware Автоматически стартуют новые машины и добавляем их конфигурацию за нашим балансировщиком., если средняя нагрузка CPU превышает заданный верхний порог Автоматически останавливаются, и когда перестают туда идти хиты, выводятся из балансировщика, если средняя нагрузка опускается ниже заданного нижнего порогаnnКак это выглядит:Идет рост и потом снижение хитовnnnnС ростом хитов возврастает нагрузка на сервер.nnЧерез системными утилиты типа top или atop scaling сервис собирает метрики и мониторит Load Average. Он через API гипервизора на VMware стартует новые машины и добавляет их конфигурацию за нашим балансировщиком. После добавления новых машин нагрузка падает, затем снова растет из-за порога по количеству машин. Со снижением количества хитов нагрузка падает. Средняя нагрузка опускается ниже заданного нижнего порога. Scaling сервис выводит сервер из балансировщика и, когда туда перестают идти хиты, останавливает сервер.nnnnПри этом есть заданный максимальный порог количества серверов, который сервис превысить не может. Он устанавливается вручную и с ростом общей нагрузки постепенно поднимается.nnnnВесь подход к инфраструктуре сводиться к правилу:»Нужно сделать просто там, где можно сделать просто.nА где делается сложно, делать сложно не нужно»n

Деплой обновлений и хотфиксов

Выпуск обновлений или деплой нового кода для Битрикс24 имеет свои особенности. Так как это бизнес инструмент, убытки от ошибок несут в первую очередь пользователи. И, соответственно, от этого страдает репутация Битрикс24. Поэтому вероятность ошибок необходимо сводить к нолю. Но в тоже время деплой нового кода должен быть быстрым, так как это дает возможность проекту быстрее развиваться и быстро исправлять ошибки.nnРеализация в Битрикс24 имеет следующую архитектуру:n

Общий этап:

Выделен отдельный сервер обновлений с отдельным балансировщиком, единый и для Amazon и для Российского сегмента. Он максимально эмулирует рабочую среду. Сразу на него разворачивается код нового релиза. Далее с ним работают тестировщики, выполняют нагрузочные тесты. В итоге на этом сервере полностью рабочий код, готовый к выпуску в продакшн.n

Для инфраструктуры на Amazon:

С сервера обновлений в амазоне делается новый образ AMI. Постепенно каждый сервер помечается «плохим». Он выводится из балансировки и стопится, а новые стартуют из нового образа. Для обновления баз данных реализован механизм проверки версии. В случае если клиент с новой версии приложения обращается к старой версии базы, то по требованию происходит ее обновление.n

Для инфраструктуры в России:

Есть дополнительный пул машин, который запускается прямо с сервера обновлений с помощью Ansible. Далее сервера со старым релизом останавливаются, выводятся из балансировки и запускаются сервера с новым кодом. Обновление баз данных реализовано как для Amazon Web Services.n

Stage для обновлений

Проверка кода на эмулированной среде всё равно далека от использования с реальными клиентами. И так как допускались ошибки, был добавлен этап раскатки обновления – stage. Для этого завели отдельную группу машин и реализовали в балансировщике логику, в которой возможно пользователей группами по маске или по именам выводить на нее. Таким образом, релиз после тестирования ставиться на отдельную группу машин, проверяется на живых клиентах. Stage позволяет смелее экспериментировать и сводить ошибки к нолю. В итоге новый код релизится примерно раз в день. Сотрудники 1С-Битрикс выполняют роль первых тестировщиков. Они, испытывая все новшества, дают обратную связь и высказывают свои пожелания по улучшению[3].nnУстановка хотфиксов.nnБерется обычная машина и назначается эталонной. На нее устанавливается код с хотфиксом. И без stage этапа код запускается на всех клиентов.nnссылки:3 https://blog.bitrix24.ru/iz-pervykh-ust-1sbitriks-na-puti-k-uspekhu-s-bitriks24/