관측 가능성에서 AIOps까지

1. Monitoring과 Observability

개념 및 차이점

• Monitoring: 미리 정해둔 지표가 정상 범위 내에 있는지 확인하는 작업임.
• Observability: 사전 정의되지 않은 질문에도 데이터로 답을 찾아내는 능력임.
• 질문과 답에 따른 4가지 국면:

1. 대시보드 지표 확인: 질문과 답을 모두 아는 상황임.
2. 긴급 대응: 질문은 알지만 답은 그때그때 찾아야 하는 상황임.
3. 사각지대: 데이터는 존재하나 아무도 들여다보지 않는 영역임.
4. 미지의 영역: 무엇을 물어야 할지조차 모르는 상황으로, Observability가 겨냥하는 핵심 목표임.

관측의 3대 신호 (M.L.T)

• Metric (지표): 시간에 따른 시계열 수치 데이터로, 전체 시스템 상태를 빠르게 파악하는 데 강점이 있음.
• Log (로그): 특정 시점의 사건을 문장으로 기록한 것으로, 개별 사건의 상세 원인 파악에 강함.
• Trace (트레이스): 요청의 이동 경로 및 구간별 소요 시간을 구조화한 것으로, 지연(Latency) 위치 추적에 강함.
• 보완 관계 및 표준 조사 흐름:

1. 지표로 영향 범위 파악
2. 트레이스로 요청 단위 원인 축소
3. 로그로 상세 원인 확인
4. 지표로 전체 영향 재확인

지표 해석 시 고려 요소

• 시간 범위, 라벨 범위(전체 vs 특정 서비스), 분모(분량 대비 실패율), 운영 맥락(배포 직후, 피크 타임 등)을 종합 고려해야 함.
• 지표는 이상 신호만 알려줄 뿐이며, 근본 원인은 로그, 트레이스, 배포/설정 이력을 함께 검토해야 함.

---

2. 지표(Metric)의 종류와 라벨 관리

지표의 3가지 타입

• Counter: 재시작 시 초기화되는 누적값임. 값 자체보다 rate()나 increase()를 통한 최근 증가 속도 파악이 핵심임.
• Gauge: 큐 길이, 메모리 사용률 등 오르내리는 현재 상태값임. 한계값, 정상 범위, 처리량 맥락을 함께 확인해야 함.
• Histogram: 지연시간 등 분포와 백분위수 측정용임. 버킷(Bucket) 경계를 사전에 지정해야 하며 추후 변경이 어려움.

평균의 함정과 백분위수

• 평균값: 소수의 느린 요청이 다수의 정상 값에 묻히는 착시가 발생함.
• 백분위수 (p95, p99): 느린 소수 요청의 경험을 명확히 드러내므로 서비스 지표 설정 시 필수적임.

라벨과 카디널리티 (Cardinality)

• 좋은 라벨: 값의 종류가 고정적이고 적은 필드임 (예: 서비스명, 메서드, 상태 코드).
• 나쁜 라벨: 요청마다 값이 바뀌는 고카디널리티 필드임 (예: 사용자 ID, 요청 ID, 이메일).
• 카디널리티 폭발: 라벨 조합 수가 곱으로 증가하여 데이터 저장 및 조회 비용이 폭증하는 현상임. 운영 중 값 종류가 늘어날 여지가 있는지 사전 반증이 필요함.

---

3. Prometheus & Grafana — 수집부터 알림까지

Prometheus 수집 방식

• Pull 방식 (기본): Prometheus가 대상의 /metrics 엔드포인트를 주기적으로 방문하여 수집함.
• Push 방식 (Pushgateway): 배치 작업처럼 수집 전 워크로드가 종료될 가능성이 있는 경우 사용함.
• 판단 기준: 워크로드의 실행 주기 및 수집 전 소멸 여부임.

수집 상태 진단 (up 지표)

• up = 1: 정상 수집 상태임.
• up = 0: 대식을 발견했으나 수집에 실패한 상태임 (포트/경로 오류 등).
• 빈 결과: 대상 자체가 Prometheus에 등록되지 않은 상태임 (ServiceMonitor selector/라벨 불일치 등).

Alert Rule과 Alertmanager

• Prometheus (Alert Rule): 조건 지속 시간(for)을 검증하여 상태 전이(Inactive $\rightarrow$ Pending $\rightarrow$ Firing)만 담당함.
• Alertmanager: 알림의 라우팅, 그룹핑, 사일런스(음소거) 등 전송 정책을 담당함.
• 좋은 알림 원칙: 단순 수치 변동이 아닌 "사람의 개입이 필요한 상황"에만 알림을 설정하여 알림 피로를 방지함.

Grafana 디버깅 절차

• Explore: 임시 조회 및 디버깅 용도임.
• Dashboard: 지속적인 관측 용도임.
• 대시보드 미출력 시 디버깅 순서: 데이터소스 연결 상태 $\rightarrow$ 쿼리 구문 $\rightarrow$ 조회 시간 범위 순으로 차례로 검증함.

---

4. 로그 파이프라인 (Fluent Bit ~ Loki)

로그 파이프라인 4단계

1. 수집 (Input)
2. JSON 파싱 (Parser)
3. 메타데이터 부착 (Filter)
4. Output 전달 (Loki 등)

• 각 단계별 장애 증상이 명확히 구분되므로 LogQL 쿼리 및 로그 상태를 통해 원인 단계를 논리적으로 추적해야 함.

Loki 라벨과 Fluent Bit DB 옵션

