Хабрахабр

Интервью с Иваном Кругловым, Principal Developer: Service Mesh и «нестандартные» инструменты Booking.com

Иван Круглов, Principal Developer в Booking.com, выступал на Слёрм DevOps c темой SRE, а после выступления согласился за чашкой кофе поговорить о Kubernetes, Service Mesh, open source и «нестандартных» решениях в Booking.com

Там будут рассмотрена теория и практика применения SLI/SLO/error budget, проведение разбора полетов (post-mortem), эффективная ликвидации IT-инцидентов, построение надежных систем (мониторинг и алертинг, graceful degradation, failure-injection, capacity planning, предотвращение cascading failures). Так как тема SRE оказалась намного обширнее, то Иван и его коллега Бен Тайлер, Principal Developer в Booking.com, согласились стать спикерами Слёрм SRE, который пройдёт 3—5 февраля 2020.

А сейчас слово Ивану.

Что для вас в последнее время было интересным профессиональным вызовом?

Первое: занимаюсь внутренним облаком Booking.com. В последние два года я занимаюсь двумя вещами. По этому поводу у меня был долгий и обстоятельный доклад на Highload. Оно построено на Kubernetes.

Это предыдущий мой проект, который я оставил коллеге. У нас был долгий и интересный путь, как мы строили наше облако.

Это, собственно, горячая тема, как в своё время были Big Data и Kubernetes. Сейчас я занимаюсь такой темой, которая называется Service Mesh.

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

Вот сидит микросервис, к нему приходит HTTP запрос. Как вы знаете, откуда приходит запрос? И точно так же сервис, который зовёт другой сервис. Действительно ли он пришёл от того сервиса, от которого я думаю? В небольших организациях это, наверное, не так актуально. Мне нужно быть точно уверенным, что сервис, который я зову, именно нужный мне сервис, а не какой-то там фейковый. И для крупных компаний это достаточно серьёзная проблема. А в крупных, когда у тебя тысячи и десятки тысяч машин, ты не уследишь за каждой машиной. Всегда когда ты делаешь какую-то коммуникацию, ты должен провести верификацию. То есть, скажем так, все строится на уровне zero trust. Это всё достаточно тяжёлые с точки зрения имплементации процессы. Получается, что на уровне сетевого взаимодействия нужно провести аутентификацию и авторизовать операцию. Это лишь одна из фич которые делает Service Mesh. И получается такая картина, что Service Mesh берёт на себя эти задачи по обеспечению безопасного взаимодействия. Там еще много чего — reliability, monitoring, tracing и другие.

И вы считаете, что эта технология является будущим?

Это моё личное мнение. Service Mesh — это тренд, который нарастает. Например есть Istio. Он достаточно уже распространён. Я думаю, что у всех крупных поставщиков скоро появится или уже появился полноценный Service Mesh. Потом в облаках, в том же Амазоне, появился Service Mesh.

То есть такая же прорывная технология, как некогда был, да и сейчас есть Kubernetes?

