골든 시그널

골든 시그널은 서비스가 지금 사용자에게 멀쩡한지를 네 값으로 가늠하게 해 줍니다. 지연, 트래픽, 오류, 포화 넷입니다. 잴 수 있는 값이 많아도 이 넷부터 재기로 정해 두는 것입니다.

쉽고 빠른 이해

골든 시그널은 서비스를 볼 때 맨 먼저 보기로 정해 둔 값 넷입니다. 응답에 얼마나 걸리나, 요청이 얼마나 들어오나, 실패한 요청이 얼마나 되나, 서비스가 얼마나 찼나입니다.

잴 수 있는 값은 많습니다. 이것저것 다 재고 알림을 걸면 모니터링이 복잡해져 고치기 어려워집니다. 넷만 잘 재도 서비스를 꽤 덮을 수 있습니다.

어떻게 쓰나:

1. 사용자를 상대하는 서비스에서 넷을 잽니다
2. 대시보드 화면에 넷을 띄웁니다
3. 넷 가운데 하나가 나빠지면 사람을 부릅니다. 포화는 나빠지기 직전에 부릅니다

대가도 있습니다. 서비스가 얼마나 찼는지는 서비스마다 무엇을 잴지 따로 정해야 합니다. 데이터 처리 파이프라인처럼 데이터가 얼마나 묵었는지가 중요한 시스템은 넷 말고 다른 값을 봐야 합니다.

상세

응급실에 실려 온 환자에게 의료진이 맨 먼저 재는 값이 있습니다. 체온, 맥박, 호흡, 혈압입니다. 이 넷으로 병명을 알아내지는 못합니다. 그래도 지금 위급한지와 어디부터 볼지는 정해집니다.

서비스에도 그런 넷을 정해 두자는 결정이 골든 시그널입니다. 구글에서 서비스의 신뢰성을 맡는 SRE(Site Reliability Engineering, 사이트 신뢰성 엔지니어링) 팀들이 모니터링과 알림의 원칙을 정리한 글에서 나온 이름입니다.

넷만 고르라는 결정

결정은 한 문장입니다. 사용자를 직접 상대하는 시스템에서 지표를 넷만 잴 수 있다면 이 넷을 재라는 것입니다.

넷으로 줄이는 까닭은 모니터링의 무게에 있습니다. 감시할 값과 알림을 계속 얹으면 모니터링도 깨지기 쉽고 고치기 어려운 짐이 될 수 있습니다. 무엇을 감시할지 고를 때 단순함을 먼저 보라는 것이 이 원칙의 방향입니다.

네 신호가 재는 값

넷은 각자 다른 것을 잽니다. 아래 표의 HTTP(HyperText Transfer Protocol)는 웹에서 요청과 응답을 주고받는 규약입니다.

이 문서에서 신호는 네 가지 가운데 하나를 가리킵니다. 지표는 그 신호를 보려고 모으는 수를 가리킵니다. 초당 HTTP 요청 수는 트래픽 신호를 보는 지표 하나입니다.

오류의 세 갈래 가운데 정책상 실패는 약속에서 나옵니다. 응답 코드가 성공이어도 약속한 시간을 넘겼으면 실패로 셉니다.

넷이 쓰이는 화면과 알림

네 신호가 먼저 쓰이는 곳은 대시보드와 알림입니다.

대시보드는 서비스에 대한 기본 물음에 답하는 화면입니다. 보통 네 신호를 어떤 형태로든 담습니다.

알림은 사람을 부르는 장치입니다. 네 신호를 모두 재고 그중 하나가 문제일 때 사람을 부른다고 해 봅니다. 그러면 서비스는 적어도 꽤 괜찮게 감시됩니다. 포화만은 문제가 되기 직전에 부릅니다.

대가

네 신호를 감시의 중심에 둔 서비스가 치르는 값을 봅니다. 하나는 넷이 요청을 받는 시스템을 전제로 한다는 것입니다. 다른 하나는 포화를 서비스마다 새로 정해야 한다는 것입니다.

