Решение: что делать, если ваш сервис на Amazon заблокирован Роскомнадзором

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

Причина проблем. Многим известно, что в попытке заблокировать Telegram Роскомнадзор начал веерно блокировать IP-адреса крупных мировых хостингов, которые Telegram использовал для восстановления работы. Самые крупные из них — Amazon (AWS) и Google Cloud. Многие российские и зарубежные сервисы, использовавшие эти хостинги, оказались заблокированы и стали не доступными через большинство российских провайдеров связи.

Масштаб проблемы. Заблокированными оказались 18 млн IP-адресов и 34 тысяч российских сайтов. Статистику блокировки IP-адресов и числа пострадавших российских сервисов ведёт Филипп Кулин на сайте usher2.club.

Статистика по Amazon:

• Заблокировано подсетей: 116 из 743 (16%).
• Число IP-адресов в заблокированных подсетях: 12,8 млн из 32,3 млн (40%).
• Дата-центров с заблокированными подсетями: 15 из 20 (75%).

Заблокировано большинство старых дата-центров с большим набором сервисов. Пять новых небольших дата-центров полностью не заблокированы. Ещё три новых дата-центра имеют по одной заблокированной подсети.

Как это затронуло нас. Наша облачная бизнес-платформа Bpium оказалась частично заблокирована. Сначала у части клиентов перестали скачиваться файлы, далее начались перебои в работе API. У некоторых клиентов сервис нестабильно работал в течении трёх дней.

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

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

Осознание проблемы. Проблема в том, что новые серверы создаются на IP-адресах в разных подсетях, порой в заблокированных Роскомнадзором. К сожалению, Amazon даёт возможность выбирать лишь макроподсеть, внутри которой множество как заблокированных, так и рабочих подсетей.

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

Выбор решения. Нам потребовалось время, чтобы понять причину несистематичных сбоев у разных клиентов. В этом нам помог Telegram-бот @rkn_block_check_bot. Он позволяет проверить IP-адрес на предмет блокировки Роскомнадзором. Осознав проблему, мы решили попытаться найти незаблокированный Роскомнадзором дата-центр в Amazon (их более 20).

Совет: с помощью бота @rkn_block_check_bot вы можете проверить, попадает ли ваш сервис в заблокированные подсети. Или проверить, почему не работает какой-либо сторонний сервис.

Первым делом мы нашли список IP-адресов всех дата-центров Amazon — миллионы IP-адресов. Встала задача проверить все диапазоны, чтобы найти дата-центр с незаблокированными подсетями.

Мы обратились к Дмитрию Москину, автору Telegram-бота, с просьбой проверить список IP-адресов Amazon по базе заблокированных адресов. Дмитрий согласился помочь, провёл анализ и сделал документ с полным списком IP-адресов Amazon, разделённым по дата-центрам.

Совет: используя этот список, облачные сервисы могут выбрать дата-центр для работы в зависимости от того, какие сервисы Amazon используют. Дмитрий, спасибо!

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

Совет: для переноса файлов между файловыми хранилищами (Amazon S3) дата-центров мы использовали сервис Flexify.io, который посоветовали коллеги из Mail.Ru Group. Для переноса баз данных RDS можно воспользоваться функцией создания «Read replica» в другом регионе, а позже отвязать её от мастера («Promote read replica»), благодаря этому можно обойтись даунтаймом в несколько секунд.

Анализ российского рынка. Во время сбоев мы активно изучали российские хостинги. К сожалению, на нашем рынке мы не нашли ни одного близкого аналога. Российские хостинги на текущем этапе развития предоставляют «голые» серверы, а не готовую инфраструктуру и сервисы. Воссоздать столь гибкое и управляемое облако требует много времени, знаний и больших ресурсов. Контролировать и управлять таким решением сложно, вероятность рисков сбоев высока.

Надежда на светлое будущее. Из российских мы нашли лишь один хостинг, который следует пути развития IaaS — инфраструктуры близкой к идеологии Amazon. Это решение от Mail.Ru Group. Функционально сервис ещё слаб и не подошёл нам, так как ещё не позволяет использовать сертификаты безопасности на балансировщике.

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

#блокировки #amazone #роскомнадзор