{"id":14262,"url":"\/distributions\/14262\/click?bit=1&hash=8ff33b918bfe3f5206b0198c93dd25bdafcdc76b2eaa61d9664863bd76247e56","title":"\u041f\u0440\u0435\u0434\u043b\u043e\u0436\u0438\u0442\u0435 \u041c\u043e\u0441\u043a\u0432\u0435 \u0438\u043d\u043d\u043e\u0432\u0430\u0446\u0438\u044e \u0438 \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u0435 \u0434\u043e 1,5 \u043c\u043b\u043d \u0440\u0443\u0431\u043b\u0435\u0439","buttonText":"\u041f\u043e\u0434\u0440\u043e\u0431\u043d\u0435\u0435","imageUuid":"726c984a-5b07-5c75-81f7-6664571134e6"}

7 лет в облаках: путь «Битрикс24» от Amazon к Multi-Cloud

Соблюдаем 242-ФЗ, 152-ФЗ, GDPR и снижаем риски.

«Битрикс24» выбрал мультиоблачную инфраструктуру еще до того, как это стало мейнстримом. На старте «подошел» Amazon, но со временем американские облака пришлось дополнить российскими. Что стало причиной переезда? Какие ошибки и риски возникли в работе? И почему с Роскомнадзором лучше не шутить?

– рассказал Александр Демидов, директор направления облачных сервисов «Битрикс24»

Что такое «Битрикс24» и зачем ему облака

«Битрикс24» помогает работать 5 млн компаний по всему миру. Решение доступно на 18 языках.

Это «сердце» бизнеса — на приложении строятся ключевые процессы:

  • Внутренние и внешние коммуникации
  • Хранение файлов и клиентских баз данных
  • Ведение задач и CRM

Это еще и платформа для создания лендингов и интернет-магазинов.

Сервис как SaaS-решение появился в 2012 году.

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

Железо vs инфраструктурное облако

К выбору платформы подошли серьезно. Сразу отказались от покупки или аренды «железа»

  • Необходимы вложения в инфраструктуру
  • Трудно масштабировать
  • Сложно администрировать, если «железо» размещается в территориально удаленных датацентрах
  • Пришлось бы создавать сопутствующие сервисы с нуля

«Битрикс24» был нашим внутренним стартапом. Мы не хотели серьезно вкладываться в оборудование и инфраструктуру. В то же время рассчитывали на быстрый рост. Но точных прогнозов не было. Поэтому выбор пал на инфраструктурное облако.

Его преимущества:

  • Требует минимальных вложений на старте
  • Легко масштабировать
  • Удобно администрировать
  • Доступна масса сопутствующих сервисов: облачная DNS, балансировщики нагрузки, автоскейлинг (инструмент для автоматического управления ресурсами и масштабирования ) и объектные хранилища
  • Не нужно самим делать все с нуля ― есть готовое решение, которое сокращает время вывода на рынок. Это критично для сервисов.

В облаке можно быстро выкатывать новые решения для клиентов.

Почему выбрали Amazon

Мы сразу решили работать с этим облаком.

Причин несколько:

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

В чем практический смысл?

У нас бизнес-приложение, поэтому днем активность клиентов выше, чем ночью. Благодаря системе мониторинга Cloud Watch и автоскейлингу в рабочие часы мы запускали больше виртуальных машин, а в нерабочие — меньше. И платили только за ресурсы, которыми пользовались.

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

Облака по обе стороны Атлантического океана

Амазоновское инфраструктурное решение снизило себестоимость и помогло обеспечить отказоустойчивость. Но через год после старта сервиса появились первые технические предпосылки к «переезду» из США в Европу.

Мы поняли, что мало размещаться в одном регионе – это отражается на скорости работы. Нужно, чтобы европейские клиенты пользовались дата-центром, который к ним территориально ближе. И это еще был никакой не Multi-Cloud.

Multi-Cloud — это, когда компания вместо одного облака использует два и более. Бизнес распределяет свои активы, чтобы не зависеть на 100% ни от одного из выбранных облачных провайдеров.

