[경험 공유] 트래픽 공격에 관한 경험

배경설명

어느 날이었다.
저녁 시간 대 쯤 갑자기 모니터링 보드에서 급격한 hps 증가를 보았다.

예제 그림

너무 급격하게 오른 요청 수로 인하여 요청들이 쓰레드를 모두 차지하여 혼잡 상태에 들어가게 되고,
이로 인해 파드가 무한 재시작하는 상황이 발생했다.

판단

증가 폭이 빨라도 너무 빨랐다.
재배포나 일반적 플로우에서의 일시적 혼잡 상태라면 어느정도 피크를 달성한 이후에 정상화되어야 하고 유저의 일반적 재요청일 경우의 그래프라고 하기 어려울 만큼 해당 그래프는 급격한 증가세에 있었다.

진행

이로 인하여 플로우 상 진행되지 않는 서버가 존재하자 비즈니스적 타격을 받게 되었다.
기존에 RateLimiter가 존재했지만 해당 RateLimiter는 결국 어플리케이션 레벨에 있는 라이브러리였기 때문에 쓰레드 워커가 일을 할 수 밖에 없었다.
예상을 훨씬 상회하는 트래픽이 들어오자 RateLimiter로 바로 거부하는 작업조차 혼잡 상태가 되었다.

해결

scale out도 해봤지만 어플리케이션 단에서 트래픽 처리가 어려워서 마찬가지로 파드들이 계속 죽었다. 인프라팀쪽에서 잘 처리를 해줘서 처리 후에 잘 마무리가 되었다.

소감

처음 RateLimiter를 적용하는 Feature를 맡게되었을 때 나는 작업 후에 예상 트래픽량을 급격하게 상회하는 트래픽에 대해서도 안전할 것이라고 생각하고 있었다.
하지만 이도 결국 쓰레드 내부에서 작업이 이루어지는 것이기 때문에 예상 트래픽량을 정말 훨씬 많이 초월하게 되는 경우에 이슈가 생길 수 밖에 없는 구조였다.
비정상적 요청을 어느정도까지는 커버할 수 있곘지만 이 이후에 작업들에 대해서는 항상 고민해보는게 좋다는 것을 알게되었다.
어떤 새로운 기술을 적용할 때 이 기술의 진짜 한계는 어떨 지 고려해보는 것이 좋을 것이라 생각하게 되었다. 쓰레드 단에서 막히는 것과 인프라 트래픽에서 차단되는 것의 차이 이런 부분을 알아야 좀 더 발전할 수 있다는 것을 알게된 계기인 것 같다.