AWS має кілька місць для зберігання та екземпляри EC2 з різними цінами. Як я міг визначити, яке місце найкраще підходить для певного регіону. Чи інтуїтивно зрозумілий (ближче до вашого регіону обслуговування - це найкраще) чи є проблеми з надійністю (зокрема, місце розташування AWS стикається з більшими відключеннями, ніж інші). Чи доступні дані для прийняття такого рішення?
Я розробляю додаток, орієнтований переважно на індійських клієнтів. Отже, я розглядаю Сінгапур чи Токіо як варіант.
Відповіді:
Розумні та інноваційні люди з TurnKey Linux нещодавно відкрили своє рішення для вирішення вашої проблеми, див. Регіональні центри обробки даних AWS на GitHub:
Цей проект використовується для створення індексів (та візуальної карти для довідки), що використовуються Центром TurnKey для пошуку найближчого центру обробки даних AWS для користувача. [наголос мій]
Алгоритм, що використовується, детальніше описаний у пошуку найближчого центру обробки даних за допомогою GeoIP та індексації , а також наступної публікації Пошук найближчого архіву пакета APT за допомогою GeoIP та індексації .
Хоча це трохи трюк, візуалізація дуже серйозна і підтверджує, відповідно. ілюструє причину на перший погляд дивного факту, про який Джош уже згадував , а саме те, що користувачі в Австралії в даний час, як правило, отримують кращу затримку через захід США (Північна Каліфорнія / США-захід-1), а не Азіатсько-Тихоокеанський регіон (Сінгапур / ap-південний схід) -1) регіон. ( Порада : перевірка Майбутніх кабелів у нижньому правому куті показує, що це, ймовірно, зміниться, що детальніше описано в кабельній карті Грега , яка вказує, що Австралія може переходити між обома локаціями AWS із затримкою в найближчі роки;)
Тим часом AWS надає корисну карту, що ілюструє їх Глобальну інфраструктуру для швидкої оцінки, а також відповідні деталі, такі як, наприклад, кількість зон доступності та кінцева точка API.
Що ще важливіше, AWS щойно оголосив про географічну підтримку DNS, про яку вже згадував Джахуфар. Див. Вступний пост Доступна багаторегіональна маршрутизація, заснована на затримках , яка тепер доступна для AWS , що робить доступною ту саму технологію маршрутизації на основі затримок, яка забезпечує Amazon CloudFront для користувачів Amazon EC2 , Еластичне балансування навантаження та багато іншого.
Отже, якщо ваше середовище вже складається з архітектури екземплярів автоматичного масштабування EC2, просто застосування цієї маршрутизації на основі затримок має вирішити вашу проблему автоматично.
Хоча варіант використання, очевидно, націлений на пропозиції, що породжують декілька областей AWS, складні функції навколо маршрутизації на основі затримок та зважених наборів записів Round Robin можуть також дозволити вам легше визначити потрібну інформацію і собі.
Спробуйте cloudping.info
Він буде виконувати пінг HTTP з вашого браузера до кожного регіону AWS.
Region Latency
US-East (Virginia) 28 ms
US-West (California) 100 ms
US-West (Oregon) 110 ms
Europe (Ireland) 100 ms
Europe (Frankfurt) 119 ms
Asia Pacific (Singapore) 269 ms
Asia Pacific (Sydney) 239 ms
Asia Pacific (Japan) 209 ms
South America (Brazil) 147 ms
ПРИМІТКА для адміністраторів SO : Я не пов’язаний з цією службою. Я знайшов його під час підготовки до сертифікації AWS.
Існує також веб-сайт для тестування швидкості: https://cloudharmony.com/speedtest, якщо ви легко хочете перевірити, який регіон вам найбільше підходить.
Ось інструмент консолі, який показує найближчу область aws:
Він написаний голангом і дуже простий у використанні:
➥ ./awsping --verbose 1
Code Region Latency
0 eu-central-1 Europe (Frankfurt) 36.97 ms
1 eu-west-1 Europe (Ireland) 63.18 ms
2 us-east-1 US-East (Virginia) 126.52 ms
3 ap-south-1 Asia Pacific (Mumbai) 156.98 ms
4 us-west-1 US-West (California) 192.92 ms
5 us-west-2 US-West (Oregon) 226.23 ms
6 sa-east-1 South America (São Paulo) 247.74 ms
7 ap-northeast-1 Asia Pacific (Tokyo) 312.22 ms
8 ap-northeast-2 Asia Pacific (Seoul) 329.54 ms
9 ap-southeast-2 Asia Pacific (Sydney) 337.84 ms
10 ap-southeast-1 Asia Pacific (Singapore) 395.73 ms
Регіони упорядковуються за латентністю.
Ви можете запустити його на будь-якому сервері та визначити найближчий для вас регіон.
Тестування затримки для різних регіонів очевидно доцільне! Я перебуваю в Австралії, і багато користувачів тут отримують кращі затримки до Заходу США, ніж до Сінгапуру - частково це зводиться до місцевих постачальників послуг Інтернету та міжнародного зв'язку. Тестувати, чи є у вас користувачі в регіоні, на який ви націлюєте, порівняно просто.
Надійність на стороні AWS (тобто не проблеми з мережею користувачів) в основному є наслідком розгортання в декількох зонах доступності. У регіонах США вибір більше, ніж в регіонах APAC, просто тому, що вони довше обслуговують ці ринки. Побічним ефектом цього є те, що функції розгортаються відносно пізно до Сінгапуру / Токіо - зазвичай нові функції розпочинаються на Сході США.
Оскільки ви вже маєте на увазі S3 та EC2 як сервіси, якими ви хотіли б користуватися, і вони обидва доступні у найближчих регіонах, оцініть, чи нові веб-служби від AWS негайно важливі - якщо ні, то шукайте щось (латентність) поруч.
Зараз Amazon пропонує можливість маршрутизації до центру обробки даних на основі найнижчої затримки кінцевого користувача. Це новий "Маршрутизація на основі затримок" Route53!
http://docs.amazonwebservices.com/Route53/latest/DeveloperGuide/CreatingLatencyRRSets.html
EDIT: Подивіться на відповідь Марка Цая. Так слід іти (Маршрут 53 не існував, коли я писав цей)
Це, ймовірно, належить до ServerFault, але тут йдеться:
Те, про що ви в основному просите, - це Geo DNS.
Зараз це безпосередньо не підтримується в AWS - хоча я бачив, як деякі розмови про це впроваджуються в деяких повідомленнях форуму AWS - швидше за все, в їх службі Route 53 .
До цього часу ви могли б розглянути сторонні рішення, такі як Zerigo, які нададуть вам можливість використання Geo DNS.
Або якщо ви хардкор, ви можете прокрутити свій власний, налаштувавши BIND з IP2Location
EDIT: Є публікація на ServerFault, яка розповідає про провайдерів Geo DNS
Що стосується вашого запитання щодо продуктивності та надійності AWS: Вам слід розглянути можливість обслуговування вашого сайту від найближчої AZ до вашого користувача - це цілком логічно з точки зору швидкості та відсутності всіх ваших екземплярів в одній AZ. Ви можете перевірити AWS Service Health Dashboard, щоб отримати загальне уявлення про те, наскільки надійні послуги Amazon у різних AZ. Зверніть увагу, що ці дані безпосередньо від Amazon - я ніде більше не бачив незалежної статистики.
http://blog.datapath.io/aws-network-latency-map обговорює комерційну пропозицію отримати цю інформацію. Він показує час затримки від вказаного вами місця до вказаної служби AWS на карті.
