Превод на статията: Модел на нишки на Envoy — https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310

Тази статия ми се стори достатъчно интересна, а тъй като Envoy най-често се използва като част от «istio» или просто като «ingress controller» в Kubernetes, повечето хора няма да имат същото директно взаимодействие с него, както например с типични инсталации на Nginx или Haproxy. Въпреки това,ако нещо се наложи, би било добре да разберем как е устроено отвътре. Опитах се да преведа възможно най-много текст на български, включително и специални термини; за тези, които не желаят да виждат това, оставих оригиналите в скобки. Добре дошли под кат.

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

Един от най-често задаваните технически въпроси, които получавам за Envoy, е искането за ниско ниво описание на използваната модел на нишки (threading model). В този пост ще опиша как Envoy свързва съединенията с нишките и ще дам описание на системата за локално съхранение на нишки (Thread Local Storage), която се използва, за да направи кода по-паралелен и високопроизводителен.

Общ преглед на нишките (Threading overview)

Envoy използва три различни типа нишки:

Основен (Main): Тази нишка управлява стартирането и спирането на процеса, цялата обработка на API XDS (xDiscovery Service), включително DNS, проверка на здравословното състояние (health checking), общо управление на клъстера и процеса на работа на услугата (runtime), нулиране на статистиката, администриране и общо управление на процесите — Linux сигнали, горещо рестартиране (hot restart) и т.н. Всичко, което се случва в тази нишка, е асинхронно и „неблокирующее“. Обикновено основната нишка координира всички критични процеси на функционалността, за изпълнението на които не е необходимо голямо количество CPU. Това позволява голяма част от управленския код да бъде написан така, сякаш е еднопоточен.
Работен (Worker): По подразбиране Envoy създава работна нишка (worker thread) за всеки физически поток в системата, контролирано чрез опцията --concurrency. Все работни потоци стартират "неблокираща" цикъл от събития (event loop), който отговаря за прослушването (listening) на всеки слушател (listener). Към момента на написването на статията (29 юли 2017 г.) няма сегментиране (sharding) на слушателя (listener), приемане на нови връзки, създаване на инстанция на стека от филтри за свързване и обработка на всички операции по вход-изход (IO) по време на съществуването на връзката. Отново, това позволява голяма част от кода за обработка на връзките да бъде написан, сякаш е еднопоточен.
Файлов (File flusher): Всеки файл, който записва Envoy, основно дневници за достъп (access logs), в момента има независим блокиращ поток. Това се дължи на факта, че записването в файлове, кеширани от файловата система, дори при използване на O_NONBLOCK понякога може да блокира (със sigh). Когато работните потоци трябва да запишат във файл, данните фактически се переместят в буфер в паметта, където в крайна сметка се изхвърлят чрез потока file flush. Това е една от областите на кода, в която технически всички работни потоци (worker threads) могат да блокират (block) същата блокировка (lock), опитвайки се да запълнят буфера в паметта.

Обработка на връзки (Connection handling)

Както бе споменато накратко по-горе, всички работни потоци прослушват всички слушатели (listeners) без никакво сегментиране. Следователно, ядрото се използва за разумно изпращане на приетите сокети към работните потоци. Съвременните ядра като цяло са много добри в това, те използват функции, като повишаване на приоритета на вход-изхода (IO), за да се опитат да запълнят потока с работа, преди да започнат да използват други потоци, които също прослушват същия сокет, както и да не използват циклична блокировка (Spinlock) за обработка на всяка заявка.
След като връзката бъде приета на работния поток (worker thread), тя никога не напуска този поток (thread). Цялостната обработка на връзката се извършва напълно в работния поток (worker thread), включително всякакво поведение на пренасочване (forwarding behavior).

Това има няколко важни последствия:

Всички конекционни пулове в Envoy принадлежат на работния поток. По този начин, въпреки че конекционните пулове HTTP/2 правят само едно свързване с всеки родителски хост наведнъж, ако има четири работни потока, ще има четири конекционни HTTP/2 към родителския хост в устойчиво състояние.
Причината, поради която Envoy работи по този начин, е, че запазвайки всичко в един работен поток, почти целият код може да бъде написан без блокирания и така, сякаш е еднопоточен. Този дизайн опростява написването на голямо количество код и се мащабира изключително добре за почти неограничен брой работни потоци.
Въпреки това, един от основните изводи е, че от гледна точка на ефективност на пуловете за памет и свързвания е наистина много важно да се конфигурира параметърът --concurrency. Имате повече работни потоци от необходимото, което води до загуба на памет, създаване на повече неактивни свързвания и намаляване на ефективността на конекционния пул. В Lyft нашите контейнери envoy sidecar работят с много ниска паралелизация, така че производителността е приблизително равна на услугите, до които се намират. Стартираме Envoy като крайна прокси (edge) само при максимална паралелизация.

