클라우드 비용 할당을 위한 태깅 표준화 방법
2023년 5월 10일
|
10 mins read
태깅의 일관성은 클라우드 관리를 위한 가장 중요한 전략 중 하나입니다. 주요 클라우드 서비스 공급자가 태깅에 대한 정책 및 표준 개발을 지원하기 위한 지침과 고려 사항을 제공하지만 범용 클라우드 태깅에 대한 ”글로벌 표준“은 없습니다. 본 블로그에서는 효과적인 태깅 관리를 위한 태깅 표준의 예시를 소개하고자 합니다.
태깅 표준화의 필요성
태그를 가장 효과적으로 사용하는 회사는 일반적으로 비즈니스 관련 태그 그룹을 생성하여 기술, 비즈니스 및 보안 차원에 따라 리소스를 구성합니다. 비용 할당은 클라우드 재무 관리에 필수적입니다. 태그, 연결된 계정, 폴더 또는 레이블을 통해 효과적으로 수행할 수 있습니다. 태그, 레이블 및 계정은 많은 이점을 제공하지만 한 가지 주요 이점은 비용 할당을 위해 청구 데이터에 비즈니스 차원과 컨텍스트를 추가한다는 것입니다. 비용 할당 측면에서 리소스에 태그를 지정하는 두 가지 주요 방법인 범주화 및 계층적 접근 방식을 소개하려고 합니다.
태그 분류
1. 기술 태그
엔지니어가 리소스를 식별하고 작업하는 데 도움이 됩니다. 여기에는 애플리케이션 또는 서비스 이름, 환경 또는 버전 번호가 포함될 수 있습니다.
| Keys | Definition |
|---|---|
| Name | Identify individual resources |
| Application ID | Identify resources that are related to a specific application |
| Application Role | Describe the function of a particular resource (such as web server, message broker, database) |
| Cluster | Identify resource farms that share a common configuration and perform a specific function for an application |
| Environment | Distinguish between development, test, and production resources |
| Version | Help distinguish between versions of resources or applications |
2. 자동화 태그
계정의 각 리소스에 대한 정리, 종료 또는 사용 규칙을 자동화하는 데 사용할 수 있습니다. 예를 들어 더 이상 사용하지 않는 샌드박스 서버에 태그를 지정하고 스크립트를 실행하여 삭제할 수 있습니다.
| Keys | Definition |
|---|---|
| Date/Time | Identify the date or time a resource should be started, stopped, deleted, or rotated |
| Opt In/Opt out | Indicate whether a resource should be included in an automated activity such as starting, stopping, or resizing instances |
| Security | Determine requirements, such as encryption or enabling of Amazon VPC flow logs; identify route tables or security groups that need extra scrutiny |
3. 비즈니스 태그
비지니스 태그를 이용하여 이해 관계자는 비용과 각 리소스를 담당하는 팀 또는 비즈니스 단위를 분석할 수 있습니다. 예를 들어 작년에 출시한 새 제품에 클라우드 비용 중 몇 퍼센트가 사용되는지 알고 싶을 수 있습니다. 그러면 해당 노력의 투자 수익을 확인할 수 있습니다.
| Keys | Definition |
|---|---|
| Project | Identify projects that the resource supports |
| Owner | Identify who is responsible for the resource |
| Cost Center/Business Center | Identify the cost center or business unit associated with a resource, typically for cost allocation and tracking |
| Customer | Identify a specific client that a particular group of resources serves |
4. 보안 태그
보안 태그는 규정 준수 및 보안 표준이 조직 전체에서 충족되도록 합니다. 이러한 태그는 액세스를 제한하거나 많은 규정 준수에 대한 특정 데이터 보안 요구사항을 나타내는 데 사용될 수 있습니다.
| Keys | Definition |
|---|---|
| Confidentiality | An identifier for the specific data confidentiality level a resource supports |
| Compliance | An identifier for workloads that must adhere to specific compliance requirements |
계층 기반 접근 방식
계정은 상호 배타적이지만 태그는 그렇지 않습니다. 계정은 기본 색인으로 사용해야 하며 라벨은 보조 색인으로 상인합니다. 일반적인 모범 사례에서 조직은 계정을 사용하여 가장 중요한 기본 부서를 분할한 다음 태그를 사용하여 보다 세분화된 가시성을 위해 해당 계정을 더욱 깊이 분석할 수 있습니다.
계정을 사용하여 개별 제품 및 해당 환경을 분류할 수 있습니다. 서로 다른 제품 또는 애플리케이션은 종종 서로 다른 비용 센터 또는 예산을 나타내기 때문에 이는 중요합니다. 일부는 COGS 비용이고 일부는 R&D이므로 별도의 환경(개발, 생산, 스테이징 등)은 재무 팀에서 다르게 설명해야 할 수 있습니다. 또한 다양한 팀에서 생산 비용과 개발 비용을 함께 그룹화하여 자금이 어디로 가는지 확인하거나 비용 최적화를 위해 서로 다른 정책을 적용할 수 있습니다.
리소스 이름 지정 표준화
범용 클라우드 리소스에 이름을 할당하는 것은 고려해야하는 중요한 태깅 전략입니다. 불행히도 모든 회사에 대한 공통 표준은 없습니다. 리소스에 대한 명명 표준을 개발하면 리소스를 체계적으로 유지하는 데 도움이 되며 클라우드 비용 보고서에서 관련 리소스를 함께 그룹화하는 데 사용할 수 있습니다.
각 태그는 각 자산에 대한 고유 ID와 리소스에 추가된 다른 모든 태그를 이해할 수 있는 링크를 제공해야 합니다. 다중 테넌트 다중 클라우드 환경의 일반적인 예는 다음과 같습니다.
[CSP]-[business unit]-[application id]-[environment]-[sequence]
| Value | Description | # characters | Source | Description |
|---|---|---|---|---|
| CSP | cloud service provider: aws, gcp, azr, etc | 3 | Fixed | CSP name |
| Business Unit | grp, uk, de, es, it.. | 2 | Fixed | Highest level of organization mapping |
| Application id | application id (web, wrk..) | 2-10 | Selected | Optional as it could change over time |
| environment | environment: prd, dev, stg | 3 | selected | use acronyms or abbreviations aligned to environment strategy |
| sequence | numerical sequence: 01, 02, 03 etc | 2 | selected | delimited numbers make each resource unique |
Example:
aws-kr-web-prd-01
멀티 클라우드의 어려움
각 클라우드 공급자는 서로 다른 용어와 서로 다른 태그 제한을 사용합니다. 예를 들어 AWS는 “키(Key)/값(Value)” 쌍을 “태그(Tag)“로 참조하고 GCP는 “라벨(Label)“을 사용합니다. 다중 클라우드 서비스를 사용하는 경우 여러 클라우드 서비스에서 리소스에 대한 일관적인 가시성를 제공해 줄 수 있는 좋은 다중 클라우드 관리 도구가 있어야 합니다.
주요 클라우드 서비스 회사에서 사용하는 태그의 주요 차이점은 아래 표에 요약되어 있습니다. 모든 클라우드 서바스에서 사용할 수 있는 공통적인 부분을 멀티 클라우드 전략으로 만들어야 합니다.
| AWS | Google Cloud Platform | Microsoft Azure | |
|---|---|---|---|
| Hierarchy | Linked accounts | Folders and projects | Subscriptions |
| Key/value pairs | Tags | Labels | Tags |
| Number of tags per resource | 50 (some services allow only 10) | 64 | 50 (some services allow only 15) |
| Tag key length | 128 | 63 | 512 |
| Tag value length | 256 | 63 | 256 |
| Format | unicode characters | ||
| (UTF-8 and .:+-@_/-(hyphen) | alphanumeric | ||
| (UTF-8 and - _ can include international character) | |||
| Excluded | cannot contain: <, >, %, & , , ?, / | ||
| Tags automatically allocated to your detailed billing data | NO - manual selection required | Yes - some limit apply | Yes - some limits apply |
태그 표준 문서
클라우드 태깅 규칙은 문서화되어야 하며 회사에서 사용하는 태깅 전략의 정책을 다루어야 합니다. 이 문서는 주로 사용 중인 태그, 태그 책임자 및 각 태그에 포함된 값을 나열해야 합니다.
또한 태깅 정책이 무엇이고 무엇을 하는지 문서화해야 합니다. 이 문서는 중앙화되어 공유되고 책임자에게 승인을 받아야 합니다.
이상적으로 FinOps 팀이 태깅 정책, 해당 문서 및 구현 진행 상황에 대한 개요를 제공하기 위한 중앙 도구를 갖추고 있는 것이 좋습니다. 이 중앙 리포지토리는 팀이 회사의 태깅 전략 및 거버넌스의 완전성을 보장하는 데 도움이 됩니다.
아래 표는 태깅 및 라벨링 표준의 예시입니다.
| Key | Compliance | Description | Attachment | Allowed Values | Relevance | Example |
|---|---|---|---|---|---|---|
| name | mandatory | Account and Resources | Naming convention | Biz, Dev, Sec, Ops | aws-kr-web-prd-01 | |
| application_id | recommended | Application ID | Account or Resources | variable | dev | web_worker_1 |
| application_role | mandatory | Application Role | Account or Resources | variable | dev | worker |
| cluster | recommended | Cluster name | Account or Resources | Naming conventions | dev | web |
| env | mandatory | Environment | Account or Resources | production, staging, development | dev | development |
| tech_owner | recommended | Architect or Technical Lead | Account or Resources | email address | dev | tech@example.com |
| project_owner | recommended | Delivery Lead | Account or Resources | email address | biz | porj@example.com |
| budget_owner | recommended | Person or team responsible for payments | Account or Resources | email address | biz | budget@example.com |
| project | mandatory | Project name | Account or Resources | variable | biz | web server |
| cost_center | mandatory | cost allocation and reporting | Account or Resources | variable | biz | GRMT1093 |
| confidentiality | mandatory | Data Classification | Account or Resources | C1, C2, C3, C4, Secret | sec | c1 |
| tag_version | mandatory | Naming, labeling and tagging policy version | Account or Resources | vX_X | ops | v1_0 |
필수 태그는 모든 계정과 리소스에 적용되어야 하며 권장 태그는 필요한 경우 적용됩니다. 선택적 태그에는 특정 유형의 리소스 또는 사용 사례에만 적용될 수 있는 리소스 관련 키가 포함될 수 있습니다. 준수 수준은 자동화된 보고 분류 및 준수 위반의 심각도를 정의합니다. 경우에 따라 컴퓨팅 또는 스토리지와 같은 공통 리소스에 대한 특정 하위 표준을 정의할 수 있습니다. 여기에는 이러한 리소스 관리에 도움이 되는 보다 자세한 보안 및 운영별 레이블이 포함될 수 있습니다.
결론
태깅 업무는 중앙화된 표준 문서가 필요합니다. 표준 문서에 따라서 태그의 생성, 수정, 주기적인 유지/보수 및 오류 감시를 해야 하여 보다 정확한 태그를 클라우드 자원에 지정하도록 하는 것이 중요합니다. 정확한 태그를 유지해야 정확한 클라우드 비용 지출 데이터에 대한 가시성을 확보하고 올바른 의사결정이 가능합니다.
앞으로도 유용한 클라우드/AWS 정보와 함께 찾아오겠습니다✨