Хотя тут интересно заметить, что на мой взгляд ни Kubernetes, ни Service Mesh ничего нового не изобретают. Думаю да. Service Mesh делает примерно то же самое. Kubernetes взял существующий стек технологий и сделал его автоматизацию. В Service Mesh появился Envoy, который я сегодня продемонстрирую. Он дает новые инструменты на существующей базе. Иван затрагивал этот вопрос в выступлении на интенсиве Слёрм DevOps) Идея в том, что Service Mesh — это инструмент более высокого уровня, который позволяет оркестрировать коммуникациями большого флота микросервисов. (Прим. Это то, что делает Kubernetes. Поясню… Для того, чтобы запустить микросервисную архитектуру, нужно, первое, это так называемый runtime — это место, где приложение будет запущено. Service Mesh его дополняет, в том плане, что он обеспечивает взаимодействие между этими микросервисами, которые будут запущены в runtimе.

Вы в ближайшее время будете развивать именно эту технологию?

Я занимаюсь инфраструктурой. Я могу говорить за себя. И в инфраструктурном плане в ближайшие несколько лет это будет одной из основных тем — Kubernetes и Service Mesh.

Они будут развиваться параллельно?

Kubernetes делает runtime. Безусловно, потому что они дополняют друг друга. Service Mesh обеспечивает взаимодействие.

Но в Kubernetes они слишком базовые. Точнее так, в Kubernetes есть некоторые компоненты, которые как бы покрывают аспекты Service Mesh. В смысле, IP пакеты умеют ходить из пункта А в пункт Б. То есть Kubernetes, c точки зрения сетевого взаимодействия, даёт вам только низкоуровневое сетевое взаимодействие. Окей, там есть Ingress-контроллеры, есть моменты более высокоуровневой маршрутизации, то есть не только сетевое взаимодействие. Всё. Такой очень простой пример. Но тем не менее, в Kubernetes, например, нет встроенных механизмов обеспечения надёжности выполнения запросов. По умолчанию. В Kubernetes если «под» (Pod) падает, Kubernetes его сам поднимет. Но на уровне сетевого взаимодействия такого не происходит. Это механизм retry. То есть если сервис главной страницы посылает запрос сервису корзины, и по какой-то причине это не получилось, повтор запроса (retry) не произойдёт.

Он позволяют, если запрос завершился неудачей, повторить его ещё раз. Service Mesh в этом плане добавляет функционал. Если, например, у нас есть флот «подов», которые работают за сервис «главной страницы», и флот «подов», которые являются сервисом «корзина». Есть другие механизмы например outlier detection. Соответственно, в Service Mesh есть механизмы, которые позволяют динамически строить картину, кто кому доступен, и переключаться между ними — причём всё это в real time. Если они географически разделены, то у них могут появляться такие вещи, что одна часть «подов» видит одну часть «подов», а другая часть «подов» — другую часть «подов». Каждый «под» может принять решение, что вот с этим «подом» у меня разговор медленный — все остальные нормально, а этот медленный — потому я его выкину из своего пула. А если у одного из «подов» слишком большой latency, то выкинуть его. Когда у нас есть десять «подов», девять «подов» работают без ошибок, а десятый постоянно шлёт ошибки. Так работает механизм определения аномалий. И Service Mesh принимает решение его выкинуть. Или девять «подов» отвечают с latency 15 ms, а один отвечает с latency 400 ms.

То есть у нас есть клиент, и есть сервер. Еще Service Mesh хорош в том, что позволяет собирать статистику на стороне клиента. Ну, потому что это проще всего. Обычно статистику собирают на стороне сервера. Соответственно, по идее-то мерить нужно на стороне клиента, а не на стороне сервера. Мы хотим с помощью метрик понять, насколько хорошо наш пользователь взаимодействует с нашим сервисом. Потому что между ними большая пропасть, которая заполняется сетевыми взаимодействиями.

Каждый компонент из этого всего разнообразного может выйти из строя.

И могут возникать ситуации, когда на стороне сервиса latency 20ms, а на стороне клиента 2 секунды. И Service Mesh хорош в том, что он ставит агент и туда, и сюда — и статистику шлёт с двух концов. В результате, из-за retransmit-ов в TCP стеке получается, что наш клиент видит latency в 2 секунды. Например, на стороне сервера мы собираем статистику с web-сервера, но у нас 5% пакетов теряется по какой-то причине. У меня-то всё хорошо, у меня latency 20 ms. А на стороне сервера мы по прежнему видим отличную latency: как в буфер всё отправили, так и готово! А каково клиенту?!

И как вы это решаете?

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

Какие у вас метрики надёжности и доступности в компании?

Сегодня я об этом буду рассказывать. Всё по большему счёту стандартно. Выступление Ивана на третьем дне Слёрма DevOps) Есть пять или шесть основных показателей. (Прим. Потому что по идее, ключевая идея SRE строится на одном таком высокоуровневом утверждении — нам нужно выделить метрику или метрики, которые бы отражали user experience. Так называемых Service Level Indicators: latency, durability, freshness, correctness… Когда я готовился к презентации на Слёрме, я пытался найти у нас в Booking.com нестандартные кейсы, интересные примеры SLI, которые не укладываются в эту модель. И как найти вот эту равновесную точку, которая бы отразила user experience — вот это интересная задача. И для некоторых сервисов latency, durability подходит, для других — нет.

Или всё стандартно? Какие уникальные решения ты увидел в Booking.com, когда пришёл туда работать?

У нас многое что «нестандартно». Нет. Откуда вообще идёт нестандартность… Нестандартность часто идёт от того, что компания столкнулась с проблемой раньше рынка, и следовательно «стандартного» решения нет. Давайте поясню, почему нестандартно в кавычках. В этом плане Booking.com, будучи компанией, которая работает на рынке с 1997 года и доросла до таких размеров, в своё время столкнулась с рядом проблем, которые не были решены.

По моим наблюдениям это выглядит как-то так. Например, Google. Например, я общался с ребятами из Google, которые патчили ядро Linux. Они внутри делают крупные разработки, которые выкладывают в public лет через пять или через десять. Я говорю им: «Вот здесь чётко проблема в ядре. Тогда у меня были определённые проблемы в TCP стеке. Они говорят: «А, так у нас патченное ядро. Как вы с этим боретесь?». У нас в 2013 году было пропатчено. У нас здесь настройку можно подтюнить. А мы только сейчас, в 2018 году его выкатываем в open-source».

Он тоже построен по образу и подобию технологии, которую Google использует внутри. Примерно тоже самое с Service Mesh. Istio это по сути open-source реимплемнтация их внутренней системы. Но они не выкладывают ее в open source напрямую. На мой взгляд это происходит потому, что когда компания является первопроходцем, она создает решения под себя. С Kubernetes так же. Open source — это дорого. Потому что так быстрее, дешевле. А чтобы выстроить комьюнити, нужно вложить огромную кучу усилий. И кто бы что ни говорил, что выкладывать надо, на самом деле надо выстраивать комьюнити. Мне кажется, что за любыми серьёзными «аптейками» стоит ещё более серьёзный маркетинг, в который естественно вкладываются деньги. И только тогда пойдёт тебе отдача.

И потом выложить в open source довольно сложно. К чему я это… Как я говорил, при решении проблемы, компания делает много под себя. У нас свой сервис Service Mesh, своя система мониторинга. Нужно выпилить бизнес-логику и кучу мелких деталей. В публикации на open source есть свои плюсы... И чтобы выкладывать это в open source, это нужно переделать.

Какие, например?

Они важны. Технологический бренд, лояльность, проще on-boarding.

Их не посчитаешь напрямую.

Не посчитаешь напрямую. Да, верно. Я не за и не против open source. Это долгосрочные, стратегические вложения. Баланс долгосрочной и краткосрочной стратегии. Подходить нужно взвешенно, оценивая, что даёт компании публикация конкретной технологии.

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

S.: Невозможно охватить всю тему SRE за одно выступление. P. Потому мы выделили под эту тематику целый интенсив Слёрм SRE, который пройдёт 3—5 февраля 2020. Там не только инструментарий, там ещё и сама философия подхода. Спикерами по теме выступят сам Иван Круглов, Principal Developer в Booking.com, его коллега Бен Тайлер, Principal Developer в Booking.com, Эдуард Медведев, CTO в Tungsten Labs, Евгений Варавва, разработчик широкого профиля в Google.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть