읽기 저장소로 가장 자연스러운 선택은 이미 사용할 MySQL 의 Read Replica 를 활용하는 것이었습니다. 다른 대안으로 Redis 에 비정규화된 Query Model 을 별도로 구축하는 방식도 검토했습니다.

• 쓰기 요청 → MySQL 에 본 데이터 변경
• 읽기 요청 → Redis Query Model 에서 비정규화된 데이터 O(1) 조회
• 쓰기 성공 후 Redis Query Model 을 애플리케이션 내부에서 동기 업데이트

VU(가상 유저)를 점차 늘려가며 측정한 결과, 첫 병목지점이 DB에서 나타났습니다.

Stage 6 Grafana — HikariCP Connections

Stage 6 Grafana — Process CPU

Stage 6 에서 VU를 두 배로 늘리게되면서, CPU 사용량이 전반적으로 100%에 가까이 도달하게되었고, 실제로 100% 도달한 시점에 작업 처리에 지연이 발생하게 되고, 커넥션 점유 시간이 늘어나게되면서 순간적으로 Hikari 대기 큐도 최대 pool size까지 쌓인 것을 확인할 수 있었습니다. 이에 따라 Spring 인스턴스 1대의 한계에 도달한 것으로 파악하였으며 인스턴스 확장을 고려해보기로 했습니다.

서버 자원은 이미 처음에 가정했던 최대자원인 CPU: 1.0, 메모리: 512MB를 사용하고 있었으므로 스케일업은 불가능하여 스케일아웃을 적용하기로 했습니다. 이미 데이터 저장소를 CQRS 구조로 적용 중이었으므로 읽기 서비스와 쓰기 서비스로 분리할 수 있었지만, 모놀리스 2대를 올려놓고 결과가 어떻게될 지 관찰을 먼저 해보기로 했습니다. 부하 분산은 앞단에 Nginx를 두어 적용 했습니다.

• RPS : 306 → 310
• 각 인스턴스 CPU : 평균 ~37%
• Hikari active : 3~4 / 30
• p95 latency : 506ms → 16.5ms

CPU, DB, 지연시간 등을 확인해보니 전반적으로 안정화된 것을 확인할 수 있었습니다. 이제 VU와 트래픽을 더 늘려서 어떤 병목이 추가적으로 드러날지 확인해보기로 했습니다.

VU 를 6,000 까지 늘려서 한계를 재탐색했습니다. RPS는 310 → 604 로 선형 확장에 성공했지만, 자원은 다시 포화 지점에 도달했습니다.

Stage 8 Grafana Overview

이번엔 HikariCP 대기큐 최대값이 0 이었습니다. 반면에 CPU 사용률은 VU를 6000까지 끌어올린 후 홀드 구간인 00:48 ~ 00:59 동안 평균 80%정도를 사용하고 있었고 최대 99%까지 여러번 도달하고 있었습니다. CPU가 평균 80% 사용하고 있다면 예측 불가능한 트래픽 스파이크가 발생할 때 여유 마진 20%로는 감당하기 어렵다고 생각했습니다. 또한 이미 간헐적으로 CPU가 99%까지 순간 포화가 발생하고 있는데, 이 순간 들어오는 요청들은 처리 지연이나 큐잉이 발생할 수 있고, 지속되면 에러로 이어질 수 있었습니다. 따라서 가용 서버의 확장이 필요한 상황으로 이해했습니다. 그렇다면 CPU 의 대부분을 어떤 요청이 소비하고 있는지 엔드포인트별로 분리해 관찰해봤습니다.

엔드포인트별 누적 요청 건수 — 읽기 엔드포인트가 트래픽의 대부분

엔드포인트별 서버 시간 점유 — CPU 시간의 대부분이 읽기 기능

저장소는 CQRS 로 분리되어 있지만 애플리케이션 레벨에서 읽기와 쓰기가 여전히 같은 JVM 을 공유하고 있었고, 트래픽의 96.7% 를 차지하는 읽기가 JVM 의 거의 모든 CPU 를 잡아먹고 있었습니다. 이 구조에서는 인스턴스를 몇 개 더 띄워도, 그 인스턴스 CPU 의 약 90% 는 또다시 읽기를 위해 소비될 것입니다.

