Что такое service mesh

Я бы начал с базового определения, что service mesh — это в первую очередь подход, который имеет множество конкретных реализаций. Основной смысл в том, что когда у нас есть какая-то распределённая система, которая работает, взаимодействует по сети, мы добавляем дополнительный сетевой уровень, который позволяет нам добавлять какие-то возможности, любую логику в межсервисное взаимодействие сетевых узлов.

Если говорить более простыми словами, когда у нас есть набор микросервисов, каких-то кусочков системы, мы просто добавляем к каждому этому кусочку специальный прокси-сервер и трафик между этими микросервисами пускаем через прокси-серверы. Таким образом, получаем большой сет разных возможностей по управлению трафиком между этими сервисами, по сбору статистики, мониторингу. На самом деле множество ещё всяких крутых штук в виде безопасности, mutual TLS и т.д. Но основное то, что service mesh — это подход.

Можем сделать вывод, что service mesh — это не какая-то конкретная технология, а, скорее, подход, который в практическом ключе представляет из себя добавление прокси-серверов к каждому микросервису. Что позволяет нам более гибко управлять и трафиком, и безопасностью соединения между этими микросервисами. Наверняка есть какой-то условный Control Plane или Daemon, который за всем этим следит, управляет этим, централизованно распределяет конфигурации к этим прокси-серверам и так далее?

В целом, да. Однако прокси-сервис — это необязательный атрибут. Для service mesh, я думаю, это будет динамическая конфигурация, потому что в микросервисной среде важно, когда она динамична. Все меняется, масштабируется: скейл ап, скейл даун. И на мой взгляд, динамичность — самый важный критерий. А с остальным я соглашусь.

Перейдем к следующему вопросу: когда нам стоит задуматься о том, что нам пора внедрять у себя service mesh? Какие плюсы и минусы его использования? Насколько я знаю, service mesh — относительно молодая технология. В том плане, что сейчас разве что крупные компании позволяют себе его внедрение, только-только начинают этим заниматься, в частности, в России. Насколько простому обывателю стоит задумываться о том, что пора использовать service mesh. Какие факторы служат для того, чтобы определиться с этим? Ну, и что за собой это повлечет, какие плюсы и минусы использования?

Тоже попытаюсь ответить на этот вопрос. Я зайду издалека. Попытаюсь объяснить, почему я у себя в компании в 2018 году решил внедрять service mesh. Я говорю про Booking.com.

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

Проблема номер один: у меня было 20-30 сервисов. Они находились не под моим контролем. Они деплоились по своему расписанию командой, которая находится в других часовых зонах, а мне надо проапгрейдить какую-то версию. И процесс апгрейда занимал долгое время. Мне нужно было ждать. А ждать это очень долго.

Второе, мы начали в то время переходить на более микросервисный подход. И было понятно, что у нас единый стек. Саша говорил про гомогенные и гетерогенные стеки. Давайте переведу на русский язык. Гомогенный стек — это когда у вас одна технология, например, Java, и все сервисы у вас на Java. Гетерогенные — это когда у вас зоопарк. Один сервис на Python, второй на Java, третий на Go. В Booking.com мы решили не закладываться на гомогенный стэк, мы решили заложиться на то, что стеков будет много. Поэтому было понятно, что библиотеку, в которой всё красиво, придётся переписать на потенциальные 4-5 языков, а потом ещё всё это поддерживать. И ещё желательно сделать так, чтобы они все были в одном тоне. И метрики чтобы они выдавали одинаковые. И reliability-паттерны они реализовывали тоже консистентно. В общем, было понятно, что это огромный геморрой, и поэтому мы придумали решить эти проблемы переходом на единую платформу или подход, то есть деплой прокси, который бы независимо от того, на чём написано стоящее за ним приложение, все метрики, паттерны, и дискавери делал бы одним и тем же способом.

