분류
배포·관측
무중단 배포, 헬스체크, 설정·기능 플래그, 로그·트레이스·알림·SLO 처럼 내보내고 지켜보는 일을 모았어요.
16편 · 마지막 글 2026.08.12
배포·관측 글
16편 중 1–12
서비스 목표(SLO)는 장애 전에 정한다 — 기준 문장과 에러 버짓
사용자는 느리다는데 평균 응답 시간은 평소와 같아서, 30분째 장애가 맞는지부터 따지고 있어요. 무엇이 정상인지 평소에 한 문장으로 정해 두는 법과, 그 기준을 배포 판단에 쓰는 법을 알 수 있어요.
기능(피처) 플래그는 지우지 않으면 부채가 된다 — 정리 규칙
기능 플래그를 2년 쓰다 보니 200개가 됐고, 무엇이 켜져 있는지 아무도 몰라요. 지우자니 무섭고요. 플래그가 왜 안 지워지고 쌓이는지, 만들 때부터 지울 계획을 세우는 법을 정리했어요.
카나리 배포가 못 잡는 장애 5가지
카나리에서 30분을 지켜보고 통과한 배포가 전체로 넓힌 뒤에 터졌어요. 통과했으니 배포 탓은 아니라고 믿어 원인 찾기도 늦어졌고요. 카나리가 못 보는 다섯 가지와 그걸 덮는 법을 알 수 있어요.
샘플링이 장애 요청만 버린다 — 꼬리 샘플링(tail sampling)
추적 비용을 줄이려고 1% 만 남겼더니, 장애 때 찾는 실패 요청은 두세 건밖에 안 남았어요. 흔한 건 남고 드문 건 사라지거든요. 요청이 끝난 뒤 결과를 보고 남길 것을 고르는 법을 담았어요.
로그는 많은데 못 찾는다 — 구조화 로그와 trace_id
로그는 초당 수천 줄씩 쌓이는데, 장애 때 특정 사용자의 요청 하나를 못 찾아 몇 시간을 헤맸어요. 남기는 것과 찾을 수 있는 건 달라요. 나중에 찾을 수 있게 로그를 미리 설계하는 법을 정리했어요.
분산 추적이 큐·스레드 풀에서 끊길 때 — 추적 문맥 전파
분산 추적을 붙였는데 하필 시간이 가장 오래 걸리는 큐·워커 구간에서 추적이 끊겨요. 문맥이 스레드에 묶여 있어서예요. 큐와 스레드를 넘어서도 요청을 끝까지 따라가게 만드는 법을 알 수 있어요.
설정 변경이 코드 배포보다 위험한 이유 — 설정도 코드처럼
콘솔에서 타임아웃 값 하나 바꿨을 뿐인데 서비스가 무너졌어요. 되돌리려니 이전 값이 뭐였는지 아무도 몰랐고요. 설정 변경이 코드 배포보다 위험한 이유와 설정을 코드처럼 다루는 법을 정리했어요.
롤백이 안 되는 배포 — 코드는 되돌려도 데이터는 안 돌아온다
문제가 생겨 이전 버전으로 되돌렸는데 장애가 그대로예요. 데이터는 이미 새 형식으로 바뀌었고 알림도 나간 뒤였거든요. 되돌릴 수 없는 배포를 미리 가려내고 안전하게 내보내는 법을 알 수 있어요.
무중단 배포에서 컬럼 이름 바꾸기 — 확장·이전·정리 5단계
컬럼 이름 하나 바꾸고 배포했을 뿐인데 운영에서 몇 분간 오류가 쏟아졌어요. 스테이징에선 멀쩡했고요. 배포 중 옛 코드와 새 스키마가 함께 도는 구간을 안전하게 넘는 다섯 단계를 담았어요.
알림이 하루 200개면 아무도 안 본다 — 알림 피로 줄이기
알림을 꼼꼼히 걸었더니 하루 200개씩 와서 아무도 안 보게 됐어요. 진짜 장애 알림도 그 사이에 묻혔고요. 알림이 많을수록 못 보게 되는 이유와, 사람을 부를 만한 알림만 남기는 기준을 정리했어요.
라벨 하나가 모니터링을 통째로 죽인다 — 지표 카디널리티 폭발
디버깅하기 쉬우라고 지표에 사용자 ID 라벨을 붙였더니, 몇 시간 뒤 모니터링 시스템이 메모리를 다 쓰고 죽었어요. 라벨 하나가 왜 그렇게 무거운지, 넣어도 되는 라벨을 가르는 법을 알 수 있어요.
새로 뜬 인스턴스가 먼저 죽는다 — 워밍업과 배포 직후 DB 부하
부하가 올라 서버를 늘렸는데 새로 뜬 인스턴스만 유독 느리고, 늘릴수록 상황이 나빠져요. 같은 이미지인데도요. 새 인스턴스에 없는 게 무엇인지, 미리 데워 두는 방법을 담았어요.
조건에 맞는 글이 없어요. 브루니가 숨었나 봐요.