요청을 받는 시스템이라는 전제

네 신호 가운데 지연과 오류는 요청에서 출발해 정의됩니다. 지연은 요청 하나에 걸린 시간입니다. 오류는 실패한 요청의 비율입니다. 결정 문장도 사용자를 직접 상대하는 시스템을 대상으로 적혀 있습니다.

서비스 종류가 바뀌면 보는 값도 바뀝니다. 서비스 수준 목표에 쓸 지표를 SLI(Service Level Indicator, 서비스 수준 지표)라고 부릅니다. SLI 를 고를 때는 대개 서비스 종류마다 아래처럼 갈립니다.

이 표와 네 신호는 쓰임이 다릅니다. 네 신호는 감시할 값을 고른 것입니다. 이 표는 서비스 수준 목표에 쓸 지표를 고른 것입니다. 이 표가 보여 주는 것은 서비스 종류에 따라 중요한 값이 달라진다는 점입니다.

데이터 처리 파이프라인을 서비스로 굴릴 때 세우는 목표에는 데이터 신선도가 있습니다. 「데이터의 X% 를 Y 시간 안에 처리한다」나 「가장 오래된 데이터가 Y 시간보다 묵지 않는다」처럼 적습니다.

데이터 정확성도 목표로 세웁니다. 청구 파이프라인에서 정확성이 깨지면 고객에게 요금이 더 붙거나 덜 붙을 수 있습니다.

네 신호 가운데 데이터가 얼마나 묵었는지를 재는 신호는 없습니다. 신선도는 네 신호 밖에서 따로 재야 합니다.

서비스마다 새로 정하는 포화

포화는 무엇을 재야 하는지가 애플리케이션마다 다릅니다. 많은 시스템은 사용률 100% 에 닿기 전에 성능이 떨어집니다. 그래서 사용률 목표를 꼭 따로 정해 둬야 합니다.

무엇으로 포화를 잴지는 서비스가 얼마나 단순한가에 따라 갈립니다. 아주 단순한 서비스는 부하 테스트에서 얻은 고정값 하나로 포화를 가늠해도 충분할 수 있습니다. 요청의 복잡도를 바꾸는 매개변수가 없고 설정도 드물게 바뀌는 서비스입니다. 「한 번만 쓰는 값을 하나 달라」나 「전역에서 유일하고 계속 커지는 정수를 달라」 같은 요청만 받는 서비스가 그렇습니다.

대부분의 서비스는 그렇지 않습니다. 이런 서비스는 최댓값이 알려진 간접 지표를 써야 합니다. CPU(Central Processing Unit, 중앙처리장치) 사용률이나 네트워크 대역폭이 그런 지표입니다.

복잡한 시스템에서는 서비스가 부하를 얼마나 더 견디나를 재서 포화를 보완할 수 있습니다. 지금 트래픽의 두 배를 제대로 감당하나, 10% 더만 감당하나, 아니면 지금보다도 적게 감당하나를 묻는 것입니다.

예시

네 신호를 기본 지표로 내주는 제품 셋을 봅니다. 대상은 Linkerd, Google Cloud Endpoints, Istio 입니다. 제품마다 넷 가운데 무엇을 어떤 지표 이름으로 내주는지를 봅니다.

세 제품의 표에 오르는 신호는 지연, 트래픽, 오류 셋입니다. Cloud Endpoints 는 포화가 빠진다고 밝혀 둡니다.

Linkerd

Linkerd 는 HTTP, HTTP/2, gRPC(구글이 만든 원격 프로시저 호출 프레임워크) 트래픽을 개발자가 손대지 않아도 자동으로 잽니다. 기본으로 기록하는 요청량·성공률·지연 분포 셋을 「golden」 지표라고 부릅니다.

