Раздел 5.4. Потоки данных: Нервная система бизнеса (2010 — ...)

К 2010 году интернет изменился. Пользователи больше не заходили на сайты, чтобы просто почитать текст. Они начали жить в сети. Чаты, лайки, стриминг видео, биржевые котировки — всё это требовало мгновенной реакции. Старая архитектура, где сервер вежливо обслуживал одного клиента за другим, а данные мирно спали в базах, рухнула.

В этом разделе мы увидим, как русский сисадмин спас мировой интернет от перегрузки, и как инженер LinkedIn превратил хаос данных в упорядоченный поток, вдохновившись мрачным писателем.

Раздел 5.4. Потоки данных: Нервная система бизнеса (2010 — наше время)

А. Проблема C10k и Nginx: Один против десяти тысяч

Предыстория: Эпоха толстых официантов

В начале 2000-х главным веб-сервером планеты был Apache HTTP Server. Это был «автомат Калашникова» в мире веба — надежный, модульный, на нем работал весь ранний интернет (Amazon, Yahoo, eBay).

Но у Apache была архитектурная проблема, заложенная в 90-х: он работал по модели «Один клиент — Один процесс».

Аналогия с рестораном:

Представьте, что Сервер — это ресторан.

• Модель Apache: На каждого нового посетителя, вошедшего в дверь, ресторан нанимает отдельного официанта. Этот официант стоит над душой клиента, пока тот читает меню, ест, пьет кофе и платит.
• Масштаб: Если в ресторане 5 посетителей — всё отлично. Но если пришло 10 000 посетителей (популярный сайт), вам нужно нанять 10 000 официантов.
• Катастрофа: Эти официанты начинают толкаться в проходах. Они сжирают всю еду (оперативную память, RAM) и кислород (процессорное время) просто фактом своего существования. Даже если клиенты ничего не делают (просто читают страницу), 10 000 процессов висят в памяти.

В 1999 году Дэн Кегель сформулировал это как C10k Problem (Concurrent 10k connections) — проблема 10 тысяч одновременных соединений.

В те годы это было приговором. Если на ваш сайт ставил ссылку популярный ресурс (например, Slashdot), сервер падал за секунды. Это называлось «Слэшдот-эффект». Железо было дорогим, и купить сервер с 64 Гб оперативной памяти было невозможно.

Игорь Сысоев: Код из подвала Рамблера

В начале 2000-х в Москве, в компании Rambler (тогдашнем «русском Google»), работал системный администратор Игорь Сысоев.

Rambler испытывал колоссальные нагрузки. Сысоев видел, как серверы Apache задыхаются, и понимал: дело не в слабом железе, дело в устаревшей логике обработки соединений.

В свободное от работы время (начиная с 2002 года) он начал писать свой веб-сервер на языке C. Он хотел создать инструмент, который решал бы проблему C10k не грубой силой, а хитростью. Он назвал его Nginx (читается как «Engine X»).

Техническая революция: Event Loop

Сысоев отказался от модели «Один клиент — Один процесс». Он внедрил модель Асинхронного, неблокирующего ввода-вывода (Event Loop).

Аналогия с рестораном (Nginx):

В ресторане всего Один официант-супергерой (на каждое ядро процессора). Но он работает иначе:

1. Он подбегает к столику №1: «Выбрали? Нет? Ок, я не буду ждать, я вернусь через миллисекунду».
2. Мгновенно подбегает к столику №2: «Заказ принят, передаю на кухню (в базу данных)».
3. Мгновенно к столику №3: «Вот ваш счет».

Этот «официант» (Worker) никогда не блокируется (не ждет). Он крутится в бесконечном цикле, обрабатывая тысячи мелких событий в секунду.

Результат: Nginx мог держать 10 000, 50 000, 100 000 соединений, потребляя всего 10–20 мегабайт памяти (в то время как Apache съедал бы гигабайты).

Победа и Бизнес-триумф

В 2004 году, в день основания компании Nginx, Сысоев открыл исходный код под лицензией BSD (делайте что хотите).

Сначала технологию взяли русские гиганты (ВКонтакте, Яндекс, Mail.ru), потому что им нужно было держать нагрузку рунета на ограниченном железе.

Затем слухи дошли до Запада.

• Когда Netflix, Instagram, Airbnb и Pinterest начали взрывной рост, они столкнулись с той же проблемой: Apache не справлялся. Они все мигрировали на Nginx.

Финал истории:

Игорь Сысоев долгое время не монетизировал проект. Только в 2011 году была создана коммерческая компания Nginx Inc.

В 2019 году американская корпорация F5 Networks купила Nginx за $670 миллионов.

Русский сисадмин, решавший локальную проблему Рамблера, случайно создал фундамент, на котором сегодня работает 70% самых нагруженных сайтов мира.

Б. Apache Kafka: Лог — это главное

Если Nginx решил проблему соединений (как пустить миллион людей в дверь), то следующая проблема была в данных. Что делать с информацией, которую эти миллионы людей генерируют каждую секунду?

Сюжет: Кошмар в LinkedIn (2010)

