Terraform과 Shell Script를 통해 AWS 비용 절감하기

들어가기 전에

지난 6월부터 현재까지 소프트웨어 마에스트로 과정을 진행하면서 Kubernetes 기반 MLOps 서빙 플랫폼을 제작하고 있습니다. 핵심 목표로는 모델러가 Kubernetes, Backend 지식 없이 모델 버전 관리, 인퍼런스 서버 배포, A/B 테스트, 모니터링 등의 기능을 제공하는 것입니다.

 

 

So1s

 

저희 팀에서는 Kubernetes를 사용하기 위해서 클러스터를 사용할 수 있는 환경이 필요했습니다.

다행스럽게도 소프트웨어 마에스트로 측에서 AWS에 대한 비용을 일부 지원하고 있기 때문에 AWS EKS를 사용하기로 결정했습니다.

 

---

겪었던 문제점

단일 클러스터 사용으로 인한 팀원 간의 개발 충돌 문제 발생

개발 초기에는 단일 EKS 클러스터를 통해 기능 개발을 수행했습니다. 그러나 개발을 진행하게 되면서 팀원 간의 개발 충돌이 발생하기 시작했습니다. 개발 초기에는 팀원 모두 클러스터를 사용하여 개발하는 태스크가 많았기 때문에 원활한 개발을 할 수 없었습니다. 또한 팀원들 마다 다른 시간대에 개발하는 경우가 있었기 때문에 클러스터를 쉽게 끌 수가 없었고 이로 인해 AWS에 대한 과도한 지출이 발생했습니다.

 

즉, 단일 클러스터 사용으로 인해 문제가 발생했습니다. 따라서 클러스터를 분리할 필요성을 느꼈습니다.

그러나 팀원들은 개발 중인 클러스터를 구축하지 못했기 때문에 클러스터 환경에 대한 이해도가 부족할 것이라고 판단하여 문서를 함께 제공했습니다.

 

그래서 EKS 클러스터 구축 관련 문서를 바탕으로 개인 마다 클러스터를 할당하고 개발을 끝나게 되면 끄는 방식으로 진행했습니다.

노션으로 관리한 EKS 설정 문서

 

빈번한 EKS Spec 변경, 클러스터 내 트러블 슈팅 문제점

문서화를 했을지라도 개발 초기였기 때문에 EKS spec을 변경하는 상황이 자주 발생했습니다. 이로 인해 문서를 변경하고, 팀원들에게도 변경 사항을 공유하고, 팀원들의 클러스터 내에서도 이를 반영해야 하는 불필요한 커뮤니케이션 홉이 발생했습니다.

 

또한 팀원 중 한명이 클러스터 관련 트러블 슈팅을 할 때에도 EKS 설정을 담당한 저에게 구체적인 EKS 설정을 전달받고 트러블 슈팅을 했기 때문에 이 역시 불필요한 홉이 발생했습니다.

결국 이전 개발 방식보다 더 불편해졌기 때문에 다시 단일 클러스터 환경을 유지하여 개발을 진행했습니다.

 

비용 관리의 필요성

8월 중순부터 7월 AWS 비용을 넘기더니 8월 AWS 비용이 약 1000달러가 나오게 됐습니다.

7월에는 479달러로 약 2배 가량 증가했습니다.

개발을 진행함에 따라 많은 리소스가 필요해졌고 이에 따라 EKS에 EC2 인스턴스를 계속해서 추가하고 있었습니다. 또한 모델 바이너리를 GPU를 통해 빌드하거나 배포를 하는 상황도 고려해야 했기 때문에 GPU 노드를 추가할 예정이었습니다.

 

이와 같은 비용이 계속해서 발생하거나 더 늘어날 경우 클러스터를 가동시킬 수 없었기 때문에 해결책이 필요했습니다.

 

---

문제 해결하기

Terraform 도입하기

지금까지 발생했던 문제들을 다시 정리하면 다음과 같습니다.

• 비용 문제
  • GPU 도입 예정
  • 24시간 구동 중인 클러스터
• 클러스터 스펙 변경에 따른 빈번한 문서 업데이트
  • 클러스터 트러블 슈팅에 대한 불필요한 커뮤니케이션 홉 발생

 

위 문제들을 해결할 수 있는 방법에 대해 고민하게 됐고 이에 따라 IaC인 Terraform을 도입하기로 결정했습니다.

Terraform은 hashicorp에서 제공하는 IaC 중 하나로 코드로 인프라를 관리할 수 있다는 장점을 가지고 있습니다.

이를 통해서 다음과 같은 장점을 기대할 수 있었습니다.

 

• 테라폼 코드와 CLI가 설치되어 있다면 간단한 명령어만으로 EKS 클러스터를 생성할 수 있다.
• 사용할 벤더사에 대한 지식만 충분하다면 기존 코드에 간단한 수정 및 추가 작업을 할 수 있다.
• 코드를 작성하기 때문에 문서화를 할 필요가 없다.

 

