При преминаването от монолитно приложение към архитектура с микросервиси, ние се сблъскваме с нови проблеми.

В монолитното приложение обикновено е достатъчно просто да се определи къде в системата е възникнала грешката. Най-вероятно проблемът е в кода на самия монолит или в базата данни. Но когато започваме да търсим проблема в архитектура с микросервиси, всичко вече не е толкова очевидно. Трябва да намерим целия маршрут, който е преминал запитването от начало до край, да го изолираме от стотиците микросервиси. Освен това много от тях имат и собствени хранилища, в които също могат да възникват както логически грешки, така и проблеми с производителността и отказоустойчивостта.

Дълго търсех инструмент, който да помогне за справяне с такива проблеми (писах за това в Хабра: 1, 2), но в крайна сметка направих собствено опенсорсно решение. В статията разказвам за предимствата на подхода service mesh и споделям нов инструмент за неговото реализиране.

Разпределеното трасиро е разпространено решение на проблема с намирането на грешки в разпределени системи. Но какво, ако в системата все още не е внедрен такъв подход за събиране на информация за мрежовите взаимодействия, или, което е по-лошо, в част от системата той вече работи коректно, а в друга част не, тъй като не е добавен в старите услуги? За определяне на точната коренна причина за проблема е необходимо да имаме пълна представа за това, което се случва в системата. Особено важно е да разберем кои точно микросервиси участват в основните критични за бизнеса пътища.

Тук на помощ може да дойде подходът service mesh, който ще се заеме с цялата машинерия за събиране на мрежова информация на ниво по-долу от самите услуги. Този подход ни позволява да прихващаме целия трафик и да го анализираме в движение. Освен това приложенията не трябва дори да знаят нищо за него.

Подходът service mesh

Основната идея на подхода service mesh е добавянето на още един инфраструктурен слой над мрежата, който ще ни позволи да извършваме всякакви действия с взаимодействието между услугите. Повечето реализации работят по следния начин: към всеки микросервис се добавя допълнителен sidecar контейнер с прозрачен прокси, през който преминава целият входящ и изходящ трафик на услугата. И точно в това пространство можем да правим клиентска балансировка, да прилагаме политики за сигурност, да въвеждаме ограничения на броя заявки и да събираме важна информация относно взаимодействието на услугите в продукция.

Решения

Вече има няколко реализации на този подход: Istio и linkerd2. Те предлагат множество възможности извън кутията. Но в същото време идва и голям разход на ресурси. Освен това, колкото по-голям е клъстъра, в който работи такава система, толкова повече ресурси са необходими за поддържането на новата инфраструктура. В Авито експлоатираме kubernetes клъстери, в които има хиляди екземпляри на услуги (и техният брой продължава да нараства бързо). В текущата реализация Istio консумира около 300Mb оперативна памет на всеки екземпляр на услуга. Поради голямото количество възможности, прозрачното балансиране също оказва влияние на общото време за отговор на услугите (до 10ms).

В края на краищата, ние проучихме какви именно възможности са ни необходими в момента и решихме, че основното, поради което започнахме да внедряваме подобни решения, беше възможността да събираме информация за tracing от цялата система прозрачно. Също така искахме да имаме контрол върху взаимодействието на услугите и да извършваме различни манипулации с заглавията, които се предават между услугите.

В резултат на това достигнахме до нашето решение:  Netramesh.

Netramesh

Netramesh — това е леко service mesh решение с възможност за безкрайно мащабиране, независимо от броя на услугите в системата.

Основните цели на новото решение бяха малък разход на ресурси и висока производителност. От основните възможности искахме веднага да можем прозрачно да изпращаме tracing span’и в нашата Jaeger система.

Днес повечето облачни решения са реализирани на Golang. И, разбира се, това има своите причини. Писането на мрежови приложения на Golang, които работят асинхронно с вход-изход и се мащабират по необходимост на ядра, е удобно и доста просто. И, което също е много важно, производителността е достатъчна за решаване на тази задача. Затова и ние избрахме Golang.

