[TroubleShooting] 최소 10배 이상 트래픽 비용 발생할 뻔한 이야기
/ 3 min read
Table of Contents
현재 내가 만들고 있는 서비스는 scrap
과 article
이 있다. 각각 content가 존재하는 데 원문 그대로를 마크다운 형식으로 저장하고 있어 상당히 데이터가 큰편이다.
문제
/scraps/
, /articles/
와 같이 전부 가져올 때 content를 아무런 정제 없이 전부 보내주고 있어 content 길이가 엄청났다.
content가 왜 필요하냐 할 수도 있지만 현재 내가 만드는 서비스는 scrap
, article
각각의 title과 content를 카드형식으로 미리 보여주고 있기에 필요했다.
사실 처음에 content 길이에 대한 별 생각 없이 그냥 return 했다…
해결
이걸 사실 trouble-shooting이라 하기에는 너무나 쉽다. 블로그 글을 쓰기 위해 일부러 그런 것은 아닙니다.. 진짜 깜짝 놀랐습니다..
substring으로 content를 미리보기 용도로만 일부 잘라서 보내고, 상세 페이지에서만 전체를 제공해서 이를 해결하고자 했다. 굳이 모든 내용의 content를 보여줄 필요가 없었다.
결과
scraps
, articles
에 content가 얼마나 크냐에 다르겠지만, 데이터가 쌓일수록 지금보다 더 많은 %
가 개선될 것이다.
/scraps/
content-length: 349667 -> 8864
약 97% 개선!
Before

After

/articles/
content-length: 156341 -> 15815
약 90% 개선!
Before

After

결론
단순히 개발만 하는 것이 아니라, 도메인과 비즈니스에 대한 깊은 이해가 없으면 이런 비용 문제를 놓치기 쉽다는 점을 다시 한 번 느꼈다. 앞으로는 기능 구현뿐 아니라, 서비스 전체의 흐름과 비용 구조까지 고려하는 개발자가 되어야겠다.