В этом учебнике предельно простые и понятные ответы даны на следующие вопросы:
- Почему Amazon не сотрудничает с Роскомнадзором?
- Сколько стоит постоянный перенос серверов Telegram на другие IP-адреса в облаке?
- Почему нельзя запретить сервисы, размещенные на Amazon, по конкретным IP, а не по подсетям сразу?
Когда вы запускаете свой сервис на Amazon, обычно это происходит так: а) вы настраиваете какую-то виртуальную машину, б) установите на него свой сервис, в) проверяешь, что все работает, а потом г) вы делаете из него AMI — полный слепок, образ вашего сервиса вместе с операционной системой и всем остальным, что там есть.
Он хранится в облаке, а затем при необходимости очень легко и просто (а главное автоматически) тиражируется в любом разумном масштабе с автоматической корректировкой.
На скриншоте показан интерфейс, в котором указаны некоторые дополнительные настройки для запуска нескольких экземпляров предварительно настроенного снапшота.
Стрелкой отмечен параметр «Автоматически назначать внешние IP-адреса для каждого экземпляра».
Итак, вот оно.
Когда вы запускаете свой сервис в больших масштабах, вы можете указать Amazon, чтобы он развернул поблизости еще один экземпляр вашего сервиса, когда на процессор виртуальной машины будет определенная нагрузка.
Или, например, сразу сто штук.
Или не тогда, когда процессор находится под нагрузкой, а, скажем, когда одновременно имеется пара сотен активных сетевых подключений.
Такие показатели для автоматическое масштабирование много, и правила автозапуска тоже можно настроить достаточно гибко.
Теперь давайте посмотрим на этот график: 
Это примерное количество одновременно активных пользователей интернет-сервисов по всему миру в рабочее время.
В Тихом океане почти никто не живет, в Китае есть собственный Интернет, а наибольшее количество пользователей находится в Европе, и особенно на западе США.
Это справедливо практически для любого сервиса с мировым покрытием, будь то Steam, Netflix, Wikipedia или Telegram. Как мы видим, разница между максимумом и минимумом составляет полтора раза.
Буквально это означает, что если вы работаете на весь мир, то примерно половину дня, пока в Западном полушарии день, вам потребуется почти в два раза больше энергии, чем другую половину дня, когда в Азии день.
.
Вот вы и настраиваете себе соответствующие правила автоматического масштабирования, чтобы не тратить процессорное время (и свои деньги — в облаках, как нигде, время=деньги) зря в тот момент, когда оно не нужно.
А половина экземпляров вашего сервиса просто убивается самим облаком по расписанию, когда Америка ложится спать.
А на следующий день, когда нагрузка увеличится, снова услужливо поднимет их.
Теперь ответим на вопрос 3).
Стрелка на скриншоте нарисована не просто так.
Опция «Автоматически назначать внешние IP-адреса для каждого экземпляра» берет адреса из доступного пула адресов — Amazon владеет несколькими миллионами, а еще несколько арендует у других владельцев.
Публичный IPv4-адрес сейчас в дефиците, поэтому иметь его для каждого виртуального экземпляра на постоянной основе, независимо от того, работает он сейчас или нет, — большая роскошь — и стоит денег (причем в любом дата-центре Amazon вам дают только 5 постоянных адресов, и они этот лимит увеличивают с очень большим писком).
И как только инстанс убит, адрес тут же возвращается в общий пул.
И так далее.
Кого он ударит следующим? Да любому.
Может быть для вас, а может для другого клиента, который тоже автоматически масштабирует свой сервис, а может для эфемерного экземпляра собственного сервиса Amazon. Таким образом, ответ на вопрос 3) тривиален: потому что сегодня этот IP ваш, а через пару часов он будет чужой.
Если ваш сервис кому-то не нравится, но он автоматически масштабируется, то вы можете забанить его по IP, но только если вы забаните весь пул.
А на вопрос 2) ответ тоже тривиален: вообще не стоит. Облако само назначит следующему инстансу какой-нибудь другой адрес из доступного ему пула, хотите вы этого или нет. Теперь о первом вопросе.
Ответ не столь очевиден, но попробуем сделать то, что называется обоснованным предположением (не знаю, как лучше сказать по-русски, «догадка, основанная на опыте», наверное?).
Амазонка — старейшее из больших облаков.
Программное обеспечение, которое управляет всем этим автоматическим масштабированием, было написано десять лет назад и с тех пор работает как часы.
Сам гигантский сервис Amazon работает точно в том же облаке.
Эта обвязка не сломана, ее не нужно ремонтировать, и любые изменения, которые пишут люди, несут в себе риск внесения ошибок.
Поэтому функция изоляции пулов адресов для клиента, если начать ее разрабатывать прямо сейчас, отнимет чертовски много времени, а если вдруг приведет к большим изменениям, то цена возможных последствий будет в миллиарды долларов.
В самом прямом смысле.
А ответ на 1) звучит так: Amazon просто невыгодно переделывать свою инфраструктуру под требования сумасшедшего государственного надзорного органа, все клиенты которого не приносят достаточно денег, чтобы компенсировать возможный риск для себя.
и клиенты из других стран.
Звучит жестко, но, к сожалению, это бизнес.
Кстати, с остальными облаками все точно так же.
YouTube запретили, поскольку сервисы самого Google не отделены от сервисов клиентов Google и работают в одном облачном пространстве с единым пулом адресов.
То же самое и со службами Microsoft. Роскомнадзор, блокируя облачные сервисы, воюет с технологией, на которой строятся облака.
Со скриптами.
С алгоритмами.
Это все равно что бороться с законами физики или пытаться пнуть стихию: крайне глупо и бессмысленно.
Невозможно победить облака и ветер, можно только уйти под землю и никогда их не увидеть.
Теги: #amazon #Google #облачные сервисы #Роскомнадзор #Telegram #ИТ-законодательство
-
Orm — Отвратительный Антипаттерн
19 Oct, 24 -
Craftable — Генератор Crud Laravel
19 Oct, 24 -
Порекомендуете Vps? Медиапроект, Начало
19 Oct, 24 -
Новые Правила Сервисной Игры
19 Oct, 24 -
Движущиеся Элементы В Прототипе Axure
19 Oct, 24 -
Qpimg — Динамическое Создание Css-Спрайтов
19 Oct, 24
