Привет! Меня зовут Ренат Ахмеров, я руководитель направления по работе с виртуальными сетями и сетевыми функциями в MWS Cloud Platform. В этой статье я расскажу про сетевые возможности нашей облачной платформы, приправляя рассказ своей личной историей взаимоотношений с компьютерными сетями. 

Чтобы наглядно объяснить, как работают сети в нашем облаке, мы рассмотрим по шагам построение некой e-commerce системы: от примитивного решения в одной «коробочке» до полноценной Enterprise Grade-архитектуры.

30 октября 2025 случилось одно из важнейших событий в моей профессиональной жизни. Если не самое важное. После примерно двух лет труда наша большая дружная команда запустила в открытый доступ публичное облако MWS Cloud Platform и провела впервые конференцию MWS Cloud Day, приуроченную к этому событию. 

На конференции я рассказывал про сети, а именно про то, какие возможности сервис VPC предоставляет пользователям. После этих слов, конечно же, можно задаться вопросом: «А зачем же мне читать эту статью, если я уже видел этот доклад либо могу пойти потратить 25 минут и посмотреть его?» Давайте поясню. 

Дело в том, что подготовка подобного рода выступлений — это достаточно сложная совместная работа многих людей (докладчика, супервайзера, дизайнеров, корректоров, маркетинга и т. д), в ходе которой для докладчика, как я это называю, определяется своего рода «туннель повествования» таким образом, чтобы соответствовать духу конференции, не наврать с точки зрения маркетинга, не обмануть слушателей в ожиданиях, а мы, поверьте, к этому относимся максимально серьёзно, соблюсти тайминг и т. д. Поэтому! Считайте, что эта статья — моя «режиссёрская версия» того выступления, где я могу выйти за рамки этого самого туннеля и рассказать обо всём более развесисто, добавив деталей и рассуждений.

Как всё начиналось

Так почему же это было, возможно, самое важное событие в моей профессиональной жизни? Дело тут в том, что сошлось много звёзд таким образом, чтобы я мог наконец сказать себе: «Мы добились очень серьёзного результата, которым можно гордиться в рамках очень и очень амбициозного проекта». Конечно, были и раньше успешные проекты, которыми я очень горжусь. Но здесь — публичное облако, построенное за два года! 

А ещё ирония, что мой вклад здесь — это развитие виртуальных сетей в качестве руководителя, хотя я не сетевик, с какого ракурса ни посмотреть на мою прежнюю карьеру и образование. Забегая вперёд, скажу, может быть, странное: отсутствие значительного опыта в сетях до этого проекта, пожалуй, было и к лучшему.

Сказать честно, я всегда побаивался компьютерных сетей, даже можно сказать, обходил их стороной, такая уж была профессиональная фобия, что ли. Когда я начинал карьеру, то программирование меня привлекало тем, что там я видел некую стройность и гармонию во всём. Каждый язык программирования, с которым я сталкивался, был по-своему продуман, а вот в сетях было столько много странного, на первый взгляд нелогичного и ужасно сложного! Куча устройств, протоколов, функций — всё это представлялось в моей голове каким-то нагромождением, где не всегда одно с другим явно связано. Непонятные концепции и прочее, прочее.

И вот наконец спустя 20 с чем-то лет, после того как я проработал разработчиком и техлидом разработки на паре-тройке десятков проектов, меня позвали строить новое публичное облако, да ещё и одним из руководителей направления виртуальных сетей. Сам челлендж был настолько крутым, что отказаться я попросту не нашёл сил. Погрузиться в сети и наконец в них что-то понять, а ещё и во многом систематизировать это понимание в головах целой большой команды да и у ряда пользователей будущего облака тоже. Уух!

Ещё готовясь к конференции MWS Cloud Day, я всерьёз задумался над тем, как вообще рассказать про то, что мы в итоге сделали в рамках сервиса VPC. Одна из важных, на мой взгляд, вещей, которая у меня быстро всплыла в голове, такая: в студенчестве я подрабатывал системным администратором, мне приходилось лезть в различные интерфейсы разных устройств, всяких цисок и т. п., и настраивать там кучу разных не всегда понятных параметров, истинное значение которых понимают только избранные, чтобы в итоге заставить сеть работать нужным образом. У меня, по крайней мере вначале, всё это вызывало серьёзные сложности.