• Loki 라벨: 라벨 조합마다 별도 스트림을 생성함. High-cardinality 필드(trace_id 등)를 라벨로 지정하면 성능이 급격히 저하됨.
• Fluent Bit tail DB 옵션: 오프셋 저장 유무는 로그의 유실 민감도 vs 중복 민감도 간 트레이드오프에 따라 결정함.

---

5. Trace — 분산 시스템 인과관계 추적

Trace의 필요성

• 로그만으로 해결할 수 없는 인과관계, 구간 시간, 서버 간 시계 오차 문제를 Context Propagation(문맥 전파)을 통해 해결함.

Trace 해석 및 주의점

• Waterfall 스팬 분석: 가장 길게 표시된 부모 스팬은 자식 스팬의 대기 시간을 포함하므로, 실제 병목 원인은 가장 안쪽의 자식 스팬일 확률이 높음.
• 동기 vs 비동기: 동기 흐름은 지연이 상위로 전파되는 강결합 구조이고, 비동기 흐름은 큐로 분리되어 결합도는 낮으나 관측 추적이 까다로움.
• 트레이스 분리 설계 원칙: 작업 경계, tail sampling 기술적 한계, 보존 기간, 처리 주체의 독립성에 따라 트레이스를 분리함.
• 한계: 미계측 구간 및 샘플링으로 인해 트레이스가 누락될 수 있으므로, "트레이스 없음"이 "문제 없음"을 의미하지는 않음.

---

6. 관측 설계의 비즈니스 적용

서비스 경로별 관측 설계

• 조회 경로 (검색/카탈로그):
• 주 지표: 서비스별 p99 응답시간
• 보조 지표: 캐시 히트율, Read Replica 지연

• 결제 경로:
• 주 지표: 절대 실패 건수보다 실패율을 우선 측정 (트래픽 증가와 품질 악화 구분)
• 상세 지표: Provider 및 실패 코드를 조합한 지표 구성

설계 태도

• 단일 지표가 감추고 있는 빈틈을 파악하고, 트레이스 및 로그 등 보조 신호로 이를 보완하는 사슬형 설계를 적용해야 함.

---

7. 이상 탐지에서 AIOps까지 (판단 프레임)

판단의 3단계 개념

• Anomaly (이상 패턴): 평소와 다른 패턴인가?
• Incident (인시던트): 사용자/비즈니스에 영향이 발생했거나 임박했는가?
• Alert (알림): 지금 사람이 즉시 개입해야 하는가?
• 데이터/근거가 부족할 경우 "아직 판단할 수 없다"를 정당한 결론으로 수용함.

주요 문제 패턴 진단

• 게임 서버 FPS 저하: 동접자 증가에 따른 정상 부하와 백업 프로세스 실행이 복합 작용한 사례임. 교차 검증 및 데이터 반증이 필수적임.
• 캐시 스탬피드 (Cache Stampede): 키 동시 만료 + 요청 병합 부재 + 워커 풀 포화가 결합하여 20ms 쿼리가 1초 지연으로 증폭되는 현상임.
• CPU 쓰로틀링: 평균 CPU 사용률 지표에 은폐되므로 쓰로틀 전용 지표(container_cpu_cfs_throttled_periods_total 등)를 별도 확인해야 함.

SLI / SLO / SLA / Error Budget

• SLI: 사용자 관점의 서비스 수준 측정 지표임.
• SLO: 내부적으로 달성하고자 하는 목표 수준임.
• SLA: 고객과 계약한 외부 약속으로, SLO보다 완화된 기준을 적용함.
• Error Budget: SLO가 허용하는 실패 허용량으로, 서비스 안정성과 배포 속도 간 트레이드오프를 관리하는 기준임.

인과관계 검증

• 두 지표의 동시 변동이 인과를 의미하지 않음. 반증 테스트 및 제3의 공통 원인(예: 정기 배치 작업) 존재 여부를 의심해야 함.

---

8. 인프라 자동화 및 배포 트러블슈팅

Kafka 컨슈머 랙 진단

• Producer 유입률 일정 + 처리율 저하 + 컨슈머 멤버 수 유지 조건 시, 레코드 1건당 처리 시간이 증가했음을 의미함.
• 디스크 I/O 병목 등 하위 의존성 지연을 원인으로 특정하는 단계적 가설 검증이 필요함.

IaC (Terraform)

• 선언형 방식으로, 최종 상태를 정의하고 plan $\rightarrow$ apply 프로세스를 거침.
• state 파일 내 민감정보 평문 노출 위험이 있으므로 버전 관리 시스템 커밋을 금지함.

Kubernetes 트러블슈팅

• Ingress/ALB 오류: 컨트롤러 이벤트 로그를 통해 생성 경로 상의 병목 지점을 추적함.
• ImagePullBackOff: 아키텍처 불일치, 태그 오타, 인증 정보 누락, Pull Limit 초과, 네트워크 문제 등을 이벤트 메시지 원문으로 구분하여 조치함.

배포 전략 비교

• 롤링 배포: 무중단 배포가 가능하나 신/구 버전이 일시 혼재됨.
• 블루/그린 배포: 버전 일관성을 유지하나 자원을 2배 소비함.

---

마무리

• 단일 지표나 신호에 의존한 성급한 결론을 배제함.
• 특정 신호가 대답하지 못하는 질문을 파악하고, 다른 신호로 반증 및 보완하는 체계를 구축하는 것이 관측 가능성(Observability)의 본질임.