Firma uruchamia swoją podstawową logikę biznesową na flocie instancji Amazon EC2 w grupie Auto Scaling za Application Load Balancerem (ALB). Rekord Route 53 api.example.com wskazuje na ALB. Zespół deweloperski musi wdrożyć dużą aktualizację logiki biznesowej w taki sposób, aby podczas okna testowego tylko 10% klientów otrzymywało nową wersję, a każdy klient musiał konsekwentnie używać tej samej wersji przez cały czas trwania okna testowego. Jak firma powinna wdrożyć aktualizację, aby spełnić te wymagania?

Prawidłowa odpowiedź to utworzenie drugiej grupy docelowej na istniejącym ALB, wdrożenie nowej logiki biznesowej na instancjach EC2 zarejestrowanych w tej nowej grupie docelowej, a następnie zmodyfikowanie reguły słuchacza ALB, aby wykonywała routing ważony między grupami docelowymi z lepkością grupy docelowej. To rozwiązanie pozwala na kierowanie 10% ruchu do nowej wersji (routing ważony) i zapewnia, że klienci, którzy otrzymają nową wersję, będą konsekwentnie z niej korzystać (lepkość grupy docelowej). Pozostałe opcje są nieprawidłowe, ponieważ: Utworzenie drugiego ALB z routingiem ważonym w Route 53 nie gwarantuje spójności sesji dla klienta, który raz trafi na nową wersję. Aktualizacja konfiguracji uruchamiania grupy Auto Scaling z polityką AutoScalingRollingUpdate nie pozwala na kontrolowanie procentu ruchu ani na utrzymanie spójności sesji dla konkretnych klientów. Zmiana algorytmu routingu ALB na "najmniej zaległych żądań" (LOR) i włączenie lepkości sesji ALB nie pozwala na kierowanie określonego procentu ruchu do nowej wersji ani na kontrolowanie, którzy klienci otrzymają nową wersję.