Monzo построила резервный банк Stand-in на GCP на случай отказа AWS

Monzo, крупный британский необанк, описал в инженерном блоге архитектуру своей резервной инфраструктуры под названием Monzo Stand-in. Это полностью независимый набор систем в Google Cloud Platform (GCP), который может подхватить работу основной платформы Monzo, работающей в Amazon Web Services (AWS), при крупном сбое. Stand-in поддерживает только самые важные для клиента функции: оплату картой, снятие наличных, отправку и получение переводов, проверку баланса и операций, заморозку и разморозку карты. Когда Stand-in включён, приложение Monzo автоматически переключается на упрощённый интерфейс с этим ограниченным набором функций.

Почему не продублировать основную платформу целиком? Monzo объясняет: если бы обе платформы хранили строго согласованные данные, запись считалась бы успешной только тогда, когда прошла на обеих платформах сразу, и при недоступности любой из них компания вообще не смогла бы ничего записывать, то есть надёжность бы упала, а не выросла. Поэтому синхронизация между основной платформой и Stand-in сделана асинхронной и в конечном счёте согласованной (eventually consistent), а системы, которым такая задержка недопустима, например, бухгалтерская книга (ledger), в Stand-in вообще не переносятся.

Вторая причина раздельной архитектуры, снижение риска общего сбоя. Основная платформа и Stand-in используют разный код, включая независимую логику обработки карточных транзакций у каждой из них, чтобы ошибка в коде или процессах одной платформы не задела вторую. Monzo отмечает: облачные провайдеры вроде AWS, GCP и Azure в основном решили проблему отказов оборудования, но классические планы аварийного восстановления по-прежнему исходят именно из этого риска, тогда как не менее вероятная причина простоя, баг в собственном коде или процессах компании, от которого несколько дата-центров с одинаковым софтом не спасают.

Экономика решения: Stand-in обходится Monzo примерно в 1% от стоимости содержания основной платформы, и компания ожидает лишь небольшой рост расходов, если включит Stand-in во время реального инцидента. Для сравнения, полное дублирование всех сервисов и данных обеих платформ могло бы почти удвоить общие расходы на инфраструктуру.

Синхронизация устроена через события: каждое изменение в основной платформе публикуется в общую систему событий, и отдельный сервис Stand-in Data Syncer забирает из неё подмножество событий, чтобы обновить минимально необходимое состояние в Stand-in, баланс, ограниченную историю операций, данные карт и счетов, список копилок и получателей платежей. Все данные, синхронизированные в Stand-in, считаются неизменяемыми. Отдельно, по похожей, но чуть иной схеме, синхронизируются токенизированные данные вроде зашифрованных номеров карт, с обменом между двумя наборами ключей, обозначенными в документации как A и B.

Когда Stand-in включён и сам принимает решения, например одобряет платёж, эти решения не считаются окончательной записью системы: они складываются в отдельную устойчивую очередь в виде так называемых Monzo Advices, извещений, которые основная платформа обязана применить дословно, как только снова станет доступна (сразу или, при полном простое, позже). Поскольку Stand-in может работать с чуть устаревшим представлением баланса клиента, теоретически возможна ситуация, когда транзакция будет одобрена, а по данным основной платформы средств для неё не хватало, тогда клиент уйдёт в неавторизованный овердрафт; Monzo пишет, что на практике это происходит крайне редко благодаря дополнительным контролям. Чтобы одна и та же операция не задвоилась в обеих платформах, каждой транзакции присваивается общий идентификатор корреляции (Correlation ID).

Включение и отключение Stand-in сейчас, ручной процесс: инженеры Monzo используют собственный CLI-инструмент, чтобы включить нужные компоненты для нужных категорий клиентов при обнаружении критичного сбоя; в компании отмечают, что в перспективе процесс можно автоматизировать по тем же эвристикам, которыми инженеры пользуются вручную. Отключение Stand-in, тоже осознанное ручное решение: когда API основной платформы снова становится доступен, трафик не переключается обратно мгновенно, а возвращается постепенно.

Маршрутизация платежей устроена гибко: сначала трафик продолжает идти через основную платформу, которая проксирует его в Stand-in, это даёт Monzo точный контроль над тем, какая доля клиентов и даже какие именно клиенты переходят на Stand-in. Если основная платформа полностью недоступна, у Monzo есть более тяжёлый вариант, подключить Stand-in напрямую к платёжным сетям через собственные дата-центры, хотя в этом случае контроля над распределением трафика меньше. Оба маршрута, по словам Monzo, постоянно и регулярно тестируются в проде, чтобы быть уверенными в их работоспособности.

