푸으름

✏️ 배경발생 상황: 새 마이그레이션 파일이 있는 배포에서 리허설용 MySQL 컨테이너를 새로 띄우고, 준비됐는지 폴링 확인한 뒤 운영 DB 덤프를 복원하는 단계.원인: 준비 확인이 소켓 방식(mysql -uroot -e "SELECT 1")인데, mysql:8.0 컨테이너가 뜰 때 초기화용 임시 서버가 잠깐 떴다 꺼지고 그다음 진짜 서버가 뜸. 폴링이 임시 서버가 살아있는 타이밍에 걸리면 "준비 완료"로 착각하고 바로 복원을 시도 → 그 사이 임시 서버는 꺼져서 ERROR 2002로 실패.해결 방법: 준비 확인을 TCP 방식으로 변경.간결하고 명확한 RCA였다. 참고로 이 readiness 체크는 원래 mysqladmin ping을 쓰다가, 실제 인증까지는 보장하지 않는다는 걸 알고 한 번 mysql ..

✏️ 배경서버에서 5xx 에러가 나면 ServerErrorAlertService가 Discord webhook으로 알림을 쏘도록 이미 되어 있었다. 에러 시간, 요청 엔드포인트, 상태 코드, 클라이언트 정보, 에러 메시지, 스택트레이스(1,000자 제한)까지 알림 자체는 꽤 충실했다. 문제는 그 다음이었다. 알림을 보고 "아, 이거 원인이 뭐지"를 확인하려면 Grafana(Loki)에 들어가서 시간대랑 엔드포인트만 갖고 로그를 눈으로 훑어야 했다. 트래픽이 몰리는 시간대인 경우 같은 엔드포인트로 수십 건이 찍힐 수 있기 때문에, 알림에 찍힌 그 요청 하나를 정확히 짚어내는 게 사실상 불가능했다. 인프라를 다시 들여다보니 필요한 재료는 이미 다 있었다. 로깅 쪽 (logback-spring.xml) - p..

✏️ 들어가며Spring에서 캐시를 쓸 때 @Cacheable, @CacheEvict 정도는 금방 외워진다. "조회할 때 캐시부터 확인한다", "변경되면 캐시를 지운다"까지는 한 줄로 설명할 수 있다. 문제는 그다음이다. @Cacheable을 붙이면 대체 어디에 저장되는지, Redis인지 로컬 메모리인지, CacheManager는 무슨 역할을 하는지까지 가면 설명이 흐릿해진다. @Cacheable / @CacheEvict / @CachePut 세 어노테이션의 동작부터 시작해서, Spring Cache 추상화가 CacheManager를 거쳐 실제로 Redis나 Caffeine 같은 저장소에 어떻게 연결되는지, 그리고 이 어노테이션들이 내부적으로 AOP Proxy로 동작한다는 것까지 이어서 정리했다. ✏️..

✏️ 들어가며실시간 GPS 트래킹 기능의 좌표 저장 로직을 리팩토링한 이슈(#277)를 처리하면서, 단순해 보였던 "batch insert 전환" 작업이 코드 리뷰를 거치며 어떻게 다듬어졌는지 정리한다. 단순히 "이렇게 고쳤다"가 아니라, 왜 그렇게 판단했는지, 리뷰에서 뭘 지적받았는지, 되돌린 결정은 무엇이었는지까지 흐름 그대로 남겨둔다. ✏️ 1. 배경 - GPS 트래킹은 어떻게 저장되는가먼저 전체 흐름을 짚고 가야 문제를 이해하기 쉽다.클라이언트가 WebSocket(STOMP)으로 GPS 좌표를 서버에 전송한다.TrackingGpsPublisher가 이 좌표를 Redis Stream(tracking:gps)에 publish한다.TrackingStreamConsumer가 스트림을 consume해..