А теперь представьте себе виртуальную сеть в облаке, куда пользователь приходит, накликивает какие-то сущности через публичное API и получает виртуальное сетевое окружение. Хотим ли мы весь этот железячный низкоуровневый сетевой мир перетаскивать на это самое API и заставлять пользователя в этом всём разбираться? Вопрос как будто риторический, не правда ли? 

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

Отдельная, конечно же, «приятная» вещь здесь, которая всё усложняет, — это необходимость обратной совместимости при развитии API, но об этом как-нибудь в другой раз, ибо тема эта совершенно бездонная.

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

Огромная, кстати, работа в этом всём — это как раз вычленить это существенное. С точки зрения попадания в пользовательскую аудиторию, важная часть пользователей, на которых мы ориентируемся, — это разработчики, которым, как правило, нет интереса возиться с тонкими настройками, им нужно дать возможность сформулировать свои потребности в простом виде. При этом у них должна быть возможность реализовать в облаке как простые, так и сложные конструкции. А вторая часть аудитории — опытные сетевики, которым нужно больше контроля, то есть те самые тонкие настройки, про которые я говорил ранее. И как-то нужно всем угодить. 

Вот как раз об этом всём я далее и попробую рассказать на примере построения корпоративной системы в облаке. А заодно попробую раскрыть мысль о том, почему сети в облаке — это и просто и сложно одновременно.

Пример: строим e-commerce систему

Давайте сделаем сложное! Мысленно построим e-commerce систему и разместим её в нашем облаке. Что это конкретно за система, в целом неважно, это может быть система «Букинга» отелей, система микроплатежей, CRM-система и т. д. Важно здесь то, что зачастую такие системы используют похожие архитектурные принципы для решения одних и тех же вызовов (CAP-теорему никто не отменял, в конце концов) и строительные блоки. И одна из моих задач — это как раз познакомить вас с этими строительными блоками, которые наше облако, а точнее сервис MWS Cloud Platform VPC, предоставляет пользователям для того, чтобы укротить сеть было проще.

Решение «на коленке»

С чего бы начать? Ну, по старой программистской, как мне кажется, доброй привычке я бы предложил всю нашу систему, а точнее некий её прототип, сначала впихнуть буквально в одну виртуальную машину в облаке и поместить её в некое сетевое окружение, чтобы она стала минимально полезной. Чтобы по крайней мере какие-то тестовые пользователи могли слать на неё запросы. На этой виртуалке ставим всё, что нужно для реализации как фронтенда, так и бэкенда. Какой-нибудь Denwer или нечто подобное в помощь. И вот теперь начнём говорить про сети и про то, как они устроены в MWS Cloud Platform. 

К слову говоря, совокупность сервисов для управления облачными сетями пользователей, так уж повелось, в индустрии обычно называется Virtual Private Cloud, или сокращённо VPC. Мы не исключение, поэтому часть облачной платформы MWS Cloud Platform, связанную с сетями, мы назвали MWS Cloud Platform VPC.

Базовый сетевой минимум

Итак, чтобы виртуалка была в сети, нужно создать эту самую сеть. Соответственно, сеть (Network) — это и есть самая первая и самая важная сущность в нашем API.

Сеть (Network) — виртуальный облачный аналог компьютерной IPv4-сети в организации. Представляет из себя изолированное окружение с адресным пространством, описываемым RFC 1918. В нотации CIDR это диапазоны адресов: 10/8, 172.16/12 и 192.168/16. Эти диапазоны адресов специально придуманы как немаршрутизируемые (из интернета) и повсеместно используются в локальных сетях.

Чтобы наша виртуалка стала доступной в созданной сети, скажем, из других виртуалок, нужно выделить и связать с ней некоторый IP-адрес. Однако сам по себе адрес выделяется не напрямую из сети, а из некоторой подсети, которая служит более мелким сегментом всей сети.

Подсеть (Subnet) — сегмент облачной сети. Определяется более узким диапазоном адресов, например 10.0.1.0/24.

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

Вообще говоря, планирование сетевого пространства, нарезание подсетей — важная часть создания всей облачной IT-инфраструктуры организаций, да и не только облачной. Через подсеть можно распространять общие настройки для группы виртуалок через протокол DHCP. Практика показывает, что у многих людей DHCP ассоциируется с выдачей IP-адресов хостам, однако через него можно раздавать много чего. 

К примеру, в DHCP-настройках подсети можно указать адрес DNS-сервера, к которому будут ходить виртуалки, чтобы резолвить любые имена. К слову, по умолчанию виртуалки используют нашу систему Private DNS, которая на данный момент умеет резолвить имена виртуалок в той же сети и имена хостов в интернете через специальные, так называемые рекурсивные, DNS-серверы, которые умеют в том числе и правильно кешировать внешние записи.

