모든 글 · 3쪽
전체 글 124편 중 25–36번째 글이에요. 최신 글이 앞에 있어요.
3쪽 글 목록
124편 중 25–36
트랜잭션 안에서 외부 API 를 부르지 마라
결제사가 조금 느려졌을 뿐인데 결제와 상관없는 화면까지 우리 서비스가 통째로 멈췄어요. 트랜잭션 안에서 외부 API 를 부른 게 원인이었죠. 왜 그런지와 호출을 밖으로 빼는 법을 다뤄요.
JSON 컬럼은 스키마를 미루는 빚이다
요구사항이 자주 바뀌어 JSON 컬럼에 속성을 몰아넣었더니, 1년 뒤엔 어떤 키가 있는지 아무도 몰라요. 조회도 느려졌고요. 빨리 가려던 선택이 빚이 되는 과정과 갚는 순서를 정리했어요.
대량 적재 뒤 쿼리가 느려지면 — ANALYZE 와 낡은 통계
데이터를 대량으로 넣은 직후부터 쿼리가 느려졌다가 시간이 지나면 저절로 나아요. 그래서 원인을 못 찾고 다음 적재 때 또 반복되죠. 옵티마이저가 낡은 통계로 계획을 세우는 문제를 다뤄요.
인덱스가 있는데 안 타는 이유
인덱스를 만들었는데 쿼리는 그대로 느리고, 개발 DB 에선 잘 타던 인덱스를 운영에서만 안 타요. 옵티마이저가 인덱스를 못 쓰는 경우와 일부러 안 쓰는 경우를 가려내는 순서를 정리했어요.
대량 DELETE 가 복제를 무너뜨린다
오래된 로그를 정리하려고 천만 행을 한 번에 지웠더니, 복제 지연이 수십 분으로 뛰고 디스크는 오히려 늘었어요. 대량 삭제가 왜 사고가 되는지와 안전하게 나눠 지우는 법을 정리했어요.
소프트 삭제(deleted_at)가 느려지는 이유 — 부분 인덱스와 유니크 재설계
지운 데이터를 실제로 지우지 않고 표시만 해 뒀더니, 2년 뒤 테이블의 70%가 삭제된 행이 됐어요. 조회가 점점 느려지는 이유와 탈퇴한 이메일로 재가입이 막히는 문제를 함께 풀어요.
서머타임에 배치가 두 번 돌거나 건너뛴다
한국은 서머타임이 없지만, 해외 결제사 리포트를 받는 순간 1년에 두 번 배치가 건너뛰거나 두 번 돌아요. 로컬 시각을 믿으면 생기는 정산 사고와 안전하게 스케줄 잡는 법을 정리했어요.
REPEATABLE READ, MySQL 과 PostgreSQL 은 다르다 — 격리 수준
같은 REPEATABLE READ 인데 MySQL 과 PostgreSQL 에서 동작이 달라요. DB 를 옮기면 코드는 그대로인데 결과가 바뀌는 이유죠. 이름은 같고 보장은 다른 격리 수준을 DB 별로 비교했어요.
안 쓰는 인덱스 찾는 법 — pg_stat_user_indexes 로 지워도 되는지 판단하기
느릴 때마다 인덱스를 하나씩 더하다 보니 테이블 하나에 열두 개가 됐어요. 조회는 그대로인데 쓰기는 느려졌고요. 안 쓰는 인덱스를 찾는 법과 지워도 되는지 판단하는 기준을 정리했어요.
운영 중 인덱스 추가 — CREATE INDEX CONCURRENTLY 로 쓰기 막지 않기
운영 중에 인덱스 하나를 추가했더니 몇 분 동안 주문이 안 들어왔어요. 스테이징에선 1초 만에 끝났던 작업이에요. 쓰기를 막지 않고 인덱스를 만드는 방법과 그때 조심할 점을 다뤄요.
pgbouncer transaction 모드가 깨는 prepared statement·SET
커넥션을 아끼려고 pgbouncer 설정 하나를 바꿨더니 앱이 가끔 이상해져요. 다시 보내면 성공해서 재현도 안 되고요. 세션에 걸어 둔 설정이 조용히 사라지는 이유와 피하는 법을 정리했어요.
서비스 목표(SLO)는 장애 전에 정한다 — 기준 문장과 에러 버짓
사용자는 느리다는데 평균 응답 시간은 평소와 같아서, 30분째 장애가 맞는지부터 따지고 있어요. 무엇이 정상인지 평소에 한 문장으로 정해 두는 법과, 그 기준을 배포 판단에 쓰는 법을 알 수 있어요.
조건에 맞는 글이 없어요. 브루니가 숨었나 봐요.