조용한 개발 노트

보이지 않으면 통제할 수 없다분산 시스템은 정상과 비정상의 경계가 흐리다.일부 요청만 실패한다특정 구간에서만 지연이 발생한다장애는 천천히 퍼진다이런 환경에서 단순한 모니터링만으로는 무엇이 일어나고 있는지 알 수 없다.그래서 분산 시스템에서는 Observability가 필수가 된다.Observability는 모니터링이 아니다모니터링은 보통 다음 질문에 답한다.CPU 사용률은 얼마인가에러율이 증가했는가서버는 살아 있는가하지만 분산 시스템에서 더 중요한 질문은 이것이다.왜 이 요청이 실패했는가Observability는 내부 상태를 추론할 수 있는 능력을 의미한다.왜 분산 시스템은 본질적으로 불투명한가분산 시스템은 다음 이유로 본질적으로 불투명하다.요청이 여러 서비스와 노드를 거친다부분 실패가 정상 동작처럼 보..

8편에서 Kafka 성능 문제의 상당수가 JVM이 아니라 OS·운영 환경에서 발생한다는 이야기를 했다. 그런데 현장에서 가장 자주 마주치는 질문은 이거다.“Lag이 늘었는데, 어디가 문제지?”Kafka에서 관측이 어려운 이유는 도구가 부족해서가 아니다. 지표가 무엇을 의미하는지 오해하기 쉽기 때문이다.Consumer Lag은 무엇을 말해주는 지표인가Consumer Lag은 단순히 말하면 브로커에 쌓인 데이터와 소비자가 읽은 위치의 차이다.Lag = 아직 읽지 않은 메시지 수Lag = 처리 대기 중인 작업량여기까지는 맞다. 하지만 많은 오해는 여기서 시작된다.Lag이 크다고 반드시 장애는 아니다Kafka의 로그 모델을 떠올려보자.데이터는 삭제되지 않는다소비자는 자기 속도로 읽는다이 구조에서는 Lag이 일시..

10편에서 샘플링이 Observability의 성패를 좌우한다고 이야기했다. 그런데 샘플링까지 잘 설정했는데도, 여전히 이런 말을 듣게 되는 경우가 있다.“Trace는 보이는데, 그래서 뭐가 문제인지는 모르겠다.”이 단계에서의 문제는 도구가 아니다. 대부분 표현 방식과 해석 방식에 있다.문제 1. 이름이 의미를 전달하지 못한다Trace를 열었을 때 가장 먼저 보이는 것은 Span의 이름이다.그런데 이런 이름을 자주 보게 된다.method.invokeservice.callprocess기술적으로는 맞을 수 있다. 하지만 이 이름들만으로는 무슨 일이 일어났는지 설명할 수 없다.OpenTelemetry 공식 문서는 Span 이름이 “무엇을 했는지”를 한 문장으로 설명해야 한다고 강조한다.예를 들어:GET /or..

9편에서 OpenTelemetry Collector 설정을 “관측 데이터가 흐르는 설계도”로 읽는 법을 살펴봤다. 이제 남은 가장 어려운 질문이 있다.“그 많은 Trace를 다 모아야 할까?”결론부터 말하면 아니다. 샘플링을 잘못하면 Observability는 비용만 늘리고, 정작 중요한 순간에는 아무것도 설명해주지 못한다.왜 샘플링이 필요한가분산 추적은 본질적으로 데이터가 많다.요청 하나당 여러 개의 Span트래픽이 늘수록 기하급수적으로 증가저장-전송-분석 비용이 모두 따라온다“일단 다 모아두고 나중에 보자”는 전략은 거의 항상 실패한다. 비용이 먼저 한계에 도달하기 때문이다.그래서 OpenTelemetry는 샘플링을 설계의 일부로 취급한다.샘플링의 본질: 무엇을 포기할 것인가샘플링은 기술 문제가 아니..

8편에서 OpenTelemetry Collector가 관측 데이터의 흐름을 통제하는 축이라는 이야기를 했다. 하지만 실제로 Collector를 마주하면, 대부분 여기서 멈춘다.“설정 파일이 너무 복잡하다.”이 편의 목표는 단순하다. Collector 설정을 ‘외울 대상’이 아니라 ‘해석 가능한 구조’로 만드는 것이다.Collector 설정은 파이프라인 정의다Collector 설정 파일의 핵심은 개별 옵션이 아니다.데이터가 어디서 들어와서, 어떻게 처리되고, 어디로 나가는지를 정의하는 파이프라인이다.이 관점으로 보면, 설정 파일은 크게 세 덩어리로 나뉜다.receivers: 데이터를 어디서 받을 것인가processors: 받은 데이터를 어떻게 다룰 것인가exporters: 데이터를 어디로 보낼 것인가그리고..

