배경

최근 Cloud Engineer에서 DevOps Engineer로 직무변경을 하며 이직에 성공했습니다.
인수인계를 받고 클라우드 구성을 파악한 뒤 가장 처음으로 맡게된 업무가 기존의 로그수집 환경을 개선하는 것이었습니다.

현재 직장에서는 서비스의 로그 수집을 별도 EC2에 설치한 LogStash에서 Kubernetes Cluster에 Container로 배포된 Fluentd 기반의 로그수집 방식으로 전환하는 작업을 진행하고 있습니다.
현재 환경은 Service -> Confluent(kafka) ->LogStash-> AWS OpenSearch(Elastic Search)로 로그를 수집하고 있는데, 이를 Service 를 통해 로그를 수지 및 전달하는 형태로 전환하는 것입니다.

현재 LogStash가 설치된 EC2와 Confluent Kafka로 이어지는 구성에서는 LogStash로 인한 인스턴스 비용과 Kubernetes에 위치한 Service들이 LogStash로 로그를 전송하면서 발생하는 데이터 전송 비용이 상대적으로 큽니다.
이를 Kubernetse Container기반의 로그 수집 환경으로 전환한다면 EC2와 Confluent에 대한 비용을 절약할 수 있습니다.

물론 향후 트래픽이 늘어난다면 전환한 환경에서도 kafka나 AWS kinesis와 같은 메시지큐나 데이터 스트리밍을 담당하는 솔루션을 추가해야겠지만 전자보다는 비용적으로 확실히 유리합니다.

이 시리즈에서는 LogStash 기반의 로그 수집 환경을 Fluentd를 활용한 Container기반의 로그 수집 환경으로 전환하면서의 의사 결졍과 발생하는 문제점들을 해결해나가는 과정을 작성해보려고 합니다.

그 과정에서 Kubernetes Cluster가 배포되어 있다고 가정하고, 간단한 Prototype Loggin Application을 만들고, Container이미지로 만들고, 로그를 수집하는 작업을 거칠 예정입니다.

누가 이 글을 보게되실지 모르겠지만 기본적으로 Kubernetes Cluster를 구성하고 리소스를 배포할정도의 지식은 갖추고 계신다고 가정하고 리소스 생성에 대한 부분은 많은 부분 생략하겠습니다.