IT 리소스는 보통 공유되는 자원이고, 부서 비용에 큰 부분을 차지하며, 비즈니스 우선순위에 영향을 미치기 때문이죠.
그래서 이 IT 리소스 비용을 효율적으로 관리하는 것이 IT 리소스를 잘 사용하는 것 만큼이나 중요합니다.
그렇다면 Kubernetes 환경에서의 비용 관리는 어떻게 할 수 있을까요?
이번 포스팅에서는 IT 환경에서 비용을 관리하는 방법에서 시작해 Kubernetes의 비용 관리 도구인 Kubecost를 사용하는 방법까지 알아보도록 하겠습니다.
1. IT 비용을 어떻게 관리할 수 있을까?
1-1. Chargeback, Showback
FinOps 관점에서 IT 리소스 비용을 관리하는 방법은 크게 2가지로 구분할 수 있습니다.
첫번째는 Showback 모델입니다.
Showback 방식은 리소스 사용량을 각 부서에게 투명하게 공개하며, 이에 대한 실제 청구는 하지 않는 방식입니다.
주로 부서에 리소스 비용에 대한 인식을 높이는 것에 목적을 두며, 강제성을 띄지 않는 방식입니다.
두번째는 Chargeback 모델입니다.
Chargeback 방식은 리소스 사용량을 각 부서에게 투명하게 공개하지만, 비용 대한 실제 청구까지 실행하는 방식입니다.
부서에게 실제로 비용을 청구해 리소스를 효율적으로 사용하도록 강제성 및 책임감을 부여하는 방식입니다.
두 IT 비용 관리 방식의 차이점 및 공통점을 정리하면 아래와 같습니다.
특성
Showback
Chargeback
목표
비용에 대한 인식 재고
비용 관리에 대한 책임 부여
강제성
단순 비용 확인으로, 강제성을 가지지 않음
Budget을 정해 한도 내에서만 비용을 사용하게끔 하는 강제성을 가짐
공개 정보
비용, 리소스 사용량
비용, 리소스 사용량
비용 투명성
비용 관련 정보를 각 부서에게 투명하게 공개
비용 관련 정보를 각 부서에게 투명하게 공개
1-2. FinOps의 지향점
위에서 설명했다시피, Showback과 Chargeback은 도입 목표와 강제성에 있어서 상이한 차이점을 가지고 있습니다.
그렇다면 이 두 방식 중 효율적인 IT 비용 관리를 위해 최종적으로 도입해야 할 모델은 무엇일까요?
바로 Chargeback 모델입니다.
Kubecost에서 제안한 IT 부서의 비용 관리 방식의 도입 순서는 아래와 같습니다.
처음에는 단순히 비용 정산만을 수행하다가, Showback 모델을 도입한 후, Chargeback으로 변경한 뒤, 이를 집행하는 것이 IT 부서 FinOps의 도입 과정이라고 볼 수 있습니다.
그렇다면 왜 Chargeback 방식을 IT 부서가 지향해야 할 최종적인 비용 관리 방식인 걸까요?
1-3. Why Chargeback?
공유지의 비극(tragedy of common)은 구성원들이 공유 자원을 무분별하게 사용할시 결국 자원이 고갈되고 만다는 경제 용어입니다.
이 공유지의 비극 현상은 리소스를 여러 팀,부서가 공유하는 IT 부서에서 발생하기 쉽습니다.
특히 Cloud, Kubernetes 환경과 같이 이용자 입장에서 무한한 것처럼 보이는 리소스는 마치 공짜인 것처럼 받아들여지기 때문에 자원을 무분별하게 사용할 확률이 더 높습니다.
이러한 상황은 결국 공유하는 IT 자원을 무분별하게 사용해 과다 비용을 부르는 비극적인 결과를 낳게 됩니다.
따라서 IT 부서에서 공유지의 비극으로 인한 과다 비용 발생을 방지하기 위해서는 Chargeback 모델을 도입해 구성원들의 책임감있는 리소스 사용을 독려해야 합니다.
1-4. Kubernetese에서 Chargeback을 도입하기 어려운 이유
지금까지 FinOps 관점에서 Chargeback을 왜 최종 지향점으로 삼아야 하는지 알아봤습니다.
Chargeback 모델을 성공적으로 도입하기 위해서는 아래와 같은 4가지 요소로 비용을 정산할 수 있어야 합니다.
즉 Chargeback을 도입하기 위해서는 정산이 정확(Accurate)하고 공정(Fair)하게 이루어져야 하며, 시기 적절(Timely)하고 완전(Complete)해야 합니다.
하지만Kubernetes플랫폼을 통해서 IT 자원을 사용,관리하는 부서는 이 Chargeback 모델의 4가지 요소를 지키기 어렵습니다.
그것은 Kubernetes 플랫폼이 다른 환경과 구별되는 몇가지 특성을 가지고 있기 때문인데요.
Chargeback 모델을 도입하기 어렵게 만드는 Kubernetes의 특징들은 다음과 같습니다.
Multi-tenancy
Kubernetes 환경은 하나의 Cluster에서 Namespace 단위로 테넌시를 나눌 수 있는 Multi-tenancy 환경입니다.
여러 테넌시를 가질 수 있는 Kubernetes의 특성은 FinOps 엔지니어로 하여금 tenant 단위로 비용을 정산해야 하는 어려움을 부여합니다.
Short Lifecycle
Kubernetes에서 사용할 수 있는 오브젝트들은 대부분 짧은 생명주기를 가졌습니다.
Application이 올라가는 Pod와 그 안의 Container는 언제든 대체될 수 있는 객체이며, 영원히 존재하지 않습니다.
이렇게 Kubernetes 내의 오브젝트들은 짧은 생명주기를 가졌기 때문에 이에 대한 비용을 정산하려면 더욱 신속하고 정확한 비용 정산 능력을 필요로 합니다.
Flexible Environment
Kubernetes 플랫폼을 이루는 Cluster는 항상 변화하는 가변적인 환경입니다.
Cluster를 이루는 Node는 리소스 사용량에 따라 언제든 대체,축소 및 확장될 수 있습니다.
게다가 Cluster Autoscaler, Karpenter 등의 Cluster 자동 관리 도구들은 Kubernetes Cluster를 더욱 동적으로 변화시키는 역할을 합니다.
따라서 Kubernetes Cluster의 비용을 정산하기 위해서는 다양하게 변화하는 환경에 대응할 수 있어야 합니다.
2. Kubecost를 활용한 비용 관리
지금까지 Chargeback 모델을 왜 도입해야 하는지, 도입하기 위해서는 어떤 요소를 지켜야 하는지, Kubernetes 환경에서는 Chargeback을 왜 도입하기 힘든지 알아봤습니다.
위에서 말한 이유들때문에, Kubernetes 환경은 다른 환경보다 더 정교하고 정확한 비용 정산 능력을 필요로 합니다.
가령 아래와 같은 기존 Cloud Billing 보고서로는 Kubernetes의 테넌트별 비용, Pod별 비용, 네트워크 비용을 산출하기 어렵습니다.
그래서 Kubernetes 환경은 특수한 비용 관리 도구가 필요한데요.
이를 위해 등장한 것이 Kubecost입니다.
2-1. Kubecost란?
Kubecost는 Kubernetes 환경의 비용 가시성을 위해 2019년에 등장한 Opensource 도구입니다.
Kubecost는CSP(Cloud Service Provider)에서 가져온 Billing Data를 기반으로 Kubernetes의kube-api와 Prometheus를 통해 수집한 각종 메트릭을Aggregate해 Kubernetes 비용을 산출하는 구조를 가지고 있습니다.
이렇게 Kubecost는 CSP에서 제공하는 데이터를 기반으로 비용을 산출하기 때문에 정확한 비용 산정은 물론 CSP사에서 제공하는 할인된 가격을 기반으로 비용을 산출할 수도 있습니다. (On-demand, Spot, Negotiated pricing 등..)
현재 Kubecost는 Free, Enterprise 플랜을 제공하는 Kubecost와 Kubecost와 같은 비용 정산 엔진을 사용하지만 완전한 무료 오픈소스인 Opencost로 나누어져 있습니다.
이번 포스팅에서는 두 제품 중 더 다양한 기능을 제공하고 커뮤니티가 활발한 Kubecost의 Free plan을 활용해 비용 가시성을 확보하는 방법에 대해 알아보도록 하겠습니다.
2-2. Kubecost가 제공하는 기능
Kubecost는 Kubernetes 환경의 비용 가시성을 제공하기 위한 다양한 기능들을 가지고 있습니다.
Cost drill down by kubernetes objects
가장 중요한 기능은 역시 Kubernetes 클러스터에서 발생한 비용을 Kubernetes 오브젝트별로 측정 및 산출할 수 있다는 것입니다.
현재 Kubecost에서는 Kubernetes의 오브젝트인 Cluster, Container, Pod, Service, 등.. 다양한 오브젝트 별로 비용을 정산할 수 있는 기능을 제공하고 있습니다.
CSP, Vendor에서 제공하는 기존 비용 보고서는 사용한 리소스에 대한 비용만을 확인할 수 있기 때문에 Kubernetes 클러스터, 혹은 노드에 대한 정산만이 가능했습니다.
하지만 Kubecost는 CSP(Cloud Service Provider)에서 제공하는 Pricing table을 기반으로 CPU, RAM 사용량을 각 Kubernetes 오브젝트 별로 Aggregate함으로써 Kubernetes 환경에 특화된 비용 보고서를 받을 수 있습니다.
Kubernetes network cost
기존의 비용 보고서는 Network Egress 비용에 대한 거시적인 비용만을 제공했습니다.
이러한 방식으로는 최종적인 Network 비용에 대한 정보만을 확인할 수 있을뿐, Kubernetes 환경의 Network 흐름으로 인해 산출되는 비용에 대한 인사이트를 얻기 어려웠습니다.
이같은 어려움을 해결하기 위해 Kubecost는 각 노드마다 설치되는 Daemonset을 통해 각 Pod가 발생시킨 Network 비용을 유형별로 수집해 보고서에 포함하는 기능을 제공하고 있습니다.
CSP는 보통 Internet, Cross zone, Cross region 등 Network Egress 유형에 따라 비용을 달리 산정하는데, 이에 따른 유형별 Network Egress 비용을 Pod 별로 수집해 보고서로 확인할 수 있습니다.
Saving reports
Kubecost는 수집한 비용과 사용 중인 리소스를 기반으로 얼마만큼의 비용을 절약할 수 있는지 알 수 있는 Saving report를 제공합니다.
Saving report에서는 노드 및 컨테이너의 Right-sizing, Pod와 Volume의 관리 등 다양한 방법으로 과다지출 비용에 대한 절약 방법을 확인할 수 있습니다.
Saving report는 단순히 과다 지출 내역을 알려주는 것 뿐만 아니라, 절약을 위해서 변경할 수 있는 선택지를 사용자에게 제안함으로써 비용 관리를 직관적이고 편리하게 수행할 수 있습니다.
3. Kubecost 설치 및 구성
이제부터는 kubecost를 어떻게 설치 및 구성하여 Kubernetes 비용 가시성을 확보할 수 있는지 알아보도록 하겠습니다.
3-1. kubecost architecture
Kubecost는 Multi-cluster 배포를 지원하기 때문에 여러 클러스터에서 수집한 비용을 하나의 뷰에서 확인할 수 있습니다.
따라서 비용을 수집할 클러스터와 비용을 확인할 뷰를 제공하는 클러스터를 구분하는 것이 좋습니다.
이를 고려해서 Kubecost는 아래와 같은 아키텍쳐로 구성할 수 있습니다. 위 아키텍쳐의 세부 사항은 아래와 같습니다.
각 클러스터에는 Prometheus, Kubecost를 설치합니다.
Prometheus는 설치된 클러스터의 메트릭을 수집해 저장합니다.
각 클러스터에 설치된 Prometheus의 메트릭을 중앙 클러스터의 Grafana로 Aggregate합니다.
각 클러스터에 설치된 Kubecost를 중앙 클러스터의 Kubecost로 Aggregate합니다.
User는 중앙 클러스터에 노출된 Grafana, Kubecost를 통해 비용을 확인합니다.
3-2. kubecost 설치
kubecost를 사용하기 위해 설치해야 할 컴포넌트는 크게 Grafana, Prometheus, Cost-analyzer 3개가 존재합니다.
이 3개의 구성요소는 비용을 수집할 클러스터(아키텍쳐상 환경별 4개 클러스터)인지, 비용을 확인하기 위한 뷰(아키텍쳐상 위의 mgmt 클러스터)를 제공하는 클러스터인지 여부에 따라 설치 여부가 달라집니다.
뷰를 제공할 클러스터
뷰를 제공하는 클러스터는 자기 자신의 비용 메트릭 수집 뿐만 아니라, 사용자에게 비용 정보를 제공하기 위한 뷰도 제공해야 합니다.
