EKS 클러스터에 간단한 Flask 어플리케이션 배포하기
서버 로그 수집에 Fluent Bit 를 도입할 수 있을지 탐색할 계획입니다. 현재 소속된 팀의 서버 개발자 분들은 Amazon EKS 로 Kubernetes 클러스터를 운영하고 있습니다. 그래서 일단 Kubernetes 에 대해 어느정도 이해가 필요할 것 같아서 직접 써보며 익혀보려고 합니다.
software engineer
서버 로그 수집에 Fluent Bit 를 도입할 수 있을지 탐색할 계획입니다. 현재 소속된 팀의 서버 개발자 분들은 Amazon EKS 로 Kubernetes 클러스터를 운영하고 있습니다. 그래서 일단 Kubernetes 에 대해 어느정도 이해가 필요할 것 같아서 직접 써보며 익혀보려고 합니다.
이전까지는 생성자에 schedule_interval 을 적어서 DAG 를 주기적으로 실행했습니다. 그러던 중 Airflow 외부의 배치 프로그램이 끝날 때 마다 DAG 를 Trigger 하고 싶은 상황이 생겼습니다. 방법을 찾아보다가 Triggering DAGs (workflows) 문서를 발견했고 적용해봤습니다.
올해 데이터야 놀자 행사에서 타다(TADA) 서비스의 데이터 웨어하우스 : 태초부터 현재까지 라는 제목으로 발표하고 왔습니다. 발표 자료는 Speaker Deck 에서 확인하실 수 있습니다. 힘들지만 유익했던 경험이라 느낀 점들을 글로 정리해보고 싶었습니다.
Cloud Composer 를 써보기 위해 Environment 를 만들 때, Worker nodes 의 Node count 와 Machine type 값을 어떻게 줄 지 고민했습니다. 넉넉한 걸로 하자니 비용이 아까웠고, 작은 걸로 하자니 이후 resource 가 많이 필요한 task 를 실행할 수도 있을 것 같아 망설여집니다. Environment 생성 후에 Machine type 을 바꾸려면 Upgrading the machine type 문서에서 소개하는, default-pool 을 없애고 새로 만드는 방법을 써야 하는데, 그 동안 task 실행이 중단되는 것도 그렇고 그리 매력적이지 않습니다. Upgrading the machine type 문서에서도 처음 Environment 를 생성할 때 machine type 을 잘 선택하고, resource 가 많이 필요한 task 를 실행하고 싶으면 GKEPodOperator 를 쓰라고 얘기합니다.
Cloud Composer 를 업무에 적용해보기 위해 처음 학습한 내용을 Cloud Composer 시작하기 글에서 정리했었습니다. 학습한 내용들을 가지고 이후 실제로 업무에 (= 데이터 파이프라인 개발) 적용했고, 그 과정중에 몇가지 고민하고 정리한 내용들이 있었습니다.