Скорость и надежность обработки данных: синхронная репликация в in-memory

Несмотря на сложную экономическую обстановку, крупные компании продолжают курс цифровизации бизнеса. Мобильные приложения и онлайн-кабинеты стали обязательным каналом коммуникации и обслуживания, что кратно увеличивает нагрузку на ИТ-инфраструктуру. Проблему производительности действующих систем можно решить несколькими путями, один из них — технологии in-memory. Но способны ли они гарантировать достаточный уровень надежности?

Около десяти лет назад для всех карточных операций банку было достаточно информационной системы с пропускной способностью 1000 запросов в секунду. Для сравнения, сегодня обработка только инвестиционных сделок банка из топ-10 — это более 5000 ежесекундных обращений. Традиционные базы данных, которые многие компании и банки используют в качестве основного хранилища, не справляются с потоком запросов от пользователей мобильных приложений. Чтобы избежать финансовых и репутационных убытков, ИТ-департаменты ищут способы ускорить существующие системы.

Для многих компаний решением стали in-memory-технологии. Этот подход подразумевает, что хранение и обработка данных происходит в оперативной памяти, а запись на диски ведется для большей надежности. Таким образом, удается достигнуть кратно лучшей пропускной способности и обработки в секунду сотен тысяч запросов против в лучшем случае 10-15 тысяч в традиционных базах данных. Но если вычисления в оперативной памяти настолько производительнее, почему мы не наблюдаем повального перехода с традиционных баз данных? Ответ связан с ресурсами — смена технологий требует денег и времени.

ИТ-ландшафт большинства крупных компаний формировался задолго до появления in-memory в современном представлении. Многие бизнес-процессы "завязаны" на устаревших системах. Перенос критических систем на другой стек технологий в данном случае неразрывно связан с большими финансовыми затратами. Порой дешевле создать новую компанию, чем мигрировать с устаревающей инфраструктуры. Каждая компания сама выбирает, создавать ли новую архитектуру с нуля или усовершенствовать то, что есть.

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

Зачем нужна репликация базы данных

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

Реплики можно делать на технологиях одного производителя или разных вендоров. Например, для Oracle часто используют GoldenGate с другими базами. Такое же решение можно собрать с использованием in-memory, и оно будет дешевле. Репликация между базами разных вендоров позволяет повысить надежность решения. Благодаря такому подходу можно не переписывать основную логику приложения, и все равно его ускорить.

Синхронная и асинхронная репликация

Репликация делится на два типа – асинхронная и синхронная. In-memory решения часто используют асинхронную репликацию, так как она не влияет на скорость ответа пользователю. Задержка между появлением изменений и их отображением в приложении составляет менее миллисекунды, что едва ли может быть заметно для человека. Ключевой показатель, который достигается с помощью асинхронной репликации — скорость восстановления базы данных (RTO).

С асинхронной репликацией транзакции отправляются на реплику независимо от ответа пользователю. Поэтому, если произойдет авария на сервере, данные могут быть потеряны в момент, когда пользователь получает ответ об успешной записи. Из-за этого асинхронная репликация не подходит для работы с критической информацией, например, финансовыми операциями или клиентскими заказами.

При синхронной репликации основная база данных сразу отправляет информацию о транзакции во все реплики, и считает операцию завершенной только когда получает от них подтверждение о выполнении. Таким образом, достигается минимальная целевая точка восстановления (RPO). На практике это означает, что данные во всех репликах будут абсолютно идентичны, и в случае аварии ни одна транзакция не будет утрачена.

Синхронный подход также имеет свои недостатки. Ожидание ответа от реплик вызывает задержку, которая кратна количеству подтверждений: если база данных ждет одну реплику, операция выполняется в два раза дольше, если две – в три и так далее.

Синхронная репликация в In-memory

Любая in-memory технология рассчитана на большую пропускную способность. А подход синхронной репликации, когда от реплик нужно получать подтверждение по сети влечет рост latency - задержки отклика - примерно в два раза. То есть по логике вещей синхронная репликация привносит latency в угоду надежности. Может поэтому не так много вендоров реализуют ее в своих продуктах.

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

В асинхронной репликации запросы завершаются сразу, поэтому у них очень небольшие требования. А когда мы изолируем запросы друг от друга в синхронной репликации, на каждый из них нужно тратить вычислительные ресурсы и место в памяти. Для тысячи в секунду использовать эти ресурсы - не проблема. Но когда количество запросов начинает увеличиваться до десятков тысяч, эти небольшие расходы заметно нагружают память и требуют больших затрат. Поэтому синхронная репликация для in-memory это особая работа, которую мы в Tarantool проделали.

В поисках баланса

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

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

Несмотря на то, что синхронная репликация позволяет повысить надежность in-memory до уровня традиционных баз данных, среди подобных решений такой подход встречается достаточно редко.