이제는 아무도 무슨 일이 일어나고 있는지 모른다

Source: Dev.to

Introduction

우리는 그 어느 때보다 관측성을 갖추고 있습니다. 그럼에도 불구하고 왜 모든 사고가 혼란으로 시작할까요?

지난 화요일 오후 2시 47분, 우리 API 지연 시간이 급증했습니다.

작은 급증이 아니라 — 전체 팀을 깨우는 급증이었습니다.

우리는 기대할 수 있는 모든 것을 갖추고 있었습니다:

• 지연 시간 증가를 보여주는 Grafana 대시보드
• 느린 데이터베이스 쿼리를 가리키는 Datadog 트레이스
• 정상적인 CPU와 메모리를 보여주는 CloudWatch 메트릭
• 오류 비율에 따라 작동하는 PagerDuty
• 그래프와 스크린샷으로 가득 찬 Slack

놀랐던 것은 사고가 발생했다는 것이 아니라,
모든 도구가 설계대로 정확히 작동했음에도 여전히 중요한 질문에 답할 수 없었다는 점입니다:

실제로 무슨 일이 일어나고 있는가?

배포가 요청을 배치하는 방식을 바꿨다는 것을 파악하는 데 약 18 분이 걸렸습니다. 그로 인해 요청당 지연 시간이 약간 증가했고, 이것이 재시도 로직을 트리거해 데이터베이스에 중복 쿼리가 폭주하게 되었습니다.

데이터는 모두 있었지만, 나는 그 이야기를 볼 수 없었습니다.

우리는 잘못된 문제를 해결했다

지난 10년 동안 가시성 도구는 수집 및 시각화에 매우 능숙해졌습니다.

• 거의 모든 것을 계측할 수 있습니다.
• 거의 모든 것을 그래프로 시각화할 수 있습니다.
• 전체 분산 시스템에 걸쳐 요청을 추적할 수 있습니다.

하지만 우리는 여기서 대부분 멈추었습니다.

우리는 다음과 같은 질문에 답하는 도구를 만들었습니다:

“이 메트릭은 무엇을 하고 있나요?”

하지만 다음 질문에는 답하지 못했습니다:

“실제로 무슨 일이 일어나고 있나요?”

그것들은 다른 질문입니다.

• 첫 번째는 데이터 문제입니다.
• 두 번째는 추론 문제입니다.

실제로 인시던트를 디버깅하는 방법

인시던트 대응이 실제로 어떻게 진행되는지 살펴보겠습니다.

1. 브라우저 탭을 몇 개 열기: Grafana, Datadog, 로그, 클라우드 콘솔, 서비스 대시보드, 그리고 몇 달 전에 만들어졌지만 업데이트되지 않은 노트북 등.

2. 질문하기 시작하기:

   • 최근에 무엇이 바뀌었나요?
   • 언제부터 문제가 시작됐나요?
   • 같은 시기에 또 무엇이 바뀌었나요?
   • 이 일들 사이에 어떤 연관성이 있을까요?

당신은 메트릭을 읽는 것이 아니라 조각들로부터 이야기를 재구성하고 있습니다.

“배포는 2시 30분에 이루어졌고… 지연 시간이 2시 32분에 급증했어… 그때 어떤 서비스였지… 그 배포에서 무엇이 바뀌었지… 재시도에 영향을 줬을까… 잠깐, 재시도 양이 평소보다 훨씬 많아…”

이것이 인시던트 대응의 실제 인지 작업입니다: 차트를 단순히 보는 것이 아니라 차트를 이해로 전환하는 과정입니다.

Source: …

모호성 문제

같은 신호가 매우 다른 설명을 지원할 수 있다는 점이 이 문제를 어렵게 만든다.

다음과 같은 상황을 관찰했다고 가정해 보자:

