Назад | Перейти на главную страницу

Подходит ли один экземпляр RDS для нескольких географических местоположений?

Я хочу создать мультигеографическую инфраструктуру. По сути, мне нужно обслуживать веб-сайт для пользователей из США, ЕС и Австралии.

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

Насколько мне известно, есть несколько вариантов:

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

  2. Иметь полноценную среду на каждой территории (отдельные RDS и EC2, никак не связанные с другими). Примите тот факт, что пользователь не может обмениваться логинами / данными на разных территориях.

  3. Пусть на каждой территории EC2 работают с MySQL. Встраивайте что-нибудь в уровень приложения для обработки синхронизации между базами данных по мере записи.

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

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

№ 2 - ограничение, но возможность.

№ 3 полон потенциальных проблем с синхронизацией, не работающей должным образом.

№4 возможен, но потребует существенного рефакторинга прикладного уровня, что само по себе может привести к проблемам.

Какой здесь лучший подход? Мне не хватает вариантов? Является ли задержка между центрами обработки данных «приемлемой»?

Параметры

Вариант 2 нельзя сделать надежным для одного URL-адреса, так как он будет зависеть от геолокации. Геолокация не будет надежно выбирать один и тот же сервер для данного пользователя с течением времени. Для этого вам понадобятся разные URL-адреса для каждого региона.

Вы упустили несколько вариантов:

  1. Для записи используйте центральный экземпляр RDS с репликами чтения в каждом регионе.
  2. Используйте MySQL, встроенный в репликацию, а не функции AWS. Я не знаю, сможете ли вы сделать это с помощью RDS - я подозреваю, что вам придется запускать MySQL на EC2. Это похоже на №4, но не совсем то же самое.
  3. Иметь один экземпляр / кластер EC2 и экземпляр RDS. Ускорьте работу приложения с помощью системы распространения контента, например CloudFront.

Опционный анализ

Я всегда сначала выбирал самый простой вариант, которым в данном случае являются EC2 и RDS в одном месте, используя CDN для повышения производительности. Вы не сказали, почему вы думаете, что вам нужно несколько серверов приложений в разных регионах, поэтому я озадачен, почему вы сразу перешли к относительно сложным вариантам.

Если одно расположение не соответствует требованиям к производительности, вы можете рассмотреть возможность размещения серверов приложений в каждом регионе с одной базой данных RDS. Это может быть быстрее, это зависит от поведения вашего приложения. Вам нужно будет провести сравнительный анализ.

Только тогда я мог бы рассмотреть дополнительную сложность нескольких баз данных.

Читать реплики

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