Цена многорежимности

[ermouth]

На днях анализировал, во сколько обходится конфигурабельность “на лету”, применительно к большой распределённой системе. Прикидывал, во что обойдётся с инженерной точки зрения поддерживать многорежимность работы. В моём случае – перераспределение сервисов по физическим машинам в зависимости от нескольких параметров входящего трафика.

Получилось, что “перевозить” с одних узлов на другие имеет смысл только два сервиса из 12, зато это такие сервисы, которые обслуживают основной поток запросов.

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

У меня получился интересный вывод: на время переконфигурации мне надо иметь в сети дополнительный довольно мощный узел, принимающий на себя существенную часть нагрузки. На время переконфигурации в системе образуется центр “напряжения”, которое со временем “рассасывается” по другим узлам.

Фиговей всего, что этот узел надо поддерживать рабочим всё время. Если узел включать только перед сменой конфигурации сети, время, необходимое на синхронизацию данных, делает всю затею бесполезной. “Приёмистость” конструкции получается многие минуты – а нужны единицы секунд.

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

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

Так выглядят Ту-160 и Rockwell B-1B, тяжёлые стратегические ракетоносцы с изменяемой геометрией крыла:

Отличный пример конвергентной эволюции, как снаружи – так и внутри.

Дело в том, что отклоняемые консоли крыла крепятся к остальной конструкции по сути в двух точках. Это означает сосредоточение огромных напряжений самого разного спектра в очень ограниченном объёме. Более того, эти две точки должны быть жёстко связаны – а они существенно разведены в пространстве (10 метров почти).

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

Вот как выглядит центроплан в этих бомберах (подкрашен синим):

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

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

Comments

[morfizm.livejournal.com]

Есть простой вариант, интересно, почему он не подходит (если ты уже думал о нём).

1. Дизайнишь систему как N как можно более независимых кластеров. Входной поток делится между ними поровну. Нужен мощный load balancer, способный быстро перераспределять трафик между здоровыми кластерами, если один из кластеров нездоров.

2. Каждый кластер имеет реплику каждого сервиса, в нужной тебе пропорции по машинам.

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

Если кластеров N, то в любой момент времени ты можешь гарантированно использовать только (N-1)/N от capacity. Это выглядит вполне приемлемой ценой за атомарное обновление софта. Не нужно думать о backwards compatibility чтобы одни сервисы могли разговаривать с новыми версиями других, и т.п. - т.к. все коммуникации идут только внутри кластера, и ты его грохаешь одним ударом, можно выкатывать атомарно.

[ermouth.livejournal.com]

Думал, конечно. Load balancer – это получается такая же точка сосредоточенной нагрузки.

[morfizm.livejournal.com]

Да, но его можно сделать относительно недорого, чтобы поддерживал немеренную нагрузку. Есть софтварные решения, вроде AWS Elastic Load Balancer (там, на самом деле, создаётся managed sharded service на EC2 instance'ах), есть хардварные (NetScaler).

[ermouth.livejournal.com]

Не, это титановая балка всё.

У меня по условиям задачи никаких специализированных решений, каждый узел – ординарный инстанс на хостинге средней надёжности.

[morfizm.livejournal.com]

NetScaler это титановая балка. ELB - нет, ты платишь пропорционально трафику, оно скейлится transparently, as needed.

Если сервисы такие маленькие, что тебе достаточно одного инстанса, а instance-per-cluster это слишком много железа, то рассмотри вариант контейнеризации. Запускай мини-инстанцы через Docker + Kubernetes. Тогда ты сможешь их иметь сколько угодно. Если ты не на AWS, то можешь load balancer реализовать самостоятельно, отдельным скалируемым сервисом. Я не смотрел, но уверен, что есть готовые опенсорсные решения, причём уже под Docker + Kubernetes.

Фундаментально load balancer это ещё один layer, через который будет проходить весь трафик, и который должен быть способен handle'ить все одновременные соединения. Но так как всё, что нужно делать, это route, pass through, and health checks, это минимальный функционал, и всё должно быть очень быстро на небольшом количестве железа.

[morfizm.livejournal.com]

Ну, т.е. load balancer не нужно воспринимать как "точку". Это не точка. Это распределённый сервис, аналогичный другим распределённым сервисам.

[ermouth.livejournal.com]

> ELB - нет, ты платишь пропорционально трафику

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

Вообще, на Амазоне я бы всё делал по-другому. С лямбдой, ELB, S3 и прочее. Хотя Амазон у меня всё равно будет – как DNS.

> через Docker + Kubernetes

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

> Фундаментально load balancer это ещё один layer

И это значит, что одно соединение _всегда_ превращается в два (до прокси и от прокси до узла). С координатором в два соединения превращается только первое.

[morfizm.livejournal.com]

Про РФ понятно. Действительно, лучше всё крутить в пределах датацентра.

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


> И это значит, что одно соединение _всегда_ превращается в два (до прокси и от прокси до узла). С координатором в два соединения превращается только первое.

На это есть несколько аргументов:

1. Ну и что? Неужели ты скажешь, что у тебя сетевые соединения или bandwidth это bottleneck приложения? Мне кажется общий тренд таков, что сетевые ресурсы всё сложнее и сложнее полностью утилизировать. Bottleneck это память или проц. Чаще проц.

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

3. Второе соединение можно очень долго не закрывать, реюзая его для разных запросов. Оверхед небольшой. Скорее всего, куда больше можно сэкономить на протоколах передачи (скажем, переход с JSON на protobufs).

[ermouth.livejournal.com]

> Неужели ты скажешь, что у тебя сетевые соединения или bandwidth это bottleneck приложения?

Это всё вряд ли будет жить в одном ДЦ. Значит, мне надо исключить ситуацию, что _каждый_ запрос сначала летит в Мск, а потом оттуда в Новосиб, при том что юзер, например, в Иркутске.

Во-первых, неприемлемая latency, во-вторых меж-ДЦ соединения должны быть https. Два https-запроса вместо одного это нехорошо. Даже если соединение не закрывать.

Ну и координатор – это гораздо дешевле.

> Да, но зато гибкость, как раз та, что тебе нужна

Она не необходима, поэтому я по совокупности соображений идею выкинул.

[ermouth.livejournal.com]

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

Хорошо, что ты мне повозражал, спасибо.