Zespół DevOps wdraża aplikację ECS za ALB przy użyciu CodeDeploy z wdrożeniem blue/green all-at-once. Ostatnie wydanie spowodowało znaczny wzrost czasów odpowiedzi i wymagało wycofania. Zespół chce zastosować podejście do wdrożenia, które pozwoli im obserwować nową wersję przed przekierowaniem całego ruchu i szybko wycofać zmiany, jeśli czasy odpowiedzi wzrosną. Która kombinacja kroków spełnia te wymagania?

Zmiana konfiguracji wdrożenia CodeDeploy na CodeDeployDefault.ECSCanary10Percent5Minutes jest prawidłowa, ponieważ strategia canary (kanarkowa) kieruje mały procent ruchu (10%) do nowej wersji przez określony czas (5 minut), co pozwala na obserwację jej zachowania przed przekierowaniem całego ruchu. To spełnia wymaganie obserwacji nowej wersji i szybkiego wycofania. Utworzenie alarmu CloudWatch dla metryki ALB TargetResponseTime i powiązanie go z grupą wdrożeniową CodeDeploy jest również prawidłowe. Ten alarm monitoruje kluczową metrykę wydajności (czas odpowiedzi) i automatycznie wycofa wdrożenie, jeśli czasy odpowiedzi wzrosną, co bezpośrednio odpowiada na problem zespołu. CodeDeployDefault.ECSLinear10PercentEvery3Minutes jest mniej optymalne, ponieważ liniowe wdrożenie stopniowo zwiększa ruch, ale nie zapewnia natychmiastowej obserwacji małej próbki ruchu jak canary. Alarmy na UnHealthyHostCount lub TargetConnectionErrorCount są mniej odpowiednie, ponieważ te metryki wskazują na poważniejsze problemy z dostępnością, a zespół chce wykrywać wzrost czasów odpowiedzi, co jest subtelniejszym problemem wydajności.