Когда хотя бы одна подсеть создана, из неё можно выделить адрес.

Адрес (Address) — IP-адрес сетевого ресурса в облачной сети. Всегда выделяется в некоторой подсети. Может присваиваться виртуальным машинам и другим ресурсам сети.

Этот объект мы зачастую ещё называем «внутренний адрес», это даже более точный термин, а почему это так — увидите далее.

В итоге получаем следующую картинку.

И вот теперь, после того как нашей виртуалке присвоен адрес, она становится, ну скажем так, минимально полезной с точки зрения сетевого доступа к ней. Если предположить, что в той же сети есть ещё одна виртуалка, они уже могли бы слать друг другу IP-пакеты. Но только внутри самой сети!

Доступ в интернет (и из него)

Представим теперь, что мы захотели слать запросы к нашей системе из интернета. Тут уже не обойтись без публичного адреса, которым наш ресурс (виртуалка) может представляться в сети Интернет. Несмотря на то что термин «публичный адрес» уже укоренился в головах многих людей, наш следующий ресурс API, который с ним ассоциируется, называется «внешний адрес». А причина проста: с точки зрения нашего облака есть много внешних сетей. Это всевозможные корпоративные сети наших клиентов и интернет. Механика работы с этими сетями мало чем отличается. А раз есть внешние сети, то логично адреса для представления наших облачных ресурсов в этих сетях называть внешними адресами. 

«Публичный адрес» — это частный случай внешнего адреса для интернета. Ну и если вспомнить, что у нас есть ещё понятие внутреннего адреса, то получается полная симметрия «внутренний — внешний». О работе с другими внешними сетями (помимо интернета) будет чуть позже, где речь пойдёт о так называемом интерконнекте.

Итак, следующий важный ресурс:

Внешний адрес (ExternalAddress) — IP-адрес сетевого ресурса во внешней сети, например в интернете. В случае с интернетом выделяется из некоторого общего для всего облака пула адресов.

Поскольку внешних адресов, в сравнении с внутренними, ограниченное количество, то они платные (опять же в случае интернета!).

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

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

• Внешние адреса платные, и возникает естественное желание их экономить, например, через переиспользование одного адреса многими ресурсами, а значит, связь «один к одному» в принципе не всегда валидна. 

Для связывания внутреннего адреса с внешним мы ввели специальные ресурсы в API, которые реализуют сетевую функцию NAT (Network Address Translation), то есть трансляцию адресов. На данном этапе построения нашей e-commerce системы нам можно использовать разновидность NAT, которая называется One-To-One NAT.

One-To-One NAT (OneToOneNat) — ресурс, транслирующий конкретный source-адрес исходящего IP-пакета в некоторый конкретный внешний. И обратно для входящего пакета.

Здесь следует отметить одно важное свойство One-To-One NAT. А именно: он ничего не делает с заголовком source port пакета. Source Port, в общем-то, придуман для того, чтобы понять, как обрабатывать обратный трафик в случае множества пользовательских сессий. Если кратко, Source Port — идентификатор клиента на некотором хосте (ассоциирующимся с source address), посылающим пакеты, который потом используется для маршрутизации обратного пакета.

В данном случае Source Port пакета всегда соответствует Dest Port пакета, а это даёт возможность построить полноценный двусторонний канал связи. Например: из интернета можно слать запросы на соответствующий внешний адрес по порту 22 (SSH), и, пройдя через NAT, на виртуалку также придёт пакет на порт 22. Это самая простая разновидность NAT, если точнее, SNAT, то есть Source NAT, которая бывает полезна в простых сценариях. О более сложном чуточку далее.

---

Если вдруг у кого-то на предыдущем параграфе слегка «сломалась» голова, очень рекомендую познакомиться с тем, как в общих чертах устроен IP-пакет, в частности, узнать, что такое Five tuple, и разобрать пару основных сценариев сетевого взаимодействия. Например, как веб-браузер общается с некоторым удалённым сервером по протоколу HTTP. Это и полезно в целом, и облегчит понимание текста данной статьи. Далее будем предполагать, что читателю такие вещи известны.

---

В итоге получаем уже следующую картинку.

