Ch21. 과부하 처리하기

로드밸런싱 정책의 목적은 과부하를 피하기 위함이다. 이번 장에서는 과부하를 처리하는 다양한 방법에 대해서 알아보도록 하자.

 

경감된 응답 리턴

평상시의 응답보다 정확도가 조금 떨어지거나 혹은 더 적은 데이터를 제공하는 것이다. 이렇게 하면 연산을 수행하기가 더 쉬워진다. 하지만, 과부하가 극심한 경우에는 서비스가 경감된 응답조차도 연산하고 서비스할 수 없을 수도 있다. 이런 상황에서는 에러를 리턴하는 것 외에는 신속하게 대처할 수 있는 방법이 없다. 물론 데이터센터 자체에서 수용량을 넘어서는 트래픽을 전달받지 않도록 하면 해결 되기는 한다.

 

초당 쿼리 수의 함정

쿼리는 종류에 따라 요구하는 자원이 상당히 다르다. 따라서 초당 쿼리 수를 통해 수용량을 모델링하면 실망스러운 결과를 볼 수 있다.

 

더 나은 방법은 사용 가능한 자원에 대해 직접적인 수용량을 측정하는 것이다. 우리는 대부분의 경우 단순한 CPU 사용량이 자원 증설에 대한 신호로써 손색이 없다는 점을 알아냈다. 그 이유는 다음과 같다.

• 메모리에 대한 부하는 본질적으로 CPU 사용률의 증가를 동반한다.
• 나머지 자원이 CPU보다 먼저 바닥나는 경우는 극히 드물기 때문에 해당 자원을 준비할 여력이 충분하다.

 

사용자별 제한

전체적인 과부하가 발생하면 서비스가 엉뚱한 행동을 하는 고객에게만 에러 응답을 리턴하고 나머지 고객들은 영향을 받지 않도록 하는 것이 중요하다. 그러기 위해서는 서비스 소유자는 고객의 행위를 고려해서 자신들의 수용량을 준비해야 하며, 서비스 수준 동의에 따라 사용자별 할당량을 정의해야 한다. 참고로 서비스 소유자는 모든 고객들이 자신의 자원을 지속적으로 한계치까지 사용하지 않는다는 사실에 기초해 이 같은 계획을 수립한다.

 

클라이언트 측에서의 사용량 제한

고객의 자원 소비량이 할당량의 범위를 벗어나면 백엔드 태스크는 신속하게 이후의 요청을 거부해야 한다. 하지만 이러한 요청을 거부하는 것도 비용을 소모하는 작업이다. 따라서 클라이언트 측에서 애초에 요청이 가지 않도록 사용량을 제한하는 것이 더 좋은 방법이다.

 

중요도

해당 요청이 얼마나 중요한지를 나타내는 값이다.

• CRITICAL_PLUS: 가장 중요한 요청을 위한 값으로 이 값을 가진 요청들은 실패 시 사용자에게 직접적인 영향을 미치게 된다.
• CRITICAL: 프로덕션 환경에서 전달되는 모든 요청들이 기본적으로 사용하는 값이다. 서비스들은 예상되는 CRITICAL 및 CRITICAL_PLUS 등급의 요청들을 모두 처리하기에 충분한 사용량을 준비해야 한다.
• SHEDDABLE_PLUS: 어느 정도 실패가 발생하는 것을 용인할 수 있는 트래픽을 위한 값이다. 실패 시 몇 분이나 몇 시간 후에 다시 재시도하게 되는 일괄 작업을 위한 기본값이다.
• SHEDDABLE: 부분적 실패가 자주 발생하거나 간혹 아예 사용이 불가능할 것으로 예상되는 작업들을 위한 값이다.

중요도에 따라 올바르게 대처할 수 있도록 다양한 제어 메커니즘에 중요도를 결합했다.

 

활용도에 대한 신호들

활용도는 단순히 CPU 사용률을 측정한 것일 수도 있고 예약된 메모리 대비 사용 중인 메모리 비율을 측정하기도 한다. 활용도가 설정된 한계치에 다다르면 요청의 중요도에 따라 이에 대한 처리를 거부하기 시작한다.

 

재시도 여부 결정하기

구글에서는 재시도 허용 수준을 최대 3회까지로 제한하고 있다고 한다. 그리고 클라이언트별 재시도 한계를 정의해서 특정 비율 안에서만 재시도를 수행하도록 정의하기도 한다. 이에 따라 요청의 증가율이 다르게 나온다.

 

정리

태스크의 부하를 데이터센터에 상대적으로 균일하게 배분하기 위한 다양한 기법들(클라이언트 측 사용량 제한, 고객별 할당량 등)에 대해서 살펴보았다. 추후에 로드밸런싱을 구현할 일이 생긴다면 19~21장에 배운 내용을 바탕으로 상황에 맞게 적절한 로드밸런서를 구현할 수 있을 것 같다.