대시보드는 녹색인데도 고객들은 결제가 실패했다고 불평하고 있습니다. 이 위치에 있었다면 모니터링과 관찰 가능성의 차이점을 이미 이해하고 계실 것입니다. 모니터링은 확인하려고 생각한 것만 확인했는데 이번 실패는 새로운 것입니다.

이 가이드에서는 마케팅 용어 없이 두 가지 아이디어를 모두 설명하고 경고부터 근본 원인까지 하나의 가상 사건을 따라갑니다. 로그, 추적 및 숫자는 프로세스를 설명하기 위해 고안되었습니다. 또한 공급업체와 실무자는 이 선을 다르게 긋고 일부는 이를 부분적으로 마케팅 구별로 간주한다는 점도 알아야 합니다. 우리는 실용적인 부분에 중점을 둡니다.

짧은 대답

모니터링은 활동입니다. CPU, 오류율, 디스크 공간 등 무엇을 관찰할지 미리 결정하고 경고를 트리거하는 임계값을 설정합니다. “내가 걱정했던 일이 일어날까?”라고 대답합니다.

관찰 가능성은 시스템의 속성입니다. 이 용어는 외부 출력에서 ​​시스템의 내부 상태를 얼마나 잘 추론할 수 있는지 설명하는 제어 이론에서 유래되었습니다. 실제로는 다음과 같이 대답합니다. “예상하지 못한 문제를 포함하여 무슨 일이 일어나고 있고 왜 일어나고 있습니까?”

자동차를 생각해 보세요. 대시보드의 경고등이 모니터링 중입니다. 이는 일련의 알려진 문제를 다룹니다. 누군가가 엔진의 모든 부분에 대해 새로운 질문을 할 수 있도록 하는 정비사의 전체 진단 포트는 관찰 가능성에 더 가깝습니다.

모니터링과 관찰 가능성을 나란히 놓고

이것은 둘 중 하나를 선택하는 것이 아닙니다. 언제 살펴봐야 하는지 알려주는 알림이 여전히 필요합니다.

모니터링만으로는 충분하지 않은 이유

하나의 서버에 하나의 애플리케이션을 사용하면 문제가 발생할 수 있는 목록이 상당히 짧아서 모두 볼 수 있습니다. 최신 시스템에는 수십 개의 서비스, 대기열, 타사 API와 함께 왔다 갔다 하는 컨테이너가 있을 수 있습니다. 실패는 아무도 예측하지 못한 조합, 즉 하나의 지역, 하나의 고객 유형, 특정 앱 버전 및 단일 느린 종속성의 조합이 됩니다.

생각하지 못한 질문에 대해서는 대시보드를 미리 작성할 수 없습니다. 나중에 물어볼 수 있는 데이터가 필요합니다.

로그, 측정항목, 추적

이러한 세 가지 유형의 원격 측정을 종종 관찰 가능성의 기둥이라고 합니다. 각각은 다른 질문에 대답합니다.

측정항목

http_requests_total{service="checkout", status="500"} 1832
http_request_duration_seconds{service="checkout", quantile="0.95"} 2.4

메트릭은 저장 비용이 저렴하고 쿼리 속도가 빠르므로 대시보드 및 경고에 이상적입니다. 많은 지표 시스템에서 사용자 ID와 같이 카디널리티가 높은 레이블을 사용하면 비용이 급격히 증가할 수 있으므로 주의하세요.

흔적

추적은 서비스 전체에서 하나의 요청을 따릅니다. 각 단계는 시작 시간과 기간이 포함된 범위입니다.

POST /checkout                      2410 ms
├─ auth-service: verify token         18 ms
├─ cart-service: load cart            42 ms
├─ pricing-service: calculate       2290 ms   <-- slow
│  └─ SELECT coupons ...            2265 ms
└─ payment-service: not reached

추적을 통해 느린 단계가 분명해지며, 이는 별도 서비스의 별도 로그에서 확인하기가 매우 어렵습니다.

로그

로그는 한 순간에 발생한 일에 대한 세부 정보를 제공합니다. 잠시 후에 이를 유용하게 만드는 방법을 살펴보겠습니다.

사건 둘러보기

다음은 가상의 예를 통해 조각들이 서로 맞춰지는 방식입니다.

모니터링 처리 1단계. 그 이후의 모든 것은 관찰 가능성이었습니다. 각 질문이 이전 답변에서 어떻게 나온 것인지 확인하세요. “오늘의 캠페인 모바일 앱 쿠폰 쿼리”에 대한 대시보드를 미리 구축할 수 있는 사람은 아무도 없습니다. 수정 자체에 대해서는 SQL 쿼리 최적화 가이드에서 그러한 계획을 읽는 방법을 보여줍니다.

더 나은 로그

일반 텍스트 로그는 사람의 눈을 위해 만들어지기 때문에 쿼리하기가 어렵습니다. 구조화된 로그는 시스템이 필터링할 수 있는 필드를 사용합니다.

# Hard to search
ERROR Payment failed for user 42 after 3 tries

# Easy to search
{"level":"error","event":"payment_failed","user_id":"42",
 "attempts":3,"provider":"acme","trace_id":"a1b2c3","duration_ms":2410}

