Мое приложение настроено в трех регионах (ЕС, Азиатско-Тихоокеанский регион, США), а главный сервер MySQL RDS находится в eu-west-1, а реплики чтения — в других регионах.
Это отлично работает для запросов на чтение, при этом региональное приложение очень быстро подключается к своей локальной реплике чтения RDS, но когда моему приложению необходимо выполнить запрос на запись, ему приходится подключаться к главной базе данных в eu-west-1.
При записи в главную базу данных из США или AP задержка огромная, обычно для завершения вставки требуется около 2,5 с.
Я действительно изо всех сил пытался найти какую-либо информацию о том, как преодолеть эту проблему. Aurora часто упоминается на форумах и в руководствах по глобальным базам данных, но для этого требуется репликация типа экземпляра, причем db.r5 является минимальным значением, что вскоре становится очень затратным при запуске нескольких экземпляров.
Кто-нибудь сталкивался с этой проблемой с медленной кросс-региональной записью в master DB? Поможет ли VPC peering ускорить это?
решение1
Это не полный ответ, скорее некоторые мысли, которые можно попробовать, и вопросы, которые не влезут в поле для комментариев. Пожалуйста, постарайтесь удержаться от желания поставить минус :)
VPC-пиринг определенно стоит попробовать, в этом случаетрафик остается на магистральной сети AWSчто должно немного сократить задержку. Не знаю, насколько это поможет. Эти три области находятся на расстоянии 200-300 мс друг от друга, так что у вас всегда будут некоторые задержки.
Я подозреваю, что разговор между клиентом и БД — это несколько запросов на одну вставку — например, создать соединение, подключиться к определенной БД, вставить, зафиксировать, закрыть. Если это так, то сокращение задержки помогает, но более важно исключить некоторые шаги. Используете ли вы пул соединений, чтобы соединения были уже открыты? Я подозреваю, что VPC Peering и общая оптимизация — это будет лучшим решением, чем любая из идей ниже.
Если есть способ сделать обновления асинхронными? Если вы можете поместить записи в очередь SQS, обрабатываемую в одном регионе, это, вероятно, будет сделано в течение секунды или двух. Это может быть оптимизацией по сравнению с прямыми соединениями с базой данных, в зависимости от того, насколько это быстро.
Другой вариант — Multi-master, использующий собственные функции репликации базы данных. Я не совсем уверен, можно ли это сделать в RDS, но, возможно, стоит взглянуть на это, а также на преимущества и недостатки. Если вы ожидаете, что люди будут обновлять одну и ту же запись одновременно, вам придется защититься от этого.
Другим вариантом может быть шардинг, с данными конкретных пользователей в конкретных базах данных. Однако это усложнит логику вашего приложения.