Post

[K8s ELK 시리즈 #0] 왜 시작했나 — 물리 인프라를 클라우드로 옮기기

[K8s ELK 시리즈 #0] 왜 시작했나 — 물리 인프라를 클라우드로 옮기기

시작은 현업에서 쓰는 시스템이었다

나는 대형 운영 시설의 IT 인프라팀에서 일한다.

담당 시스템 중에 내부적으로 모니터링 플랫폼이라고 부르는 게 있다. 이름은 거창한데 구조를 뜯어보면 딱 ELK 스택이다.

1
2
3
4
5
6
7
현장 장비/서버 (SNMP, 시스템 로그)
    ↓
Logstash AP서버 (수집/파싱)
    ↓
Elasticsearch (저장/검색)
    ↓
대시보드 서버 (시각화)

수십 대 서버, 물리 장비. 인덱스 수천 개, 데이터 TB 단위.

근데 이게 전부 물리 서버다. 서버 한 대 죽으면 사람이 가서 살려야 하고, 용량 늘리려면 장비 구매 품의 올려야 한다. 스케일 아웃? 몇 달 걸린다.

“이걸 K8s 위에 올리면 어떻게 될까?”

그 질문에서 이 시리즈가 시작됐다.


ELK 스택이 뭔데

Elasticsearch + Logstash + Kibana

1
2
[데이터 소스]  →  [Logstash]  →  [Elasticsearch]  →  [Kibana]
장비/서버 로그     수집·파싱·변환    저장·검색·인덱싱     시각화·대시보드

Logstash — 수집과 변환

데이터를 받아서 가공하는 파이프라인이다. 구조는 단순하다:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
input {
  tcp { port => 6001 codec => json }  # TCP 6001로 JSON 수신
}

filter {
  grok {
    # 텍스트 로그를 필드로 분리
    match => { "message" => "%{TIMESTAMP_ISO8601:time} %{HOSTNAME:host} %{GREEDYDATA:msg}" }
  }
  mutate {
    add_field => { "[@metadata][index]" => "log-syslog" }
  }
}

output {
  elasticsearch {
    hosts => ["es:9200"]
    index => "%{[@metadata][index]}-%{+YYYY.MM.dd}"
  }
}

Input → Filter → Output 3단계. 어디서 받고, 어떻게 가공하고, 어디로 보낼지.

Elasticsearch — 검색 엔진이자 저장소

일반 DB(MySQL, MSSQL)랑 근본적으로 다르다:

일반 RDBElasticsearch
스키마 고정유연한 매핑
Row 단위Document(JSON) 단위
SQLREST API + JSON 쿼리
정확한 값 검색전문 검색(Full-text)
테이블Index

로그 데이터에 특화된 이유:

  • 구조가 제각각인 로그 → 스키마 고정 불필요
  • “disk full” 같은 텍스트 검색 → Full-text search
  • 날짜별 인덱스 자동 분리 → log-syslog-2026.03.22
  • 대용량 → 샤드로 분산 저장

Kibana — 눈으로 보는 대시보드

브라우저에서 접속하는 웹 UI. 코딩 없이 ES 데이터를 시각화한다. SFMS의 AppleMango 솔루션이 이 역할이다.


왜 K8s인가

현재 물리 환경의 한계:

1
2
3
4
서버 죽음 → 수동 복구 (사람이 가야 함)
용량 부족 → 장비 구매 (몇 달 걸림)
설정 변경 → SSH 접속해서 직접 수정
환경 재현 → 문서 보고 처음부터 다시

K8s로 바꾸면:

1
2
3
4
Pod 죽음 → 자동 재시작 (Self-healing)
용량 부족 → 명령어 한 줄 (Scale out)
설정 변경 → YAML 파일 수정 후 apply
환경 재현 → YAML 파일 그대로 다른 곳에 올리기

인프라를 코드로 관리한다(IaC). 이게 DevOps/SRE의 핵심이다.


시리즈 계획

내용
#0 (이 글)개론, 기본 개념, 왜 시작했나
#1minikube 환경 세팅, K8s 기본 개념 실습
#2Elasticsearch StatefulSet 배포
#3Logstash 배포 + 파이프라인 설정
#4Kibana 배포 + 대시보드 구성
#5테스트 데이터 유입 + 검증
#6현업 구조와 비교, 한계와 개선점

물리 서버 10대짜리를 K8s YAML 몇 개로 재현하는 과정이다. 잘 될지 모른다. 삽질하면 그것도 그대로 쓴다.


환경

  • MacBook M2 (minikube)
  • Docker Desktop
  • minikube v1.31.2
  • kubectl v1.28.2
  • 목표 스택: Elasticsearch 6.8.x + Logstash 6.8.x + Kibana 6.8.x

현업 ES 버전이 6.8.23이라 맞추기로 했다. 최신 8.x랑 많이 다르다는 거 알고 시작한다.


다음 편에서 minikube 띄우는 것부터 시작한다.

This post is licensed under CC BY 4.0 by the author.