이 시점까지 Redis Query Model 동기화는 쓰기 서비스 내부에서 Spring Event를 활용해 각 도메인 로직의 독립성은 확보하기 위해 노력한 상태였지만, 결국 직접 호출하는 방식이었습니다. 서비스를 물리적으로 분리하면 이 호출이 네트워크 통신이 필요하게 되고, 결과적으로 쓰기 장애가 읽기 영역으로 전파될 수 있었습니다. 쓰기와 읽기의 결합도를 실제로 차단하려면 비동기 이벤트 기반으로 전환해야 했습니다.

따라서 이벤트 브로커를 도입하기로 결정했습니다.

Redis Streams 를 선택한다면 하나의 Redis 인스턴스로 캐싱 / 읽기 쿼리 / 이벤트 스트리밍까지 모두 처리하는 건 부담이 되므로이 되므로, 이벤트 스트리밍 전용 Redis 인스턴스를 새로 올리는 편이 합리적일 것입니다. 그런데 어차피 새 인스턴스를 추가한다면, 앞으로 지속적으로 서비스가 성장하며 부하가 증가할 것을 고려했을 때 높은 트래픽 처리량과 확장성 · 안정성을 갖춘 Kafka 를 선택하는 편이 더 합리적이라고 판단했습니다.

또한 Redis Streams 는 인메모리 기반으로 초저지연 실시간 메시징에 강점이 있지만, 이 프로젝트의 이벤트 처리는 Query Model 업데이트 · 인기글 집계 등 최종 일관성만 맞으면 되는 수준이므로 초저지연까지는 굳이 필요하지 않았습니다. 결론적으로 Kafka 를 이벤트 브로커로 선택했습니다.

• write-app: MySQL 본 데이터 쓰기
• Kafka: 이벤트 브로커 — 읽기 / 쓰기 결합도 차단 레이어
• read-app: 독립 배포 / 독립 확장, Redis Query Model 기반 고속 조회

분리 직후 Stage 9 에서 동일 VU 6,000 부하로 재측정했습니다. 주요 지표 전반에서 개선을 보였습니다.

Stage 9 Grafana — p95 19.1 ms · 안정 구간 유지

Stage 9 Grafana — 서비스별 CPU 분리 관찰 (write / read-1 / read-2), 각 서비스 모두 여유 구간

한 가지 주목할 점은 한계 RPS 자체는 604 → 550으로 약간 감소했다는 것입니다. nginx path 라우팅 오버헤드와 새로 추가된 이벤트 발행 요인으로 유추되지만, 이는 분리가 만든 구조적 여유를 확보한 대가로 충분히 수용 가능한 수치라고 생각되었습니다. 오히려 이제부터는 read-app 만 독립적으로 수평 확장할 수 있으므로, 읽기 트래픽 증가 시 선형으로 RPS를 늘릴 수 있는 구조가 확보되었습니다.

RPS는 961 까지 올라갔지만 기존에는 실패한 요청이 전혀 없었지만 이번에는 실패율이 2.53%나 발생했습니다. 또한 latency의 p99(최악의 케이스) max 값이 1.49 s로 매우 느린 수치로 관찰되었습니다.

Stage 12 Grafana CPU 사용량 그래프

Stage 12 Grafana Tomcat thread 사용량 그래프

CPU 100% 도달이 시작된 12:18:00 경의 Tomcat 스레드 현황을 살펴보니 일시적으로 busy 스레드(워커 스레드 중 작업을 처리하고 있는 스레드)가 pool 사이즈 최대값에 도달하고 있었습니다. CPU의 일시적 과부하로 인해 Tomcat의 워커 스레드들이 처리를 하지못한채 자원을 점유해갔고, 최대 pool 사이즈를 초과한 요청들이 대기큐에 쌓이다가 대기 큐도 꽉차서 요청이 거절된 비율이 전체 요청의 2.53%까지 발생한 것으로 상황을 이해했습니다.

부하 시나리오에 의하면 3분에 걸쳐 VU를 최대값으로 끌어올린 뒤 4분 간 Hold한 뒤 다시 0명까지 줄어들게됩니다. 이에 따르면 CPU 사용률 100%에 도달했던 12:18:00 경부터 12:22:00까지 CPU 사용률도 꾸준히 80% 이상 수준으로 포화상태라고 볼 수 있었고, 가용 서버 확장을 고려할만한 상황이라고 생각되었습니다.

