이 문서는 2024년 4월 19일, Korea FinOps Meetup 2회 참석 내용입니다.
회고
서론
FinOps 페르소나 이해 – 김수현, CJ 올리브네트웍스 클라우드 엔지니어
FinOps 태깅 전략 – 박진수, Mercari, Inc. FinOps 엔지니어
사전 지식
핀옵스 파운데이션은 리눅스 파운데이션의 하위 프로젝트 중 하나입니다.
따라서 동일한 행동 강령을 따라서 진행을 하고 있습니다.
목적
비용보다는 문화에 중심을 두고 있다.
FinOps 페르소나의 이해
발표자 : 김수현님, CJ 올리브네트웍스 클라우드 엔지니어
발표 키워드 : 팀은 상호 협력해야 한다.
CJ 올리브네트웍스의 사고 경험
사내 운영, 교육 담당자님들이 비용에 대한 큰 가이드나 고민이 없었다.
기본적인 인스턴스의 가이드를 주기는 하지만 수강생들이 이런 가이드를 따르지 않는 경우가 있다. 이런 것들은 기본적으로 협업을 하지 않았기 때문에 발생한 문제라고 생각합니다.
FinOps Personas
Persona Details - Core Personas
FinOps Persona를 통해서, 조직은 클라우드를 효과적으로 사용할 수 있습니다.
각 Persona는 조직과 FinOps 실행애서 일정한 역할을 수행하며 개별적인
대부분의 조직에는 항상 핀옵스 실행에 관여하는 핵심 페르소나가 있습니다. 이러한 핵심 페르소나는 클라우드를 효과적으로 사용하기 위한 모든 조직 분야를 제공합니다. 각 페르소나는 조직과 FinOps 실행에서 역할을 수행하며, 각 페르소나마다 추구하는 관점, 과제, 지표 및 결과가 다른 페르소나와 약간 다를 수 있습니다.
FinOps Practisioner
중앙 집중화된 비용 관리 실현 가능
비용 가시성을 개선해야 함CEO
위험 관리
엔지니어링을 비즈니스와 연결을 가능
클라우드 지출을 예측하고 투자에 대한 효율적인 지침을 내릴 수 있음CTO/CIO
클라우드 지출을 예측하고 효과적으로 클라우드를 투자 가능
적극적으로 엔지니어 팀에 지원을 할 수 있음CFO (클라우드 비용 관리 및 비용 효율성 목적)
클라우드 비용에 대한 책임 증가
예측 모델이나 예상에 대한 의존도가 증가할 수 있음
클라우드 비용에 대한 가시성 향상
단위 경제성을 강화 가능
비용 효율적으로 서비스를 제공 가능지출을 정확하게 식별가능ㅅ
쇼백, 차지백
비용에 대한 책임감을 강화 가능
좋은 방향으로 클라우드를 투자할 수 있도록 유도 가능FinOps Procurement (조달 : CSP, MSP 업체 등과의 관계 관리)
Persona Details - Allied Persona
FinOps ITSM
경제적으로도 지속가능한 IT 서비스를 제공
FinOps ITAM
FinOps Sustainability
기후 환경적으로 지속가능한…
FinOps Security
보안, 백업과 관련된 비용은 매우 비싸지만 반드시 필요하다.
이 부분을 얼마나 비용 효율적으로 운영할 수 있을 것인가.FinOps ITFM / TBM
Best Practices
Cycle | Inform → Optimize → Operate
Phase | Crawl → Walk → Run
QnA
AWS or ESG?
현재는 ESG 공시가 의무가 아닌 선택이지만, 의무가 되려는 움직임이 있다.
FinOps를 알기 전/후 적으로 어떤 부분들이 달라졌는지 궁금합니다.
FinOps를 알기 전에는 비용을 크게 신경을 쓰지 않거나 단순하게 비용을 줄이는 정도로 생각했다. 하지만 단순하게 비용을 줄였을 때, 장애가 발생한 적이 있었다.
FinOps를 안 후에는 가용성 등을 고려하여 의사 결정을 하려고 하고 있다. 전체 비용의 총합을 고려하는 것 같다.
FinOps Persona를 실제로 팀원분들에게 전파를 하고 팀이 바뀌는 과정 중에 있는 지가 궁금합니다.
FinOps Persona, Tool 등에 대한 전파를 했으나 FinOps Persona가 제대로 정착되지 않았다.
FinOps 태깅 전략
발표자 : 박진수, Mercari, Inc. FinOps 엔지니어
발표 키워드
태그 없이 FinOps할 수 있나요?
태그는 필수적이라고 생각을 합니다.
리소스에 정보 추가
Inform
Chargeback : 비용 할당
Showback ; 비용 분석
Optimize
자동화 전략 스케쥴링
Operate
정책 실행과 규정 준수
태그 배포 시, 발생하는 문제점
기존에 존재하는 일관성 없는 태그
이미 수많은 리소스들과 연동이 되어 있기 때문에 쉽게 바꾸기 힘듦
낮은 우선순위
기능 개발에 비해 뒤로 밀림
CTO 등 상위 레벨로부터의 OKR 조정 등이 필요잦은 변경과 잦은 요구에 대한 저항
일관성 있는 정책 및 로드맵 공유를 통해 완화
FinOps 정책을 자주 변경할수록 저항이 강해짐
끝까지 협력을 얻기 위해서 분기 단위로 호흡을 관리자동화 및 툴의 부재
리소스 당 수십 개가 넘어가면 피로도가 심해짐
IaC, CI/CD 등을 통해 최소한의 노력으로 많은 태그를 관리할 수 있도록 고안엔지니어의 지식 부족
내가 관리하고 있는 리소스에 대해서 어떤 값이 맞는지 몰라서 대충 적어내는 경우
따라서 이런 부분들에 대한 가이드가 필요함
낮은 우선순위 - 대책 (0)
현재 비용 할당에 대한 분석
손해를 보고 있는 팀 및 조직(BU) 찾기
해당 BU를 중심으로 태그 전개 나가기
그 후 Showback, Chargeback 차이를 기반으로 조정
낮은 우선순위 - 대책 (0) - 개선 사례 1
Bigquery 비용을 전부 개발 조직에서 부담. 타 부서의 용도로 인한 사용을 포함, CTO 입장에서 자신이 운용할 수 있는 자원이 줄어드는 것이기에 CTO 관리 하 조직에서는 Tagging에 대해 수우러하게 진행할 수 있음
낮은 우선순위 - 대책 (0) - 개선 사례 2
프로덕트 Growth 팀 주도로 실행된 A/B 테스트 역시 태그 부족으로 인해 추가 비용이 개발팀으로 할당
낮은 우선순위 - 대책 (1)
전제 : 조직구조(BU, Division, Team 등) 에 대한 태그는 이미 추가되었다고 가정
All Hands 과정에서 비용 지표를 공개하여 경쟁을 유도
단, 사전에 해당 팀들에 미리 전달하여 소프트 랜딩
낮은 우선순위 - 대책 (2)
No tag… No resource?
극단적인 방식
자동화 및 툴의 부재 - 대책 (0)
Tag Template 등을 만들어서 사용
자동화 및 툴의 부채 - 대책 (1)
CI/CD 파이프라인에서 작업
Terraform으로 1차 Tag 삽입
CI/CD에서 Tag 추가 삽입
자동화 및 툴의 부재 - 대책 (2)
테라폼 파일에는 최소한의 정보를 갖도록 구성
추가적인 정보는 폴더 구조 및 metadata.csv로 부터 반영
태그에 대한 관심
재무 : 태그는 단지 수단일 뿐
개발자 : 태그에 대한 관심 낮음, 잘 협력해주지만 자발적이진 않음
운영 : 태그에 대한 관심 높음, 본인들이 필요한 영역에 대해서
보안 : 태그에 대한 관심 높음, 본인들이 필요한 영역에 대해서
기타 : 태그에 대한 관심 높음, 본인들이 필요한 영역에 대해서…
태그 관리 협의체
최소한의 태그 수 유지
정기적인 모임을 통해 추가할 태그에 대해 논의
정기적인 기간을 지켜서 개발자들에게 요청하기
추가된 태그를 어떻게 관리할 것인지
코드가 아닌 다른 저장소도 고려해보기
입력 용이성
접근 편의성
공유된 리소스에 대해서
Shared: True 태그를 사용하며 동시에 추가로 코스트 할당 로직을 개발해야 한다…
Data Transfer 비용 등도 어느 정도 샘플링을 떠서 그 서비스를 사용하고 있는 이해 관계자들을 모아서 비용을 청구를 해야 한다고 생각 → 이것이 추가로 코스트 할당 로직
Tip
태그를 소급 적용되지 않는다… → AWS Backfill이 있음…
QnA
IaC나 CLI를 쓰지 않고 태깅 자동화 하는 방법
→ AWS Tag Editor 등이 있음
공유 리소스(Data Transfer, API Call Logs) 이후 샘플링하면 어느 정도의 지표가 나오는지?
→ 태그 추가 만으로 알 수 없고 그 이후에 찾아야함
처음부터 태깅을 시작한다면 어떤 것부터 하고 싶은지
→ 전형적으로 이해 관계자들을 모아 놓고 회의를 할 것 같음
태깅을 강제하는 경우나 돌아다니는 경우가 있나?
→ 현실적으로 불가능하다.
태그 품질, 오염된 태그라는 단어가 나와있었다.
오염되었을 경우에는 새 수레에 담아서 하는 경우(대규모 변경) / 청사진을 그려가면서 하는지(점진적으로 수정)→ 뒤짚으면 서비스에 영향이 있기 떄문에, 천천히 갈아 엎는다.
좋은 태그, 이 태그는 아름답다 하는 룰셋이 있나?
Chargeback을 할 때, 예산이 있고 예산 범위 내에 강제가 되나요? 아니면 권고 수준인가요?
→ 권고 수준이며, 최대한 예산을 지키려고 노력을 한다.
예산은 어떻게 산정하는가?
→ 회계연도 1년 당 한 번 FinOps 예산을 산정
→ 각 팀 별로 예산은 체계적으로 추정하는 경우도 있지만 두루뭉술하게 잡기도 함
→ 각 팀별로 잡은 예산을 FinOps 엔지니어가 취합
예산 범위를 벗어나는 허용치(마진)은 어떻게 정하는가?
→ 팀바팀.
예산이 너무 많이 넘어가면 부검을 하는가?
부검을 한다면 FinOps 단위 경제학 측면에서 작업을 하는가?→ 이게 큰 의미가 있는 작업인지 모르겠다.
→ 서비스/팀의 규모가 커질수록 단위 경제학이 올라가고 줄어드는 경우가 있어서 유의미한 지표인지 알 수 없다.
FinOps 도입 전/후에 패널티나 리워드가 있었는가?
→ 없다.
→ 억울하게 더 내던 팀은 덜 내는게 리워드이고.. 그 반대의 팀은 패널티…
조직도가 변경되면 어떻게하는가?
→ 처음에는 조직도를 그대로 태그로 옮긴 경우가 있었고 이는 변경에 취약했다.
→ 별도의 mapper 레지스트리 써도 되지 않을까..?키(Key)
값(Value)
…
1
14경영지원실
…
2
15경영지원실
…
→ 변경된 것을 찾아가는 것은 현실적으로 어려운 것 같다.
Terraform 코드 수정 후 CI/CD에서 코드 추가 삽입 시. diff는 어떻게 처리?
→ Wrapper 툴인 Titan을 사용하고 있음. 따라서 코드가 삭제되지 않음