두 번째 양식을 사용하면 “지난 시간 동안 공급자당 몇 건의 실패가 발생했습니까?”라고 즉시 질문할 수 있습니다. trace_id 필드는 접촉한 모든 서비스에 걸쳐 전체 요청에 로그 라인을 연결하므로 특히 중요합니다.

비밀번호, 토큰, 카드번호를 절대 기록하지 말고 개인정보를 잘 관리하세요. 가이드에서 설명한 대로 JWT는 로그에서 읽는 사람이라면 누구나 재사용할 수 있습니다.

황금빛 신호

무엇을 모니터링해야 할지 모르시나요? Google의 사이트 안정성 엔지니어링(Site Reliability Engineering) 책에서는 사용자 대면 시스템에 대한 네 가지 신호를 제안합니다.

부하 테스트와 스트레스 테스트에서 보여준 것처럼 평균은 느린 요청을 숨기므로 지연 시간에 백분위수를 사용합니다.

사람들이 신뢰하는 경고

알림이 항상 실행되면 사람들은 알림 읽기를 중단합니다. 좋은 것은 몇 가지 규칙을 따릅니다.

• 사용자가 느끼는 증상에 대한 경고입니다. “2% 이상의 결제 오류”가 “85%의 CPU”를 능가합니다. 누구에게도 해를 끼치지 않는 높은 CPU는 누구도 깨워서는 안 됩니다.
• 모든 경고를 실행 가능하게 만드세요. 아무도 아무것도 할 필요가 없으면 대시보드 항목으로 만들거나 제거하세요.
• 런북 링크. 응답자에게 어디를 보고 무엇을 시도할지 알려줍니다.
• 정기적으로 검토하세요. 지난 달에 무시된 알림을 삭제하거나 수정하세요.

서비스 수준 목표

SLO는 “사이트는 빠르고 안정적이어야 한다”를 “30일 동안 결제 요청의 99.9%가 성공한다”와 같은 측정 가능한 목표로 바꿉니다. 이는 오류 예산으로 알려진 약 0.1%의 실패를 허용합니다. 많이 남아있으면 더 빨리 배송할 수 있고, 거의 다 소모되면 신뢰성을 우선으로 할 수 있습니다. 이는 배송 속도와 안정성 사이의 논쟁을 해결하는 데 유용한 방법입니다.

OpenTelemetry 및 도구

OpenTelemetry는 원격 분석을 생성하고 내보내기 위한 공급업체 중립적인 오픈 소스 표준입니다. Cloud Native Computing Foundation의 프로젝트입니다. 이를 계측하면 나중에 코드를 다시 작성하지 않고도 백엔드를 변경할 수 있습니다. 스토리지나 대시보드 제품 자체는 아니므로 다음 제품과 페어링하세요.

이러한 제품은 자주 변경되므로 현재 기능과 가격을 직접 확인하세요. 데이터 양에 따라 비용이 빠르게 증가할 수 있으므로 샘플링을 사용하고 보존 제한을 설정하세요.

시작하는 방법

1. 가장 중요한 서비스에 대한 골든 신호부터 시작하세요.
2. 사용자가 발견한 증상에 대해 하나 또는 두 개의 알림을 추가합니다.
3. 구조화된 로그로 전환 각 줄에 요청 ID가 있습니다.
4. 자동 계측은 많은 공통 프레임워크를 다룰 수 있으므로 OpenTelemetry를 사용하여 기본 사용자 여정에 추적을 추가합니다.
5. 배포를 그래프에 연결하여 CI/CD 파이프라인의 릴리스로 인해 변경이 발생했는지 확인할 수 있습니다.
6. 각 사건으로부터 교훈을 얻습니다. 각 사건이 끝난 후 어떤 데이터를 사용하면 더 빨리 해결할 수 있었는지 물어보고 이를 추가하세요.

하나의 서비스를 갖춘 소규모 팀에는 거대한 플랫폼이 필요하지 않습니다. 기본 지표, 양호한 로그 및 몇 가지 경고만으로 충분할 수 있습니다. 추적은 서비스 수가 증가함에 따라 유지됩니다.

일반적인 실수

• 도구를 구입하고 이를 관찰 가능성이라고 부릅니다. 가치는 좋은 도구 사용과 데이터 사용 방법에서 나옵니다.
• 세 개의 기둥을 체크리스트로 취급합니다. 연결할 방법이 없는 데이터를 분리하면 탭을 통해 검색하게 됩니다. 공유 ID가 중요합니다.
• 모든 것을 수집합니다. 필터링되지 않은 원격 측정은 비용이 많이 들고 소음이 추가됩니다.
• 대시보드가 ​​너무 많습니다. 아무도 열지 않는 수백 개의 보기보다 신뢰할 수 있는 몇 개의 보기가 있습니다.
• 테스트를 대체한다고 생각합니다. 출시 전에는 여전히 테스트가 필요합니다. 하지만 Canary 릴리스는 이러한 신호와 잘 어울립니다.

마무리

모니터링을 통해 문제가 발생했음을 알 수 있으며, 관찰 가능성을 통해 원인을 알아낼 수 있습니다. 실제 테스트는 간단합니다. 익숙하지 않은 문제가 나타나면 새 코드를 제공하지 않고도 원인을 찾을 수 있습니까? 다음에 사건이 발생하면 대답할 수 없는 모든 질문을 적어 두십시오. 그 목록이 로드맵입니다.

자주 묻는 질문

계속 학습하세요