AWS EKS 비용 절감 방안 (인스턴스 비용 절감)

개요

EKS를 사용하다 보면 노드의 타입과 개수가 늘어나면서 인스턴스에 대한 비용이 많이 늘어나게 된다.

이때 비용절감을 할 수 있는 방법은 크게 두 가지가 있다.

첫 번째는 모니터링을 통해 리소스(Limit, Request)를 알맞게 조정하는 것이다.

두 번째는 인스턴스를 On-Demand만 사용하지 않고 RI 또는 Spot을 같이 사용하는 것이다.

 

1.  리소스(Limit, Request) 조정

Kubernetes를 사용하면서 Pod 리소스가 무한정으로 커지지 않고 리소스 용량 관리를 하기 위해서는 리소스(Limit, Request) 설정을 해야 한다.

또한 CA, HPA에서 확장/축소시킬 기준값이 되기 때문에 운영환경에서 리소스 설정은 필수이다.

 

설정팁은 Request를 무조건 작게 설정하면 조금만 사용량이 늘어도 HPA에 의해 Pod 개수가 늘어나기 때문에 오히려 Node의 리소스를 많이 사용하게 된다.

그리고 QoS 우선순위를 위해서 Request와 Limit을 일치시키는 것이 가장 좋다. (Guaranteed) 

Request보다 Limit을 더 높게 설정해야 한다면 Request와 Limit의 차이가 크지 않도록 설정하는 것이 Burstable 타입 중에선 우선순위가 높다. (우선순위가 낮은 Pod부터 Eviction 시킨다)

 

여러 가지 상황을 고려하고 지속적인 모니터링을 통해 적절한 Request, Limit을 설정해서 Node의 리소스를 절약해야 한다. 

참고: https://jenakim47.tistory.com/96

Kubernetes QoS(Qualitu Of Service)와 Pod Eviction의 상관 관계

 

 

2. 인스턴스 유형을 적절히 섞어 사용

인스턴스 On-Demand 유형보다 예약 인스턴(RI)의 비용이 최대 72% 저렴하고 Spot의 비용이 최대 90% 저렴하다.

그렇기 때문에 On-Demand 유형만을 사용하는 것보다 상황에 맞춰 적절히 섞어서 사용하는 것이 비용 절감을 할 수 있는 방법이다. 

 

나와 같은 경우에는 개발, 스테이징 환경 EKS Node On-Demand를 사용하던 것을 전부 Spot으로 전환하여 비용을 50% 절감하였다.(리소스 조정도 같이 했다)

개발, 스테이징 환경은 테스트 환경이기 때문에 서비스 중단이 잠깐 발생하여도 괜찮았기 때문에 Spot 전환이 가능했다.

 

Spot을 사용하면 언제든 노드가 탈취될 수 있기 때문에 사전 작업이 필요하다. 

 

2-1. Spot 사용하기 위한 전제 조건

• 인스턴스 타입과 가용영역을 여러 개 선택해서 유연성을 높여야 한다. Spot이 필요한 컴퓨팅 용량을 찾고 할당할 수 있는 더 좋은 기회를 얻을 수 있다.
• 시작템플릿에서 인스턴스 배포에 온디멘드와 스팟 비율을 설정한다. 온디멘드 - 20% 스팟 - 80% 와 같이 설정하여 안정성을 높인다. 삭제되면 안 되는 서비스를 온디멘드에 스케쥴링한다.
• 스팟 할당 전략을 용량 최적화로 선택한다. 가용 영역 내의 가장 가용성이 높은 풀에서 스팟 인스턴스를 요청하기 때문에 이 전략은 중단 위험이 가장 낮다.
• 용량 재조정(capacity rebalancing)을 활성화한다. 용량 재조정이 활성화되면 Auto Scaling은 재조정 권장 사항을 받은 스팟 인스턴스를 사전에 교체하려고 시도하여 중단 위험이 높지 않은 새 스팟 인스턴스로 워크로드를 재조정할 수 있는 기회를 제공한다.
• aws-node-termination-handler 사용을 고려한다. Gracefully handle EC2 instance shutdown within Kubernetes을 위한 도구이다. 

