Эй, люди с ошибкой сервера,
Представьте себе обычную компанию «Программное обеспечение как услуга», предлагающую услугу, работающую на AWS (эй, это мы). Здесь нет ничего сложного, стандартное веб-приложение делает свое дело, как обычно, и приложение для смартфона конечного пользователя. Поскольку клиенты из Европа, естественно, регион AWS eu-central-1 содержит все для нескольких арендаторов.
Теперь отделу продаж удается привлечь клиента из Австралия - Пока все хорошо, так как веб-приложение уже может работать с разными часовыми поясами, валютами и локалями. Но: Австралия так далеко, как вы можете добраться от Европы (по крайней мере, на Земле), и поэтому теперь требуется довольно много времени на поездку туда и обратно. На запрос мы видим примерно 300–400 мс дополнительно в каждом направлении. (EDIT: это неправильно, когда речь идет о RTT, как указано в рекомендациях, мы видим 2x400 мс = 800 мс дополнительно для первого HTTPS запрос).
Для упомянутого веб-приложения, которое используется заказчиком для целей управления, это вполне нормально.Визуализированный HTML появится чуть позже, но благодаря CDN (CloudFront) активы не будут проблемой.
Но затронуто приложение для смартфонов конечного пользователя, которое выполняет меньше, но больше запросов JSON. Там он чувствует себя на грани «нормального», но определенно не мгновенный.
Теперь вопрос: как улучшить тайминги с точки зрения конечного пользователя?
Здесь мы уже рассмотрели несколько вариантов:
Клонируйте полное программное обеспечение и также разместите его в AWS ap-southeast-2.
Преимущество: потрясающая производительность, простота настройки, CI/CD позволили бы развернуть один и тот же код одновременно в Европе и Австралии.
Недостатки: мы должны поддерживать и платить за два идентичных набора инфраструктуры, данные не могут быть легко разделены, много дублирования во всех терминах.
Переместите только вычислительные экземпляры в AWS ap-southeast-2.
Нет, не будет работать, так как запросы к базе данных или Redis будут еще больше зависеть от времени прохождения туда и обратно.
Иметь реплику только для чтения в AWS ap-southeast-2 и выполнять запись в eu-central-1.
Лучше, чем вариант 2, но добавляет много сложности в код, плюс количество операций записи обычно не так уж и мало.
Разверните балансировщик нагрузки в AWS ap-southeast-2 и подключите VPC через одноранговые соединения.
Идея: пользователи подключаются к конечной точке AU, а трафик идет через мощное соединение с инстансами EU. Однако мы, очевидно, не уменьшим расстояние, и мы не уверены в потенциальном улучшении (если оно есть?)
Кто-нибудь сталкивался с подобной проблемой и готов поделиться некоторыми мыслями?
Обновление: кажется, что только первый запрос HTTPS кажется очень медленным.
Изучая параметры AWS Load Balancer, я также заметил, что Глобальный акселератор AWS может помочь, поэтому мы провели несколько тестов.
Из локальной системы (в ЕС):
curl -w "dns_resolution: %{time_namelookup}, tcp_installed: %{time_connect}, ssl_handshake_done: %{time_appconnect}, TTFB: %{time_starttransfer}\n" -o /dev/null -s "https://saas.example .com/ping" "https://saas.example.com/ping"
dns_resolution: 0,019074, tcp_installed: 0,041330, ssl_handshake_done: 0,081763, TTFB: 0,103270
dns_resolution: 0,000071, tcp_installed: 0,000075, ssl_handshake_done: 0,000075, TTFB: 0,017285
Из AU (экземпляр EC2):
curl -w "dns_resolution: %{time_namelookup}, tcp_installed: %{time_connect}, ssl_handshake_done: %{time_appconnect}, TTFB: %{time_starttransfer}\n" -o /dev/null -s "https://saas.example .com/ping" "https://saas.example.com/ping"
dns_resolution: 0,004180, tcp_installed: 0,288959, ssl_handshake_done: 0,867298, TTFB: 1,161823
dns_resolution: 0,000030, tcp_installed: 0,000032, ssl_handshake_done: 0,000033, TTFB: 0,296621
От AU до AWS Global Accelerator (экземпляр EC2):
curl -w "dns_resolution: %{time_namelookup}, tcp_installed: %{time_connect}, ssl_handshake_done: %{time_appconnect}, TTFB: %{time_starttransfer}\n" -o /dev/null -s "https://saas-with -global-accelerator.example.com/ping" "https://saas-with-global-accelerator.example.com/ping"
dns_resolution: 0,004176, tcp_installed: 0,004913, ssl_handshake_done: 0,869347, TTFB: 1,163484
dns_resolution: 0,000025, tcp_installed: 0,000027, ssl_handshake_done: 0,000028, TTFB: 0,294524
В двух словах: кажется, что рукопожатие TLS вызывает наибольшую начальную задержку. Однако, если его можно использовать повторно, дополнительное время для AU в EU кажется действительно «всего» ~ 277 мс (0,294524 с - 0,017285 с) для времени до первого байта.
Привет!