В 2013 году у нас получилось быстро «переехать» в Ирландию и позже — в Германию. Для миграции выбрали тот же самый Amazon и подключили к нему всех европейских и российских клиентов. Так мы:

  • Решили вопросы со скоростью доступа и отклика
  • Обеспечили более комфортную работу с «Битрикс24.Диск», мобильными приложениями, чатами, уведомлениями
  • Продублировали инфраструктуру

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

Тучи сгущаются, или 242-ФЗ

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

Но когда интернет и все, что с ним связано, становится критически важным для работы инфраструктуры и государственных сервисов, власть желает его регулировать. Это неизбежно и есть не только в России — США, европейские страны, Китай разными способами регулируют интернет.

В нашей стране это вылилось в 242-ФЗ, который вступил в силу 1 сентября 2015 года. Закон предписывает собирать и обрабатывать персональные данные граждан России на территории РФ.

В то время наш сервис размещался в зарубежном облаке Amazon. Провайдер не был представлен в России, и это усложняло задачу.

Забить, поиграть в прятки или переехать

Как реагировать на закон? У сервисов, которые хостились за границей, было несколько вариантов.

Первый – «забить» и ничего не делать. Как показывает практика, этот вариант работает до сих пор. Многие небольшие сайты, магазины и сервисы, похоже, рассуждают так: «Мы маленькие, никому не нужны, кто нас придет проверять?»

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

Мы этот вариант не рассматривали из-за репутационных рисков. Клиенты и партнеры приходили к нам и напрямую спрашивали: «Как вы будете соблюдать законы?» Естественно, мы отвечали, что работаем прозрачно и все соблюдаем.

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

Третий – выделить персональные данные и перенести их локально, а остальную инфраструктуру оставить на европейских серверах.

У второго и третьего вариантов много рисков. В 2014–2015 гг. из-за курсовых разниц начались проблемы с оплатой иностранного хостинга в валюте. Кроме того, мы бы начали сильно зависеть от связанности разных сегментов. Любое нарушение могло сильно отразиться на работе сервиса.

И последний вариант – полностью выделить сегмент локальных пользователей и перенести их в Российскую Федерацию. На нем мы и остановились.

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

Выбор облачного провайдера в России

Перед нами снова встал вопрос: «железо» или облако? И вновь мы отказались от первого варианта.

В идеале нам хотелось работать с «русским Amazon». Но в то время в России ничего похожего еще не придумали. Пришлось выбирать из того, что было.

Требования к облаку были базовыми:

• Виртуальные машины с произвольной конфигурацией дисков

• Динамическая тарификация

• Наличие API: стоп/старт машин, подключить/отключить диски, назначить внешний IP

• Снэпшоты дисков и целые образы виртуальных машин

• Балансировщики Level 7, DNS, Firewall, горизонтальное масштабирование, сервисы очередей

Мы были готовы, что часть сервисов придется написать самим.

Сразу отмечу, что сейчас все изменилось. За четыре года российские облачные технологии сильно эволюционировали. Появилось много игроков, которые все больше похожи на тот самый «российский Amazon» в лучшем смысле этого слова. Свои облака запустил “Яндекс” и Mail.ru, сотовые операторы тоже развивают эту нишу.

Рынок облаков

По данным Gartner, объем мирового рынка публичных облачных сервисов в 2019 году вырастет на 17,5% и составит $214,3 млрд.

По оценкам iKS-Consulting, объем российского рынка IaaS (Infrastructure-as-a-service, инфраструктура как услуга) в 2018 году составил 17,4 млрд руб., что на 33% больше показателя 2017 года. Весь объем российского облачного рынка эксперты оценили в 68,4 млрд руб. по итогам 2018 года.

По прогнозам iKS-Consulting, в 2022 году объем рынка облачных услуг в России превысит 155 млрд руб. Доля IaaS увеличится с 25% в 2018 году до 31% в 2022 году.

Ключевые игроки российского рынка: Selectel, Mail.ru Cloud Solutions, «Ростелеком», DataLine, Beecloud, Яндекс.Облако.

«Переезд» в Россию

Процесс проходил в несколько этапов:

  • Вначале мы подготовили территориальные фронтенды
  • Потом развернули тестовую среду и начали миграцию пользователей
  • В конце концов мы полностью переключили «старых» и начали регистрировать новых российских клиентов на территории РФ

