클라우드 관리 KPI와 자동화
비IT전문가가 클라우드 직접 비용 관리하기 필살기는 바로 자동화!!!
https://brunch.co.kr/magazine/cloud-finops
클라우드 비용 아직도 엑셀로 하시나요(https://brunch.co.kr/@cebi750/11)라는 글과 재무팀에서 직접 클라우드 비용 뽀개기(https://brunch.co.kr/@cebi750/12)라는 글을 꽤 많은 분들이 읽어 주셨습니다. 이제 IT비전공자의 클라우드 관리하기 시리즈의 마지막으로 KPI와 자동화에 대한 내용을 적어보려고 합니다.
저도 전산을 전공하기는 했지만, 코드 한 줄 안 만든지 거의 20년이니까 CSP에서 제공해주는 화면에서만 클라우드를 관리할 수 있다는 점에서 IT비전공자들과 똑같은 상황입니다. 다행히 AWS나 MS나 Google이나 우리의 기대나 상상 이상으로 클라우드를 관리할 수 있는 콘솔이나 포탈의 기능을 잘 제공해 주기 때문에 시간만 충분히 투자하면 누구나 클라우드의 자원과 비용을 가시화하고 효율화 할 수 있습니다.
하지만 몇 가지 해결하기 어려운 문제가 있습니다.
1. 우리에게는 클라우드 관리 콘솔이나 포탈을 공부할 여력과 시간이 없습니다.
정말 내가 게을러서가 아니고 정말 맘 먹고 해 보려고 해도 러닝 커브가 상당히 높습니다. 기본 제공하는 화면 외에 내가 원하는 기준으로 좀 바꿔 보려면 SQL 정도는 구사해 주어야 합니다. 치사하게 디테일하게 필터를 적용하거나 피보팅을 해 보고 싶은데 그냥은 안해줍니다.
그리고 콘솔에서 제공하는 수많은 여러가지 기능들 중에서 어떤 기능을 써야할지 파악하는 것도 쉽지 않습니다. 만약 RDS에 대하여 무언가 하기를 원하는데, 어떤 건 RDS 서비스 자체가 가지고 있는 관리 기능을 이용해야 하고, 어떤 건 Cloudwatch를 통해서 모니터링 해야 한다고 하고, 어떤 건 AWS Config를 통해서 관리 기준을 적용해야 한다는 식입니다. 아 복잡합니다.
2. 두번째는 어떤 지표를 가지고 관리할 것인지 참 어렵습니다.
비용의 상승율을 부서별로 제한하면 될까요? 어떤 서비스에서 고객이 급증했거나 대대적인 마케팅 이벤트를 진행하면 비용이 같이 올라갈텐데요? 그럴때마다 예산 품의받고 심사할까요? 그리고, 잘 아시다시피 클라우드 비용은 하나의 상품에 하위 구성 요소들이 제각각 비용과 할인이 적용되는 다단계로 복잡한 구성인데, 단지 부서별 총합계만 관리하면 제대로 관리가 되는 걸까요?
여차저차해서 지표를 잡았다 하더라도 어느 수준으로 적당한 것인지 판단할 수 있는 기준이 없다는 점도 참 어려운 문제입니다. 도대체 남들은 어떻게 하고 있는건지 궁금하지 않으신가요?
3. 세번째는 지표에 대한 집계와 후속 조치의 자동화입니다.
매번 각 서비스 개발팀에 요청해서 데이터를 받고, 엑셀 작업을 하고, 계획대비 실적을 뽑아야 한다면 지속적인 관리는 바로 불가능입니다. 이럴 바에야 시작을 아예 안하는게 낫습니다. 어차피 처음 한번은 더 고생 많이 할텐데... 고생만 하고.. 모든 관리의 핵심은 지속성입니다. 한번 한다고 되는게 아니죠. 자동화에 대한 방법을 분명히 하고 진행하셔야 합니다. 개발팀을 참여 시켜서 자동화를 하시거나 OpsNow와 같은 자동화된 클라우드 관리 플랫폼을 사용하시는 것을 고려해 보시기 바랍니다.
제가 운영하는 Cloud Management Platform인 OpsNow를 사용하시는 기업이 현재 1,000개가 넘습니다. 어떤 회사 안에는 인프라 비용 관리를 전당하는 담당자가 있는 회사도 있습니다. 계속 신경을 쓰고, 지속적으로 관리를 잘해도 저희가 같이 참여하여 비용절감 리포트를 뽑아보면, 최소 10% 내외에서 많게는 50%까지 절감 요소들이 튀어 나옵니다.
왠만한 규모의 스타트업들도 한달에 $10,000 이상의 클라우드 비용이 발생합니다. 저희에게 문의하시면 FinOps 전문가들이 출동해서 매달 줄일 수 있는 10% 이상의 비용 절감 요소를 알려 드리고, 지속적으로 관리할 수 있는 체계도 잡아 드리고, 필요한 경우 교육과 클라우드 전문가들도 연결시켜드립니다.
클라우드를 사용하시는 기업에게 정말 CMP는 Must-have 입니다. ^^;;
매달 초 날라오는 비용지출 품의서에 의해서 그리고, CSP에서 발행하는 인보이스에 그대로 맞추어서 열심히 지불을 하고 계신다면, 꼭 이 글을 개발팀 담당자, 재무팀 담당자, 회계팀 담당자 등에게 공유해 주시고 대책을 마련하시기를 바랍니다.
오늘 공유드리려고 준비한 내용은 저희가 FinOps KPI 라고 부르는 항목들입니다. 아주 Common한 항목들입니다. 좀더 델리케이트한 KPI와 목적이나 부서의 역할에 따라서 KPI 조합이나 산출식을 정교하게 구성해야 할 필요도 있지만, 시작하는 단계에서는 아래 항목들 중 적절한 KPI를 선택하시고, 목표치를 설정해서 주단위, 월단위로 주기적인 모니터링을 하시는 것으로 충분하다고 생각합니다.
RI/SP/EDP Coverage : 대상이 되는 전체 인스턴스 총비용 중 해당 계약으로 적용되는 금액. 이 수치는 좀 애매할 수 있습니다. 이 커버리지가 높다고 비용 효율이 좋다고 할 수는 없으니까요. 그리고 커버리지가 낮아지는 이유 중에는 비즈니스 성장이 예상보다 커서 인프라가 늘어나기 때문인 경우가 많기 때문에 지표의 의미가 혼돈될 수 있습니다. 특히, RI의 경우 다른 사양의 인스턴스로 전환이 안되기 때문에 주의해서 계약을 체결해야 한다는 점 기억하시기 바랍니다.
RI/SP/EDP Utilization : 체결된 계약 규모 중 한달 (혹은 특정기간) 소진된 규모. 이 지표는 반드시 관리를 해야 합니다. Commit 된 금액이기 때문에 안 쓰면 그냥 버리는 지출이 됩니다. 100% 소진이 될 수 있게 해야지요. 생각하시는 것 보다 소진 안되는 금액이꽤 많습니다.
Private Price Savings : CDN, Data Transfer 등 특정 할인이 적용이 가능한 상품의 On-demand 대비 절감금액. 이 지표는 조금 어렵기는 한데, 가급적 Private Pricing 할인이 적용된 상품을 사용하도록 관리하기 위한 지표입니다. 예를 들어 AWS Cloudfront를 좋은 조건으로 사용하고 계신다면, S3의 Data Transfer Out을 줄이고 , CF를 많이 사용하도록 개발하는 것이 개이득입니다.
Spot Instance Coverage : Spot Instance 는 On-demand 대비 90%까지 저렴하게 제공됩니다. RI, SP 의 경우 최대 72% 저렴한 것에 비하면 18%나 더 줄일 수 있습니다. 저희의 경우 테스트, 개발계, 일시적으로 리소스를 사용하는 배치의 경우 기본적으로 Spot Instance를 사용합니다. Spot Instance의 약점은 인스턴스가 강제로 회수될 수 있다는 점인데, 문제될 만한 곳에는 사용하지 않으면 아주 좋은 제도입니다.
미사용 Instance, Storage, Snapshot, IP 의 총금액 혹은 해당 상품의 전체 대비 비율 : 제 개인적으로 가장 맘에 안드는 클라우드의 단점입니다. 사실 클라우드 서비스의 잘못은 아니지요. ^^;; VM Instance(컴퓨터)가 하나 생기고, IP(네트워크), EBS(외장 하드디스크) 등을 붙여서 사용을 했고, 사용하는 중간중간 Snapshot(백업 이미지)를 만들었는데, 해당 컴퓨터를삭제(폐기)하고 나서도 연결해서 사용되던 네트워크, 외장 하드, 백업 이미지 등만 남아 있는 상태인 것 입니다. 당연히 그만큼 돈이 나가고요. 이 Unused Resource에의해 발생하는 비용이 정말 많습니다. 특히, 성장하는 기업의 경우에 더 어마어마하게 숨어 있습니다. 계속 새로운 서비스가 만들어지고 변경되고 하니까요.
Aged Snapshots : unused snapshot과 다르게, 정상적으로 생성되 보관이 필요하지만 매우 오래된 스냅샷의 경우에 해당합니다. 일반적으로 7일, 30일 혹은 90일 기준으로 자동으로 삭제하는 것이 좋겠지요. 특정한 사유가 있다면 Glacier 와 같이 장기보관용으로 옮기는 방법도 있습니다.
% of S3, EBS storage on the wrong tier : Aged Snapshot 에서 언급한 바와 같이 storage에는 여러가지 타입이 있습니다. 저장하고 꺼내는데 3~5시간씩 걸리는 Deep Glacier 같은 저장 공간도 있고, S3 Intelligent-Tiering 과 같이 AWS에서 입출력 빈도와 사이즈를 감안하여 저장공간을 조정하는 옵션도 있습니다. 일반적으로 대부분의 경우 가장 그중에서 가장 비싼 S3 Standard 를 쓰고 있습니다. 회사마다 기준은 다르게 가져갈 수 도 있지만, 저장공간의 사이즈보다 저장 위치나 데이터 입출력 빈도에 대한 비용 관리는 매우 중요한 지표입니다.
% of idle instance, days of idle 도 중요한 관리 지표입니다. idle의 정의는 CPU와 메모리의 사용율, 네트워크의 데이터 입출력, 저장공간에 대한 데이터 읽기쓰기(IOPS) 에 의하여 결정이 됩니다. idle 상태에 따라서 자동으로 정지되는 스케쥴을 건다던가, 인스턴스 사이즈를 낮추는 등의 조치를 취해야 합니다.
% of untagged resources, % of wrong tagging resource : 관리의 시작이 되는 지표입니다. 제 이전 글 재무팀에서 직접 클라우드 비용 뽀개기(https://brunch.co.kr/@cebi750/12)에서 설명드린 바와 같이 가장 먼저 시작해야 하는 것은 리소스에 태그 달기 입니다. 구분할 태그를 안 붙여 놓거나 잘못 붙여 놓으면 관리는 시작부터 불가능합니다
sum of spending of untagged resources : 이 지표도 관리하기 좋은 지표입니다. untagged, wrong tagging 리소스를 포함하고 있기 때문에 전체 비용 중에서 관리가 안되는 비용의 규모라고 볼 수 있습니다.
data updates 주기 : 관리하는 지표로 보기 어려울 수 있지만, 중요한 요소입니다. 한달에 한번 CSP에서 발행한 인보이스를 가지고 비용을 관리할 것인지, 매일매일 발생되는 비용을 가지고 관리를 할 것인지, near-real time 으로 관리를 할 것인지를 정해야 합니다. 대부분의 CSP에서는 빌링데이터는 하루 단위 이하의 간격으로 업데이트를 하고, 리소스의 Usage, Performance Metric은 분 단위 이하의 간격으로 업데이트를 합니다. OpsNow에서는 빌링은 최소 3시간에서 최대 하루 단위로 CSP의 업데이트 정보를 가져오고 있으며, 리소스의 Usage, Perforamance 정보는 5분~60분 단위로 업데이트를 하고 있습니다. 업데이트 주기가 중요한 이유는 관리의 타이밍 때문입니다. 옵션 설정 하나 변경하고 3일 동안 4백만원이 초과발생했습니다. 한달을 모르고 지나갔으면 4천만원입니다. AWS 비용 폭탄 사건(https://brunch.co.kr/@cebi750/10) 입니다.
Unit cost of spending and business performance : 사실 상 가장 중요한 지표라고 할 수 있습니다. 근래의 비즈니스 환경에서는 인건비보다 IT인프라비용이 더 크게 들어가는 테크기업들이 허다합니다. CAC(Customer Acqusition Cost)에서 클라우드 비용이 커지고 있습니다. 중요한 지표인 만큼 이 지표에 대해서는 좋은 글들이 많기 때문에 저는 생략하도록 하겠습니다.
이와 같이 약 20여개에 가까운 지표들을 소개해 드렸습니다.
일부는 CSP의 콘솔이나 포탈에서 뽑을 수 있는 것도 있고, 일부는 별도의 작업이 필요할 수도 있습니다. CSP에서는 대부분의 데이터가 계정별로 나오기 때문에 이러한 지표들을 부서별로 프로젝트별로 관리하기 위해서는 OpsNow의 서비스그룹, 조직트리 같은 기능들을 이용하시면 가능하다고 이전 글들에서 설명드렸으니 참조하시기 바랍니다. AWS의 RI 나 SP 처럼 Payer 계정 안에 포함된 모든 계정들 간에 공유되는 경우들이 있어서 수치의 왜곡이 발생할 수도 있고, 계약 시점에 Upfront fee(선납금)이 발생하거나 한달치 RI 비용이 매월 1일 날짜로 발생되어서 왜곡이 발생될 수 있습니다. VPC 같은 비용은 특정 서비스로 분배하기 어려운 공통 비용의 성격을 가질 수도 있습니다.
옵스나우와 같은 CMP에서는 이러한 내용에 대한 편의성을 제공해 드리고, 자동으로 데이터를 원하는 기준으로 집계해 드리고, 리포트를 만들어 드리는 역할을 합니다.
위에 언급된 지표들이 정책으로 정의 되어 있고, 정해진 스케쥴에 의하여 자동의 검사가 진행이 됩니다. 그 결과에 따라서 액션이 실행이 됩니다. 액션은 인스턴스를 정지하거나, 삭제하는 등의 리소스에 대한 액션이 자동으로 이루어 질 수도 있고, 이메일이나 리포트로 담당자에게 노티피케이션이 가게 할 수도 있습니다. 담당자가 구체적인 내용을 확인할 수 있게 문제가 되는 리소스와 구체적인 로그를 전달해 주도록 되어 있습니다. 예를 들어 RI 만료가 30일 이내라던가, RI Utilization이 떨어진다거나, Unused Resource가 발생하면 조치를 자동으로 삭제한다던가 RI에 대해 조치를 취할 담당자에게 통보가 되는 것 입니다.
비용이나 리소스 관리 지표를 위한 정책도 있고, 보안을 위한 지표도 있습니다. 예를 들어 S3에 대한 퍼블릭 접근이 허용되어 있거나, 사용자가 가진 Access Key가 90일 넘게 사용이 되고 있다던가, 인스턴스에 대한 보안그룹이 규정에 맞지 않게 설정되어 있는지 등은 계속 감시해야 하는 기본적인 보안 정책입니다.
제가 OpsNow을 서비스하기 때문에 종종 OpsNow의 기능을 언급하게 되는데, 중요한 것은 관리를 하는가 하지 않는가 입니다. OpsNow 사용하시던, 다른 CMP를 사용하시던, CSP의 Console을 사용하시던, 어떤 방법이 되었던지 신경을 쓰고 관리를 시작하면, 비용의 10% 이상을 분명히 줄일 수 있다는 점을 꼭 기억해 주시기 바랍니다.
"Cloud 관리를 위한 FinOps" - 전체 내용 보기 (https://brunch.co.kr/@cebi750/17)
