Об архитектуре системы морского навигатора

Введение

Описание и анализ архитектуры проекта по морской навигации, в котором принимал участие Perfect Solutions, на конкретном примере позволяет разобрать ситуацию асинхронной передачи данных по спутниковой связи в несколько датацентров. Прозвучала следующая задача: необходимо сделать один девайс как для команды корабля, так и для владельцев судна. Если первым требуются рекомендации по прохождению маршрута в режиме реального времени, то вторых интересует информация о перемещении судов для принятия бизнес-решений. И естественно, информацию нужно собрать с судна, качественно передать, надежно хранить и предоставить клиентам.

По ощущениям, архитектура проекта простая, т.к. в ней только три компонента: источник данных (корабль), сеть передачи данных (спутник, сеть Интернет) и получатель (системы в ЦОДах). В море бывают зоны, где связи просто нет, поэтому передача данных асинхронная и отложенная (об организации передачи – отдельная статья). Вообще, вся зона связи здесь «серая», т.к., кроме всего, вероятен случай отказа оператора в предоставлении услуг спутника. Работа идет сразу с тремя ЦОДами, причем на разных континентах, во избежание ситуации, когда один из них просто не способен принять данные из-за какой-либо аварии у себя, геополитических трудностей или других причин. 

После этой поправки анализ архитектуры проекта дает понять, что главная проблема – обеспечение синхронизации между разными базами данных, территориально находящихся в датацентрах, а уже существующие варианты репликации данных не подходят. Этап получения данных требует тщательной проработки, без этого вся архитектура рассыплется, как карточный домик.

С чем работаем

Для надёжности пакеты данных с корабля отправляются в избыточном количестве. Защита базы от дупликации данных есть в алгоритме записи, о котором пойдет речь ниже.
Специальное приложение принимает данные и делает запись в базу. В пакете данных есть составной идентификатор, по которому определяется его уникальность, и он состоит из ID корабля, ID метрики (тип измерения, например, координаты), ID времени снятия метрики на корабле и последовательный ID для метрики (для каждой - своя последовательность). Этот идентификатор полностью пишется в базу.

Если приходит пакет с таким же идентификатором, то он просто отбрасывается приложением.

Трёхглавый монстр

В данном проекте идет непрерывная запись в три датацентра и возможна следующая ситуация: в одном ЦОДе записались пакеты A, B, C, в другом ЦОДе записался пакет A, потом произошла авария или сбой и B, C не записались. А в конечном итоге базы должны быть одинаковыми. Как дотянуть недостающие строки в фоновом режиме, продолжая вставлять новые, да еще и сделать эту систему между несколькими базами? 
Логическая и бинарная репликации не подходят по умолчанию, поскольку они используются при записи на один Primary-сервер и один или несколько Secondary-серверов для создания резерва. Master-master также не подходит, здесь проблема касается блокировки. Таблицы блокируются при изменениях строк. Процесс постановки и снятия блоков долгий, а с нарушениями связи практически бесконечный. Сначала нужно «закрыть» базы, потом провести изменения, затем отправить запрос «снять блок», ответить на него, пока это все произойдет, здесь даже читать долго.  Конкретно в нашей задаче устойчивый канал связи с широкой полосой между ЦОДами на разных континентах сделать невозможно. Вообще, это нормально, когда канал от Европы к Америке моргает и падает, только еды не просит.
Напрашивается вывод: существующие способы не подходят и нужен нестандартный механизм репликации данных. 

Как реализовано

Ниже представлена схема взаимодействия компонентов обмена данными между датацентрами

В результате появилась шина обмена данными между ЦОДами, которая состоит из следующих компонентов, причем они все есть в каждом датацентре: 
•    Приложение – принимает данные от спутника, записывает в БД, делает проверку предыдущего идентификатора и записывает в Очередь недостающие
•    Очередь – записывает недостающие строки
•    Requestor – «слушает» Очередь, берет из нее строки и отправляет запрос в брокер
•    Брокер – шина обмена данными между датацентрами, которая принимает запросы от Requestor, направляет запросы в Sender и другие брокеры за недостающими строками, получает ответ от Sender, записывает строки в Writer
•    Sender – получает запрос из своего брокера, проверяет свою БД, отвечает брокеру о наличии данных и отправляет нужные строки в брокер
•    Writer – принимает строки от своего брокера и записывает в свою БД.

Алгоритм работы приложения после записи строки в БД представлен ниже.

Если проверка показала, что в БД нет строки с предыдущим идентификатором, то приложение делает запись об этом в Очередь, и работа идет следующим образом: 

В результате новые строки вставляются, а недостающие подтягиваются тогда, когда это становится возможно. Такая система работает не моментально и базы отличаются в некоторые моменты времени, но они согласуются. Все достаточно просто и красиво, это даже подходит и под n-ое количество датацентров. 
Большой плюс – в распределении трафика.

