Cloud Tracing — сервис распределённой трассировки в VK Cloud. Приложения отправляют в него спаны по протоколу OpenTelemetry, сервис хранит их и отдаёт через Jaeger-совместимое API. Поэтому трейсы можно открывать в привычных Jaeger UI и Grafana без доработок.За этой совместимостью стоит выбор хранилища, который для публичного облака оказывается сложнее, чем кажется. Сервис принимает поток спанов от сотен несвязанных клиентов, хранит десятки терабайт телеметрии и должен надёжно изолировать данные проектов друг от друга. По умолчанию один проект может отправлять до 1 МБ/с, а доступ к данным контролируется токенами IAM. При таких ограничениях недостаточно просто выбрать базу, которая быстро записывает спаны или умеет находить трейс по trace ID.На странице развёртывания Jaeger на момент проектирования сервиса были перечислены шесть вариантов: Cassandra, Elasticsearch, Kafka, gRPC-плагин, Badger и memory. На первый взгляд это полноценный список кандидатов. Но локальные хранилища отпадают для прода, Kafka оказывается буфером перед настоящим хранилищем, а gRPC-плагин служит способом подключить систему, которой в списке нет. В результате сравнивать приходится Cassandra и Elasticsearch, а через плагин появляется третий вариант — ClickHouse.Я Леонид Левин, архитектор PaaS в VK Cloud. Этот разбор мы подготовили вместе с технологическим евангелистом Стасом Погоржельским и инженерами сервиса. Мы разберём, почему Cassandra и Elasticsearch по-разному подходят для хранения трейсов, что дали чужие продовые кейсы и наши замеры до 362 тысяч спанов в секунду на четырёх ядрах коллектора, а также как схема хранения на ClickHouse закрыла точечное чтение и поиск по атрибутам. Читать далее