7편에서 Java Agent 하나로 요청 흐름이 바로 보이기 시작한다는 이야기를 했다. 여기까지 오면 이런 생각이 들기 쉽다.“이 정도면 Agent만 써도 충분한 거 아닌가?”소규모 환경에서는 맞는 말이다. 하지만 서비스 수가 늘고, 환경이 복잡해질수록 Collector 없이 버티기 어려운 지점이 반드시 온다.Agent만 쓰면 어디서 막히는가Java Agent는 애플리케이션 내부에서 관측 데이터를 만들어내는 역할을 훌륭하게 수행한다. 문제는 그 다음 단계다.모든 서비스가 각자 백엔드로 직접 전송한다환경마다 설정이 조금씩 달라진다샘플링-필터링 정책을 바꾸려면 전부 재배포한다이 구조에서는 관측이 늘어날수록 운영 부담이 기하급수적으로 커진다.Collector는 무엇을 하는 컴포넌트인가OpenTelemetry ..

3편에서 Trace가 끊어지는 가장 큰 원인이 Context Propagation이라는 이야기를 했다. 그런데 Context를 잘 전달했더라도, 여전히 이런 상황은 자주 발생한다.“메트릭은 분명히 나빠졌는데, 로그에서는 큰 문제가 안 보인다.” “로그에는 에러가 있는데, 지표는 정상이다.”이 혼란의 원인은 단순하다. 각각 다른 질문에 답하는 도구를, 하나의 답을 기대하며 보고 있기 때문이다.Signals는 역할이 다르다OpenTelemetry 공식 문서는 관측 신호(signals)를 traces, metrics, logs 세 가지로 나눈다. 이 분류는 구현 편의가 아니라, 각각이 답하는 질문이 다르기 때문이다.Metrics: 지금 시스템 상태가 정상인가? (전체적인 건강 상태를 빠르게 본다)Logs: 어..

장애가 났다. 알람도 울렸고, 대시보드도 빨갛다. 로그도 남아 있다. 그런데 막상 "왜 느려졌는지"를 한 문장으로 말하기가 어렵다. 특히 서비스가 여러 개로 쪼개진 분산 환경에서는 이 문제가 더 자주-더 오래 반복된다.이 글은 OpenTelemetry 공식 문서의 관점(telemetry를 통해 내부 상태를 이해한다)을 빌려, 왜 이런 일이 생기는지-그리고 무엇이 빠져 있는지를 "문제 중심"으로 정리한다. 다음 글부터는 OpenTelemetry의 핵심 개념을 하나씩 붙여서, 실제로 원인을 추적 가능한 형태로 만들어갈 예정이다.현실: 로그-메트릭은 있는데 "요청 흐름"이 없다우리가 흔히 갖고 있는 관측 데이터는 보통 두 가지다.로그: 특정 시점에 어떤 일이 발생했는지(텍스트로 기록)메트릭: 어떤 값이 얼마나..

46편에서는 ApplicationEvent를 로직이 아닌 운영 신호로 사용하는 기준을 정리했다.이번 글에서는 그 신호들이 실제로 모이는 장소, Actuator를 중심으로 보안(Security)과 관측(Observability)을 어떻게 함께 설계해야 하는지를 다룬다.이 영역은 실무에서 사고가 가장 자주 발생하는 교차 지점이기도 하다.1) Actuator는 “상태 API”이지 “디버그 도구”가 아니다많은 팀이 Actuator를 문제 생겼을 때만 켜는 디버그 도구처럼 취급한다.하지만 Spring Boot에서 Actuator의 본질은 애플리케이션의 상태를 설명하는 API다.즉:개발자만을 위한 도구 ❌운영 시스템과의 계약 ⭕이 관점이 없으면, 노출과 보안은 항상 땜질이 된다.2) Observability의 출발..

29편에서는 Spring Boot Security Auto-Configuration을 통해 왜 기본적으로 “막혀 있는 상태”가 출발점인지를 살펴봤다.이번 글에서는 그 보안의 연장선, 운영에서 사고를 가장 자주 만드는 영역인 Actuator 보안 설계를 다룬다.Actuator는 운영에 필수지만, 동시에 노출되는 순간 가장 위험한 인터페이스가 된다.1) Actuator는 “관리 API”이지 “일반 API”가 아니다Actuator Endpoint는 일반 비즈니스 API와 성격이 다르다.사용자를 위한 API ❌운영 시스템을 위한 API ⭕이 차이를 무시하고 동일한 접근 정책을 적용하면, 보안 사고는 시간문제다.Actuator는 사람보다 시스템이 먼저 소비하는 인터페이스다.2) 기본 노출 정책이 보수적인 이유Sp..