프로젝트 요약
사내 서비스 및 B2B 상품 개발을 위한 하이브리드 클러스터 개발/운영
•
제목: 사내외 프로젝트를 위한 하이브리드 클러스터 개발 참여
•
기간: 2022년 12월 - 2023년 12월 (13개월)
•
Roles: DevOps 실무 담당 ~ 하이브리드 클러스터 개발 + CI/CD, 챗봇, 데이터 파이프라인 개발/운영 [기여도 50%]
◦
Hybrid Clusters
▪
퍼블릭 클러스터, 온프레미스 쿠버네티스, 멀티 클러스터, API 게이트웨이, IaC, GPU 오퍼레이터
◦
CI/CD
▪
퍼블릭 플랫폼 CI, 온프레미스 커스텀 CI, GitOps를 이용한 CD, 챗봇으로 결과/이슈 알림
◦
Pipelines
▪
ML 연구를 위한 데이터 파이프라인, ML 추론을 위한 프로덕션 파이프라인
•
성과: 하이브리드 클러스터 도입 ~ 온프레미스 리소스 활용성 증가 + 퍼블릭 리소스 비용 감소 + DevOps 문화 전파
◦
비용 절약
▪
퍼블릭의 가용성은 유지하면서, 온프레미스의 경제성을 이용해 순수 클라우드 대비 50% 이상의 비용 절약
◦
자원 활용
▪
유휴 온프레미스 리소스의 90% 활용, 타 부서 프로토타이핑을 위한 멀티클러스터 공급
◦
DevOps 문화
▪
클라우드 네이티브 개발환경 도입. 앱 현대화 및 CI/CD를 포함한 DevOps 문화 전파. 모니터링을 통한 의사결정 지원
•
대표 사용 기술
◦
Kubernetes
◦
AWS EKS
◦
IaC
◦
Ansible
◦
Terraform
◦
CI/CD
◦
Bitbucket Pipeline Runners
◦
Argo CD
◦
Argo Workflows
◦
Python/FastAPI
◦
Python/Bolt (Slack)
아키텍처
1. 하이브리드 클러스터
퍼블릭의 가용성은 유지하면서, 온프레미스의 경제성을 이용하는 하이브리드 클러스터를 도입하였습니다. 실시간성이 필요없는 경우 (연구/개발, CI/CD, 대규모 파이프라인 등) 온프레미스를 우선 사용하게 됩니다. 따라서 순수 클라우드 대비 비용을 50-66% 까지 절약할 수 있었습니다.
다음은 하이브리드 아키텍처를 간소화한 모습입니다.
API 게이트웨이 패턴을 이용하여, 각 클러스터를 모니터링한 후 워크로드를 할당합니다. 사용자에게 끊김없는 서비스 경험을 제공하면서, 비용 효율을 달성할 수 있습니다.
하이브리드 클러스터의 장단점
•
장점
◦
앱을 변경할 때 GitOps를 이용한 배포로 멀티 클러스터(온프레미스+퍼블릭)에서 함께 테스트할 수 있다.
◦
퍼블릭 클러스터의 장점을 이용하여 서빙워크로드에 대해 고가용성을 유지할 수 있다. (연간 다운타임 4%이내)
◦
온프레미스 클러스터의 장점을 이용하여 순수 클라우드 대비 비용을 50-66% 까지 절약할 수 있다.
•
단점
◦
아키텍처 디자인이 어렵다 → 데브옵스 팀과 연구/개발팀의 전사적 노력 필요
◦
온프레미스 리소스 관리가 어렵다 → 높은 러닝허들과 대기인력이 필요함
◦
아키텍처를 위해 자원 오버헤드가 생긴다 → API 게이트웨이를 개발하고 유지해야함
위 장단점을 고려하였을 때, 하이브리드 클러스터 구조는 합리적이었습니다. 서비스를 유지할 수 있을 정도의 학습/인력 자원을 투자하고, 최대한 관리 포인트를 줄이고 자동화합니다. 결과적으로 클라우드 비용을 절약하고 서비스 가용성을 유지할 수 있었습니다.
한 번 하이브리드 구조를 성공한 사례가 생기면, 이후 다른 프로젝트에도 적용할 수 있게 됩니다. 따라서 장기적인 관점에서 사내 데이터센터를 이용한 하이브리드 클러스터 구조는 데브옵스팀의 좋은 에픽이 될 수 있습니다.
하이브리드 클러스터를 구성하기 위한 각 클라우드의 기술 스택은 다음과 같습니다.
•
온프레미스
◦
배포: Argo CD (App of Apps 패턴)
◦
파이프라인: Argo Workflows
◦
레지스트리: Nexus
◦
GPU: NVIDIA GPU Operator
◦
모니터링: Grafana Stack (PLG)
◦
스토리지: Minio & Longhorn
◦
관리: Portainer
•
퍼블릭 (AWS EKS의 경우)
◦
배포: Argo CD (App of Apps 패턴)
◦
파이프라인: Argo Workflows
◦
레지스트리: AWS ECR
◦
GPU: NVIDIA GPU Operator
◦
모니터링: Grafana Stack (PLG)
◦
스토리지: S3 & AWS EBS
◦
관리: Portainer & CloudWatch
위 인프라 구성으로 같은 워크로드(서버, 파이프라인)를 할당할 경우에도 각 클라우드에 맞게 동작하도록 설정하였습니다.
2. 하이브리드 CI/CD
CI/CD를 위한 관리형 도구들은 편리한 대신 많은 비용을 요구합니다. 관리형 CI/CD 도구인 GitHub Actions, Bitbucket Pipelines는 웹 개발에는 높은 효율을 보이지만, 대용량의 ML 이미지의 경우 빌드에 여러 문제점을 불러올 수 있습니다:
•
관리형 CI/CD 도구는 빌드에 필요한 큰 RAM 용량을 지원하지 않습니다.
◦
예를 들어 64GB, 128GB을 요구하는 ML 모듈의 빌드에서는 이를 지원하는 GitHub Action의 Runner가 없습니다. Self-hosted Runner를 사용할 수 있지만, 이 경우 IO 및 Runner의 고가용 설정이 복잡해집니다.
◦
이를 위해 커스텀 CI/CD가 필요합니다. 온프레미스 장비 혹은 클라우드의 VM을 할당해야 합니다.
•
모델 빌드 및 테스트를 위한 비용이 많이 듭니다.
◦
빌드하기 위해 큰 용량의 모델 데이터를 불러와야합니다. 또, 빌드 후 테스트를 위해 대용량의 데이터를 받아야합니다. S3 및 클라우드 스토리지를 마운트하게 되면 모델을 빌드할 때 마다 큰 비용이 나가게 됩니다.
◦
회사의 정책에 따라 이 비용을 감수할 수 있지만, 이를 온프레미스로 전환한다면 많은 예산을 아낄 수 있습니다.
위 두 경우를 고려하여 ‘커스텀 하이브리드 CI/CD’를 도입하였습니다.
하이브리드 CI/CD의 아키텍처는 다음과 같습니다.
ML 모듈의 소스코드가 병합되면 웹훅을 통해 API 게이트웨이에 전달합니다. API 게이트웨이는 각 클러스터의 상태를 확인하고 CI/CD 파이프라인을 할당합니다.
•
1순위로 온프레미스 클러스터에 CI/CD를 할당합니다. 빌드에 필요한 전처리 에이전트를 수행하고 이미지를 빌드합니다.
•
온프레미스에 장애가 있거나, 자원이 부족할 때 2순위로 퍼블릭 클러스터에 할당하여 온프레미스 CI/CD와 동일하게 빌드될 수 있도록 임시 파이프라인을 가동합니다.
◦
이 때 CA, Karpenter와 같은 도구를 이용하여 필요할 때만 리소스를 할당하는 설계가 필요합니다. 평소에는 CI/CD를 위한 퍼블릭 리소스를 할당하지 않습니다.
이 과정을 통해 대규모의 CI/CD도 비용 절약을 최대화 하면서 연구/개발 사이클에 문제가 없도록 구성하였습니다.
