SUS02-BP06 버퍼링 또는 제한 개선으로 수요 곡선 완화
버퍼링 및 제한은 수요 곡선을 완화하고 워크로드에 필요한 프로비저닝 용량을 줄입니다.
일반적인 안티 패턴:
-
클라이언트 요청은 필요하지 않아도 즉시 처리합니다.
-
클라이언트 요청에 대한 요구 사항을 분석하지 않습니다.
이 모범 사례 확립의 이점: 수요 곡선을 완화하면 워크로드에 필요한 프로비저닝 용량이 줄어듭니다. 프로비저닝 용량을 줄이면 에너지 소비와 환경에 미치는 영향도 줄어듭니다.
이 모범 사례를 따르지 않을 경우 노출되는 위험 수준: 낮음
구현 가이드
워크로드 수요 곡선을 완화하면 워크로드에 프로비저닝된 용량을 줄이고 환경에 미치는 영향도 줄일 수 있습니다. 아래 그림에 표시된 수요 곡선을 바탕으로 워크로드를 가정합니다. 이 워크로드에는 2개의 정점이 있으며, 이러한 정점을 처리하기 위해 주황색 선으로 표시된 리소스 용량이 프로비저닝됩니다. 이 워크로드에 사용되는 리소스와 에너지는 수요 곡선 아래의 영역이 아니라 프로비저닝된 용량 선 아래의 영역으로 표시됩니다. 이 2가지 정점을 처리하려면 프로비저닝된 용량이 필요하기 때문입니다.
![Provisioned capacity waveform with two distinct peaks that require high provisioned capacity.](images/provisioned-capacity-1.png)
높은 프로비저닝 용량이 필요한 2개의 고유한 정점이 존재하는 수요 곡선입니다.
버퍼링 또는 제한을 사용하여 수요 곡선을 수정하고 정점을 완화할 수 있습니다. 이렇게 되면 프로비저닝된 용량과 소비되는 에너지가 줄어듭니다. 클라이언트가 재시도를 수행할 때 제한을 구현합니다. 요청을 저장하고 나중에 처리하도록 버퍼링을 구현합니다.
![Waveform diagram displaying a workload with smoothed-out peaks created using buffering or throttling.](images/provisioned-capacity-2.png)
수요 곡선 및 프로비저닝된 용량에 대한 제한의 효과입니다.
구현 단계
-
클라이언트 요청을 분석하여 응답 방법을 결정합니다. 고려해야 할 질문은 다음과 같습니다.
-
이 요청을 비동기식으로 처리할 수 있는가?
-
클라이언트에 재시도 기능이 있는가?
-
-
클라이언트에 재시도 기능이 있는 경우 현재 요청을 처리할 수 없으면 나중에 다시 시도해야 함을 소스에 알려주는 제한 기능을 구현할 수 있습니다.
-
Amazon API Gateway
를 사용하여 제한을 구현할 수 있습니다.
-
-
재시도를 수행할 수 없는 클라이언트의 경우 수요 곡선을 완화하려면 버퍼를 구현해야 합니다. 버퍼는 서로 다른 속도로 실행되는 애플리케이션이 효과적으로 통신할 수 있도록 요청 처리를 연기합니다. 버퍼 기반 접근 방식은 대기열 또는 스트림을 사용하여 생산자의 메시지를 수락합니다. 메시지는 소비자가 읽은 후 처리되므로 소비자의 비즈니스 요구 사항을 충족하는 속도로 메시지를 실행할 수 있습니다.
-
Amazon Simple Queue Service(Amazon SQS)
는 단일 소비자가 개별 메시지를 읽을 수 있는 대기열을 제공하는 관리형 서비스입니다. -
Amazon Kinesis
에서는 여러 소비자가 같은 메시지를 읽을 수 있는 스트림을 제공합니다.
-
-
전체 수요, 변경률 및 필수 응답 시간을 분석하여 필요한 제한 또는 버퍼의 크기를 적절하게 조정합니다.
리소스
관련 문서:
관련 동영상: