day-log

RDS PostgreSQL 16→17 업그레이드 새벽 작업기 — replication slot에 또 당했다지난주 토요일 새벽 2시. RDS PostgreSQL 16에서 17로 메이저 업그레이드를 돌렸다. 작업 자체는 한 시간 안에 끝날 줄 알았는데, 결국 새벽 6시까지 책상에 앉아있었다. 또 replication slot이었다.분명히 사전 점검 체크리스트에 "logical replication slot 확인" 항목을 넣어뒀다. 그런데도 당했다. 어떻게 당했는지, 그리고 이번에 알게 된 게 뭔지 적어둔다. 다음에 또 같은 데서 미끄러지지 않으려고.사전 점검은 했는데작업 전 점검은 평소대로 돌렸다.SELECT slot_name, plugin, slot_type, database, active, restart..

오늘 알게 된 건 아닌데, 의외로 안 걸어둔 팀이 꽤 있더라. idle_in_transaction_session_timeout 얘기다.내용은 단순하다. BEGIN 떠놓고 클라이언트가 다음 쿼리 안 보내고 가만히 있는 세션을 지정 시간 지나면 서버가 죽인다. 기본값이 0(비활성)이라 그냥 둔 클러스터가 많은데, 한 번 사고 겪고 나면 절대 안 빼게 된다.왜 굳이 켜야 하나문제는 두 갈래다.첫째, 락 점유. 누가 어딘가에서 UPDATE 치고 COMMIT 안 한 채 자리 비우면 그 행은 계속 잠긴 채로 다른 쿼리들이 줄을 선다. 우리 팀에선 예전에 어드민 페이지에서 BEGIN; UPDATE ... WHERE id=?; 까지 가놓고 응답 안 돌아온 세션 하나 때문에 결제 트래픽 P99가 8초까지 튀었다.둘째, ..

지난주 일요일 새벽 2시쯤 알림이 왔다. 결제 API 쪽에서 prepared statement "S_3" does not exist 에러가 분당 수백 건씩 찍히고 있었다. 그 전날 PgBouncer를 1.25.1로 올린 게 화근이었다. 안 그래도 PG16.11에 PgBouncer 1.25.1 조합에서 prepared statement 관련 버그 리포트가 올라온 게 있었는데, 우리도 그 케이스에 정확히 걸려든 거였다.이번 글은 그날 새벽 내가 뭘 보고 뭘 했고, 최종적으로 어떻게 마무리됐는지에 대한 기록이다. 깔끔한 해결책 같은 건 아직 없다. 워크어라운드로 일단 막아둔 상태.배경: 왜 transaction mode + prepared statement를 켰나작년에 우리 팀은 PgBouncer를 1.21로..

지난주 화요일 새벽 2시, 메이저 버전 업그레이드를 한다고 멘션이 와있었고 나는 콘솔 앞에 있었다. 사전 리허설은 두 번 했다. 스위치오버 30초, 길어야 1분. 그런데 실제 작업은 7분 걸렸다. 7분이라는 숫자 자체보다, 그 7분 동안 회사 메인 서비스의 결제 API가 절반쯤 죽어있었다는 게 문제였다.이 글은 그날 무슨 일이 있었는지, 그리고 다음에 같은 작업을 또 한다면 뭘 다르게 할지에 대한 기록이다. AWS 공식 문서나 베스트 프랙티스 글들이 말하지 않는 것들이 좀 있더라.시작은 평범했다대상은 Aurora PostgreSQL 14.10 클러스터다. 14가 2026년 11월에 standard support가 끝난다는 공지가 작년 말에 나왔고, 우리는 6월 안에 16으로 올리기로 했다. 17이 아니라..

지난주 화요일 오후, 모니터링 알람이 울렸다. PgBouncer 앞단의 connection 사용량이 평소 대비 3배 가까이 튀어 있었고, 어플리케이션 쪽 P99 레이턴시는 슬슬 200ms를 넘기고 있었다. 트래픽은 평소 수준. 이상한 점은 RDS Postgres의 active connection 수가 거의 변동이 없다는 거였다. 즉, 클라이언트 → PgBouncer 사이에서 뭔가 막혀 있다는 뜻이다.이번 글은 그날 밤 새벽 2시까지 잡고 있던 이 문제를 어떻게 추적했는지, 그리고 결국 prepared statement와 transaction pooling이 충돌하던 지점을 어떻게 풀어냈는지에 대한 기록이다. 결론부터 말하면, 우리가 두 달 전에 한 PgBouncer 버전 업그레이드가 진짜 원인이었다.처음..