Если говорить более конкретно о применении service mesh, то у меня нет ответа, что вот в этой точке надо применять его, а в этой не нужно. Но в общем, чем больше у вас сервисов и чем на большем количестве языков они написаны, тем большая вероятность, что service mesh вам поможет. Я говорю про вероятность, а не про уверенность, так как там проблем тоже много. И Саша про них рассказал. Если ваши сервисы отвечают за сотни миллисекунд, ну, добавит вам прокси пару миллисекунд — большой разницы вы не почувствуете.

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

Про оверхэд, с точки зрения инфраструктуры, запуск прокси на каждом сервисе — это, то, что я видел, потребление ОЗУ ещё. Каждый под у нас теперь потребляет на 50-70 МБ ОЗУ больше, даже при холостом, если я правильно помню метрики, которые смотрел. То есть надо подумать над тем, действительно ли оно вам надо.

Подрезюмируем, если у вас в компании действительно большой развесистый кластер, большое развесистое приложение с кучей микросервисов, да еще и написанных на разных языках, при этом есть серьёзные требования к отказоустойчивости и быстрому фиксу проблем, чтобы, если какой-то фейл случился, мы смогли быстро всё это пофиксить, главное, быстро понять, в каком месте именно эта проблема возникла. Как сказал Иван, нет какого-то единого фактора или единого аргумента, который скажет, что вот теперь надо внедрять service mesh. Чем больше этих аргументов складывается, тем больше вам стоит уже смотреть в сторону service mesh и подготавливать какую-то почву, может, на тестовом кластере развернуть, поковырять, посмотреть, как это. На продакшн, конечно, ставится он легко, тот же Istio.

Следующий вопрос, который хотелось бы обсудить это про то, что если service mesh — подход, методология, то какие конкретно есть продукты сейчас? Что актуально? И на что можно обратить внимание, если компания решила попробовать service mesh?

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

Первая — это Console Connect. Это разработка от Hashicorp. Технологии Hashicorp и их инструменты достаточно качественные. В случае, если у вас уже есть что-то из их стека, хорошая история посмотреть в том числе на их решение service mesh. С точки зрения количества возможностей, они обычно догоняют Istio, но реализуют более даже продуманно и детально во многом благодаря тому, что hashicorp имеют собственных клиентов, на которых изначально эти продукты обкатывают и затем выдают уже в паблик готовые решения.

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

Собственно, я бы посмотрел с разных сторон на три решения: Istio, Console Connect и Linkerd2. В конце концов, скорее всего, задачи, которые вам нужно решить в своей системе, они реализуют все. Какая из этих технологий лучше подойдёт, уже будет зависеть от того, что вам будет удобнее и что больше понравится. Если говорить о видении, лично мне кажется, что в конечном счете останутся если не победителями, то в большей степени лидерами service mesh решения именно на базе Envoy-proxy, просто потому, что сейчас он набирает огромную популярность, имеет очень большое количество фич из коробки. И, скорее всего, большинство service mesh будут именно на нём. Но тем не менее смотреть всё равно стоит на всё.

Я соглашусь с Александром. Istio — самый большой, самый популярный, в том числе потому что за ним Google. Это их технология. Остальные не трогал и не знаю. Но я знаю, что у Hashicorp всё ориентировано на простое использование. Есть смысл посмотреть туда. И если у вас есть сервис Discovery или вы пользуетесь Consul, то тоже есть смысл смотреть туда. Linkerd2 — это третья версия, которая на данный момент есть.

Почему Envoy используется в service mesh? Почему не более матерые инструменты, как Nginx или Haproxy, которые имеют достаточно большую функциональность? Видимо, чего-то не хватает. Чего?

Основная характеристика service mesh — это динамичность. И именно она отсутствует и в Nginx, и в Haproxy. Они были рождены в эру более статичной конфигурации, которую вы могли записать в конфиги, описать, и они либо не менялись, либо менялись не часто. В service mesh изменения ежесекундные. В Envoy и Linkerd есть собственные протоколы, которые позволяют динамически пушить в них конфигурацию. Можно написать сервис, который по HTTP2 будет туда пушить конфигурацию. И они оба динамично перестраивают таблицы, работают очень хорошо. Это для меня основная причина, почему Nginx и Haproxy не приживаются в service mesh.

