실제 사용자를 받는 서비스를 만들면서 배운 것 (회고)
가입자 466명, MAU 300명. 지표를 모으는 것과 읽는 것은 다른 일이었습니다.
백엔드 개발 기록
아주이벤트, 메일상자, 아올다 클라우드를 만들면서 마주친 문제와 해결 과정을 적습니다.
글에 나오는 코드는 실제 저장소의 코드이고, 수치는 전부 직접 측정한 값입니다.
하루 830건을 위해 분당 10만 건을 준비했습니다 (회고)
하루 830건을 보내면서 분당 10만 건을 준비했습니다. 과하게 만든 것보다 과하게 말한 것이 문제였어요.
측정하지 않은 것은 안다고 할 수 없습니다 (회고)
제가 오래 설명해온 내용이 측정 한 번에 뒤집혔습니다. 코드는 맞았고 설명이 틀렸어요.
아직 없는 행은 잠글 수 없습니다 (Lock 전용 테이블과 Unique 제약)
SELECT FOR UPDATE로는 신규 INSERT 경쟁을 막지 못합니다. 30번 시도에서 30번 모두 중복이 생겼어요.
@Transactional 안에서 외부 API를 호출하면 안 되는 이유 (커넥션 풀 실측)
트랜잭션 안에서 외부 API를 부르면 6.5배 느려지고, 부하가 조금 오르면 35%가 실패합니다.
비동기로 바꾸자 로그가 끊겼습니다 (MDC와 TaskDecorator)
비동기로 바꾸자 traceId가 200건 전부 끊겼습니다. 그리고 오염을 막는 장치가 제가 생각한 코드가 아니었어요.
PostgreSQL에서 UUID를 CHAR(36)으로 저장하고 있었습니다
PostgreSQL에서 UUID를 CHAR(36)으로 저장하면 공간은 1.74배, 조인은 1.76배 손해입니다.
Redis 조회수를 DB로 옮길 때 증가분이 사라지는 문제 (Lua 델타 차감)
Redis 조회수를 DB로 옮길 때 DEL을 쓰면 16.85%가 유실됐습니다. 읽은 만큼만 DECRBY 하면 0건이 됩니다.
Circuit Breaker와 Retry, 어느 쪽을 바깥에 둘 것인가 (Resilience4j 중첩 순서)
Resilience4j에서 CB와 Retry의 중첩 순서를 바꿔 실측했습니다. 재시도로 살아나는 오류 50건 중 32건이 차단기 때문에 실패했어요.
공지 목록 조회를 고치다가 네 번 갈아엎었습니다 (OSIV, BatchSize, Fetch Join, 페이지네이션)
OSIV를 끄자 예외가 터졌고, BatchSize와 Fetch Join을 거쳐 DTO 프로젝션까지 갔습니다. 쿼리 수는 유일한 지표가 아니었어요.