15 вопросов
Практика
Ты мигрируешь старое двухуровневое клиент-серверное приложение на AWS. К приложению обращаются через определенный DNS домен, оно состоит из нескольких серверов приложений и сервера базы данных. Клиенты подключаются к серверам приложений по TCP, а серверам приложений нужно знать IP-адреса клиентов для нормальной работы — они их сейчас получают из TCP сокета. Ты планируешь использовать Multi-AZ RDS MySQL инстанс для базы данных. При миграции ты не хочешь менять код приложения. Как бы ты реализовал эту архитектуру на AWS, чтобы максимизировать масштабируемость и высокую доступность, но при этом сохранить видимость IP-адресов клиентов для серверов приложений?
Ты разрабатываешь мультиплатформенное веб-приложение, которое будет крутиться на AWS EC2 инстансах, и к нему будут подключаться с ПК, планшетов и смартфонов на Windows, macOS, iOS и Android. Приложению нужны отдельные конфигурации sticky sessions и управление SSL сертификатами для каждого типа платформы. Какой подход архитектуры даст самое экономное и производительное решение?
Какой смысл у функции "Connection draining", и как она управляет трафиком во время обновления инстансов или когда проверка здоровья падает?
Твоя система управления контентом, которая крутится на Amazon EC2 инстансе, почти на 100% грузит процессор. Какие шаги ты бы предпринял, чтобы снизить нагрузку на этот инстанс?
Какой сервис был бы самым подходящим для приложения, которому нужна как обработка изображений, так и общие вычисления, когда он работает вместе с Application Load Balancer?
После настройки Elastic Load Balancer (ELB), как ты можешь убедиться, что запросы пользователя постоянно направляются на один и тот же бэкенд-инстанс? Какая конкретно настройка включает это поведение?
У тебя компания развернула 10 m1.large Reserved Instances с высокой нагрузкой в двух availability zones, трафик идёт через Route 53 на Elastic Load Balancer. Через несколько месяцев роста ты купил два дополнительных c3.2xlarge Reserved Instances с средней нагрузкой и зарегистрировал их на том же ELB. Заметил, что m1.large инстансы работают на 100% мощности, а c3.2xlarge инстансы имеют кучу неиспользованной ёмкости. Какой подход будет наиболее экономичным и эффективнее всего использует твою EC2 ёмкость?
Одна стартап-компания развернула свой сайт для обмена фотографиями в VPC с Elastic Load Balancer'ом, распределяющим веб-трафик между двумя подсетями. Load Balancer настроен на использование сессионных cookies, сгенерированных AWS, для session stickiness с TTL сессии в 5 минут. Веб-серверы управляются группой Auto Scaling с минимальным и максимальным размером в 4 экземпляра. Компания готовится к публичному запуску, запуская программу load-testing установленную на одном экземпляре Amazon EC2, расположенном в зоне доступности us-west-2a. После 60 минут load-testing логи веб-серверов показывают следующее распределение HTTP-запросов: - Webserver #1 (подсеть в us-west-2a): 19,210 запросов от load-tester'а, 434 запроса от бета-пользователей - Webserver #2 (подсеть в us-west-2a): 21,790 запросов от load-tester'а, 490 запросов от бета-пользователей - Webserver #3 (подсеть в us-west-2b): 0 запросов от load-tester'а, 410 запросов от бета-пользователей - Webserver #4 (подсеть в us-west-2b): 0 запросов от load-tester'а, 428 запросов от бета-пользователей Какие рекомендации можно внедрить, чтобы HTTP-запросы load-testing распределялись равномерно между всеми четырьмя веб-серверами?
У тебя есть веб-приложение, которое работает на шести инстансах Amazon EC2, каждый использует примерно 45% своих ресурсов. Auto-scaling настроен так, чтобы всегда работало ровно шесть инстансов, потому что приложение обрабатывает одинаковое количество запросов без скачков трафика. Приложение критично для твоего бизнеса, и тебе нужна высокая доступность в любой момент. Ты хочешь убедиться, что нагрузка распределяется равномерно по всем инстансам и что все инстансы используют один и тот же Amazon Machine Image (AMI). Какие архитектурные решения тебе нужно принять?
В какую категорию облачных сервисов входят Load Balancer и DNS сервис?
Какой тип load balancer'а принимает решения о маршрутизации на транспортном уровне или уровне приложения и поддерживает и EC2, и VPC?
Какой эффект от включения sticky sessions на Elastic Load Balancer'е для инстанса, который обрабатывает запросы пользователя?
В чём главное отличие между классическим load balancer'ом и application load balancer'ом, особенно если речь идёт о маппинге портов и конфигурации listener'ов?
Что такое Elastic Load Balancing (ELB) и как он распределяет входящий трафик между несколькими целями, вроде EC2 инстансов, контейнеров или IP-адресов?
Какие типы load balancers доступны в Amazon EC2?