И вот теперь, казалось бы, можно ходить из интернета к нашей виртуалке и всё должно работать. Однако кое-чего всё же не хватает. Как было сказано ранее, One-To-One NAT преспокойненько транслирует IP-адреса, никак не трогая порты. Всё пространство портов внешнего, а значит, и внутреннего адреса становится доступным снаружи. Включая всевозможные нежелательные, связанные с различными службами. Например, Telnet, SSH и т. д. При том что в нашем сценарии нужно ходить всего-то на один порт, традиционно используемый для HTTP. Так сложилось, что разработчики на тестовых окружениях любят, например, порт 8080.

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

Для того чтобы предоставить доступ на входящий трафик по определённому порту определённого адреса, в нашей модели требуется создать так называемое правило файервола. Как известно, термин «файервол» ассоциируется с неким механизмом фильтрации сетевого трафика. По сути, можно сказать, что совокупность правил файервола и определяет, как он настроен в облачной сети MWS Cloud Platform.

Правило Firewall (FirewallRule) — ресурс, определяющий правило прохождения IP-пакетов облачной сети. Правила бывают разрешающие и запрещающие, на входящий и исходящий трафик.

Для того чтобы наш пример заработал, нужно создать разрешающее правило файервола на входящий трафик для порта 8080. Можно его даже ограничить одной конкретной виртуальной машиной, указав в правиле соответствующий destination IP-адрес.

И вот это уже будет итоговая картинка для данного этапа разработки. Наша виртуальная машина будет доступна внутри облачной сети, а также извне. Использованные сущности публичного API сервиса MWS Cloud Platform VPC по сути — некий гигиенический минимум, без которого нельзя обойтись.

Масштабируем разработку

Некий прототип нашей e-commerce системы мы таким образом получили. Что дальше? На практике happy path развития проекта может выглядеть так: мы показываем получившийся прототип бизнес-руководству, они говорят: «Отлично, вот вам ресурсы, делайте дальше уже по-серьёзному».

Итак, получив ресурсы: людей, деньги, железо, что бы мы сделали дальше? Мне кажется логичным отмасштабировать разработку. Организационно это значит сформировать несколько команд и разделить между ними ответственность и задачи проекта.

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

Каждому сервису своя подсеть

С точки зрения сети всё это означает, что мы можем ресурсы каждой команды разместить в отдельной подсети, которая, как уже было сказано ранее, — удобный домен управления. В нашем сервисе VPC есть важный нюанс, который нужно учитывать: подсети одной сети по умолчанию имеют свободный доступ к ресурсам друг друга, то есть могут беспрепятственно слать друг другу пакеты и они будут доходить до адресата.

---

Здесь я немного отойду в сторону и немного поясню кое-что. Сама по себе связанность ресурсов внутри облачной сети — это очень сложная низкоуровневая магия, основанная на методах инкапсуляции пользовательского пакета и необходимой для маршрутизации пакета информации в пакет IPv6 Underlay-сети, и затем декапсуляции на нужном сервере и передаче гипервизору, основанная на технологии под названием SRv6 (Segment Routing over IPv6). Именно на ней мы строим свою Overlay-сеть. 

Кстати, о терминах: 

Underlay-сеть — если угодно, «железячная» IPv6-сеть, в которую у нас объединены Compute-серверы с виртуалками. О том, как устроена Underlay-сеть у нас в облаке, писали в этой статье.

Overlay-сеть — мультитенантная IPv4-сеть, которая доступна нашим пользователям и построена поверх Underlay. Вопрос о том, как работает связанность ресурсов пользователя, — это вопрос о том, как устроена Overlay-сеть. Рассказали об этом в статье на Хабре.

Отдельный пункт, который, к моему сожалению, совсем не умещается в рамки этой статьи (возможно, в другой раз) — это механизмы управления пользовательскими сетями, т. е. нарезание новых сетей и их модификация. Ведь это всё динамические сущности, управляемые действиями пользователя.

Ранее мы делали небольшой экскурс в устройство нашей Overlay-сети в рамках реалити-проекта Building the Cloud в эпизоде № 6.

---

Итак, предположив, например, что наша система состоит из сервиса складского учёта, сервиса работы с заказами и сервиса финансовых операций, получаем следующую картинку.

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

Доступ в интернет (опять)