아래 표의 백분위수는 값을 작은 것부터 늘어놓았을 때 그 순번에 있는 값입니다. 99번째 백분위수 지연이면 요청의 99% 가 그 시간 안에 끝났다는 뜻입니다.

경로는 클라이언트가 보내는 요청을 묶어 세는 단위입니다. 재시도도 이 단위에 걸어 둡니다. 클라이언트와 백엔드 사이에 따로 서 있는 중계 장치를 가리키는 말이 아닙니다.

성공률은 오류를 뒤집어 적은 값입니다. 실패한 요청의 비율 대신 성공한 요청의 비율을 봅니다. 낮은 백분위수는 시스템의 평소 성능을 보여 줍니다. 높은 백분위수는 튀는 요청을 잡는 데 도움이 됩니다.

같은 성공률도 재시도 앞에서 재느냐 뒤에서 재느냐에 따라 값이 다릅니다. linkerd viz stat-outbound 명령은 성공률을 경로 단위와 백엔드 단위로 나눠 보여 줍니다. 백엔드는 요청을 받아 처리하는 개별 서비스 쪽입니다.

재시도를 건 경로라면 두 값이 갈립니다. 경로 단위 값은 재시도를 거친 뒤의 성공률입니다. 클라이언트가 느끼는 값이 이것입니다. 백엔드 단위 값은 재시도 전의 성공률입니다. 재시도에 가려진 서비스의 문제가 이 값에서 드러날 수 있습니다.

flowchart TD
    A["클라이언트"] -->|"요청 · 실패하면 다시 보낸다"| C["백엔드"]
    A -.- M1["경로 단위 성공률 · 재시도를 거친 뒤 · 클라이언트가 느끼는 값"]
    C -.- M2["백엔드 단위 성공률 · 재시도 전"]

초당 요청 수도 같은 방식으로 나뉩니다. 경로 단위는 재시도 뒤의 요청 수입니다. 백엔드 단위는 재시도 전의 요청 수입니다.

Google Cloud Endpoints

Cloud Endpoints 는 구글 클라우드에서 API(Application Programming Interface, 프로그램끼리 부르는 접점)를 내놓을 때 쓰는 서비스입니다. 사용자가 API 를 부르면 요청과 응답 정보를 로그로 남기고 지표를 자동으로 모읍니다. 네 신호 가운데 지연, 트래픽, 오류 셋을 추적합니다.

Endpoints 가 모은 지표는 구글 클라우드의 감시 서비스인 Cloud Monitoring 에서도 보입니다. 알림은 거기서 겁니다. 알림 조건을 만들 때 고르는 칸은 조건 종류(Condition Type), 자원 종류(Resource Type), 지표입니다.

트래픽과 오류는 같은 지표 Request count 를 씁니다. 응답 코드 분류를 5xx 로 거르면 그 수가 오류가 됩니다.

Endpoints 지표로 알림을 걸 수 없는 신호는 포화 하나뿐입니다. 포화를 보려면 무엇을 재야 하는지가 애플리케이션마다 다릅니다. 단서가 하나 붙습니다. 서비스를 가장 먼저 옥죄는 자원이 네트워크 입출력이라면 Endpoints 지표 가운데 하나로 알림을 걸 수 있을지도 모릅니다. 어느 지표인지는 자료에 없습니다(미확인).

Istio

Istio 는 HTTP, HTTP/2, gRPC 트래픽에 대해 표준 지표를 내보냅니다. 그 가운데 둘과 레이블 하나로 세 신호를 만들 수 있습니다.

아래 표의 낱말 몇을 먼저 풉니다. 프록시는 서비스 앞에서 요청을 대신 받아 넘기는 중계 프로그램입니다. 레이블은 지표에 붙여 값을 갈라 볼 수 있게 하는 이름표입니다. COUNTER 는 줄지 않고 오르기만 하는 정수입니다. DISTRIBUTION 은 값의 구간마다 빈도를 대응시킨 것입니다.

요청 수를 응답 코드별로 가르면 실패한 요청의 비율을 구할 수 있습니다.