Какво означава неблокиращият режим

Терминът „неблокиращ“ е използван многократно при обсъждане на начина, по който работят основният и работните потоци. Целият код е написан при предположението, че нищо никога не блокира. Въпреки това, това не е съвсем вярно.

Envoy използва няколко дълги блокировки на процеса:

Както вече бе споменато, при записване на достъпни журнали всички работни потоци получават една и съща блокировка преди запълването на буфера на журнала в паметта. Времето за задържане на блокировката трябва да е много ниско, но е възможно тази блокировка да бъде оспорвана при висока паралелизация и висока пропускна способност.
Envoy използва много сложна система за обработка на статистиката, която е локална за потока. Това ще бъде тема на отделен пост. Все пак, накратко ще спомена, че като част от локалната обработка на статистиката на потока понякога е необходимо да се получи блокировка за централното "хранилище на статистиката". Тази блокировка никога не трябва да бъде необходима.
Основният поток периодично се нуждае от координация с всички работни потоци. Това става чрез "публикуване" от основния поток в работните потоци, а понякога и от работните потоци обратно в основния поток. За изпращането е нужна блокировка, за да може публикуваното съобщение да бъде поставено в опашка за последваща доставка. Тези блокировки никога не трябва да подлежат на сериозно съревнование, но все пак могат технически да бъдат блокирани.
Когато Envoy записва в системния поток за грешки (standard error), той получава блокировка на целия процес. Като цяло, локалното водене на журнал от Envoy се счита за ужасно по отношение на производителността, затова му не се обръща много внимание за подобрение.
Има няколко други случайни блокировки, но нито една от тях не е критична за производителността и никога не трябва да се оспорва.

Локално хранилище на потока (Thread local storage)

Поради начина, по който Envoy отделя задълженията на основния поток от задълженията на работния поток, съществува изискване, че сложната обработка може да бъде извършена в главния поток и след това предоставена на всеки работен поток с висока степен на паралелизъм. В този раздел се описва системата Envoy Thread Local Storage (TLS) на високо ниво. В следващия раздел ще опиша как тя се използва за управление на клъстера.

Както вече беше споменато, основният поток обработва практически всички функции на управлението (management) и функционалността на плоскостта за управление (control plane) в процеса на Envoy. Плоскостта за управление тук е малко претоварена, но ако я разгледаме в контекста на самия процес на Envoy и я сравним с маршрутизацията, извършвана от работните потоци, тя изглежда разумна. Като общо правило, процесът на основния поток извършва определена работа, а след това е необходимо да обнови всеки работен поток в съответствие с резултата от тази работа. в това време работният поток не трябва да поставя заключване при всеки достъп.

Системата TLS (Thread local storage) Envoy работи по следния начин:

Кодът, изпълняващ се в основния поток, може да выдели слот TLS за целия процес. Въпреки че това е абстрактно, на практика това е индекс в вектор, осигуряващ достъп O(1).
Основният поток може да задава произволни данни в своя слот. Когато това е направено, данните се публикуват във всеки работен поток като обичайно събитие от цикъла на събитията.
Работните потоци могат да четат от своя слот TLS и да извлекат всякакви локални данни на поток, налични там.

Въпреки че това е много проста и невероятно мощна парадигма, която много прилича на концепцията за заключване RCU (Read-Copy-Update). По същество, работните потоци никога не виждат никакви промени в данните в слотовете TLS по време на изпълнението на работа. Промяната се случва само в периода на покой между работни събития.

Envoy използва това по два различни начина:

Запазвайки различни данни на всеки работен поток, достъпът до тези данни се осъществява без никакво заключване.
Запазвайки общ указател на глобални данни в режим "само за четене" на всеки работен поток. Така, всеки работен поток има брояч на препратките към данните, който не може да бъде намален по време на изпълнението на работа. Само когато всички работници се успокоят и заредят нови общи данни, старите данни ще бъдат унищожени. Това е идентично на RCU.

Поток за актуализация на кластера (Cluster update threading)

В този раздел ще опиша как TLS (Thread local storage) се използва за управление на кластера. Управлението на кластера включва обработка на API xDS и / или DNS, както и проверка на работоспособността (health checking).