CPU의 일시적 과부하에 대한 요인을 파악하기 위해 포화 시작 시점에 어떤 기능이 주로 latency가 발생했는지 확인해보았습니다.

Stage 12 Grafana 엔드포인트별 p95 latency

확인해보니 GET /v1/articles에 해당하는 게시글 목록 조회 기능이 가장 긴 latency가 소요되고 있었습니다. 뿐만아니라 같은 JVM의 다른 읽기 기능들(GET /v1/hot-articles, GET /v2/comments)의 latency도 함께 증가하여 영향을 받고 있었습니다.

Stage 12 Grafana — Kafka Consumer Lag(미처리된 Consumer 메시지가 밀린 수)

그와 더불어서, HTTP 요청뿐 아니라 같은 JVM 에서 돌던 인기글 기능을 위한 Kafka consumer 의 메시지 소비까지 일시 지연된 것을 확인할 수 있었습니다.

즉 "한 기능의 부하가 관련 없는 다른 기능들로 전파되는" 구조적 문제가 확인되었습니다. 이 전파를 막으려면 기능 간 서로 다른 JVM에 나눠 배치하는 것이 필요하다고 판단되었습니다.

실제로 "무엇을 메인 서비스로 독립시키고 무엇을 묶을 것인가" 는 추가 관측이 필요했습니다. Stage 12의 엔드포인트별 부하 분포를 자세히 들여다봤습니다.

Stage 12 Grafana — 엔드포인트별 트래픽 분포

관측 결과 게시글 도메인 기능들의 누적 처리 시간이 81.3%로 압도적으로 높았습니다. 이에 근거하여 게시글 도메인의 기능들을 메인서비스로 독립시키기로 결정했습니다. 이 때 서비스 분리의 개선 효과를 보다 명확히 체감하기 위해 가용 서버 인스턴스는 늘리지 않은 채, 각 인스턴스 별로 서비스 분리만 진행하여 담당 도메인의 역할을 수행하도록 하였습니다. 이제 서버 확장ㆍ성능 튜닝ㆍ개선을 적용할 때 주요 요인과 개선 결과를 해당 도메인에 맞춰 보다 세밀하게 파악 가능할 것으로 기대할 수 있을 것입니다.

분리 직후 동일 VU 12,000 부하로 재측정했습니다. CPU 사용량의 변화만 보면 개선이 잘 된건지 의문이 들 수 있지만, 주요 트래픽을 차지했던 게시글 기능을 article 담당 서버가 담당함으로써 다른 기능들의 병목이 해소된 것을 확인할 수 있었습니다. latency가 전반적으로 개선되었으며, kafka 인기글 consumer 처리도 격리되어 안정화되었습니다.

무엇보다 가용 중이던 자원의 변동없이, 서비스 격리만을 진행했는데도 개선 효과가 나타났다는 점이 고무적이었습니다. 하지만 별도로 분리한 article 서비스는 서버 자원이 부족한 상황으로 파악되며, 코드 레벨에서 비효율적인 부분을 찾아 개선하거나, 서버의 추가 확장 등 추가 개선이 필요해보입니다.

초기 쿼리와 그 실행 계획입니다:

SELECT * FROM article WHERE board_id = 1
ORDER BY created_at DESC LIMIT 30 OFFSET 90;

EXPLAIN — Type=ALL, rows=12,329,010, Extra=Using filesort

• Type = ALL: 전체 1,200만 건을 Table Full Scan
• rows = 12,329,010: 필터 조건 (board_id = 1) 을 적용하기 위해 전체 행을 스캔
• Extra = Using where; Using filesort: 정렬을 메모리에서 해결 못 해 디스크에서 filesort 수행

1,200만 건에 대해 Full Scan + 디스크 정렬이 반복되니 수초가 걸리는 건 당연한 결과였습니다.

게시판 별로 필터링 (board_id) + 최신순 정렬에 맞춰 복합 인덱스를 생성했습니다. 분산 시스템을 고려해 Snowflake 로 채번하는 article_id 를 최신순 정렬 키로 활용했습니다 (생성 시간 순으로 증가 보장).

CREATE INDEX idx_board_id_article_id ON article (board_id, article_id);