В реальной жизни, несмотря на то что в подобном сетапе не нужен доступ ко всем облачным ресурсам из интернета, самим же облачным ресурсам, как правило, нужен доступ в интернет для того, чтобы скачивать установочные образы, пакеты, известные конфиги и т. п. Ранее мы уже упоминали про ресурс One-To-One Nat в сочетании с внешним адресом для решения задачи выхода виртуалки в интернет, однако на данном этапе виртуалка не одна и использование отдельного внешнего адреса на каждую может быть делом расточительным. И здесь может помочь наш следующий ресурс.

Egress Nat (EgressNat) — ресурс, предоставляющий одной или нескольким подсетям исходящий доступ в интернет и использующий один или несколько внешних адресов для этого.

Важное отличие от One-To-One Nat в том, что теперь всё пространство портов внешнего адреса делится между виртуальными машинами подсетей, для которых создан Egress Nat. Под капотом порты для отдельных виртуалок выделяются по мере того, как те отправляют сетевые пакеты. И поскольку заранее неизвестно, какие порты достанутся виртуалкам, то полноценный двусторонний канал сделать нельзя и внутреннее устройство Egress Nat запрещает установление входящих соединений в принципе. Подробнее о технологии написали в статье на Хабре.

Однако для исходящего трафика это отличное решение, которое позволяет через небольшое кол-во внешних адресов — на практике чаще всего хватает одного — выпускать в интернет большое количество виртуалок. Если изначально выбранных внешних адресов перестало хватать, то всегда можно добавить новые и таким образом увеличить общую портовую ёмкость. 

Достаточно ли этого для выхода в интернет? И да и нет. «Да» — в смысле, что всё будет работать, если создать сущности, о которых мы уже поговорили. «Нет» — потому что мы не рассмотрели ещё одну важную вещь, а без неё картина будет неполной.

«Поезда и стрелки»

Давайте зададимся вопросом: «А как облако и его сервис VPC вообще понимают, какие сетевые пакеты куда отправлять? Какой пакет нужно отправить на хост X, где живёт виртуалка Y, а какой вообще нужно отправлять в интернет?» Не буду томить и повторять мантру про поезда и стрелки, а скажу прямо: это управляется сетевыми маршрутами.

Маршрут (Route) — ресурс, описывающий правило направления сетевого пакета для некоторого множества облачных ресурсов. Характеризуется CIDR-префиксом назначения и интерфейсом (в сетях next hop), на который нужно отправить пакет.

И вот теперь мы получаем следующую картину.

В нашем примере мы имеем маршрут с префиксом 0.0.0.0/0, который в сетях называется маршрутом по умолчанию (Default Route). В целом маршрут для конкретного пакета находится по известному правилу Longest Prefix Match («наиболее узкий диапазон, включающий dest-адрес пакета»). Маршрут по умолчанию как раз-таки проигрывает всем прочим маршрутам, то есть применяется только в том случае, если не нашлось никакого другого подходящего маршрута. 

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

Интерфейс, или чаще всего это называется next hop, данного маршрута internet-gateway. По сути это некая виртуальная с точки зрения пользователя штука, существующая в единственном экземпляре в облаке, которая умеет перенаправлять сетевые пакеты в интернет и обратно, до нужной виртуалки в случае обратного трафика. 

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

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

Защищаем доступ в корпоративную сеть

Если мы вернёмся обратно к проектированию нашей e-commerce системы, то увидим, что у нас есть сервис финансовых операций. Предположим, у нашей компании уже есть набор сервисов внутри корпоративной сети, которые мы просто хотим переиспользовать для реализации. Понятно, что раз речь о финансах (хотя не только в этом дело), то хотелось бы максимально защитить соответствующий сетевой трафик. Как это сделать? На данной стадии развития проекта я бы предложил построить IPSec-туннель в корпоративную сеть.

Для настройки IPSec-туннеля делаем следующее:

• Создаём виртуалку в отдельной подсети, например 172.16.0.0/24. Назовём эту виртуалку IPSec VM, и пусть у неё будет адрес 172.16.0.10.

• Устанавливаем на IPSec VM софт для туннелирования и настраиваем его. К примеру, StrongSwan.

• Настраиваем для IPSec VM двусторонний доступ в интернет, для этого ей даём отдельный внешний адрес и создаём уже упомянутый One-To-One NAT, здесь вдаваться в подробности не будем, всё предельно просто.

• Далее чуть заковыристей. На удалённой стороне (в корпоративной сети) выделяется некоторый доступный извне диапазон адресов, причём, как правило, в сером адресном пространстве. 

