게시글 조회수 기능은 처음 만들 때 꽤 단순해 보인다.

게시글 상세 페이지에 들어오면 조회수를 1 올리면 되는 것 아닌가?

게시글 상세 API가 호출될 때마다 PostgreSQLdml viewCount 값을 +1 해주면 된다.

await prisma.post.update({
  where: { id: postId },
  data: {
    viewCount: { increment: 1 },
  },
});

작은 블로그라면 이 방식으로도 충분하다.

트래픽이 많지 않고, 특정 게시글 하나에 요청이 물리는 상황도 거의 없기 때문이다.
하지만 서비스가 커지고, 대형 커뮤니티처럼 인기 게시글 하나에 트래픽이 집중되는 상황이라면 이야기가 달라진다.

이번 글에서는 게시글 조회수를 DB에 바로 업데이트하는 방식과 Redis에 먼저 누적한 뒤 batch로 DB에 반영하는 방식을 비교해본다.

테스트 목적

이번 테스트의 목적은 단순했다.
게시글 상세 조회마다 DB에 직접 viewCount +1 하는 방식과 Redis에 먼저 누적하고 나중에 DB에 반영하는 방식은 실제로 얼마나 차이가 날까?

조회수는 대부분의 서비스에서 강한 정합성이 필요하지 않다.

예를 들어 실제 조회수가 10000 인데 화면에 잠깐 9980 으로 보인다고 해서 서비스가 망가지지는 않는다.
반대로 조회수 때문에 게시글 상세 API가 느려지거나, DB가 병목이 되는 것은 훨씬 치명적이다.

그래서 이번 테스트에서는 조회수의 즉시 정확성보다 동시성 상황에서의 성능과 안정성에 초점을 맞췄다.

GET /post/:slug
→ 게시글 조회
→ PostgreSQL viewCount + 1
→ 응답

장점은 명확하고, 구현이 쉽고, 조회수 정합성도 좋다.
PostgreSQL의 increment 는 원자적으로 처리되기 때문에 동시에 여러 요청이 들어와도 숫자가 깨지지 않는다.

단점은, 인기 게시글 하나에 트래픽이 몰리면 같은 row를 계속 업데이트하게 된다.
특정 row 하나에 쓰기 요청이 집중되면 해당 row가 병목 지점이 된다.
이런 상황을 흔히 hot row 문제라고 부른다.

조회수 증가를 요청 경로에서 바로 DB에 쓰지 않는다. 대신 Redis에 먼저 누적한다.

GET /post/:slug
→ 게시글 조회
→ Redis INCR
→ 응답

그리고 별도의 flush 작업이 주기적으로 Redis에 쌓인 증가분을 PostgreSQL에 반영한다.

별도 flush 작업
→ Redis 누적값 읽기
→ PostgreSQL viewCount에 합산

예를 들어 5초간 조회가 1000 번 발생했다면, DB에 1000번 update를 날리는 대신 다음처럼 한 번만 반영할 수 있다.

UPDATE "Post"
SET "viewCount" = "viewCount" + 1000
WHERE id = $postId;

즉, 요청마다 DB를 쓰지 않고 Redis에 가볍게 누적한 뒤, DB 쓰기를 batch로 줄이는 방식이다.

테스트 조건

테스트는 동일한 게시글 하나에 요청을 집중시키는 방식으로 진행했다.

이번 시나리오는 hot-1 이다.

여기서 hot-1 은 여러 게시글을 골고루 조회하는 상황이 아니라, 인기 게시글 하나에 모든 요청이 몰리는 상황을 의미한다.

RPS 는 Resquests Per Second 의 약자다.
초당 몇 개의 요청을 처리하는지를 의미한다.

p95 latency는 전체 요청 중 95%가 이 시간안에 응답했다는 의미다.
평균 응답 시간보다 p95를 더 중요하게 보는 이유는, 평균값은 일부 느린 요청을 잘 드러내지 못하기 때문이다.

20 RPS 에서는 두 방식 모두 안정적이었다.
50 RPS 에서, DB Direct 방식은 목표 처리량을 제대로 처리하지 못했다.
실제 처리량은 약 41 RPS에 머물렀고, p95 latency는 5초를 넘었다.
반면, REDIS Batch 는 거의 목표 처리량을 그대로 처리했다.
이 구간부터 병목이 되기 시작했다.
100 RPS 에서는 두 방식 모두 테스트 환경의 한계에 걸렸다.
하지만 REDIS Batch 가 더 늦게 무너졌다.

정리

작은 블로그라면 DB에 직접 조회수를 증가시키는 방식도 괜찮다.
구현이 단순하고, 운영하기도 쉽다.

하지만 서비스가 커질 가능성을 고려한다면, 조회수는 요청 경로에서 DB를 바로 update하기보다 Redis 같은 중간 저장소에 먼저 쌓고 batch로 반영하는 구조가 더 적합하다.

조회수는 실시간 정산 시스템이 아니다.
조금 늦게 반영되어도 괜찮은 숫자다.

그렇다면 조회수 로직은 정확한 숫자를 즉시 쓰는 것보다, 서비스 전체의 응답 속도와 DB 안정성을 해치지 않는 방향으로 설계하는 것이 더 낫다.