로그 데이터를 수집하는 방법에 대해서

 

현재 필자의 시스템은 MSA로 구성되어있다. 그리고 각 마이크로서비스의 로그 기록은 Elasticsearch에 기록되고 있는데
그 방식이 조금 특이(?)하다.

전통적인 EFK 시스템을 통해서 기록되는 것이 아니라 로그라이브러리를 통해 기록되고 있기 때문이다.

 

왜 로그라이브러리를 통해서 로그 데이터를 기록하게 됐는지, 각각의 장단점은 무엇인지 간략하게 설명하고자한다.

 

로깅 라이브러리를 통해서 Elasticsearch로 전송하는 방식

장점

• 구조 단순성
  Fluentd, Logstash와 같은 추가적인 로그 수집 레이어를 생략할 수 있다.
  애플리케이션과 Elasticsearch 사이의 연동만 설정하면 되므로 관리할 구성요소가 줄어든다.
  로그 장애 포인트는 Elasticsearch 하나로 줄어듬.
• 유연성
  데이터 포맷을 애플리케이션 내부에서 JSON으로 구성할 수 있다.
  특정 애플리케이션에서만 별도의 Elasticsearch 인덱스를 관리하는 등 커스터마이징을 하기 쉽다.

단점

• 코드 의존성 증가
  여러 언어에서 동일한 로깅 기능을 구현하려면 각 언어별로 로깅라이브러리를 만들어서 제공해야한다.
• 확장성 문제
  Elasticsearch 클러스터가 일시적으로 과부하 상태가 되면 애플리케이션에서 로그 전송 실패가 발생할 수 있다.

 

EFK 시스템을 사용하여 로그 전송

장점

• 유지보수와 단순화
  애플리케이션 로깅 코드와 Elasticsearch 연동을 분리하므로, 애플리케이션 개발과 로그 관리가 독립적으로 이루어질 수 있음
• 확장성 및 복구성
  Fluentd는 로그를 일시적으로 버퍼링하므로, Elasticsearch의 일시적 과부하나 네트워크 장애에도 로그 손실이 발생하지 않음
  다양한 출력 대상을 쉽게 연동 가능

단점

• 초기 설정 복잡성
  EFK 스택 설치와 구성은 상대적으로 복잡하며, 모든 애플리케이션과 Fluentd 설정을 맞추는 과정이 필요
  Fluentd, Elasticsearch, Kibana의 리소스 관리가 추가로 요구됨
• 리소스 소모
  Fluentd와 Elasticsearch 모두 추가적인 리소스를 사용하며, 클러스터의 노드 용량이 부족할 경우 영향을 미칠 수 있음
• 장애 점 추가
  Fluentd나 Elasticsearch의 장애가 발생하면 전체 로그 수집 파이프라인에 영향을 미칠 수 있음

 

어떤 방식을 선택해야 할까?

로깅 라이브러리를 사용해볼 수 있는 경우:

• 로그 수집 대상이 소수의 애플리케이션이고, 모든 애플리케이션이 동일한 로깅 라이브러리를 쉽게 사용할 수 있는 경우.
  필자는 모든 언어가 Go로 구성되어 있고 소수의 애플리케이션을 운영하고 있다.
• 간단한 시스템에서 로그 관리를 시작하고 싶거나, 중앙 집중형 관리 시스템을 구축할 필요가 없는 경우.
• Elasticsearch와의 직접 통합이 필요하고, 중간 단계에서 추가 작업이 필요하지 않은 경우.

EFK 시스템이 적합한 경우:

• 대규모의 분산 시스템에서 많은 애플리케이션이 실행되고 있는 경우.
• 로그를 다수의 저장소나 서비스로 전송해야 하거나, 다양한 포맷의 로그를 처리해야 하는 경우.
• 중앙 집중형 로그 관리와 시각화가 중요한 경우. (예: DevOps, 운영팀이 Kibana를 적극 활용)
• 장애 복구 및 확장성을 고려해야 하는 상황.

 

결론

로깅 라이브러리를 통한 방식은 간결하며, 초기 구성과 관리가 용이하지만 확장성 측면에서 한계가 있을 수 있다. 반면, EFK 시스템은 확장성과 중앙 집중화에 유리하나 리소스 소모와 복잡성이 증가한다.

현재 환경과 요구 사항에 따라 로깅 전략을 선택하되, EFK 스택 도입 여부는 시스템 복잡성과 로그 관리 요구 수준에 따라 판단하는 것이 적절하다고 생각한다.