Важно: в облачной сети не должно быть подсети, соответствующей этому диапазону. По сути, цель наша и состоит как раз в том, чтобы, ходя из облака в какой-то серый диапазон адресов, мы на самом деле попадали на туннелирующую виртуалку (IPSec VM) и далее через неё в корпоративную сеть через интернет. Предположим, таким диапазоном будет 10.10.0.0/16.

• Объясняем виртуалкам в наших подсетях, что пакеты, идущие от них на адреса в диапазоне 10.10.0.0/16, должны попадать на IPSec VM. Для этого нам нужно создать маршрут, где dest prefix будет как раз равен 10.10.0.0/16, а в качестве интерфейса перенаправления (next hop) должен быть указан адрес IPSec VM, то есть 172.16.0.10.

Таким образом, получаем следующую схему.

Самое важное в этой истории с маршрутами то, что в качестве next hop’а могут выступать разные вещи, и в том числе конкретные IP-адреса конкретных виртуалок. Часто такой вид маршрутов в сетях называют статическим. Таким образом, мы решили проблему приватного доступа к готовым сервисам, живущим в корпоративной сети.

---

Конечно, описанная здесь инструкция очень рамочная и подсвечивает только самые важные аспекты, связанные с управлением сетевым трафиком. Более полная инструкция содержит массу деталей. Например, туннелирующая виртуальная машина должна уметь работать в режиме переадресации IP-пакетов (IP forwarding). Для этого требуется соответствующим образом сконфигурировать и облачный ресурс этой виртуальной машины, и гостевую операционку, чтобы сетевой стек на ней позволял форвардить пакеты. 

Также есть много нюансов, связанных со StrongSwan, которые явно выходят за рамки данной статьи. С более подробной инструкцией можно ознакомиться в нашей официальной документации здесь: https://mws.ru/docs/cloud-platform/vpc/general/vpc-s2s-vpn-setup.html

---

Итого

Итак, в завершение этой части подытожим, что мы уже сделали (пропускайте, если и так всё хорошо запомнили!):

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

• Сделали доступ в интернет через Egress Nat для виртуалок для того, чтобы они могли скачивать всё необходимое для своей настройки. При этом, что важно, использовали для этого всего один внешний IP-адрес. Практика показывает, что для десятков виртуалок одного адреса действительно хватает. Помним, что всегда можно добавить ещё, если портов перестало хватать.

• Разобрались с маршрутами, и в том числе почему облако сразу знает, какие пакеты нужно отправлять в интернет.

• Построили IPSec-туннель, чтобы использовать готовые корпоративные инструменты для сервиса финансовых операций по защищённому на уровне L3-L4 каналу. Для этого настроили маршрутизацию пакетов через туннелирующую виртуалку посредством создания статического маршрута (маршрута на IP-адрес).

А теперь вопрос? Тянет ли всё описанное на архитектуру Enterprise-уровня, где на первый план выходят такие вещи, как поддержка огромного количества пользователей и высокой нагрузки в целом и обеспечение высокой доступности нашей системы. По крайней мере опытный в построении таких систем читатель наверняка уже заметил ряд моментов в нашем текущем решении, которые мешают достижению этих целей. Давайте далее посмотрим на эти моменты и попробуем предложить решение для каждого из них.

Решение Enterprise-уровня

Больше пользователей

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

Сегодня бизнес устраивают одни характеристики системы, а через месяц или два, с ростом бизнеса (к чему все стремятся), — совсем другие. Представим, что каждый сервис у нас теперь представлен не одним экземпляром, а несколькими репликами. В таком случае возникает задача входящий пользовательский трафик извне облака каким-то образом распределять между ними. И такого рода распределителем в MWS Cloud Platform служит специальный сервис, который мы называем «Сетевой балансировщик нагрузки».

Сетевой балансировщик нагрузки (NetworkLoadBalancer) — высокопроизводительный отказоустойчивый сервис, который принимает сетевой трафик и равномерно распределяет его между виртуальными машинами в облачной сети. Работает на уровнях L3-L4 модели OSI.

При создании сетевого балансировщика нагрузки ему присваивается внешний адрес и порт, на который он должен принимать запросы, а также список внутренних адресов, которые мы в контексте балансировщика называем рилами (от англ. real), между которыми он должен распределять нагрузку. 

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

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

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

Ещё одна важная вещь — управление сетевыми сессиями: если установлена клиентская сессия с некоторым рилом, то трафик от того же клиента продолжает ходить туда, в один и тот же рил, до тех пор, пока сессия не закончится. И всё это корректно работает даже в условиях постоянных изменений топологии рилов.

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

