본문 바로가기
BackEnd/이슈 정리

[대규모 트래픽] 사양 변경으로 인한 네트워크 부하

by 하용권 2025. 7. 20.

현재 운영하고 있는 서비스의 요청량은 하루에 3~4억 건 정도 됩니다.

작년에 특정 데이터를 추가했고,이로 인해 여름이나 겨울에는 제공하는 데이터가 증가하게 되었습니다.

 

 

문제 상황

 

피크 시간대에 네트워크 부하가 차고, 이로 인해 이 대역폭을 이용하는 모든 서비스에 영향이 갔습니다.

 

처음에는 저희 측 서버에 변경 점이 없어서 저희 팀의 문제는 아니라고 생각했었습니다.

평소보다 오히려 요청량이 적었기 때문입니다.

 

물론 평소보다 수집되는 데이터의 수가 많았습니다.

하지만 작년에는 데이터를 추가한 후에 수집되는 데이터가 3배 더 많은 적도 있었지만, 큰 이슈가 없었습니다.

작년에 네트워크 트래픽을 고려하여 데이터 개수가 일정 개수 넘어가면 슬랙이 울리게 했었습니다.

 

 

하지만 실제 서버의 out traffic을 확인했을 때, 평소보다 1.4배 정도 증가했습니다.

 

피크 시간대가 지나가고 트래픽이 떨어짐에 따라서 해결은 되었습니다.

하지만 당일에 원인은 찾지 못했습니다.

 

원인

다음 날에도 똑같은 현상이 일어났고, 원인을 찾으려 했습니다.

우선 임시 조치로 n 분 마다 주던 데이터를 m 분마다 주는 데이터에 같이 제공하도록 수정했습니다.(n < m)

 

이렇게 함으로써 해결은 되었습니다.

하지만 작년에는 이보다 더 많은 데이터를 제공했었는데, 왜 갑자기 이러한 문제가 생겼는 지는 의문이었습니다.

 

 

 

계속 고민해보니, 작년 여름과 달리 올해 초쯤에 새로운 사양이 고객에게 서비스 되었습니다.

원래 n 분마다 데이터를 제공했었는데, m 분마다 데이터를 제공하는 사양이 추가되었던 것입니다.

네트워크 트래픽을 고려하여 클라이언트에서 몇 분주기로 호출할 지까지 정했었습니다.

 

하지만 이는 작년 여름에 새로운 데이터가 들어오기 전에 검토를 했었습니다.

즉, 새로 추가된 데이터는 고려하지 않았었습니다.

 

이 상태에서 여름 때, 데이터가 증가했고 이로 인해 네트워크 대역폭이 부족해지는 현상이 발생했던 것입니다.

 

 

 

 

 

느낀점

 

전에 새로운 사양을 추가한 상태에서, 데이터의 개수가 추가 되었습니다.

 

새로운 사양을 추가했을 때에는 네트워크 트래픽을 고려했었지만, 그 후에 추가된 데이터에 대해서는 이전 변경점을 빼고 검토한 것이 문제였습니다.

 

사실 트래픽이 큰 서비스가 아니었다면, 새로운 사양이 추가된 후에 데이터가 증가하더라도 큰 영향이 없을 수 있습니다.

하지만 대규모 트래픽이 발생하는 서비스다보니, 이런 사소한 점을 놓치면 큰 문제가 발생하는 것을 알 수 있었습니다.

 

 

앞으로는 이러한 변경점을 잘 트래킹할 필요가 있다는 것을 깨달았습니다.

새로운 것이 추가될 때 추가되는 것만 고려하는 것이 아니라, 과거에 반영했던 다른 변경점도 같이 고려를 해야 되는 것을 알 수 있었습니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

반응형