클라우드 비용 최적화를 위한 Automatic Labeling System 구축기

1. FinOps는 왜 어려운가

1. 측정 가능한 비용, 불가능한 비용

클라우드 인프라를 운영하는 사람이라면 누구나 비용 최적화를 원합니다. 하지만 이를 달성하는 것은 누구에게나 쉽지 않습니다. 그래서 이 문제를 해결하기 위해 많은 이들이 FinOps 와 같은 프레임워크를 도입해 이 같은 문제를 해결하고자 해왔습니다. FinOps는 클라우드와 같은 기술 분야에서 비즈니스 가치를 극대화하고자 하는 운영 프레임워크이자 문화를 뜻합니다.

하지만 FinOps를 적용하는 과정에서 기술 비용과 재정 비용 사이의 최적해 를 찾아야 하는 문제를 마주하게 됩니다. 이는 재정 비용을 절감하고자 하면 기술적인 운영, 관리에 소요되는 비용인 기술 비용이 상승하고, 기술 비용을 절감하고자 하면 재정 비용이 상승해 조직 전체의 Budget이 줄어든다는 Tradeoff를 말합니다.

이 같은 Tradeoff는 대부분의 조직에서 해결하기 어려운 문제입니다. 왜냐하면 문제를 해결하기 위해 비용을 측정하는 것부터 쉽지 않기 때문입니다. 다행히 재정적 비용($)은 청구서에 적힌 숫자를 통해 쉽게 확인할 수 있지만, 기술적 비용은 Engineer의 운영, 개발, 유지 보수에 들어가는 Man power 및 소모되는 시간, 기술적인 부채 등 다양한 정성적 요소들을 포함한 까다로운 측정이 필요하다는 어려움이 있습니다.

2. 비용과 배분

그렇다면 비용 최적화는 달성할 수 없는 목표일까요? 왓챠의 플랫폼 팀은 Tradeoff 문제를 풀기 위해 완벽한 최적해를 구하는 대신, 개선 가능한 영역을 식별하고 이를 통제하는 것으로 비용 최적화를 달성하고자 했습니다. 즉 산출하기 까다로운 기술 비용을 측정하려고 하는 대신, 상대적으로 확정적인 재정적인 비용을 분석해 효율화를 달성하고자 했습니다.

하지만 재정적인 비용을 분석하는 작업은 이 비용이 언제, 누가, 어떤 서비스 때문에 생성되었는가? 등의 다양한 비용의 메타 정보 (Metadata)를 필요로 합니다. 이러한 메타 정보는 재정적 비용을 더 세밀하게 식별할 수 있게 해주며, 특히 비용을 대상에 대응시키는 비용의 배분(Cost allocation)을 가능케 하기 때문에 중요합니다.

3. Resource Labeling을 통한 해결

비용의 메타 정보 정의는 기술적인 영역에서 봤을 때 리소스 라벨링(Resource Labeling)으로 구현할 수 있습니다. 리소스 라벨링이란 서비스가 제공하는 Labeling, Tagging 등의 방법을 활용해 리소스에 적절한 의미를 담은 메타 정보를 정의하는 작업을 의미합니다.

리소스 라벨링을 통해 운영자는 Cloud 리소스와 같은 기술적인 재고(Inventory)에 높은 cardinality를 부여함으로써 비용의 맥락을 더 정밀하게 파악할 수 있습니다. 또한 잘 구성된 리소스 라벨링은 다음과 같은 질문에 답을 할 수 있게 합니다.

1. Who : 이 비용은 어느 팀의, 혹은 누구의 책임인가?
2. What : 어떤 서비스, 혹은 프로젝트에서 발생했나?
3. Where : 어떤 환경(Dev,Test,Prod..)인가?
4. When : 언제 생성되었나?
5. Why : 이 리소스의 목적은 무엇인가?

따라서 왓챠의 플랫폼 팀은 기술 비용을 측정하는 대신, 리소스 라벨링을 통해 비용의 메타 정보를 세밀하게 정의함으로써 재정적 비용에 맥락을 부여하고 이를 분석해 비용 최적화를 이루고자 했습니다.

2. Labeling을 향한 여정

1. Resource Labeling의 어려움