SELECT * FROM article WHERE board_id = 1
ORDER BY article_id DESC LIMIT 30 OFFSET 90;

EXPLAIN — Type=ref, key=idx_board_id_article_id, Extra=NULL (filesort 사라짐)

• Type = ref: Table Full Scan 제거, 인덱스 기반 접근으로 변경
• key = idx_board_id_article_id: 방금 생성한 복합 인덱스 사용
• Extra = NULL: Using where · Using filesort 모두 사라짐

일반적인 페이지 (작은 OFFSET) 는 잘 동작했지만, OFFSET 이 매우 커지는 상황 (예: 50,000 번 페이지 = OFFSET 1,499,970) 에서 다시 약 4초가 소요됐습니다. 그런데 EXPLAIN 은 여전히 인덱스를 잘 타고 있었습니다.

SELECT * FROM article WHERE board_id = 1
ORDER BY article_id DESC LIMIT 30 OFFSET 1499970;

EXPLAIN — 여전히 Type=ref, key=idx_board_id_article_id (작은 OFFSET 과 동일한 계획)

EXPLAIN 상으로는 인덱스를 제대로 쓰는데 실제 실행은 여전히 느린 모순. 인덱스 탐색 자체가 아니라 인덱스 탐색 이후의 과정 에 숨은 비용이 있다고 추정했습니다.

생성한 복합 인덱스는 Secondary Index 입니다. SELECT * 로 전체 컬럼을 가져오려면 Secondary Index 에서 얻은 article_id 를 가지고 Clustered Index (본 테이블) 를 한 번 더 탐색 해야 합니다 — 인덱스 트리를 두 번 타는 구조.

• Secondary Index 에서 조건에 맞는 행을 찾은 뒤, 실제 데이터를 가져오려면 Clustered Index 에 별도로 접근 필요
• OFFSET 이 작을 땐 (30건 앞 90건 = 총 120행) Clustered Index 접근도 적어 빠름
• OFFSET 이 매우 클 때 (1,499,970 이후 30건) 는 필요한 30건을 얻기 위해 앞의 약 1,500,000 행 전체에 대해 Clustered Index 접근이 발생
• 사용자에게 실제로 반환되는 건 30행이지만, 디스크 IO 는 약 1,500,000 회 — 이것이 4초의 실체

인덱스에 포함된 컬럼 (board_id, article_id) 만 먼저 뽑아내면 Secondary Index 만으로 결과를 완결할 수 있어 Clustered Index 접근이 사라집니다 (Covering Index). 이렇게 먼저 뽑아낸 30개의 article_id 에 대해서만 Clustered Index 를 Join 으로 접근하면, 실제 디스크 IO 는 30회로 제한됩니다.

select * from (
  select article_id from article
  where board_id = 1
  order by article_id desc
  limit 30 offset 1499970
) t left join article on t.article_id = article.article_id;

• Sub Query 단계 — Secondary Index 만으로 article_id 30 개 추출 (Covering Index 동작, Extra = Using index)
• Join 단계 — 추출된 30 개의 article_id 에만 Clustered Index 접근
• Clustered Index 접근 횟수: 약 1,500,000 회 → 30 회 (약 50,000 배 감소)

Secondary Index → Clustered Index 접근하는 리소스 비용이 생각보다 굉장히 크다는 사실을 알 수 있었습니다. 이는 인덱스를 설계할 때 굉장히 중요한 포인트가 될 수 있을 것입니다. 이에 따라 최초 인덱스를 설계할 때, Covering Index가 가능하도록 설계하는 방향을 고려하는 것은 좋은 방향이 될 것 같다고 느꼈습니다.

인기글 기능은 위 처럼 좋아요, 댓글, 조회수 이벤트가 발생하면, 인기글 서비스에서 일 단위로 점수를 계산하여 상위 10건을 선정하고 있습니다.

여기서 만약 악의적인 사용자(어뷰저)가 특정 게시글을 일부러 여러 번 조회한다면 조회수 데이터가 조작되게 되고, 인기글도 어뷰저가 원하는 대로 조작이 충분히 가능할 것 같다는 생각이 들었습니다. 이는 인기글 기능을 구현할 때 방어를 반드시 해야 하는 문제로 생각되어 개선해보기로 했습니다.