테라폼에 대한 설명은 아래 글에 자세하게 나와있습니다.

 

Infrastructure Provisioning Tool, Terraform

 

Terraform으로 EKS 환경 구축하기

비용 절감을 위해서 기본적인 테스트 및 개발을 할 수 있는 Dev 환경과 부하 테스트 같은 실제 사양이 요구되는 Prod 환경을 나눠서 개발하기로 결정했습니다.(온라인 서비스가 아닌 PaaS 플랫폼이기 때문에 staging 환경과 prod 환경의 역할을 합쳤습니다.)

 

따라서 Dev 환경과 Prod 환경을 나눠서 개발을 진행했으며 이 중에서도 dev, prod 모두 공통적으로 필요한 리소스들은 global로 옮겼습니다.

 

Terraform 상태관리 같은 경우 Dev 환경에서는 local 환경에서 관리를 했으며, Prod 환경에서는 S3, DynamoDB를 활용한 remote backend 설정을 구성했습니다.

remote backend 설정을 한 이유는 Prod 클러스터를 1개만 생성하도록 제한하여 무분별한 Prod 클러스터 사용을 방지할 수 있었으며, 모든 팀원이 Prod 클러스터 내에서 트러블 슈팅을 할 수 있기 때문입니다.

 

AWS에서 존재하는 모든 서비스들을 다 Terraform 코드로 마이그레이션 하는 것은 상당히 오랜 시간이 걸릴 것이라고 생각했습니다. 따라서 Route53, S3 같은 서비스들은 그대로 유지하고 Terraform으로 전환이 필요한 리소스들은 Terraform AWS modules를 활용하여 개발하기로 결정했습니다.

 

Terraform AWS modules

 

 

Shell Script 사용하기

이제 Terraform을 사용해서 쉽게 EKS 클러스터를 구축할 수 있게 됐지만 추가적인 문제가 발생했습니다.

1. 수동으로 클러스터 내에 External-DNS, ALB Controller 같은 종속적인 Helm Chart를 설치해줘야 한다.
2. Prod, Dev를 실행하려면 다른 경로에서 실행해야한다.
3. 클러스터를 삭제할 때에도 종속적인 Chart를 우선적으로 삭제해줘야 한다. (ALB Controller를 통해 생성된 ALB는 테라폼에서 관리하지 않은 리소스이므로 ALB Controller를 먼저 삭제해줘야 한다.)

위 같은 문제를 해결하고자 Shell Script를 통해 프로비저닝 스크립트를 개발했습니다.

Shell Script를 통해 어떤 개발환경인지 확인하고, GPU를 사용할 것인지 등 어떤 리소스에 대해 확인할 것인지 확인합니다.

이후 테라폼을 통해 클러스터를 생성하고 각 개발환경마다 필요한 Helm Chart를 설치합니다.

 

프로비저닝 스크립트 외에도 clean up 스크립트도 제작하여 순차적으로 안전하게 삭제할 수 있었습니다.

 

자세한 코드는 아래 레포지토리에서 확인할 수 있습니다.

 

 

GitHub - so1s/so1s-infra: So1s EKS Terraform

---

Terraform과 프로비저닝 스크립트를 통해 얻은 성과들

과도하게 AWS를 사용했던 만큼 Terraform과 함께 프로비저닝 스크립트를 도입하게 되면서 많은 비용 절감을 하게 됐습니다.

 

9월 15일부터 본격적으로 모든 팀원이 프로비저닝 스크립트를 사용하게 됐고 그에 따라 평균 23 달러 정도 썼던 지출을 10달러 미만으로 사용하게 됐습니다.

도입 기간 동안 지출한 금액(9/15 ~ 9/30 * 2)을 기준으로 계산을 했을 때에는 923달러를 썼던 8월보다 약 83%를 절감하는 효과를 봤습니다.

 

또한 개인마다 클러스터를 할당받고 개발을 하기 때문에 기능 개발을 충돌 없이 개발을 했습니다.

Github에서 제공하는 최근 1달간 Infra 레포지토리 커밋 그래프

클러스터 관련 추가 기능 및 트러블 슈팅도 복잡한 문서 대신 직관적인 코드로 이뤄져있기 때문에 팀원들이 이전보다 쉽게 기여할 수 있었습니다.

 

마무리

Terraform을 통해 개발을 할 당시에는 “기능 개발에 더 집중을 해야 하는데 어떡하지?”라는 걱정이 앞섰습니다. 그러나 걱정과는 다르게 오히려 팀원들의 개발 효율이 더 올라가게 됐고 비용적인 측면에서도 많이 절감하게 되어 소프트웨어 마에스트로 프로젝트 지원 비용을 다른 방향을 활용할 수 있었습니다.

 

또한 자동화를 통해서 실제 개발 속도와 비용 절감 효과를 몸소 경험하게 되면서 앞으로도 프로젝트 기능 개발에만 국한되지 않고 다양한 측면에서도 문제를 해결할 수 있는 개발자가 되어야겠다고 생각했습니다.