Tag: 모니터링

쿠버네티스 운영 입문: 클러스터를 안정적으로 굴리는 첫걸음
쿠버네티스를 도입하면 컨테이너 배포가 쉬워질 것이라 기대하지만, 실제 운영에서는 파드가 갑자기 재시작되거나 노드가 압박을 받아 워크로드가 쫓겨나는 일이 빈번하게 발생합니다. 운영의 본질은 ‘배포’가 아니라 ‘안정적으로 계속 굴리는 것’입니다. 이 글에서는 처음 클러스터를 책임지는 입장에서 반드시 이해해야 할 구조와 설정을 다룹니다.
운영 문제: 왜 파드는 예고 없이 죽는가
가장 흔한 장애는 리소스 미설정에서 비롯됩니다. requests와 limits를 지정하지 않으면 스케줄러는 노드 용량을 가늠하지 못하고, 한 파드가 메모리를 폭주시키면 OOMKilled가 연쇄적으로 발생합니다. 실제로 노드당 평균 메모리 사용률이 85%를 넘어가면 eviction 위험이 급격히 올라갑니다.
아키텍처: 컨트롤 플레인과 워커의 역할
컨트롤 플레인은 클러스터의 두뇌입니다. kube-apiserver가 모든 요청의 관문이 되고, etcd가 상태를 저장하며, scheduler와 controller-manager가 원하는 상태(desired state)와 실제 상태를 끊임없이 비교해 수렴시킵니다. 워커 노드의 kubelet은 이 명령을 받아 컨테이너를 실제로 띄웁니다. 운영자는 이 reconciliation loop를 이해해야 장애 원인을 추적할 수 있습니다.
구성: 리소스와 헬스체크 기본 세팅
최소한의 안정성을 확보하려면 모든 워크로드에 리소스 경계와 프로브를 설정해야 합니다. 아래는 권장 출발점입니다.
```
resources:
  requests: { cpu: "250m", memory: "256Mi" }
  limits:   { cpu: "500m", memory: "512Mi" }
livenessProbe:
  httpGet: { path: /healthz, port: 8080 }
  initialDelaySeconds: 15
readinessProbe:
  httpGet: { path: /ready, port: 8080 }
  periodSeconds: 5
```
livenessProbe는 ‘죽었으면 재시작’, readinessProbe는 ‘준비 안 됐으면 트래픽 차단’이라는 서로 다른 목적을 가집니다. 둘을 혼동해 livenessProbe를 너무 공격적으로 잡으면 부팅 중인 파드가 계속 재시작되는 죽음의 루프에 빠집니다.
모니터링과 비용: 무엇을 봐야 하는가
- 노드별 CPU/메모리 사용률과 allocatable 대비 점유율
- 파드 재시작 횟수(restartCount)와 OOMKilled 빈도
- 스케줄 실패(Pending) 파드 수와 그 원인 이벤트
- PVC 스토리지 잔여 용량
비용 관점에서는 노드 활용률이 핵심입니다. requests를 실제 사용량보다 과하게 잡으면 노드는 한가한데도 새 노드가 늘어 비용이 새어 나갑니다. 2주간 실측 데이터를 기준으로 requests를 재조정하면 흔히 20~30% 노드 비용을 절감할 수 있습니다.
정리
쿠버네티스 운영의 기본은 화려한 기능이 아니라 리소스 경계, 헬스체크, 관측 지표라는 세 가지 토대입니다. 이 토대를 먼저 다진 뒤에야 오토스케일링이나 멀티클러스터 같은 고급 주제로 나아갈 수 있습니다. 작게 시작하되, 측정 가능한 상태에서 시작하십시오.
2026-04-27
MLOps 파이프라인 설계: 모델을 실험에서 운영까지 흐르게 하는 법
많은 팀이 노트북에서 좋은 정확도를 낸 모델을 운영에 올리는 순간 좌절합니다. 재현이 안 되고, 데이터가 바뀌면 성능이 조용히 무너지며, 누가 어떤 버전을 배포했는지 아무도 모릅니다. MLOps는 이 혼돈을 반복 가능한 파이프라인으로 바꾸는 운영 규율입니다.
운영 문제: 모델은 배포 후에 썩는다
소프트웨어와 달리 모델은 코드가 그대로여도 입력 데이터 분포가 변하면 성능이 떨어집니다. 이를 데이터 드리프트라 부릅니다. 한 추천 모델은 출시 6주 만에 클릭률이 12% 하락했는데, 코드 변경은 전혀 없었습니다. 원인은 신규 사용자 유입으로 입력 분포가 달라진 것이었습니다.
아키텍처: 4개의 흐름으로 보는 파이프라인
MLOps 파이프라인은 데이터 파이프라인, 학습 파이프라인, 배포 파이프라인, 모니터링 파이프라인의 네 흐름으로 나눠 보면 명확해집니다. 각 흐름은 독립적으로 트리거되되, 모니터링이 드리프트를 감지하면 학습 파이프라인을 다시 깨우는 폐루프(closed loop)를 이룹니다.
- 데이터: 수집 → 검증 → 피처 스토어 적재
- 학습: 실험 추적 → 모델 레지스트리 등록 → 평가 게이트
- 배포: 카나리 → 점진 롤아웃 → 롤백 트리거
- 모니터링: 예측 분포·지연·드리프트 관측
구현: 재학습 자동화 예시
드리프트가 임계치를 넘으면 자동으로 재학습을 트리거하는 것이 핵심입니다. 파이프라인 정의는 코드로 관리해 재현성을 보장합니다.
```
if drift_score > 0.15:
    trigger_pipeline(
        name="retrain-recommender",
        params={"window_days": 30, "min_samples": 50000},
    )
    register_if_better(metric="auc", threshold=0.82)
```
여기서 register_if_better가 중요합니다. 새 모델이 기존 모델보다 검증 지표가 나을 때만 레지스트리에 승격시켜야 무분별한 배포를 막을 수 있습니다.
모니터링과 비용
학습은 GPU 비용이 크기 때문에 무조건 자주 돌리는 것이 정답이 아닙니다. 드리프트 기반 트리거를 쓰면 정해진 주기 재학습 대비 GPU 사용 시간을 40% 이상 줄이면서도 성능 저하를 조기에 잡을 수 있습니다. 예측 지연(p95 latency)과 처리량도 함께 추적해 서빙 비용과 품질의 균형을 잡아야 합니다.
정리
MLOps의 목표는 멋진 모델이 아니라 ‘믿고 맡길 수 있는 흐름’을 만드는 것입니다. 실험 추적, 모델 레지스트리, 드리프트 모니터링이라는 세 축을 갖추면 모델이 썩기 전에 스스로 회복하는 시스템에 다가설 수 있습니다.
2026-04-25
클라우드 비용이 새는 곳: 절감 포인트 7가지 실전 분석
클라우드 청구서가 매달 늘어나는데 어디서 새는지 모르겠다는 고민은 거의 모든 성장 단계 조직이 겪습니다. 비용 최적화는 무작정 인스턴스를 줄이는 것이 아니라, 낭비의 위치를 데이터로 특정한 뒤 우선순위를 매겨 공략하는 작업입니다.
운영 문제: 비용은 분산되어 보이지 않는다
가장 큰 적은 ‘유휴 자원’과 ‘오버프로비저닝’입니다. 끄지 않은 개발 서버, 연결되지 않은 디스크 볼륨, 트래픽 없는 로드밸런서가 조용히 돈을 먹습니다. 실측해 보면 전체 청구의 15~25%가 실제로는 아무 가치를 만들지 못하는 유휴 비용인 경우가 흔합니다.
절감 전술 7가지
- 리소스 라이트사이징: 실측 사용률 기반으로 인스턴스 다운사이징
- 예약 인스턴스·저축 플랜으로 안정 워크로드 할인(최대 60%)
- 스팟 인스턴스로 배치/학습 작업 비용 70~80% 절감
- 유휴 자원 자동 정리: 미연결 디스크·스냅샷·구 AMI
- 오토스케일링으로 야간·주말 축소
- 스토리지 계층화: 콜드 데이터를 저비용 티어로 이동
- 데이터 전송 비용 최소화: 같은 리전·가용영역 배치
구현: 태깅 없이는 절감도 없다
비용을 줄이려면 먼저 비용을 귀속시킬 수 있어야 합니다. 모든 자원에 팀·환경·서비스 태그를 강제하면 어느 팀의 어느 환경이 비용을 일으키는지 보입니다.
```
tags:
  team: "recommendation"
  env: "prod"
  service: "ranking-api"
  cost-center: "ml-platform"
```
태그가 정착되면 ‘미태깅 자원은 매주 자동 알림’ 같은 거버넌스 규칙을 걸어 누수를 구조적으로 막을 수 있습니다.
모니터링: 비용도 지표다
비용은 월말에 확인하는 숫자가 아니라 매일 보는 지표여야 합니다. 일일 비용 추세를 대시보드로 띄우고, 전일 대비 20% 이상 급증하면 알림을 보내는 이상 탐지를 걸어두면 잘못된 배포로 인한 폭증을 하루 안에 잡을 수 있습니다.
측정되지 않는 비용은 줄어들지 않는다. 가시성이 절감의 90%다.
정리
비용 최적화는 일회성 다이어트가 아니라 지속적 운영 습관입니다. 태깅으로 가시성을 확보하고, 라이트사이징과 할인 약정으로 구조를 잡은 뒤, 일일 비용 모니터링으로 누수를 조기에 막는 순환을 만드십시오.
2026-04-24
옵저버빌리티 3축: 로그·메트릭·트레이스를 하나로 엮는 법
장애가 났을 때 ‘서버가 느립니다’는 알지만 ‘왜 느린지’는 모르는 상황, 익숙하실 겁니다. 전통적 모니터링은 알고 있는 문제만 잡지만, 옵저버빌리티는 예상치 못한 문제도 사후에 파고들 수 있게 해줍니다. 그 토대가 로그, 메트릭, 트레이스라는 세 기둥입니다.
운영 문제: 데이터는 많은데 답이 없다
세 신호를 각각 따로 수집하면, 메트릭에서 지연 급증을 봐도 어느 요청 때문인지 추적할 수 없습니다. 옵저버빌리티의 진짜 가치는 세 신호를 상관(correlation)시켜 하나의 사건을 입체적으로 재구성하는 데 있습니다.
세 기둥의 역할
- 메트릭: 무슨 일이 일어나는가 (수치·추세, 저비용·고압축)
- 로그: 정확히 무엇이 일어났는가 (이벤트의 맥락)
- 트레이스: 어디서 시간이 걸렸는가 (요청의 전체 경로)
메트릭으로 이상을 감지하고, 트레이스로 병목 구간을 좁힌 뒤, 로그로 근본 원인을 확인하는 흐름이 이상적인 디버깅 동선입니다.
구현: 상관관계의 열쇠는 trace_id
세 신호를 엮는 결정적 장치는 모든 신호에 공통 trace_id를 심는 것입니다. 로그 한 줄에서 trace_id를 클릭하면 해당 요청의 전체 트레이스로 점프할 수 있어야 합니다.
```
{
  "ts": "2026-06-25T09:14:02Z",
  "level": "error",
  "trace_id": "a1b2c3d4",
  "service": "checkout",
  "msg": "payment timeout",
  "latency_ms": 5021
}
```
OpenTelemetry 같은 표준을 쓰면 언어·프레임워크가 달라도 동일한 trace_id 전파 규약을 공유할 수 있어, 마이크로서비스 전체를 하나의 추적 망으로 연결할 수 있습니다.
비용: 다 저장하면 파산한다
옵저버빌리티의 함정은 비용입니다. 모든 로그와 트레이스를 100% 보관하면 데이터 비용이 인프라 비용을 넘어서기도 합니다. 정상 트래픽은 1~5%만 샘플링하고 에러·고지연 요청은 100% 보관하는 테일 샘플링이 비용과 가시성의 균형점입니다.
정리
옵저버빌리티는 도구를 사는 게 아니라 신호를 엮는 설계입니다. 공통 trace_id로 세 기둥을 연결하고, 똑똑한 샘플링으로 비용을 통제하면, 처음 보는 장애 앞에서도 자신 있게 질문을 던지고 답을 찾을 수 있습니다.
2026-04-21
온콜 장애대응 회고: 새벽 3시 알림이 가르쳐준 것들
새벽 3시, 휴대폰이 울립니다. 결제 성공률이 급락했다는 알림입니다. 잠에서 덜 깬 채로 노트북을 여는 그 순간이, 사실 한 조직의 운영 성숙도를 가장 정직하게 드러냅니다. 이 글은 여러 장애를 겪으며 배운 것들을 회고합니다.
운영 문제: 영웅에 의존하는 대응의 한계
초기에는 시스템을 가장 잘 아는 한 사람이 모든 장애를 해결했습니다. 빠르지만 위험한 구조였습니다. 그 사람이 휴가를 가면 복구가 멈췄고, 지식은 그의 머릿속에만 있었습니다. 좋은 온콜은 영웅이 아니라 누구나 따라갈 수 있는 절차에 의존해야 한다는 걸 비싸게 배웠습니다.
대응 흐름: 진정하고, 좁히고, 복구한다
- 감지: 좋은 알림은 증상이 아니라 사용자 영향(성공률·지연)을 알린다
- 분류: 심각도(SEV)를 정해 호출 범위와 커뮤니케이션을 결정
- 완화: 근본 원인보다 먼저 영향 차단(롤백·트래픽 차단)
- 복구: 정상화 확인 후 임시 조치를 정식 조치로 대체
가장 중요한 교훈은 ‘원인 규명보다 완화가 먼저’라는 순서였습니다. 새벽에 근본 원인을 파헤치느라 30분을 쓰는 대신, 직전 배포를 즉시 롤백했다면 영향 시간을 1/5로 줄일 수 있었습니다.
비난 없는 포스트모템
장애는 사람의 실수가 아니라 그 실수를 허용한 시스템의 문제다.
포스트모템에서 ‘누가 잘못했나’를 묻기 시작하면 사람들은 사실을 숨깁니다. ‘어떤 안전장치가 없어서 이 실수가 장애로 번졌나’를 물어야 시스템이 개선됩니다. 우리 팀은 모든 SEV2 이상 장애에 대해 48시간 내 포스트모템을 작성하고, 거기서 나온 액션 아이템을 다음 스프린트에 반드시 반영하는 규칙을 세웠습니다.
모니터링과 온콜 건강
온콜 자체도 측정 대상입니다. 야간 호출 빈도, 오탐(false positive) 비율, MTTR을 추적했습니다. 오탐이 많은 알림은 사람을 둔감하게 만들어 진짜 장애를 놓치게 합니다. 6개월간 노이즈 알림을 정리하니 야간 호출이 절반으로 줄었고, 동시에 진짜 장애의 평균 복구 시간도 짧아졌습니다.
정리
장애는 피할 수 없지만 배움의 재료로 바꿀 수는 있습니다. 영웅 의존을 절차로, 비난을 학습으로, 노이즈를 신뢰로 바꾸는 과정이 곧 운영 성숙입니다. 새벽 3시의 알림은 괴롭지만, 그것을 줄여가는 여정이 결국 더 단단한 시스템을 만듭니다.
2026-04-17