Представьте социальную сеть LinkedIn в 2010 году. Компания быстро растет, но внутри царит технологический ад.

У них есть десятки разрозненных систем:

• Frontend (показывает профили).
• Поиск (индексирует людей).
• Рекомендации («Люди, которых вы можете знать»).
• Безопасность (ловит спамеров).
• Аналитика (считает клики для рекламодателей).

Каждой системе нужны данные от всех остальных.

Команда «Поиска» просит команду «Сайта»: «Скидывайте нам новые профили раз в час в CSV-файле».

Команда «Безопасности» просит: «Дайте нам прямой доступ к базе, мы будем читать логины».

Это превратилось в Спагетти-архитектуру. Количество связей росло как $N^2$. Данные терялись, базы падали под нагрузкой от постоянных выгрузок. Разработчики тратили 80% времени на написание «труб» для перекачки данных.

Джей Крепс и идея Писателя

Ведущий инженер LinkedIn Джей Крепс (Jay Kreps) понял, что проблема фундаментальна.

«Мы пытаемся использовать базы данных (SQL) для передачи информации. Но базы данных созданы для хранения. Нам нужна не библиотека, а телеграф. Нам нужна труба».

Крепс вспомнил старую, низкоуровневую концепцию из устройства баз данных — Transaction Log (Журнал транзакций).

Это просто файл на диске, в который события дописываются строго в конец (Append Only):

1. Вася зашел на сайт.
2. Петя лайкнул Машу.
3. Маша обновила фото.

Джей Крепс решил построить систему, которая будет только гигантским, быстрым, распределенным Журналом. Никаких сложных индексов, никаких изменений задним числом. Только запись в конец.

Он назвал систему Kafka.

Почему такое название?

• Официальная версия: Система оптимизирована для писанины (writing), а Франц Кафка — любимый писатель Крепса.
• Неофициальная версия: Ситуация с данными в LinkedIn была настолько бюрократической, запутанной и кошмарной, что напоминала романы Кафки («Процесс», «Замок»).

Как работает Kafka: Центральная нервная система

Kafka — это не база данных, где вы делаете сложные запросы. Это «Тупая труба и умные потребители».

1. Producer (Источник): Сайт просто кричит в трубу (в тему "Клики"): «Пользователь X кликнул!». Ему все равно, кто это услышит. Его задача — быстро сбросить событие.
2. Kafka (Брокер): Записывает это событие в конец файла на диске. Это происходит безумно быстро (миллионы сообщений в секунду), потому что головка жесткого диска не прыгает, а пишет последовательно.
3. Consumers (Потребители): Подписываются на тему.
   • Сервис «Аналитика» читает трубу: «Ага, клик, добавлю в отчет для рекламодателя».
   • Сервис «Рекомендации» читает ту же трубу: «Ага, клик, предложу ему похожую статью».
   • Сервис «Безопасность» читает ту же трубу: «Странный клик, проверю на ботов».

Event-Driven Architecture (Событийная архитектура)

Сервисы больше не знают друг о друге. Они не связаны. Они просто реагируют на события.

Это превратило IT-архитектуру компаний из «набора складов» (баз данных) в Центральную нервную систему. Сигнал от пальца (клик) мгновенно доходит до мозга (аналитика).

Влияние: Data in Motion (Данные в движении)

До Kafka доминировала парадигма Data at Rest (Данные в покое).

• Вы копили данные весь день, а ночью запускали тяжелый отчет (Batch processing). Директор узнавал о проблемах вчерашнего дня только сегодня утром.

Kafka ввела эру Data in Motion (Stream Processing). Данные обрабатываются, пока они летят.

• Uber: Использует Kafka, чтобы рассчитывать цену поездки (Surge Pricing) в реальном времени. Если в районе стадиона резко вырос спрос, цена поднимается мгновенно, а не завтра.
• Банки: Ловят мошеннические транзакции за миллисекунды. Пока ваша карта еще в терминале, алгоритм анализирует поток транзакций через Kafka и блокирует операцию, если она подозрительна.

Бизнес-финал:

В 2014 году Джей Крепс и его команда ушли из LinkedIn и основали компанию Confluent, чтобы продавать Kafka как сервис корпорациям. В 2021 году Confluent вышла на IPO с оценкой $10 миллиардов.

Идея «простого журнала событий» оказалась золотой жилой.

Итог раздела 5.4

2010-е годы подарили нам инструменты для работы с безумными нагрузками современной экономики.

1. Игорь Сысоев (Nginx) научил серверы держать удар миллионов пользователей, используя асинхронность.
2. Джей Крепс (Kafka) научил компании реагировать на действия этих пользователей мгновенно, превратив хаос интеграций в упорядоченный поток событий.

Инфраструктура готова. Данные текут рекой. Но данные сами по себе глупые. Нам нужно что-то, что сможет найти в этом потоке смысл. В следующем, финальном модуле, мы скормим эти петабайты данных Нейросетям и замкнем круг истории, вернувшись к мечте Алана Тьюринга о мыслящей машине.