하지만 많은 조직에서 리소스 라벨링을 통한 FinOps를 제대로 정착시키는 것은 어려운 과제였습니다. 기존의 왓챠 또한 그 많은 조직 중 하나였습니다. 기존 왓챠에서는 리소스 라벨링을 위해 라벨에 대한 컨벤션, 규약을 담은 Labeling Policy를 문서 형태로 배포하고 이를 반영한 라벨링을 수동으로 작업하도록 했습니다.

하지만 해당 정책은 문서로만 정의되어 있는 권고 사항에 불과했기 때문에 정책을 지키도록 강제하지는 못했습니다. 따라서 초기에는 조직 구성원들이 Labeling Policy를 준수해 리소스를 생성했었으나, 아래의 이유로 정책이 유명무실화되는 문제가 있었습니다.

1. Labeling의 누락 : 사용자가 Labeling Policy를 준수하지 않는 Label을 정의하거나 Labeling 자체를 수행하지 않는 경우가 존재했습니다.
2. 긴급 대응 시 리소스 생성 : 장애 대응, 이슈 해결 등의 상황에서 리소스 생성 시 Labeling을 건너뛰는 상황이 존재했습니다. 이 경우 추후에 Labeling을 하겠다고 하지만 그러하지 않는 경우가 대다수였습니다.
3. 자동화 프로세스에 의한 리소스 생성 : 사용자가 직접 생성한 리소스가 아닌, Autoscaling 등 System이 자동으로 생성한 리소스의 경우 Labeling이 전파되지 않았습니다. 리소스 자동 생성 후 Manual labeling을 수행하고자 했으나 이는 리소스의 Scale이 커질 수록 비현실적인 방법이 되었습니다.
4. 자연적인 소멸 : Labeling Policy는 강제성을 띈 정책이 아니었기 때문에 신규 입사자가 입사하거나 기존 조직원이 퇴사할 경우 해당 정책의 규율이 희미해져 점점 지켜지지 않았습니다.

위 문제를 해결하기 위해 플랫폼 팀에서 가장 우선적으로 고려했던 방안은 Labeling Policy의 강제화였습니다. Labeling Policy를 지키지 않으면 리소스가 생성되지 않게 하거나, 미준수 리소스를 제거하는 방안입니다. 하지만 이와 같은 정책은 기술 체계에 익숙지 않은 Engineer에게 리소스 이용의 Hurdle로 작용할 수 있었으며, 장애 대응과 같은 긴급 상황 시에 대응 시간을 늦출 수 있다는 우려가 있었습니다.

따라서 왓챠에게 필요한 것은, 이용자 경험을 해치지 않으면서 모든 리소스에 일관된 Labeling을 보장할 수 있는 방법이었습니다.

2. 자동화를 통한 해결

방법을 찾기 위한 첫걸음으로 Policy 기반 Labeling의 실패 원인을 파악하고자 했고, 이를 통해 Resource Labeling이 아래의 영역에서 실패했다고 판단했습니다.

1. 규모 (Scale) : Cloud와 같은 기술 기반의 규모가 커질수록 사용자가 수동으로 입력하는 Labeling은 비현실적인 방법이 되었습니다. 사용자의 Labeling 입력 속도가 리소스의 증가 속도를 따라가지 못했기 때문입니다.
2. 일관성 (Consistency) : 사용자의 수동 입력에 의존하는 Labeling은 인적 오류(Human error)를 유발할 수 있었습니다. 오타, 정책 미준수, 라벨 누락 등의 원인으로 Labeling Policy의 일관성을 유지하기 어려웠습니다.
3. 지속성 (Continuity) : 초기 Labeling Policy를 정의했을 시에는 정책에 대한 관리가 잘 이루어지는 듯 했지만, 시간이 지나며 방치되는 문제가 있었습니다. 방치된 정책은 라벨의 적용 범위(Coverage)를 떨어뜨리는 결과로 이어졌습니다.

팀에서는 이러한 실패 영역을 어떻게 우아하게 해결할 수 있을까? 라는 문제를 지속적으로 고민했습니다. 고민 끝에 나온 결과는 "자동화(Automation)를 통해 기존 Policy Labeling의 단점을 극복" 하는 방식이었습니다.

