유휴 서버를 찾다가 Hybrid Cloud까지 갔습니다: 비용 가시화에서 Unit Economics를 향해가는 카카오의 FinOps 여정
백정태 - 카카오 / 정원천 - 카카오
유휴 서버, 줄이면 되는 것 아닌가요?
- 매년 서버 구매 예산 때마다 “정말 이만큼 필요한가?” - 재무는 구매 규모가 부담, 서비스 조직은 여유를 원함
- 그런데 이미 가진 서버 중 CPU / 메모리 / 네트워크 사용률이 낮은 유휴 서버도 적지 않음 -> 회수해서 재배치하면 되지 않나?
사용률이 낮다 ->
- 서비스가 끝났는데 정리되지 않은 자원
- 장애가 났을때 대신 일해야 하는 자원
- 배치, 이벤트를 기다리는 자원
- 사용률이 낮다는 이유만으로 바로 회수할 수 없음
- “남아 보인다”와 “회수할 수 있다”는 다른 이야기
- 파드 리소스 리퀘스트처럼 여유를 두는 건 합리적이지만, 필요한 여유와 과도하게 확보한 자원을 구분할 데이터가 없었음
- 서버를 하나하나 들여다볼 수는 없으니 판단 기준이 필요
그래서 우리는 무엇을 근거로 가장 효율적인 판단을 할 수 있는가?
- 그 판단의 기준을 찾아온 여정
- 실제로 카카오는 무엇을 바꿔왔는가
이 서버, 누가 왜 쓰고 있나요?
- 서버 신청서로 알 수 있던 것: 어떤 조직이 얼마나 샀는지, 작년 대비 증가량, 공통 플랫폼이 산 서버 양
- 알 수 없던 것: 조직이 아니라 어떤 서비스가 얼마나 쓰는지, 공통 플랫폼을 실제로 쓰는 서비스가 어딘지
- 플랫폼마다 사용자 구분 방식이 다름 (조직 / 계정 / 플랫폼 자체 기준)
- 플랫폼 비용 증가를 서비스 변화와 연결해서 따라가기 어려움
- 자원 제공 방식의 변화: SE가 함께 규모 산정 -> 사용자가 직접 신청하는 셀프 서비스
- 속도는 유지하되, 각 팀이 확보한 자원이 적정한지 전사가 같은 기준으로 볼 수 있어야 함
- 관점 전환: 어느 조직이 샀는가 -> 어떤 서비스가 쓰는가
서비스 카탈로그
- 서버, DB, 플랫폼을 서비스라는 기준으로 연결
- 실무적으로 가장 어려웠던 작업 - 플랫폼별 사용자 관리 방식이 다르고, 이미 운영 중인 시스템에 새 기준을 연결해야 했음
- 결과: 서비스별 서버 / DB / 공통 플랫폼 사용량과 그 비용 추적 가능 (수치는 비공개)
비용이 늘었는데 그건 나쁜건가요?
- 비용만으로는 잘 쓰고 있는지 판단 불가 - 같은 비용 곡선이라도 처리량을 같이 보면 효율 차이가 보임
- 지연시간, 에러율을 처리량과 함께 보듯 비용도 함께 보기
- 정상 처리 요청 1,000건당 비용
- 메시지 100만 건 전달 비용
- 단위당 비용 = Unit Economics, 카카오가 향하는 방향
- 같은 결과를 내는 데 무엇이 더 효율적인지 판별 가능
장애, 이벤트에 대비한 여유를 어떻게 확보할 것인가 고민함
- 여유는 필요하지만, 지금처럼 유휴 자원을 운영하는 방식이 최선인지 재검토
피크 때문에 1년 내내 들고 있어야 하나요?
- 피크 기준으로 확보한 자원은 평시엔 유휴로 보이지만 피크엔 서비스를 지키는 힘
- 여유를 없애는 건 위험 -> 여유를 제공하는 방식을 바꾸기로 함
- 서비스간 자원 공유 (공유 풀)
- 서비스별 과다 할당을 조정하고, 각자 확보한 여유를 공용 풀로 모음
- 서비스마다 피크 시간이 다를수록 효과가 큼
- 한계: 새해 첫 순간처럼 메시지, 선물하기 등 여러 서비스 피크가 동시에 오면 공용 풀만으로 부족
- 하이브리드 클라우드 구성
- 계속 보유할 자원은 내부 자원으로, 특정 기간만 쓸 자원은 빌렸다 반납하는 퍼블릭 클라우드로
- 질문의 변화: “남는 서버가 있는데 왜 또 사나?” -> “내부 자원을 적정하게 쓰고 공유 여력을 늘린 뒤에도 부족한 순간만 외부에서 잠깐 확보할 수 있을까?”
그래서 카카오는 실제로 무엇을 했나요?
DKOS - 인하우스 OpenStack 위의 Kubernetes 플랫폼
- 서비스별 Kubernetes 클러스터를 만들어 운영, 서비스 카탈로그와 연동
온프로미즈 환경
- onprem 환경에서의 비용 절감 - Karpenter 기반 노드 오토스케일러
- 기존 DKOS는 파드 단위 HPA만 제공 -> 실질적 자원 효율화를 위해 노드 오토스케일링 필요
- 워크로드 리퀘스트 사이즈 자동 조정
- 사용자들은 리퀘스트를 실사용량보다 높게 잡는 경향
- 파드 사용량을 모니터링하다가 리퀘스트 대비 실사용량이 작으면 리퀘스트를 실사용량 근처로 자동 축소
- 리퀘스트 축소 -> 빈패킹으로 일부 노드에 파드 집약 -> 빈 노드는 Karpenter가 삭제 -> 공용 풀로 반환
- 같은 워크로드를 더 적은 노드로 운영, 공용 풀 가용 자원 증가 -> 이벤트 대응 여력 확보
- 20~30%의 컴퓨팅 자원 절감 기대
- 현재 점진 적용 중, 대상 서비스가 많아 전체 적용엔 시간이 걸릴 것
하이브리드
- 온프레미스 상시 서버는 최소화, 급하게 필요한 버스트 자원은 퍼블릭 클라우드로
- 검토한 두 가지 방식
- 퍼블릭 클라우드의 관리형 Kubernetes 사용 -> 사용자가 두 곳에 배포해야 하고, 카카오 사내 정책에 맞게 수정 필요
- 기존 DKOS 클러스터에 노드 추가 -> 사용자는 기존 방식 그대로, 반납도 간편
- 기존 DKOS 노드에 클라우드 노드를 추가하도록 함
- 외부 트래픽은 카카오 DC로 받고, 퍼블릭 클라우드와는 DX(전용선)로 연결
검증: 선물하기 대기열
- 버스트 트래픽이 잦은 선물하기 대기열 서비스를 직접 올려 검증
- GSLB로 유입 -> 선물하기 게이트에서 레이트 리밋 도달 시 대기열 오픈 -> 관제 컴포넌트가 지표를 보고 대기열 서버 파드 증설
- 버스트 대응 전략 4단계 (시간 순)
- 도메인 경험 기반 예측 - 명절, 발렌타인 / 화이트 / 빼빼로데이, 수능 전날, 크리스마스 등 알려진 이벤트 전에 미리 대기열 생성
- AI로 트래픽 패턴 감지 -> 신호 발생 -> 사람이 증설 판단
- 실시간 임계치 감시 - 50% 넘으면 경고 + 대기열 생성
- 신호를 놓치고 피크가 오면 즉시 대기열 생성
- 상시 보유하면 온프렘이 훨씬 싸지만, 특정 기간만 쓰면 클라우드가 더 싼 구간이 존재 -> 그 경계를 넘지 않게 관리하는 것이 목표
- 현재 일부를 수동 구성해 동작 확인, 11월 말까지 자동화 완료 목표
정리
- 필요한 여유는 지키면서 단위당 비용을 낮춘 이야기
- 효율을 알려면 측정할 수 있어야 하고, 단위당 서비스 비용에 답할 수 있어야 함 - 출발점은 측정
- 지연시간과 에러율을 볼 때 비용이라는 축도 함께 관리해보자