먼저 데이터 조작을 시도하는 사용자를 식별하기 위한 기준을 정해야 했습니다. 기준은 크게 로그인한 사용자와 비로그인 사용자로 나눌 수 있습니다.

어뷰징 방지는 처음 적용해보는 것이기도 하고, 식별하기 위한 기준만 달라질 뿐 원리는 동일하다고 느껴 우선 간단하게 로그인 사용자 별로 어뷰징 방지를 구현해보기로 했습니다.

최대 약 1,200만 건의 게시글 데이터 각각에 대해 사용자 별로 상태를 관리해야 하는데, 메모리 상에서 이렇게 많은 상태를 관리하기에는 비효율적이므로 DB를 상태 저장소로 채택했습니다. 약 10분 정도면 어뷰징 방지도 어느정도 가능하면서, 캐싱 등을 활용하면 DB 용량도 꽤 효율적으로 사용가능할 것이라 판단하여 10분 동안 상태를 관리하기로 결정했습니다.

• TTL을 10분으로 하여, Redis를 사용해 해당 게시글 ID, 사용자 ID에 대해 setIfAbsent로 Lock을 걸어줍니다
• Lock 획득에 성공하면 조회수를 카운트하고, 이후 동일한 사용자가 동일한 게시글을 다시 조회했을 때 10분이 지나지 않았다면 Lock 획득에 실패하여 조회수는 카운트되지 않습니다
• 사용자는 10분 내에 여러 번 동시에 조회 시도하더라도 Redis로부터 분산 Lock을 단 1번만 획득 가능합니다

완성된 시스템을 다시 도식화해보면 위와 같습니다.

사용자1은 10분 내에 여러 번 동시에 게시글1을 조회 시도하더라도 Redis로부터 분산 Lock을 단 1번만 획득 가능합니다.

이에 따라 10분 동안 사용자1은 게시글1에 대해 조회수를 단 1번만 증가시킬 수 있게 되었습니다.

Redis를 상태 저장소로 선택한 덕분에 TTL을 통해 10분 만료를 자동 처리할 수 있어 별도의 정리 로직이 불필요했습니다. 또한 분산 환경에서 여러 API 서버가 동일한 Redis를 바라보므로 어떤 서버로 요청이 들어오든 일관된 어뷰징 방지가 보장됩니다. 향후 트래픽이 더 커지면 Redis Cluster로 수평 확장이 가능하다는 점도 확장성 측면에서 좋은 선택이었다고 생각합니다.

현재 아키텍처 구조 상, 분산되어 있는 서로 다른 서비스 간 연계 처리는 Kafka를 통해 Event로 처리하고 있습니다.

그런데 만약 Producer가 자신의 비즈니스 로직 수행은 성공했지만, Event 전송 중 Kafka, 네트워크 이슈 등의 문제로 장애가 발생한다면 어떻게 될까요?

인기글 기능을 예로 들면, Producer인 Write 서비스에서 좋아요가 수행되고 이벤트 전송까지 하였지만, 실제 Kafka에는 해당 이벤트가 저장되지 않았을 때, 좋아요는 증가하겠지만 증가한 좋아요 수가 Consumer 서비스에서 인기글 데이터를 최신화하는데 필요한 점수 계산에 반영이 안될 것입니다.

즉, 이벤트가 유실되어 데이터 정합성 문제가 발생할 수 있을 것이라 예상되었습니다. 이 문제를 해결하기위해서는 서로 분산된 시스템 사이의 트랜잭션을 보장하기 위한 매커니즘이 추가적으로 필요하다고 판단되었습니다.

Consumer로 구현되는 게시글 조회 서비스에 비정규화 Query Model의 업데이트, 인기글 서비스 정도이므로 이벤트 처리가 꼭 실시간으로 강력하지 않고 최종적인 데이터 정합성만 맞는다면 상관이 없다고 여겨졌습니다. 더군다나 이벤트 전송이 실패해도 얼마든지 별도로 재전송이 가능합니다.