참고

https://docs.aws.amazon.com/ko_kr/whitepapers/latest/cost-optimization-leveraging-ec2-spot-instances/spot-best-practices.html

https://aws.amazon.com/ko/blogs/korea/capacity-optimized-spot-instance-allocation-in-action-at-mobileye-and-skyscanner/

 

 

aws-node-termination-handler vs Capacity Rebalancing

공식 문서를 보면 Capacity Rebalancing 기능이 aws-node-termination-handler을 대체한다고 나온다.

하지만 실제로 테스트를 해 본 결과 Capacity Rebalancing 기능은 Rebalance Recommendation 이벤트가 발생하면 새로운 Spot을 생성하지만 새로운 Spot이 Ready 상태가 되기까지 기다리지 않고 기존 Spot을 Drain 한다.

aws-node-termination-handler는 Rebalance Recommendation 이벤트가 발생하면 기존 Spot을 Cordon 시키고 새로운 Spot을 생성한다. 그리고 새로운 Spot이 Ready 상태가 될 때까지 기다린 다음 기존 Spot을 Drain 시킨다. 그래서 Spot이 종료될 때 Pod가 더욱 원활하고 빠르게 재스케쥴링 되었다.

Spot 솔루션을 사용한다면 Capacity Rebalancing 기능과 추가로 aws-node-termination-handler를 사용해야 하겠다.

 

그리고 aws-node-termination-handler에서 Rebalance Recommendation, Instance interruption 이벤트 슬랙 알람설정 기능이 좋다. 

 

참고

aws-node-termination-handler: https://github.com/aws/aws-node-termination-handler

capacity rebalancing: https://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/ec2-auto-scaling-capacity-rebalancing.html

 

2-2. RI 사용하기 위한 전제 조건

RI는 약정 기간이 1, 3년이 있고 인스턴스 유형을 선택해야 한다.

표준 RI에 경우 한번 선택한 인스턴스 유형을 변경하거나 환불할 수 없기 때문에 신중하게 결정해야 한다.

그렇기 때문에 처음부터 RI를 구매하는 것보단 운영을 하면서 인스턴스 타입이 몇 가지로 고정적으로 사용하고 있다면 그때 구매해야 한다. 

참고: https://aws.amazon.com/ko/ec2/pricing/reserved-instances/

 

추가로 Saving Plan을 같이 고민해 보면 좋을 거 같다.

https://aws.amazon.com/ko/savingsplans/

 

---

Next Step...

인스턴스 비용을 최적화했다면 그다음은 네트워크 비용 최적화이다.

EKS를 Multi-AZ로 설계를 했다면 Cross-AZ에서 파드간 통신을 하면서 트래픽 비용이 많이 발생한다.

 

Cross-AZ 통신 비용 절감에는 세 가지 방법이 있다.

1. 가용영역 한 곳에서 EKS를 구축한다.
2. Topology Aware Hint 기능을 사용한다.
   1. https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/
   2. https://aws.amazon.com/ko/blogs/tech/amazon-eks-reduce-cross-az-traffic-costs-with-topology-aware-hints/
3. Single Zone EKS를 Active-Active 구성한다.
   1. 예를 들어, A Zone에 EKS를 구축하고 C Zone에 EKS를 구축해서 Active-Active로 사용한다.
   2. Cross-AZ 간 통신 비용과 Statefulset EBS PV 문제를 해결할 수 있다.

 

첫 번째 방법은 가용성 문제가 발생할 수 있다.

두 번째 방법은 해당 기능이 아직 베타이고 전제 조건 달성이 어려워서 PoC를 많이 해봐야 한다.

세 번째 방법이 제일 좋은 방법 같지만 트래픽 비용보다 EKS 개수를 늘리는 방법이 과연 비용 효율적 일지 운영 효율적 일지는 더 고민해봐야 할 사안이다.