---

Если вы хотите углубиться в детали нашего опыта построения балансировщика нагрузки, посмотрите 11-й выпуск нашего реалити-проекта Building the Cloud по ссылке.

---

Больше сервисов для сервисов

Вернёмся к проектированию нашей e-commerce системы.

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

Важно отметить, что здесь речь идёт только о внутриоблачном трафике в отличие от первого случая, а потому может возникнуть вопрос: мы предоставляем одно решение и для внешнего входящего трафика, и для внутреннего? Ответ таков: и да и нет. «Нет», потому что это два технологически разных решения, и «да» — потому что внешний и внутренний сетевые балансировщики нагрузки представлены в API одним ресурсом, который просто нужно по-разному конфигурировать. В итоге получаем следующую картину.

На данный момент сетевой балансировщик уже доступен в режиме Preview, который даёт возможность попробовать им попользоваться бесплатно и оставить для нас обратную связь, которую мы отработаем до GA-релиза.

Надёжный канал в корпоративную сеть

Какие ещё проблемы нам нужно решить на пути к enterprise grade решению? К примеру, всё ли хорошо с нашим IPSec-туннелем, где ключевым элементом служит тунеллирующая виртуалка, на которую проброшен статический маршрут (маршрут на внутренний IP-адрес) для того, чтобы ресурсы сети могли заруливать исходящий трафик на неё? Как несложно понять, эта тунеллирующая виртуалка служит в нашей архитектуре единой точкой отказа. Она падает, и шифрованный L3-L4-канал до on-prem сети пропадает, а значит, наш сервис финансовых операций прекращает свою работу. Никаких механизмов автоматического восстановления этой конструкции нет.

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

Для организации безопасного доступа к облачным ресурсам MWS Cloud Platform предлагает технологию Interconnect. Можно сказать, что Interconnect — это некое общее название, кстати говоря, прижившееся в мире публичных облаков, за которым скрывается набор технических и организационных инструментов для организации (внимание!) прямого доступа из корпоративной сети организации клиента в облачную сеть, минуя интернет вообще. Как это делается? Ответ: очень сложно. Возможно, мы выпустим в обозримом будущем отдельную статью и/или выпуск реалити на эту тему.

Главное в технологии Interconnect заключается в том, что организация и MWS Cloud Platform налаживают прямое физическое соединение, производится некоторая настроечная магия на стороне облака и далее в облачном проекте у клиента появляется ресурс NAT-шлюз (NatGateway), который можно указать в качестве next hop в некотором пользовательском маршруте. И пакеты, соответствующие этому маршруту, будут перенаправляться в корпоративную сеть. 

Ранее мы уже упоминали, что различные корпоративные сети, с которыми мы стыкуемся, и интернет мы называем внешними сетями. Они действительно внешние по отношению к нашему облаку. На данный момент в интернет мы всегда ходим, применяя функцию NAT, из-за того что нам нужно сделать преобразование адресов (внешний адрес нельзя назначить виртуалке напрямую). И описанный чуть ранее способ доступа в корпоративную сеть также осуществляется через NAT, то есть мы считаем, что в корпсети своё адресное пространство, из которого для облачных ресурсов выделяется некий диапазон адресов и пакеты, идя туда, NAT’ятся. 

При этом все механики работают абсолютно симметрично с тем, как работает доступ в интернет. По этой причине шлюз в ресурсной модели, предоставляющий доступ таким образом, содержит в названии NAT. И более того, для доступа в интернет предсоздаётся специальный read-only NAT-шлюз с фиксированным именем internet-gateway.

Мы отдаём себе отчёт в том, что на самом деле наличие NAT в цепи доступа к корпоративной сети может быть неудобным моментом в некоторых случаях. По этой причине наша команда на данный момент работает над технологически более сложным решением с рабочим названием Cloud Interconnect, которое позволяет осуществлять прямой BGP-стык между корпоративной и облачной сетью, при этом NAT не требуется — мы буквально объединяем два адресных пространства в одно, обмениваясь маршрутами по протоколу BGP.

В настоящий момент организация соединения через Interconnect возможна по заявке, команда работает над тем, чтобы этот процесс становился проще для пользователей.

Таким образом, возвращаясь к нашей e-commerce системе, получаем следующую картинку.

