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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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