박동진

번역 배치 작업이 운영DB 를 오래 붙잡고 있을 위험 확인

원인

LLM 응답은 번역 분량에 따라 수초에서 수십 초가 걸리는데, 저장용 커넥션을 미리 잡고 응답을 기다리면 그 시간만큼 운영 트래픽이 쓸 커넥션이 묶임

해결

LLM 호출 구간과 DB 저장 구간을 분리해 대기 중에는 커넥션을 점유하지 않도록 조치 - 연결 풀은 최소 1 최대 2 로 묶고, lock_timeout 1.5초 · statement_timeout 5초를 걸어 오래 버티는 대신 빨리 포기하도록 설정

여러 인스턴스가 동시에 뜰 경우 같은 행을 중복 번역하는 이슈

원인

기존 배치 Worker 가 이미 실행 중인지 확인할 방법이 없어, 프로세스가 둘 이상일 경우 같은 대상을 각자 처리했습니다.

해결

PostgreSQL advisory lock 을 통해 Worker 진입을 직렬화해 인스턴스 간 중복 실행을 차단했습니다.

저장 단계에서 실패한 건이 기록 없이 사라지는 현상

원인

UNIQUE 충돌 · lock 대기 · statement timeout · 응답 검증 실패가 모두 예외로 끝나면서, 어떤 항목이 왜 빠졌는지 남지 않았습니다.

해결

실패 유형을 구분해서 수동 처리 큐로 이관하고 작업 이력에 기록했습니다. 풀 대기가 1초를 넘는 건도 실패로 처리하지 않고 같은 큐로 보내 다시 검토할 수 있게 했습니다.

요청 1건마다 Redis 조회 - vuser 70 구간에서 1,400 TPS 스파이크

원인

모든 요청이 Gateway 에서 Redis 내 blacklist:{jti} 를 조회하다 보니, 초당 처리량이 그대로 Redis 호출량이 됐습니다. 실제로 블랙리스트에 걸리는 토큰은 1% 미만임에도 전량을 조회하고 있었습니다.

해결

Caffeine L1 캐시(TTL 5s)를 우선 조회하고 Cache Miss 일 때만 Redis 로 내려가게 바꿔 조회 24회 → 1회 (-95.8%). 로그아웃 후 최대 5초 지연은 AT TTL(15분) 대비 0.3% 라 수용했습니다.

vuser 50 구간에서 503 에러 및 TPS 가 0 으로 떨어지는 현상

원인

Resilience4j Bulkhead 의 maxConcurrentCalls 가 25 로 묶여 있었습니다. 동시 호출이 한도를 넘자 BulkheadFullException 이 즉시(elapsed 0ms) 발생했고, 이 예외를 Circuit Breaker 가 실패로 집계해 sliding window 실패율이 50% 를 넘겨 OPEN 으로 전환됐습니다.

해결

한도를 200 으로 올려 BulkheadFullException 4,917건 → 0건, Circuit Breaker 는 CLOSED 를 유지했습니다.

로그인 TPS 175 에서 정체, 응답 135ms

원인

부하테스트 분석 결과 지연의 97% 가 Keycloak ROPC 호출이었습니다. Gateway 1ms 미만, User Service 5ms 미만인데 Keycloak 왕복만 약 130ms 였습니다.

해결

at-cache:{SHA-256(lower(email))} 키로 Redis AT 캐시를 도입해 TPS 175 → 1,568 (+796%), 응답 135ms → 63ms (-53%). 이메일을 해시로 써서 PII 평문 저장을 피했습니다.

DB 커넥션 대기로 응답이 지연되는 현상

원인

HikariCP 풀 기본값 10 인데 vuser 는 50 이라서 구조적으로 부족했습니다. 게다가 connection-timeout 이 30초라 대기가 그대로 응답 지연으로 쌓였습니다.

해결

Little's Law(L = λ × W)로 필요 커넥션을 산정해 풀을 50 으로, timeout 은 3초 fast-fail 로 조정했습니다. GET /users/me TPS 1,720 으로 예측 대비 오차 1%, 응답 37ms → 11ms (-70%).

콜드스타트 37.2초, 부하 테스트 에러율 100%

원인

설정 파일에는 올바른 값이 적혀 있었지만 요청에 실리지 않았습니다. 응답 유지시간(keepAlive)을 YAML 정수 -1 로 쓰자 문자열 "-1" 로 직렬화됐고, 단위가 없는 값이라 Ollama측에서 거부하고 있었습니다.

해결

단위를 명시(-1s)해 콜드스타트 37.2s → 1.2s (-97%), 에러율 100% → 0% 로 회복했습니다.

100 ~ 450자 답변시간 평균 88.9초, p95 188.6초

원인

모델이 답하기 전 내부적으로 추론하는 과정(thinking mode)을 끄는 설정이 적용되지 않고 있었습니다. application.yaml 에는 있었지만 ChatClientFactory 가 defaultOptions 를 통째로 지정하면서 덮어쓰고 있었습니다.

해결

전달 경로를 고쳐 평균 88.9s → 33.0s (-63%), p95 188.6s → 74.5s (-60%). 다만 사실 포함률이 77.8% → 57.1% 로 함께 떨어져, 트레이드오프를 규명하고 기본값은 품질 우선으로 되돌렸습니다.

검색은 정답을 찾아오는데 모델이 그 내용을 쓰지 못함

원인

청크 1500토큰이 한국어 공고문에서 평균 5,425자 청크를 만들었고, topK=3 근거만으로 약 4,521토큰이 되어 검색 단계에서 이미 num_ctx 4,096 을 초과하고 있었습니다.

해결

청크를 800토큰으로 낮춰 문항 통과율 0.0% → 50.0%, 정답 핵심내용 포함률 38.1% → 76.2% 로 올렸습니다.

오전 이른 시간에 접속하면 빈 화면이 뜨거나 전날 운세가 나오는 현상

원인

원본 방송이 오전 7시에 갱신되는데 그 시각을 기준으로 삼지 않아, 갱신 전 접속과 갱신 후 접속이 같은 데이터를 보고 있었습니다.

해결

방송 시간을 기준으로 당일/전날 운세를 구분해 노출하고, API 갱신이 늦어지면 TV Asahi 사이트를 직접 조회하는 fallback 을 둬 빈 화면이 뜨지 않도록 했습니다.

방문자가 늘수록 원본 사이트로 요청이 그대로 전달됨

원인

초기 구조에서는 방문 시점마다 원본을 조회해, 트래픽이 그대로 외부 사이트 부하로 이어졌습니다.

해결

Cloudflare Workers 가 하루 한 번 설정한 시간에 수집·번역한 결과를 KV 에 캐싱하고 프론트엔드는 캐시만 읽도록 바꿨습니다. GitHub Actions 로 매일 캐시를 미리 채워 첫 방문자도 지연을 겪지 않게 했습니다.