통합 로그 시스템 비교

통합 로그 시스템 필요성

• 기존에는 각 MicroService가 (Pod 단위로) Log 파일을 만들고, 그 로그파일을Persistent Volume Claim에 저장함으로써 로그 파일을 한 군데에서 관리하는 시스템이었다.
• 장애가 날 경우 어디 MicroService 문제인지 추측해서 그 Pod의 Log를 열어서 일일이 로그파일을 확인해야 문제를 파악할 수 있었다.
• 🙃 As-is
  • 알람이 오지 않기 때문에 장애 파악이 느리다 (사용자가 문제를 발견했을 때 알게됨)
  • 여러 로그 파일을 열어봐야함. 여러개의 로그창을 띄워놓고 문제를 파악해야함
  • Info,Error 정보가 섞여있어 Error메세지만 찾기 어려움
• 🙂 To-be
  • 한군데에서 여러 MicroService의 로그파일을 관리할 수 있어야 한다.
  • 쿼리로 원하는 로그 메세지만 필터링해서 뽑아낼 수 있어야 한다.
  • 특정 에러 메세지가 일정 횟수 이상으로 발생하면 Slack 으로 알람이 와야 한다.

후보

1. Logz

• ELK를 대신 구축해주는 서비스(Logstash,ElasticSearch, Kibana)
• 장점
  • ELK 구축이 안되어 있는 경우 일일이 설치할 필요 없어서 간편
• 단점
  • 가격이 비쌈 👉 비용 (30일 기준 $1.56/per GB)

참고 자료

• https://logz.io/
• Log4J, Logback용 LogZ 라이브러리 사용법 (Azure 공식문서)
• Kibana 대시보드 만들기
  • Kibana: TimeSeries graph로 표현 + 쿼리로 원하는 로그만 조회 가능
    • 로그레벨, 로그 패턴 등으로 검색 가능
    • Kibana에서 제공하는 기능으로, Logz안쓰더라도 Kibana 연동하면 가능한 기능

2. CloudWatch + Kinesis

• CloudWatch Log: ec2의 설치되어 로그 수집. 애플리케이션 이름단위로 로그를 쌓을 수 있음
• Kinesis Data firehose
  • Kinesis는 다양한 데이터를 수집하고 원하는 형태의 데이터 포맷으로 만들어줄 수 있음
  • 원하는 데이터 포맷으로 변형할 수 있기 때문에 ElasticSearch, S3등 다양한 목적지(Data Warehouse)에 보낼 수 있음
• Elastic Search + Kibana
  • 오픈 소스 검색 엔진인 Elastic Search에 데이터를 저장하고 + 시각화는 Kibana로 한다
  • Elastic Search는 실시간 로그를 쌓아둘 수 있고, 빠르고 다양한 검색기능을 지원한다
• S3 + Athena
  • Kinesis를 통해 S3에 데이터를 보내 쌓아두고, Athena를 통해 S3로부터 직접 데이터를 쿼리하여 분석할 수도 있음
• 장점
  • 다양한 데이터 Storage에 로그파일을 저장할 필요가 있는 경우 Kinesis를 이용하면 다양한 포맷으로 저장할 수 있다
  • 로그 메세지를 가공해서 분석하고, 이를 바탕으로 비즈니스 인사이트를 뽑아내야하는 경우 유용할 것 같다
• 단점
  • 구축할 PaaS 서비스가 많기 때문에 번거롭고, 비용이 많이 들 것 같다
  • 로그레벨에 따른 단순 로그 메세지 검색만 필요로 하는 경우에는 다소 과한 스펙이다

참고 블로그

3. EKK 사용 (Filebeat + ElasticSearch + Kibana)

• Logstash 가 아니라 filebeat이 유리한 이유
  - MSA환경에서는 서비스와 함께 logshipper도 빠르게 생성과 소멸이 이루어져야함
  - filebeat은 상대적을 가벼움 (상대적으로 적은 리소스 소모)
  - 지정한 로그파일 또는 위치를 모니터링(변화 감지) 하고 그 로그 이벤트를 수집해 Elasticsearch 또는 Logstash로 전달하는 역할
  
  

참고 블로그: Filebeat

참고 블로그: ELK Stack 을 이용한 관제 시스템 만들기

비교

공통점

• 공통적으로 로그수집 서비스 → 데이터 Shipping 시스템 → Elastic Search → Kibana 구조
• Kibana에서 시각화, 로그 쿼리(검색)기능, 알람 기능을 활용한다

As-is

• 이미 Logstash, ElasticSearch가 구축되어 있음
• Logback, Kubernetes 설정으로 Pod별로 이름을 따서 로그 파일이 생성되고, 공유 디렉토리(Persistent Volume Claim)에 저장됨

이런 상황을 고려하여 1,2,3안을 비교해보았다.

비교

구분	1안 (Logz)	2안 (CloudWatch +Kinesis)	3안 (Filebeat)
장점	ELK 구축하지 않아도 됨	- CloudWatch Log 설치하여 애플리케이션 이름단위로 로그 수집가능, - Kinesis를 이용할경우 데이터 집계, 다양한 포맷으로 변환하여 각각의 Warehouse에 데이터 전송 가능	Docker 내에서도 Filebeat 실행시 ElasticSearch에 Dat 보낼 수 있음
단점	비용 (30일 기준 $1.56/per GB)	구축할게 많음, Log 수집만 필요한 경우에는 과한 기능	ELK가 없다면 일일이 구축해야함
의견	이미 ELK 구축 되어있어서 굳이 사용하지 않아도 될 것 같음	- 이미 K8s에서 서비스 이름별로 로그파일을 만들기 때문에 CloudWatch는 필요없을 것 같다. - S3없이 ElasticSearch에만 쌓을 생각이면 이미 Logstash 있으니 Kinesis는 필요 없을 것 같디	- 이미 ELK 구축이 되어있어서 가장 적합할 것 같음 - 다만 지금은 Persistent Volume Claim에 log파일들이 다 저장되기 때문에 Bastion에 설치하면 될 것 같음 - Persistent Volume, ElasticSearch 이중으로 로그가 영구저장되는데, 이를 방지하고자 한다면 Docker 내에 FileBeat를 실행시키고, 바로 ElasticSearch에 보내는 방법도 좋을 것 같음