쿠버네티스 비용 분석과 정산
우리는 일상에서 비용을 정산해야 할 경우가 많이 있습니다. 각자 자기 비용을 내고 음식을 주문하는 경우는 어렵지 않지만, 모임에서 회식을 하는 경우 여러가지 음식을 시켜서 공유하는 경우가 많습니다. 술을 많이 마시는 사람이 있는가 하면, 안주를 많이 먹는 사람이 있고, 처음부터 참석하는 사람이 있는가 하면 뒤늦게 합류하는 경우도 있습니다. 2차, 3차로 모임이 이어지는 경우라면 더 복잡해 지고, 일부 특정인에게 혜택이 돌아가는 비용을 공동 부담하게 된다면 비용정산에 대해 불만을 가지는 경우가 많아질겁니다.
또 다른 예로 분식집에서 5천원에 김밥을 주문했는데 10조각으로 잘려서 나왔다면 한조각에 500원이라고 볼 수 있을까요? 모든 조각이 정확하게 1/10로 잘려있지 않을테고, 양쪽 꼬퉁이는 보통 밥보다 속이 많아서 원가가 다를겁니다. 또한 비슷하게 잘린 조각이라도 속의 두께가 정확하게 같을 수 없고, 같이 제공되는 반찬 비용을 얼마로 계산할거냐에 따라 김밥 한조각의 비용을 산정하는게 더욱 복잡해 질겁니다.
쿠버네티스는 동일한 리소스를 여러 Tenant가 공유함으로써 (멀티테넌시) 주어진 리소스를 보다 효율적으로 사용할 수 있습니다. 동적으로 리소스가 필요에 따라 할당되는 특성은 서비스 운영을 유연하게 해주는 장점이지만 비용정산 측면에서는 오히려 걸림돌로 작용하게 됩니다.
쿠버네티스 환경의 비용정산이 필요한 경우는 직접적으로 사용량에 따라 비용이 청구되는 퍼블릭클라우드 뿐 아니라 프라이빗 클라우드 환경에서도 발생합니다. 여러 팀이 복수의 서비스를 쿠버네티스 환경에서 운영하는 경우, 팀별로 원가 정산을 해야 할 필요성이 있고 서비스의 사업성을 판단하기 위해서 원가 계산이 필요한 경우도 있습니다. 또한 지속적으로 늘어나는 리소스 요구사항이 과연 적절한지, 증설이 실제로 필요한지, 낭비되는 리소스는 없는 지 판단하기 위해서는 쿠버네티스 리소스가 어떻게 분배되어 사용되고 있는지 비용측면에서 분석할 필요성이 생기게 됩니다.
쿠버네티스 비용 정산 요구사항
쿠버네티스 비용정산에 대한 요구사항은 크게 4가지정도로 볼 수 있습니다. 첫번째는 Cluster, Namespace, Controller, Pod, Service등 쿠버네티스의 컨셉에 따른 비용분석, 두번째는 가시적인 비용 분석 기능, 세번째는 리소스를 운영하는 팀, 부서등과 같은 조직구조나, 환경(DEV, STG, PRD)에 따른 비용집계, 네번째는 비용최적화를 위한 권고안 등입니다. 비용이 세부적으로 분석된다면 자연스럽게 비용절감을 위한 최적화가 이루어지게 되는데 시스템의 규모가 커질 수록 비용절감 요소를 수작업으로 찾는 작업이 쉽지 않기 때문에 이를 쉽게 찾아내고 궁극적으로 자동화 할 수 있는 FinOps 요구사항이 점차 커지고 있습니다.
일반적으로 클라우드 환경에서 30%이상의 리소스가 불필요하게 사용된다고 알려져 있습니다. 낭비되는 리소스를 찾아내고 최적화를 달성하기 위해서는 우선적으로 세부적인 비용 분석을 위한 가시성이 확보되어야 합니다. 사용한 만큼 비용을 지불하기 때문에 퍼블릭클라우드로 이전하면 비용을 절감할 수 있다는 기대로 옮겨갔던 기업들이 오히려 비용이 더 많이 들어가는것을 체감하고 종종 되돌아 오는것도 기존에 데이터센터에서 운영하던 형태로 리소스를 사용하고 낭비되는 리소스를 적절히 관리하지 않은것은 아닌지 되돌아 볼 필요가 있습니다.
쿠버네티스 비용 요소
쿠버네티스 클러스터의 비용은 오픈소스 프로젝트인 OpenCost (https://www.opencost.io/) 에서 정의한 내용을 참조하면, Cluster Asset Costs와 Cluster Overhead Costs로 나눌 수 있고, 이중 Cluster Asset Costs는 다시 Resource Allocation Costs와 Resource Usage Costs로 나눌수 있습니다.
개념만으로 보면 쉽게 이해하기 어려운데 아래 그림에서 실제 퍼블릭 클라우드에서 청구되는 노드, PV, 네트워크, 클러스터 관리비용 등과 매칭을 시켜보면 좀 더 이해하기 쉽게 해석될 수 있습니다. 쿠버네티스 환경의 비용정산이 어려운것은, 쿠버네티스는 이를 논리적으로 나누어 사용하기 때문에 쿠버네티스 컨셉에 맞추어 비용을 정산하기 위해서 노드, PV, 네트워크 비용, 클러스터 관리비용을 더 세분화하고 이용현황에 맞도록 정산해야 하며, 공통되는 비용은 재배분해야 할 필요가 있습니다. 이렇게 되어야 어떤 관점에서 비용을 집계하더라도 정확하게 비용을 정산할 수 있습니다.
Cluster Asset Costs를 실제 Container, Pod, Deployment등과 같은 쿠버네티스 워크로드로 환산할때는 Idle Cost를 같이 고려해야 합니다. Idle Cost는 실제 쿠버네티스 워크로드가 할당된 비용은 아니지면 결국 비용이 발생하므로 이를 해당 노드를 사용하는 워크로드에서 공유하게 되고 Idle Cost를 최소화하기 위한 노력 또한 필요합니다. 따라서 실제 워크로드 비용은 Allocated Costs와 Resource Usage Costs의 합이지만 비용측면에서 Resource Allocation Costs는 Idle Costs 와 Allocated Costs의 합이 됩니다.
비용 절감을 위한 분석도구
클라우드의 비용을 관리하는 도구들은 시장에 많이 나와 있습니다만 쿠버네티스 환경에 대한 비용은 클라우드 사업자도 세부적으로 제공하지 않기 때문에 비용을 분석하기 쉽지 않습니다. 또한 실시간으로 비용을 확인 할 수 없기 때문에 자칫하면 요금폭탄을 만나게 되는 경우도 있습니다. 게다가 쿠버네티스를 사용하는 기업은 대부분 여러팀에서 독립적으로 배포를 하는 경우가 많아서 관리주체를 특정하기 어려운면이 있고, 프로그래밍방식으로 리소스를 프로비저닝하는 경우는 대량의 리소스가 한꺼번에 생성되기도 합니다. 잘못된 설정이나 또는 멀웨어등으로 리소스가 갑자기 프로비저닝 된다면 이를 실시간으로 인지할 수 있는 수단이 필요하게 됩니다.
아울러, 실시간으로 비용을 분석하기 위해서는 필연적으로 운영현황을 수집해야 하는데 여기에 많은 리소스가 들어간다면 이들 리소스 또한 비용을 증가시키기 때문에 비용분석도구는 최소한의 리소스를 사용할 수 있도록 최적화되어야 합니다.
통상 분석도구는 매트릭(Metric)과 디멘전(Dimension), 그리고 필터(Filter)의 조합으로 이루어 집니다. 메트릭은 시시각각 변하는 수치를 지속적으로 수집하는것을 의미하고 디멘전은 수집된 메트릭을 어느 관점에서 집계하여 바라볼것인가를 의미합니다. 마지막으로 필터는 메트릭과 디멘전의 조합으로 쌓여있는 데이터를 관심있는 부분집합으로 분리하여 보는 방법을 의미합니다.
Kubecost는 다양한 메트릭을 수집하여 처리합니다. 여기에는 노드별 CPU, GPU, RAM의 시간당 비용, 네트워크 egress, CAdvisor를 통한 Container 리소스 이용현황, K8s 상태정보 (KSM), Node Exporter를 통한 하드웨어, OS 관련 정보, GPU 이용현황등이 있습니다. 모든 메트릭은 Prometheus에 저장되는데 실제 Kubecost API를 통해 보여지는 정보는 Prometheus에 저장된 메트릭을 다시 한번 정제한 ETL 정보입니다. ETL 정보는 시간별, 일별 데이터로 집계가 되어 최소한의 리소스를 사용하여 빠르게 비용분석결과를 보여주게 됩니다.
대표적인 쿠버네티스 비용분석도구인 Kubecost의 Allocation 분석화면을 보면, Namespace별로 CPU, GPU, RAM, PV, Network, LB, Shared, Efficiency등이 세부적으로 분석된것을 볼 수 있습니다. 이 내역들이 비용으로 환산된 메트릭이며, Namespace라는 디멘션으로 집계되어 (Kubecost에서는 Aggregation으로 불립니다) 시각적으로 표현되고 있고 필터는 지난 7일에 해당되는 필터가 적용되어 있습니다. 집계되는 방식은 Namespace외에 쿠버네티스 컨셉에 해당하는 Cluster, Service, Pod와 Team, Department, Environment, Label등 총18가지 Aggregation을 지원하고, 모든 Aggregation에 대해 필터를 적용하여 선별적으로 관심있는 영역을 분석할 수도 있습니다.
Namespace중 하나를 선택하면 하위 컨셉인 Controller, Pod, Container로 범위를 좁혀갈 수 있는데 이를 분석도구에서는 드릴다운(Drill Down)이라고 부릅니다. 드릴다운을 해나가다 보면, 마지막 리소스 단계인 CPU, RAM, PV등 최소 리소스별로 사용된 비용을 확인 할 수 있습니다.
분석된 내용은 주기적인 리포트 형태로 받아 볼 수 있고 비용에 대한 임계치(Threshold)를 설정하면 과도한 비용이 발생하는 경우 알람을 받을 수도 있습니다.
앞선 그림에서 시간대(일일)별로 비용 현황을 분석했다면 전체 비용을 리소스 사용량별로 집계하거나 Treemap형태, 백분율로 환산한 집계, 리소스 효율에 대한 추이등 다각도로 사용된 비용을 시각화하여 볼 수 있습니다.
클라우드 비용을 절감하는 방안중 가장 비중을 많이 차지하는것은 온디맨드 리소스대신 할인된 가격을 적용받을 수 있는 Reserved Instance, Enterprise Discount Plan, Saving Plan, Spot Instance등을 최대한 활용하는것입니다. Kubecost는 디폴트로 온디맨드 가격을 기준으로 비용을 환산하지만 빌링정보(AWS Cost and Usage Report, Azure Cost Export, Google BigQuery Export)를 통합하면 실제 할인되어 청구되는 비용과 일치하도록 조정된 결과를 볼 수 있습니다.
쿠버네티스를 사용하게 되면 여러가지 필요에 따라 멀티클러스터, 멀티 클라우드, 하이브리드 클라우드 환경으로 진화하게 됩니다. Kubecost는 이를 모두 통합하여 관리 할 수 있기 때문에 특정 부서가 여러 환경의 리소스를 사용하는 경우에도 이를 단일 화면에서 집계하여 쉽게 분석할 수 있습니다. 또한 클러스터내 비용과 더불어 클러스터 외부의 자원까지 관리 할 수 있기 때문에 쿠버네티스 환경을 포함한 클라우드 비용을 전반적으로 분석할 수 있고 클러스터내에서 공유되는 비용을 적절히 분배하여 집계할 수 있습니다.
비용 절감 지원 기능
비용분석의 궁극적인 목적은 비용절감에 있다고 할 수 있습니다. 불필요하게 방치된 리소스로 인한 비용이나 과도하게 설정된 리소스들, 효율이 떨어지는 워크로드를 식별하고 적절한 사이징을 추천해 주기 때문에 알람기능과 함께 사용하면 생각보다 많은 비용을 절감할 수 있습니다.
대표적인 비용절감 기능은 클러스터 노드나 컨테이너에 대한 Right-Sizing이 있습니다. 분석기간을 설정하여 리소스 이용률을 분석한 후 노드나 컨테이너에 대한 사이징을 적절히 추천해 줍니다. 컨테이너의 경우, 요청한 리소스양과 실제 리소스가 사용된 최대양을 기준으로 베이스라인을 잡아준 후 일정량의 마진을 조합하여 추천하는 방식으로 클러스터나 컨테이너가 사용되는 환경에 따라 마진을 다르게 가져가게 됩니다. 예를들어 개발환경은 조금 더 타이트하게, 운영환경은 조금더 여유를 두고 적절한 사이징을 추천해 줍니다. 추천받은 사이징을 참고하여 직접 변경을 할 수도 있지만 이를 도구상에서 직접 적용하거나 지속적으로 자동화 하는 기능도 구현되어 있습니다. 컨테이너 Right-Sizing 영역은 오픈소스로 제공되는 도구가 몇가지 있고 상용솔루션도 나와 있습니다. 도구별로 추천값을 도출하는 방식에도 다소 차이는 있지만 대동 소이한 것으로 보이고 Right-Sizing을 중심으로 특화된 영역이 각기 다르기 때문에 편이성이나 각 도구가 궁극적으로 지향하는 바를 보고 판단하는것이 바람직 합니다.
Right-Sizing은 쿠버네티스 특성상 큰 비용절감의 여지가 있는 영역입니다. 필요한 리소스만큼 쿠버네티스 노드를 채워가다보면 필연적으로 남은 리소스를 활용하지 못하는 경우가 생깁니다 (Bin Packing Problem 이라고 합니다) 이 경우 어쩔수 없이 새로운 노드를 추가하게 되는데, 기존 노드의 Idle 리소스는 물론 새로운 노드에는 새로운 컨테이너만 사용될 뿐 더 많은 Idle 리소스가 생기게 됩니다. 컨테이너들이 Right-Sizing을 통해 기존 노드내에서 수용되거나 노드 타입을 변경해서 불필요하게 낭비되는 Idle 리소스가 발생하지 않는다면 비용을 비용을 절감할 수 있게 됩니다.
더 이상 사용되지 않는 워크로드에 대해서도 식별하는 기능이 있는데 해당 워크로드에서 얼마만큼의 트래픽을 발생하는지가 기준이 됩니다. 트래픽이 없다고 사용되지 않는다고 보장할 수는 없지만 리소스에 대한 릴리즈가 누락되었거나 야간이나 휴일에 사용되지 않는 개발환경등 정리대상을 쉽게 식별할 수 있습니다. 그외에 삭제과정에서 남겨진 (Orphaned) 리소스나 이용률이 적은 노드, 이용되지 않는 볼륨을 식별해 주고, Spot Instance로 전환할 수 있는지 검증하는 기능도 제공합니다. 정리되었을때 절감할 수 있는 비용이 얼마나 되는지 금액으로 표시해 주기 때문에 우선순위를 쉽게 정할 수 있고 비용절감을 직접적으로 체감할 수 있는 효과가 있습니다.
마치며
쿠버네티스 비용 분석 분야에서 Kubecost는 독보적인 위치에 있습니다. 오픈소스 프로젝트를 통해 핵심엔진에 대한 개선이 지속적으로 이루어지고 있고 Enterprise 향 기능도 FinOps 문화에서 요구하는 기능들을 (e.g. Cost Center) 대부분 채워나가고 있습니다. 설치형이나 SaaS 버전 모두 Free Tier를 지원해서 Enterprise 버전에서만 지원되는 멀티클러스터, 15일이상 Retention등이 없더라도 충분히 활용해 볼 만 합니다. 또한, AWS EKS를 사용하고 있다면 무료로 제공되는 Bundle 버전에서 일반 Free Tier보다 많은 기능을 제공하고 쉽게 설치할 수 있도록 통합되어 있기 때문에 좀 더 쉽게 접해 볼 수 있습니다.
Written by Jay Kim
Jay 는 OSC Korea의 공동설립자 겸 CTO로 글로벌 기술기업에서 20년 이상 엔지니어 및 컨설턴트로 활동하며, 네트워크, 방송/통신 및 다양한 분야의 IT 신기술을 국내 도입한 경험을 보유하고 있으며, 현재 OSC Korea 의 신규 솔루션 발굴과 내재화를 이끌고 있습니다.
Kubecost 는
쿠버네티스 비용 실시간 분석 및 모니터링에서 비용주체별 정산, 리소스 최적화를 통한 비용절감, 비용알람과 퍼블릭 클라우드 비용 통합관리에 이르기까지 종합적인 비용 거버넌스를 제공하는 FinOps 솔루션입니다. Kubecost 에 대한 상세소개나 데모를 원하시면 한국파트너 OSC Korea 로 문의 주세요.
