Компания запускает основную бизнес-логику на парке инстансов Amazon EC2 в группе Auto Scaling за Application Load Balancer (ALB). Запись Route 53 api.example.com указывает на ALB. Команда разработки должна развернуть крупное обновление бизнес-логики таким образом, чтобы в течение тестового окна только 10% клиентов получали новую версию, и каждый клиент должен последовательно использовать одну и ту же версию в течение всего тестового окна. Как компания должна развернуть обновление, чтобы удовлетворить эти требования?

Правильный ответ — создание второй целевой группы и использование взвешенной маршрутизации с привязкой к целевой группе. Это позволяет направлять 10% трафика на новую версию (через новую целевую группу) и гарантирует, что каждый клиент будет последовательно использовать одну и ту же версию благодаря привязке к целевой группе. Первый неверный вариант (два ALB с взвешенной маршрутизацией Route 53) не обеспечивает привязку клиента к версии, так как Route 53 кэширует ответы DNS, и последующие запросы от одного клиента могут быть направлены на другой ALB. Третий неверный вариант (обновление конфигурации запуска ASG с MaxBatchSize) выполняет постепенное развертывание, но не позволяет контролировать процент трафика и не обеспечивает привязку клиента к версии. Четвертый неверный вариант (вторая ASG, LOR и привязка сессий ALB) не позволяет точно контролировать процент трафика (LOR распределяет трафик динамически) и привязка сессий ALB привязывает клиента к конкретному инстансу, а не к версии приложения, что может привести к переключению версий, если инстанс с новой версией недоступен.