Promise 캐싱으로 API 호출 횟수 줄이기

이 블로그는 Notion API를 사용하고 있습니다. 이 API는 초당 평균 3회라는 호출 횟수 제한을 가지고 있습니다. SSG(ISR)로 정적 사이트 생성을 하고 있고 호출 횟수 제한은 시간당 10800회니까 글 수가 엄청나게 방대해지지 않는 이상 문제가 없고, 조금 추하지만 글이 너무 많아지면 글을 제외하고 사이트를 빌드한 후 글만 따로 포스팅해도 될 일입니다. ISR revalidate 주기는 1시간으로 지정해 놓았고, 그림 파일만 필요할 때 클라이언트 사이드에서 리로드하고 있으니 빌드 시점이 아니라면 10800회를 넘을 일은 없어 보입니다.

현재 시점에서 블로그 프로덕션 코드가 푸시되어 빌드될 때에 API를 몇 회나 호출하는지 살펴 봤습니다.

포스트는 현재 20개인데, 전체 호출 수는 143회였습니다. 많긴 하지만 이 정도면 십 년은 거뜬해 보이는데요…

글 수에 비해 호출 횟수가 이렇게 많은 이유는 크게 두 가지 때문인데, POSTLIST의 경우 Next.js에서 동적으로 라우트 및 메타데이터를 생성하기 위해 전체 글 리스트를 포스트마다 중복호출하기 때문이고 BLOCK의 경우에는 Notion API의 특수성 때문인데, 본문 내용을 쪼개어 재귀호출해야 하기 때문입니다. 왜 이렇게 호출해야 하는지에 대해서나, Notion API의 구조에 대해 더 알고싶으신 분들은 읽어보시면 도움이 됩니다.

아직 널널하지만 어쨌든 신경이 쓰이는 건 어쩔 수 없는 것 같습니다. 제 블로그 방문자가 큰 기업 테크 블로그처럼 많아지지는 않겠지만 그냥 최적화 측면에서 저 호출 횟수가 불편해 보이기 때문입니다. 같은 데이터를 불필요하게 여러 번 가져오고 있는데 그걸 가만두고 볼 개발자가 있을까요…

문제는 배포 환경입니다. 저는 Vercel을 이용해 편하게 배포하고 있었는데, 이걸 위해 redis, upstash, kv같은 걸 추가로 쓰기는 아쉬운 상황입니다. 이사를 가거나 리모델링하기는 싫고 지금 있는 가구만 잘 옮겨서 발 뻗고 눕고 싶은 욕심이라고 할까요. 그래서 인 메모리에 야매로 캐싱을 해 보는 것으로 결론을 냈습니다.

ISR을 이용해 페이지 자체는 캐싱이 되기 때문에 빌드 타임에만 캐싱을 해 주면 되니, 아주 짧은 시간 동안에만 유효한 데이터가 메모리에 할당되어 있으면 되지 않을까 싶었습니다. vercel이 주는 메모리 환경도 널널하고, 블로그 포스트 내부의 그림 파일같은 것들은 파일 객체가 아니어서, 링크 형태로 저장해 뒀다가 로드하기 때문에 메모리에 부하가 적을 것이라고 판단했습니다.

모듈 전역에 객체를 두고, 초기 호출에 데이터를 저장한 뒤 그 다음부터는 캐시에 저장한 것을 빼내 오면 되지 않을까 생각했습니다. 타임스탬프를 두고 짧은 시간이 지난 뒤에는 데이터를 지우고 재호출하는 식으로요. 그대로 구현했는데, 캐시가 작동하지 않았습니다. 아래는 POSTLIST 로그의 일부입니다. CACHE 라는 단어가 하나도 보이질 않습니다. 여러 번 다시 빌드해 봐도 어쩌다 한두 번 보이기는 했지만, 제대로 작동한다고 보기는 어려웠습니다.

사실 저는 이 원인을 생각도 못 하고 있다가 며칠 전에 TIL 페이지를 만들고, 글 리스트 id값이 두 개가 되면서 단서를 발견하게 됐습니다. 빌드가 이루어지는 과정의 로그를 살펴보면 7702로 끝나는 것과 f819로 끝나는 것 두 종류의 id값이 규칙성 없이 번갈아서 나오는 것을 보실 수 있습니다. next build로 페이지를 빌드할 때 순차적으로 빌드하는 게 아니라 병렬적으로 빌드한다는 것을 추론해볼 수 있습니다. 즉 호출의 동시성 문제가 해결되지 않는다는 것입니다.

이렇게 병렬 빌드를 하게 되면 첫 번째 비동기 요청이 완료되기 전에 다른 정적 페이지 빌드가 시작되어 버릴 가능성이 있기 때문입니다.

병렬 빌드에 따른 해결 방법은 생각보다 빨리 생각났는데, 인터페이스를 이렇게만 바꾸고, 비동기 요청의 결과값이 아닌 Promise를 저장하는 것입니다. 동시성 문제나 ISR 시점에서의 정보 불일치 문제 때문에 저장한 타임스탬프 같은 상태 정보도 다 떼 버리고요.

Promise는 pending 상태였다가 fulfilled 또는 rejected로, 자동으로 상태가 변화되는 특성을 가지고 있어 동시성 문제를 알아서 해결하고, .then 체인 또는 await 으로 그 결과값을 Single Source로서 사용할 수 있기 때문입니다.

이렇게 캐싱한 후의 결과를 살펴보겠습니다.

전체 요청 143개 중 캐시된 것은 41개이고, 그 중 캐시된 글 리스트 API의 개수를 세어 보면 34개입니다. 글 리스트를 40번 요청하고 있었는데 6번 호출하는 것으로 줄였습니다. 로그를 잘 보면 2종류의 글 리스트 API (7702와 f819) 를 3회씩 호출하고 있는 것을 보실 수 있습니다.

즉 본문 캐싱은 여러 번 호출될 일이 없기 때문에 사실 (예상하다시피) 무용합니다. 그럼에도 블록에 대한 캐싱을 적용한 이유는 작동할 여지가 있어서인데, 본문이 아니라 글 리스트 데이터베이스에 대한 메타데이터를 담고 있는 블록(1c9f)이 존재해서입니다. (Notion API는 페이지나 데이터베이스도 블록으로 간주하지만, 다른 API 엔드포인트를 사용합니다). 아래에 전체 로그를 제공하니, 로그를 잘 검색해 보시면 나머지 7개가 하나의 캐싱된 블록을 불러오고 있는 것을 보실 수 있습니다.

솔직히 85% 줄였다고 하고 싶은데 표본이 적어서 어폐가 있는 것 같고요, 인 메모리 캐싱이어서 기술적으로 대단한 것은 아니지만 자바스크립트의 성질을 활용해서 해결한 것에 의의가 있다고 생각합니다. 빌드 환경에 대해 공부했던 것이 번뜩이고 지나가서 이런 문제를 해결해보게 됐습니다. 블로그를 만들 때부터 찝찝한 것이었는데 이렇게 해결하게 되어서 기분이 좋습니다.