대량 트래픽에 대응을 해보자

서비스에서 수요성이 있는 정보에 대해서 PUSH를 보내면 사용자가 몰리고 그로인해서 서비스가 전체적으로 느려지는 현상이 발생을 한다.

그러면 어떻게 해야지 서비스가 느려지는 상황을 막을 수 있을까?

 

1. 캐시 사용

A. DB Query 관련

사용자가 그렇게 많지 않고 질의비용이 그렇게 비싸지 않으면 그냥 나름대로 그렇게 써도 문제가 없을 것 같다.

그러나 사용자가 많아질 경우 Connection이 많아지고 그로인해서 CPU 사용률이 갑자기 오르게 될 것이다.

그럴 때에는 간단한 질의에 경우에도 느린 결과값을 보여줄 것이고 심할 경우에는 Timeout이 발생할 확률도 크다.

그렇기에 Cache를 통해서 DB로 접근할 것들을 우회해서 Cache를 통해서 대응하는 것이 유효한 방법이 되어질 수도 있다.

 

B. View 관련

DB에 질의하는 것 이외에 Service를 실행하는 주체에 Cpu가 급격하게 치솟을 수도 있다.

트래픽이 크게 발생하여 그럴수도 있겠지만 해당 서비스에 대한 비용이 커서 CPU가 치솟았을 확률이 크다.

그렇기에 캐시를 할 수 있는 경우 해당 결과값을 캐시를 통해서 빠르게 전달만 하는 것이 효과적인 방법이 되어질 수 있다.

 

2. DB Index 설정

이상하게 그렇게 무거운 작업도 아닌데 오래 걸리는 경우가 있다.

모니터링 툴을 통해서 확인하면 보통 100ms 미만으로 떨어지는 쿼리가 있는 반면 비정상적으로 500ms 이상으로 나오는 경우가 있다.

이럴때 별다른 거 설정할 것 없이 인덱스만 설정해줘도 100ms 으로 떨어지는 경우가 대다수이다.

그리고 저렇게 느린 쿼리들이 많이 호출되는 경우 당연히 DB에는 부하가 생기기에 다른 작업에 대해서도 느려지고 이런 경우
전체적인 서비스 장애가 발생할 수 있다.

 

3. 서비스별 적절한 환경 사용

A. 대량의 트래픽을 예상하고 결과값이 다른 경우

이러한 경우 물리적인 서버대수를 늘리는 것도 방법이 되어질 수 있고 Auto Scale 로 대응을 하는 방식도 있지만

그렇게 대응하는 경우 예상치 못하는 비용의 발생 및 대처가 느리다라는 단점이 있다.

그래서 이때 유용하게 사용할 수 있는 것이 Lambda 와 같은 Serverless 기반의 환경인데 Lambda 를 기준으로 설명하면

Lambda 의 경우 트래픽에 따라 자동으로 대응을 하는 환경이고 Instance 의 Scale Out 대비 또, Request 별로 비용이 발생하다보니 경제적이다.

다만, Lambda 의 경우 Connection 이 직접적으로 DB에 붙는 경우 부하가 생길 수가 있기에 이러한 부분들은 상황에 따라서 우회하는 방향을 선택해야한다.

 

B. 대량의 트래픽을 예상하지만 결과값이 같은 경우

이러한 경우에는 결과값을 정적파일로 서빙을 하는 것이 괜찮다.

만약 내가 상품정보를 제공한다 했을 때 여러 부분은 정적 파일로 제공하는 것이 가능하다.
(내가 생각했을 때, 재고관련 제외하고 대부분은 가능할 것 같다.)

그리고 admin 상에서 상품에 대한 정보가 바뀔 때 해당하는 Response를 미리 정적 파일로 제공을 해서 클라이언트에서 요청시에는 정적파일을 요청하도록 협의가 되어진다면 많은 트래픽을 서비스에서 감당하는 것이 아닌 다른 환경을 통해서 해결할 수 있을 것이다.

 

 

그외 

정적파일의 경우 CDN을 통해서 서빙하는 경우 더욱 더 빠르게 제공을 해줄수도 있고,

해당하는 작업이 즉각적인 응답을 필요로 하지않는다면 비동기로 처리해서 할 수도 있다.(가입 이메일 등등...)

웹서버(Nginx, Apache 등등..) 에서 캐시를 태우고 LB에서 Sticky 설정을 통해서 캐시 대응 및 instance memory 캐시 설정,

Auto Scale 설정을 통해서 비정상적인 상황에 자동으로 대응하도록 설정,

레거시 코드 개선 등등 이 있을 수 있다.