이러한 결론의 첫 번째 근거는 자동화 시스템으로 리소스 규모 문제를 해결할 수 있다는 것이라는 기대였습니다. 자동화된 시스템은 인간과 달리 리소스의 규모가 아무리 커져도 결국 모든 리소스에 라벨링을 수행할 수 있기 때문입니다.

두 번째 근거는 자동화 시스템으로 일관성 문제 를 해결할 수 있을 것이라는 기대였습니다. 시스템은 정의된 정책을 매번 동일하게 적용할 수 있기 때문에 일관적인 Labeling을 유지할 수 있습니다. 그리고 시스템의 도입은 인간의 개입으로 인한 인적 오류(Human error)를 미연에 방지할 수 있을 것입니다.

마지막 근거는 자동화 시스템으로 시간이 지날수록 정책이 희미해지는 지속성 문제를 해결할 수 있을 것이라는 기대였습니다. 시스템은 사람과 달리 퇴사하거나 잊어버리지 않기 때문에 정책을 일관적으로 유지할 수 있을 것입니다.

위의 이유로 기존의 Manual 한 Policy 기반의 Labeling의 실패 영역을 극복할 수 있는 "Automatic Labeling System"을 설계해 비용 최적화를 위한 맥락을 확보하고자 했습니다.

3. Automatic Labeling System

1. 설계 목표

시스템을 설계할 때 가장 중요한 것은 해당 시스템이 달성해야 하는 목표가 명확해야 하다는 것입니다. 이에 따라 Automatic Labeling System을 설계할 시 달성하고자 하는 목표를 다음과 같이 정의했습니다.

1. 라벨링 커버리지(Labeling Coverage) 확대 : 가능한 많은 리소스가 해당 라벨링 시스템을 통해 라벨링 되는 것을 목표로 했습니다. 이 시스템의 궁극적인 목적은 비용 최적화를 위한 도구가 되는 것입니다. 따라서 많은 기술적 재고(Inventory)들이 비용 최적화를 위한 정보를 산출할 수 있도록 목표를 정의했습니다.
2. 수동 작업(Manual job) 제거 : 해당 시스템은 인간의 개입 없이도 자동으로 동작하는 것을 목표로 했습니다. 이를 통해 앞선 문제였던 규모, 일관성, 지속성 문제를 자동으로 해결하고자 했습니다.
3. 기존 태그 존중 : 이미 존재하는 라벨들을 시스템이 임의로 덮어쓰거나 삭제하지 않도록 하고자 했습니다. 기존 라벨들은 다른 시스템이 필요로 하거나 리소스의 이력으로써 유의미한 정보를 제공할 수 있기 때문에 이러한 정보들을 유지하도록 했습니다.
4. 단일 시스템 지향 : 시스템은 여러 서비스 제공자, 혹은 테넌트에 분할되지 않고 단일한 시스템을 유지하도록 했습니다. 서비스 제공자마다 각각의 라벨링 시스템을 구축하기 보다는, 하나의 라벨링 시스템에서 모든 리소스를 라벨링함으로써 유지 및 관리의 포인트를 최소화하고자 했습니다.

2. 핵심 설계 원칙

시스템이 달성해야 하는 목표를 제시했다면, 이 목표를 달성하기 위해 시스템이 지켜야 할 일관적인 기준을 정의해야 합니다. 이러한 기준을 확립하기 위해 시스템이 지켜야 하는 핵심 설계 원칙을 정의했습니다. 핵심 설계 원칙은 최대한 단순하게 정의함으로써 지켜야 하는 기준이 모호해지지 않도록 했습니다.

1. Additive Only : 시스템은 기존 라벨을 덮어쓰지 않고 누락된 라벨만 추가한다. 현재 운용 중인 리소스 중에는 과거에 태그가 부착된 리소스도 존재했습니다. 이러한 과거의 태그들은 다른 시스템이 필요로 하거나 이력 보관 차원에서 덮어쓰거나 삭제하지 않고 남겨두도록 원칙을 정립했습니다.
2. Least Privilege : 시스템은 라벨링에 필요한 최소한의 권한만 부여받는다. 보안 관점에서 봤을 때 Automatic Labeling System은 가장 위험한 취약점이 될 수 있습니다. 조직 내 대부분의 리소스에 접근하는 광범위한 수행 영역을 가져야 하기 때문입니다. 따라서 시스템은 꼭 필요하거나 최소한의 권한만을 가지도록 해 시스템 탈취 시의 악용을 방지했습니다.
3. Fail Safe : 라벨링이 실패해도 리소스 자체의 동작에는 영향이 없어야 한다. 해당 시스템은 비용의 메타 정보 수집이라는 중요한 목표를 가지고 있지만, 이 목표가 전체 시스템의 가용성(Availability)보다 중요하지는 않습니다. 따라서 이 시스템이 목표를 달성하는데 실패해도 전체 시스템의 가용성에는 영향을 미치지 못하도록 했습니다.

