한컴테크를 통해 한컴의 기술을 공유합니다. 한컴의 프로그래밍, 프레임워크, 라이브러리 및 도구 등 다양한 기술을 만나보세요. 한컴 개발자들의 다양한 지식을 회사라는 울타리를 넘어 여러분과 공유합니다. 한컴이 제공하는 기술블로그에서 새로운 아이디어와 도전을 마주하고, 개발자가 꿈꾸는 미래를 실현하세요.

한컴테크

HancomCloudCost와 클라우드 인프라 비용 절감

글쓴이 /

시작하며

본 포스팅에서는 한컴 클라우드의 운영과 비용 추적을 위해 개발된 HancomCloudCost(이후 HCC)가 어떤 프로젝트인지 설명해 드리고 그 개발 목적을 이해하는 데 도움이 되는 배경 정보를 소개하겠습니다. 그리고 클라우드 인프라 비용 절감이라는 주제에 대해서도 다뤄보겠습니다.

FinOps와 인프라 비용 절감

클라우드 인프라 비용 절감 주제에 관하여 이야기할 때, 기본적인 FinOps에 대한 용어는 어느 정도 파악하고 있는 것이 좋습니다. Financial Operations를 의미하는 FinOps는 IT업계에 클라우드 투자가 증가하면서 그 비용 효율성과 프로젝트 가치를 최적화하기 위해 자연스럽게 발생한 문화입니다. 간단히 정의하면 클라우드 리소스 효율성과 서비스의 비즈니스 가치를 극대화하는 데 주안점을 두는 문화적 관행입니다. 기존 인프라 관리가 클라우드 환경에서는 효과적이지 않다는 사실을 인식하고 수용하여 기술과 재무 및 비즈니스 간에 협업할 수 있는 팀을 결합하는 새로운 문화를 만드는 것입니다.

FinOps가 조직에 도움을 주는 이점은 명확합니다. 크게 세 가지가 있습니다.

  1. 조직은 FinOps를 통해 비용의 출처를 명확하게 추적할 수 있으며 현재 지출과 과거 지출을 비교하여 주요 프로젝트의 우선순위와 성장 동력을 파악할 수 있습니다.
  2. FinOps는 실시간 데이터 통찰을 제공하여 조직이 빠르고 정확하게 대응할 수 있으며 사용량 기반의 클라우드 환경에서 빠른 의사 결정은 중요한 요소입니다.
  3. 유휴 자원을 식별해서 클라우드 낭비를 줄이고 지출을 효과적으로 통제할 수 있습니다.

FinOps 원칙을 자세히 살펴보면 기업은 클라우드 비용을 추적, 분석 및 최적화할 수 있는 정책과 프로세스를 수립하면서 비용을 절감하는 것 이상의 효과를 얻을 수 있음을 알 수 있습니다.

(※ 업계에서는 컨테이너화된 애플리케이션을 그 어느 때보다 많이 사용하고 있고 줄어들 기미가 보이지 않고 있습니다. 컨테이너화된 애플리케이션은 주로 온디맨드 클라우드 환경에서 운영되므로 지출을 효과적으로 관리할 필요성이 더 커지게 됩니다.)

비용 최적화 수명 주기(Lifecycle)

FinOps는 계층적이고 반복적인 프로세스입니다. FinOps 소개에서 흔히 볼 수 있는 최적화 수명 주기에 의하면,

<그림. FinOps Lifecycle(출처: 핀옵스 재단)>
  1. 먼저 ‘Inform’ 단계에서 비용 할당을 관찰하고
  2. 이를 기반으로 적절한 사이즈로 온디맨드 자원을 최적화한 후
  3. 다음 ‘운영’ 단계에서 비용과 속도, 품질의 균형을 확인합니다. 다시 Inform으로 돌아가 반복합니다.

여기서 알 수 있듯이 클라우드 인프라 비용 최적화를 시작할 때 첫 번째 나와야 하는 질문은 어떤 팀이 비용을 얼마나 주도하고 있는지 파악할 수 있어야 합니다. 여기서 FinOps의 핵심 원칙 중 하나는 총예산 지출이 아닌 팀이나 프로젝트 단위에 초점을 맞춰야 한다는 것입니다. 그래서 팀별 예산이 정해져 있는지, 그리고 팀 비용 지출을 알기 위해서 올바른 태깅(Tagging) 전략이 수립되어 있는지 등에 관한 질문이 따라옵니다.

많은 클라우드 서비스 공급자(CSP)는 여러 리소스를 관리하기 위해 리소스 태깅(Resource Tagging)을 지원합니다. 여기에서 적절한 태깅 전략이 이루어진다면 태깅을 통해 리소스를 그룹으로 묶어서 팀별로 비용 지출을 살펴볼 수 있습니다. 태깅 전략이 잘 이루어지면 어떤 팀이 어느 정도 비용을 얼마나 사용하고 있는지 파악할 수 있을 뿐만 아니라, 가용 리소스를 정확히 파악하여 효과적인 자원 할당으로 비즈니스 가치에 기반한 의사 결정이 가능해집니다.