운영

네 신호를 서비스에서 모을 때 정할 값과 걸리는 곳을 봅니다. 지연을 어떻게 나눠 모으나, 얼마나 자주 재나, 응답 코드가 놓치는 오류는 무엇인가, 포화를 얼마나 일찍 아나, 의존 서비스는 어떻게 보나, 알림을 어떻게 두나입니다.

성공과 실패의 지연을 나눠 모으기

성공한 요청의 지연과 실패한 요청의 지연은 갈라서 잽니다. 데이터베이스나 다른 핵심 백엔드와 연결이 끊겨 생긴 HTTP 500 은 아주 금방 응답될 수 있습니다. 이런 500 을 전체 지연에 섞으면 계산이 사람을 오도할 수 있습니다.

그렇다고 실패를 걸러 버리기만 하면 안 됩니다. 오래 걸린 실패는 금방 끝난 실패보다 더 해롭습니다. 실패한 요청의 지연도 따로 추적해야 하는 까닭입니다.

평균 대신 분포로 모으기

평균 지연만 보면 오래 걸린 소수의 요청, 곧 꼬리가 가려집니다. 초당 1,000 요청에 평균 지연이 100ms 인 웹 서비스에서도 요청의 1% 는 쉽게 5초가 걸릴 수 있습니다.

꼬리는 백엔드가 여럿일 때 더 커집니다. 사용자의 페이지 하나가 이런 백엔드 여럿의 응답을 다 기다린다고 해 봅니다. 백엔드마다 오래 걸리는 1% 가 있습니다. 백엔드가 늘수록 그중 하나가 그 1% 에 걸릴 확률이 커집니다. 그러면 백엔드 하나의 99번째 백분위수가 프론트엔드 응답의 중앙값(50번째 백분위수)이 되기 쉽습니다.

평균과 꼬리를 가르는 가장 단순한 방법은 지연 값을 하나하나 모으는 대신 지연 구간별 요청 수를 세는 것입니다. 구간은 0~10ms, 10~30ms, 30~100ms, 100~300ms 처럼 나눕니다. 구간마다 그 안에 끝난 요청이 몇 개인지 셉니다. 이렇게 모은 값은 히스토그램으로 그릴 수 있습니다.

구간 경계를 대략 3배씩, 곧 지수로 늘리면 요청의 분포를 쉽게 볼 수 있는 경우가 많습니다.

재는 간격

시스템의 측면마다 재는 간격을 달리합니다. CPU 부하를 1분 단위로 보면 높은 꼬리 지연을 일으키는 급등이 꽤 오래 이어져도 안 보입니다.

반대로 너무 자주 잴 필요가 없는 값도 있습니다. 1년 다운타임 9시간 이하(연간 가용성 99.9%)를 목표로 하는 웹 서비스라면 성공 응답 200 을 분에 한두 번보다 자주 확인하는 것은 아마 불필요하게 잦습니다. 같은 목표에서 하드디스크가 얼마나 찼는지를 1~2분에 한 번보다 자주 확인하는 것도 아마 필요 없습니다.

CPU 부하를 초 단위로 모으면 흥미로운 데이터가 나올 수 있습니다. 그러나 그렇게 잦은 측정은 모으고 저장하고 분석하는 비용이 아주 클 수 있습니다.

해상도는 높아야 하지만 값이 아주 빨리 전해질 필요는 없을 때가 있습니다. 그럴 때는 서버 안에서 먼저 표본을 모아 비용을 줄일 수 있습니다. 바깥 시스템은 그 분포를 시간에 걸쳐, 또는 서버 여럿에 걸쳐 모아 묶습니다. 예를 들면 이렇습니다.

1. 지금 CPU 사용률을 매초 기록합니다
2. 5% 단위로 나눈 구간 가운데 맞는 구간의 수를 매초 하나 올립니다
3. 그 값을 1분마다 묶습니다

