부제: 각 프레임워크가 "어떤 불편을 없애려고" 만들어졌는지로 읽으면 역할이 갈린다
여기서부터는 시리즈 C(관측과 보안 후킹) 다. 시리즈 A(무엇을)·B(어떻게)에
이어, 이번엔 관측(Observability) 을 같은 방식으로 — 개념마다 한 줄 정의 —
정리한다.
관측 도구는 이름만 보면 다 비슷해 보인다. 다 "모니터링" 같다. 그런데 이
시리즈의 방법대로 "이게 어떤 불편을 없애려고 나왔나" 로 읽으면 단번에
갈린다. 이번 편은 딱 그 한 줄 정의만 붙잡는다. (코드를 안 고치고 어떻게
추적하는가의 원리 는 다음 편 C2에서 판다.)
프레임워크별 한 줄 정의
먼저 카드로 한눈에.
| 프레임워크 | 한 줄 정의 | 없앤 불편 |
|---|---|---|
| Prometheus | 측정항목(metrics) 수집·시계열 DB(pull) | 서비스마다 카운터 심고 대시보드 짜던 걸 표준 규격으로 |
| Loki | 로그(logs) 집계 — 라벨 기반 중앙 질의 | 서버마다 SSH 타고 grep 하던 걸 한곳에서 |
| Tempo | 분산 추적(traces) 백엔드 | 요청의 A→B→C 흐름을 코드 수정 없이 재구성 |
| Grafana | 시각화·대시보드 | 소스별로 흩어진 화면을 하나의 관측 UI로 |
| Beyla | Grafana의 eBPF auto-instrumentation | 앱에 계측 코드·에이전트를 안 붙이고 관측 |
| Linkerd | 경량 서비스 메시(사이드카) | 앱 코드 무수정으로 통신 암호화(mTLS)+관측 |
| Keycloak | IAM/SSO 인증 서버(별개 축) | 앱마다 로그인 구현하던 걸 표준 프로토콜로 |
세(네) 기둥 — metrics·logs·traces + 시각화
관측의 고전적 정의는 세 기둥이다. 세 신호는 서로 답하는 질문이 다르다.
- Prometheus (메트릭) — "지금 상태가 어떤가?" 요청 수·지연·에러율·CPU
같은 숫자를 시계열로 모은다. Prometheus가 각 대상을 주기적으로 pull해
가져가는 게 특징. 이상 징후를 가장 먼저 알아채는 신호다. - Loki (로그) — "무슨 일이 있었나?" 텍스트 로그를 라벨로 묶어 중앙에서
질의한다. 메트릭이 "에러율이 튀었다"를 알려주면, 로그가 "왜"의 첫 단서를 준다.
(Prometheus의 사촌답게 라벨 모델이 닮았다.) - Tempo (추적) — "그 요청이 어디로 흘렀나?" 하나의 요청이 서비스 A→B→C를
지나며 남긴 span을 이어 붙여 여정을 재구성한다. 분산 시스템에서
"느린 게 어느 구간인지"를 짚어 준다. - Grafana (시각화) — 위 세 신호는 저장소가 다 다르다. Grafana는 그 셋을
한 화면에 붙여, 메트릭에서 이상 → 로그로 원인 → 트레이스로 경로 로
자연스럽게 파고들게 해 준다. 관측의 얼굴이다.
코드 무수정 관측의 다리 — Beyla와 Linkerd
세 기둥은 "어디에 저장하나"의 이야기다. 그런데 애초에 그 신호를 앱에서 어떻게
뽑아내나? 예전엔 코드에 계측 라이브러리를 심어야 했다. 요즘은 앱을 안
고치고 경계에서 뽑는 두 갈래가 있다.
- Beyla — Grafana의 eBPF auto-instrumentation. 커널에 프로브를 심어
애플리케이션의 HTTP/gRPC 송수신을 관찰하고, 거기서 RED(Rate·Errors·
Duration) 메트릭과 트레이스를 만들어 낸다. 앱에는 손도 안 댄다. - Linkerd — 경량 서비스 메시. 각 Pod 옆에 사이드카 프록시를 붙여
서비스 간 트래픽을 가로챈다. 그 프록시가 mTLS(통신 암호화) 를 걸면서
동시에 RED 메트릭·트레이스를 뽑는다. 통신 보안과 관측을 코드 무수정으로
함께 얻는 게 핵심.
이 둘이 "코드를 안 고치고 관측한다"의 실현 장치다. 그런데 커널에 프로브를
심고, 트래픽을 가로챈다 — 이 방식이 사실 보안 업계가 오래 써 온 후킹 기법과
같은 뿌리다. 그 이야기가 다음 편(C2)의 주제다.
별개 축 — Keycloak (인증)
마지막 하나는 관측이 아니라 인증이라 축이 다르지만, 같은 자가호스팅 스택에
함께 얹히기에 정의만 붙여 둔다.
- Keycloak — 오픈소스 IAM/SSO 서버. OAuth2·OIDC·SAML 같은 표준
프로토콜로 로그인·권한을 대신 처리하고, 여러 소셜 로그인을 하나로 묶는
아이덴티티 브로커 역할을 한다. 앱마다 로그인을 직접 구현하던 수고를
없앤다. - 방향성: 나는 구글·네이버·카카오 연동 로그인을 이 Keycloak으로
묶을 계획이다. (구현기는 별도 글에서 다룬다.)
정리
- Prometheus=메트릭, Loki=로그, Tempo=추적, Grafana=시각화 —
세 기둥 + 얼굴. - Beyla(eBPF)·Linkerd(서비스 메시)는 코드 무수정으로 신호를 뽑는 다리.
- Keycloak은 관측이 아니라 인증(IAM/SSO) — 소셜 로그인용으로 별도 축.
- 이름이 아니라 "없앤 불편" 으로 읽으면 역할이 갈린다.
다음 편(C2)에서는 이 시리즈를 처음 열게 한 질문으로 간다 — 코드를 안 고치고
추적하는 auto-instrumentation이, 보안 업계의 후킹 기법(Detours·ETW·EDR)과
어떻게 같은 뿌리에서 나오는가. B2에서 만난 그 eBPF가 여기서 다시 등장한다.
참고
- Grafana Docs — Prometheus, Loki, Tempo, Beyla
- Linkerd Docs — Architecture (service mesh)
- Keycloak Docs — Server Administration (OIDC/Identity Brokering)
답글 남기기