AWS RDS. Долгое время ответы RDS ( US регион) с EC2 Singapore. Как решить?

Question

[sailorpapay]

акая проблема. Есть MySQL RDS. В регионе US (орегон). Все EC2 находятся в нем. Сейчас появилась необходимость в EC2 в регионе Asia. Сингапур. Только время достукивания c Сингапура в US RDS - 5-7 сек. (Реад реплика не подходит, нужно чтение и запись)

Answer 1

[Иван Шумов]

Кажется у вас проблемы именно с архитектурой. Это удаленные регионы и, конечно, могут быть проблемы (хотя 5-7 секунд это, конечно перебор. Вы замеряли на что именно уходит это время)

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

Расскажите поподробнее какие решения у вас и для чего. В идеале с сетевой архитектурой (набросок из Lucidcharts или draw.io более чем подойдет)

Comments

[Иван Шумов]

Также вопрос, вы соединяетесь с базой через интернет или внутри сети AWS?

[hOtRush]

Просто интересно, чем тут поможет cdn или клудфронт, это же для статики? Может автору нужно что-то вроде мульти-мастер базы?

[Иван Шумов]

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

Но вообще я подозреваю что человек просто выкинул базу наружу из облака и пошли задержки. А надо было VPС Peering сделать

[hOtRush]

Иван Шумов, ну вот доставил клудфронт мой spa в сингапур за 10мс, надо почитать/записать базу кучу некэшируемых данных, он ускорит мой аякс запрос если латенси между базой/бэкендом и spa 5-7 секунд?

[Иван Шумов]

hOtRush, да, по тому что ec2 инстанс должен находиться в том же vpc что и rds. Таким образом проблема в обработке запросов уходит сама по себе (ее и не было у автора, пока он в другой регион не залез)

CDN ускоряет взаимодействие по http/rtmp протоколам между клиентом и сервером в ОБЕ стороны

[hOtRush]

Иван Шумов, хорошо, получается надо клудфронт связывать с балансером, при этом неважно в каком регионе ec2 инстанс, главное ec2 и rds в одном vpc и латенси будет минимальным?

[Иван Шумов]

hOtRush, ну, можно напортачить в настройках между любой парой сервисов, но, в целом, да, все так и есть

[Иван Шумов]

hOtRush, и надо не забывать что даже у AWS есть предел скорости передачи информации. CF Network очень крутая вещь, но если у вас сервер на земле, а клиент на луне то магии ждать не стоит)

[hOtRush]

Иван Шумов, ну и палец к носу, какая латенси будет между сингапуром и орегоном?

[Иван Шумов]

hOtRush, только что замерил: напрямую работа между регионами на 54% медленнее чем через CDN

[Иван Шумов]

hOtRush, забавно что мы тут с вами переписываемся, а автор вопроса еще не объявился)

[hOtRush]

Иван Шумов, да, забавно. Но вот еще вопрос, что быстрее, хттп запрос через cdn или запросы с сервера к базе если сделать новый инстанс в удаленном регионе (сингапур) с нужной vpc (то есть база в одном регионе, сервер в другом, сетевые запросы к базе с такой же задержкой по сути). Запросов может быть много что будет увеличивать общее время ответа, и получается что выгодней просто иметь бэкенд и базу в одном регионе чем дробить бэкенд по разным?

[Иван Шумов]

hOtRush, Все надо считать и проверять, но давай разделим на несколько частей задачу:
USER->CDN->EC2 (внутри AWS Network, low latency) это быстрее чем USER->EC2 (over Internet, high latency) из-за Edge Location Network
RDS Public access - не обрабатывается через CDN, а значит == USER->EC2(over Internet, high latency)
Private RDS via VPC Peering (внутри AWS Network, low latency)

Делаем выводы.

Бэкэнд в разных регионах нужен в первую очередь ради отказоустойчивости через Route53. VPC Peering все-равно нужен в таком случае, иначе боль и унижение. А CDN полезен вообще всегда. Он еще и дешевле прямых запросов, если память не изменяет

[sailorpapay]

Иван Шумов, СДН под мою задачу - не подходит.
Смотрю в сторону VPC Peering, но не получилось настроить.

вот по етому факу.
https://medium.com/tensult/vpc-peering-26346a4c0b9c

Region A (Ec2) VPC 1 (vpc ip 172.31).0.0/16
Region B (RDS) VPC 2 (vpc ip 172.30).0.0/16

1 - Peering Connections создал запрос с Region A . --> Region B
2 - принял запрос на Region B (RDS) (vpc ip 172.30).0.0/16
Имею пир pcx-04