Как следствие, получается, если у нас стоят прокси-сервисы в виде Envoy, у нас появляются какие-то возможности, какие-то фичи. И с этим связан следующий вопрос. Если мы говорим про Service mesh, про то, что действительно это тяжело, но вроде как очень здорово и круто, хотелось бы теперь акцентировать внимание на том, какие есть фичи в service mesh? Безопасность, обсервабилити, стратегии деплоя.

Под термином обсервабилити обычно понимается совокупность трёх: мониторинг (классические метрики), логирование, трейсинг. Это то, что позволяет вам как оператору сервиса понять, что происходит или происходило в вашем сервисе сейчас или когда-то в прошлом. Сразу скажу, что service mesh логирование не трогает ни в коей мере. То есть в контексте service mesh это про метрики и про трейсинг.

Отвечая на этот вопрос, я его сначала перефразирую. Что внедрение этой технологии даёт бизнесу? На мой взгляд, это консистентность. Сейчас поясню. Представьте, что у вас есть, условно говоря, 100 микросервисов, и вам нужно понять, как они взаимодействуют между собой. Вы можете инструментировать сервисы и заставить их выплёвывать HTTP-метрики. Но скорее всего, у вас получится всё в разнобой. Кто-то будет репортить в секундах, кто-то будет репортить в миллисекундах, кто-то будет выдавать класс ошибок 5xx, кто-то будет выдавать 500. Появляется неконсистентность. Поэтому встаёт вопрос построения единого дашборда, чтобы понять, что происходит с вашей системой. И это всё превращается большой головняк. Потому что у вас метрики называются по-разному, они в разных юнитах и т.д. С service mesh эта проблема решается вся и разом, потому что вы деплоите всё с одним Envoy, он выплевывает метрики с одним именем, в одних юнитах, с одними бакетами и т.д. Просто строится один дашборд, где вы выбираете нужный сервис и видите список всего, что с ним происходит.

С трейсингом чуть сложнее, потому что он построен на хедерах, и эти хедеры нужно прокидывать между входом в приложение и выходом из него. То есть требуется небольшая дополнительная инструментация, но в общем и целом результат то же. Перед вами появляется топология и возможность отслеживания конкретного запроса. В развесистой микросервисной архитектуре понять, что происходит — огромная проблема. Control Plane в service mesh — это централизованная панель управления, поэтому определенные политики вы можете запушить централизованно. Начиная с частоты ретраев, таймаутов. Представьте, что вы создали новый сервис. И если у вас правильно настроены дефолтные настройки, вы сразу из коробки получаете мониторинг, трейсинг, ретраи, бэкоффы, circuit breaker — причем в одних из лучших имплементаций. Вы можете пушить сертификаты, политики доступа (например, этот сервис может разговаривать с одним, а с другим нет).

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

Я бы еще добавил, что поскольку service mesh – это про внедрение в синхронное взаимодействие между нашими микросервисами, то здесь безграничные возможности по управлению трафиком, который идет между сервисами. Это возможность там сделать канареечные деплойменты, Blue-green деплоймент, — те вещи, которые из коробки, например, в Kubernetes сделать сложно либо невозможно.

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

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

Допустим, мы продали идею бизнесу и сами пропитались этой идеей, какие шаги должны пройти специалисты с технической и организационной точек зрения? Как правильно внедрить service mesh у себя, если у нас уже работает тот же самый Kubernetes? Как внедрить service mesh и ничего не сломать?

