3. 캐시 서버 병목 원인과 대책

캐시 서버가 병목이 되는 경우는 다음 두 가지이다.

 

ㅁ 캐시 사용 방법 문제

 

캐시 사용 시에 웹 서버와 캐시 서버간 지속적인 접속을 사용하지 않았을 때 캐시 서버 족 CPU 리소스 사용률은 낮은 수준을 유지하지만, 캐시 사용 부분의 latency가 느려져 전체 시스템에 영향을 주는 경우가 있다. 이런 경우 캐시 서버 접속에 있어 지속적인 접속 사용을 검토하는 것이 좋다.

 

ㅁ 서버 리소스 부족

 

* CPU 리소스 부족

* 메모리 리소스 부족

 

캐시 서버 리소스를 모니터링했을 때 CPU나 메모리 리소스 부족이 확인되면 캐시 서버의 스케일 업 또는 스케일 아웃을 검토하기 바란다. 그리고 캐시 서버의 스케일 업이나 스케일 아웃은 온라인 상태에서는 어렵고 구성 변경 중에는 캐시가 히트하지 않는 상황이 발생하기 때문에 주의해야 한다.

 

세션용 스토리지 등의 확장 작업 중 캐시가 초기화 되어 문제가 발생하는 상황에서는 데이터를 영구적으로 유지하는 캐시 시스템을 이용하거나 여유가 있는 인스턴스 타입을 사용하는 등의 대책이 필요하다.

 

ㅁ 캐시 서버 병목 원인과 대책 참고표

원인 구분	원인 상세	주요 증상	대책
캐시 사용 방법 문제	지속적인 접속을 이용하지 않음	캐시 서버 CPU 사용률 높아짐	지속적인 접속 사용 검토
서버 리소스 부족	CPU 리소스 부족	캐시 서버 CPU 사용률 높아짐	- 스케일 업 - 스케일 아웃
	메모리 리소스 부족	메모리 부족으로 캐시아웃 발생	- 스케일 업 - 스케일 아웃

 

 

ㅁ 캐시 사용 정책

 

캐시를 사용하면 시스템 전체 성능을 향상시킬 수 있고 캐시를 잘 활용하면 확장하기 어려운 부분의 부하도 줄일 수 있다.

 

다음은 CDN 사용도 포함하여 적극적으로 캐시를 사용한 사례

 

ㅇ [전제 조건] 캐시 히트율이 높음

 - 마스터 데이터 참고 등 실행 시에 결과가 거의 변경되지 않는 경우

 - 모든 사용자에게 거의 같은 페이지를 응답하는 경우

 

ㅇ [전제 조건] 캐시가 오래되어도 큰 문제가 되지 않거나 오래된 상태 캐시 변경 가능

 - 캐시 보관 기간을 짧게 설정하면 어느정도 해소 가능

 - DB를 갱신했을 때 캐시 내용도 변경 가능한 경우(Read-through 캐시라면 캐시 삭제만으로 가능)

 

ㅇ 리소스 부하가 큰 부분에 적용

 - Latency가 높은 시스템과 충돌이 발생한 경우

 - Throughput이 낮은 시스템과 충돌이 발생한 경우

 - CPU 리소스를 많이 소비하는 처리가 발생한 경우

 

전제조건으로 캐시 히트율이 높은 상황을 설명했지만, 히트율이 낮은 캐시의 보관 기간을 길게하여 히트율을 높이겠다는 방법은 좋지 않다. 그 이유는 다음과 같다.

 

ㅇ 보관 기간을  길게 해도 선형적으로밖에 증가하지 않음

ㅇ 히트율이 낮은 불필요한 데이터가 시스템 리소스(메모리, 스토리지)를 점유함

ㅇ 캐시의 미스 히트에도 리소스를 사용함

ㅇ 보관 기간을 길게 하면 오래된 데이터에 접근하기 쉬워짐

 

반대로 히트율이 높은 데이터를 대상으로 했을 때는 1~10초간의 짧은 시간 동안 보관해도 충분한 효과를 볼 수 있다. 애플리케이션 설계 시에는 캐시 히트율을 높이는 것이 중요하다.

 

예) 초간 1,000 접속이 발생하는 처리를 1초간 유지하는 캐시를 사용한 경우 해당 처리 실행 횟수는 1,000rps -> 1rps로 감소한다.

 

ㅁ Read-through Cache에서 Cache Miss Heat의 스파이크 대책에 대해

 

캐시를 사용하는 것만으로 시스템 특정 부분의 부하를 분산시킬 수 있다. 그대로라면 캐시가 초기화되었을 때 미스 히트가 발생한 순간 많은 접속이 해당 부분에 집중된다.

 

예) 초간 1,000 접속이 있는 처리Latency가 1초 걸리는 경우 캐시가 초기화되어 사용할 수 없게 된 경우 해당 처리 실행 횟수는 1,000rps 요청 발생

 

만약 위의 처리가 10초 걸리는 경우에는 동시에 10,000요청이 발생하고, 캐시가 적절하게 사용되었을 때는 동시에 하나의 요청밖에 발생하지 않는 곳에 10,000 요청이 발생하여 시스템이 멈춰버린다.

 

이런 증상이 발생할 때는 캐시 갱신 작업은 동싱 하나의 요청만 발생하도록 캐시 갱신 처리에 들어가기 전에 해당 키에 대한 락을 거는 기능을 애플리케이션 쪽에 추가하는 것을 검토한다.

 

또 캐시의 논리적 유효 기간을 물리적인 보관 기간과는 별도로 설정하여 그 시간을 초과한 최초 요청만 캐시 갱신을 시도하고 다른 요청은 기존의 캐시 데이터를 이용한다.