무엇을 언제 보는가? 장애 조사의 순서
| 신호 | 답하는 질문 | 성격 |
|---|---|---|
| 메트릭 | 지금 문제가 있나? | 집계 수치, 저비용과 장기 보관 |
| 트레이스 | 이 요청의 어디가 느렸나? | 요청 단위 경로, 표본 수집 |
| 로그 | 그때 정확히 무슨 일이 있었나? | 단건 이벤트, 고비용과 상세 |
메트릭 이상 감지 -> 트레이스로 느린 구간 특정 -> 로그로 원인 확인
Q.메트릭, 로그, 트레이스를 각각 언제 사용하나요?
| 축 | 답하는 질문 | 특징 |
|---|---|---|
| 메트릭 | 지금 문제가 있는가 | 집계된 숫자. 싸다. 오래 보관한다 |
| 트레이스 | 어디가 느린가 | 한 요청의 구간별 시간. 서비스 경계를 넘는다 |
| 로그 | 왜 그런가 | 개별 사건의 상세. 비싸다. 짧게 보관한다 |
순서가 정해져 있습니다. 메트릭으로 감지하고, 트레이스로 위치를 찾고, 로그로 원인을 확인합니다.
| 단계 | 실제로 보는 것 |
|---|---|
| 메트릭 | 결제 API p99 가 3초로 올랐다 |
| 트레이스 | 느린 요청을 열어 보니 외부 호출에 2.8초를 쓴다 |
| 로그 | 그 시각 로그에 타임아웃 재시도 기록이 있다 |
거꾸로 하면 비쌉니다. 로그부터 뒤지면 무엇을 찾는지 모르는 상태로 대량의 텍스트를 검색하게 됩니다.
세 축을 잇는 것이 요청 식별자입니다. 트레이스 id 를 로그에 남겨 두면 특정 요청의 로그만 모아 볼 수 있습니다.
흔한 실수: 로그에 지표 성격의 정보를 남기고 그것을 집계해 쓰는 것. 비용이 수십 배 들고 조회가 느립니다. 숫자는 메트릭으로 남깁니다.
Q.장애가 발생했을 때 어떤 순서로 조사하나요?
원인 규명보다 영향 축소가 먼저입니다.
| 순서 | 하는 일 |
|---|---|
| 1 | 범위 확인. 전체인가 일부인가, 언제부터인가 |
| 2 | 최근 변경 확인. 배포, 설정 변경, 트래픽 급증 |
| 3 | 되돌릴 수 있으면 되돌린다 |
| 4 | 의존성 확인. 우리 문제인가 남의 문제인가 |
| 5 | 자원과 지표 확인. CPU, 메모리, 커넥션, 큐 길이 |
| 6 | 트레이스와 로그로 원인 특정 |
| 7 | 복구 확인, 그리고 회고 |
2번과 3번이 가장 효율적입니다. 장애의 상당 부분은 방금 바꾼 것 때문이고, 되돌리면 원인을 몰라도 복구됩니다. 먼저 멈춘 피를 막고, 부검은 나중에 합니다.
1번에서 시작 시각을 정확히 잡는 것이 중요합니다. 그 시각 전후의 배포와 이벤트만 보면 후보가 크게 줄어듭니다.
흔한 실수: 원인을 알아야 고칠 수 있다고 생각하는 것. 되돌리기가 가능하면 원인 규명보다 먼저 합니다. 사용자 영향 시간이 그만큼 짧아집니다.
Q.로그 비용을 줄이면서 조사 가능성을 유지하는 방법은?
전부 남기거나 전부 버리는 것이 아니라, 정보량 대비 비용이 나쁜 것부터 줄입니다.
| 방법 | 내용 |
|---|---|
| 수준 정리 | 정상 흐름의 debug 를 끈다. 대개 여기서 대부분이 줄어든다 |
| 샘플링 | 성공 요청은 일부만, 실패는 전부 남긴다 |
| 구조화 | 문장 대신 필드로 남겨 필요한 것만 저장하고 검색을 빠르게 한다 |
| 중복 제거 | 같은 오류가 초당 수천 건이면 묶어서 세고 대표만 남긴다 |
| 계층 보관 | 최근은 검색 가능한 저장소, 지난 것은 값싼 보관소로 |
| 지표로 대체 | 횟수만 필요한 것은 메트릭으로 옮긴다 |
두 번째가 조사 가능성을 지키는 핵심입니다. 문제가 생긴 요청은 대개 실패하거나 느린 요청이라, 오류와 느린 요청을 전량 남기고 정상만 줄이면 조사에 필요한 것은 대부분 남습니다.
트레이스 id 를 남겨두면 샘플링해도 특정 요청은 끝까지 추적됩니다.
흔한 실수: 보관 기간만 줄이는 것. 비용은 줄지만 며칠 뒤 발견되는 문제를 조사할 수 없게 됩니다. 양을 줄이고 기간은 남기는 쪽이 낫습니다.
Q.알림을 어떤 기준으로 설계하나요?
기준은 하나입니다. 사람이 지금 무언가 해야 하는가. 아니면 알림이 아니라 대시보드입니다.
| 좋은 알림 | 나쁜 알림 |
|---|---|
| 사용자 영향을 나타낸다 | 내부 지표 하나가 임계를 넘었다 |
| 조치할 것이 있다 | 보고 넘기는 것밖에 없다 |
| 원인 후보가 좁혀진다 | 무엇을 봐야 할지 모른다 |
| 드물게 온다 | 매일 온다 |
그래서 증상 기준으로 겁니다. CPU 80%는 증상이 아닙니다. 오류율 상승과 p99 악화가 증상입니다. CPU 가 높아도 사용자가 괜찮으면 알릴 일이 아닙니다.
| 항목 | 판단 |
|---|---|
| 지속 시간 조건 | 순간 튐에 울리지 않게 몇 분 이상 지속을 조건에 넣는다 |
| 심각도 분리 | 즉시 대응과 다음 근무일 확인을 나눈다 |
| 묶음 | 한 원인이 여러 알림을 만들면 하나로 합친다 |
| 정기 점검 | 안 울리는 알림과 무시되는 알림을 지운다 |
흔한 실수: 알림을 많이 걸어 안전하다고 느끼는 것. 자주 울리면 사람이 무시하기 시작하고, 그때부터는 진짜 알림도 묻힙니다. 울렸을 때 반드시 본다는 신뢰가 알림의 가치입니다.
먼저 스스로 답해보고 아래 답변과 견줘보세요. 막히는 부분은 문제로 확인할 수 있어요.
읽었으면 문제로 확인해보세요
성능 최적화 문제를 풀면 틀린 문제가 자동으로 노트에 쌓입니다. 가입 없이 5문제를 먼저 풀어볼 수도 있어요.