Производителност

Сфокусирали сме усилията си върху постигане на максимална производителност. За решение, което се внедрява до всеки инстанс на услугата, е необходимо малко потребление на оперативна памет и процесорно време. И, разбира се, забавянето при отговора също трябва да е минимално.

Нека видим какви резултати получихме.

RAM

Netramesh консумира ~10Mb без трафик и 50Mb при максимум натоварване до 10000 RPS на един инстанс.

Istio envoy прокси винаги консумира ~300Mb в нашите клъстери с хиляди инстанси. Това не позволява да го мащабируем в целия клъстер.

С Netramesh получихме намаляване на потреблението на памет с ~10 пъти.

CPU

Използването на CPU е относително равно под натоварване. То зависи от броя на заявките за единица време към sidecar. Стойностите при 3000 заявки в секунда в пик:

Има още един важен момент: Netramesh е решение без control plane и без натоварване не консумира процесорно време. С Istio sidecar-ите винаги обновяват endpoint-ите на услугите. В резултат можем да видим такава картина без натоварване:

Използваме HTTP/1 за взаимодействие между услугите. Увеличението на времето за отговор при проксифицирането през envoy с Istio е било до 5-10ms, което е доста много за услуги, които са готови да отговарят за милисекунда. С Netramesh това време намалява до 0.5-2ms.

Мащабируемост

Небольшо количество ресурси, изразходвани от всеки прокси, позволява да се разположи близо до всяка услуга. Netramesh е създаден без компонент на control plane за просто поддържане на лекотата на всеки sidecar. Често в решенията за service mesh control plane разпространява информация за service discovery във всеки sidecar. С нея идва и информация за тайм-аутите, настройки за балансиране. Всичко това позволява да се правят много полезни неща, но, за съжаление, увеличава размера на sidecar-ите.

Откриване на услуги

Netramesh не добавя никакви допълнителни механизми за service discovery. Целият трафик се проксифицира прозрачно през netra sidecar.

Netramesh поддържа HTTP/1 приложение протокол. За определянето му се използва конфигурируем списък с портове. Обикновено в системата има няколко порта, по които се извършва взаимодействие по HTTP. Например, за взаимодействие между услуги и външни заявки използваме 80, 8890, 8080. В такъв случай те могат да бъдат зададени с помощта на променливата за среда. NETRA_HTTP_PORTS.

Ако използвате Kubernetes като оркестратор и неговия механизъм Service за вътрешногрупово взаимодействие между услугите, механизмът остава точно същият. Първо, микросервисът получава service IP адрес чрез kube-dns и отваря ново свързване към него. Това свързване първоначално се установява с локалния netra-sidecar и всички TCP пакети първоначално пристигат именно в netra. След това netra-sidecar установява свързване с първоначалната точка на назначение. NAT на pod IP на възела остава точно същият, както и без netra.

Разпределено проследяване и предаване на контекста

Netramesh предоставя функционалността, необходима за изпращане на tracing span’ове относно HTTP взаимодействията. Netra-sidecar обработва HTTP протокола, измерва закъсненията на заявките, извлича необходимата информация от HTTP заглавията. В крайна сметка получаваме всички trace’ове в единна система Jaeger. За фина конфигурация могат да се използват също променливи за среда, предоставени от официалната библиотека. jaeger go library.

Но има проблем. Докато услугите не генерират и предават специалния uber заглавие, няма да видим свързаните tracing span’ове в системата. А това е, което ни е необходимо за бързо откриване на причините за проблемите. Тук Netramesh отново има решение. Прокси четат HTTP заглавията и, ако в тях няма uber trace id, го генерират. Netramesh също така съхранява информация за входящите и изходящите заявки в sidecar и съпоставя тях чрез обогатяване с необходимите заглавия на изходящите заявки. Всичко, което е необходимо да направят услугите, е да предават само едно заглавие. X-Request-Id, което може да бъде конфигурирано с помощта на променливата за среда. NETRA_HTTP_REQUEST_ID_HEADER_NAME. За управление на размера на контекста в Netramesh, могат да се задават следните променливи за среда: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (времето, през което контекстът ще се съхранява) и NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (периодичността на почистването на контекста).

