골든 시그널
고친 사람 github-actions[bot]
골든 시그널은 서비스가 지금 멀쩡한지를 네 값만 보고 가늠하게 해 줍니다. 지연, 트래픽, 오류, 포화 넷입니다. 재는 값이 수백 가지여도 사용자가 겪는 문제는 대개 이 넷에 먼저 나타납니다.
쉽고 빠른 이해
골든 시그널은 서비스 상태를 볼 때 맨 먼저 보는 신호 넷입니다. 응답이 느려졌나, 요청이 얼마나 들어오나, 실패한 응답이 늘었나, 자원이 한계에 가까운가입니다.
이 넷이 정해져 있지 않으면 장애가 났을 때 무엇부터 볼지 매번 다시 고르게 됩니다. 화면에 그래프가 수십 개 떠 있어도 어느 것이 사용자의 불편을 뜻하는지 가리기 어렵습니다.
어떻게 쓰나:
- 서비스 하나를 정해 넷을 나란히 잽니다
- 화면 맨 위에 넷을 놓고 세부 그래프는 그 아래에 둡니다
- 사람을 깨우는 알림은 되도록 이 넷에서 만듭니다
대가는 넷이 원인을 알려 주지 않는다는 것입니다. 어디가 아픈지는 보여 주지만 왜 아픈지는 다른 값을 더 봐야 합니다.
상세
응급실에 실려 온 환자에게 의사가 맨 먼저 재는 값이 있습니다. 체온, 맥박, 호흡, 혈압 넷입니다. 이 넷으로 병명을 알아내지는 못하지만 지금 위급한지, 어디부터 봐야 하는지는 정해집니다.
서비스에도 그런 넷이 있다는 것이 골든 시그널입니다.
이 이름은 구글의 SRE(Site Reliability Engineering, 사이트 신뢰성 엔지니어링) 책이 붙였습니다. 잴 수 있는 것이 넷뿐이라면 이 넷을 재라는 뜻입니다. SRE 는 서비스가 약속한 수준으로 돌아가게 만드는 일을 다루는 분야입니다.
넷을 미리 정해 두는 까닭이 있습니다. 서비스 하나에서 잴 수 있는 값은 수백 가지입니다. 무엇이 중요한지 정해 두지 않으면 장애가 났을 때 무엇부터 볼지 매번 다시 고르게 되고, 그 고르는 시간이 곧 사용자가 기다리는 시간이 됩니다.
넷이 각각 묻는 질문
넷은 서로 다른 질문 하나씩을 맡습니다. 질문이 겹치지 않아서 하나가 멀쩡해도 다른 셋이 문제를 드러낼 수 있습니다.
| 신호 | 묻는 것 | 흔히 재는 값 |
|---|---|---|
| 지연 | 요청 하나를 처리하는 데 얼마나 걸리나 | 요청이 들어와 응답이 나가기까지의 시간 |
| 트래픽 | 요청이 얼마나 들어오나 | 초당 요청 수 |
| 오류 | 요청 가운데 얼마나 실패하나 | 실패한 응답의 비율 |
| 포화 | 자원이 한계까지 얼마나 찼나 | 메모리나 디스크가 찬 정도 |
표에서 앞의 셋은 사용자가 보낸 요청을 세어 얻습니다. 마지막 포화만 요청이 아니라 서비스가 가진 자원을 재서 얻습니다. 세 번째 신호가 재는 실패한 응답의 비율은 오류율이라고 부릅니다.
성공과 실패를 갈라 재는 지연
지연을 잴 때 흔히 걸리는 함정이 하나 있습니다. 실패한 요청은 대개 빨리 끝납니다. 연결을 거절하거나 값을 확인하다 곧바로 되돌아오기 때문입니다.
그래서 성공과 실패를 섞어 평균을 내면 오류가 늘어난 순간에 지연이 오히려 좋아 보입니다. 빨리 끝난 실패가 평균을 끌어내립니다. 성공한 요청의 지연과 실패한 요청의 지연은 갈라서 잽니다.
평균 하나만 보는 것도 위험합니다. 대부분이 빨리 끝나면 오래 걸린 몇몇은 평균에 묻힙니다. 그래서 오래 걸린 쪽에서 몇 번째에 있는 값이 얼마인지를 보는 백분위수를 함께 씁니다.
포화가 낯선 까닭
넷 가운데 포화만 성격이 다릅니다. 나머지 셋은 사용자가 겪은 것을 재지만 포화는 서비스 안의 자원이 얼마나 찼는지를 잽니다.
무엇을 재는지는 서비스마다 다릅니다. 메모리가 먼저 바닥나는 서비스가 있고, 커넥션 풀이 먼저 마르는 서비스가 있습니다. 커넥션 풀은 데이터베이스로 나가는 연결을 미리 만들어 두고 빌려 쓰는 묶음입니다. 가장 먼저 바닥나는 자원 하나를 골라 그것의 찬 정도를 봅니다.
포화를 보는 값은 다른 셋보다 앞서 움직입니다. 지연과 오류는 사용자가 이미 겪은 뒤에 오르지만 포화는 곧 그렇게 되리라는 것을 미리 알려 줍니다.
넷이 번지는 순서
넷은 따로 노는 값이 아닙니다. 부하로 생기는 장애는 대개 아래 순서로 번집니다.
flowchart TD
A["요청이 몰린다 · 트래픽"] --> B["자원이 차오른다 · 포화"]
B --> C["요청이 기다린다 · 지연"]
C --> D["기다리다 끊긴다 · 오류"]
그림을 거꾸로 읽으면 어디를 볼지가 정해집니다. 오류가 늘었는데 지연도 함께 늘었다면 그 앞의 포화부터 봅니다. 오류만 늘고 지연과 포화가 잠잠하다면 부하가 아니라 코드나 의존 서비스 쪽을 의심합니다.
이 순서가 언제나 성립하지는 않습니다. 잘못 나간 배포는 포화 없이 오류만 늘립니다.
이 넷이 쓰이는 대시보드와 알림
먼저 대시보드의 맨 윗줄입니다. 넷을 위에 두고 아래로 갈수록 서버별·구성 요소별 그래프를 둡니다. 위에서 이상을 보고 아래로 내려가며 원인을 좁히는 순서가 화면 배치에 담깁니다.
다음은 알림 규칙입니다. 사람을 깨우는 알림은 되도록 이 넷에서 만듭니다. 자원 하나가 잠깐 튀었다는 이유로 알림을 걸면 사용자에게 아무 일도 없는데 사람이 깨는 일이 잦아집니다.
서비스가 약속한 수준을 정할 때도 출발점이 됩니다. 어느 값을 얼마로 지킬지 정하려면 먼저 무엇을 잴지 골라야 하는데, 그 후보가 대개 이 넷 안에 있습니다.
골든 시그널이 답하지 못하는 범위
골든 시그널이 답하는 것은 어디가 아픈지까지입니다. 왜 아픈지는 다른 값과 로그를 더 봐야 나옵니다. 넷만 띄워 놓고 원인이 안 보인다고 하는 것은 이 신호에 없는 것을 바라는 것입니다.
재는 단위도 정해져 있습니다. 서비스 하나씩 재도록 만들어진 신호라 여러 서비스를 한데 묶어 평균을 내면 한 서비스만 망가진 것이 묻힙니다.
요청과 응답이라는 왕복이 없는 일에는 그대로 안 맞습니다. 큐에 쌓인 일감을 꺼내 처리하는 작업이 그렇습니다. 그럴 때는 밀린 일감의 수와 처리가 얼마나 뒤처졌는지를 지연과 트래픽 대신 봅니다.
관련 항목
골든 시그널을 이루는 네 신호
신호를 숫자로 만드는 값
메트릭 · 백분위수 · 히스토그램 · 처리량 · 응답 시간 · 가용성
신호를 띄우고 알리는 도구
대시보드 · 알림 · 모니터링 · Prometheus · Grafana · 로그
신호로 서비스 수준을 약속하는 체계
서비스 수준 지표 · 서비스 수준 목표 · 서비스 수준 계약 · 오류 예산
같은 생각에서 나온 다른 신호 묶음
포화가 차오르는 자원
커넥션 풀 · 스레드 풀 · 메모리 · 디스크 · 큐 적체
신호가 나빠진 뒤 밟는 대응 절차
이 신호가 속하는 상위 분야
다른 이름: golden signals · four golden signals · 네 가지 황금 신호