ELK 마이그레이션 7.2 to 9.2.3

 

최근 사내 로그 관리 시스템인 ELK(Elasticsearch, Logstash, Kibana + APM) 스택을 7.2 버전에서 9.2.3 버전으로 마이그레이션 했습니다. 메이저 버전 업그레이드를 9버전으로 바로 넘어갔습니다.

 

이 업무를 진행하게된 이유는 레거시와 인프라 아키텍처 최적화의 목적으로 사용되지 않는 서비스, 데이터를 모두 정리하기 위해서입니다. 이번 마이그레이션 과정에서 겪은 변경점들과 이를 통해 얻게 된 이점에 대해 기록해보려고 합니다!

---

1. Filebeat 변경점: Log -> Filestream

filebeat의 type이 log Deprecated되며 9 메이저 버전에서는 filestream 방식이 강하게 권장되었습니다. 9.x 환경에서는 filestream 방식으로 기본값이 변경되었습니다. 그러면 왜 이러한 방식으로 변경했을까요?

 

대표적인 이유로는 "파일 추적 정확도(중복/유실 감소) + 대규모 환경에서의 성능/안정성"을 개선하려는 목적으로 변경했다고 합니다. 

 

Reference

https://www.elastic.co/docs/reference/beats/filebeat/migrate-to-filestream

Migrate log or container input configurations to filestream | Beats

 

Inode 기반 추적으로 변경

기존 log 방식이 파일의 경로와 이름을 기준으로 로그 파일을 인식했습니다. 하지만 filestream은 파일 고유의 Inode ID를 기반으로 파일을 식별합니다. (원래 리눅스 운영체제 내부에서는 파일을 inode를 기반으로 인식함)

또한 파일의 어디까지 읽었는지를 기록하는 Offset 관리 방식도 달라졌습니다. 이러한 변경은 로그 파일명이 변경되더라도 추적이 가능하다는 장점이 있습니다.

 

이러한 변경점에 대해서 이해하고 적용하는데에 있어서 기존의 로그 저장 방식에 적용가능하도록 노력했습니다. Logrotate 시에 파일 로테이션 과정에서 Inode가 재사용되거나 변경되는 시점을 Filebeat가 정확히 인지하지 못하면, 로그를 중복 수집하거나 아예 놓치는 경우가 발생할 수 있습니다. log type(tail_files: true)에서는 이러한 문제점이 발생하지 않았습니다. 저는 저희 플랫폼의 서버로그 저장 정책을 따라 Filebeat가 Inode 변경을 놓치지 않도록 설정을 조정했습니다.

 

2. Logstash 파이프라인 최적화

이 마이그레이션 작업은 오래된 파이프라인 설정을 재정비할 좋은 기회였습니다. 이전까지는 클라이언트 이벤트 로그 서버에서 발생하는 모든 Access 로그를 일단 Logstash로 전송한 뒤, Logstash 필터에서 불필요한 로그를 드랍(Drop)하는 방식을 사용해 왔습니다.

(ciritical 한 로그만 필터링해서 알림 시스템과 연동해 사용중이었음)

네트워크 비용과 리소스 낭비 제거

기존 ELK 클러스터링 방식에서는 문제가 없었지만, 저희는 네트워크 대역폭 문제를 겪고 있어서. 이러한 불필요한 네트워크 대역폭을 차지하는 것을 감내할 수 없었습니다. 어차피 버려질 로그가 네트워크 대역폭을 차지하고, Logstas에서는 필터링하기 위해서 CPU 프로세스 자원를 사용하고 있었습니다. 게다가 우리는 이미 별도의 로그 데이터 수집, 메트릭/모니터링 인프라를 갖추고 있었기에 모든 클라이언트 정상 로그를 ELK에 적재할 필요가 없었습니다.

 

따라서 저는 수집 전략을 바꿨습니다.

• Before: 모든 로그 전송 -> Logstash에서 필터링
• After: Filebeat에서 치명적 로그(Error, Fatal)만 필터링하여 전송

정상 로그는 클라이언트 로그 데이터 수집 파이프라인으로 보내고 ELK는 오직 이슈 대응을 위한 로그만 수집하도록 Filebeat 단에서 설정을 변경했습니다. 결론적으로 불필요한 트래픽을 없애 인프라 리소스 사용을 절약했고, Logstash의 부하를 상당히 많이(프로세스 사용량 30% 이상) 줄일 수 있었습니다.

---

3. Index Management : 날짜 기반 관리 -> ILM 위임

