Понятные сервисы и паранойя о безопасности
Три года назад я ничего не знал о блокчейне, но за последнее время мир поменялся. Мы с партнерами одни из первых предложили Центробанку и банкирам использовать блокчейн в работе. Но предложение вызвало скепсис. А Следственный комитет и законодатели предлагали даже наказывать всех, кто занимается криптовалютой.
За последние несколько лет изменилось не только отношение к криптовалютам. Изменился и сам блокчейн, и вся наша экономика в целом. Через полтора года после нашего первого предложения Центробанку, мы получили совсем другой ответ — внедрять блокчейн в банковскую систему очень важно.
Блокчейн — это не только криптовалюты. В бизнесе и банкинге стоит задача — избежать потерь при обмене данных. Например, есть процессинг платежей и система, отслеживающая мошеннические действия. Их необходимо связать, но они разрабатываются разными командами. И им требуется обмен. Эту проблему может решить блокчейн.
В России очень мало компаний делают понятные заказчику сервисы, которые реально выживают после разрыва кабеля между дата-центрами. К решению проблемы безопасного обмена данных есть много подходов в информационной безопасности: формирование контуров, подписывание данных. Но хочется это упростить. И снизить паранойю, которая тормозит бизнес, особенно банковский. Службы безопасности постоянно боятся непредвиденных ситуаций и начинают усложнять систему и сервис.
В реальном бизнесе применить биткоин сложно
Распределенная система работает на то, чтобы данные сошлись. Когда мы меняем корпоративную базу, как правило, — Oracle, на систему с распределенными реестрами, мы меняем подход к архитектуре. У нас добавляется eventual consistency (согласованность в конечном итоге — «Хайтек»). Важно правильно соединить классический и новый подход к фиксации данных. Чтобы не получилось так: перевел деньги от А к Б, а после синхронизации систем окажется, что у А эти деньги списались, а к Б они еще идут.
Информационная безопасность и физическая безопасность в наших банках достаточно продвинутая. Потому что ЦБ отзывает лицензию, если организация устроена неправильно. В хороших банках контур защищен, а сервер находится под ключом. Поэтому идея форкнуть (скопировать процесс или код — «Хайтек») эфириум или какой-то любой популярный продукт на этом фоне проигрывает — нет гарантий, что получится поддерживать процесс по регламенту безопасности по мере обновления оригинального кода.
В реальном бизнесе сложно применить биткоин или эфириум. Бизнесу важно, только чтобы транзакция была надежно зафиксирована. Архитектура упрощается — отслеживаем простую цепочку, где каждая последующая запись имеет контрольную сумму, ссылку, на предыдущую. Главное, чтобы эти цепочки можно было легко и быстро проверить. Например, выгрузил антифрод из системы процессинга транзакций — и все.
Антифрод — ответственная часть системы, в которой анализируются аномалии данных. Чтобы правильно их анализировать, необходимо убедиться: что данные на входе чистые, что админ или программист процессинга — не мошенники и не происходит модификаций на каком-то отрезке транзакции. Следующий этап: обеспечить выполнение вердиктов антифрод-системы, то есть хранить файл с записями ее действий. В большой компании, где больше 20 продуктов и много продуктовых команд, наблюдать за всем сложно, но иначе деньги будут куда-то утекать. Поэтому хранение в неизменяемом хранилище — очевидный коммерческий бонус от блокчейн-платформы.
Единая база — это медленное восстановление после аварий. База данных, таблица с аккаунтами и SQL-запросы — существующие решения, они есть у всех банков. Некоторые обратились к блокчейну, потому что курс валюты подскочил, а обслуживать традиционные решения стало реально дорого. Поэтому нужно какое-то хранилище. Но когда все в одной точке, даже если это реплицированная база данных, будут проблемы — если упала одна из реплик, придется слишком много данных восстанавливать: например, 200 ГБ данных перекачать — крайне сложно, даже если это происходит на скорости в гигабит.
Для финансовой системы неприемлемо ожидание. Клиенты не будут ждать, пока приложение говорит: «Извините, сервис недоступен». Это обидно: хранишь свои деньги в системе, а тебе еще какие-то отказы в обслуживании поступают. Соответственно, это большие требования к времени загрузки.
Архитектура процессинга и большие данные
Наш паттерн: вместо демократии, как в биткоине, мы работаем в доверенном окружении. Транзакции проходят через сервисы, которые называются гейтами. У каждого гейта есть свой блок — чейн, а все транзакции следуют друг за другом. Для каждого счета — своя цепочка. То есть у нас нет единой цепочки, а гейты договариваются друг с другом.
Каждый узел работает по принципу «как я хочу, так и дайте мне». Изначально есть один общий диапазон счетов. Например — от нуля до бесконечности. Появляется первый узел. Он смотрит на текущую ситуацию и видит, что он единственный в этой сети. Узел берет полностью на себя весь диапазон. Появляется второй узел. Он запрашивает информацию у первого, изучает ее и говорит: «Я хочу половину». Если они договариваются, то все хорошо. Договориться можно, когда узлов более трех, чтобы был кворум.
Шардирование (горизонтальное разделение) — принцип проектирования базы данных, при котором логически независимые данные хранятся раздельно в секциях. А они, в свою очередь, размещаются на разных, физически и логически независимых серверах. Шардирование позволяет однозначно привязать клиента и все его данные к заранее известному экземпляру баз данных — шарду, обеспечив практически неограниченную от количества клиентов горизонтальную масштабируемость.
Основная проблема в шардированных системах (данные находятся внутри одной сетевой компоненты — «Хайтек») — появление «монстра» с большой нагрузкой. Сервисы делятся по шардам и каждый обрабатывает свой кусочек. Например, во «ВКонтакте» данные шардированы. Есть моя страничка с десятью постами, а есть страничка Павла Дурова, у которой безумное количество френдов, постов, комментариев. Сервисы, которые обрабатывают его и меня, имеют разную нагрузку. Решить такую задачу просто. Каждый гейт запрашивает «кусочек ответственности» и берет его, продлевая свои права периодически. Если не продлил — шард вернулся, и его может забрать любой другой. Поэтому добавление, удаление узлов происходит очень легко. Упал узел, или надо его обновить, вывели его — ввели. Если это сделали за секунду, то вообще никто ничего не заметит.
Иногда проще провести несколько оптических каналов, чем писать дорогую катастрофоустойчивую систему. В инфраструктуру тоже надо вкладываться. А программисты через некоторое время сами запутаются и не поймут — реально ли система катастрофоустойчивая, или они заблуждались.
Чейн на каждом гейте ограничен — копия чейна не хранится как у биткоина или смежных систем. Скачивать всю историю не требуется, достаточно подкачивать информацию по мере работы с ней. Например, вы делаете перевод, но данные по нему еще не пришли. Система в фоновом режиме подкачивает информацию и повторяет запрос, пока проблема не будет решена. Множество повторов — особенности таких систем. Но это не плохо, а нормально.
Надежное хранение и бесконечные базы данных
«Надежное хранилище» — место хранения всей оставшейся цепочки платформы. Такой подход используется где угодно, на любых языках и стеках технологий. Это важно. Мы не используем ни Memcached, ни Redis, потому что у нас ограниченная схема данных — только транзакция и настройка счета. При этом используется гибридный подход: с одной стороны, это распределенный реестр, с другой — надежное хранилище с транзакциями.
Memcached — ПО, реализующее сервис кэширования данных в оперативной памяти множества доступных серверов на основе хеш-таблицы.
Redis — сетевое журналируемое хранилище данных типа «ключ — значение» с открытым исходным кодом.
Достаточно надежное сохранение транзакций обеспечивается за счет хранения всех данных на каждом шарде в трех копиях. Гейты проводят транзакцию, считают баланс, и если он сошелся, перенаправляют и дублируют данные — у себя и в базе. Затем все переводится в транзакционную модель на шардах. У базы данные поделены, но уже по своей логике, независимо от гейтов. У каждого шарда есть свои реплики — в нескольких дата-центрах. Ничего не произойдет, если отключится один дата-центр. Реплики восстановят данные из двух копий.
Jepsen — фреймворк для тестирования баз данных, написанный Кайлом Кингсбери с никнеймом Aphyr. Jepsen запускает любую базу данных на пяти виртуальных машинах и начинает слать случайные запросы на каждую машину. В процессе отправки запросов на фиксацию и чтение данных, запускается сценарий — и Jepsen начинает случайно уничтожать эти машины. Гонять системное время. Замораживать процесс и размораживать его. Убивать эту машину, поднимать ее. «Полный дестрой», как в реальном мире. Кайл с помощью Jepsen разломал большинство баз данных и собрал большое количество багрепортов по ним.
При написании нашего хранилища мы задрали высокую планку: проходить тест Jepsen. И недавно это получилось. Наша база полностью проходит тест на всех трех уровнях: от шардов до всего кластера. Еще одна вещь, которую мы поняли при тестировании: параллельный доступ — это очень большая проблема. И мы ее решили. Поскольку мы добавляем только данные в наш чейн, у нас нет параллельного доступа и записи в один и тот же ключ.
Проблема реальных распределенных систем — часы. На разных участках системы происходит сбой часов, но необходимо определять, какое событие произошло раньше. Это важно в том случае, когда приходят запросы с разных концов на разные точки системы. Они не смогут через одну точку входить, иначе это будет единой точкой отказа.
Проблема транзакций со сбитым временем решаются обменом логических часов. Если время в транзакциях отличается, то мы просто синхронизируем часы и пробуем заново. Другой подход — попытаться часы изначально синхронизировать как можно точнее между собой. Например, Google это делает с помощью атомных часов в каждом дата-центре. Когда с двух точек приходят разные запросы с разными временами, мы смотрим на временные метки и просто ждем этот интервал времени. Если ничего больше не пришло, — значит, никакое новое событие не придет из прошлого или будущего.
Сайдчейн — система с блокчейном, без выхода в глобальные сети. Чтобы сделать этот подход надежным, периодически из любого сайдчейна выгружаются данные и считаются контрольные суммы от них, которые после фиксируются в смарт-контракте эфириума или биткоина.
Мастерчейн — система для проведения анкоринга: когда данные выгружаются из системы и фиксируются в неподконтрольном месте. Сегодня Центробанк с участниками рынка развивает легальную блокчейн-платформу общего назначения. Данные при нем уходят не в биткоин, а в Мастерчейн ЦБ. Именно Мастерчейн, скорее всего, будет иметь правовой статус платформы в России.
Распределенные системы, в первую очередь, используются в процессинге платежей. В нашей системе можно зафиксировать факт любого события. Сайдчейн используется просто как безразмерная база данных, но со своими ограничениями. Единой точки у нее нет, все договариваются и согласовываются распределенно.
Если в базу бесконечно записывать данные, — то через 20 лет это будут миллиарды транзакций в год. Память будет увеличиваться, и придется где-то хранить информацию. Поэтому в системе активно используется шардирование на небольшие кусочки. Если какой-то шард «пухнет», он просто делится на два других, как биологическая клетка. Будет просто больше шардов, не один дата-центр, а десять. Удорожания тоже не произойдет. Все данные лежат в компактном виде, их можно хранить на дешевых дисках. Это очевидное коммерческое преимущество такой базы.