트래픽 과부하가 발생할 경우 어떻게 할 것인가?

일단은 어쩔 수 없는 과부하가 발생하기 전에 사전 모니터링을 해서 과부하를 줄여야합니다.

과부하가 발생하면, 서비스의 속도가 저하되거나 서비스가 접속 불가능한 상황이 됩니다.

두 가지 측면으로 서비스 병목 지점을 찾을 수 있습니다. 다음으로 설명을 시작하겠습니다.

Infra 측면에서 서비스의 병목 지점을 일단 찾아야한다.

예를 들어, 3-tier 구조인 Client-Server-DB에서 Server와 DB 중에 어느 부분이 지금 높은 시스템 자원을 사용하고 있는지 확인합니다.

대부분은 Server나 DB 둘 중 한 부분에서 병목지점을 확인할 수 있습니다.

WAS에서 병목현상이 발생할 경우에는 WAS 자체를 Scale-Up 또는 Scale-Out을 고려해야합니다.

일시적인 트래픽 증가로 인한 과부하는 Scale-Out이 적절합니다. AWS를 예로들면, Auto-Scaling-Group을 사전에 셋팅하여 대응할 수 있습니다.

Scale-Up 같은 경우에는 지속적인 Traffic으로 일정기간 지속적으로 WAS에 부하를 주고 있는 상황이면, 언제 닥칠지 모르는 과부하를 위해서 Scale-Up으로 Server의 리소스를 확보해두는 것으로 해결할 수 있습니다.

DB에서 병목 현상이 발생하는 경우에는 심각한 상황이다.

관계형 DB는 WAS처럼 간단하게 Scale-Out으로 트래픽을 분산 처리할 수 없기 때문에 간단하지 않습니다.

Traffic이 과부하인 상태에서는 일단 Traffc이 DDOS와 같은 잘못된 요청이 아닌지 부터 살펴보고, 만약 의도적 공격이라면 IPS를 통해서 WAS 앞 단에서 막는 것이 중요합니다.

그런데 사실 DB에 일시적이 과부하가 발생하면, 보통 Traffic이 줄어들때까지 기다리는게 보통입니다.

일단은 평소에 DB에 관련된 최적화가 이루어져있는지 체크하는 과정이 중요하다. 가장 간단하게 할 수 있는 Query 최적화가 있습니다.

그리고 평소에 Query 실행계획을 보면서 Query를 적용하기 전에 테스트하는 과정이 필요합니다.

주로 DML 키워드 WHERE이나 ON에서 검색조건이되는 컬럼이 Index가 적용되어있지 않은 경우에 Full Scanning으로 인한 속도 저하가 있습니다.

데이터 베이스 Engine의 최적화 InnoDB, MyISAM, MEMORY를 선택하는 방식에 따라 비즈니스 로직에 최적화된 Engine이 다르기 때문에 잘 사용해야합니다.

보통 Engine의 큰 차이점은 flush 시점과 Lock의 범위정도라고 할 수 있습니다.

개발 과정에서 JMeter를 통해서 부하 테스트 시나리오를 만들고 WAS의 리소스 사용과 형태를 주기적으로 확인해나가야합니다.