이렇게 하면 수집과 보관에 아주 큰 비용을 들이지 않고도 짧은 CPU 과열을 볼 수 있습니다.

응답 코드가 놓치는 오류

응답 코드만으로 모든 실패를 나타낼 수는 없습니다. 그럴 때는 응답 코드와 별도로 서비스 안에서만 쓰는 두 번째 규약을 두어야 할 수 있습니다. 일부만 실패하는 경우를 추적하려는 것입니다.

실패의 종류마다 잡는 방법이 크게 다를 수 있습니다. 로드 밸런서에서 HTTP 500 을 세면 완전히 실패한 요청은 꽤 잘 잡을 수 있습니다. 엉뚱한 내용을 내보내고 있다는 것은 끝에서 끝까지 도는 시스템 테스트만 잡아냅니다. 앞 표의 암묵적 실패(200 인데 내용이 틀림)가 이 경우입니다.

포화를 일찍 보는 값

지연이 오르는 것은 흔히 포화를 앞질러 알려 줍니다. 1분 같은 짧은 창에서 99번째 백분위수 응답 시간을 재면 포화를 아주 일찍 알아챌 수 있습니다.

곧 닥칠 포화의 예측도 포화에 듭니다. 「이대로면 데이터베이스가 4시간 안에 하드디스크를 채운다」 같은 값입니다.

의존 서비스의 네 신호

서비스 자신이 안 바뀌어도 그 서비스가 부르는 의존 서비스가 바뀌거나 탈이 날 수 있습니다. 바로 부르는 의존 서비스의 응답도 감시해야 하는 까닭입니다.

의존 서비스마다 요청과 응답의 바이트 크기, 지연, 응답 코드를 내보내는 것이 합리적입니다. 그래프로 그릴 지표를 고를 때는 네 신호를 염두에 둡니다. 지표에 레이블을 더 달면 응답 코드, RPC(Remote Procedure Call, 원격 프로시저 호출) 메서드 이름, 상대 작업 이름으로 쪼개 볼 수 있습니다.

계층이 여럿인 시스템에서는 같은 값이 보는 사람에 따라 뜻이 바뀝니다. 모니터링이 답할 물음 가운데 무엇이 고장났나를 증상이라 부릅니다. 왜 고장났나는 원인이라 부릅니다. 원인은 중간 단계의 것일 수도 있습니다.

데이터베이스 읽기가 오래 걸리게 됐다고 해 봅니다. 데이터베이스를 맡은 SRE 에게 오래 걸리는 읽기는 증상입니다. 웹사이트가 오래 걸리는 것을 보는 프론트엔드 SRE 에게 같은 읽기는 원인입니다.

알림 규칙을 단순하게 두기

요구를 계속 얹으면 모니터링이 아주 복잡해질 수 있습니다. 여러 백분위수와 여러 지표에 지연 임계값마다 알림을 걸게 됩니다. 원인 후보마다 그것을 찾는 코드와 대시보드도 붙습니다. 결국 모니터링도 다른 소프트웨어처럼 깨지기 쉽고 고치기 어려운 짐이 될 수 있습니다.

단순함을 지키려고 감시할 값을 고를 때 세 가지를 따릅니다.

• 실제 장애를 가장 자주 잡는 규칙은 되도록 단순하고 예측 가능하고 믿을 만하게 둡니다
• 드물게 쓰이는 수집·집계·알림 설정은 걷어 낼 후보입니다. 어떤 SRE 팀은 분기에 한 번도 안 쓰이면 그렇게 봅니다
• 모아 두기만 하는 신호도 걷어 낼 후보입니다. 어느 대시보드에도 안 뜨고 어느 알림에도 안 쓰이는 신호입니다

경계

골든 시그널 옆에는 이름이 비슷한 점검법이 있습니다. RED(Rate, Errors, Duration) 방법과 USE(Utilization, Saturation, Errors) 방법입니다. 셋은 무엇마다 재나와 무엇을 재나로 갈립니다.

