손민기

노출 API OOM이 반복돼도, 광고 선정은 멈추지 않은 이유

노출 트래픽이 2배로 튀자 노출 API에 OOM이 발생해 광고 엔진 태스크가 50~62분 주기로 반복 재시작됐습니다. 노출 이벤트는 지연되고 일부 누락됐지만, 광고 선정은 OpenSearch와 Redis만으로 돌도록 DB 의존을 끊어 둔 덕분에 선정과 응답은 정상이었습니다.

장애 RCA를 주도해 OOM의 원인을 규명했습니다. 직접 원인은 노출 수집 경로의 R2DBC 커넥션 풀이었습니다.

flowchart TD
    A["노출 중복검증"] --> B{"Redis(SETNX)
존재?"}
    B -->|미존재| C["R2DBC로 DB 조회"]
    C --> D["다수 광고 ID
무제한 병렬 조회"]
    D --> E["동시성 제한 세마포어 비활성
+ 풀 획득 타임아웃 없음"]
    E --> F["커넥션 무한 대기
→ 힙 누적 → OOM"]
    F --> G["엔진 태스크
50~62분 주기 재시작"]
    S["광고 선정"] --> T["OpenSearch + Redis
(DB 비의존)"]
    T --> U["선정/응답 정상"]
    style F fill:#fee2e2,stroke:#ef4444
    style G fill:#fee2e2,stroke:#ef4444
    style U fill:#dcfce7,stroke:#22c55e
                        

• 노출 중복검증이 Redis(SETNX) 미존재 시 R2DBC로 DB 조회
• 다수 광고 ID를 무제한 병렬 조회 → 동시성 제한 세마포어가 주석 처리로 비활성
• R2DBC 풀에 획득 타임아웃 미설정 → 커넥션 충돌이 무한 대기 → 힙 누적 → OOM

복구와 재발 방지, 그리고 역할 구분.

• 실제 복구 = 엔진 태스크 재시작 (캐시 재투입은 이미 OOM이라 무효) → 공식 MTTR 2시간 48분, 인지~복구 10시간 19분
• 본인 기여 = RCA 주도로 원인 규명 + 풀 사용률 메트릭과 그라파나 대시보드 추가 (풀 설정 재조정은 팀)
• 재발 방지 → 메모리 2GB → 4GB 증설 + GC/Heap 모니터링과 알림
• 격리 설계 → 광고 선정은 DB 비의존이라 무영향, 노출 이벤트만 지연

스토리지 등급 변경으로 배치 처리 시간 88% 단축

수백만 건 데이터 인입 배치가 디스크 입출력에서 병목이 걸려 처리 시간 편차가 컸습니다. 스토리지 등급을 한 단계 상향하고, 적용 전후를 일별 로그로 직접 비교 측정했습니다.

복합 인덱스 설계로 느린 정렬 쿼리 개선 (무중단 적용)

지갑 차감 내역 조회가 단일 인덱스로 느렸고, 정렬에서 파일 정렬(filesort)이 발생했습니다. 조회 조건과 정렬 컬럼을 모두 포함한 복합 인덱스로 교체해 정렬까지 인덱스로 처리하도록 했습니다.

실행 계획(EXPLAIN)으로 병목을 먼저 확인한 뒤, 조건과 정렬 컬럼 순서를 맞춰 복합 인덱스를 설계했습니다. 인덱스 추가는 운영 트래픽에 영향이 가지 않도록 락 없이 온라인으로 적용했고, 스테이징에서 실행 계획을 다시 확인해 파일 정렬이 사라진 것을 검증한 뒤 상용에 반영했습니다.

30개 이상 서비스를 무중단으로 옮기되, CDC만 다르게 다룬 이유

보안 요건을 맞추려고 메시지 브로커(Kafka)를 외부 노출 구간에서 내부 구간으로 옮겨야 했습니다. 30개 이상의 서비스가 물려 있어 중단이 곧 매출 손실이었고, 같이 걸린 Kafka 메이저 업그레이드(본인 확인 기준 3.8)도 순단 없이 끝내야 했습니다.

flowchart LR
    P["프로듀서
30+ 서비스"] --> OLD["기존 브로커
(외부 구간)"]
    OLD ==>|실시간 복제| NEW["신규 브로커
(내부 구간)"]
    C["컨슈머
30+ 서비스"] -.1단계 전환.-> NEW
    P -.2단계 전환.-> NEW
    OLD -.3단계 복제 종료.-> NEW
    style NEW fill:#dbeafe,stroke:#2563eb
    style OLD fill:#f1f5f9,stroke:#94a3b8
                        

사전 검증에서 일반 토픽은 복제로 무중단 전환이 되지만, 변경 데이터 캡처(CDC) 커넥터는 재시작 시 오프셋을 이어받지 못해 데이터 누락이 구조적으로 발생한다는 점을 확인했습니다. 그래서 CDC만 분리해 위험을 격리했습니다.

flowchart TD
    A["전체 이관"] --> B{"대상 종류?"}
    B -->|일반 토픽| C["실시간 복제로
무중단 전환"]
    B -->|CDC 커넥터| D["트래픽 적은 새벽에
중단 후 재생성"]
    D --> E["전체 스냅샷 회피
(변경분만 캡처)"]
    E --> F["누락분은
수동 반영 스크립트로 보정"]
    style C fill:#dcfce7,stroke:#22c55e
    style D fill:#fef3c7,stroke:#f59e0b
                        

• 30개 이상 서비스 무중단 이관 → 일반 트래픽 다운타임 0
• Kafka 메이저 업그레이드(3.8) 병행, 이관 절차는 Terraform으로 코드화해 재현 가능하게 정리

Jenkins 단일 서버 한계를 AWS Batch 분산으로 넘긴 이유

Jenkins 단일 서버에서 배치를 돌렸는데, 서비스가 커지며 하루 약 6,400건(Peak Time 병렬 약 40건)까지 늘었고 언어도 Node에서 Python, Java로 확장됐습니다. 특정 시간대에 CPU와 메모리가 100%까지 치솟아 리소스 알림이 빈번했고, 리팩터링이나 서버 증설로는 한 서버에서 수십에서 수백 개 Job을 동시 실행하는 한계를 넘지 못했습니다.

그래서 배치 실행을 AWS Batch로 분산했습니다. 공식 Jenkins 플러그인이 6년간 미업데이트 상태라, AWS Batch 제출과 로그 polling, 재시도, 취소, 알람을 직접 구현한 자체 Jenkins 플러그인(Java 11)을 개발했습니다.

flowchart LR
    J["Jenkins 스케줄링"] --> P["자체 Jenkins 플러그인
(Java 11)"]
    P --> B["AWS Batch
Job 제출"]
    B --> F["Fargate Spot
(쓴 만큼 과금, 병렬)"]
    P -.CloudWatch 로그 polling.-> P
    P -.실패 3회 재시도 / 양방향 취소.-> P
    P -.실패 알람.-> S["Slack"]
    style F fill:#dbeafe,stroke:#2563eb
    style P fill:#e0e7ff,stroke:#6366f1
                        

• AWS Batch 3요소(Job Definition, Job Queue, Compute Environment)로 구조를 잡고, 컴퓨팅은 Fargate Spot으로 병렬 실행
• aws_batch Terraform 모듈을 infra와 app 분리 구조로 개발하고 dev와 prod tfvars를 나눠 재현 가능하게 표준화
• 런타임 1시간 이상이거나 중단 불가 워크로드는 온디맨드로 분리하고, 30분 이내이면서 중단 허용인 워크로드만 Spot으로 보냄

• 하루 약 6,400건 배치 → 단일 Jenkins 서버에서 AWS Batch로 분산 → CPU 100% 병목 해소
• 중단 허용 워크로드만 Fargate Spot → 할인 최대 70%
• WMS, Supply, 검색 3개 도메인에 적용

서버가 속삭였다 "나 그만 괴롭혀" — 펫프렌즈 Batch 인프라 이야기