로그 관리의 왕: ELK Stack (Elasticsearch, Logstash, Kibana)

1. grep으로는 한계가 온다

애플리케이션을 처음 개발할 때는 로그 파일 하나면 충분합니다. 터미널 열고 tail -f server.log만 띄워놔도 무슨 일이 일어나는지, 누가 들어왔는지 다 알 수 있죠. 하지만 서비스가 커지고 MSA(마이크로서비스)를 도입하면 재앙이 시작됩니다.

• 지난주 화요일 오후 2시의 로그를 찾으려면 50대 서버를 다 뒤져야 합니다.

그래서 우리는 "로그를 한곳에 모으고, 검색할 수 있는 시스템"이 필요합니다. 그 표준이 바로 ELK Stack입니다.

---

2. ELK Stack의 3대장

ELK는 세 가지 오픈소스 프로젝트의 앞글자를 딴 것입니다.

2.1. Elasticsearch (E) - 검색 엔진

• 역할: 로그를 저장하고 검색하는 두뇌입니다.
• 특징: 일반적인 DB(RDBMS)가 아닙니다. 역색인(Inverted Index) 구조를 사용하여 텍스트 검색에 특화되어 있습니다. 수억 건의 로그 중에서 "Error"라는 단어가 포함된 줄을 0.1초 만에 찾아냅니다. 구글 검색창을 내 서버 로그에 달았다고 생각하면 됩니다.

2.2. Logstash (L) - 수집 및 가공

• 역할: 데이터를 수집해서 Elasticsearch에 예쁘게 넣어주는 파이프라인입니다.
• 특징: 단순히 옮기는 게 아니라 변환(Transform)을 합니다.
  • 비정형 데이터인 로그 문자열을 분석해서 JSON으로 바꿉니다.
  • IP 주소를 GeoIP로 분석해서 "어느 나라 접속인지" 정보를 추가합니다.
  • 민감한 개인정보(주민번호 등)를 마스킹 처리할 수도 있습니다.
• 참고: 최근에는 조금 무거워서 Fluentd나 Beats로 대체되기도 합니다.

2.3. Kibana (K) - 시각화

• 역할: Elasticsearch에 저장된 데이터를 눈으로 보여주는 대시보드입니다.
• 특징:
  • Discover: 로그를 검색하고 필터링하는 화면. (가장 많이 씀)
  • Visualize: "시간대별 에러 발생 추이", "국가별 접속 분포" 같은 그래프를 그립니다.
  • Dashboard: 여러 그래프를 한 화면에 모아서 상황판을 만듭니다.

---

3. ELK에서 ELKB로 (Beats의 등장)

Logstash는 강력하지만 무겁습니다. (JVM 위에서 돔). 모든 웹 서버마다 Logstash를 설치하는 건 부담스럽습니다. 그래서 Beats라는 경량 수집기가 등장했습니다. (Go 언어로 작성됨)

• Filebeat: 로그 파일만 읽어서 보냄.
• Metricbeat: CPU, 메모리 사용량 보냄.
• Packetbeat: 네트워크 패킷 보냄.

그래서 요즘은 ELK + Beats 구조를 많이 씁니다. Filebeat (수집) -> Logstash (가공) -> Elasticsearch (저장) -> Kibana (조회)

---

4. 왕좌의 도전 - OpenSearch와 Loki

Elasticsearch가 라이선스 정책을 변경하면서(오픈소스 -> 유료 기능 포함), AWS가 포크(Fork)를 떠서 OpenSearch라는 프로젝트를 만들었습니다. 지금은 기능이 거의 비슷하지만, 클라우드 서비스를 쓴다면 AWS OpenSearch Service를 더 많이 쓰게 됩니다. 둘은 배다른 형제입니다.

한편, Grafana Labs는 Loki라는 새로운 로깅 시스템을 내놓았습니다.

• Elasticsearch: 로그의 "내용"까지 전부 인덱싱함. (검색이 빠르지만 로그 용량을 많이 차지함)
• Loki: 로그의 "라벨(시간, 서버명)"만 인덱싱함. (검색은 조금 느리지만 비용이 엄청나게 저렴함)

"나는 로그 내용 검색(Full-text Search)이 중요하다" -> ELK "나는 그냥 시간순으로 로그 보고 비용 아끼고 싶다" -> Loki (Grafana와 찰떡궁합)

---

5. 로그 잘 남기는 법 - 로그 레벨 전략

ELK가 아무리 좋아도, 개발자가 로그를 System.out.println("aaaa") 이렇게 찍으면 소용이 없습니다. 로그 레벨(Level)을 확실히 구분해야 합니다.

• FATAL / CRITICAL: 프로세스가 죽는 상황. 즉시 기상 알람 발송. (예: OOM, DB 접속 불가)
• ERROR: 비즈니스 로직 실패. 누군가 아침에 확인해야 함. (예: 결제 실패, 중요 API 타임아웃)
• WARN: 당장 문제는 아닌데 이상함. 추후 확인 필요. (예: CPU 사용량 85% 초과, Deprecated API 호출)
• INFO: 정상 작동 로그. 흐름 파악용. (예: 서버 시작됨, 배치 작업 완료)
• DEBUG: 개발할 때만 켜는 디버깅용. 운영에서는 끄는 게 정석. (너무 많이 쌓이니까)

운영 환경(Production) 기본 설정은 보통 INFO입니다. DEBUG 레벨을 운영에서 켜두면 디스크가 1시간 만에 꽉 찰 수 있으니 주의하세요.

---

6. ELK 운영 팁 - 초록, 노랑, 빨강 (Cluster Health)

Elasticsearch를 운영하다 보면 클러스터 상태(Cluster Health)를 자주 보게 됩니다.

• Green (초록): 모든 샤드(Primary + Replica)가 정상입니다. 행복합니다.
• Yellow (노랑): 데이터는 다 있는데(Primary 정상), 백업본(Replica)이 아직 안 만들어졌습니다.
  • 노드 하나가 죽으면 데이터 유실 가능성이 있습니다. 주로 노드를 막 추가했을 때 보입니다.
• Red (빨강): 비상 사태. 일부 데이터(Primary Shard)가 사라졌습니다. 검색하면 일부 결과가 안 나옵니다.
  • 원인: 디스크가 꽉 찼거나(Disk Watermark), 노드 여러 개가 동시에 죽었을 때.
  • 조치: 빨리 죽은 노드를 살리거나, 디스크를 비워야 합니다.

---

7. 마무리 - 데이터가 힘이다

ELK Stack을 구축하면 단순히 "에러 찾는 속도"만 빨라지는 게 아닙니다.

• "우리 서비스는 점심시간에 트래픽이 3배 튀는구나."
• "특정 API가 유독 느리구나."
• "공격 시도가 특정 국가에서 많이 들어오는구나."

로그 데이터에서 비즈니스 인사이트를 얻을 수 있게 됩니다. 로그는 그냥 버려지는 텍스트가 아니라, 여러분 서비스의 블랙박스 데이터입니다. 잘 모아서 활용하세요.

---

---