RED 방법을 만든 사람은 이 방법이 구글 SRE 로 일하며 배운 것에 바탕을 둔다고 밝힙니다. 골든 시그널은 RED 방법과 거의 같습니다. 크게 다른 점은 포화가 하나 더 든다는 것입니다. 그는 포화를 고급 쓰임새로 보고 뺐습니다. 앞의 셋을 익혔다면 포화도 넣으라고 덧붙입니다.

오류를 적는 단위도 다릅니다. RED 방법은 초당 실패한 요청 수로 적습니다. 골든 시그널은 실패한 요청의 비율로 적습니다.

디스크 사용률 90% 와 포화

디스크 하나가 사용률 90% 로 돌고 있습니다. 이 값은 골든 시그널의 포화에 드나.

그 디스크가 서비스에서 가장 빠듯한 자원이라면 듭니다. 골든 시그널의 포화는 서비스가 얼마나 찼는지를 가장 빠듯한 자원을 중심으로 봅니다. 입출력이 빠듯한 시스템이면 입출력을 봅니다. 대부분의 서비스는 CPU 사용률처럼 최댓값이 알려진 간접 지표로 포화를 봅니다.

USE 방법은 같은 값을 포화가 아니라 사용률 칸에 둡니다. USE 방법에서 사용률은 일정 시간 동안 자원이 일하느라 바빴던 정도입니다. 퍼센트로 적고 「디스크 하나가 사용률 90% 로 돌고 있다」가 그 예입니다. USE 방법의 포화는 자원이 처리하지 못해 밀린 일의 정도입니다. 흔히 큐 길이로 적습니다. 「CPU 의 평균 실행 대기열 길이가 4」가 USE 방법의 포화입니다.

같은 「포화」라는 낱말이 두 방법에서 다른 값을 가리킵니다. 골든 시그널의 포화에는 빠듯한 자원의 사용률, 부하를 얼마나 더 견디나, 「4시간 안에 하드디스크를 채운다」 같은 예측이 들 수 있습니다. USE 방법의 포화는 자원 하나에 밀린 일만 가리킵니다.

관련 항목

골든 시그널을 이루는 네 신호

지연 · 트래픽 · 오류율 · 포화

네 신호를 숫자로 담는 지표

메트릭 · 백분위수 · 히스토그램 · 꼬리 지연 · 처리량 · 응답 시간 · 가용성

네 신호를 띄우고 알리는 도구

대시보드 · 알림 · 알림 피로 · 모니터링 · Prometheus · Grafana · 로그

네 신호를 기본 지표로 내주는 제품

Linkerd · Istio · 서비스 메시 · Cloud Endpoints · Cloud Monitoring

네 신호로 서비스 수준을 약속하는 체계

서비스 수준 지표 · 서비스 수준 목표 · 서비스 수준 계약 · 오류 예산

골든 시그널과 견주는 점검법

RED 방법 · USE 방법 · DORA · 성능 분석

골든 시그널이 기대는 모니터링 구분

블랙박스 모니터링 · 화이트박스 모니터링 · 증상 기반 모니터링 · 원인 기반 모니터링

포화가 차오르는 자원

커넥션 풀 · 스레드 풀 · CPU · 메모리 · 디스크 · 네트워크 대역폭 · 큐 적체

네 신호 대신 다른 지표를 쓰는 시스템

데이터 파이프라인 · 배치 처리 · 스트리밍 · 데이터 신선도 · 저장 시스템

네 신호를 재는 시험

부하 테스트 · 종단 간 테스트 · 합성 모니터링

네 신호가 지나가는 요청 경로

로드 밸런서 · 프록시 · 의존 서비스 · RPC · 재시도

신호가 나빠진 뒤 밟는 대응 절차

온콜 · 장애 대응 · 인시던트 · 사후 분석

골든 시그널이 속하는 상위 분야

관측성 · SRE · 신뢰성 · 성능