데이터가 저장되는 Elasticsearch 영역에서도 큰 변화가 있었습니다. 기존에는 Logstash 설정 파일에 YYYY.MM.DD 형식을 하드코딩하여 날짜별로 인덱스를 생성했습니다. 직관적이지만 인덱스 생명주기 관리 관점에서는 유연하지 못한 방식이라고 생각했습니다.

날짜 기반 관리의 단점

저는 날짜 기반으로 인덱싱을 관리하면 문제가 장애대응, 구조변경이 필요할 때 발생할거라고 생각했습니다.

 

예를 들어볼까요?

특정 인덱스에 매핑 오류가 발생해 Reindexing을 하거나 샤드 수를 조절하고 싶다고 합시다. 하지만 이미 해당 날짜의 이름을 가진 인덱스가 존재하기 때문에 충돌이 발생합니다. 이를 우회하기 위해 임시 인덱스를 만들고 Alias를 교체하는 과정은 번거롭고 휴먼 에러가 발생하기 쉽습니다.

 

저는 날짜 기반 인덱스 이름 방식을 버리고 ILM(Index Lifecycle Management)과 Index Template에 완전히 인덱스 관리에 대한 책임을 주는 것으로 전환했습니다. 이 방식은 Elasticsearch가 인덱스의 샤드 용량 크기, 시간(하루, 일주일) 등을 종합적으로 조건을 걸고 자동으로 Rollover를 수행해주는 것입니다.

 

ILM과 Template을 통한 자동화

이제 인덱스 관리의 주도권은 Elasticsearch가 가집니다.

• 조건 기반 Rollover: 날짜가 아닌 샤드 크기(예: 50GB)나 문서 수를 기준으로 인덱스를 자동으로 Rollover합니다.
• 유연성 확보: 특정 인덱스가 과도하게 커져 성능을 저하시키는 문제를 방지하고, 데이터 수명 주기를 정책 코드로 관리할 수 있게 되었습니다.

---

4. EndUser서버 APM 이전

이번 마이그레이션의 또 다른 핵심 과제는 EndUser 서버에 APM(Application Performance Monitoring)을 이전하는 것이었습니다.

 

이 부분에 대해서 제가 한 일은 많지는 않았습니다. 저는 기존 APM agent 버전, 코드를 확인하고 마이그레이션 가능 여부와 코드 변경점이 필요한지 체크하여 게임 서버 파트 분들에게 Request 를 보냈습니다.

 

따라서 변경점에 대해서 가볍게 읽고 넘어가겠습니다.

 

가장 큰 변화는 Data Streams이 완전히 적용되었습니다.

• 7.x: apm-*라는 단일 인덱스 패턴에 의존
• 9.x: APM 데이터가 성격에 따라 traces-apm-*, metrics-apm-* 등으로 자동 분류되어 Data Streams 형태로 이전보다 더 세분화해 저장

이러한 변화로 앞에서 말한 ILM 정책을 APM 데이터에도 일관성 있게 적용할 수 있었습니다. 게임 서버에서 발생하는 방대한 트레이싱 데이터도 ILM을 통해 상황에 맞게 생명주기를 튜닝할 수 있는 것입니다. 결론적으로 저희 팀은 문제가 발생한 게임 로직의 지연 시간을 직관적으로 파악하고, 불필요한 로그 데이터 관리의 부담을 덜수 있었습니다.

---

5. 마치며

마이그레이션 후, 성능 향상은 명확했습니다. ELK 9.2.3에 탑재된 Lucene 10 엔진의 힘으로, 하루 수억 건의 로그가 유입되는 환경에서도 대시보드 로딩 속도가 10초에서 5초 이내로 단축되었습니다.

 

Elasticsearch의 세그먼트 머지(Segment Merge), BKD 트리 같은 내부 자료구조를 공부하고, 우리 시스템에 최적화된 설정을 찾아가는 과정을 겪었습니다. "기존 설정을 그대로 옮기자"는 생각도 있었지만, 새로 구축하며 레거시를 걷어낸 덕분에 인프라 리소스 비용 절감과 성능 향상이라는 좋은 결과를 얻을 수 있었던 것 같습니다. 

 

의사결정, 히스토리 부분에 대해 시니어 분들의 도움을 많이 받았습니다. 감사하게 생각하고 있습니다.

항상 업무를 하며 기본에 대해서 중요함을 느끼게 됩니다. 정진합시다!! :)

---

2026-02-18
+ 추가적으로 elasalert 기반의 로그 모니터링 시스템, Kibana 대시보드 고도화를 진행했습니다.

설 연휴기간 동안 elasalert 덕분에 대형사건 하나 막을 수 있었는데. 좋아해야하나 ??.. ㅎㅎ;;