• 14:30에 배포가 이루어짐
• 14:32에 지연 시간이 증가함
• 그 직후 오류율이 상승함
• 재시도량이 급증함
• 인프라 메트릭은 정상 유지

무슨 일이 일어난 걸까?

스토리 1

배포에 버그가 포함되었다. 잘못된 코드 때문에 지연 시간이 증가했고, 오류가 뒤따랐다. 롤백한다.

스토리 2

지연이 재시도를 유발했고, 이는 하위 시스템에 부하를 증폭시켰다. 인프라가 고갈된 것은 아니지만, 재시도 증폭으로 인해 간헐적인 실패가 발생했다. 재시도 동작을 조정한다.

스토리 3

배포가 요청 특성을 변경하여 모델‑서빙 레이어에서 실질적인 처리량을 감소시켰다. CPU가 한계가 아니라 처리량이 한계다. 배칭이나 워밍‑업 동작을 수정한다.

같은 데이터. 다른 시각. 다른 해결책.

차이는 신호가 아니라, 질문하는 방식에 있다.

내가 탐구하고 있는 것

나는 이 문제를 한 번만이 아니라 그 뒤에 있는 패턴을 오랫동안 생각해 왔다.

우리는 사고가 발생했을 때 인간이 머리 속에서 서사 구조를 만들기를 기대한다. 이는 비용이 많이 들고 오류가 발생하기 쉬우며, 시스템이 더 분산될수록 점점 어려워진다.

“신호를 서사로 전환하는” 작업을 엔지니어링 문제로 다룬다면 어떨까?

인간의 판단을 대체하려는 것이 아니라, 다음과 같은 잡무를 돕기 위함이다:

• 시간적 상관관계 식별
• 가능한 인과 관계 제안
• 여러 타당한 해석 제시
• 모호성을 명시적으로 드러내기

나는 이 탐구를 Coherence라고 부른다.

현재는 다듬어진 도구가 없다. 아직 초기 단계의 생각이며, 이것을 깔끔하게 구현할 수 있을지, 실제 환경의 잡음에 의해 무너질지 모른다. 그 불확실성이 내가 이 주제에 관심을 갖는 이유 중 하나다.

이것이 나쁜 생각일 수 있는 이유

Here are real risks.

• 잘못된 자신감을 만들 수 있습니다. 생성된 서사는 틀렸음에도 불구하고 권위 있게 들릴 수 있습니다.
• 중요한 세부 정보를 숨길 수 있습니다. 모든 형태의 요약은 정보를 잃게 되며, 때로는 가장 중요한 정보가 사라집니다.
• 잘못된 문제를 해결하고 있을 수 있습니다. 실제 문제는 해석이 아니라, 우리의 시스템이 너무 복잡해서 전혀 이해할 수 없다는 것일지도 모릅니다.
• 사람들이 이를 신뢰하지 않을 수 있습니다. 프로덕션 사고를 디버깅하고 있다면, 자동화된 설명을 신뢰하는 것은 큰 도약입니다.

이러한 우려에 대한 명확한 답은 없습니다.

왜 나는 여전히 탐구할 가치가 있다고 생각하는가

현재 접근 방식, 즉 인간에게 방대한 데이터를 제공하고 스트레스 상황에서 완벽하게 추론하도록 요구하는 방식은 확장성이 없습니다.

• 시스템은 복잡성이 계속 증가하고 있습니다.
• *“여기에 데이터가 있습니다”*와 “무슨 일이 일어나고 있는지” 사이의 격차가 점점 벌어지고 있습니다.

우리는 아마도 시각화에만 국한되지 않고 추론 수준에서 작동하는 도구가 필요할 것입니다.

이 특정 아이디어가 실패하더라도, 문제 자체는 시간을 투자할 가치가 있습니다.

이러한 고통을 느꼈거나 이 프레이밍이 잘못됐다고 생각한다면, 진심으로 의견을 듣고 싶습니다.

무엇이 실제로 당신을 “inciden