Управлението на потоците на кластера включва следните компоненти и етапи:

Мениджърът на кластера е компонент в Envoy, който управлява всички известни upstream на кластера, API интерфейса CDS (Cluster Discovery Service), API интерфейсите SDS (Secret Discovery Service) и EDS (Endpoint Discovery Service), DNS и активни външни проверки на работоспособността (health checking). Той е отговорен за създаването на "в крайна сметка последователно" (eventually consistent) представление на всеки upstream на кластера, което включва откритите хостове, както и състоянието на работоспособността (health status).
Инструмент за проверка на работоспособност (health checker) активно проверява работоспособността и докладва за промените в състоянието на работоспособността на клъстерния мениджър.
CDS (Cluster Discovery Service) / SDS (Secret Discovery Service) / EDS (Endpoint Discovery Service) / DNS се изпълняват за установяване на принадлежност към клъстера. Промените в състоянието се връщат на мениджъра на клъстера.
Всеки работен поток постоянно изпълнява цикъл на обработка на събития.
Когато мениджърът на клъстера определи, че състоянието на клъстера е променено, той създава нова снимка на състоянието на клъстера, достъпна само за четене, и я изпраща на всеки работен поток.
През следващия период на покой работният поток ще обнови снимката в резервирания слот TLS.
По време на събитието на вход-изход, което трябва да определи хост за управление на натоварването, балансировчикът на натоварването ще поиска слот TLS (Thread local storage) за извличане на информация за хоста. Не са необходими блокировки за това. Обърнете внимание, че TLS също може да инициира събития при обновяване, така че подсистемите за управление на натоварването и други компоненти да могат да пресмятат кешове, структури от данни и т.н. Това е извън обхвата на тази статия, но се използва на различни места в кода.

Използвайки описаната по-горе процедура, Envoy може да обработва всяка заявка без никакви блокировки (освен описаните по-рано). Освен сложността на самия код TLS, по-голямата част от кода не е необходимо да разбира как работи многопоточността и може да бъде написана в еднопоточен режим. Това улеснява написването на по-голямата част от кода в допълнение към отличната производителност.

Други подсистеми, които ползват TLS (Other subsystems that make use of TLS)

TLS (Thread local storage) и RCU (Read Copy Update) се използват широко в Envoy.

Примери за използване:

Механизмът за промяна на функционалността по време на изпълнение: Текущият списък на включената функционалност се изчислява в основния поток. След това на всеки работен поток се предоставя снимка само за четене с използване на семантиката RCU.
Замяна на таблици с маршрути.: За таблиците на маршрути, предоставени от RDS (Route Discovery Service), таблиците на маршрути се създават в основния поток. Snapshot, само за четене, ще бъде предоставен на всеки работен поток, използвайки семантиката RCU (Read Copy Update). Това прави промените в таблиците на маршрути атомарно ефективни.
Кеширане на HTTP заглавия: Както се оказва, изчисляването на HTTP заглавието за всяка заявка (при изпълнение на ~25K+ RPS на ядро) е доста скъпо. Envoy централно изчислява заглавието приблизително на всеки половин секунда и го предоставя на всеки работник през TLS и RCU.

Има и други случаи, но предходните примери трябва да осигурят добро разбиране за какво се използва TLS.

Известни проблеми с производителността (Known performance pitfalls)

Въпреки че общо взето Envoy работи доста добре, има няколко известни области, които изискват внимание, когато се използва с много висока паралелност и пропускна способност:

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

Заключение (Conclusion)

Моделът на потоците Envoy е проектиран да осигури простота при програмирането и масивен паралелизъм, като същевременно позволява потенциално неефективно използване на паметта и връзките, ако не са правилно конфигурирани. Тази моделна структура работи изключително добре при много голям брой потоци и пропускна способност.
Както споменах накратко в Twitter, дизайнът може да работи и над напълно функционален мрежов стек в режим на потребителя, като DPDK (Data Plane Development Kit), което може да доведе до това обикновените сървъри да обработват милиони заявки в секунда с пълна обработка на L7. Ще бъде много интересно да видим какво ще бъде построено през следващите няколко години.
Един последен кратък коментар: много пъти ми зададоха въпроса защо избрахме C ++ за Envoy. Причината остава, че това все още е единственият широко разпространен език на индустриално ниво, на който може да се изгради архитектурата, описана в този пост. C ++ определено не е за всички или дори за много проекти, но за определени случаи на употреба все още е единственият инструмент за извършване на работата.