지난주 화요일 새벽 2시 47분알림이 울렸다. 캐시 레이어 P99가 평소 8ms 수준에서 4초까지 튀었다는 것이다. 멘탈이 나갔다. 침대에서 노트북을 펴는데 손이 약간 떨렸다.원인은 Redis Cluster slot resharding이었다. 평소처럼 야간 저트래픽 시간대에 노드 두 대를 추가하고 슬롯을 옮기는 작업이 돌아가고 있었는데, 이게 그냥 평범하게 끝나지 않았다. 몇 시간 동안 로그와 메트릭을 뒤지면서 알게 된 것들을 정리해둔다.우리 환경24노드 Redis Cluster (마스터 12, 레플리카 12). EKS 위에서 StatefulSet으로 운영 중이고, 키 수는 약 1.2억개, 메모리는 노드당 평균 28GB. 샤드 수가 늘어 일부 노드가 메모리 한계에 다다라서 노드를 추가하기로 했다. 새 노..

지난주 새벽 3시, 알람으로 깨서 백업 잡이 또 깨진 걸 확인했다. PVC 30개 짜리 워크로드 백업이 두 시간 째 매달려 있었고, node-agent 데몬셋의 메모리는 8Gi를 찍고 OOM. 이게 벌써 이번 분기 들어 세 번째다. 1.14에서 1.15로 올린 다음부터 백업 패턴이 이상해졌고, 솔직히 말하면 우리 팀은 한 달 가까이 이 마이그레이션을 우습게 봤다.원인은 단순하지 않았다. Velero 1.15에서 데이터 업로드 액션이 node-agent에서 떨어져 나와 DataUpload 단위 마이크로서비스 파드로 분리됐는데, 그 변화가 우리 클러스터 토폴로지와 안 맞았다. 이 글은 그 한 달간의 삽질을 정리한 노트다.처음에 뭐가 바뀐 건지 제대로 안 봤다릴리즈 노트를 한 번은 읽었다. "data move..

지난주 화요일 새벽 3시, 슬랙 알림이 미친 듯이 울렸다. 결제 DB의 P99 레이턴시가 평소 12ms에서 280ms로 튀어 올랐다. 폰을 더듬어 잡고 일어나면서 머리가 멍했다. 트래픽은 한산한 시간대인데 왜?처음엔 단순한 락 경합인 줄 알았다. pg_stat_activity 봤는데 long-running 쿼리도 없고, pg_locks도 깨끗했다. 근데 디스크 IOPS는 평소 대비 4배. 뭔가 백그라운드에서 디스크를 갈아먹고 있는 게 분명한데 보이질 않았다. 멘탈이 살짝 나갔다.pg_stat_io를 켰다작년에 PG16으로 올리면서 pg_stat_io 뷰를 알게 됐었는데, 평상시엔 잘 안 보던 거였다. 이번 같은 상황에서 진가를 발휘하는 뷰다. context 컬럼에 bulkread, bulkwrite, v..

왜 굳이 켜야 하나PgBouncer 1.21에서 transaction pooling 모드에서도 prepared statement를 쓸 수 있게 된 게 벌써 2년 가까이 됐다. 우리 팀도 작년 가을에 1.22로 올리고 max_prepared_statements를 켰는데, 그동안 마주친 함정 몇 개가 있어서 정리해둔다. 비슷한 마이그레이션을 앞두고 있는 분들에게 도움이 됐으면 한다.이 글은 "PgBouncer는 뭔가요"부터 시작하지 않는다. 이미 transaction 모드로 PgBouncer를 운영 중이고, 애플리케이션이 prepared statement를 쓰고 있거나 쓰고 싶은 상황을 가정한다.JDBC, asyncpg, pgx, psycopg3 같은 모던 드라이버는 기본적으로 Parse/Bind/Execu..