Cloudflare запустила Meerkat, экспериментальный сервис глобального распределённого консенсуса без лидера
Внутренние сервисы Cloudflare читают и изменяют одни и те же данные плоскости управления (control-plane), например, информацию о том, где размещён конкретный экземпляр модели ИИ, или о том, какая машина сейчас имеет право писать в базу данных, из более чем 330 дата-центров по всему миру. Для этого нужны гарантии: разные читатели никогда не должны видеть противоречивое состояние, а система обязана оставаться доступной для записи, даже если часть дата-центров или каналов связи отказывает. Обеспечить строгую согласованность (когда каждый читатель гарантированно видит все предыдущие записи) в таких условиях сложно, потому что сеть Cloudflare работает поверх обычного интернета: серверы и дата-центры падают, очереди переполняются, кабели обрываются.
Для синхронизации данных в таких условиях используют алгоритмы консенсуса, они позволяют группе машин согласовывать одну и ту же последовательность значений (например, операций put/get в key-value хранилище), пока жива и может обмениваться сообщениями хотя бы половина участников. Проблема в том, что распространённые алгоритмы вроде Raft в глобальных сетях работают плохо: они полагаются на единственного лидера и таймауты. Писать может только лидер, и если он падает или деградирует по сети, система становится недоступна, пока не истечёт таймаут и не будет выбран новый лидер, а настроить корректные значения таймаутов в сети с непредсказуемыми задержками очень трудно. По словам Cloudflare, недоступность лидера в consensus-системах уже становилась причиной нескольких реальных инцидентов в компании.
В ответ команда Cloudflare Research последний год разрабатывала новый сервис распределённого консенсуса Meerkat, построенный на алгоритме QuePaxa, он опубликован в 2023 году исследователями EPFL. Ключевое отличие QuePaxa от Raft: писать могут все реплики в любой момент, и работа системы никогда не останавливается из-за таймаута, это хорошо подходит для сети Cloudflare. Поверх лога консенсуса Meerkat в компании уже строят транзакционное key-value хранилище и систему распределённой аренды ресурсов (leasing). По словам авторов поста, это первое промышленное развёртывание QuePaxa в глобальном масштабе. Пока Meerkat остаётся экспериментальным сервисом на ранней стадии разработки, рассчитанным на небольшие объёмы данных плоскости управления (например, информацию о лидерстве для реплицированных баз данных), и используется только внутри компании.
Cloudflare сформулировала для системы два требования. Во-первых, доступность: сервис должен принимать запросы на чтение и запись от клиента из любого дата-центра, пока жива и может обмениваться сообщениями большая часть машин (формально система из 2f+1 машин переживает отказ f из них), а клиент способен связаться хотя бы с одной машиной, подключённой к этому большинству. Это значит, что отказ одной машины или деградация одного канала связи не влияют на доступность всей системы, таким свойством Raft-системы не обладают. Во-вторых, корректность: пока в системе нет активно вредоносных участников (и багов), две актуальные реплики никогда не разойдутся во мнении о состоянии данных, например, одна не будет считать, что key1=1, пока другая считает, что key1=2. При этом, как и Raft-системы, Meerkat не защищён от византийских отказов (Byzantine faults), то есть от намеренно вредоносного поведения участников.
Технически кластер Meerkat, это набор реплик, каждая из которых связана со всеми остальными и может принимать и чтение, и запись; дата-центры для размещения реплик указывает разработчик, а Meerkat расставляет их автоматически. Клиент отправляет запрос (например, put или get для key-value хранилища) любой реплике кластера. Внутри каждая реплика превращает запрос в «событие» и с помощью алгоритма консенсуса рассылает его всем остальным репликам, так что все реплики ведут один и тот же лог событий слот за слотом, реплика может отставать, но никогда не зафиксирует для слота значение, отличное от остальных. Это обеспечивает линеаризуемость: если один клиент выполнил put k1 v1, затем другой, put k1 v11, а третий следом читает k1, он всегда получит v11, независимо от того, каким репликам, разбросанным по миру, были отправлены эти три запроса. В будущих постах серии Cloudflare обещает рассказать, в частности, о том, как key-value хранилище Meerkat обеспечивает ещё и сериализуемость (serializability).
Ключевые факты
- Сервисы Cloudflare читают и пишут общее состояние плоскости управления из более чем 330 дата-центров по всему миру и должны при этом оставаться и строго согласованными, и доступными при сбоях сети.
- Алгоритмы вроде Raft полагаются на единственного лидера и таймауты; недоступность лидера уже вызывала у Cloudflare реальные инциденты, а верно настроить таймаут в сети с непредсказуемыми задержками почти невозможно.
- Meerkat, новый сервис консенсуса, который команда Cloudflare Research строила последний год на алгоритме QuePaxa (опубликован в 2023 году исследователями EPFL); писать могут все реплики одновременно, лидера и таймаутов нет.
- По заявлению Cloudflare, это первое промышленное развёртывание QuePaxa в глобальном масштабе; формально система из 2f+1 машин переживает отказ f из них, оставаясь доступной для чтения и записи из любого дата-центра.
- Meerkat пока экспериментален и работает только внутри Cloudflare, на нём уже построены транзакционное key-value хранилище и система распределённой аренды ресурсов (leasing), а как и Raft, система не защищена от византийских (умышленно вредоносных) отказов.
Почему это важно
Инфраструктура Cloudflare охватывает более 330 дата-центров по всему миру, и множеству внутренних сервисов нужно согласованно читать и писать общее состояние плоскости управления (control-plane), то есть оставаться и строго согласованными, и доступными, даже когда часть сети отказывает. Стандартный инструмент для этого, алгоритмы консенсуса вроде Raft, но они полагаются на единственного лидера и таймауты: если лидер недоступен, запись останавливается до истечения таймаута и выбора нового лидера, а в сети с непредсказуемыми задержками правильно настроить таймауты почти невозможно. Cloudflare прямо говорит, что уже сталкивалась с инцидентами из-за недоступности лидера в consensus-системах. Meerkat, попытка закрыть эту системную проблему алгоритмом QuePaxa, где лидера нет: писать может любая реплика в любой момент, и прогресс никогда не блокируется таймаутом. Это, по заявлению Cloudflare, первое промышленное развёртывание QuePaxa в глобальном масштабе, то есть проверка академического алгоритма 2023 года боевой нагрузкой одной из крупнейших сетей интернета.
Кому это важно
В первую очередь, инженерам распределённых систем и командам эксплуатации (SRE/infrastructure), которые проектируют мультирегиональные сервисы и базы данных и на практике знают, как дорого обходятся протоколы с выбором лидера. Внутри Cloudflare это разработчики сервисов, которые будут строить свои приложения поверх Meerkat, уже сейчас на нём работают транзакционное key-value хранилище и система распределённой аренды ресурсов (leasing/локи). Тема также важна исследователям и практикам в области консенсус-алгоритмов (Paxos/Raft и их альтернативы), Meerkat интересен как редкий случай промышленного внедрения относительно свежей академической работы (QuePaxa, EPFL, 2023) в масштабе, который сложно воспроизвести в лабораторных условиях.
Как это применить
Meerkat пока не продукт и не open-source библиотека, это экспериментальный внутренний сервис Cloudflare, доступный только собственным командам компании и рассчитанный изначально на небольшие объёмы данных (например, информацию о лидерстве для реплицированных баз). Внешним разработчикам взять его «в работу» сейчас нельзя. Но модель использования, которую описывает Cloudflare, показательна для собственных инфраструктурных решений: разработчик запрашивает кластер реплик, указывает допустимые дата-центры размещения, а дальше система сама расставляет реплики и принимает запросы (например, get/put для key-value хранилища) от любой реплики кластера, гарантируя линеаризуемые чтения и записи. Это первый пост из серии, Cloudflare обещает отдельно разобрать, среди прочего, как Meerkat обеспечивает сериализуемость (serializability) для key-value хранилища, так что тем, кто следит за темой консенсуса, стоит ждать продолжения на блоге компании.
Можно ли доверять
Источник, официальный инженерный блог Cloudflare, а не пересказ через третьи руки, и авторы формально определяют, что именно система гарантирует: доступность при живом большинстве из 2f+1 машин и корректность (отсутствие расхождений между репликами) при отсутствии вредоносных участников. В основе лежит не изобретённый Cloudflare с нуля протокол, а рецензируемый алгоритм QuePaxa, опубликованный исследователями EPFL в 2023 году, это добавляет доверия к теоретической базе. В то же время сама компания называет Meerkat экспериментальным сервисом на ранней стадии: он используется только внутри Cloudflare, независимой внешней проверки заявленной надёжности в проде пока нет, а сам материал, это техническое введение и первая часть серии постов, а не аудит или бенчмарк. Часть технических деталей (например, разбор пограничного случая линеаризуемого чтения с отстающей репликой) в материале раскрыта не до конца, это скорее вступление в тему, чем исчерпывающая техническая спецификация.
Риски и подводные камни
Главное ограничение прямо признаётся в тексте: как и Raft-системы, Meerkat не защищён от византийских отказов (Byzantine faults), то есть от намеренно вредоносного или скомпрометированного участника кластера, а не только от честных сбоев вроде падения машины или обрыва сети. Сервис остаётся экспериментальным, применяется пока только внутри Cloudflare и только для сравнительно небольших объёмов данных плоскости управления, как решение поведёт себя под более тяжёлой промышленной нагрузкой или при расширении сценариев использования, пока не показано. Новый алгоритм консенсуса в проде, это всегда операционный риск: тонкие граничные случаи в протоколах согласования данных исторически оказывались источником сложных багов даже у зрелых систем, а Meerkat моложе и куда менее обкатан. Сроков открытия Meerkat для внешних пользователей или перевода в статус продукта в посте не названо.
«Мы сталкивались с несколькими инцидентами, вызванными недоступностью лидера в системах, построенных на консенсусе.»
— Cloudflare Research