AWS: настройка нескольких регионов с использованием одного экземпляра RDS


11

Я пытаюсь масштабировать наше веб-приложение (PHP, MySQL, memcache) в многорегиональной схеме. В настоящее время мы используем установку с двумя экземплярами EC2 позади ELB и экземпляром RDS, все они находятся в регионе США-ВОСТОК (Вирджиния).

Мы хотели бы также присутствовать в регионе ЕС (Ирландия). Это означает, по крайней мере, новый экземпляр EC2 (идентичный другим, обслуживающим то же приложение).

Я скопировал нужный AMI, настроил новый экземпляр, настроил ту же конфигурацию ELB (требуется для завершения SSL) и настроил маршрутизацию на основе задержки в Route53. И это работает как предложено.

Но у клиентов из ЕС есть проблемы со скоростью. Это связано с тем, что экземпляры EC2 ЕС подключаются к экземпляру RDS в США. Насколько я знаю, Amazon еще не включил многозонную репликацию RDS.

Есть ли у вас какие-либо предложения о том, как правильно ускорить всю настройку при использовании одного экземпляра RDS?

Кроме того, какие-либо идеи в целом о том, как масштабировать вещи? В идеале мы хотели бы продолжать использовать технологию RDS по разным причинам. Тем не менее, я открыт для предложений (я думаю, что следующей идеей будет размещение наших собственных серверов MySQL).

Ответы:


5

Вы должны тщательно продумать, почему вам нужны одинаковые данные как в США, так и в ЕС. Ведь это разные пользователи.

Работа в мультирегиональной среде намного сложнее и, как правило, снижает производительность из-за внутренней задержки между США и ЕС.

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

Самый простой способ - настроить выделенный RDS-сервер в ЕС и ничего не распределять между этими экземплярами.


Здравствуйте, парень, проблема в том, что клиенты из ЕС и США должны иметь доступ к одним и тем же данным. Есть ли обходной путь / идея?
Ион

Как часто эти данные обновляются (если не часто, вы можете легко скопировать их между регионами)?
Парень

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

4

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


1
Существует ли какой-либо (полу) автоматический способ репликации экземпляра RDS за определенный интервал? Есть идеи? Я полагаю, эта копия также будет доступна только для чтения, верно?
Ион

AWS по умолчанию поддерживает реплики для чтения, это правильно: aws.amazon.com/rds/faqs/#86 - я уверен, что можно выполнять репликацию для чтения / записи, но это выходит за рамки SF (я бы уточнил у наших Сайт DBA).
Натан, C

Да, но реплики для чтения создаются в том же регионе. Нам нужна реплика чтения в другом регионе, и в прошлый раз я проверял, что они не поддерживают это.
Ион


1

Я считаю, что это то, что вы хотите. Репликация RDS на EC2 с запущенным mysql в другом регионе.

https://aws.amazon.com/about-aws/whats-new/2013/09/05/amazon-rds-new-data-migration-capabilities-mysql/


Добро пожаловать в сбой сервера! Хотя это может теоретически ответить на вопрос, было бы предпочтительным включить сюда основные части ответа и предоставить ссылку для справки.
Slm

Спасибо, кажется интересным! Это более релевантная ссылка: docs.aws.amazon.com/AmazonRDS/latest/UserGuide/…
Ион

0

Одним из возможных решений для улучшения задержки может быть использование Amazon ElastiCache (который в основном Memcached находится под прикрытием).

Вам нужно будет создать узел ElastiCache в каждом регионе (US-EST и EU), и ваша логика приложения (EC2) будет использовать узел кэша всякий раз, когда это возможно. Если вы пойдете по этому пути, вам придется реструктурировать приложение: 1) знать, что и когда кэшировать, и 2) получить как можно больше данных с локального узла ElastiCache.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.