EKS Fargate 유형 애플리케이션 로그 수집 Part 1

1. 포스팅하는 이유

 
서비스를 처음 맡게 되었을 때 인프라가 EKS Fargate 유형을 사용하고 있었다. 로그 수집을 위해 FluentD를 사용하고 있었는데, 아이러니하게도 Control Plane 노드(master 노드에서 명칭이 변경된 걸로 암, 이하 CP라고 칭하겠음) 로그들만 수집하고 있었다. 물론 CP 노드의 로그들을 수집하면, 클러스터 모니터링의 일부분은 구성할 수 있다.
 
하지만 정작 중요한 애플리케이션 로그들과 워커 노드들의 상태를 수집하고 있지 않았다. 정확하게는 수집할 수 없었다고 말하는 게 맞다.
 
그 이유는 Fargate 유형의 특성과 연관이 있는데, Fargate의 특성과 한계점에 대해서는 밑에서 알아보도록 하자. 하지만 애플리케이션 로그들도 중요하고, 워커 노드들의 상태를 모니터링할 수 있어야 장애에 빠르게 대응할 수 있다고 생각했다.  
 

애플리케이션 로그들과 워커 노드의 정보를 수집하는 방법은 없을까?

 
고민이 들기 시작했고, 굉장히 많은 삽질로 얻은 것에 대해서 포스팅을 하려고 한다. 
 
혹여나 같은 상황에 직면한 사람들이 있다면, 해당 포스팅이 유익했으면 한다.
 

2. EKS Fargate 특성

 
먼저 컴퓨팅 엔진의 큰 종류를 알아보자면, EC2가 프로비저닝 컴퓨팅 엔진이고, Lambda가 서버리스 컴퓨팅 엔진이다. 우리가 알아볼 AWS의 Fargate는 컨테이너용 서버리스 컴퓨팅 엔진이다. 한 마디로 Lambda처럼 프로비저닝을 신경 쓰지 않고, 개발자는 애플리케이션 코드 부분만 신경 쓰면 되는 장점이 있다. Fargate도 Saving Plan이 가능하므로, 사용하고 있지 않다면 사용을 추천한다 최소 20%~40%까지 저렴하게 이용할 수 있다. 
 
앞에서 말했듯이 컨테이너 서버리스 컴퓨팅 엔진이므로 EKS에만 종속된 서비스는 아니고, 컨테이너 기반으로 동작하는 ECS에도 사용 가능하다. 여기까지만 본다면, Fargate는 완벽하다. 프로비저닝을 신경 쓰지 않아도 되고, Lambda처럼 사용한 vCPU만큼의 비용만 지불하면 되기 때문에 워크 로드가 일정하지 않거나, 불규칙적인 경우 비용 측면에서도 유리할 수 있기 때문이다. 하지만 Fargate에는 확장성이라는 한계가 존재한다.

 

3. Fargate 유형의 한계점

 
앞에서 언급한 확장성의 한계는 내가 겪은 문제를 예시로 사용할 예정이다.
 
나는 FluentD보다 경령화된 Fluent Bit를 이용해서 EKS 및 애플리케이션의 상태를 수집하고자 했다. 이때 AWS의 WorkShop이라던지 공식 문서를 찾으면 AWS에서 Fluent Bit를 기본적으로 적용할 수 있도록 도움을 주는 GitHub 링크를 제공한다. 해당 절차에 따라서 적용했으나, Fluent Bit Yaml 파일에는 DaemonSet 형태로 배포하고 있었는데 CP 노드를 제외하고, 나머지 노드들에 배포가 되지 않은 현상을 겪었다. 문제를 해결하기 위해 Fargate 유형의 공식 문서를 찾아봤다.
 
원인 1. Fargate 프로파일에 작성되지 않으면, fargate-schedular가 동작하지 않아 파드 할당이 불가능
원인 2.Fargate에 의해서 생성된 노드들은 Taint가 걸려 있음
 
이제 원하는 대로 동작을 시키기 위해선 해당 원인들을 해결해야 한다. 
 

4. 나의 소중한 삽질

 

원인 1. Fargate 프로파일에 작성되지 않으면, fargate-schedular가 동작하지 않아 파드 할당이 불가능 해결법

 
EKS의 Fargate 프로파일은 여러 개의 namespace와 label 같은 걸로 구성할 수 있기 때문에 namespace가 추가된다면, 설정 파일에 추가하면 된다. Cloud9를 이용하고 있었기 때문에 CLI로 해결하려 했으나, 복잡했다. 따라서 EKS 콘솔에 들어가서 Fargate 프로파일을 수정했다.
 

원인 2. Fargate에 의해서 생성된 노드들은 Taint가 걸려 있음 해결법

 
Fargate로 생성된 노드들은 기본적으로 아래와 같은 Taint가 걸려있다.
 

effect: NoSchedule

key: eks.amazonawws.com/compute-type

value: fargate

 
따라서 Toleration을 추가해주면 Taint를 무력화해줄 수 있다.
 
하지만 그럼에도 Fluent Bit 파드가 실행되지 않았다. 이유를 더 찾아보니 Fargate 유형은 하나의 노드에 하나의 파드만 실행할 수 있도록 설정이 구성됐다는 것이다. 공식 문서에서 Since Amazon EKS Fargate runs only one pod per node라는 문구를 확인할 수 있다.
 

즉 원인3. Fargate 유형은 한 개의 노드에는 한 개의 파드만 할당할 수 있음

 
이제 AWS 제공하는 방법인 DaemonSet으로 배포하려면 Fargate를 포기해야 한다.(나의 한계일 수도 있음)
 
그래서 내가 내린 결론은 DaemonSet으로 배포하지 않으면 되겠네!! 였다.
 

5. 한계를 극복한 방법

 
Fargate의 제한 사항으로 인해서 DaemonSet으로 배포할 수없다면, Side Car 패턴으로 하나의 Pod안에 Fluent Bit 컨테이너를 추가로 보내면 된다. 잘못된 지식으로 1 파드=1 컨테이너라고 알고 있는 분들도 있겠지만, 정확히는 1 파드=N컨테이너다.
 
Fluent Bit의 DaemonSet을 Side Car 패턴으로 변경하는 것은 매우 간단하다. DaemonSet에 쓰여있는 것들을 그대로 사용해도 되기 때문이다.(helm chart로 구성돼 있으면, 설정 값들을 일일이 환경 변수로 넣어줘야 했어서 애먹었을지도 모르겠다.)
 

6.  다음 이야기

 
해당 포스팅에서는 매우 이론적인 부분만 다뤘다. Hands On까지 넣고 싶었지만, 글이 너무 복잡해지고 길어질 것이라고 생각했다.
 
따라서 다음 Part2에서 위에서 겪은 상황들을 재구성해보고, 해결법까지 적용해 볼 예정이다. 
 
(일이 너무 바빠져, 언제 포스팅할지는 미지수다.)