Също така е възможно да комбинирате няколко пътеки във вашата система, маркирайки ги с помощта на специален сесионен маркер. Netra позволява да установите HTTP_HEADER_TAG_MAP за преобразуване на HTTP заглавия в съответните tracing span тагове. Това може да бъде особено полезно за тестване. След преминаване на функционалния тест, можете да видите коя част от системата е била засегната, като филтрирате по съответния session ключ.

Определяне на източника на заявката

За определяне откъде е дошла заявката, може да се възползвате от функционалността за автоматично добавяне на заглавие с източник. С помощта на променливата на средата NETRA_HTTP_X_SOURCE_HEADER_NAME може да зададете името на заглавието, което ще се задава автоматично. С помощта на NETRA_HTTP_X_SOURCE_VALUE можете да зададете стойност, в която ще се задава заглавието X-Source на всички изходящи заявки.

Това позволява унифицирано разпределение на този полезен заглавие в цялата мрежа. След това можете да го използвате в службите и да го добавите в логове, метрики.

Роутинг на трафик и вътрешности на Netramesh

Netramesh се състои от два основни компонента. Първият, netra-init, установява мрежовите правила за прихващане на трафика. Той използва iptables redirect правила за прихващане на целия или част от трафика на sidecar, който е вторият основен компонент на Netramesh. Можете да настроите кои именно портове да бъдат прихващани за входящи и изходящи TCP сесии: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.

Също така в инструмента има интересна възможност — вероятностен роутинг. Ако използвате Netramesh изключително за събиране на tracing span’ове, можете да спестите ресурси в продукционно средище и да включите вероятностен роутинг с помощта на променливите NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (от 0 до 1). Стойността по подразбиране е 1 (прихващан е целия трафик).

След успешен прихват netra sidecar приема ново свързване и използва SO_ORIGINAL_DST опцията на сокета за получаване на първоначалната точка на дестинация. След това Netra отваря ново свързване към оригиналния IP адрес и установява двупосочна TCP комуникация между страните, слушайки целия преминаващ трафик. Ако портът е определен като HTTP, Netra се опитва да го парсира и проследи. Ако парсинга на HTTP не е успешен, Netra прави фалбек на TCP и прозрачно проксира байтовете.

Построяване на граф на зависимостите

След получаване на голямо количество информация за tracing в Jaeger, желаете да получите пълен граф на взаимодействията в системата. Но ако вашата система е достатъчно натоварена и за един ден се натрупват милиарди tracing span-ове, агрегирането им става доста сложна задача. Има официален начин за това: spark-dependencies. Въпреки това, той ще отнеме часове да изгради пълен граф и ще изисква извличане на целия dataset от Jaeger за последните 24 часа.

Ако използвате Elasticsearch за съхранение на tracing span-ове, можете да се възползвате от прост инструмент на Golang, който ще изгради такъв граф за минути, използвайки особеностите и възможностите на Elasticsearch.

Как да използвате Netramesh

Netra може просто да се добави към всяка услуга, работеща под управлението на всеки оркестратор. Можете да видите пример тук.

Към момента Netra няма възможност за автоматично внедряване на sidecar към услугите, но има планове за реализиране.

Бъдещето на Netramesh

Основната цел Netramesh е постигане на минимални разходи за ресурси и висока производителност, предоставяйки основни възможности за observability и контрол на междусервизните взаимодействия.

В бъдеще Netramesh ще получи поддръжка на други протоколи на приложен слой, освен HTTP. В близко бъдеще ще стане възможно L7 рутиране.

Използвайте Netramesh, ако се сблъсквате с подобни проблеми, и пишете ни въпроси и предложения.

Източник: habr.com