조용한 개발 노트

46편에서는 CI/CD 파이프라인에 Rollback·Canary 판단을 자동화해 배포 안정성을 높이는 방법을 정리했습니다.이번 글에서는 그 자동화가 제대로 동작하기 위한 전제,“장애를 얼마나 빨리, 얼마나 정확히 감지할 수 있는가”를 다루겠습니다.핵심은 단순합니다. 지표는 적게, 의미는 분명하게입니다.1. 관측(Observability)의 세 축모니터링은 보통 다음 세 가지로 구성됩니다.Metrics – 숫자(상태)Logs – 사건(원인)Tracing – 흐름(경로)이 세 가지를서로 보완적으로설계해야, “왜 느린지/왜 터졌는지”를 빠르게 연결할 수 있습니다.2. Metrics – 무엇을 반드시 봐야 할까Spring 서비스에서 반드시 봐야 할 핵심 지표는 다음 네 가지입니다.요청 성공률 (Error Rat..

33편에서는 Web 계층 장애를 요청 흐름 기준으로 분해해 어디서 문제가 생겼는지 찾는 방법을 살펴봤습니다.이번 글에서는 그 흐름을APM 지표와 1:1로 연결해 숫자로 병목을 증명하는 방법을 정리해보겠습니다.핵심은 단순합니다. APM의 각 구간이 Spring Web 요청 흐름의 어느 단계인지 정확히 매핑하는 것입니다.1. APM을 볼 때 가장 흔한 오해많은 경우 APM을 이렇게 봅니다.“응답 시간이 느리다”“DB는 빠른데 왜 느리지?”하지만 APM의 진짜 가치는“어디에서 시간이 쓰였는지”를 알려주는 데 있습니다.이를 위해서는 Spring Web 요청 흐름과 APM 구간을 머릿속에서 정확히 겹쳐야 합니다.2. 요청 흐름과 APM 구간 기본 매핑Spring Web 요청 흐름을 APM 구간과 매핑하면 대략 다..