DB ACID

동시성 문제 발견한 후 공부하게 된 ACID 정리.

비정상 트래픽 차단 기능을 만들면서 Rate Limit이랑 Bot 탐지 미들웨어를 붙이는 작업을 구현하고 있었다.

slowapi를 쓰려다가 문서를 보니 in-memory 기반이라는 걸 알게 됐다. 멀티 워커 환경에서는 워커마다 카운터가 따로

돌아가니까 Rate Limit이 사실상 무의미해진다는 것 또한 배우게 되었으며, Redis의 자체 기능을 통해

해당 부분을 해소할 수 있음을 깨닫고 Redis 적용 필요성을 느꼈다.

Request
  ↓
Bot 탐지 미들웨어
  ↓
Rate Limit (Redis 카운터)
  ↓
Endpoint
  ├── 크레딧 차감 (Redis DECR)
  ├── Job 생성 → PostgreSQL
  └── SQS 발행

그래서 전체 아키텍처에 있어 Redis DECR과 같은 내부 기능으로 처리하면 멀티 워커 환경에서 발생할 수 있는

race condition을 해결할 수 있음을 배워 팀원분께 아키텍처 문의를 드렸더니 답변을 해주셨다.

"크레딧에 접근하는 워커는 API 하나. 6개 워커는 AI 기능용이라
크레딧 소모 이후에 시작되는 애들이고, Redis는 아직 저희한테 해당 안 돼요."

사실 처음에 들었을 때도 제대로 이해하지 못했다. 나는 멀티워커를 그냥 워커가 여러개니 멀티워커라 생각했는데,

그게 아니었고 해당이 안된다고 하신 거구나 정도로만 생각했다.

"DB의 ACID만 알아도 동시성 문제를 어느 정도 해결할 수 있어요."

추가적으로 말씀해주셔서 다시 공부해보게 되었다.

---

ACID가 뭔데

ACID는 Atomicity원자성, Consistency일관성, Isolation격리성/독립성, Durability지속성/영속성의 약어.

• A:트랜잭션간 명령은 전부 성공하거나 실패해야하며, 하나라도 실패하면 전체 작업취소
• C:트랜잭션 성공후 db는 정해진 규칙을 유지해야함.
• I:여러 트랜잭션 동시 실행 간 서로 영향을 주지 않는 독립적 동작이 이루어져야함.
• D:성공된 트랜잭션의 결과는 시스템 장애가 발생해도 영구적으로 반영되어야 한다.

우리 코드를 뜯어보았다

공부하고 나서 실제 코드를 다시 봤다. 생각해보니 DB 트랜잭션간 다양한 변수 발생으로 중간에 과정이 중단될수도,

실패할 수도 있는데 그런 중도실패했을 때를 대비한 코드가 없었다. 버그 발생 시 조회할 수 있는 로거 구현은

코드 리뷰를 들으며 차후 수정하였었지만, 프로덕션 레벨의 코드는 코드 베이스가 커질수록 디버깅을 위한 장치와

변수에 대비하는 전략을 심도있게 설계해놓아야 함을 이번 기회로 다시 한 번 깨달았다.

 

코드에서 발견했던 ACID 위반 문제들이다.

rollback 문제 식별

# 문제 상황 (익명화)
def deduct_and_record(db, user):
    user.credits -= 1
    db.commit()              # 1차 커밋
    record_event(db, ...)    # 여기서 터지면?
    db.commit()              # 2차 커밋 — 크레딧만 빠진 채로 끝남

 크레딧 차감(deduct_credit)이 단독 커밋된 뒤, 이벤트 기록(create_event)이나 Job 생성(create_job)에서 예외가 터지면 

크레딧은 이미 빠진 상태인데 분석 작업은 생성되지 않는다. 사용자 입장에서는 횟수가 줄었는데 결과가 없는 상황이 된 것이었다. 실제로 credit_service.deduct_credit()이 db.commit()을 직접 호출하고 있었고, 이후 job_repo.create_job()까지 가기 전에