Конечно же, нужно понимать, что Interconnect — это решение прежде всего для больших организаций, у которых есть возможности организации прямого стыка. VPN-туннель — легковесное решение проблемы настройки безопасного доступа через интернет. Наша команда, понимая это, рассматривает возможность предоставления специального облачного сервиса для построения VPN-туннелей, который уже не будет обладать недостатками описанного наивного решения на виртуалке.

Надёжные хранилища

Что ещё в нашей e-commerce системе осталось неотказоустойчивого? И тут давайте вспомним, что во второй фазе построения системы мы решили, что у каждого сервиса есть своя база данных. И это тоже проблемное место, потому что, если база упала, работа целого сервиса прекращается. Если этим сервисом пользуются другие сервисы, то страдают и они. 

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

В MWS Cloud Platform для решения этой проблемы на помощь приходят Managed-сервисы. На данный момент в GA запущены Managed Postgres для организации кластеров баз данных, Managed Kafka для кластеров Kafka и в режиме Preview работает Managed ClickHouse.

Важно в этой истории следующее: само слово Managed в названии этих сервисов буквально означает «управляемый» и имеется в виду именно «управляемый облаком». Пользователь только делает запрос на создание нужного ресурса, например кластера Postgres, получает точки доступа к нему и пользуется. Всю сложность развёртывания, операционной поддержки, масштабирования, обновления и т. п. полностью берёт на себя облако и предоставляет высокие гарантии доступности сервиса.

Внимательный читатель может спросить: это всё здорово, но при чём тут вообще сети, когда мы говорим о базах данных и Kafka? Во-первых, хочется дать читателю ещё одно направление, в котором можно двигаться при изучении возможностей MWS Cloud Platform. А во-вторых, интересный момент здесь в том, что все эти сервисы на самом деле под капотом используют весь арсенал возможностей Overlay-сети, который мы разрабатываем. 

К примеру, внутренний сетевой балансировщик нагрузки уже давно работает внутри Managed-сервисов, несмотря на то что публично он стал доступен только недавно. Помимо этого, используется технология Private Link для организации доступа типа «клиент-сервис» между двумя облачными сетями, которую мы планируем позже в этом году вывести в публичный доступ.

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

Конечно же, есть ещё очень много всяких технических тонкостей, которые мы не затронули, и архитектура реальной системы на самом деле гораздо сложнее того, что мы получили. Основной фокус в этой статье именно на том, как мы на примере построения некой бизнес-системы строим пользовательскую сеть в MWS Cloud Platform и как мы управляем сетевым трафиком.

Заключение

В заключение хочется немного поделиться своими мыслями о том, как в итоге прошло моё погружение в сети при построении облака. Будучи базово разработчиком, я понимал, что у меня нет шансов за короткое время освоить всё то, что настоящие сетевые эксперты (как мы говорим, «настоящие сварщики» ?) осваивают годами реальной практики и перед этим ещё окончив какой-нибудь профильный вуз. Мне в таких условиях всегда хочется понять: а где же я могу принести ту самую пользу, ради которой меня позвали работать в эту компанию? Само собой, была разработка, которую я во многом помогал «поставить на ноги», но это было дело понятное и привычное. А вот именно по части сетей… 

Ответ, однако, нашёлся довольно быстро: я осознал, что всю ту сложность сетевого мира, с которой я сам столкнулся, я как раз и могу помочь облечь в какую-то простую форму для пользователя. И как я говорил уже ранее, небольшой начальный опыт в сетях, как мне кажется, тут был на руку: я ещё в состоянии смотреть на сетевой домен свежим взглядом, прямо как многие наши пользователи, и задавать, возможно, наивные, но очень нужные вопросы типа: «а зачем нам это вообще нужно?», «а как мы это можем упростить?», «а для каких реальных сценариев мы хотим реализовать эту фичу?» и так далее.

Конечно, качественное API возможно сделать, только хорошо понимая предметку, и у нас как раз есть топовые сетевые эксперты, которые с нами работают бок о бок. Всю нашу работу невозможно было бы выстроить без них. И как мне кажется, этот самый симбиоз навыков разработчика и сетевика даёт весьма интересный результат: мы научились очень сложные сетевые вещи упаковывать в очень простые, но расширяемые интерфейсы, на которых можно строить как самые простые бизнес-кейсы, так и весьма заковыристые конфигурации с большими возможностями тюнинга разных сетевых аспектов.

Пользуйтесь нашим облаком и приходите в сообщество MWS Cloud Platform в Телеграме, чтобы обсудить решения, архитектуру или задать вопросы. В чате отвечают инженеры облака.