Что такое единая биометрическая система и зачем она нужна
Что такое единая биометрическая система (ЕБС). Объясняем простыми словами
Биометрия или биометрические данные — это физические характеристики или особенности поведения, по которым можно опознать конкретного человека. Существует пять самых распространённых типов биометрии: отпечаток пальца, трёхмерная фотография лица, запись голоса, снимок радужной оболочки глаза и рисунок вен на ладони.
Биометрические данные широко используются: большинство современных смартфонов можно разблокировать по отпечатку пальца или изображению лица. Эти же системы применяются для оплаты покупок через смартфон.
Особенность Единой биометрической системы — в её универсальности: она не привязана к учётной записи, например в Apple (Apple ID) или Samsung (Samsung account), как и к профилю клиента в конкретном банке. Передав в ЕБС один раз образец голоса и фото лица, можно три года получать услуги, которые требуют «юридически значимого подтверждения личности» в любых учреждениях, которые подключились к системе. По состоянию на ноябрь 2021 года можно с помощью профиля на «Госуслугах» и ЕБС обращаться удалённо в банки, чтобы открыть там счёт, вклад или запросить кредит.
Создание ЕБС инициировали Банк России и Минцифры. Разработчиком и оператором системы стала госкомпания «Ростелеком». Биометрическая система работает с июля 2018 года.
Пример употребления на «Секрете»
«За почти три года существования ЕБС в неё внесли всего 164 000 записей. В Минцифры хотят увеличить показатель до 70 млн — столько граждан сейчас зарегистрировано на портале госуслуг».
(Из новости о планах правительства активизировать затянувшийся сбор биометрических данных россиян.)
Ошибки в употреблении
Единую биометрическую систему не стоит путать с Единой системой идентификации и аутентификации (ЕСИА). Вторая используется при получении госуслуг: регистрация на портале «Госуслуги» — это и есть регистрация в ЕСИА.
Условно Единую систему идентификации можно назвать электронным паспортом, с помощью которого человек может записаться на приём к врачу, получить сертификат на маткапитал, зарегистрироваться по новому адресу, заказать различные справки и выписки, оплатить налоги и штрафы, выбрать дату вакцинации от коронавируса, получить электронный сертификат с QR-кодом и т. д.
Нюансы
Чтобы сдать биометрические данные для ЕБС, нужно прийти в отделение банка, подключённого к системе. Все крупные банки в ней уже есть, по состоянию на сентябрь 2021 года в списке находилось 216 кредитных организаций.
Согласие на обработку биометрических данных клиент даёт трём операторам: банку, в котором сдаёт биометрию, Минцифры России и «Ростелекому». Чтобы отказаться от использования сданной биометрии, нужно зайти на портал «Госуслуги» и деактивировать её в личном кабинете. Если человек снова захочет получать услуги по биометрии, ему придётся сходить в банк и заново сдать данные.
Критика
Противники Единой биометрической системы опасаются, что данные из неё можно будет похитить так же, как и из других систем, и использовать для мошенничества или преследования неугодных. Один из ярких критиков системы, президент компании InfoWatch и соосновательница «Лаборатории Касперского» Наталья Касперская, отмечала, что информацию, слитую из ЕБС и ЕСИА, могут использовать, например, «в крупных сделках с недвижимостью, при управлении счётом в банке, при проходе на закрытые объекты и тому подобном».
Единая биометрическая система — что это и зачем она нужна?
Чем дальше развиваются технологии, тем меньше приватности остается у персональных данных человека. За удобство и скорость современных технологий человек теперь должен платить не только деньгами, но и личными данными.
Ни для кого не новость, что во многих современных гаджетах присутствуют биометрические технологии. Так, разблокировать телефон может только его владелец, приложив палец к сканеру для отпечатков или же наведя камеру на свой глаз. Устройство распознает хозяина и разблокируется. Если это попытается сделать другой человек, то у него ничего не получится. Подделать отпечаток или сетчатку глаза практически не возможно.
Если с мобильными гаджетами у людей не возникает вопросов, то всех возмутил факт того, что было решено создать единую систему биометрических данных человека. В базе будут сохранены данные, что позволит любому госоргану или иному субъекту за отдельную плату получить эти сведения.
В связи с этим в России с 1 июля 2018г. запущена в действие единая биометрическая система (ЕБС). Сдав свои данные туда, человек может получить доступ ко многим финансовым или госуслугам без предоставления паспорта. Вместе со сведениями (данные паспорта, СНИЛС, телефонный номер, ИНН), которые хранятся на платформе Госуслуг, человек сможет открывать дистанционно счета в кредитных учреждениях, оформлять кредиты без паспорта, совершать иные денежно-финансовые транзакции.
Пока повально люди не спешат загружать свои данные в ЕБС. Для многих возникла проблема: получить удобный и комфортный доступ ко многим услугам или же сохранить свои данные приватными. Сейчас система находится в стадии тестирования. К ней постепенно подключаются банки и госорганы.
Что такое ЕБС?
Это цифровая платформа, которая была разработана корпорацией Ростелеком, Минсвязи РФ и ЦБ. Она позволяет проводить идентификацию человека по его голосу и лицу. Люди, которые сдали свои биометрические образцы, могут теоретически дистанционно получать различные финансовые услуги.
Пока же с этим есть проблемы, поскольку Ростелеком не может договориться с Google и Apple на размещение своего приложения в маркеты. Приложение защищено криптографией, а маркеты не желают размещать «черный ящик».
Не все банки пока готовы подключиться к ЕБС из-за расходов. Цена подключения банка к ЕБС начинается с 3 млн.р. за обеспечение киберзащиты и покупку оборудования. Последующее подключение каждого отделение обойдется еще в 130 т.р. Годовое обслуживание обойдется банку в 1,2 млн.р. Из четырех сотен российских банков пока согласие дали 50.
Как попасть в ЕБС?
Идентификация будет происходить по голосу и лицу. Регистрацией будут заниматься банки и госорганы. Для внесения данных в ЕБС нужно:
При обращении в дальнейшем за услугами, человеку достаточно включить камеру, озвучить сгенерированную фразу. Точность идентификации контролируется специальными алгоритмами ПО.
Хранение данных в ЕБС.
Данные будут подлежать хранению 3 года. Далее придется их обновлять. Разработчики установили нормы качества биометрического материала. Вместе с образцами в ЕБС будут передаваться данные о дате и времени создания материала. За совершенные ошибки при проверке контроля качества сведений ответственность возложат на сотрудника и организацию.
Пока же возникают вопросы по идентификации, если человек заболел, пропал голос, надорвал связки, сделал пластику лица и пр. В этом случае система его не распознает и удаленный доступ ко всем счетам и услугам будет закрыт. На эти вопросы пока нет ясных ответов. Разработчики заявляют, что они работают над этим и готовы принять все предложения и советы по улучшению системы ЕБС.
Требования к биометрическим сведениям.
Для биометрического материала есть свои требования. При их невыполнении пройти системы контроля будет невозможно.
Что касается лица, то требования таковы:
Требования по голосу:
Собирать данные планируется из разных источников, однако, пока решили остановиться на банках, поскольку здесь идет более жесткая идентификация. Далее пройти идентификацию можно будет в МФЦ, на почте и пр. Однако, здесь нужно обеспечить надежный контроль за сбором данных.
Можно ли передавать данные в ЕБС?
Вместе с этим эксперты предупреждают, что кража базы биометрических данных намного опаснее, чем кража паролей. Завладев такой информацией, мошенники получат полный контроль не только над счетами, но и над всей жизнью человека.
Что такое ЕБС и нужно ли начинать бояться биометрии в России
Насколько защищены биометрические данные и стоит ли переживать, что с помощью биометрии государство сможет контролировать каждого?
В 1983 году на экраны вышла очередная серия бондианы «Никогда не говори никогда». В этом фильме актёр Шон Коннери в роли агента 007 проникает в секретную комнату после прохождения биометрии: идентификации глаз, ладони и голоса.
Прошло 38 лет, и вход в офис по отпечатку пальца или перевод денег голосом уже не кажется такой фантастикой. Биоэквайринг работает в России с 2017 года, благодаря чему можно с помощью пальца оплатить покупки в магазине или рассчитаться ладошкой за школьный обед в столовой. Кроме того, к концу 2021 года в столичном метро должна появиться возможность оплаты проезда по лицу.
Обозреватель Skillbox Media. Пишет про бизнес, интернет-маркетинг и управление.
Что такое Единая биометрическая система?
Новый закон регламентирует объединение уже имеющихся и будущих биометрических данных в общую систему. С помощью ЕБС россияне могут взять кредит, открыть банковский счёт, снять наличные в банкомате или дистанционно подписать документы. За два года правительство рассчитывает увеличить число записей в ЕБС со 164 тысяч до 70 млн.
Чтобы сдать биометрические данные, нужно пойти в банк и завести учётную запись. Компьютер получит снимок лица человека и запомнит всё до мельчайших подробностей: форму носа, цвет глаз и другие параметры. При этом доступа к системе сами кредитные организации иметь не будут. Они смогут лишь узнавать о соответствии предоставленных данных шаблону, который хранится в ЕБС. Если процент соответствия окажется выше 99,99%, банк сможет предоставить услугу дистанционно.
Как рассказал Skillbox Media директор по цифровой идентичности ПАО «Ростелеком» Иван Беров, регуляторы предъявляют к ЕБС наиболее строгие правила. Биометрические данные передаются по защищённым каналам связи и хранятся в виде математически обработанных моделей.
«Восстановить фотографию или голос по модели просто невозможно. Кроме того, биометрические данные хранятся в обезличенной форме отдельно от персональных. Биометрия — в ЕБС, а персональные данные — на „Госуслугах“», — пояснил он.
Беров добавил, что, даже если злоумышленники выкрадут такие «слепки» у оператора, они не смогут увидеть фото или прослушать запись голоса.
По мнению директора технического департамента RTM Group Фёдора Музалевского, опасаться стоит не утечек биометрических данных, а обычных мошенников.
«Утечка образца голоса через ЕБС — не самое страшное. Обычные телефонные мошенники могут вывести вас на разговор и записать его, получив образец вашего голоса», — подчеркнул эксперт в разговоре со Skillbox Media.
Уже известны случаи, когда злоумышленники подделывали голоса, чтобы выманить деньги у своих жертв. Если в перспективе для подтверждения платёжной операции достаточно будет голосовой команды, то любые сведения о голосе гражданина могут стать материалом для фальсификации, считает Музалевский. Однако, как правило, банки используют двухфакторную аутентификацию — изображение лица и запись голоса.
Отпечаток пальца вместо банковской карты
Сканирование отпечатков пальцев в настоящее время чаще всего используется для аутентификации на смартфонах. Впервые таким сенсором оснастили телефон Pantech GI100 в 2004 году. Однако широкое распространение дактилоскопические сканеры получили только в 2013 году, когда Apple выпустила на рынок iPhone 5S.
Отпечаток пальца можно использовать не только в качестве ключа к защите информации, но и вместо банковской карты. Так, ещё в 2014 году Сбербанк опробовал в образовательных учреждениях Чувашии технологию безналичной оплаты питания с использованием отпечатков пальцев. Сейчас система, получившая название «Ладошки», запущена во многих российских школах.
Покупатели «Азбуки Вкуса» тоже могут расплатиться за покупки отпечатком пальца. Для этого необходимо зарегистрироваться на кассе магазина и привязать банковскую карту к своим биометрическим данным. После этого будет достаточно просто приложить палец к специальному терминалу — нужная сумма автоматически спишется со счёта клиента.
По словам руководителя направления анализа защищённости исходных кодов ПАО «Ростелеком» Вячеслава Герасименко, цифровой отпечаток пальца сам по себе нигде не хранится. Тот же дактилоскопический сканер для разблокировки смартфона просто генерирует математическую модель пальца и не требует для работы его снимок. Воспроизвести эти данные невозможно, отметил Герасименко в разговоре со Skillbox Media.
Однако надёжность такого метода аутентификации не раз подвергалась сомнению. Так, в 2014 году хакер Ян Крисслер, известный под псевдонимом Starbug, сумел подделать отпечаток пальца тогдашнего министра обороны Германии, а ныне главы Еврокомиссии, Урсулы фон дер Ляйен. Для этого Крисслер использовал программу Verifinger и несколько фотографий чиновницы, снятых обычным фотоаппаратом под разными углами.
Также Starbug демонстрировал способ обхода Apple Touch ID на iPhone 5S. Хакер взял отпечаток с поверхности экрана смартфона и распечатал его на кусочке латекса. Затем он намазал узор столярным клеем и покрыл графитом. С помощью этого «слепка» Крисслер смог разблокировать чужое устройство.
Как хакеры обманывают системы распознавания лиц
В 2020 году сеть московских кафе Prime запустила функцию оплаты счёта по лицу. Чтобы воспользоваться этой услугой, необходимо предварительно сдать биометрические данные в банке, который выпустил карту. Также оплату по лицу тестируют сети магазинов «Лента», «Перекрёсток» и «Пятёрочка».
Но иногда нейросети дают сбой. В 2020 году система распознавания лиц в столичном метро приняла москвича за преступника. В итоге его задержали — и не сняли с него все подозрения, пока не нашли реального подозреваемого.
В 2021 году двое похожих мужчин из Екатеринбурга случайно взломали Face ID на iPad. Даниил взял у своего друга Никиты планшет и хотел спросить пароль, но экран разблокировался сам. При этом они не приходятся друг другу родственниками, а лицо Даниила не было внесено в память устройства.
Это не единственный случай, когда Face ID не сумела защитить гаджет Apple от несанкционированной авторизации. В 2019 году на конференции Black Hat USA исследователи продемонстрировали способ обхода аутентификации, позволяющий получить доступ к iPhone жертвы за 120 секунд. Для этого потребовалось три вещи: очки, скотч и спящий владелец смартфона.
Исследователи обнаружили, что система биометрической аутентификации не извлекает полные 3D-данные из области вокруг глаз, если распознаёт, что владелец носит очки. Вместо этого Face ID ищет чёрную область с белой точкой посередине, которая является радужной оболочкой глаза.
Исследователи решили воспользоваться этим. Они взяли обычные очки, наклеили на линзы чёрный скотч, проделали в нём дырочку и надели аксессуар на спящего владельца смартфона. Этого оказалось достаточно, чтобы обмануть FaceID и получить доступ к смартфону.
Китайские хакеры пошли ещё дальше. Чтобы обойти государственную систему распознавания лиц, они использовали технологию deepfake, позволяющую «примерить» на себя чужую внешность. Злоумышленники подавали налоговые декларации за якобы трудоустроенные «мёртвые души» и присваивали себе деньги из фонда заработной платы. За три года они «заработали» более 76 млн долларов.
Борьба с дипфейками
Нейросети могут подделывать не только лица, но и голос. В 2016 году компания Adobe представила систему VoCo. Она позволяет редактировать запись речи, изменяя слова и целые фразы — как в текстовом редакторе. Приложение также может синтезировать любой голос путём анализа исходного аудиофайла. В основе системы лежат технологии рекуррентных и свёрточных нейронных сетей.
В 2019 году компания Тимура Бекмамбетова Screenlife Technologies и команда «Робот Вера» заявили о работе над проектом на основе искусственного интеллекта Vera Voice. Искусственный голос сможет озвучивать сериалы, игры, рекламу или даже отправлять поздравления с днём рождения с голосами знаменитостей.
Пока что для создания качественного дипфейка требуются немалые ресурсы, вычислительные мощности и время на тренировку моделей. Но тем не менее высококлассные подделки становятся всё более доступными благодаря решениям с открытым кодом. Распространение технологии вынуждает исследователей и власти искать способы противодействия новой угрозе.
Над технологиями распознавания дипфейков работают крупнейшие лаборатории Стэнфордского, Бингемтонского и Калифорнийского университетов, а также многие IT-гиганты, включая Facebook, Microsoft, Intel и Twitter. В 2019 году в Калифорнии приняли первый в истории закон по работе с дипфейками, который запрещает любую попытку манипуляции человеческим вниманием с помощью искусственного интеллекта.
Кроме того, в мае 2021 года МВД России объявило о запуске разработки решения для распознавания дипфейков. Система, получившая название «Зеркало», должна быть готова к ноябрю 2022 года. Однако эксперты скептически оценивают шансы правоохранителей на успех.
«На отечественные исследования в этой области выделено около 4 млн рублей, что ставит под сомнение создание действительно эффективного решения», — рассказала Skillbox Media Мария Чмир, глава стартапа Deepcake, специализирующегося на применении технологий замены лиц в рекламных роликах.
Переживать пока рано?
Директор технического департамента RTM Group Фёдор Музалевский считает, что сегодня не следует переживать из-за активного сбора биометрических данных и внедрения систем распознавания лиц. По словам специалиста, такие данные пока не предназначены для взаимодействия с произвольными камерами.
«Камеры ЕБС изначально созданы для идентификации граждан, в том числе для подтверждения финансовых операций. А вот камеры безопасности не позволяют достоверно и автоматизированно идентифицировать человека, поэтому на данный момент они не связаны с ЕБС», — пояснил Музалевский.
При этом он не исключил, что в отдельных случаях, например при раскрытии преступлений, данные из ЕБС могут сравниваться с данными камер наблюдения. Однако это не планируется делать систематически, так как сейчас точность идентификации оставляет желать лучшего.
Вместе с тем эксперт отметил, что любому государству удобнее управлять гражданами, если они находятся «на карандаше».
«ЕБС — один из способов учёта финансово активных граждан, что становится особенно актуальным в условиях санкций. Создание удобного механизма перевода безналичных денежных средств, очевидно, позволит усилить контроль за денежными потоками и сократить теневой сектор экономики», — резюмировал Музалевский в разговоре со Skillbox Media.
Как устроена Единая биометрическая система
Единая биометрическая система (ЕБС) с 2018 года используется для идентификации человека по его биометрическим характеристикам: голосу и лицу.
Чтобы получать услуги по биометрии, пользователю необходимо зарегистрироваться в системе в одном из 13,1 тысяч отделений банков. Там операционист сделает его фотографию, запишет голос и отправит эти данные в систему. А для того чтобы компании могли оказывать по биометрии различные услуги, им необходимо провести интеграцию с ЕБС.
Меня зовут Сергей Браун, я заместитель директора департамента цифровой идентичности в РТЛабс. Вместе с Артуром Душелюбовым, начальником отдела развития и разработки департамента цифровой идентичности, мы расскажем, как мы создавали платформу для любой биометрии, с какими проблемами встретились и как их решали.
Для тех, кто предпочитает видео – смотрите выступление на HighLoad++ Весна 2021, под катом ждет запись.
Выступление на HighLoad++ Весна 2021
Биометрия. Начало
Когда наше государство решило сделать биометрическую систему, первый вопрос, который возник у нас: «Хорошо, но как это организовать?». Мы не хотели изобретать велосипед и знали, что очень много коллег работают с самой разной биометрией. Поэтому сначала мы посмотрели, что есть на рынке. Оказалось, что существует много решений вендоров, а модные сегодня нейросети постоянно развиваются, обучаются и растут. Здорово!
Мы стали изучать существующие решения и выяснили, что у каждого вендора свои характеристики биопроцессоров. Один работает лучше, другой — хуже. Этот видит в темноте, а тот — нет, кто-то умеет распознавать голос. А нам нужен был однозначный результат. В итоге мы решили проверять вендоров по нескольким модальностям с несколькими сетями и работать с разными вендорами, чтобы брать от каждого лучшее.
С другой стороны, перед нами стояли вопросы безопасности. Когда к нам приходит человек, для платформы он находится в удаленном канале, мы его не видим. Нам неизвестно, что происходит с ним, где он, как он выглядит. Но нам надо понимать, что это действительно человек, а не фото или видеозапись, смонтированная злоумышленниками. И уметь отражать возможные атаки.
И, конечно, бизнес хотел знать, сколько будет ему стоить риск ошибки распознавания биометрии. Не говоря уже о том, что вся система должна работать отказоустойчиво, без потерь данных и не разъехаться под нагрузкой.
Итак, что в итоге у нас получилось.
Нейросети и попугаи
Нейросети работают загадочно. Если попросить вендоров сравнить две фотографии, то мы получим разные score. Один вендор скажет 42, другой — 78, а третий — 33. Почему так? И что это означает?
Чтобы понять их объяснения, нам пришлось собрать собственную базу образцов и на ней измерять самим:
Вероятность ложного допуска;
Вероятность ложного недопуска;
Вероятности ложного совпадения;
Вероятности ложного несовпадения;
Обобщенную вероятность ложного допуска;
Обобщенную вероятность ложного недопуска.
Мы открыли ГОСТ, написали много кода и посчитали реальные вероятности для каждого score каждого вендора.
Так мы закрыли первый шаг нашей схемы ЕБС:
Сравниваем биометрию
На следующем этапе мы создали отдельные процессы переиндексации данных и перерегистрации образцов во всех биометрических процессорах. Потому что вендоры постоянно что-то меняют в своих нейросетях. У каждого своя платформа, и не все извлекают шаблон по запросу. Плюс у всех различное API.
С API мы решили просто. Предложили вендорам реализовать стандартную и очень простую API, всего из пары методов. Это стало необходимым условием сотрудничества. Многие смогли это сделать.
Сейчас процесс выглядит примерно так. Для нас вендор — это black box, перед которым мы ставим nginx для балансировки. Если вендор медленный, то для распределения нагрузки мы ставим его 10-20 копий. Когда нам надо сравнить две фотографии, мы отправляем их вендору в разные API: «Вот два вектора, они похожи или нет?»
Что происходит, когда к нам приходит биометрия, например, фотография? Мы распознаем, что это она, а затем смотрим в конфиг, сколько у нас вендоров. Например, шесть. У каждого из них мы запрашиваем на фотографию вектор, он же шаблон. К сожалению, вендор отвечает не всегда, потому что не все из них извлекают данные. Но в итоге фотографию и все векторы (биометрические шаблоны), которые вендор смог из нее извлечь мы сохраняем к себе.
Сейчас, когда к нам приходит новый вендор, все наши актуальные фотографии сразу проходят через него. То же самое мы делаем и со звуком, и с чем угодно.
Так мы закрыли следующий квадрат схемы:
Как обезопасить себя и клиента?
На рынке много решений для проверки, что это живой человек, а не фотография или видео. Разница в том, что одни хорошо видят подделки на веб-камере, а другие — на фотографиях, снятых телефоном. Еще можно проверять не по фотографии, а по голосу. Третий вариант — взять видео и проверять и по голосу, и по лицу. Посмотреть, как человек открывает рот, правильные ли буквы говорит, хорошо ли их произносит, и вообще не монтаж ли это.
Мы решили комбинировать всё, чтобы наверняка удостовериться, что человек живой. Подход применяем такой же, как на предыдущем шаге. Считаем liveness обычным вендорским решением с единой API. Если интересно, на портале можно об этом прочитать подробнее.
Так мы закрыли очередной элемент нашей схемы ЕБС:
Транспорт и очередь
После того, как работа с вендорами наладилась, мы стали смотреть, что за биометрия к нам приезжает.
Например, мы хотим проверить человека, который открывает счет. Операция не самая простая, поэтому хочется надежно проверить, что это действительно он. Мы запрашиваем данные в виде видео, потому что это пока самый надежный liveness.
20Mb на транзакцию. По-хорошему, нам нужно транспортировать и фотографию, а качественная фотография легко может весить 1Mb. А еще некоторые вендоры возвращают нам на 30Kb звука мегабайтный вектор. Чтобы передвигать это всё по системе, мы выбрали отличное решение, о котором наверняка все знают.
Очереди c персистентностью + балансировка
Мы взяли Kafka, потому что она довольно простая и эффективная для решения задач с большим количеством мегабайтов. Создали очереди, поставили модули с двух сторон: один пишет, второй читает. С каждой стороны их, очевидно, может быть несколько:
Apache Kafka architecture
При всей своей простоте Kafka децентрализована. Это позволило нам малой кровью закрыть возможности масштабирования и вопросы балансировки. Стандартные механизмы балансировки Kafka позволяют читателям отваливаться, приходить и уходить.
С точки зрения надежности Kafka позволяет получить копии упавшего модуля и все данные с него. Даже если упала вся нода или весь сервер. Если потребитель не обработал сообщение, он для Kafka его не коммитит. Даже если модуль «умрет», то другая копия получит данные и выполнит задачу.
Очереди с репликацией
Поскольку Kafka живет в основном на дисках, то по факту это — журнал. Поэтому мы осознанно пошли на то, что, если данные отреплицировались, то мы ждем при записи с каждого из наших модулей ответ от всех имеющихся в кластере брокеров. И так как в этом случае нам быстрые и дорогие диски не нужны, мы взяли обычные. Репликация позволяет их легко менять если что-то выйдет из строя чисто механически или совсем невосстановимо по софту.
А так как Kafka поделена внутри себя на партиции, то, если одна выпадет, мы сможем прожить какое-то время на оставшихся. И одновременно за счет количества партиций мы увеличиваем потенциально возможное количество читателей.
Сравнение с RMQ
Вполне логичный вопрос — почему именно Kafka? А не, например, тот же RabbitMQ?
Первая и основная причина — это децентрализация. У RabbitMQ есть Central Store. Да, он имеет свои механизмы отказоустойчивости. Но он не предназначен для того, чтобы в него передавать ощутимый объем сообщений, при этом еще и разный, скачущий то вверх, то вниз. Не очень понятно, как он себя будет вести. Плюс у него довольно плотная связь с памятью.
У других решений такого же типа механизм чтения и общения с очередями построен так, что если потребитель забрал то, что отправили, это считается доставленным. В Kafka, в силу того, что она ближе к журналу, сообщение будет храниться вне зависимости от того, прочитал его потребитель или нет. Сообщение будет удалено только в момент срабатывания определенной политики очистки по месту или по времени.
Нам не очень хотелось устраивать сложную маршрутизацию и строить хитрые схемы. Проще записать один раз — кому надо, те придут и прочитают. Всю архитектуру системы мы построили в основном в режиме пайплайнов, то есть это прямой поток, когда от очереди не нужен роутинг.
Но в случаях, когда он нам все-таки нужен, Kafka тоже справилась.
Схема с Kafka streams для конвейеров обработки
Мы просто воспользовались встроенной логикой самой Kafka, ее удобным DSL с возможностью за счет механизмов кеш-журналов переобработать сообщение, если что-то пошло не так. Мы поставили один модуль с Kafka-стримами и сагрегировали то, что нужно:
Здесь логика такая. Если к нам на вход что-то пришло, мы разветвляем работу и собираем воедино, дожидаясь результата. Например, на схеме видно, что мы работаем параллельно с несколькими вендорами и с liveness. В этом режиме нам помогают именно стримы.
Так мы достроили еще один элемент нашей архитектуры:
Передавать научились – давайте сохраним!
Логика RegionServer’а
Когда мы посмотрели на данные, которые у нас ходят, то увидели, что они все неструктурированные и вообще непонятные. Для странного и непонятного мы нашли отличное решение — HBase поверх Hadoop.
В силу того, что HBase — это колумнарная база данных, выросшая из BigTable, в ней есть ряд особенностей того, как она хранится на дисках в самом «низу» схемы хранения. Так как там есть прямой стык с HDFS, то она может жить на распределенной FS (файловой системе).
В HBase также есть понятия RegionServer и Region, которые по факту — единицы хранения. И мало того, что они хранятся обособленными кусками, так каждый из них может распределяться на блоки HDFS. Далее эти блоки разделяются на файлы в обычной FS на диски на машинах. Что опять нас возвращает к тому, что есть много дешевых дисков. Почему бы не использовать их примерно для того же, что и в Kafka? И этот подход себя оправдал.
Логика сбора данных выглядит так. RegionServer отвечает за Region, он управляет одним или несколькими регионами. Дальше все это проваливается в HDFS. Здесь применяется фактор репликации, который вы настроили. Потерять что-нибудь очень трудно.
Посмотрим, как это стыкуется с тем, что мы говорили про передачу биометрии и прогон сообщений с биометрией по Kafka.
Распределение нагрузки на кластер
Здесь все довольно просто. У нас есть некие однотипные данные с точки зрения того, как они выглядят. Но они могут быть размером как 10Mb и больше, так и 1Kb. Логично разделить их по какому-то признаку, чтобы не перемешивать и равномерно сложить.
Для этого мы взяли таблицы HBase, так как там есть понятие column family. По факту это просто объединение данных, которое уже внизу разделяется на регионы. И при этом все хранится единым куском.
Мы разделили один column family — одна модальность. Это может быть либо отдельно звук, либо голос, либо еще что-нибудь. Но если мы поставим, например, размер региона 10Gb, то не будем умирать на постоянных compaction или на сложных перебалансировках таблиц.
Конечно, стандартная рекомендация HBase по настройкам — делать регионы поменьше. Потому что, когда в HBase что-то пишется, весь column family начинает схлопываться и собираться или, наоборот, разбиваться. Это одна из самых тяжёлых операций для HBase, которая использует память по количеству объектов. Но, так как у нас регионы хоть и достаточно крупные, но их немного, то мы можем себе это позволить. Плюс это равномерным слоем ляжет в FS, распределившись на диски и на машины.
Что в итоге получилось?
Схема хранения биометрии по CF + запросы
По логике получаемых данных мы их разделили на модальности: фото, звук, видео. Вендоры отдают нам шаблоны разного размера и объёма, с разными характеристиками. Мы их также поделили на column family и назначили каждому вендору свой.
Каким образом это все раскладывать так, чтобы не делать bottleneck, не пережать при перебалансировке? Здесь у нас подход довольно стандартный. В HBase все привязано к row key. Чем лучше вы определили, какие ключи будут использоваться в качестве ключей для строк, тем равномернее можно распределить данные.
Например, можно взять Round Robin, сделать пресплит таблицы, и начать «проворачивать» ключи (row key) так, чтобы они не шли непосредственно инкрементально друг за другом (+1). Обеспечить такое распределение можно просто меняя первый и последний байт ключа. Мы так и сделали. Начинаем отсчёт с нуля, дальше просто меняем байты и получаем цифры уже не от 0 до N, а инкремент по несколько другой логике.
Это позволяет наполнять довольно равномерно каждый из RegionServer, распределяя при этом нагрузку, в том числе и на запись, на разные машины, диски и ноды в самом кластере.
Дело в том, что HBase набивает каждый регион по кускам. Он просто назначает каждому региону диапазон id. Если вы будете инкрементально крутить id каким-нибудь автоинкриментом, вы положите всю запись в один RegionServer. HBase будет «греть» одни и те же диски, и в какой-то момент они рассплитятся. Для нас стало лучшим решением простая замена двух байтов местами в инкрементальном id.
А мы тем временем донесли данные и сложили на хранение:
Мультимодальность, мульти-liveness
Теперь надо поговорить о том, как это работает. У нас есть Kafka и модули, которые работают сами по себе:
Когда человек хочет пройти биометрическую верификацию, фронт запрашивает одноразовые инструкции персонально под этого человека, сгенерированные прямо сейчас. Он получает их из модуля инструкций (который, кстати, тоже пишет всю историю в тот же самый HBase) и отвечает наружу.
Человек выполняет инструкции, например, улыбается или приседает — всё, что мы его просим сделать. Потом присылает нам видео, и мы начинаем его разбирать. Вытаскиваем фотографию, отрезаем звук. Если проверок несколько, то определяем, какой liveness какую часть будет проверять. Все раздаем по исполнительным модулям. После этого получаем результат, собираем его и отдаем наружу. Вроде бы всё понятно. Но для нас возникает следующая проблема.
Модулей у нас много. И каждый должен быть запущен не в одном экземпляре, а нескольких. Если API не один, а хотя бы два, то запрос пришел на одну ноду, а ответ может получить другая. А нам надо ответить точно в тот же TCP-коннект. Что делать?
Мы нашли простое решение. У Redis есть хороший механизм PubSub, и мы отправляем ему все пакеты с id. Когда какая-то из нод получает ответ, она проверяет — это мой коннект или нет? Если это не ее коннект, она отдает данные в Redis. Та нода, которая изначально получила запрос, на эту информацию подписана. При изменении данных в Redis через механизм PubSub она всё получает и может отвечать наружу.
В качестве приятного бонуса мы решили с помощью Redis также оповещать модули. Мы просто подписываемся на нужный ключ в Redis. Когда произойдет ивент того, что админ что-то настроил, модулю не надо ничего перезапускать. Он получит этот ивент через Redis, заберет нужное обновление из реестра, и проапдейтится.
Вторым приятным бонусом для нас стал отказ от Zookeeper. С ним мы жили вполне успешно, пока модулей было не очень много и не было постоянного изменения сторонних настроек для модулей (например, настроек вендоров или модальностей). Балансировка была построена на том, что Zookeeper и Kafka всё между собой синхронизировали.
Но как только появились настройки, отличающиеся от технических настроек модулей, возникла проблема. Человеку, который видит Zookeeper второй и даже третий раз, довольно сложно посмотреть, что в нем хранится. Приходилось все время вспоминать, как работать с Zookeeper.
В итоге мы выпилили много кода взаимодействия с Zookeeper, синхронизации, подключения и уменьшили объём конфигов. Переехали в обычные плоские JSON-конфиги. Выкатили модуль в OpenShift, дали ему новый configmap, он при подъеме с контейнера получил JSON, и всё работает. Всем стало проще.
Мы пришли почти к финалу. Осталось поговорить про внешние API.
Внешнее взаимодействие
Мы не находимся внутри бункера. У нас есть еще потребители сервисов, и им надо как-то помочь. Если для наших сложных проверок просто написать им текстовые инструкции, то это не сработает. Поэтому мы сами реализовываем логику инструкций и проверки на стороне платформы.
У нас есть своя часть фронта, у клиента — своя. Например, для телефона это SDK. Но лучше сделать всё через наше приложение, которое само реализует эту сложную логику.
Преимущество в том, что мы полностью контролируем фронт. А значит, если нас ломают или нам надо срочно внедрить новые liveness или проверки, мы проводим эти работы сами. Не ждем, пока контрагент встроит в свое приложение нашу новую версию.
Протокол у нас общий и на веб-интерфейсе, и на мобильной версии — мы видим, кто пользуется сервисом. И в зависимости от того, какие сигналы пришли, например, от системы аномалий, мы можем сформировать инструкции для этой конкретной сессии, для конкретного человека.
Наружу мы отдаем всего пару простых интерфейсов. Тем самым мы закрываем проблемы с нормативами и сертификацией.
Итак, мы сложили полную схему ЕБС:
Остается сказать несколько слов об архитектуре.
Мы используем Docker, который прекрасно работает для биометрических вендоров, потому что они используют библиотеки, собрать которые самому невозможно. Для себя мы от всех вендоров запрашиваем докер-образ.
А дальше мы ставим кластер Hadoop, транспорт в Kafka, хранение в HBase. Hadoop — хорошая база данных, а все остальные модули размещаем в OpenShift.
Вот так сложилась архитектура Единой биометрической системы.
Видео нашего выступления можно посмотреть здесь.