Во время практики AWS я столкнулся со следующим вопросом, и у меня другое мнение, и я хочу опубликовать его здесь для дальнейшего обсуждения, так как он отвечает на очень распространенную потребность, спасибо.
У вашей компании есть штаб-квартира в Токио и филиалы по всему миру, и она использует программное обеспечение для логистики с мультирегиональным развертыванием на AWS в Японии, Европе и США. Программное обеспечение для логистики имеет трехуровневую архитектуру и в настоящее время использует MySQL 5.6 для сохранения данных. В каждом регионе развернута собственная база данных. В регионе штаб-квартиры вы запускаете ежечасный пакетный процесс чтения данных из каждого региона для расчета межрегиональных отчетов, которые отправляются по электронной почте во все офисы, этот пакетный процесс должен выполняться как можно быстрее, чтобы быстро оптимизировать логистику. Как вы строите архитектуру базы данных, чтобы соответствовать требованиям?
A. For each regional deployment, use RDS MySQL with a master in the region and a read replica in the HQ region
B. For each regional deployment, use MySQL on EC2 with a master in the region and send hourly EBS snapshots to the HQ region
C. For each regional deployment, use RDS MySQL with a master in the region and send hourly RDS snapshots to the HQ region
D. For each regional deployment, use MySQL on EC2 with a master in the region and use S3 to copy data files hourly to the HQ region
E. Use Direct Connect to connect all regional MySQL deployments to the HQ region and reduce network latency for the batch process
Я склоняюсь к E, причина в следующем:
- Direct Connect обеспечивает полосу пропускания, в обход интернет-провайдера и более частную и быструю (при необходимости).
- Здесь вопрос не в стоимости.
- Первоначальное время настройки может быть больше по сравнению с другими вариантами, однако стоимость времени начальной настройки не должна быть здесь сутью, здесь задается вопрос: «этот пакетный процесс должен быть завершен как можно быстрее, чтобы быстро оптимизировать логистику. < / strong> », поэтому речь идет не о первоначальной настройке, а о том, как реализовать правильное решение для предоставления услуги« как можно быстрее »ПОСЛЕ настройки.
И поэтому я считаю, что E - лучший вариант для этой цели.
Я открыт для обсуждения, пожалуйста, если я неправильно понимаю. Спасибо.
