한빛미디어에서 출간한 클라우드 핀옵스 기반으로 스터디에 참여하고 있습니다. 해당 내용 기반으로 블로그 작성하였습니다.
먼저, 스터디를 주관해주신 https://www.costclipper.io/ CEO Eric Kim에 깊은 감사의 말씀을 전합니다.
이번 글에서는 아키텍쳐와 프로세스 측면에서 FinOps 적용 방안을 소개합니다.
(아직 현재 + 지난 회사에 적용되지 않은 이상적인 내용도 있어 조심스럽기는 한데, 일단 Best Practice라 생각하여 나열해 보았습니다.)
아키텍쳐 고려 사항
DataDog(상용 모니터링 솔루션) to Prometheus, Grafana, Tempo
DataDog 등 상용 모니터링 솔루션을 사용하는 곳이 많습니다. 그런데 서비스가 성장할수록 DataDog 비용이 아주 많이 소요됩니다. (물론 DataDog 은 아주 훌륭한 솔루션입니다.)
가능하다면 처음부터 오픈소스 Prometheus, Grafana 등 사용을 권고합니다. 최근 사용 사례가 많아 그라파나 대시보드 찾기도 쉽고 문제가 생겨도 검색하면 해결되는 경우가 많습니다.
최근에 LGTM(Looks Good To Me 가 아니라 Loki, Grafana, Tempo, Mimir) 관련 블로그 글도 꽤 보이는 편입니다.
필자도 Prometheus, Grafana, Loki로 잘 운영하였습니다.
Elastic Search to Loki
EKS 파드의 로그를 검색하는 용도로 Elastic Search 보다는 Loki를 사용하는 것이 비용이 작게 소요됩니다. 스토리지도 저렴한 S3 기반이고 Metric 기반 Index라 ES에 비하여 자원을 아주 작게 사용합니다. 성능이 문제인데 Loki에 적절한 성능 튜닝을 하면 나쁘지 않았습니다.
트래픽 패턴은 Spike가 있는가? Auto Scaling이 설정되어 있는가?
서비스 트래픽이 일정하지 않고 Spike가 있다면 트래픽에 적합한 Auto Scaling(HPA) 설정하여 노드 수량을 유동적으로 변경합니다. Max 사용량 기준으로 24시간 노드를 운영하는 건 아깝습니다.
트래픽 증가보다 노드 증가가 늦어 Auto Scaling을 사용하기 어렵다면 특정 시간 대에 미리 파드 수량을 증가하거나(Keda에 Cronjob 옵션이 있습니다.) CPU, Memory 등 자원이 아니라 Custom Metric 기반으로 HPA 설정을 할 수 있습니다.
부하테스트를 미리 해서 적절한 Metric과 반응 시간을 찾는 것이 필요합니다.
ARM, Graviton 인스턴스 사용
일반적으로 Graviton 인스턴스 사용하면 20% 이상 성능 대비 비용 효과가 있습니다. 컨테이너 이미지 생성 시 Hybrid 또는 ARM 기준으로 설정합니다.
최신 세대 인스턴스 사용
Karpenter Provisioner 설정 시 아래와 같이 instance-generation을 최신 세대로 설정합니다.
- key: "karpenter.k8s.aws/instance-generation"
operator: Gt
values: ["5"]프로세스 고려 사항
- 속도, 안정성, 비용의 균형을 고려한다.
100%, 200% 매출 증가가 10%, 20% 클라우드 비용 감소보다 중요한 시기가 있습니다. 적절한 의사 결정이 필요합니다.
물론 자동화된 프로세스로 비용 감소에 소요되는 시간을 줄이면 속도와 비용의 2마리 토끼를 잡을 수 있습니다. - FinOps를 비용 절감이 아니라 효과적으로 비용을 지출하는 것으로 생각합니다. 회사의 성장을 위하여 클라우드 비용을 효과적으로 지출한다 라고 생각합니다. 예를 들어 인스턴스 사이즈를 줄이는 것을 인스턴스 절감보다는 Right Sizing 이라는 용어를 사용하는 것이 낫습니다.
- ChargeBack, ShowBack
각 개발 팀 별로 내가 사용하는 IT 비용을 볼 수 있고 사용한만큼 부과되는 시스템을 구축합니다. 팀 단위로 비용을 할당하면 해당 팀의 팀장이 비용에 대하여 책임감을 가질 수 있습니다. - 기고, 걷고, 뛰는 단계를 고려합니다. 처음부터 잘하려고 무리하게 적용하면 안 됩니다. 예를 들어 RI, Saving Plan 적용 시 최초 설정은 30%로 하고 이 후 월별, 혹은 분기별로 사용량을 확인하여 30% - 60% - 80% 증가하는 것을 목표로 합니다.
- 개발자(혹은 전체 인원)도 처음 설계부터 비용을 중요 지표로 생각합니다. 단순히 서비스 안정성만 고려하여 초기부터 빵빵하게 리소스를 사용하지 않습니다. 물론 내 돈 나가는 게 아니라 회사 카드로 비용이 나갑니다. 하지만 비용까지 고려하는 개발자는 자기 몸값이 올라갑니다.
클라우드 사용하기 이전에는 서버 1대 사기 위하여 재무팀, 정보 전략 협의 받기가 정말 어려웠습니다. 사용하기 쉬운 만큼 섬세한 비용 고려가 필요합니다. - 클라우드 비용은 실시간으로 조회 가능하고 회사 전체 인원이 볼 수 있어야 합니다.
현실은 아마도 DevOps 1,2명만 MSP가 제공하는 비용 레포트 분석하고 있을 것 같습니다. 좀 더 많은 사람들이 관심을 가질 수 있도록 슬랙으로 매일 혹은 매주 단위로 비용 레포트를 공유하는 것도 방법이 될 수 있을 것 같습니다. - 각 팀 별로 월단위로 클라우드 비용 예측이 가능하고 예산을 기준으로 운영합니다.
- FinOps 성과를 전사에 공유합니다.
- 사용하지 않는 인스턴스는 삭제한다.
전체 인스턴스에 Tag를 할당해서 사용하지 않는 인스턴스를 파악합니다. Tag는 테라폼 등의 IaC 도구로 자동으로 할당합니다. Tag가 안달려 담당자 없는 인스턴스는 삭제합니다.
아마 대부분의 회사가 비슷할 것인데 새롭게 리소스는 잘 만드는데 기존 자원을 삭제하는 건 참 어렵습니다. 데이터 삭제가 대표적입니다. 이력 관리를 잘하고 귀찮아도 적극적으로 하려고 하는 마인드(또는 인센터브, 문화)가 필요합니다. - 계정을 분리하여 비용을 별도로 청구한다.
계정을 분리하면 NAT G/W, EKS 등 공통 비용이 추가로 발생하지만 프로젝트, 서비스 별 비용 파악은 절대적으로 유리합니다. 역시 적절하게 조정해서 계정을 분리합니다. - 공통 비용(보안, CloudWatch 등)은 사전 협의에 따라 부과한다.
1/n 혹은 사용량만큼 부과 등 정책에 따라 공통 비용도 원칙에 따라 배분합니다. 공통 비용이 참 많이 소요됩니다.
'FinOps' 카테고리의 다른 글
| 1인 DevOps의 고가용성, 작업 효율을 고려한 AWS 비용 최적화 작업 내역 (62) | 2024.04.29 |
|---|---|
| FinOps 적용 방안 - 지표(Metric) 이용 (3) | 2023.10.12 |
| FinOps 소개 - 클라우드 핀옵스(책) 기반 스터디 참여 (1) | 2023.10.08 |