서론

이번에는 웹을 만드는 사람으로써 고객에게 가장 거슬릴 수 있는 트래픽에 관련된 이슈를 프론트엔드 관점에서 조금이나마 해결할 수 있는지 작성해보려고 한다.

그동안 개인적으로는 트래픽은 대부분 서버에서 얼마나 해당 기능에 대한 많은 요청을 견뎌낼 수 있는지를 보는 것이라 백엔드의 중요성이 100%라고 생각했고, 프론트는 해봤자 디바운싱하는 것처럼 일정단위의 Call을 끊어서 보내주는 것으로 되지 않을까라고도 생각했는데, 자세히 알아보니 다른 방법이 있다고 해서 적으려고 한다.

유저 관점에서의 트래픽 장애의 예

내가 겪은 트래픽에 관한 예 중 가장 지독한 경험이었던 것은 바로 올리브영의 올영세일기간이다.

분기에 약 4~5일간 올리브영은 정각 기준으로 유저들에게 랜덤 쿠폰을 적게는 2000원에서 많게는 6000원까지 뿌렸던 것 같다. 그것도 제한 수량을 정하기 때문에, 유저들은 해당 benefit을 얻기 위해서 정각에 해당 쿠폰을 받는 버튼을 눌러야만 했고, 그 순간부터 대기열의 연속이었던 기억이 있다.

한번에 유저가 몰리면 당연히 서버 과부하를 막기 위하여 순차적으로 적용점을 각각 반영해주는 것이 당연하다고 생각하지만, 이 조차 못견뎌서 서버들이 터지는 부분도 있다고 한다. 그래서 서버는 업그레이드를 하거나 확장을 하는 등의 작업 즉, 스케일링을 통하여 해당 부분을 방지하려고 노력한다.

프론트엔드 과점에서 바라보는 트래픽 처리

요청을 서비스에 맞게 제어하기

앞서 서론에서 말한 디바운싱 매커니즘을 구현하는 것도 프론트 입장에서 서버로 가해지는 과도한 부하를 줄이는 방법이다. 예를 들어 1분 동안 수만명의 사람들이 동시에 버튼을 클릭하여 무언가 받아오거나 내주는 것을 원한다면, 그 1분을 단위를 쪼개어 수만명분의 요청을 단위만큼 줄이면서 그 단위끼리 서버에 요청을 해준다면 사용자의 의도에 맞게 요청을 제어하고 서버로의 부하를 줄일 수 있다.

캐싱활용

애매한 부분이 있어서 추가로 찾아보고 확정적인 정보를 얻을 시에 다시 작성하겠습니다 ㅠㅠ