쿠버네티스의 비용 측정

그렇다면 쿠버네티스 클러스터의 경우는 어떠할까요? 쿠버네티스의 핵심 구성 요소는 클러스터입니다. 클러스터는 여러 개의 마스터 또는 워커 노드가 클러스터를 이루고, 애플리케이션과 워크로드는 노드를 구분하지 않고 클러스터의 사용 가능한 자원을 공유하여 사용합니다. 이는 쿠버네티스의 중요한 설계 원칙 중 하나로 컨테이너 운영 자동화와 컨테이너 오케스트레이션은 쿠버네티스의 핵심 장점입니다.

일반적으로 팀이나 프로젝트(테넌트)마다 네임스페이스가 한 개씩 있습니다. 네임스페이스의 애플리케이션과 워크로드는 클러스터의 호스트 인프라 전반에 분산되어 있습니다. 따라서 쿠버네티스는 한 테넌트가 인프라의 자원을 얼마나 사용하고 있고, 얼마나 비용을 사용하고 있는가? 라는 기초적인 질문의 답을 매우 알기 어렵습니다. (*쿠버네티스에서 테넌트 별로 비용을 알기 어렵기 때문에, 노드마다 팀이나 프로젝트를 할당하는 소프트 멀티-테넌시 방식도 있지만 일반적이지 않습니다.)

하나의 프로젝트, 또는 하나의 팀이 비용을 얼마나 쓰는지 알 수 없고 실시간 가시성을 가지지 못한다면 비용을 최적화하기도 매우 어렵습니다.

HancomCloudCost

지금까지 소개한 문제를 해결하고 쿠버네티스 자원 비용 측정을 위한 니즈를 해결하여 주는 프로젝트입니다. HCC는 쿠버네티스 클러스터의 비용 측정 및 분석 도구입니다. 클러스터 운영과 관련된 비용을 파악하고 자원의 사용 효율을 쉽게 모니터링 할 수 있습니다. 이를 통해 의사 결정과 인프라 비용 최적화를 돕습니다.

다시 말하지만, 쿠버네티스 자체만으로는 쿠버네티스가 자원을 얼마나 낭비하고 있는지 알기가 어렵습니다. 이를 알기 위해서는 서드 파티 분석 도구가 필요합니다.

Key focus

HCC 프로젝트의 현재 상태는 PoC를 거쳐서 M1 단계입니다. M1 단계에서 핵심 목표는 크게 세 파트로 구분할 수 있습니다.

  • Spend Visibility
    • 클러스터 전체에서 네임스페이스별로 비용을 산정하고, 더 세부적으로는 쿠버네티스 리소스까지 구분하여 비용을 추적합니다. 그리고 한 화면에서 클러스터에 할당된 비용을 확인할 수 있는 가시성을 제공합니다.
  • Storing long-term data
    • 유관 부서와 의견 수렴을 하면서 사내에서 사용량 데이터의 장기 보관이 필요하다는 피드백을 받아 의견을 수렴하고, 도구의 활용도를 높이기 위해 장기 보관 요구사항을 반영했습니다. 쿠버네티스 전체에서 발생하는 성능 메트릭이 수집되면 원본 데이터가 생각보다 상당히 많이 쌓이게 됩니다. 이 데이터를 적극적으로 다운샘플링 하면서 장기적인 보관이 가능한 구조로 설계됐습니다.
  • Insight & optimization
    • 인사이트 모델이나 최적화 모델은 흥미로운 주제이지만, 지금은 기본적인 기능만 목표로 했습니다. 과거의 사용량 기반으로 시계열 예측 모델을 활용하여 과거의 비선형적이고 불규칙한 특성을 효과적으로 학습하여 미래 사용량을 예측하는 Forecast 대시보드를 제공합니다. Forecast 기능은 백엔드보다 더 적합한 언어와 환경을 사용한 별도의 마이크로서비스로 구현되었습니다.

아키텍처

<그림. 아키텍처 개요>

HCC는 시계열 데이터베이스(time series database, TSDB)와 메트릭 컬렉터 역할을 하는 Open Source Software와 긴밀하게 통합되어 작동합니다. HCC의 자체 Pod에서는 쿠버네티스 API를 통해서 쿠버네티스 컨트롤 플레인의 데이터를 쌓고 클라우드 서비스 제공자의 가격 및 요금 데이터 세트를 가져옵니다.

예를 들어, AWS 컴퓨팅 자원으로 작동하는 워커 노드라면 노드의 AWS 인스턴스 타입을 자동으로 감지하여 AWS Pricing 시트에서 해당 인스턴스 타입의 가격 정보를 가져오고, 기타 자원들도 여러 가지 방법으로 Pricing 데이터를 가져옵니다. 그리고 HCC는 kubelet cAdvisor에서 만들어지는 Pod 컨테이너의 vCPU, RAM, PV, Network 등 리눅스 커널로부터 수집된 메트릭을, 컬렉터 에이전트가 수집하여 시계열 데이터베이스인 InfluxDB에 저장합니다.