Успели в срок – закончили миграцию как раз к первому сентября, когда вступил в силу 242-ФЗ. А еще через три-четыре дня мы переключили регистрацию клиентов.

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

Сюрприз от Роскомнадзора

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

Это случилось 23 марта 2018 г. За несколько недель до блокировки Telegram РКН начал блокировать мессенджер Zello. Федеральная служба разослала крупным операторам письмо с предупреждением: для блокировки мессенджера будет отключено несколько миллионов IP-адресов Amazon.

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

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

Успели.

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

В апреле действительно началась блокировка Telegram, IP-адресов Amazon и других облачных провайдеров. В пиковые моменты под «раздачу» попадали до 20 миллионов IP-адресов, сегодня их количество снизилось до одного миллиона.

Сервисам, которые работают на российский рынок, стало очевидно: необходимо присутствовать на нём локально, чтобы сохранить работоспособность. Масса технических рисков ставит под удар доступность площадки для конечного клиента.

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

Миграция из S3 в HotBox от Mail.ru Cloud Solutions

В ночь с 28 февраля на 1 марта 2017 года сбой в работе Amazon S3 привел к «падению» множества сайтов и сервисов, перебоям в работе IoT-оборудования по всему миру. Тогда проблемы возникли у Trello, Coursera, Quora, Ipple, Pinterest, Airbnb, Netflix, Spotify, умного помощника Alexa. Чтобы восстановить работоспособность, ушло 4 часа 17 минут, но некоторые сервисы оставались недоступными 11 и более часов.

Объектное облачное хранилище S3 в Amazon’е спроектировали с максимальной доступностью и надежностью. Но даже его сервисы могут долго простаивать из-за блокировок и аварий.

Поэтому мы затеяли проект по резервированию S3, в котором хранится около 1 петабайта наших данных и полтора миллиардов объектов.

Миграцию данных из S3 в HotBox (сейчас называется Mail.ru Cloud Storage) запустили совместно с Mail.ru Cloud Solutions (MCS), которая разрабатывает этот сервис.

  • За несколько месяцев протестировали совместимость с API
  • Сформировали список пожеланий по доработкам
  • Получили прекрасный фидбэк
  • И сейчас мигрируем из S3 в HotBox

У нас две задачи: обеспечить отказоустойчивость и быть максимально «близко» к клиентам.

Одно облако хорошо, а два лучше

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

Даже резервирование на уровне дата-центра не поможет:

  • Если возникнут ошибки конфигурации
  • Сыграет человеческий фактор
  • Или произойдут сбои, из-за которых работа остановится

С этим мы, к сожалению, столкнулись. В прошлом году «Битрикс24» пережил болезненную аварию, после которой пришлось принципиально пересмотреть подход к резервированию.

Решили хранить информацию:

  • В двух дата-центрах
  • У двух разных провайдеров
  • Двух юридических лиц

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

Так появился новый проект по миграции данных – к двум компаниям. Одной из них стал наш текущий провайдер Corpsoft24, вторым – Mail.ru Cloud Solutions, который запустил платформу для инфраструктурных проектов Infra (сейчас называется Mail.ru Cloud Servers).

Мы уже работали с коллегами по HotBox, поэтому решили протестировать и Infra. Процесс миграции сделали понятным для клиентов. Выстроили общую схему развертывания в разных средах: в облаке Amazon, в Corpsoft24 и MCS.

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

Зачем нам Multi-Cloud?

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

Первая причина – техническая:

  • Вы географически приближаетесь к потребителям
  • Снижаете риски по сетевым задержкам
  • Устраняете проблемы связанности различных сегментов интернета

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

Законы «О безопасном интернете» или «О суверенном интернете» могут применяться с любой стороны. Потому IT-компании все чаще будут сталкиваться с ограничениями. И присутствие на локальных рынках – обязательное условие.

Вторая причина – юридическая:

  • В России необходимо соблюдать 152-ФЗ и 242-ФЗ
  • В Европе — GDPR
  • В США и Канаде тоже есть законы, которые регулируют размещение персональных данных и прочих сервисов, работающих внутри страны

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

0
Комментарии
-3 комментариев
Раскрывать всегда