[정리]AWS Cloudwatch에 EKS Log 전송하기
우선 해당 글은 로그 전송에 대한 실습이 아닌 해당 방법에 대한 정리글입니다!
이전에 정리한 내용에서 직접 실습하면서 조금 달라진 내용이 있어서 수정했습니다(2022.07.14 수정)
회사에서 EKS를 활용하게 되면서 어플리케이션 작업내역을 로깅 및 모니터링 해야할 필요가 있었고, 다른 오픈 소스를 활용하기보다 AWS cloudwatch를 활용해보고자 했다.
AWS의 공식문서를 참고하여 가장 대표적으로 Fluentd와 Fluent Bit을 사용하는 것을 알게 되었다. (AWS 공식문서)
이번 글에서는 실질적인 실습보다는 로깅을 위해 Fluentd와 Fluent Bit을 어떻게 활용할 수 있는지 이 둘은 어떤 차이가 있는지 개념적으로 정리해보려 한다.
참고 자료는 AWS공식문서를 중심으로 정리해보았다.
✅ Fluentd에 대한 지원은 곧 AWS에서 종료된다고 하니 참고
k8s Control plane vs Data plane
eks의 전반적인 작업들에 대해 로깅 및 모니터링하는 방법에 대해 정리하기 전에 우선 eks 즉 k8s의 구조에 대해서 잠깐 정리하고 가야겠다고 생각했다. 왜냐면 eks를 세팅을 할 때, 콘솔에서 로깅을 설정할 수 있는데, 실질적으로 이는 control plane에 대한 작업 로깅을 설정하는 것이기 때문이다.
k8s의 구조는 더 자세하게 정리하면 복잡하지만 대략적으로 정리해보면 control plane와 data plane 영역으로 나눌 수 있다.
contol plane
K8S 클러스터에 관한 전반적인 결정을 수행하고, 클러스터 이벤트를 감지하고 반응한다.
즉 실질적으로 여러 어플리케이션 작업이 실행되는 노드들에 대한 스케줄링, 컨트롤러 프로세스를 관리 하는 등의 "관리 감독" 역할을 하는 곳이다.
이를 aws eks에 대입해서 생각해보면, 우리가 aws에서 eks 클러스터를 만들게 되면 이 control plane을 만들게 되는 것이다.
기존에는 실제로 작업이 이루어지는 노드를 별도로 구성하고 프로비저닝 하기 위해 별도의 리소스가 필요했는데, 이제는 eks 콘솔에서 노드 그룹을 생성하고 프로비저닝 하는 것까지 가능해졌다.
data plane
위의 그림에서는 별도로 data plane에 대한 언급은 없으나, data plane은 control plane과 함께 k8s의 큰 구성요소 중 하나로 소개되고 있다. 이는 사용자의 어플리케이션이 실질적으로 구동될 수 있도록 도와주는 component를 나타낸다.
data plane의 component는 모든 worker node에 위치해 있으며, control plane에 응답하거나 data plane간에 요청/응답한다.
EKS Control Plane Logging
위의 설명에 따르면 우리가 aws 콘솔에서 eks를 세팅하는 것은 control plane을 세팅하는 것이고 따라서 control plane의 작업에 대한 로그는, 아래와 같이 AWS 콘솔을 활용하여서 cloudwatch에 전송되도록 쉽게 설정할 수 있다. AWS 공식문서 참고
위의 로그 유형에 대한 설명은 aws 공식문서를 참고했다.
1. Kubernetes API 서버 구성 요소 로그(api)
클러스터의 API 서버는 Kubernetes API가 표시되는 제어 영역 구성 요소이다. 포드, 서비스, 복제 컨트롤러 등을 포함하는 작업들이 실행되는데, 이러한 작업에 대한 로그를 의미한다.
2. 감사(audit)
Kubernetes 감사 로그는 클러스터에 영향을 주는 개별 사용자, 관리자 또는 시스템 구성 요소를 제공한다.
보안관련한 내역을 제공하는 것이다. 어떤 작업이, 언제, 누구에 의해 어떻게 발생했는지에 대한 로그 내역을 제공한다.
3. 인증자(authenticator)
인증자 로그는 Amazon EKS에 고유하다. 이러한 로그는 Amazon EKS가 IAM 자격 증명을 사용한 Kubernetes 역할 기반 액세스 제어(RBAC) 인증에 사용하는 제어 플레인 구성 요소를 나타낸다.
이는 위의 audit로그하고는 차이가 있는데, 여기서의 인증은 컴퓨터 혹은 네트워크 리소스에 대한 작업 내역을 제공하는 것이라고 보면 된다.
4. 컨트롤러 관리자(controllerManager)
컨트롤러 관리자는 Kubernetes와 함께 제공되는 핵심 컨트롤 루프를 관리한다.
5. 스케줄러(scheduler)
스케줄러 구성 요소는 클러스터에서 포드를 실행하는 시기와 위치를 관리한다.
EKS Data plane/Application Logging
그러나 eks cluster 자체에 대한 여러 관리 작업 로깅과 모니터링도 중요하지만, 실질적으로 각 워커 노드와 파드에서 실행되는 어플리케이션들에 대한 로깅과 모니터링도 매우 중요하다.
이를 위해서 container insight와 fluentd 혹은 fluent bit을 활용할 수 있다.
AWS Container Insights 란?
container insights란 aws cloudwatch에서 제공하는 기능 중 하나이다.
각각의 독립된 인스턴스나 하나의 큰 클러스터 단위가 아닌, 크게 컨테이너화된 여러 애플리케이션에 대한 지표 및 로그를 수집하고 집계 해준다.
즉 cloudwatch에서 컨테이너의 실질적인 작업에 대한 로그 모니터링 기능을 제공하는 것이다.
Fluentd vs Fluentd bit
위에서 설명한 container insight에서 로그들에 대한 집계와 모니터링을 제공한다면, 해당 기능에 작업 내역을 전달해줄 "로깅 수집 및 전달"을 해줄 추가적인 기능이 필요하다.
어플리케이션 단에 붙어서 로그를 cloudwatch에 전달해주는 역할을 Fluentd와 Fluent bit이 해주는 것이다.
그런데 곧 aws에서는 fluentd에 대한 기능 제공을 중지할 예정이므로, 아직 eks에 대한 로깅 세팅 작업을 하지 않았다면, fluentd가 아닌 fluent bit 사용을 권장하고 있다.
둘은 어떤 차이가 있일래 aws에서는 fluent bit 사용을 권장하는 것일까?
- fluentd bit은 fluentd의 경량화 버전이다.
- fluentd bit은 좀 더 성능에 집중되어 설계되었다. 즉 여러 입력에서 집계하여 데이터를 처리하는 등 많은 처리량을 목표로 한다. 그만큼 fluentd 보다 유연성이 떨어진다.
- fluent bit은 이미 배포된 환경에 대한 로그 수집을 지원한다. fluentd는 이러한 수집보다는 이렇게 수집된 로그에 대한 집계 역할에 좀 더 초점을 맞추고 있다.
- fluent bit - 로그 수집 / fluentd - 로그 집계
즉 k8s와 같은 분산클러스터에서는 같은 작업 일지라도 여러 파드/노드에서 작업 로그가 쌓이고 이러한 로그에 대한 수집 및 처리는 fluent bit을 활용하는 것이 더 효율적이라고 볼 수 있다.
또한 fluentd와 fluent bit은 서로가 대체의 기능을 하기보다는 함께 사용하여 보완될 수 있음을 위의 그림을 통해 이해할 수 있다.
즉 fluent bit으로 분산 클러스터에서 빠른 처리량으로 로그를 수집하고 이를 fluentd로 전송하여 로그를 집계하여 각 모니터링 서비스로 전달할 수 있는 것이다.
✅ fluent bit와 fluentd는 실제로 k8s의 로깅을 위한 것만이 아니라 자체적으로 로그 수집과 집계에 있어서 많이 활용되고 있으며, 대표적으로 log stash와도 같이 비교되어 ELK VS EFK 으로 많이 언급되고 있다. 이에 대해서도 후에 추가적으로 더 깊게 공부하고 정리해보려 한다.
Fluent bit 설치해서 로깅하기
eks cluster에 container insight(cloudwath agent)와 fluent bit demonset를 다운로드한 후에 클러스터에 배포하여 사용하면 된다.
결과적으로 위와 같은 구조로 eks 내에서 실행되는 각 작업들에 대한 로그가 수집되어 cloudwatch에서 모니터링 할 수 있게 된다.
위의 그림에서 알 수 있듯이 이러한 방법을 통해서 3개의 로그를 수집 및 모니터링 할 수 있다.
- Application logs : 실행에 대한 access log가 대표적
- Data plane logs : data plane을 구성하는 kubelet 및 컨테이너 런타임 엔진 로그
- Host logs: 호스트 수준의 보안 로그
cloudwatch에는 아래와 같이 로그 그룹이 생성되어서 실제로 로그를 확인할 수 있다.
위와 같이 수집된 로그들을 container insight에서 한꺼번에 관리할 수 있게된다.
마무리
해당 작업은 어떻게 보면 사용자가 흔히 생각하는 어플리케이션에 대한 실질적인 로깅과 모니터링 세팅 작업은 아니다.
eks의 control 작업과 / 실질적인 애플리케이션이 수행되는 data plane이나 노드들에 대한 시스템 로그를 모니터링 하기 위한 작업니다.
물론 이러한 어플리케이션 작업 내의 실질적인 서비스 실행과 관련된 로깅 및 모니터링은 별도의 작업을 필요로 한다.
이에 대한 구조를 이해하려면 우리가 인스턴스라는 가상 서버에 하나의 서비스를 띄워서 그 서비스의 실질적인 사용에 대한 로깅을 하고 싶은 경우를 생각하면 된다.
그 가상 서버 자체의 작업에 대한 로깅은 이러한 설정들로 충분하나, 서비스 자체에 대한 로깅은 서비스에 별도의 개발 과정을 거쳐야 하기 때문이다.
현재 airflow를 eks에 세팅하여 활용할 수 있도록 준비중인데, airflow 자체가 실행되는 파드와 전반적인 eks cluster에 대한 로깅과 모니터링은 aws에서 제공하는 공식 문서를 바탕으로 container insight와 fluent bit을 활용하려 한다.
그러나 airflow 서비스가 실행되는 과정에서의 로깅은 별도로 설정을 해주어야 하고 이 과정에서 추가적으로 정리할 내용이 있으면 또 공부해서 정리해보도록 하겠다.