• Producer 서비스는 비즈니스 로직을 수행하며 본 데이터의 상태 변경과 Outbox Table 이벤트 기록을 단일 트랜잭션으로 처리합니다
• Message Relay는 Outbox Table에서 미전송 데이터를 주기적으로 Polling(10초 간격)하여 조회하고 Kafka로 전송합니다
• 10초도 여전히 너무 길 수 있으므로, Producer 로직이 수행되면(트랜잭션 커밋되고나면) Message Relay로 이벤트를 즉시 전달하여 Kafka로 바로 이벤트 전송을 시도합니다
• 이후 Polling은 전송에 실패한 이벤트들에 대해서만 처리되도록 하였습니다
• 전송 완료된 이벤트는 더 이상 필요없으므로 삭제 처리하였습니다

• 이벤트 즉시 전달 처리와 Polling은 각각 별도의 Thread로 할당하여 처리되도록 하여 성능을 극대화하였습니다
• 이벤트 Polling은 Spring의 Scheduler를 활용하여 10초마다 정기적으로 실행되도록 하였습니다
• @TransactionalEventListener(BEFORE_COMMIT)으로 Outbox 이벤트를 Commit 직전에 저장하고, AFTER_COMMIT으로 커밋 후 즉시 Kafka 전송을 시도합니다

게시글 조회 응답을 만들려면 본문 데이터 외에 write 서비스에 있는 조회수 데이터도 함께 필요했습니다. article-read 서비스에서 조회수 데이터를 어떻게 가져올지가 본 설계의 출발점이었습니다.

위 코드는 Read 영역에서 게시글 조회를 할 때 사용하는 ViewClient의 count() 함수를 테스트하고 있습니다. count() 함수는 API 결과값을 1초동안 캐싱하고 있고, API를 호출할 때마다 "[ViewClient.count]"로 시작하는 로그를 찍고 있습니다.

테스트 코드에서는 맨 처음 캐싱이 되도록 1번 호출하고 나서, 멀티쓰레드를 이용해 동시에 5번 호출 후, 캐시를 만료시키고 있습니다.

테스트를 실행하면 API 호출 후 캐싱되기 때문에, 로그가 단 한번만 찍혀야 할 것입니다.

최초 1번 요청이 왔을 때 Lock을 점유하고, 읽고나서 캐시에 적재 후 Lock을 반환하는 방식을 고려했습니다.

Lock이 걸려있는 동안 캐시가 갱신될 때까지 기다리지말고 그대로 바로 응답해버리면 해결되지 않을까? 라는 생각이 들었습니다.

만료되었더라도 실제 데이터를 여전히 갖고 있어야 하므로, 캐시 데이터의 만료시간을 Logical TTL과 실제 만료시간인 Physical TTL 두 가지로 분리했습니다. Logical TTL이 만료되면 Lock 획득을 시도하고, 성공한 요청만 원본 데이터를 가져와 캐시를 갱신합니다. Lock 획득에 실패한 동시요청들은 Physical TTL이 아직 지나지 않아 실제 캐시 데이터가 남아있기 때문에 기존 데이터를 그대로 반환합니다.

조회수 데이터 요청이 이미 한번 캐싱되고나서 논리적 캐시는 만료되었지만, 물리적 캐시는 아직 지나지 않은 상황의 동작과정을 도식화 해보았습니다. 위 과정을 통해 크게 2가지를 기대할 수 있습니다.

최적화 전과 달리, 캐시 만료 후에 API 호출을 단 1번만 하고 있는 것을 알 수 있습니다.

이제 만료되는 타이밍에 동시 트래픽이 한꺼번에 들어오더라도 조회수 데이터를 위한 API 호출은 단 한 번만 수행하게되어 효율적으로 처리할 수 있게 되었습니다.

캐싱을 해놓았다고 해서 성능 최적화가 끝난 것이 아니라는 점을 배웠습니다. 동시성 문제나 트래픽 증가에 따라 추가 문제가 발생할 수 있으므로, 이를 미리 예상하여 테스트코드로 해당 문제 상황을 재현할 수 있어야 한다는 것을 느꼈습니다.

또한 이번에 적용한 캐시 최적화 전략이 모든 경우에 적합하지는 않다는 점도 인식하게 되었습니다. Logical TTL과 Physical TTL이 다르기 때문에, 갱신이 처리되기 전까지 과거 데이터가 일시적으로 노출될 수 있습니다. 데이터 일관성이 중요한 경우에는 치명적인 영향을 끼칠 수 있으므로, 데이터 특성에 따라 전략을 달리 적용해야 한다는 점을 배웠습니다.