В нашем случае на обновление старых версий k8s требовалось существенно больше ресурсов и времени, нежели на поддержание нескольких простых патчей в истио.
Кластеры мы в конечном счете обновили, конечно, просто это занимает больше времени.
Сразу озвучу, что нет цели доказать, что Istio это лучший Service Mesh и что всем организациям необходимо внедрять Service Mesh (скорее наоборот). Если организация большая / существует довольно долго, скорее всего в ней уже есть решения, покрывающие большУю часть механик, которую обычно даёт Service Mesh.
Service Mesh позволяет нам снять довольно существенный и важный пласт инфраструктурной логики с приложения и ускорить цикл разработки. Вы правы, что в приложение можно встроить сбор метрик, валидацию сертификата, внедрить клиентские сертификаты, попытаться что-то придумать с service discovery (имея только приложение это довольно сложно). Можно даже обернуть это в библиотеки, чтобы попытаться как-то контролировать актуальность конфигурации данных процессов.
Но даже в случае с библиотеками:
Обновление кода приложений (и версий библиотек) это всегда долго тянущийся процесс.
Данные механики (или библиотеки) придется поддерживать для всех языков программирования, которые компания хочет использовать. Их может быть много, соответственно любое добавление новой метрики превращается в "обновить N бибилотек на разных языках программирования".
Обо всем этом придется в том числе думать владельцам приложений (разработчикам). Какую им библиотеку подключить, как будет устроен service discovery и т. д. Чем больше сервисов / сотрудников, тем больше времени уходит на любое изменение.
Имея Service Mesh у нас появляется единая точка конфигурации. Нужная новая метрика по HTTP взаимодействию? Не проблема, укажем метрику в конфиге, через несколько часов все наши несколько тысяч сервисов будут писать данную метрику. Работа с сертификатами реализуется один раз, для всех приложений => проще контролировать безопасность выбранного подхода.
Касательно гибкости и управляемости -- действительно, скорее всего есть аппаратные балансировщики на входе в ЦОДы. Однако они как правило работают на уровне l3 / l4. Мы же хотим делать умный service discovery, знать о всех живых инстансах сервиса. Хотим медленно увеличивать процент канарейки при новом релизе приложения. Из коробки нигде этой информации не будет, необходим некий control plane, который будет наблюдать за системой.
Многие из этих проблем актуальны для больших организаций. Если в компании работает 30 инженеров, разрабатывающих 10 сервисов, внедрение условного Istio может сделать жизнь сильно сложнее.
Трейсинг и логирование это немного разные инструменты, которые отлично работают в симбиозе друг с другом.
Как правило логи используют для того, чтобы сообщить о том, что случилось какое-то "специальное событие": ошибка / warning / etc. К этому событию прикрепляют какие-то полезные поля для его идентификации, некоторые атрибуты и понятное описание того, что случилось.
Трейсинг же можно использовать, чтобы отслеживать все точки системы, по которым прошёл запрос. И это очень удобно в большой распределенной архитектуре, когда один человек буквально не может разбираться в логике всех сервисов, присутствующих в системе. А ведь количество сервисов в системе может измеряться тысячами... можно представить, насколько много получится уникальных цепочек обработки запроса.
Зато этот человек может в тех же самых логах найти информацию о том, что его сервис отправил запрос в другой сервис, и в ответ получил какую-то ошибку. Он может посмотреть на ID этого запроса и отследить весь его путь. Увидеть, что запрос был отправлен из сервиса A в его сервис B, после чего было много обращений в сервис C, и дальнейшая обработка запроса по пути сервисов D -> E -> F -> ..., пока запрос не дошёл до субд, которая не смогла выполнить запрос, потому что в этот момент вышел из строя старый лидер субд.
Если в системе есть некоторый платформенный слой для проксирования всех запросов (например, запросы перехватываются с помощью прокси сайдкаров, устанавливаемых рядом с каждым сервисом), можно довольно дешёво начать отслеживать все трейсы в системе. И когда разработчики будут менять / добавлять новые обработчики запросов, им не придется думать о том, что нужно не забыть написать логи, чтобы можно было в дальнейшем отслеживать цепочки запросов. А если есть большое наследие, которое сделали 10 лет назад, и никто тогда не думал о том, чтобы нужно логировать что-то? Насколько дорого будет пойти и добавить везде логирование?
Логи пишут, когда разработчик решил, что в этом месте будет полезно что-то залогировать, чтобы иметь дополнительный контекст. Трейсинг спаны пишут всегда (по модулю семплирования).
Да, можно добавить логирование на прокси, обрабатывающих трафик, и сделать какие-то общие entry-point'ы в приложении, которые будут писать логи при поступлении нового запроса. Добавить в эти логи некоторый request_id, единый в рамках одного запроса, и начать прокидывать этот request_id. Подключить к этому всему сквозной поиск в системе по request_id и решить задачу с помощью логирования. Так действительно можно сделать, но в итоге получится, что вы переизобрели трейсинг.
Как уже было упомянуто, логи и трейсинг отлично существуют в симбиозе. При логировании можно всегда указывать trace_id, и в дальнейшем отображать и логи, и трейсы в одном интерфейсе. Будет наглядно видно, по каким компонентам системы прошёл запрос, и какие логи писали сервисы при обработке данного запроса.
В нашем случае на обновление старых версий k8s требовалось существенно больше ресурсов и времени, нежели на поддержание нескольких простых патчей в истио.
Кластеры мы в конечном счете обновили, конечно, просто это занимает больше времени.
Привет! Спасибо за развернутый комментарий.
Сразу озвучу, что нет цели доказать, что Istio это лучший Service Mesh и что всем организациям необходимо внедрять Service Mesh (скорее наоборот). Если организация большая / существует довольно долго, скорее всего в ней уже есть решения, покрывающие большУю часть механик, которую обычно даёт Service Mesh.
Service Mesh позволяет нам снять довольно существенный и важный пласт инфраструктурной логики с приложения и ускорить цикл разработки. Вы правы, что в приложение можно встроить сбор метрик, валидацию сертификата, внедрить клиентские сертификаты, попытаться что-то придумать с service discovery (имея только приложение это довольно сложно). Можно даже обернуть это в библиотеки, чтобы попытаться как-то контролировать актуальность конфигурации данных процессов.
Но даже в случае с библиотеками:
Обновление кода приложений (и версий библиотек) это всегда долго тянущийся процесс.
Данные механики (или библиотеки) придется поддерживать для всех языков программирования, которые компания хочет использовать. Их может быть много, соответственно любое добавление новой метрики превращается в "обновить N бибилотек на разных языках программирования".
Обо всем этом придется в том числе думать владельцам приложений (разработчикам). Какую им библиотеку подключить, как будет устроен service discovery и т. д. Чем больше сервисов / сотрудников, тем больше времени уходит на любое изменение.
Имея Service Mesh у нас появляется единая точка конфигурации. Нужная новая метрика по HTTP взаимодействию? Не проблема, укажем метрику в конфиге, через несколько часов все наши несколько тысяч сервисов будут писать данную метрику. Работа с сертификатами реализуется один раз, для всех приложений => проще контролировать безопасность выбранного подхода.
Касательно гибкости и управляемости -- действительно, скорее всего есть аппаратные балансировщики на входе в ЦОДы. Однако они как правило работают на уровне l3 / l4. Мы же хотим делать умный service discovery, знать о всех живых инстансах сервиса. Хотим медленно увеличивать процент канарейки при новом релизе приложения. Из коробки нигде этой информации не будет, необходим некий control plane, который будет наблюдать за системой.
Многие из этих проблем актуальны для больших организаций. Если в компании работает 30 инженеров, разрабатывающих 10 сервисов, внедрение условного Istio может сделать жизнь сильно сложнее.
Спасибо за интересный материал и хороший доклад. Многие из проблем откликаются, и многие выводы перекликаются с собственными мыслями :)
Трейсинг и логирование это немного разные инструменты, которые отлично работают в симбиозе друг с другом.
Как правило логи используют для того, чтобы сообщить о том, что случилось какое-то "специальное событие": ошибка / warning / etc. К этому событию прикрепляют какие-то полезные поля для его идентификации, некоторые атрибуты и понятное описание того, что случилось.
Трейсинг же можно использовать, чтобы отслеживать все точки системы, по которым прошёл запрос. И это очень удобно в большой распределенной архитектуре, когда один человек буквально не может разбираться в логике всех сервисов, присутствующих в системе. А ведь количество сервисов в системе может измеряться тысячами... можно представить, насколько много получится уникальных цепочек обработки запроса.
Зато этот человек может в тех же самых логах найти информацию о том, что его сервис отправил запрос в другой сервис, и в ответ получил какую-то ошибку. Он может посмотреть на ID этого запроса и отследить весь его путь. Увидеть, что запрос был отправлен из сервиса A в его сервис B, после чего было много обращений в сервис C, и дальнейшая обработка запроса по пути сервисов D -> E -> F -> ..., пока запрос не дошёл до субд, которая не смогла выполнить запрос, потому что в этот момент вышел из строя старый лидер субд.
Если в системе есть некоторый платформенный слой для проксирования всех запросов (например, запросы перехватываются с помощью прокси сайдкаров, устанавливаемых рядом с каждым сервисом), можно довольно дешёво начать отслеживать все трейсы в системе. И когда разработчики будут менять / добавлять новые обработчики запросов, им не придется думать о том, что нужно не забыть написать логи, чтобы можно было в дальнейшем отслеживать цепочки запросов. А если есть большое наследие, которое сделали 10 лет назад, и никто тогда не думал о том, чтобы нужно логировать что-то? Насколько дорого будет пойти и добавить везде логирование?
Логи пишут, когда разработчик решил, что в этом месте будет полезно что-то залогировать, чтобы иметь дополнительный контекст. Трейсинг спаны пишут всегда (по модулю семплирования).
Да, можно добавить логирование на прокси, обрабатывающих трафик, и сделать какие-то общие entry-point'ы в приложении, которые будут писать логи при поступлении нового запроса. Добавить в эти логи некоторый request_id, единый в рамках одного запроса, и начать прокидывать этот request_id. Подключить к этому всему сквозной поиск в системе по request_id и решить задачу с помощью логирования. Так действительно можно сделать, но в итоге получится, что вы переизобрели трейсинг.
Как уже было упомянуто, логи и трейсинг отлично существуют в симбиозе. При логировании можно всегда указывать trace_id, и в дальнейшем отображать и логи, и трейсы в одном интерфейсе. Будет наглядно видно, по каким компонентам системы прошёл запрос, и какие логи писали сервисы при обработке данного запроса.
Если асимптотика алгоритма O(n), то O(n^2) тоже является асимптотикой данного алгоритма.
Если рассматривать join, а не left join, то возможна же ситуация, когда этот
джоин даст в результате 0 записей. Хотя если убрать LIMIT 1, то записи найдутся.
Нам было по фану решать их все.