Mockingbird Shares | Найприємніша категорія інженерних задач — ті, про які користувач навіт...

Найприємніша категорія інженерних задач — ті, про які користувач навіть не здогадується. Ніхто не завів тікет, ніхто не страждав, продукт "просто працює", а десь під капотом команда все одно знайшла вузьке місце і прибрала його. AWS щойно опублікувала розбір того, як влаштована мережа під Lambda, і там таких історій ціла пачка.Контекст такий. Коли твоя Lambda підключена до VPC, її треба пустити в приватну мережу клієнта, а для цього між воркером і цією VPC підіймається Geneve-тунель. Підняти такий тунель коштує близько 150 мілісекунд, і робилося це прямо під час холодного старту. Користувачі бачили це просто як "ну, холодний старт, шо поробиш", і особливо не нили, бо реально, шо ж ти з цим зробиш?!Але інженери взяли і зробили. Тунель тепер піднімають заздалегідь, ще до того як прилетить виклик, але з фейковим ідентифікатором мережі (VNI) замість справжнього. А в момент виклику крихітна eBPF-програма на льоту підміняє цей фейковий VNI на реальний, прямо в заголовку пакета. Дорога частина роботи поїхала з критичного шляху, і 150 мілісекунд перетворились на 200 мікросекунд. Це капець яка крута оптимізація, яку помітили трохи менше ніж нуль користувачів. І ми б не знали, якби не цей пост.Або інша кулсторі. Кожен воркер тримає купу networking-правил для маршрутизації трафіку, і колись усі вони жили в одному кореневому неймспейсі спільною купою, яка розрослася до 125 тисяч правил iptables. Ядро проходить такий список лінійно, згори вниз, тому функція, якій не пощастило опинитись ближче до кінця таблиці, отримувала повільнішу мережу за сусідку зверху, просто через своє місце у списку. Як в анекдоті, де директор взяв пачку особових справ співробітників, витяг з них декількох і сказав звільнити їх, бо він не любить лузерів.Команда рознесла правила по окремих неймспейсах кожної мережі, і коренева таблиця схудла зі 125 тисяч правил до 144 статичних. А заодно stateful NAT на iptables переписали на stateless-маніпуляцію заголовками через той самий eBPF, і налаштування мережі прискорилось у сто разів.Я скажу чесно, нетворкінг це не та зона, де я можу назвати себе експертом. Можливо ці штуки є базою і не мають вражати. І це безсумнівно є daily job для автора поста. Але крім самих технічних деталей, хочу підкреслити те, що тут показано прагматичний data driven підхід до вирішення проблем. Вимірюємо, фіксимо, вимірюємо знову — ніяких припущень "наче стало краще", лише графіки та дашборди.Ну і фіксимо проблему, яку користувачі не бачать, але всі від неї страждають.Більше деталей тут, я отримав щире задоволення від читання і вам рекомендуюЗдається, що графіки в них не з CloudWatch, цікаво, що вони використовують?