Это вторая серия про Cloudflare после кейса с Browser Run. Тогда мы смотрели, как они лихо раскочегарили шестьдесят браузеров в минуту для клиентов — проверка скорости на прочность, всё чистенько и на публику. А теперь они рассказали про совершенно другой слой: не про скорость, а про риск срыва биллинга из-за невидимых блокировок внутри ClickHouse.

И вот что меня цепляет: если первая история была про то, как Cloudflare стала «молодцом» на дашборде производительности (шестьдесят браузеров, обалдеть), то вторая — про то, кто на самом деле держит рычаг денег. А держит его та самая невидимая планировка запросов, которая может застрять в тихую, пока все любуются зелёными метриками. Не переплата за пару лишних гигабайт — здесь на кону реальные счета для реальных клиентов, которые могут просто не уйти вовремя.

Когда всё зелёное, но счета не идут

У Cloudflare в ClickHouse хранится больше ста петабайт данных. ClickHouse — это аналитическая база данных: она умеет моментально считать статистику по горам информации. Я загуглила: один петабайт — это примерно 500 миллиардов страниц текста. Так вот, они решили улучшить одну огромную таблицу — добавили колонку к ключу партиционирования. Партиционирование — это когда данные режут на куски по логике (например, по дате), чтобы не лазить по всему массиву, а сразу тыкаться в нужную горку. Всё по науке: планировали, согласовывали, запустили.

Прошло несколько недель. И вдруг — тишина. Биллинговые процессы, которые генерируют реальные счета для реальных клиентов, едва ползут. А завтра дедлайн. Представляете: вы отвечаете за деньги компании, тысячи счетов должны уйти, а инженеры разводят руками — метрики же чистые.

Но я читаю между строк и вижу здесь не только технический баг. Это управленческий риск: кто на дашборде «молодец»? На нём — инженеры, которые смотрят на I/O и память. А кто реально держит рычаг денег? Те самые потоки планировщика, которые молча застревают в lock contention.

Петабайты молчат, а внутри — пробка

Инженеры таращатся в мониторинг: ввод-вывод в норме, памяти полно, строки читаются быстро, диски не жалуются. Всё зелёное как на параде. Но процесс, от которого зависят реальные деньги, еле дышит. Стандартные метрики не показывают ничего подозрительного — это как искать очки, которые уже на носу, только очки стоят репутационных миллионов.

Проблема оказалась в lock contention. Если по-простому: когда ClickHouse готовит запрос, он строит query plan — план обхода по данным, к каким кускам обращаться. Этот самый планировщик и заблокировался из-за нового способа разбиения данных. Потоки внутри системы начали ждать друг друга — настоящая пробка. А снаружи — ни одного красного сигнала. Тишина.

Я залезла поглубже: ClickHouse использует блокировки на уровне метаданных, когда один запрос читает структуру таблицы, а другой её же меняет. В обычной жизни — секунды. Но с новым партиционированием десятки запросов вцепились в одни и те же метаданные, и всё застыло. Это не про то, что «данных много», а про то, что запросы не могут договориться, кто первый полезет.

Что вынимать из этой истории для себя

Честность Cloudflare заслуживает уважения — многие такие сценарии просто заметают под ковёр. Но практический урок тут простой и для всех, кто работает с большими данными.

Первое: если у вас вдруг начались тормоза без очевидной причины — не смотрите на зелёные метрики, как на икону. Смотрите на время ожидания. Утилита perf на Linux или syscall futex (это когда потоки спят в ожидании друг друга) покажут вам правду раньше, чем любой дашборд. Я сама как-то гонялась за «падением производительности» полдня, пока не увидела, что половина запросов просто спала на блокировках — снаружи всё было зелёное.

Второе: если вы используете ClickHouse, настройте мониторинг самого планировщика. Cloudflare сейчас патчит его, чтобы выкидывать такие contention’ы в логи. Но вы можете уже сегодня: смотрите на метрики MergeTree в ClickHouse, они показывают, сколько запросов ждут освобождения блокировок. Это не rocket science — это три кривых графика в Prometheus.

Третье: нарисуйте себе чек-лист на случай внезапного замедления системы без видимых причин. Например: «Проверить количество ожидающих запросов в планировщике», «Проверить время в futex в топе процессов», «Проверить, не было ли изменений в партиционировании за последнюю неделю». Это вас спасёт от срыва дедлайнов, когда все дашборды молчат.

Инфраструктура на petabyte-scale — это джунгли, где опасности не видно невооружённым глазом. Cloudflare выглядит умнее не потому, что никогда не ломается, а потому что сумела заметить сбой там, где все графики упорно молчали.

Материалы