EFK란?
Elasticsearch, Fluentd, Kibana 라는 각각의 툴을 사용한 데이터 수집 및 시각화 스택을 말한다. 여기서 말하는 데이터는 어느 종류든 상관없다. 시스템 로그든 비즈니스 매트릭 데이터든 원하는 데이터를 EFK를 통해 수집 및 분석할 수 있다. (다만 json 형태여야 한다)
각각의 툴이 하는 역할은 다음과 같다
-
fluentd: 통합된 로깅 레이어를 위한 오픈 소스 데이터 수집기이다. 데이터가 만들어지는 곳에 붙어서 해당 데이터를 모으는 역할을 한다.
-
elasticsearch: 분산된 검색 및 분석 엔진이다. 수집한 대용량의 데이터를 인덱싱(엄밀하게 따지면 역인덱싱)하여 저장하고 이를 검색할 수 있는 기능을 제공한다.
-
kibana: 데이터 시각화 UI 도구이다. kibana를 통해 elasticsearch가 수집한 데이터를 보다 사용자 친화적으로 확인할 수 있다. 또한 대시보드를 제작하여 로우 데이터로부터 유의미한 인사이트를 얻을 수 있다.
EFK 아키텍처 및 흐름
출처: https://medium.com/avmconsulting-blog/how-to-deploy-an-efk-stack-to-kubernetes-ebc1b539d063
- 각 쿠버네티스 환경에 배포된 시스템에서 나오는 데이터를 fluentd가 수집한다
- fluentd가 이 데이터를 elasticsearch에서 보내주면, elasticsearch는 인덱싱하여 저장한다.
- elasticsearch와 연결된 kibana UI에서 해당 데이터를 볼 수 있다
es와 persistentVolumeClaim과 연결된 부분은 중간에 데이터 유실을 막기 위해 aws s3와 같은 영속적인 데이터 스토리지에 저장해두는 것으로 보인다
그럼 ELK는?
EFK와 동일하게 데이터 수집 및 시각화 목적의 스택이지만 fluentd 대신 logstash를 사용한다. elasitcsearch와 kibana가 ELK에서 하는 역할은 EFK와 동일하다. logstash에 대한 설명은 다음과 같다.
- logstash: 다양한 소스로부터 데이터를 수집하고 곧바로 전환하여 원하는 대상에 전송할 수 있도록 하는 경량의 오픈 소스 서버측 데이터 처리 파이프라인. 수집한 데이터에서 민감한 정보를 마스킹하거나 timestamp 값을 다른 형태로 변환하는 등의 데이터 조작 작업을 할 수 있다.
약자에는 없지만 ELK 스택을 구현하기 위해서는 Beats라는 툴도 필요하다 Beats는 EFK에서 fluentd가 하는 역할과 동일하다 (MySQL과 같은 데이터 베이스의 데이터를 수집할 때는 Beats가 필요없지만 로그와 같이 어플리케이션에서 생성되는 데이터를 수집할려면 필요함)
- beats: 단일 목적의 데이터 수집기 무료 오픈 소스 플랫폼
EFK 아키텍처 및 흐름
사진 출처: https://www.guru99.com/ko/elk-stack-tutorial.html
- 데이터 원천에 beat가 붙어서 데이터를 수집한다. EFK 아키텍쳐와 마찬가지로 여러 대의 데이터 원천 각각에 beats가 붙어서 데이터를 수집할 수 있다.
- beats가 수집한 데이터를 logstash에서 적절하게 처리한 뒤 es로 보낸다 ex) GMT 형식의 timestamp값을 KST로 변환 등
- elasticsearch는 이 데이터를 인덱싱하여 저장한다.
- elasticsearch와 연결된 kibana UI에서 해당 데이터를 볼 수 있다.
왜, 그리고 언제 사용해야 하는지
MSA 기반 어플리케이션에서 생성된 로그 관리용
MSA에는 여러 대의 분산된 마이크로 서버가 돌아가고 있기 때문에 한 서버에서 장애가 발생할 경우 다른 마이크로 서비스로 쉽게 전파된다. 이 에러가 다시 다른 마이크로 서비스로 전파되고 또 전파 전파 전파되고.. 이렇게 되면 어디서 왜 에러가 발생했는지 추적하기가 어렵다. 에러 추적 및 모니터링을 위해 각 마이크로 서버의 로그를 한데 모아 관리하고 어플리케이션의 개발자가 찾아볼 수 있도록 하기 위해 사용한다.
로그 관리용
MSA가 아닌 모놀레틱 아키텍쳐 시스템에서라도 로그 데이터를 수집하기 위해 사용할 수 있다. 마찬가지로 시스템에서 발생하는 로그를 저장해 추후 에러 발생 시 로그를 확인하기 위해 사용한다. 또한 슬랙이나 이메일과 같은 서드파티 툴과 함께 사용되어서 모니터링도 가능하다.
다만 개인적인 생각으로는 모놀레틱 아키텍쳐이면서 로그 데이터를 수집하려는 목적으로는 오버스팩이라고 생각한다. 쉘스크립트를 사용해서 로그 파일을 남길 수 있고 어차피 서버 한대라 데이터 소스도 하나기 때문에 여러 군데에서 모을 필요도 없다. 에러 발생 시 슬랙 알람 기능도 프로그램 내에서 구현 가능하므로 모니터링 목적도 충분히 다른 방식으로 달성 가능하다.
비즈니스 매트릭 데이터 수집용
월별 신규 가입자 수, 일별 결제 금액 등의 정책적인 인사이트를 얻기 위해서도 사용할 수 있다. 다만 이는 amplitude나 믹스패널과 같은 기획용 데이터 분석 및 시각화 툴도 시중에 많이 나와있어 이걸로도 대체 가능하다
그렇다면 둘 중에 어느 스택을 사용해야 하는지?
그럼 EFK랑 ELK 둘 중에 뭘 사용하는게 좋을까?? 솔직히 둘 중에 뭐가 엄청나게 더 뛰어난 건 없다(고 생각한다) EFK와 ELK는 다른 데이터 collecter를 사용하기 때문에(fluentd/Beats) 이 데이터 collecter를 붙여야 하는 시스템 환경이 무엇인지 정도만 고려 사항에 들어간다고 생각한다
fluentd는 Treasure Data에서 개발되었기 때문에 쿠버네티스 환경에서 시스템이 돌아간다면 호환성을 고려하여 fluentd를 사용하기도 한다. 그렇다고 Beats가 쿠버네티스 기반 어플리케이션과 호환이 안되는 것도 아니다. 또한 데이터 collecter를 제외한 나머지 툴은 전부 elastic사에서 개발되었기 때문에 스택 내 호환성을 생각하면 logstash를 사용하는게 좋을 수도 있다.
두 스택 모두 사용해봤는데 쿠버네티스로 배포한 어플리케이션에는 EFK를, 쿠버네티스 없이 AWS EC2로 배포한 어플리케이션에서는 ELK를 사용해서 그런지 큰 차이는 못느꼈다. fluentd와 logstash를 구글링해봤을 때 트러블슈팅 해결책 포스팅 양을 비교해보는게 오히려 좋은 지표가 될 수도 있을지도 모르겠다..
피드백은 언제나 환영입니다!
참고
https://www.fluentd.org/
https://www.elastic.co/kr/logstash
https://aws.amazon.com/ko/what-is/elk-stack/
