FinOps 적용 방안 - 지표(Metric) 이용

한빛미디어에서 출간한 클라우드 핀옵스 기반으로 스터디에 참여하고 있습니다. 해당 내용 기반으로 FinOps 소개합니다. 

먼저, 스터디를 주관해주신 https://www.costclipper.io/ CEO Eric Kim에 깊은 감사의 말씀을 전합니다. 

 

일반적으로 클라우드 비용을 줄이기 위하여 재무팀, 운영팀 간 이야기하면 서로 배경 지식이 달라 의사 소통이 쉽지 않습니다. 재무팀은 '회사가 어려우니 10% 비용 줄이세요', 운영팀은 '비용 줄이다 장애 나면 책임질 수 있나요' 라고 하는 경우가 많죠.

아래 예시처럼 구체적인 데이터(또는 기준값 - 메트릭)를 기준으로 의사 소통하는 것을 권고합니다. 

(아직 현재 + 지난 회사에 적용되지 않은 이상적인 내용도 있어 조심스럽기는 한데, 일단 Best Practice라 생각하여 나열해 보았습니다.)

 

들어가기 전에 간단히 용어 정의부터

• Capacity : EC2 인스턴스가 지원하는 물리적으로 할당 가능한 자원 용량(ex: m6i.large - 2 Core, 8Gi Memory)
• Usage : 실제 파드의 자원 사용량
• Request : 파드의 자원 요청량

 

EKS 클러스터의 Capacity 대비 Request 비율은?

아래 eks-node-viewer 스크린 샷의 CPU 37.9%, Memory 68.5% 처럼 EKS 노드의 전체 할당 가능한 자원(Capacity) 대비 현재 파드의 Request 비율을 측정한다. 70% 이상 할당하는 것을 권고한다.

Karpenter를 사용하면 Karpenter가 자동으로 Request 대비 적정한 노드를 할당하고 자원 여유가 있으면 노드를 줄이는(Consolidation 옵션)등 작업을 진행한다. Karpenter 꼭 사용한다.

 

eks-node-viewer(혹은 그라파나, 데이터독 등) 등의 도구를 이용하면 편리하게 수치를 확인할 수 있다.

 

EKS Karpenter 사용하는가?
Karpenter 적용해서 비용 절약했다는 사례 아주 많음. 필자도 30% 정도.
Job, Cronjob 등으로 노드의 변화가 심하다면 노드 그룹을 분리하던지 Consolidation 옵션을 Off도 고려할 수 있다.

 

전체 파드의 기본 Request 설정되어 있는가?(네임스페이스 단위 LimitRange 설정)
Karpenter가 Request에 따른 노드 할당을 정확하게 하기 위하여 Request 설정하지 않는 파드가 없어야 한다. 네임스페이스 단위로 LimitRange 설정하면 Custom으로 Request 할당하지 않는 파드에 자동으로 Default Request 설정이 된다.

 

실제 Usage 대비 Request는 적절하게 설정되었는가?

Request 설정 시 임의의 값을 할당하지 말고(ex: 1Core, 1Gi 등) 실제 사용량에 근거하여 Request를 설정한다.

KRR(Kubernetes Resource Recommender) 도구를 사용하면 구체적인 기준으로 설정할 수 있다. 예를 들어 CPU - 최근 1주일(혹은 1달) 사용량의 Percentile 90%를 기준으로, Memory - 최근 사용량의 Max + 10% 여유 등으로 Request 값을 확인할 수 있다. (세부 설정은 물론 변경 가능하다.)

이거 적용해서 필자는 EC2 비용을 20% 이상 절약할 수 있었다. (kubecost도 유사한 기능 제공)

 

참고로 CPU는 Request만 설정하고 Limit는 설정하지 않고(Burstable)
Memory는 Request/Limit 동일하게 설정(Guaranteed)하여 운영 중이다.

CPU는 시간 Base로 사용하는 자원이라 Limit 설정하지 않는 것이 성능에 유리하였다. (초기 기동 시 Spike 발생하여 Readiness Probe Fail 나는 문제 해결 등)

 

전체 인스턴스 대비 RI 적용 비율은?

RI 적용 가능 리소스 : EC2, RDS, ElastiCache, Elastic Search DocDB, Redshift (필자는 EC2, RDS만 되는 줄 알았다. MSK는 왜 안되는거야?)

 

구매 후 취소할 수 없으므로 신중히 적용한다. 유연한 RI 인스턴스 적용(Large가 2개의 Medium으로 적용)도 EC2, RDS만 가능하고 나머지 Cache 등은 안되니 최대한 신중해야 한다.

 

RI는 인스턴스 타입이 고정되어 적용하기 어려운데 고정 자원은 RI를 사용하고  + Saving Plan을 같이 적용해서 Coverage를 높혔다.

 

일반적으로 Coverage가 50%도 안된다는데, 80% 이상 사용하는 회사도 있다고 한다.

 

RI 중 유휴 인스턴스 비율?

RI 적용되었는데 사용하지 않는 비율. 유동적인 환경이라 생각보다 많다.

 

인스턴스 대비 Spot 비율은?
EKS 개발/Stage 환경에는 Spot 인스턴스를 적극적으로 사용할 수 있다. (현재 적용 중)
운영 EKS는 상황에 따라 다를 수 있는데 Stateless한 파드라면 Spot 사용하여도 서비스에 영향 없다. (역시 적용 중)

 

DataTransfer 비용은?
EKS 사용하면 DataTransfer 비용이 많이 나온다. 개발 환경은 AZ를 1개만 사용하면 비용 절약에 도움이 된다. (운영 환경도 AZ 2개만 사용하는 것도 가능할 듯)

 

참고로 DataDog 사용하면 DataDog이 us-east-1에 있어 라이선스 비용 이 외 DataTransfer 비용도 나온다

POD의 Auto Scaling 적용되어 있는가? 

 

ALB group으로 Load Balancer 통합하는가?
개별 ingress 마다 LB 만들지 말고 alb group 옵션 사용하여 LB를 공통으로 사용한다.

사용하지 않는데 삭제하지 않는 PVC는 없는지
PVC 기본 ReclaimPolicy 설정을 Retain으로 변경하였으면 삭제되지 않는 PVC가 꽤 있다. (그리고 이유는 모르겠지만) PV 삭제하였는데 AWS에 남아있는 Volume도 있으니 AWS 콘솔에서 사용하지 않는 Volume이 있는지 확인한다.

 

Volume은 gp2가 아니라 gp3를 사용한다.