개요

10명도 되지않는 소규모 스타트업에서 ECS를 도입했다가 EKS(K8S)로 넘어가서 40%이상 비용을 줄인 방법을 알려드리려고 합니다.

ECS 도입

먼저 Beanstalk, EKS, ECS 중 ECS를 먼저 도입하게된 이유부터 설명드리겠습니다.

인스턴스 환경에 따라 서비스가 영향을 받지 않게 하고 문제 발생시 빠르게 롤백 시키기 위해 Container 기반 서비스를 도입하기로 했습니다.

소규모 회사인 만큼 EKS 까지는 불필요하다 느꼈고 Beanstalk은 이전 회사에서 사용 시 너무 느리고 버그도 많았었기 때문에 ECS를 채택했습니다.

AWS ECS

AWS beanstalk




처음 도입 시에는 굉장히 만족 했습니다.

task definition을 수정할 때마다 버저닝 해주고 롤백도 쉬웠고 알아서 인스턴스와 서비스 상태까지 관리해주었죠

하지만 1달이 지나고 바로 문제가 터집니다.

Load balancer의 문제

AWS ECS는 서비스간 호출을 위해 ELB를 사용해야 했습니다

EC2를 사용해 올린다면 ELB가 필수였고 상태체크 또한 ELB를 통해서만 가능했습니다.

그러다보니 같은 인스턴스임에도 불구하고 서로 서비스를 호출하기 위해선 ELB를 호출해야했고 해당 서비스를 외부에서도 호출해야했기 때문에 해당 ELB는 internet으로 열릴 수 밖에 없었습니다.

inbound는 문제가 없으나 outbound는 nat 를 거쳐 public dns를 찾기 위해 internet을 호출해야 했습니다

단순히 네트워크 구조가 맘에 들지 않아서가 문제가 아닙니다

Cloud map을 통한 이러한 구조가 가능한줄 알았고 해당 방식을 도입하려고 했습니다

그러나 여러 문제와 함께 위 그림은 불가능한 영역이었습니다.

1. A record의 dns만 가지고 load balancing이 불가능하다

cloud map을 ECS에 도입 시 제공해주는 서비스별 A record는 fargate에만 제공되었습니다.

그 이유는 외부에서 load balancer로 서비스에 접근하기 위해서는 EC2의 host network로 port별 구분을 통해 서비스를 생성할 수 밖에 없는데 그럼 제공하는 private dns는 해당 인스턴스의 ip를 한개만 저장해 접근할 수 밖에 없으므로 여러 인스턴스에 서비스가 등록 되어있는 경우 한쪽에만 접속할 수 밖에 없는 구조 였습니다.

즉 저 여러 인스턴스에 교차해 접근해주는 service discovery를 cloud map만 가지고는 진행하지 못 하는 구조였습니다.

단순히 A record로만 호출할 때는 하나의 ip만 알 수 밖에 없으므로 한쪽으로만 접속하게 됩니다.

제가 생각한 고정 dns를 balancing하는 dns는 SRV record로 제공해주는 형태였습니다

결국 srv record를 해석해 변경하는 load balancer가 필요했고 cloudmap은 제외한채 수동으로 private load balancer dns를 만들게 되었습니다.

2. 비용

이러다보니 외부 호출을 위한 ELB, 내부 호출을 위한 ELB까지 필요한 상황이었습니다.

결국 비용을 아끼기 위해 최소한의 ELB로 모든 서비스를 돌리려 했었으나 포트를 서비스별로 모두 분리하고 target group에 등록해야 했으며 인스턴스가 변경되거나 삭제 되더라도 target group을 수동 매칭 해야했고 (실제로 ECS와 연결된 것이 아니기에) 서비스를 삭제할 때 별도로 삭제해야 하는 등
사실상 모든 것을 수동 설정을 진행해야 했습니다.

그리고 총합 ELB만 한달에 $151가 나가고 있었습니다.

단점

외부 서비스 사실상 사용 불가

오픈 소스 서비스(filebeat 등)를 사용하려면 내 private ECR에 image를 수동으로 만들고 등록하고 설정 맞추고 테스트를 해야 하는데 이 마저도 docker compose를 지원하지 않으므로 task definition으로 일일이 맞추어야 합니다.

진짜 너무 너무 불편해서 그냥 외부 서비스는 안 썼습니다.

자잘한 운영 리소스

1. target group 수동 매칭
2. blue green 배포 code deploy 따로 봐야함
3. rolling update event bridge 따로 봐야함
4. auto scale group은 수동 매칭 후 따로 봐야함
5. git 배포 시 task definition을 맞추려면 파일 형태로 저장되어야 하는데 이를 sync하려면 서비스를 배포해야함
6. cloudformation에 의존적이고 실패 hang이 걸렸을 때 cloudformation을 보고 수정해야함
7. load balancer target group deregistration delay 및 health check delay로 인해 배포가 너무 길고 서비스 등록 할 때마다 delay 수정 해주어야 함