В августе 2024 года у Monzo произошёл крупный сбой платформы, затронувший большинство систем компании, включая обработку платежей и работу приложения Monzo. Сам сбой продлился около часа, но компания включила Stand-in почти сразу после обнаружения проблемы, это был первый случай, когда все компоненты Stand-in активировали сразу для всей клиентской базы (до этого систему только тестировали на небольших группах клиентов и частично применяли в других инцидентах). Благодаря этому клиенты продолжали проверять баланс, переводить деньги и платить картой, хотя приложение работало в упрощённом режиме.

Ключевые факты

• Monzo Stand-in, полностью отдельный набор систем на Google Cloud, независимый от основной платформы Monzo на AWS.
• Stand-in поддерживает только критичные функции: оплату картой, переводы, снятие наличных, проверку баланса, заморозку карты.
• Данные синхронизируются асинхронно через событийную систему и считаются eventually consistent; системы вроде бухгалтерской книги в Stand-in не переносятся.
• Содержание Stand-in обходится примерно в 1% от стоимости основной платформы; полное дублирование данных и сервисов могло бы почти удвоить расходы.
• Включение и отключение Stand-in, ручное решение инженеров через CLI-инструмент; трафик возвращается на основную платформу постепенно, а не мгновенно.

Почему это важно

Кейс показывает пересмотр подхода к аварийному восстановлению в банкинге: вместо классической схемы «несколько дата-центров с одним и тем же софтом», которая защищает только от отказа оборудования, Monzo строит вторую платформу с другим кодом на другом облачном провайдере, чтобы пережить в том числе баг в собственных сервисах или полный отказ конкретного облака. Для финтеха, где даже короткий простой означает, что клиенты не могут расплатиться картой, это конкретная, проверенная в проде архитектура, а не общие рассуждения об отказоустойчивости.

Кому это важно

Инженерам платёжных систем, необанков и финтех-компаний, которые проектируют аварийное восстановление; SRE-командам, выбирающим между полной репликацией данных и построением независимой резервной платформы; архитекторам, которые оценивают мультиоблачные стратегии не как маркетинговый лозунг, а как конкретный инженерный компромисс между стоимостью, согласованностью данных и надёжностью.

Как это применить

Из статьи Monzo можно вынести несколько конкретных приёмов: резервная платформа не обязана быть копией основной, ей достаточно минимального набора данных и функций для самых важных операций; вместо строгой согласованности между двумя платформами можно принять eventually consistent синхронизацию через событийную шину, оставив вне резерва системы, которые такой задержки не выдержат (у Monzo, бухгалтерская книга); операциям резервной платформы стоит присваивать общий идентификатор корреляции, чтобы не задваивать их при последующей сверке с основной; включать и отключать резерв, а также возвращать трафик, лучше управляемо и постепенно, а не одномоментно.

Можно ли доверять

Источник, официальный инженерный блог Monzo, лицензированного британского банка, то есть это первоисточник; независимой проверки приведённых цифр, например «1% от стоимости основной платформы», в тексте нет. Материал написан от коллективного лица инженерной команды, без указания конкретного автора. Про инцидент августа 2024 года источник даёт лишь краткое описание, час простоя и включение Stand-in почти сразу после обнаружения проблемы, без разбора причин сбоя.

Риски и подводные камни

Сама Monzo признаёт риск конструкции: поскольку Stand-in может работать с чуть устаревшим представлением баланса клиента, теоретически возможно одобрить платёж, для которого на основной платформе не хватало бы средств, клиент в этом случае уходит в неавторизованный овердрафт, хотя компания называет это крайне редкой ситуацией. Ручной процесс включения и отключения Stand-in означает, что скорость реакции на инцидент зависит от людей, а не только от автоматики, сама Monzo пишет, что автоматизацию только предстоит внедрить. Наконец, экономия «около 1%» касается фонового содержания системы и не гарантирует, что расходы не вырастут при реальном затяжном инциденте, компания говорит лишь о «небольшом» ожидаемом росте.

«Monzo Stand-in обходится нам примерно в 1% от стоимости нашей основной платформы, чтобы держать её работающей в фоновом режиме.»

— Monzo, инженерный блог