Тут немного расскажу про наш опыт. Внедрение этой технологии возможно постепенно. Мы можем чётко выбирать те кусочки системы, на которые мы сейчас раскатываем эту технологию, там тестировать её, смотреть на её влияние на тот же performance, смотреть, получаем ли мы нужный результат, нужный набор фич. И постепенно раскатывать. Например, Istio позволяет внедрять Envoy автоматически к каждому микросервису при помощи технологии веб-хуков, которые под капотом добавляют контейнер к нашему поду. И можно четко сказать, что мы хотим видеть Envoy-proxy в таком-то неймспейсе или уже внедрённый Envoy в таких-то инстансах. Это если говорить про внедрение в продакшен.

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

Если резюмировать, просто придерживаемся правильного подхода, не делаем резких движений и, как сказал Александр, верхнеуровневую простоту не принимаем за чистую монету, потому что под капотом всё гораздо сложнее. Есть что добавить про service mesh вне Kubernetes: Istio и Linkerd2?

Последний раз я смотрел на Istio около года назад — и это было в полурабочем состоянии. Я думаю, оно сейчас находится в нормальном состоянии. Они добавили возможность добавления в Kubernetes, декларирования в нём инстансов, которые находится вне рамок Kubernetes. Почему Istio раньше нельзя было растянуть на Kubernetes? Потому что Istio полагался на примитивы Kubernetes: service, endpoints. То есть Istio вёл свои дискавери оттуда. Они ввели понятие, по-моему, оно называется virtual service или service entry, с помощью которого вы можете задекларировать, прописать, что у меня есть какой-то инстанс, он доступен по такому-то айпишнику. Но как я понимаю, на вас ложится обязанность поддержания этого описания в актуальном состоянии. Если у вас есть железный сервис, на который айпишник прибит гвоздями, то всё нормально. Если более динамичная штука, то придётся руками писать, руками поддерживать.

Возможен ли service mesh, где нет технологий Kubernetes. Чисто технически это возможно. Потому что Kubernetes это просто оркестратор, есть и другие решения. Изначально Istio проектировался, чтобы работать под разные решения, и там был компонент, который сейчас входит в основную часть Control Plane, под названием Galay. Он как раз занимался тем, что различные манифесты конвертировал в единое описание, которое уже понимает Istio для настройки. Таким образом, мы могли настроить его под практически любое решение. А с точки зрения bare-metal, либо каких-то виртуалок, где нет инструментов автоматизации, там в принципе можно установить Envoy, прописать политики маршрутов, чтобы трафик заходил через Envoy. Но тут вопрос профита от этого и того, какие мы хотим получить фичи. Технически возможно поставить куда угодно, вопрос лишь удобства эксплуатации и необходимости в этом решении.

Кстати, чтобы коллеги понимали, Envoy — один из ключевых один из двух ключевых компонентов всех современных service mesh. Он был создан компанией Lyft. У них service mesh был весьма условный. Они свои энвои конфигурировали через конфигурационные файлы. И только позже у них возник некоторый самописный Control Plane. Написать Control Plane, кстати говоря, не так сложно на самом деле. Там есть чётко задекларированный протокол. И есть шаблонные наработки, некоторая обвязка, которая позволяет создать свой Control Plane. По сути, на текущих реализациях свет клином не сошёлся, безусловно, в них много фичей и поддержка коммьюнити, но в общем и целом, если вам нужны какие-то специфические фичи, которые вы не можете найти в том, что есть, то есть возможность написать своё. Конечно, это определенный оверхед, достаточно серьезный, но возможность есть — технология открытая, протоколы все описаны. Если мы рассматриваем вопрос, возможен ли service mesh вне Kubernetes, в широком смысле, да, возможен, никаких ограничений нет. Если говорить в более узком плане, возможно ли Istio растянуть на вне Kubernetes, или Consul растянуть на вне Kubernetes, как говорится, it depends. Чем дальше мы идём, тем больше это становится возможным. В Istio, думаю, это сейчас можно стопудово. Consul Connect, по-моему, заходил в эту сферу как раз-таки без Kubernetes. Поэтому там должно работать из коробки. Я думаю, в Consul Connect всё завязано на Consul Service Discovery. Если ваши сервисы видны в их Discovery, то они будут видны и в service mesh.