При классических механизмах репликации трафик M между ЦОДами будет стабильно большим и для этого нужно обеспечить широкую бесперебойную полосу, чего невозможно обеспечить между континентами. В реализованном механизме в штатной ситуации трафик стремится к нулю и просто идет работа по предоставленному каналу.

Со стороны администраторов

Выбор технических средств для функционирования проекта был осуществлен после составления модели угроз и защиты от них. Лучше сделать так, чтобы именно техника по максимуму закрывала опасности, а человеческий фактор по возможности сократить, т.к. вредные действия могут быть выполнены по ошибке, незнанию или случайности. Кроме этого, надежда на человека при соблюдении мер информационной безопасности, даже при ограничении прав пользователям, накладывает на него такую ответственность, какую никто просто не согласится нести. Да и как человек гарантирует неизменность данных, если это не делает «железо»? 
В данном случае недаром на серверах была выбрана СУБД PostgreSQL. Это касается не только ее способности к масштабированию, многое как раз упирается в информационную безопасность. Postgres довольно легко модифицируется и таким образом есть возможность обезопасить данные от удаления и изменения на уровне самой базы. Неважно, специально или случайно, но эти действия могут привести к потере данных о маршрутах и кораблях. Соответственно, не будут приняты необходимые решения или просто бизнес не сможет развиваться. Есть вероятность, что при технической поддержке специалист примет решение удалить базу данных и развернуть ее заново, но ошибется и удалит не ту. Или там вообще нужны другие действия. Во многом из-за этого и необходимо ограничивать действия с базами. Update данных также вреден, опять-таки по ошибке специалисты техподдержки переименуют не ту базу и в ней произойдут ненужные изменения. Описывать триггеры для этих случаев нет смысла, т.к. есть возможность удалить или изменить сам триггер. Они написаны только затем, чтобы разработчики были в курсе происходящего и получали понятный текст ошибки при попытке update/delete.

Postgres довольно легко модифицируется и таким образом есть возможность обезопасить данные от удаления и изменения на уровне самой базы

Поэтому и пришлось модифицировать само хранилище и его систему управления, а Postgres отлично подходит для такого случая, и данные разрешено только вставлять и читать. Случай добавления «лишних» строк некритичен, ведь реальные все равно остались. В конце концов маршрут все равно будет показан верный, только с непонятными кусками и сразу ясно, что кто-то добавил несуществующие данные. С авариями на оборудовании точно так же. 
Другая потенциальная угроза, которую необходимо решить – в обновлениях могут быть прописаны неверные запросы и в результате информация о маршрутах и кораблях будет выдана не их владельцам или вообще не будет отображена. Для предотвращения такой ситуации для каждого клиента организована база исключительно для него, в которой собираются данные только с его кораблей.
Указанные выше случаи имеют прямое отношение к рискам, которые несут организаторы грузовых или пассажирских перевозок. Эти риски имеют отношение к самому продукту и его качеству. Сам морской навигатор необходим для бизнеса, но если он слабо отказоустойчивый, то им же никто не будет пользоваться. Другой важный момент – система передачи и хранения данных должна функционировать вне зависимости от геополитической обстановки. В каждой стране своё законодательство, своя политика и обстановка, которые, к тому же, могут меняться, причем неожиданно. Где-то ввели санкции, где-то приняли или отменили законы, а корабли-то все равно плавают и отправляют сведения и бизнес их ждет, нельзя же останавливать процесс. Вообще, без закрытия рисков в геополитике данный проект не то что недолго бы прожил, он не имел бы смысла. Ни один крупный бизнес не будет завязываться на одного подрядчика, т.к. авария или происшествие у него может повлечь за собой большие убытки у заказчика, и нужен страховочный вариант. Конкретно здесь, если размещаться только в России, то ни одна западная компания просто не пожелает пользоваться продуктом. Поэтому, для политической нейтральности, организованы три ЦОДа: в России, в Новосибирске (хорошее качество за небольшие деньги), в Европе, в Мюнхене (исторически место с хорошими сетями) и в Америке (малая цена размещения). Если в одном из этих мест случится какая-либо авария (пропала связь, пожар, революция и т.д.), то в двух других данные сохранятся и будут одинаковыми.

Без закрытия рисков в геополитике данный проект не то что недолго бы прожил, он не имел бы смысла

Также встает вопрос о связи и спутниках, причем он выходит за рамки простого обеспечения. Спутниковую связь обеспечивают космические агентства. Для бизнеса проект с такими организациями – это повод настроить системы под несколько наборов требований и научиться работать с этим, а сверх этого получить выходы на огромное количество операторов связи для получения каналов по оптимальным ценам.

Заключение

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