Фото с сайта linkerd.io Пару лет назад ребята из Кинволк сравнил производительность Linkerd и Istio и выяснил, что Linkerd значительно быстрее и меньше Istio во всех областях, кроме одной.
.
Linkerd использовал больше ресурсов ЦП на уровне данных.
Недавно мы повторили эти эксперименты с последними версиями обеих сервисных сеток.
Как показывают результаты, Linkerd не только все еще заметно быстрее Istio, но и использует на порядок меньше памяти и ресурсов ЦП в плоскости данных.
.
Причём это происходит даже в том случае, если количество запросов в секунду более чем в три раза больше, чем в бенчмарке Kinvolk. Вы можете легко это повторить.
Теперь подробности.
Контекст
В 2019 году Кинволк опубликовал Сравнительные показатели Linkerd и Istio .Это дало два результата.
Во-первых, был Инструмент сравнения сервисных сеток с открытым исходным кодом , с помощью которого каждый может воспроизвести бенчмаркинг.
Прелесть этого инструмента в том, что он воспроизводит реальные сценарии: через простое микросервисное приложение проходит постоянный поток трафика, используются вызовы gRPC и HTTP, измеряются затрачиваемые ресурсы памяти и ЦП, а также задержка при использовании сервисной сетки.
.
Важно отметить, что задержка измеряется с точки зрения клиента, а не внутренних процессов.
Во-вторых, Kinvolk представил результаты бенчмарка Linkerd и Istio за 2019 год. Цифры показали, что Linkerd работает намного быстрее и потребляет значительно меньше ресурсов, за исключением одного участка — плоскость данных Linkerd (т. е.
прокси) потребляла больше процессорных ресурсов, чем Istio. , при очень высокой нагрузке.
Спустя два года и множество новых релизов с обеих сторон мы решили повторить этот эксперимент.
Подготовка
Мы использовали инструмент сравнительного анализа Kinvolk и последние стабильные версии обоих проектов: Linkerd 2.10.2 (установка по умолчанию) и 1.10.0 (минимальная конфигурация).Мы запустили последнюю версию инструмента для сравнительного анализа на кластере Kubernetes v1.19 с дистрибутивом Lokomotive Kubernetes и использовали любезно предоставленное «голое железо» оборудование.
Эквиникс Металл для проектов CNCF. Первое, что мы сделали, — это искали тестовую среду на Equinix Metal, которая обеспечивала бы стабильные результаты при каждом запуске.
Это оказалось сложно: многие среды давали большую разницу в задержке даже без сервисной сетки (например, в одной среде мы получили максимальную задержку от 26 до 159 мс для 200 запросов в секунду без сервисной сетки!).
Наконец мы нашли кластер в Дата-центр Equinix Metal dfw2 , что дало меньше расхождений.
Кластер состоял из шести рабочих нод конфигурации s3.xlarge.x86 (Intel Xeon 4214 с 24 физическими ядрами, 2,2 ГГц и 192 ГБ ОЗУ), на которых мы запустили приложение.
Другой узел с такой же конфигурацией генерировал нагрузку.
Плюс был главный узел Kubernetes с конфигурацией конфигурации c2.medium.x86. Затем мы приступили к настройке параметров инструмента.
Kinvolk оценивался по производительности на уровне 500 запросов в секунду (RPS) и 600 RPS. Мы расширили ассортимент и взяли 20 RPS, 200 RPS и 2000 RPS. На каждом уровне мы сделали по шесть независимых прогонов со стабильной нагрузкой по 10 минут для Linkerd, Istio и конфигурации без сервисной сетки.
Между запусками мы переустанавливали все ресурсы тестов и сетки.
Для каждого уровня мы отбросили прогон с максимальной задержкой, поэтому всего у нас осталось пять значений.
Если хотите, можете изучить наш необработанные данные .
Платформа Kinvolk измеряет поведение сервисной сетки, в частности:
- Он оценивает наибольшее потребление памяти для плоскости управления и плоскости данных.
То есть максимальное потребление памяти в плоскости управления (в сумме со всеми компонентами) в любой момент прогона будет считаться значением для этого прогона.
- То же самое происходит с памятью для прокси-сервера плоскости данных.
- Для ресурсов процессора значение рассчитывается таким же образом, используя в качестве метрики время процессора.
- Задержка измеряется с точки зрения клиента (генератора нагрузки) и включает время в сети кластера, время в приложении, время в прокси-сервере и т. д. Задержка выражается как процентиль распределения — p50 (медиана), p99, p999 ( 99,9%) и т. д.
раздел «Сводка» ниже.
) Цифры зависят как от самой сервисной сетки, так и от инструмента и его среды.
То есть это не абсолютные, а относительные величины, сравнивать которые можно только в том случае, если они получены одним и тем же методом в одной и той же среде.
Примечание автора.
Заявления о том, что медианная задержка Linkerd на X мс превышает базовую конфигурацию, не означают, что Linkerd увеличит медианную задержку в вашем приложении на X мс.
Кроме того, это не означает, что отдельный прокси-сервер Linkerd увеличит задержку на X мс (средняя задержка отдельного прокси-сервера Linkerd составляет менее миллисекунды для большинства типов трафика).
Какие функции сервисной сетки мы тестировали?
Сервисная сетка имеет множество возможностей, но в наших экспериментах мы использовали лишь некоторые из них:- В обеих сервисных сетках был включен mTLS, трафик шифровался, а аутентификация выполнялась между всеми модулями приложений.
- Обе сервисные сетки отслеживали метрики, в том числе и на L7, хотя в нашем эксперименте мы эти метрики не использовали.
- Обе сервисные сетки по умолчанию регистрируют разные сообщения на уровне INFO. Мы не настраивали логирование.
- Обе сервисные сетки могли добавлять повторы и таймауты, а также перераспределять трафик по-разному, но мы не использовали эти функции явно.
- Мы не включили распределенную трассировку, взаимодействие между кластерами и другие функции в стиле сетки.
Результаты
Результаты наших экспериментов показаны на графиках ниже.Каждое очко представляет собой среднее значение пяти пробежек.
Усы показывают одно стандартное отклонение от этого среднего значения.
Синий столбец — Linkerd, оранжевый — Istio, а желтый — конфигурация без сервисной сетки.
Задержка при 20 RPS
Мы начали с малого — 20 RPS, но даже здесь есть большая разница в задержке для пользователя.Linkerd имеет среднюю задержку 17 мс, что на 11 мс больше, чем в базовой конфигурации (6 мс).
У Istio средняя задержка составляет 26 мс, что почти в два раза больше, чем у Linkerd. Максимальная дополнительная задержка у Linkerd составляет 53 мс от базовой конфигурации (17 мс), а у Istio — 188 мс, то есть более чем в три раза больше, чем у Linkerd. Если посмотреть на процентили, то полоска Istio резко подскакивает на p99, почти до 200 мс, а у Linkerd подъем более постепенный, до 70 мс.
(Помните, что задержка измеряется с точки зрения клиента, то есть мы видим, как она воспринимается пользователем приложения.
) 
Задержка при 200 об/с
При 200 RPS мы видим аналогичную картину, и средние задержки почти такие же: у Linkerd 17 мс, опять же на 11 мс больше базовой, а у Istio 25 мс, что на 19 мс больше.В максимуме у Istio задержка составляет 221 мс, почти на 200 мс больше, чем у базовой конфигурации (23 мс), а у Linkerd — 92 мс в абсолютном выражении и 70 мс по сравнению с базовой — в 2,5 раза меньше, чем у Istio. И снова на p99 задержка Istio резко возрастает почти до 200 мс, а у Linkerd падает всего до 90 мс.
Задержка при 2000 об/с
Наконец, при 2000 RPS (что почти в три раза больше, чем у Kinvolk) ситуация примерно та же — у Linkerd медианная задержка на 9 мс выше базовой конфигурации (6 мс), а у Istio — на 15 мс выше.В максимуме у Linkerd оно больше на 47 мс по сравнению с базовой конфигурацией (25 мс), а у Istio почти в пять раз больше — 253 мс.
В целом, в каждом процентиле задержка у Istio была на 40–400 % лучше, чем у Linkerd. 
Потребление ресурсов
Теперь посмотрим на потребление ресурсов.Потребление памяти и ЦП для обеих сервисных сеток показано на графиках ниже.
Цифры практически не зависят от количества запросов в секунду, поэтому мы остановимся подробнее на сценарии с самой высокой нагрузкой — 2000 RPS. В плоскости управления мы видим, что Istio потребляет в среднем 837 МБ памяти, почти в 2,5 раза больше, чем Linkerd — 324 МБ.
Разница в потреблении ЦП в плоскости управления еще более впечатляющая — 71 мс у Linkerd против 3,7 с у Istio. Но нас больше интересуют цифры для плоскости данных.
Это именно та часть сетки, которая должна масштабироваться вместе с приложением.
Здесь разница очень заметна: в среднем максимальное потребление памяти Linkerd составляет 17,8 МБ, а у прокси Istio Envoy — в восемь раз больше, 154,6. Максимальное время процессора у Linkerd — 10 мс, а у Istio почти на порядок больше — 88. 
Полученные результаты
Бенчмарки, моделирующие реальные сценарии, показывают, что Linkerd заметно превосходит Istio и потребляет в несколько раз меньше ресурсов в плоскости данных.При максимальном количестве запросов в секунду Linkerd потребляет лишь девятую часть памяти и восьмую часть времени процессора Istio на уровне данных, при этом медианная задержка всего на 75 % больше, чем в базовой конфигурации, и менее чем на одну пятую дополнительную задержку, которую дает Istio. .
Бенчмаркинг — это искусство.
В этих экспериментах мы намеренно повторили то, что сделал Кинволк, но хотим кое-что изменить в будущем.
Например:
- Измеряйте общее, а не максимальное потребление ресурсов, чтобы лучше отображать истинные затраты.
- Измеряйте ресурсы ЦП в ядрах, а не во времени, чтобы это было больше похоже на способ измерения памяти.
- Рассчитайте процентили задержки для всех данных во всех прогонах вместо того, чтобы брать среднее значение отдельных прогонов, чтобы получить более точные цифры.
У них было 30 минут стабильного трафика, разные кластеры, разные дата-центры и другие методы учета различий в оборудовании или сетях.
Мы со своей стороны сначала попытались найти среду с минимальными расхождениями.
Почему Linkerd настолько быстрее и легче?
Эта разница в производительности и потреблении ресурсов между Linkerd и Istio в основном объясняется микропрокси на базе Rust , Linkerd2-прокси .Микропрокси лежит в основе плоскости данных Linkerd, и тесты во многом отражают его производительность и потребление ресурсов.
Мы много написал про Linkerd2-прокси И причины, почему мы любим Rust еще в 2018 году.
Интересный факт: Linkerd2-прокси был разработан не для производительности, а для оперативный соображения.
Чтобы использовать сервисную сетку на основе Envoy, такую как Istio, вам необходимо стать экспертом по Envoy. Мы решили не мучить этим пользователей Linkerd. Примечание автора: Прокси — пожалуй, самая интересная часть сервисной сетки с технической точки зрения, но наименее интересная для пользователей.
Мы считаем, что прокси-сервер Service Mesh должен составлять второстепенную часть реализации.
Мы прилагаем все усилия, чтобы большинству пользователей Linkerd не пришлось ничего узнавать о Linkerd2-прокси.
.
Как назло, Linkerd2-прокси обеспечил большой прирост производительности и эффективности.
Он был разработан исключительно как прокси-сервер сервисной сетки, поэтому он был невероятно эффективен на уровне данных.
Выбрав Rust, мы также получили все преимущества его экосистемы: при создании библиотек, таких как Токио , Гипер И Башня , используются лучшие принципы проектирования и системный подход. Linkerd2-proxy — это не только невероятно быстрый, легкий и безопасный прокси.
Он представляет собой одну из самых современных технологий во всей CNCF.
Планы на будущее
Как ни странно, несмотря на отличные результаты Linkerd в этих тестах, мы еще не изучали производительность прокси-сервера.Работая в этом направлении, мы собираемся еще больше улучшить нашу производительность.
Мы внимательно наблюдаем СМП проект , которые могут представлять стандарты сравнительного анализа.
В идеале бенчмаркинг будет проводиться независимыми третьими сторонами.
Это подводит нас к следующей теме:
Как воспроизвести эти эксперименты
Чтобы воспроизвести эти эксперименты самостоятельно, следуйте инструкции по сравнительному тестированию .Руководствуйтесь наши комментарии к методике .
Обязательно найдите среду, которая дает стабильные результаты, особенно если вы хотите оценить максимальную задержку.
Это значение сильно зависит от сетевого трафика, конкуренции за ресурсы и т. д. Помните, что вы получите относительные, а не абсолютные числа.
Расскажите нам, что произошло.
Благодарность
Особая благодарность ребятам из Equinix за предоставление среды Kubernetes; CNCF, который позволил проекту Linkerd провести эти эксперименты; и ребятам из Kinvolk, особенно Тило Фромму, за отличный инструмент для сравнительного анализа.
Связано для всех
Linkerd — это общественный проект в Фонд облачных вычислений .Линкерд поддерживает открытое управление .
Если у вас есть пожелания, вопросы или комментарии, присоединяйтесь к нашему быстро растущему сообществу! Linkerd размещен на GitHub .
У нас есть обширные сообщества в Слабый , Твиттер И список рассылки .
Теги: #Kubernetes #DevOps #Microservices #service mesh #istio #Системное программирование #linkerd #linkerd #Linkerd
-
Scss: Пара Полезных Приемов
19 Oct, 24 -
3D Гис-Проект Городского Пространства
19 Oct, 24