결국 이 모든 것을 하기 위해 cloudformation + terraform 을 사용합니다. 이럴거면 ecs 보다 ec2에 code deploy 쓰는게 낫지 않을까 라는 생각이 들었습니다.

다른 서비스 합쳐서 AWS 핵심 서비스 비용에 $1500달러, 총 $1900 이상 나가고 있는 상황이었습니다

사실상 ECS만 무료이고 다른 서비스를 다 등록시켜서 비용이 배로 나가고 있었습니다

EKS 이전

이런저런 자잘한 이유 다 빼더라도 K8S를 도입할 이유는 충분했습니다.

EKS에 고정으로 나가는 비용 $72달러는 ELB 비용의 반밖에 안되는 상대적 혜자로 보였죠

결론 부터 말씀 드리면 $1900 -> $1200 약 40%까지 비용을 절감했습니다.

RDS도 중간에 중지해서 비용이 청구되었지만 다음달 부터는 0원입니다

비용 절감 방법

일단 비용 절감의 핵심은 2가지 였습니다.

1. 규모에 맞지 않게 비싸게 운영중인 RDS와 Elasticloud를 on-premise로 변경
2. elb를 최소화하고 nat gateway를 최대한 타지 않도록 수정

여기서 주목해봐야 할 부분은 on-premise로 변경되면서 ec2의 비용이 증가하였으나 그 증가폭이 rds에 들어가는 비용에 비해 매우 적다는 것입니다.
실제로 rds+escloud의 비용은 약 $900 였는데 instance 4대에 추가하면서 약 $350달러로 낮추었다는 점입니다. (소규모이기에 운영이나 성능에 영향이 없습니다)

사진상으로는 중간에 중지되어 $100이지만 ELB를 반으로 줄이면서 $150 -> $80달러로 줄였습니다.

소규모 스타트업이기에 절대적인 비용이 작지만 규모와 관계 없이 비용이 줄여진다는 점이 핵심입니다.

편해진점

1. argo (gitops)를 도입하면서 aws 서비스 전체를 관리하는 스트레스가 없어졌습니다.

argo 페이지만으로 rolling과 auto scale 모두 관리가 가능하고 mysql, es 와 같은 외부 서비스도 함께 확인이 가능해졌습니다.

특히 git action은 image만 올리도록 의존성을 분리함으로써 문제가 생긴다고 git action을 다시 돌리는 일이 없어졌습니다.

mysql + efs를 통해 안정적으로 데이터를 관리하고 사내에서 사용하는 리소스를 파악해 유동적으로 늘릴 수 있게 되었습니다.

2. 내부 pod에 영향을 주지 않고 infra 의 테스트가 가능합니다.

인프라에 문제가 발생 시 다른 서비스에 영향을 미칠까봐 테스트를 할 때 망설여집니다. 자칫 큰 장애로 이어질 수도 있습니다.

특히 ingress나 svc의 수정은 대부분 load balancer만 변경될 뿐 pod의 재시작이 필요 없습니다.

Beanstalk이나 ECS는 설정 수정을 하면 서비스를 재배포 해야했기에 망설여진 부분이 있었던 점을 생각하면 아주 큰 차이입니다.

3. Multicloud가 가능해지고 AWS를 들어갈 필요가 없어졌습니다.

이젠 굳이 AWS를 쓰지 않아도 됩니다. k8s multi cluster를 도입하거나 크레딧을 많이주는 다른 cloud에서 똑같이 다시 올리면 됩니다.

AWS에 굳이 들어가지도 않습니다. eks는 당연히 잘 돌아갈 것이고 cloudtrail이나 비용 정도는 확인하지만 이 마저도 타사 계약을 통해 다른 웹페이지에서 보고 있습니다.

많은 장점이 있지만 제일 좋은건 이젠 argo도 보지 않고 모든게 자동으로 잘 돌아간다는 점입니다.

서버를 모르는 개발자분들도 쉽게 설정을 수정하실 수 있습니다. 이 설정도 git repository로 바로 sync하고 versioning 하고 있습니다.

마치며

많은 분들이 소규모 스타트업에서 K8S를 도입하는 것에 대해 굳이? 라는 말을 합니다.

하지만 소규모에서도 infraless 를 위한 완전 자동화에 거의 근접하였고 훨씬 적은비용으로 가능하게 했다는 점을 말씀드리고 싶습니다.

감사합니다.

요약

1. ECS는 무료이지만 다른 서비스와 연계되어 사용하면 생각보다 비싸다
2. K8S로 전환하면서 비용을 40% 줄였으며 infraless가 가능한 수준까지 설정하였다.
3. 소규모 스타트업에서 사용하는 것이 비용 낭비가 아니며 눈에 보이는 비용과 휴먼비용 모두 훨씬 줄일 수 있었던 것 같다