DB 복제 지연 문제 해결하기

1. 문제 상황

어드민 페이지에서 관리자가 신규 상품을 등록한 직후, 목록을 조회했을 때 등록한 상품이 목록에 나타나지 않는 현상이 발생했습니다. 이 문제는 사용자 입장에서 혼란을 줄 수 있고, 등록 여부에 대한 오해로 이어질 수 있기 때문에 즉시 분석이 필요했습니다.

---

2. 문제 확인 과정

테스트 중 어드민 페이지에서 상품 등록 후 곧바로 목록을 조회했을 때, 신규 상품이 조회되지 않는 현상을 직접 확인할 수 있었습니다.

처음에는 클라이언트 측 캐싱 문제를 의심했지만, 서버에서 응답한 JSON 로그를 추적해본 결과, 실제로 응답 데이터에 새로 등록된 상품이 포함되지 않았습니다.

흥미롭게도, 몇 초 후 다시 상품 목록을 조회했을 때는 등록한 상품이 정상적으로 나타났습니다. 또한, 테스트 코드에서 상품 등록 직후 50ms 정도 지연(sleep)을 두고 목록을 조회하자, 정상적으로 등록된 상품이 포함되어 있었습니다.

이 결과를 확인하고 데이터베이스의 복제 지연(replication lag) 이 문제의 원인일 수 있다는 생각을 했습니다.

---

3. 원인 분석

우리는 AWS RDS의 Aurora 클러스터 환경에서 데이터베이스를 운영하고 있었고, 다음과 같은 구조를 가지고 있었습니다:

• Writer 인스턴스: 모든 쓰기(INSERT/UPDATE) 요청 처리
• Reader 인스턴스(복제본): 읽기 전용 트래픽 처리. 자동으로 확장 가능
• 클러스터 엔드포인트 구조:
  • writer 엔드포인트: 읽기/쓰기 가능
  • reader 엔드포인트: 읽기 전용, 복제본으로 분산

백엔드 아키텍처는 전형적인 레이어드 구조(Controller → Service → Repository)를 따랐으며, Data 레이어에서 쓰기 작업은 writer DB 커넥션을, 읽기 작업은 reader DB 커넥션을 사용하는 방식으로 분기 처리되어 있었습니다.

이 구조는 읽기 부하 분산에는 효과적이었지만, 데이터 등록 직후 즉시 읽기가 필요한 상황에서는 문제가 발생했습니다.

등록된 상품은 writer에 먼저 반영되지만, reader에는 복제 지연으로 인해 아직 반영되지 않았던 것이죠.

---

4. 논의된 해결책들

제안 평가

등록 후 일정 시간(sleep) 지연	간단하지만 복제 지연은 상황마다 다르므로 신뢰할 수 없음
모든 read를 writer 인스턴스로 처리	데이터 일관성은 확보되지만 reader 확장의 이점을 잃게 되고, SPOF 위험 존재
즉시 일관성이 필요한 조회에만 writer 커넥션 사용	현실적인 절충안. 단, 어떤 API가 일관성이 필요한지 구분이 필요함

---

5. 최종 결정 및 적용

우리는 세 가지 방안 중에서 "즉시 일관성이 필요한 API에 한해 writer 커넥션을 사용" 하는 방향으로 결정하였습니다.

예를 들어, 상품 등록 후 바로 호출되는 관리자의 상품 목록 조회 API의 경우, reader 대신 writer 커넥션을 사용하도록 repository에서 커넥션 소스를 분기했습니다.

이를 통해 복제 지연에 따른 일관성 문제를 해결하고, 동시에 reader를 활용한 확장성도 유지할 수 있었습니다.

이 방법의 단점은 관리자 상품 목록 조회 API의 경우에는 writer 커넥션을 사용하기 때문에 부하 분산의 이점이 줄어 둔다는 점 입니다. 부하 분산 이점을 최대한 살리면서 데이터의 일관성을 유지하고 싶다면 등록 직후의 요청에 한해서 특정 시간동안만 컨텍스트 기반 라우팅을 적용해 reader 대신 writer 커넥션을 사용하도록 처리할 수도 있을 것 같습니다.