3. 아키텍쳐

시스템이 가져야 할 목표와 원칙을 정의했다면, 이제 시스템이 이를 기반으로 동작할 수 있는 아키텍처를 설계해야 합니다. 아키텍처는 시스템 내부의 추상적인 계층을 설명하는 시스템 아키텍처 와 해당 시스템을 AWS 리소스로 구현한 인프라 아키텍처로 나눌 수 있습니다.

시스템 아키텍처

Automatic Labeling System의 시스템 아키텍처는 각자의 역할을 수행하는 4 계층(Layer)으로 나눌 수 있습니다. 각 계층의 역할은 다음과 같습니다.

1. Trigger Layer : 라벨링 프로세스의 시작점이며, "언제 라벨링 할 것인가?" 를 결정하는 역할을 합니다. 리소스 스캔을 통해 라벨링 할 리소스를 식별합니다. 리소스 스캔은 일정한 주기별로 라벨링 할 리소스를 식별하는 Schedule 기반 스캔과 실시간으로 이를 식별하는 Event 기반 스캔의 2가지 모드로 동작합니다. 각 모드는 서로의 스캔으로 놓친 리소스를 보완하여 리소스 커버리지를 일정하게 유지합니다.
2. Scope Layer : 이전 계층에서 식별된 리소스들을 필터링하며, "무엇을 라벨링 할 것인가?"를 결정하는 역할을 합니다. 스캔 된 리소스들이 비용 최적화 관점에서 라벨링이 필요한 리소스인지 판단합니다. AWS API Gateway Routes와 같이 비용이 부과되지 않아 라벨링이 필요하지 않은 리소스나, AWS Config Rule와 같이 비용을 분류하는 것이 의미 없다고 판단한 리소스가 필터링 대상에 포함됩니다.
3. Detection Layer : 이전 계층에서 필터링 된 리소스들을 분석해 "어떻게 라벨링 할 것인가?"를 결정하는 역할을 합니다. 리소스의 이름, 생성 시간, 생성자 등의 정보를 기반으로 이를 분석하는 "Label Builder"를 통해 적절한 라벨을 생성합니다.
4. Execution Layer : 라벨링 프로세스의 마지막 단계이며, 이전 계층에서 생성된 라벨을 기반으로 API 호출을 통해 실제 라벨링을 수행하는 역할을 합니다. 라벨링은 핵심 설계 원칙 중 "Additive Only" 원칙에 따라 기존 라벨을 침해하지 않는 선에서 수행합니다.

인프라 아키텍처

Automatic Labeling System은 현재 왓챠가 주 Cloud 인프라로 사용 중인 AWS환경에서 구축했습니다. 위 아키텍처 다이어그램에서 동작하는 라벨링 프로세스의 흐름은 다음과 같습니다.

1. 멤버 계정에서 리소스 생성 API 호출 (예: CreateBucket, RunInstances)
2. Organization CloudTrail이 해당 이벤트(Audit Log)를 Amazon S3에 기록
3. S3 Event가 해당 이벤트를 Amazon SNS 통해 Amazon SQS로 전달
4. AWS Lambda가 SQS에서 메세지를 소비 (Batch로 처리)
5. AWS Lambda가 소비한 메세지를 분석해 대상 계정의 AutoTaggingRole로 AssumeRole 수행
6. AWS Lambda가 Tagging API 수행을 통해 라벨링 적용
7. 실패 시 3회 재시도 후 DLQ로 이동

위 흐름에서 AWS Lambda가 라벨링을 수행하기 위해 위임받는 Role은 핵심 설계 원칙 중 Least Privilege 원칙에 따라 작업에 필요한 최소한의 권한만을 수행할 수 있도록 구성했습니다.

