Post

트래픽 유량제어

사망 플래그

spaces_7BPEtM5qOBElefnOmX3S_uploads_0FRy2SSzk8Ldbgfv8x2z_image

평화롭던 오후에 네이버 클라우드에서 메일이 왔다.

흔한 점검 안내 메일인가 싶어 대충 보려던 순간, ‘비정상 트래픽’, ‘서비스 정지 예고’ 같은 웬 어마무시한 키워드들이 있길래 빨리 눌러봤다.

내용은 더 어마무시했다. 최근에 코드 변경사항도 크게 없긴 했는데 마구잡이로 호출하던 업보가 쌓였는지, 경고메일이 왔다. 혹시 자동으로 나가는 메일인가 했는데, 센트리에 ip 찍힌 내역 확인해보니 사람이 들어와서 확인은 해보는것 같다. 뭐가됐든 빨리 대처를 해야했다.

환장의 타이밍

image

하지만 당장 대처하기 난감했던 이유가 국토교통부쪽 관련 API 연장 심사 기간이었는데, 네이버 지도랑 기능이 엮여있다. 네이버 지도 기능을 임시로 없애버리면 국토교통부쪽 기능도 다 날아가버리는 셈이라서 빨리 분리를 해야하나 했는데, 관련 소개 자료들도 이미 다 제출해버려서 머리 과부하 중이었다.

그런데 정말 다행히도 저 메일 날아오기 직후로 연장 심사가 끝이났다. 거의 한달전부터 진행된 연장심사인데 진짜 타이밍 예술이었다. 자칫하면 다 꼬일뻔했다. 어쨌든 일단 급하게 api 호출을 막았다. 키값을 비활성화 시킬까 하다가 그냥 프론트쪽 주석 몇개 쳐서 배포했다. 임시로 해당 기능 호출하는 ui들을 전부 없앴다.

원인 분석

스크린샷 2024-08-28 153349

나는 Static Map API를 사용중이다. 최근에 요금 정책이 좀 바뀐것 같다. 원래는 월 300만건까지 무료 제공하고 그 이상으로 늘리려면 전화해서 쇼부를 쳐야했다.

어쨌든 월 최대 한도를 300만건으로 잡고, 내 지도 API 호출량을 확인해보자.

image

한달치 데이터를 뽑아봤는데 호출량은 100만건도 안되는것 같았다. 경고 메일이 왔던 날도 다른날에 비해 특별히 호출량이 많은 편도 아니긴 했다.

그렇다면 문제는 동시에 너무 많이 보낸다는 것인데, 내가 얼마나 호출중인건지 감이 안와서 다른 서비스들의 트래픽을 참고해보기로 했다.

스크린샷 2024-08-28 154453

배민에서 올라온 선착순 이벤트 서버 생존기! 47만 RPM에서 살아남다?! 라는 영상을 참고했는데, 일반적인 주말의 분당 피크 트래픽이 3천이라고 하는걸 보고 내 죄를 뉘우쳤다. 난 거의 디도스 공격을 하고있던 셈이었다.

물론 지속적으로 요청을 보내는건 아닌데, 내 서비스가 네이버를 이용해서 지도를 만들때 최소 121, 최대 441번의 요청을 0.5초도 안걸려서 보낸다. 그냥 for문 안에서 우루루 보내기 때문에 0.5초보다 더 적을수도 있다.

문제는 한 명만 지도를 만드는 것도 아니고, 한 사람이 하나의 지도만 만드는 것도 아니고, 게다가 사람들이 같은 좌표로 지도 생성하는것도 아니라서 캐싱도 안될거다. 이건 도게자를 박아야겠다고 생각했다. 그래서 겸사겸사 관련 문의를 넣었다.

제목 없음 (1)

8월 23일에 넣었는데 8월 28일 기준으로 아직 답장은 없다. 나중에 답이 오면 추가 내용 업데이트를 진행해야겠다.

뭐라도 해놓자

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
for (let i = 0; i < sideBlockCount; i++) {
    for (let j = 0; j < sideBlockCount; j++) {

    // ....

        //  await ??? 
        this.processImage(/** params... */)
            .then((isSuccess) => {
                complete++;

                    if (complete >= total) {
                        onSuccess(canvas);
                    }
            });

        // ...
        // await this.delay(100) ????
    }

}

답장이 오기 전까지 대책을 고민하고 있다. 일단 가장 먼저 생각나는건 관련 호출코드를 동기식으로 바꾸거나 딜레이를 거는 것인데, 이것도 사람 몰릴때 우루루 호출하면 결국 비슷하지 않나 해서 좋은 대안은 아니라고 생각했다.

그래서 든 생각이 요즘 ec2에 로그 && 알람 몰빵 작업을 하고 있었는데, 얘를 게이트웨이 역할로 사용할까 생각이 들었다. 지금도 람다로 구성된 이미지 api로 호출을 넘겨주는 유사 게이트웨이 역할이긴 한데, 지도 이미지들이 사이즈가 워낙 크기 때문에 ec2 메모리 사용량에 부담이 갈까봐 완전 프록시로 사용한다기보다는 관련 정보들만 재가공해서 리다이렉트를 시키는 구조로 되어 있다.

개발 서버에서 테스트를 해봐야 알 것 같긴한데, 메모리 사용량이나 gc 타이밍이 큰 문제가 되지 않는다면 여기서 트래픽 유량제어를 해야 할 것 같다. 아마 개발하다보면 문의 답변도 오지 않을까??

다음 글에는 관련 개발 내용과 네이버 문의의 후속내용을 담아보도록 하겠다. 별일 없겠지???

참고

  • https://www.youtube.com/watch?v=MTSn93rNPPE
  • https://www.ncloud.com/product/applicationService/maps#pricing
  • 내 경험
This post is licensed under CC BY 4.0 by the author.

© . Some rights reserved.

Using the Jekyll theme Chirpy