Netflix перестроила pipeline для Service Topology, чтобы real-time service map оставалась полезной под production scale. Ключевой вопрос здесь не в скорости обработки, а в том, как сохранить актуальность, целостность и управляемую деградацию.
Service Topology у Netflix строится на нескольких источниках: eBPF network flows, IPC metrics и distributed traces. Это даёт более полную карту зависимостей, но и создаёт сложную задачу на уровне ingestion pipeline. Сырые flow-records показывают сетевые hops, а не логическую связь между приложениями. Поэтому система должна не просто принять данные, а интерпретировать их и восстановить смысл.
Проблема проявляется на горячих путях. Популярные назначения создают концентрацию нагрузки, а intermediary resolution требует собрать связанные flows в одном месте. В старой схеме это приводило к hot instances. Netflix описывает случаи, когда отдельные узлы получали до 100 раз больше типичного трафика, одновременно выполняя I/O-heavy enrichment. На таком фоне сервис начинает деградировать не по одной оси, а сразу по нескольким: растёт давление на compute, storage и memory pressure.
Решение оказалось архитектурным, а не косметическим. Netflix разделила pipeline на три стадии: initial aggregation, intermediary resolution и graph persistence. Такой разрез отделяет тяжёлую интерпретацию потоков от enrichment и записи в граф. Это компромиссный, но прагматичный выбор. Он усложняет сам pipeline, но снижает риск того, что одна стадия станет узким горлышком для всей системы.
Первая стадия читает multi-region Kafka streams, фильтрует invalid records, собирает данные в five-minute windows и строит initial aggregators. Вторая стадия превращает intermediary hops в direct application-to-application edges и перераспределяет результаты. Третья стадия обогащает nodes данными о health, ownership и metadata, а затем сохраняет их в graph database. Такой порядок важен: сначала нужно восстановить смысл связи, и только потом тратить ресурсы на enrichment и persistence.
В реализации Netflix также изменила транспорт между стадиями. Вместо gRPC внутри pipeline используется server-sent events. По описанию компании, gRPC стал дорогим на этом масштабе из-за serialisation, connection-pool management и memory pressure на streaming responses. SSE оказался легче и лучше согласуется с reactive backpressure. При этом gRPC API для клиентов Service Topology сохранился. Это важная деталь: внутренний transport можно упростить, не затрагивая внешний контракт.
Отдельный слой инженерной дисциплины здесь — backpressure. Netflix использует Apache Pekko Streams, чтобы давление распространялось вверх по цепочке. Если graph storage не успевает, consumer Kafka не пытается бесконечно проталкивать данные дальше. Он останавливается и оставляет records в Kafka до появления capacity. Это значит, что система выбирает delayed freshness вместо потери данных. Для incident response это более безопасное поведение, чем неполная карта зависимостей, которая выглядит актуальной только на первый взгляд.
Интересен и механизм масштабирования. Processing fleet расширяется и сжимается по demand. Каждый instance читает текущий список healthy instances из service registry и применяет consistent hashing, чтобы определить владельца каждого aggregator. Когда instance добавляется или уходит, только затронутые aggregators переезжают на новые узлы. Это убирает отдельный rebalancing process и делает распределение более локальным. Для такой системы это разумный способ удерживать overhead под контролем.
При этом IPC pipeline устроен проще. Его metrics уже partitioned by application, поэтому там не требуется такая же тяжёлая стадия redistribution. Это показывает важный архитектурный принцип: одинаковая модель обработки не обязана подходить всем источникам данных. Сложность должна следовать за структурой данных, а не за желанием унифицировать всё ради удобства.
Наконец, Netflix описывает историческую реконструкцию топологии. Вместо полного хранения graph snapshots или replay event log система держит time-windowed aggregator snapshots и property-level mutation history. Это позволяет восстановить topology на конкретный момент времени. Для расследования инцидентов это особенно ценно, потому что зависимость меняется не только в текущем состоянии, но и вокруг события. Здесь виден ещё один компромисс: компания не хранит всё подряд, а сохраняет достаточно данных, чтобы собирать прошлое по запросу.
В сухом остатке Netflix показывает зрелый production подход. Система не пытается быть мгновенной любой ценой. Она принимает задержку свежести, чтобы не терять данные и не разрушать целостность карты зависимостей. Для архитекторов это полезный ориентир: real-time observability pipeline должен быть не только быстрым, но и предсказуемым под нагрузкой.