3 - В регион Region A (EC2) , в Route Tables удаляю роут 0.0.0.0/0 в igw, создаю 172.30.0.0/16 в ИД пира.

В итоге отсутвие сети на Region B (EC2).
где ошибка?

Как обращаться к RDS не под ендпоинту (днс имени) а по внутреннему ип?

[Иван Шумов]

sailorpapay, в RDS нельзя обращаться по внутреннему IP - за нас это делает route53 (у сервисов вообще нет статических ip, ваш кэп). DNS resolve происходит разным образом. Я вам советую пройти курсы от ACloud Guru, например. Там очень хорошо рассказано. Сам я VPC Peering не настраивал, знаю только что он сделан именно для решения подобных проблем.

[Евгений]

Иван Шумов
Несмотря на то, что ваши советы правильные и хорошие в этом треде, реальность иногда выбивает из под нас табуретку.
Проводил исследование на предмет уменьшения времени ответа для одного сервиса. Сервис в us-east-1 а клиент в Австралии :D
Опробованы Global accelerator, CF, точка входа на GCE
чистый EIP из австралии - 1500ms
GA - 1800-2000ms
CDN(делал как чистый, так и через APIGW) - ~1200ms
Точка входа через google (тупой TCP прокси, так, попробовать, поднятый в европе) - 900ms
Как говорится делайте выводы =)

sailorpapay С пирингом: до определенного момента вы все делали правильно. Последовательность действий:
1. создать пиринг и принять его (здесь насколько я понимаю у вас все было правильно сделано)
2. настроить роутинг между сетями:
регион A:
добавить в route table той подсети где находится ec2 инстанс, маршрут на 172.30.0.0/16 (CIDR VPC региона Б) через идентификатор пиринга в VPC региона A (с регионом Б они разные!)
Регион Б:
(то же самое но напишу) добавить в route table тех подсетей где развернут RDS, маршрут на 172.31.0.0/16 (CIDR VPC региона A) через идентификатор пиринга в регионе Б(еще раз, они разные с регионом A)
3. Добавить в Security Group ec2 инстанса подсеть региона Б. Добавить в Security Group RDS инстансов подсеть региона A.
Удостовериться что доступ есть. Если нет - проверьте, может быть вы еще Network ACL накрутили, тогда и его надо проверять.
4. Только после этого можно попробовать убрать маршрут 0.0.0.0/0 через igw из таблицы маршрутизации подсети ec2 инстанса(если это действительно необходимо)

P.S. Что-то мне подсказывает что у вас маловато опыта в AWS. Пройдите курсы, как чуть выше написали, особенно по VPC и Networking.
На https://www.qwiklabs.com/home?locale=en есть еще тренинги где можно бесплатно потыркаться.
Два года назад cloud academy давал триал где можно было основы послушать
(с) Лучше день потерять чем потом за 5 минут долететь.

P.S. да, я даю не оптимальные советы, потому что можно еще роуты прописать только на CIDRы сабнетов.
Можно добавить доступ между security groups - чтобы сделать правильно и как рекомендует AWS. Но автор, как мне кажется, решает не проблему "идеально сделать" а "сделать чтобы работало.
Ах да, судя по сложностям которые вы описываете, вы все еще не создаете private VPC для работы базы. Если она у вас в Default VPC в аккаунте то вам ОЧЕНЬ нужно послушать и поучиться VPC и Networking в AWS.

[Иван Шумов]

yellowmew, очень хорошие замечания и дополнения, конечно) и заодно возьму на заметку как делается пиринг, хотя это все абсолютно, черт, возьми) Курсы по AWS много дают, конечно. Я сейчас закрыл все, кроме ML и IOT по нему: Solution Architect Associate, Developer Associate, Networking Speciality, Security Speciality, Event-Driven Security, Advanced CF, Complete Serverless, S3 masterclass, DDB Deep Dive .... Да много чего и все-равно приятно учиться новому. Еще бы почаще приходилось с этим работать.

А что касается реальности ... "гравитация, бессердечная ты c****" (с) TBBT Шелдон Купер. Любая идея может встретить проблему - главное принимать ошибки и стараться их решить. Какой там первый столп в Security? Правильно, Visibility

Answer 2

[Losted]

Про сеть уже сказали. Если ожидается большое количество cross-region взаимодействий то, возможно, есть смысл посмотреть на AWS Aurora MySQL с master-master

Comments

[Иван Шумов]

только если это Aurora, а у нее еще полно недостатков, хотя хороша, конечно. И У нее есть Global Database