[리눅스 기초 #47] 흩어진 기록을 한곳에: ELK 스택으로 완성하는 중앙 집중형 로그 시스템

 

리눅스 기초 시리즈의 47번째 시간입니다! 지난 시간에는 Tailscale을 활용해 외부 포트 개방 없이 안전한 프라이빗 네트워크를 구축해 보았습니다. 이제 우리 서버는 보안과 접근성이라는 두 마리 토끼를 모두 잡았습니다. 하지만 서비스 규모가 커지고 컨테이너가 늘어날수록, 또 다른 고민이 머리를 들기 시작합니다.

"어제 새벽에 났던 에러 로그, 도대체 어떤 컨테이너에서 발생한 거지?" 여러 서버와 수십 개의 컨테이너를 일일이 돌아다니며 tail -f를 치고 계신가요? 오늘은 흩어진 모든 로그를 한곳에 모아 구글처럼 검색할 수 있게 해주는 중앙 집중형 로그 관리 시스템, ELK 스택(Elasticsearch, Logstash, Kibana)의 세계를 맛보겠습니다.

---

1. 나의 경험담: "로그 찾다 밤샌 사연, 검색의 소중함"

 

제 블로그 sunyjini.com의 마이크로서비스들이 늘어나면서, 장애가 발생했을 때 원인을 찾는 과정이 마치 '숨은그림찾기'처럼 변해버렸습니다. A 서버의 Nginx 로그를 보고, 다시 B 서버의 API 로그를 뒤지고, 마지막으로 DB 로그를 대조하는 식이었죠. 타임스탬프를 일일이 대조하며 메모장에 적어 내려가다 보니 정작 에러 수정은 시작도 못 했는데 해가 뜨고 있었습니다.

이 지옥 같은 반복 업무를 끝내기 위해 ELK 스택을 도입했습니다. 모든 로그를 하나의 거대한 데이터베이스(Elasticsearch)에 붓고, 이를 웹 대시보드(Kibana)에서 키워드로 검색하기 시작한 순간, 신세계를 보았습니다. 1시간 걸리던 디버깅이 단 1분 만에 끝나는 마법! 이제 저는 로그를 '뒤지는' 사람이 아니라 로그를 '분석하는' 스마트한 관리자가 되었습니다.

---

2. Before: "텍스트의 숲에서 길을 잃다"

중앙 집중형 로그 시스템이 없던 시절에는 각 서버에 직접 SSH로 접속해 검은 화면에서 하얀 글자들을 쫓아야 했습니다. 로그가 회전(Rotate)되어 사라지기라도 하면 과거의 장애 기록은 영원히 미궁 속에 빠지게 되죠.

기존 방식의 한계:

Terminal (Legacy Way)

 

# 서버 1 접속
ssh server1 "tail -n 100 /var/log/nginx/error.log"

서버 2 접속
ssh server2 "docker logs my-app"

"아... 아까 그 에러 메시지가 뭐였더라?"

(▲ Before: 정보가 파편화되어 있어 상관관계를 분석하기가 거의 불가능에 가깝습니다. 실시간 대응력도 현저히 떨어지는 상태입니다.)

---

3. Action: 도커 컴포즈로 로그 분석실 차리기

 

ELK 스택은 개별 설치가 까다롭지만, 우리는 이미 도커 마스터죠! Docker Compose를 이용해 로그 수집 엔진을 한 번에 가동해 보겠습니다.

ELK 맛보기 코드 (docker-compose.yml):

Docker Compose

 

version: '3.7'
services:
elasticsearch:
image: elasticsearch:7.17.0
environment:
- discovery.type=single-node
ports:
- "9200:9200"

logstash:
image: logstash:7.17.0
volumes:
- ./logstash.conf:/usr/share/logstash/pipeline/logstash.conf
depends_on:
- elasticsearch

kibana:
image: kibana:7.17.0
ports:
- "5601:5601"
depends_on:
- elasticsearch

(▲ Action: docker-compose up -d를 입력하면 로그 데이터의 저장, 정제, 시각화 인프라가 동시에 살아납니다. 이제 브라우저로 5601 포트에 접속하면 우리만의 구글 로그 검색 엔진이 열립니다.)

---

4. After: 데이터가 들려주는 서버의 이야기

ELK 스택을 갖춘 뒤, 제 서버 운영은 '추측'이 아닌 '데이터' 기반으로 바뀌었습니다. 단순한 장애 대응을 넘어 인사이트를 얻게 되었죠.

달라진 점들:

• 광속 검색: "Error 500" 키워드 하나로 지난 한 달간 모든 서버에서 발생한 오류를 0.5초 만에 찾아냅니다.
• 시각적 대시보드: 시간대별 접속자 추이, 가장 많이 발생하는 에러 유형을 파이 차트와 그래프로 감상합니다.
• 이상 징후 감지: 로그 유입량이 갑자기 늘어나면 대시보드가 이를 시각적으로 알려주어 디도스(DDoS) 공격 등을 조기에 발견합니다.

---

5. 실험 요약 및 역할 분담

구성 요소	역할	비유
Elasticsearch	로그 데이터 저장 및 검색 엔진	거대한 도서관 서고
Logstash	데이터 수집 및 포맷 변환	책을 분류하는 사서
Kibana	데이터 시각화 및 대시보드	도서 검색 키오스크
Filebeat	경량 로그 전송기 (수집책)	책을 실어 나르는 수레

---

6. 마치며: 당신의 서버는 어떤 이야기를 하고 있나요?

리눅스 기초 47단계를 거치며 우리는 이제 시스템의 모든 움직임을 기록하고 분석하는 고도의 인프라 환경을 완성해 가고 있습니다. 엔진(커널)이 내뱉는 수많은 파편 같은 로그들은, 하나로 묶였을 때 비로소 의미 있는 정보가 됩니다. ELK 스택은 여러분의 리눅스 서버에 '기억력'과 '지능'을 더해주는 도구입니다.

오늘의 인사이트: "로그를 남기는 것은 기본이고, 그 로그를 한눈에 보는 것은 실력이다."

---

47번째 이야기를 마칩니다. 이제 우리만의 '데이터 센터' 기초가 다져졌습니다. 다음 시간에는 리눅스 기초 시리즈의 대단원을 앞두고, '운영체제의 심장, 리눅스 커널 파라미터(sysctl) 튜닝으로 서버 한계 성능 끌어올리기'에 대해 다뤄보겠습니다.

이 글이 여러분의 서버 관리를 더 스마트하게 만들었나요? 혹시 ELK 스택이 사양을 너무 많이 잡아먹어 고민이신가요?

저사양 서버를 위한 경량화 버전인 'Loki 스택' 혹은 'EFK 스택' 비교 가이드를 다음 포스팅 부록으로 준비해 드릴까요?