최종적으로 수집된 메트릭 데이터로부터 우리의 비용 모델과 인사이트를 만듭니다. 그리고 최종 사용자를 위해 대시보드 UI와 API 서버를 제공합니다.

  • 데이터 파이프라인
    • 컨테이너에서 사용된 자원 사용량 메트릭은 비용 산정의 원시 데이터가 되며, 이를 수집해야 합니다. 쿠버네티스는 모든 노드마다 실행되는 kubelet 에이전트가 있고 kubelet 안에는 구글이 개발한 오픈소스 컨테이너 모니터링 도구인 cAdvisor가 포함되어 있어 컨테이너 런타임으로부터 컨테이너 실시간 리소스 사용량을 전달받고 수집합니다. cAdvisor로부터는 수집된 노드 메트릭과 기타 여러 가지 필요한 지표를, 노드마다 사이드카 패턴으로 붙은 Telegraf agent가 이를 모아서 우리의 시계열 데이터베이스로 보내 저장합니다. 그리고 HCC는 원시 데이터를 이용하여 비용 메트릭을 만듭니다.
  • 시계열 데이터베이스
    • InfluxDB는 가장 많이 사용하는 TSDB고 성능 및 기능 측면에서 우수하며 특히 쿼리 기능이 뛰어납니다. 클라우드 네이티브 컴퓨팅 재단(CNCF)에서는 쿠버네티스 모니터링을 위해 프로메테우스(Prometheus)를 제안하는데 InfluxDB와는 Pull vs. Push 기반 방식이라는 데이터를 수집하는 모델 차이는 있지만, 성능과 사용성 면에서 큰 차이가 없습니다.
  • 프레임워크
    • 대시보드 UI는 Vue.js를 사용했으며, 백엔드는 Go언어와 Gin 웹 프레임워크로 만들어졌습니다.

Screenshots

<그림. 대시보드-Overview>
<그림. 대시보드-Assets-Details>
<그림. 대시보드-Cost Allocations>
<그림. 대시보드-Cost Allocations-Contorllers>
<그림. 대시보드-Insight>
<그림. 대시보드-namespace Details>
  • Overview
    • 클러스터 전체상황을 한눈에 볼 수 있으며 주요 기능들에 대해서 요약해서 볼 수 있습니다.
  • Cost Allocation
    • 가장 까다로운 부분이고 개발에 신경을 써야 하며 실시간, 정확성, 명확한 비용 산정이 매우 중요합니다.
  • Assets
    • 클러스터 운영과 관련된 모든 자원의 기간별 발생 비용을 확인할 수 있습니다.
  • Insignt
    • 시계열 예측 모델을 활용하여 네임스페이스의 미래 사용량을 예측하는 대시보드를 제공합니다.

마치며

HCC를 활용하면 무엇을 할 수 있을까요?

  1. 기본적인 쿠버네티스 개념 단계에서부터 각 팀과 프로젝트별로 사용하고 있는 비용 할당과 리소스 효율을 추적하여 비용 지출을 분석할 수 있습니다. 즉, 사용자는 이를 통해 가용 리소스를 정확히 파악하고 인프라 비용을 최적화할 수 있습니다.
  2. 조직은 어떤 팀이나 프로젝트가 클라우드 전체에서 어느 정도 비용을 얼마나 사용하고 있는지 파악할 수 있습니다. 이를 통해서 더 필요한 프로젝트에 리소스를 할당하거나 데이터를 기반으로 의사 결정이 가능합니다. 재무적 입장에선 클러스터 전체 비용에서 팀과 프로젝트 간에 예산을 나눌 수 있습니다.
  3. 단순히 우리의 서비스가 쿠버네티스에서 얼마나 자원을 사용하고 있고 어떻게 서비스가 성장하고 있나 모니터링만 하는 용도로 사용할 수 있습니다.

추천하는 활용 방법은, HCC의 비용 모니터링을 FinOps와 연계하여 비용 중심의 팀 간 소통을 하는 것입니다. 클라우드 리소스를 사용하는 각 팀이 비용 모니터링 데이터를 공유 받고 비용 책임을 가지도록 조직을 활성화함으로써, 비용을 더 효과적으로 관리할 수 있습니다.

HCC의 다음 마일스톤은 더 다양한 리소스 사용 패턴의 모니터링, 자동화된 최적화, 인사이트 엔진 강화 등 비용을 효율적으로 관리하기 위한 흥미로운 여정이 기다리고 있습니다. 또한, 쿠버네티스의 변화에 발맞춰 우리의 시스템을 최적화하는 노력도 계속되고 있습니다.

이 글이 쿠버네티스 비용 모니터링에 대해 관심이 있는 여러분의 궁금증을 해소하고 도움이 되었기를 바랍니다.

Post Views: 1,953
Scroll to Top