또한 기존 서비스 혹은 전체 시스템이 Automatic Labeling System에 의존성을 가지지 않도록 구성해Fail safe 원칙을 준수하도록 설계했습니다.

4. 도입 및 효과

도입 이전

위 아키텍처로 설계한 Automatic Labeling System을 배포 및 구축까지 성공적으로 수행할 수 있었습니다. 하지만 단순히 시스템을 설계하고 도입하는 것만으로는 해당 시스템이 실제로 목표를 달성했는지를 판단할 수 없었습니다. 따라서 "어떤 수치를 보였을 때 이 시스템이 성공적으로 설계 목표를 달성한 것인가?" 를 판단하기 위한 Success Metric을 정의했습니다.

팀에서 정의한 Automatic Labeling System의 Success Metric은 다음과 같았습니다.

1. Labeling Coverage Rate

• 정의: 라벨링 가능한 리소스 중 라벨링 된 비율
• 의도 : 설계 목표 중 하나인 Labeling Coverage를 측정
• 계산식 : (Tagged Resource Count) / (All Resources - Non-Taggable Resource Count) * 100

2.Labeling Success Rate

• 정의 : 자동 라벨링이 성공적으로 수행된 비율
• 의도 : 설계 목표 중 하나인 수동 작업의 제거를 측정
• 계산식 : Success Tag Event Count / Tag Event Count * 100

시스템을 구축하는 것만큼이나 해당 시스템을 운영하는 것 또한 중요합니다. Automatic Labeling System의 안정성 및 작업 현황을 파악하기 위해Operation dashboard를 구축함으로써 관련 메트릭 및 로그를 실시간으로 수집할 수 있도록 했습니다. 해당 Dashboard를 통해 Tagging log, Fail log, invocation Count 등 운영에 필요한 다양한 정보를 확인할 수 있습니다.

도입 결과

위와 같이 Success Metric 및 Dashboard를 정의한 후 실제로 System을 구동해 Labeling을 수행했습니다. 리소스는 대부분이 생성 후 수 초 내에 자동으로 라벨링 되었으며, 그 결과는 아래와 같았습니다.

1. Automatic Labeling을 통해 생성된 라벨링 상태

Labeling Policy에 정의된 정책을 기반으로 CostRegion ,CreatedBy..와 같은 Tag Key가 정상적으로 정의되었으며, Tag Value는 시스템이 리소스 분석을 통해 생성한 라벨이 부착된 것을 확인할 수 있었습니다.

2. 기존 Tag가 존재하는 리소스의 라벨링 상태

기존 태그는 존중한다는 설계 목표를 달성했는지 측정하기 위해 기존재하거나 다른 시스템이 생성한 라벨을 침해하는지를 확인했습니다. 확인 결과 Karpenter와 같은 다른 시스템이 생성한 태그를 삭제하거나 덮어쓰지 않는 것을 볼 수 있었습니다.

3. 리소스 라벨링 수치

시간 당 이벤트 메트릭을 확인해 보니 시간당 평균 8~9개의 리소스들이 태깅 되는 것을 확인할 수 있었습니다.

4. Success Metric 달성률

Labeling Coverage Rate

• 결과 : 11.9% -> 82.2% : +70.3%p
• 라벨링 가능한 리소스 중 실제로 라벨링 된 비율을 의미하는 Labeling Coverage Rate는 기존 11.9%에서 82.2%로 70.3%p 늘어나는 성과가 있었습니다.

Labeling Success Rate

• 결과 : 83.5%
• 자동 라벨링이 성공적으로 수행된 비율을 의미하는 Labeling Success Rate는 83.5%로, 시간당 평균 9~10회의 리소스 라벨링 시도 중 1~2회의 실패가 존재했습니다.

위의 결과를 분석하자면, Labeling Coverage Rate는 초기 11.9%에서 시스템 구동 후 82.2%로 70.3%p 증가함으로써 설계 목표였던 "라벨링 커버리지 확대"를 어느 정도 완수했다고 볼 수 있습니다.

또 다른 설계 목표인 "수동 작업 제거 "는 시간당 평균 8~9개의 리소스들이 생성 후 자동으로 태깅 되는 것으로 보아 이를 달성했다고 볼 수 있으며, "기존 태그 존중" , "단일 시스템 지향" 설계 목표 또한 시스템의 동작 방식을 통해 완수했음을 확인할 수 있었습니다.

