"그냥 오토스케일링 그룹 뒤에 두세요"라는 조언은 웹 서버와 같은 상태 비저장 애플리케이션을 확장하는 데 흔히 사용됩니다. 복제본들이 상호 교환 가능하고 최소한의 영향으로 추가하거나 제거할 수 있기 때문에 잘 작동합니다. 그러나 이 접근 방식은 상호 교환 가능성을 위반하는 특정 속성을 가진 워크로드를 포함한 모든 워크로드에 적합하지는 않습니다.그러한 속성 중 하나는 세션이 특정 인스턴스에 연결되어 쉽게 이전할 수 없는 세션 선호도입니다. 또 다른 하나는 새 인스턴스의 느린 시작 시간으로, 인스턴스가 필요할 때 준비되지 않으면 반응형 확장이 비효과적입니다. 이러한 특성을 가진 워크로드의 경우 표준 반응형 오토스케일링은 잘못된 해결책입니다.즉각적인 반응 대신, 확장은 더 느리고 추세 기반 트리거를 사용해야 합니다. 이를 통해 새 인스턴스가 중요하게 필요하기 전에 완전히 작동할 충분한 시간을 확보할 수 있습니다. 또한 단순히 인스턴스를 종료하면 진행 중인 작업이 중단될 수 있으므로 안전하게 축소하는 것도 중요합니다.AWS 라이프사이클 후크와 같은 업계 솔루션은 인스턴스가 종료되기 전에 세션을 정상적으로 비우는 것을 가능하게 합니다. 이 패턴은 새 작업을 중지하고 기존 세션이 완료될 때까지 기다린 다음 인스턴스를 제거하는 것을 포함합니다. 화상 회의 플랫폼과 같은 대규모 시스템은 이미 이러한 더 정교한 확장 전략을 사용하고 있습니다.핵심은 인스턴스 상호 교환 가능성을 평가하는 것입니다. 어떤 인스턴스라도 즉시 어떤 작업이든 처리할 수 있다면 오토스케일링이 적절합니다. 그렇지 않다면, 세션 선호도가 있거나 느리게 시작하는 워크로드를 효과적으로 관리하기 위해 더 느린 확장 메커니즘과 적절한 축소 비우기 로직이 필요합니다. 이러한 워크로드를 반응형 상호 교환 가능한 모델로 강제하면 상당한 실패로 이어집니다."