어디서든 터지면 롤백 대상 자체가 없었다. 돈과 직결되는 크레딧 관련 이슈였기에 코드에서 큰 문제를 발견한게 맞았다.

 

# 개선 방향
def deduct_and_record(db, user):
    try:
        user.credits -= 1
        record_event(db, ...)
        db.commit()          # 한 번만
    except:
        db.rollback()
        raise

deduct_credit()을 flush()만 하도록 바꾸고, 이벤트 생성 → Job 생성까지 전부 같은 트랜잭션 안에서 진행한 뒤 job_service

레벨에서 한 번만 commit(). 중간에 어디서 터져도 except → db.rollback() 으로 크레딧 차감 자체가 취소되는 형식으로 수정했다.

BQ 전송이 fire-and-forget 무책임한 배달..?

이벤트를 PG에 저장한 직후, ThreadPoolExecutor로 BQ 전송을 비동기 실행되고 있었다고 한다. BQ 전송 함수가 executor.submit()으로 던져지고, 메인 스레드는 바로 200을 리턴하는 구조...!

# 문제 상황 (익명화)
executor.submit(send_to_bq, data)
return {"status": "ok"}   # BQ에 안 들어가도 200

BQ 전송이 실패해도 어디에도 기록이 남지 않는 상황이었다..!! 네트워크 타임아웃, 인증 만료, BQ 쿼터 초과 어떤 이유로 실패하든 데이터는 조용히 사라진다. 분석 대시보드에서 어제 이벤트가 왜 절반밖에 안 잡히지? 같은 상황이 생겨도 원인 추적이 불가능한

코드로 구현이 되어있었고, 이 또한 추후 중요한 수정사항으로 불거질 수 있는 문제였다.

## 개선 방향 >> outbox
  def record_event(db, ...):
      event = Event(...)
      db.add(event)
      db.flush()

      outbox = BqOutbox(event_id=event.id)   # 같은 트랜잭션
      db.add(outbox)
      db.flush()
      # commit은 호출자가 — PG 저장과 outbox 기록이 원자적으로 묶임

outbox 패턴이란, 메시지를 외부시스템(BigQuery)에 안전하게 전달하기 위한 패턴으로 보낼 메시지를 테이블에 적어두고, 나중에 꺼내서 보내는 패턴이라고 한다. 기존 방식이 주문서를 작성해두고 바로 택배를 던지는 형식으로 택배가 분실돼도

모르는 형태였다면, 주문서 작성 >> 발송대기 목록에 기록 >> 택배기사가 목록확인 >> 발송 / 실패 시 목록에

남아있는 것 기반으로 재시도로 보완된 패턴이다.

 

PG(PostgreSQL)에 이벤트를 저장할 때 bq_outbox 테이블에도 같은 트랜잭션으로 "전송 대기" 레코드를 남긴다.

스케줄러가 30초 간격으로 pending 레코드를 읽어 BQ에 batch insert하고, 성공하면 sent, 실패하면 failed로 마킹.

실패한 건은 재시도 대상으로 남기 때문에 데이터 유실을 방지할 수 있다!! fire-and-forget → at-least-once delivery 보장.

 

 

---

정리하면서

프로덕션 레벨의 코드를 구현해보면서, 모르는게 정말정말 많다는 것을 포함하여 핵심은 기능을 구현하는 것에 그치는 것이 아니라

변수와 이슈, 추후 수정 가능성을 대비하고 점점 더 비대해질 코드 베이스를 스스로도 기능별로 쉽게 찾아가 수정하고 디버깅할 수 있는 환경을 만드는 것에 대한 중요성을 배운다.

 

이론으로 배웠던 DB ACID 또한 배운적이 있었어도 이론으로만 생각해 기억도 나지 않았지만 실무에서 가장 기초가 중요한 것처럼

이론공부도 취업을 위한 CS 지식 공부도 취업을 위함이 아닌 모두 시니어 개발자로 성장할 수 있는 귀한 성장재료가 됨을 스스로

인지하고 가볍게 여겨선 안되겠다 생각하게 되는 중요한 경험을 할 수 있었다.