이 같은 결과를 통해 Automatic Labeling System이 비록 몇몇 보완할 점이 남아있지만, 대부분 리소스에 라벨링을 수행함으로써 비용의 메타 정보를 성공적으로 수집할 수 있었습니다. 이는 결과적으로 비용의 배분을 가능케 했으며, 궁극적으로 기술 비용의 최적화를 수행하기 위한 기반으로써 기술의 비즈니스 가치를 높이는데 큰 역할을 했습니다.

4. 마치며

1. 개선이 필요한 점

이러한 성과에도 불구하고 Automatic Labeling System은 아직 개선이 필요합니다. 100%를 달성하지 못한 Labeling Coverage Rate는 아직 라벨링 되지 않은 리소스가 여전히 존재한다는 것을 의미합니다.

Labeling Success Rate가 80% 대라는 것 또한 남겨진 숙제였습니다. 더 높은 라벨링 성공률이 더 완전한 비용의 배분을 가능케 할 것입니다.

또한 리소스가 생성되는 시간과 리소스에 라벨링 되는 시간의 차이로 정보의 정밀성이 떨어지는 문제가 있었습니다. 예를 들어 Amazon EBS 디스크의 경우 Amazon EC2 Instance의 Launch와 함께 생성될 경우 생성 이벤트가 별도로 호출되지 않기 때문에, 스케쥴 기반 스캔만으로 라벨링을 수행합니다. 이는 리소스의 실제 생성 시간과 라벨링 시간 사이의 차이인 라벨링 다운타임을 유발했습니다. 비슷한 이유로 몇몇 리소스들의 라벨링의 다운타임이 높게 나타났습니다.

2. Next Step

Automatic Labeling System 구축의 다음 과제는 시스템의 개선입니다. 우선 Labeling Coverage Rate를 100%까지 올려 최대한 많은 리소스에 라벨링 하는 것을 목표로 하고 있습니다. Labeling Success Rate 또한 더 높여 완전한 시스템이 되도록 고도화할 계획입니다.

시스템의 개선보다 더 중요한 것은 수집한 리소스 라벨들로 유의미하게 비용을 최적화하는 것입니다. 비용의 메타 정보를 바탕으로 비용에 맥락을 부여하고, 이를 분석해 비용을 최적화하기 위한 비용의 배분(Allocation)을 본격적으로 수행할 예정입니다.

3. FinOps에서 Watcha의 목표

비용 최적화를 향한 여정은 여기서 끝이 아닙니다. 오히려 자동화된 라벨링 시스템의 구축은 여정의 첫 번째 단계에 해당합니다. 현재 왓챠의 플랫폼 팀은 수집한 비용 정보를 기반으로 지출의 현 상황을 파악할 수 있는 "비용의 가시성을 확보"한 상태입니다. 이는 대부분의 리소스에 비용의 맥락이 부여되었고, 비용을 정밀하게 배분할 수 있게 되었음을 의미합니다.

이제 본격적으로 비용 최적화를 위한 다음 단계를 수행하고자 합니다. 정밀하게 배분된 비용을 바탕으로 각 대상에게 비용을 공유 하고(Showback), 나아가 그들의 비용에 책임을 지는 구조(Chargeback)을 만들어가고자 합니다. 이를 통해 조직의 구성원들이 각자의 비용을 최적화할 수 있는 재정적 생태계를 구성하는 것이 FinOps 영역에서의 단기적인 목표입니다.

하지만 궁극적으로 Watcha가 FinOps를 통해 추구하는 것은 단순한 비용 절감이 아닙니다. 글의 서두에서 언급했듯이, FinOps의 본질은 기술 비용과 재정 비용 사이의 최적해를 찾는 것입니다. 비용을 무조건 줄이는 것이 아니라, 기술의 비즈니스 가치를 극대화하는 것이 FinOps에서 Watcha가 나아가고자 하는 방향입니다.

그리고 그 방향을 향해 나아가기 위해 끊임없이 측정하고 개선하고자 합니다.

---

클라우드 비용 최적화를 위한 Automatic Labeling System 구축기 was originally published in WATCHA on Medium, where people are continuing the conversation by highlighting and responding to this story.