Throttling Design Pattern to Handle an Extreme Load

https://medium.com/@dmosyan/throttling-design-pattern-to-handle-an-extreme-load-a0b24c31e3ec

 

리소스 소비 제어는 애플리케이션이나 서비스가 과도한 부하가 걸릴 때에도 시스템이 계속 작동하고 SLA(서비스 수준 협약)를 충족할 수 있게 해줍니다. 애플리케이션의 부하는 시간에 따라, 활성 사용자 수나 그들이 수행하는 활동의 종류에 따라 달라집니다. 만약 시스템의 처리 요구 사항이 사용 가능한 리소스 용량을 초과하면 성능 저하나 시스템 오류가 발생할 수 있습니다. 이를 해결하기 위해 클라우드에서는 여러 전략을 사용할 수 있으며, 그 중 하나가 자동 확장(autoscaling)을 통해 사용자의 요구에 맞게 리소스를 동적으로 조정하는 것입니다. 이 방법은 사용자 수요를 충족시키면서도 비용을 최적화할 수 있습니다.

문제점과 해결 방안

자동 확장은 추가 리소스 제공을 트리거할 수 있지만, 리소스가 즉시 제공되지 않는 경우가 있습니다. 수요가 급증할 때, 리소스 부족이 발생할 수 있는 짧은 시간 동안 문제가 생길 수 있습니다.

이를 해결하기 위한 대안 전략은 애플리케이션이 리소스를 일정 한도까지만 사용하도록 하고, 이 한도에 도달하면 요청을 제한하는 방식(스로틀링, throttling)을 사용하는 것입니다. 시스템은 리소스 사용을 모니터링하여 임계값을 초과하면 특정 사용자나 요청을 제한할 수 있어야 합니다.

스로틀링 전략

1. 요청 거부: 특정 사용자가 정해진 시간 동안 시스템 API를 초과해 요청하면 요청을 거부하는 방식입니다.
2. 비필수 서비스의 기능 제한: 중요한 서비스가 충분한 리소스를 확보하도록 비필수 기능을 비활성화하거나 기능을 저하시키는 방법입니다. 예를 들어, 스트리밍 서비스는 해상도를 낮출 수 있습니다.
3. 부하 평준화: 우선 순위 대기열(priority queue)을 사용하여 SLA가 높은 테넌트의 요청은 즉시 처리하고, 그 외의 요청은 대기시키는 방식입니다.

3rd-party 서비스 통합 시 주의 사항

외부 서비스가 비활성화되거나 오류를 반환할 수 있으므로, 동시 요청 수를 줄여 오류 로그가 불필요하게 많이 쌓이지 않도록 해야 합니다. 성공적으로 처리된 후에는 다시 정상적인 요청 처리로 돌아갈 수 있습니다.

자동 확장과 스로틀링의 조합

자동 확장과 스로틀링을 결합하면 애플리케이션이 높은 수요 속에서도 SLA를 유지할 수 있습니다. 높은 수요가 지속될 것으로 예상되면 스로틀링을 임시적으로 사용하여 시스템이 확장될 시간을 확보할 수 있습니다.

고려 사항

• 스로틀링은 애플리케이션 설계 초기에 고려해야 하며, 구현 후 추가하기는 어렵습니다.
• 스로틀링은 빠르게 이루어져야 하며, 로드가 완화되면 원래 상태로 신속히 돌아가야 합니다.
• 스로틀링 중인 서비스가 사용자 요청을 거부할 때는 429(“Too many requests”) 또는 503(“Server Too Busy”)와 같은 오류 코드를 반환해야 합니다.

사용 시기

• SLA를 유지하기 위해.
• 특정 테넌트가 리소스를 독점하지 않도록 하기 위해.
• 갑작스러운 부하를 처리하기 위해.
• 비용 최적화를 위해 리소스 사용을 제한하기 위해.

예시

여러 테넌트 조직의 사용자들이 설문조사를 제출하는 클라우드 애플리케이션에서, 한 테넌트의 사용자가 지나치게 많은 요청을 보내면, 다른 테넌트의 사용자들에게 영향을 미치지 않도록 요청 수에 한도를 설정하여 그 이상의 요청을 차단하는 방식입니다.