Цикл историй успеха Kubernetes продолжается рассказом о британском банке-стартапе Monzo. Эту молодую компанию относят к категории «challenger banks» (да, это уже термин из Oxford Dictionary), т.е. таких небольших банков, которые бросают вызов крупной и давно сложившейся финансовой индустрии. Это становится возможным благодаря активному и повсеместному использованию современных информационных технологий в самой своей основе, т.е. отказу от операций в традиционном формате в пользу электронных аналогов, позволяющих качественно снизить расходы (банки с таким подходом ещё называют «digital-only»). Пример Monzo, созданного всего 2 года назад, интересен тем, что в достижении великих целей ему помогают платформа Kubernetes, язык Go и другие современные Open Source-продукты, хорошо знакомые DevOps-инженерам и не только.

Что за Monzo?

Компанию Monzo, изначально известную как Mondo, в 2015 году основала команда выходцев из другого challenger-банка — Starling Bank, созданного годом ранее, — во главе с успешным уже тогда предпринимателем Томом Бломфилдом (Tom Blomfield), которому на тот момент было 29 лет. Позиционируя Monzo как «банк для тех, кто ненавидит [традиционные] банки», основателям удалось очень быстро найти свою аудиторию: в начале 2016 года они проводят «самую быструю crowdfunding-кампанию в истории», собрав 1 миллион GPB за 96 секунд.



В августе того же года Monzo получил свою первую (ограниченную) лицензию для официальной деятельности в качестве банка, а в апреле 2017 года ограничения удалось снять, что сделало Monzo «полностью авторизованным банком» и позволило предлагать своим пользователям расчётные счета. За свой первый по-настоящему активный календарный год (2016-й) Monzo активировала 83700 карт и увеличила свой штат с 16 человек до 71.

Услуга компании для конечного пользователя — электронный банк, доступный как мобильное приложение для iOS и Android, которое в реальном времени получает push-уведомления обо всех платежах, совершаемых с помощью банковских карт Monzo. Оно же хранит историю транзакций с указанием гелокаций, где были совершены платежи, и автоматическим назначением категорий в зависимости от типа компании-получателя денег (эти данные улучшаются самими пользователями в соответствии с подходом crowd-sourced suggestions). (Более подробное описание функциональных возможностей приложения и банка остаётся за рамками этого материала.)

В августе 2016 года аналитики из IDC опубликовали отчёт, в котором заявили о своей уверенности в том, что Monzo сможет «предоставить все гарантии, предлагаемые любым [традиционным] банком, и эффективно конкурировать с крупными транснациональными банками в стране».

Инфраструктура и решения

Первые достаточно подробные сведения об архитектуре программного обеспечения в Monzo и инфраструктуре, обслуживающей его, стало известно благодаря докладу «Building a Bank with Kubernetes» от Oliver Beattie, возглавляющего инженеров компании (к тому времени, в команде backend engineering team работало 10 человек). Это выступление состоялось на Kubernetes London Meetup (октябрь'16), а затем — на KubeCon 2016 (ноябрь'16).

Взяв расширяемость как один из главных факторов для основного приложения банка, инженеры компании сразу выбрали микросервисную архитектуру, объясняя это тем, что не хотят получить одно большое «раздутое» приложение, которое невозможно изменять «не только сейчас, но и через 10, через 20 лет», а именно так происходит у «legacy-банков», как их называют в Monzo:

«ИТ-системы многих крупных банков не расширяются в том смысле, что делать изменения для них слишком дорого. Возьмите, например, возможность заморозить карточку в приложении по нажатию на кнопку. Друг из RBS (Royal Bank of Scotland, входит в «большую четвёрку» банков Великобритании — прим. перев.) сказал мне, что они много раз рассматривали эту возможность, однако слишком много времени ушло на то, чтобы выяснить, какие из 20 ИТ-систем потребуют изменений, а модификации для некоторых из них были заморожены на годы. В конечном счёте эта идея была отброшена как слишком дорогая».
— Jonas Huckestein, соучредитель и технический директор Monzo

На момент выступления Оливера у компании работало около 150 микросервисов в production (для контейнеров использовался Docker). Одной из проблем, с которой они столкнулись по пути к этому, стала эффективность работы приложения. Когда микросервисов мало, всех их достаточно было дублировать на каждой машине, но со временем (с ростом числа микросервисов) этот подход перестал работать. Тогда инженеры начали разбивать микросервисы на определённые группы (app, core и т.п.) для разнесения по разным хостам, но и такой вариант не стал эффективным: случалось так, что app не хватало вычислительных мощностей, а машины с core простаивали. На этом этапе к инженерам Monzo и пришёл Kubernetes, который позволил «просто иметь общий пул ресурсов», где запускается приложение и легко масштабируется по мере необходимости. Не менее интересным оказалось то, как это изменение отразилось на расходах на ИТ-инфраструктуру:



Красным цветом на этом графике отмечены расходы на прежнюю инфраструктуру, а белым — на управляемую Kubernetes. (В качестве железа для инфраструктуры в Monzo используют облако AWS.)

Следующая проблема — гибкость сложной системы, состоящей из множества взаимосвязанных микросервисов. Сначала её частично решало использование очередей на базе RabbitMQ, но такой подход не был ориентирован на Kubernetes, да и количество предъявляемых здесь требований сильно росло:



Общая суть этих требований сводилась к минимальным задержкам ответов на пользовательские запросы и максимальному успеху в шансе дать ответ. Для достижения поставленных целей были выбраны linkerd (об этом проекте и service mesh как классе ПО мы писали в здесь) и Finagle.

На каждом хосте, где запускались микросервисы, устанавливался локальный экземпляр linkerd, к которому обращались локальные микросервисы со своими запросами, а он уже связывался с остальными linkerd для принятия решения о том, куда этот запрос отправить.


Иллюстрация использования linkerd при появлении GET-запроса на HTTP-сервер Unicorn

Для обеспечения сетевой изоляции различных зон своей инфраструктуры в Monzo взяли Calico и сетевые политики Kubernetes. Например, зона «super-secure» может использоваться для хранения полных номеров банковских карт (передавать эту информацию «в чистом виде» для большинства сервисов не требуется, поэтому они могут находиться в других зонах).

На следующей конференции KubeCon, уже европейской и проходившей в марте 2017 года, тот же Оливер из Monzo снова выступил с более коротким рассказом об использовании Kubernetes в инфраструктуре компании, сообщив, что к тому моменту количество микросервисов в production выросло до 200. И почти все они относились к категории stateless: из stateful была упомянута только Apache Kafka с примечанием, что «мы начали активнее перемещать туда и технологии, связанные с базами данных». Его выступление, озаглавленное как «Обработка реальных денег в Monzo с Kubernetes и Linkerd», продолжил тёзка из Buoyant (Oliver Gould), часть доклада которого была больше нацелена на общее знакомство с linkerd (вместо какой-либо специфики с Monzo).

И последние факты об инфраструктуре Monzo удалось найти в докладе «Securing your Infrastructure with CoreOS» (31 мая на CoreOS Fest 2017):

• количество микросервисов в Monzo выросло до 230;
• для хранения всех данных используется СУБД Apache Cassandra;
• для хранения секретов используется Vault (с бэкендом Cassandra), но ещё не все данные были туда перенесены;
• для связи с платёжными системами (а точнее — между AWS и co-location, который непосредственно связывается с этими системами) используется VPN на базе WireGuard, который «превосходно подходит для контейнерной инфраструктуры».

Крупный инцидент 27 октября

Ложку дёгтя в эту историю успеха добавляет событие, случившееся совсем недавно — в конце прошлого месяца. Если вкратце, то production у Monzo не работал корректно на протяжении примерно 80 минут из-за известного бага в Kubernetes и стечения обстоятельств.

Уважение вызывает тот факт, что на форуме сообщества Monzo всё тот же Оливер опубликовал весьма детальный post-mortem о произошедшем с пояснениями даже для тех, кто впервые слышит про Kubernetes. Суть возникшей проблемы сводилась к тому, что за 2 недели до инцидента инженеры Monzo вносили изменения в кластер etcd, увеличив число узлов с 3 до 9 и заодно обновив версию etcd, и проверили его работоспособность… Однако в один прекрасный день очередной выкат обновлённого сервиса вызвал странные проблемы в работе системы, которые не решились откатом к работающей версии.

Помимо определённой последовательности событий в работе с инфраструктурой, свою роль в этом инциденте сыграли баг #47131 в Kubernetes, проявляющий себя на определённых версиях etcd (всё ещё не закрыт), и баг #1219 в linkerd (закрыт ещё в апреле с релизом linkerd 1.0). Оперативная работа инженеров компании и имеющиеся процессы/механизмы на случай аварий свели проблему к минимуму, однако полный простой банковской платформы на 20 минут (и значительные проблемы более часа) — это, конечно, недопустимая ошибка даже для такого «молодёжного» стартапа. Впрочем, реакция сообщества на этот инженерный пост приятно удивила позитивным настроем аудитории Monzo, которая поприветствовала открытость и честность компании после случившегося.

Свои разработки

В аккаунте Monzo на GitHub можно найти десятки репозиториев, некоторые из которых — собственные разработки на языке Go. В частности:

• typhon — RPC-фреймворк для взаимодействия между микросервисами;
• slog — библиотека для получения логов в структурированном виде (с учётом контекста и произвольных пар ключ-значение для каждого события) и отправки их в seelog;
• phosphor — распределённая система трассировки, похожая на Dapper от Google и Zipkin от Twitter;
• terrors — пакет для обёртывания ошибок Golang с дополнительной информацией.

Подробнее о том, как разрабатывают на Go в Monzo, можно узнать из доклада «Building a Bank with Go», озвученного в марте этого года инженером Monzo по распределённым системам (Matt Heath).

Резюмируя

По состоянию на 30 октября, количество пользователей Monzo составляло 469 тысяч, а последний раунд инвестиций, завершившийся в ноябре, принёс компании 71 миллион GBP, и всё это свидетельствует о больших перспективах проекта.

В целом же, Monzo и Kubernetes объединяет не только схожий возраст, но и ценность, которую они несут миру, делая доступным уже сегодня то, о чём многие мечтали и что является логичным развитием своей отрасли. Октябрьский инцидент, безусловно, не красит репутацию любого банка, однако из последовавшей на него реакции можно сделать вывод, что в данном случае он скорее принесёт новый полезный опыт весьма талантливой команде инженеров, чем приведёт к краху доверия.

Другие статьи из цикла

• «Истории успеха Kubernetes в production. Часть 1: 4200 подов и TessMaster у eBay».
• «Истории успеха Kubernetes в production. Часть 2: Concur и SAP».
• «Истории успеха Kubernetes в production. Часть 3: GitHub».
• «Истории успеха Kubernetes в production. Часть 4: SoundCloud (авторы Prometheus)».