Гео-распределеная БД/шардинг?

Question

[Макс]

Коллеги, хочется немного странного.
есть некий сервис аутентификации. Сейчас сервер исключительно в европе, есть желание утащить второй сервер в азию.
данные лежат в Postgre, но сие не догма. Пользователи, пришедшие в европейски сервер, вот так сразу на азиатский не придут, но потенциально могут.
что можно сделать "в лоб" - асинхронную репликацию. Вроде как не сложно и даже должно работать, но. В некоторой перспективе пользователей может быть МНОГО, но при этом мигрирующих между серверами доли процента. Синкать прям всех как-то не слишком эффективно.
Что хочется - некий извращенный шардинг(?). Т.е. европейских пользователей пишем в европейский сервер, азиатских в азиатский, но читать надо все (своих быстро, "чужих" - ну, как получится). Это вообще реально?

Comments

[boss_lexa]

для каких целей это нужно?

[Макс]

Для красоты?

[boss_lexa]

Макс,

красоты чего?

если например у вас https и цель уменьшить задержку для пользователей с других континентов, гораздо проще использовать точки присутствия (PoP) - которые будут близко к пользователю терминировать HTTPS и сразу иметь пул готовых соединений для проксирования на основным сервер.

[Макс]

Https то я терминирую, нет проблем. Но вот читать-писать в бд через Атлантику как-то неэффективно, кмк.

[boss_lexa]

Макс,

т.е у вас исполняемый код приложение и БД разделены Атлантикой? для чего?
Почему код приложения нельзя оставить только в Европе рядом с БД?

[Макс]

сорри за некропостинг.
у меня есть приложение, пользователи которого есть и в Европе и в Америке. Кажется логичным, что для уменьшения времени отклика приложение надо бы разместить и там и там, нет?

[d'Ivan]

Макс,
По запросу geographically distributed web applications в поиске есть немало интересных материалов.
Проектирование географически распределенного приложения

Answer 1

[Drno]

Поставить обратный прокси, и на основе IP адреса кидать на разные сервера?
Хз можно ли так с БД делать...

Answer 2

[ky0]

Что хочется - некий извращенный шардинг(?). Т.е. европейских пользователей пишем в европейский сервер, азиатских в азиатский, но читать надо все (своих быстро, "чужих" - ну, как получится). Это вообще реально?

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

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

Answer 3

[Владимир Коротенко]

У европейского сервера
своя база
у азиатского своя

Соответственно запросы у европейского
1. Европейская - быстрый ответ
2. Азиатская - медленный ответ и добавление в европейскую базу
3. Ничего - два запроса , но тут так получилось

У азиатского наоборот

Comments

[Макс]

все верно. вопрос - КАК

[Владимир Коротенко]

Макс,
Хороший пример, но сложноватый
https://habr.com/ru/post/321448/

Как простейший вариант этот балансировка на уровне dns Geo-DNS

https://ruhighload.com/dns+%D0%B1%D0%B0%D0%BB%D0%B...

[Владимир Коротенко]

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

[Макс]

Владимир Коротенко, вот эту мысль не понял. Приложение в Америке смотрит в свою базу, в Европе в свою. Пользователи на регионы в явном виде не делятся, US пользователь совершенно спокойно может приземлиться и на Европейский сервер (и если перелетит Атлантику, и если по какой-то причине наугрзка уйдет в Европу)

Answer 4

[boss_lexa]

между европой и азией RTT примерно 200 мс (Германия-Сингапур)
https прошлых версии требует = 3-4 RTT (600-800 мс) + DNS
если у вас настроено TLS v 1.3 + 0-RTT = 2-3 RTT (400-600) + DNS
подробнее тут https://blog.cloudflare.com/introducing-0-rtt/

Приложение и БД должны быть в одном датацентре (регионе) иначе каждый http-запрос будет отрабатываться как кол-во sql-запросов * RTT 200 мс = долго)

соотвественно если у вас трафик азии приземляется только на единственный сервер в европе пользователи из азии тратят больше на подключение, на 600-800 мс больше.

если вы купите слугу CDN для ускорения динамического сайта (или настроите свои сервера) и ваш https будет терминироваться в азии, а само приложение и бд останется все также в европе - оставшаяся задержка сократиться до 1 RTT = 200 мс,

также к этому прикручиваете быстрый anycast DNS, например Cloudflare (только DNS, без СDN) или AWS route 53 (он еще от ddos 3,4 уровня защищен)
тут статистика DNS сервисов по latency https://www.dnsperf.com/

если будете смотреть CDN выбирайте тут: https://www.cdnperf.com/
но услуга ускорение динамики есть не у всех

если хотите свое - можно использовать AWS Global Accelerator (в нем дают anycast ip) это даст:
- терминацию TCP близко к пользователя
- приоритетную сеть с меньшими задержками
- защиту от Ddos 3,4 уровня
- быстрое переключение на резервный датацентр/регион если основной упал
+ пару дешевых региональных EC2 под терминацию Https

как аналог еще смотрите Azure Front Door

Как уменьшить оставшиеся 200 мс:

1) Если использовать синхронную рекликацию между континентами, например как mysql galera/percona xtradb cluster - скорость чтения будут локальной, но кол-во транзакций записи в секунду будет очень медленным, тк упрется в RTT, а если оно 200 мс = 5 транзакций/секунда

2) Если делать шардинг пользователей по континентам, то будут возникать проблемы если у вас есть кроссшардовые операции или может быть решардинг (пользователь переезжает в другой континент).
Есть CockroachDB которые завляюят что у них это все это решается "из коробки" - на практике хз.

4) Если вам подходит eventual consistency и split brain на короткое время не сломает ваше приложение - можно попробовать БД, которые будут использовать Согласованность в конечном счёте используя асинхронную репликацию

Но так ли критично уменьшение этих оставшихся 200 мс?
Стоит ли использовать новые необкатанные БД в production с которыми нет опыта решение проблем ради оставшихся 200 мс?