클라우드 비용 최적화 로드맵 #1 - 연재를 시작하며

여는 말

안녕하세요. SK텔레콤 최준승입니다. 오늘부터 ‘클라우드 비용 최적화’를 주제로 연재물을 새로 시작해 보려고 합니다. 발행 주기는 월간이고요. 전체적인 연재물 마감은 24년 말로 계획하고 있습니다. 이번 3월부터 시작이니 대략 9~10회차 정도로 완결될 예정입니다. 참고로 여기서 말하는 클라우드는 AWS같은 Public Cloud를 뜻합니다.

사실 이 시리즈의 처음 제목은 '재미있는 비용 최적화 이야기'였는데요. 제가 '재미있다'고 표현했던 이유는 무엇일까요? 기억을 되살려 보면 Public Cloud가 대중화된지는 대략 10년 정도의 세월이 경과한 것 같은데요. 최근 '비용 최적화'라는 담론은 이 클라우드 사용자의 공통적인 숙제가 된 느낌입니다. 숙제를 풀어내는 것은 괴로운 일이지만 남의 정답지를 보는 건 재미있는 일이 아닐까요? 더구나 이 정답을 찾아가는 과정은 단답식이 아닌 생각보다 기술적이고 복합적인 영역입니다. 그래서 더 흥미롭고, 연재물로 전개할 수 있는 이야깃거리가 풍부합니다.

연재를 시작하기에 앞서 시리즈의 방향성에 대해서 먼저 말씀드리겠습니다. 일단 전체적인 이야기 구조는 아래 순서대로 진행할 예정이고요. 각 회차에서 다룰 세부 주제도 어느 정도 완성되어 있는 상황입니다.

독자 계층의 다양성을 감안하여 다루는 내용의 기술 레벨도 복합적으로 구성할 생각입니다. 전반적인 담론은 가급적 추상적으로 전개하되, 보다 기술적인 영역은 구체적인 아키텍처나 어려운 기술요소 등을 포함할 수 있습니다. 직관성을 높이기 위해 일부 삽화나 인포그래픽도 선택적으로 써보려고 합니다. 참고로 실제 최적화 방법론은 모두 AWS 기준으로 설명할 예정인데요. 이건 AWS가 사용자층이 제일 많은 Public Cloud의 표준이기도 하고, 예시로 설명하기에도 가장 적합하기 때문입니다. 다만 여기서 다루는 방법론들은 일종의 범용성이 있기 때문에, Azure나 GCP 같은 타 CSP 환경에도 공통적으로(때로는 변칙적으로) 적용이 가능합니다.

연재물 첫 글이다 보니 서론이 너무 길었네요. 이제 본격적으로 이야기를 시작해 보겠습니다. 비용 최적화 관련 여러분들의 상식 수준을 알아보기 위해 간단한 질문지를 준비했는데요. 이 중 몇 개에 해당하는지 미리 한번 체크해 보시기 바랍니다.

모든 질문을 확인하셨다면, 몇 개를 체크하셨는지 확인하시고 아래 그림을 보세요.

여러분의 수준은 크게 중요하지 않습니다. 클라우드 비용이라는 주제에 교집합이 있다면 누구나 환영이고요. 가볍게 한번 쭉 읽어보시고, 여러분의 수준에 맞는 정보를 선택적으로 취하시면 되겠습니다.

클라우드 비용을 최적화해야 하는 이유는?

자, 가장 근본적인 질문으로 시작해 보겠습니다. 클라우드 비용을 최적화해야 하는 이유가 무엇일까요? 클라우드를 쓰는 이유는 각 상품 블록을 조합해서 뭔가 유용한 서비스를 제공(또는 내부적으로 활용) 하기 위해서인데요. 그 서비스가 기능적인 요구사항이나 비기능적인 요구사항(예. 성능, 보안 등)을 충족한다는 가정하에, 블록에 들인 비용을 최소화하는 것은 너무도 당연한 과제입니다. 이 과정은 물론 올바른 블록의 선택부터, 효율적인 조합(예. 아키텍처, 운영/관리 방법론을 포함합니다. 반대로 비용이 제한된 환경에서 성능 등의 지표를 극대화하는 것을 과제로 삼을 수도 있습니다. 결국 클라우드도 파는 상품이기 때문에 구매자는 가성비라는 프레임에서 벗어날 수 없습니다.

그렇다면 클라우드 비용 최적화는 단순히 그것이 효율적인 일이니까 해야 하는 것일까요? 아닙니다. 이쯤에서 최적화의 필요성을 더욱더 강화시키는 클라우드 비용의 특성 2가지를 짚고 넘어가야 합니다.

첫 번째, 클라우드 비용은 일회성(one-time)이 아닌 지속되고 반복되는 특성이 있습니다. 서버를 한 번 사놓고 쭉 쓰는 것처럼 한 번 내는 비용이 아니고요. 내가 지금 사용하는 IT 자원의 규모에 대응하는 비용이 매달 정기적으로 발생합니다. 따라서 이 비용을 한 번 다이어트를 잘 해놓으면 그 효과는 매월 매년 지속되고요. 반대로 헤프게 쓰면 그 낭비되는 비용 또한 반복됩니다. 예를 들어 식별되지도 사용하지도 않는 서버를 그냥 쭉 켜놓으면 그 비용은 아주 꾸준히 지속적으로 낭비됩니다.

두 번째, 클라우드 비용은 기본 사용료 외의 부대비용(additional charge)이 있습니다. 일단 클라우드 사용료라는 기본값(Base) 개념을 생각해 봅시다. Amazon EC2 사용료, Amazon S3 사용료 등이 합산된 값을 떠올리시면 됩니다. 이 값을 기준으로 다양한 부대비용이 추가될 수 있는데요. 만약 여러분이 CSP의 기술 지원을 받는다면 Support Plan에 따른 요금이 추가로 발생합니다. MSP 사의 운영 서비스(Managed Service)를 받는다면 해당 요금이 별도로 추가됩니다. 해당 부대비용들은 일반적으로 기본값(Base)에 정률제로(예. 10%) 더해집니다. 따라서 모든 부대비용의 기준값이 되는 클라우드 순수 사용료를 최적화하는 것은 중요합니다. 그 최적화 수준에 따라 클라우드와 관련된 총비용이 더 큰 폭으로 증감하기 때문입니다.

비용 최적화를 어떻게 해야 할까?

앞서 클라우드의 비용 최적화가 필요한 이유를 살펴봤고요. 이번엔 비용 최적화를 어떤 순서로 진행하는지 알아보도록 하겠습니다. 3단계로 진행하면 되는데요. 아주 간단합니다.

 

첫 번째는 현재 비용 패턴을 분석하는 단계입니다. 현재 클라우드의 어떤 계정 / 서비스 / 과금 항목 / 자원으로부터 비용이 발생하고 있는지를 파악합니다. 최적화 포인트를 식별하기 위해서는 현재의 비용 패턴을 완벽하게 이해하고 있어야 합니다. 예를 들어 미식별된 자원으로부터 비용이 발생하고 있지는 않은지, 실제 예상했던 패턴과 다른 방식으로 비용이 과금되고 있는 건 아닌지를 확인합니다. 이 첫 단계는 비용 최적화에 가장 중요한 첫 단계지만 동시에 가장 난도가 높은 단계이기도 합니다. 그 이유는 뒤에서 자세히 다뤄보도록 하겠습니다.

두 번째는 최적화 포인트를 식별하는 단계입니다. 현재 높은 비용이 발생하고 있는 항목 순으로 최적화 포인트를 탐색합니다. 단순히 비용 데이터를 보는 게 아니라, 현재 클라우드 자원의 구성 현황을 비교/대조하여 최적화 포인트를 찾아야 합니다. 가능한 대안(예. 아키텍처 재구성, 특정 리소스 타입 변경)을 우선순위 별로 선정하고, 최적화 효과가 어느 정도 발생하는지를 사전에 시뮬레이션 합니다. 대안을 적용하는 과정에서 발생할 수 있는 서비스 임팩트나 부대비용이 없는지도 검토합니다. 마지막으로 비용 최적화를 실현하는 과정에서 상쇄되는 가치(보안, 가용성, 운영 편의성 등)가 없는지도 기술적으로 판단할 수 있어야 합니다. 물론 비용도 최적화하고 다른 측면의 완성도도 동시에 높일 수 있는 방향이면 더할 나위가 없겠죠. (실제 사례로 보면 이런 경우가 더 많습니다)

세 번째는 최적화 포인트를 적용하는 단계입니다. 마지막으로 실제 클라우드 자원 조정을 통해 비용 최적화를 실현하는 단계로 보시면 됩니다. (물론 약정 프로그램처럼 자원의 조정이 불필요한 방법도 있습니다) 보통 비용 최적화 작업은 서비스 임팩트가 낮은 것에서 높은 순으로 적용합니다. 예를 들어 다른 자원과 매핑되어 있지 않은 미사용 자원을 삭제하는 것은 서비스 임팩트가 거의 없는 반면, 유휴시간을 동반한 자원 Type의 변경이나 아키텍처 구조를 바꾸는 작업은 상대적으로 서비스 영향도가 클 수 있습니다. 이런 것들을 차등적으로 분류하여 최적화 활동을 순차적으로 전개하고, 반영한 내용에 문제가 없는지 비용/성능 등 다양한 측면에서 모니터링을 수행합니다.

요약하자면 비용 최적화 절차는 단순하지만, 각 단계를 완성도 높게 진행하는 것은 상당히 어렵습니다. 그래서 이 3단계를 누가 수행했느냐에 따라 그 과정과 결과가 크게 달라집니다. 왜냐하면 이 개선활동을 하기 위한 스킬 영역이 굉장히 복합적이기 때문입니다. 즉, 위 그림의 3가지 영역을 완벽하게 이해하고 있어야 합니다. 그 주체는 3륜 안을 갖고 있는 한 명의 엔지니어가 될 수도 있고, Finops 부서와 현업 부서의 TFT 형태가 될 수도 있습니다.

자 이제 질문을 좀 바꿔서, 다음으로는 클라우드 비용 파악이 어려운 이유를 좀 더 자세하게 알아보도록 하겠습니다.

비용 파악이 어려운 이유는 무엇입니까?

3번째 질문입니다. 클라우드 비용을 파악하는 것이 유독 어려운 이유는 무엇일까요? 제가 생각한 대표적인 이유 3가지를 살펴보도록 하겠습니다.

첫 번째, 클라우드는 기본적으로 후불제입니다. 클라우드 비용을 실시간으로 식별하고 제어하기 어렵게 만드는 가장 큰 장애물은 상품구조가 선사용 - 후지불 형태이기 때문입니다. 예를 들어 손님이 슈퍼마켓에서 초코파이를 하나 산다면, 초코파이를 고른 후 나가는 길에 구매와 결제가 동시에 이뤄집니다. 하지만 클라우드라는 슈퍼마켓은 양상이 좀 다릅니다. 권한이 있는 손님은 언제든지 원하는 IT 자원을 (원칙적으로는) on-demand 형태로 가져다 쓸 수 있습니다. 즉, 별도의 check out 과정이 필요 없습니다. 가져다 쓴 사용량에 대한 비용을 월 단위로 취합해서 지불하기 때문에, 구매와 결제의 시점이 크게 달라지게 됩니다.

AWS의 경우 지불단위는 계정(Account)인데, 이 계정 환경 안에서 복수의 사용자가(또는 서비스 간 호출에 따라) 실시간으로 클라우드 자원을 생성/변경/삭제합니다. 원칙적으로는 이런 활동을 통제하거나(예. AM Policy, SCP) 기록하는(예. WS CloudTrail) 서비스나 방법론이 있지만, 현실적으로 모든 것을 통제하기란 어렵습니다. 더구나 앞서 얘기한 것처럼 ‘자원의 변경 시점’과 ‘비용을 확인하는 시점’과 ‘비용을 지불하는 시점’의 괴리로 인해, 비용을 실시간으로 관리/통제하는 것의 난도는 더욱더 높아지게 됩니다.

두 번째, 클라우드는 과금 구조가 매우 복잡합니다. 일례로 과금 항목 자체가 많고, 과금 방식 또한 매우 다양합니다. 예를 들어 Amazon S3라고 하는 스토리지 서비스를 생각해 봅시다. S3라고 하는 하나의 서비스 내에 1) 저장용량에 대한 보관 비용 2) 입출력 요청에 따른 Request 비용 3) 기타 암호화 비용 등이 사용 패턴에 따라 병렬적으로 과금됩니다. 그리고 각 sub-item의 사용량을 측정하는 단위(저장 데이터량, API 요청 횟수)나 대푯값(월평균, 월 누적count)도 각기 다릅니다. 이것이 수백 개의 AWS 서비스로 확장되면, 그 복잡도는 더욱 심화됩니다. 이런 복잡한 과금 정책은 사용자가 클라우드 비용을 이해하기 어렵게 만드는 장애물이 됩니다.

클라우드 과금 구조를 어렵게 만드는 또 하나의 이유는 그 정책이 자주 바뀐다는 것입니다. 예를 들어 기존에 무과금이었던 항목을 새로 과금하거나(예. Public IP 사용료), 기존에 과금했던 항목을 무료로 전환하는 사례(예. VPC Peering 구간의 동일 AZ 간 트래픽 요금)들이 종종 있습니다. 동일 과금 항목에 대해 단가가 변경되는 사례는 상대적으로 매우 빈번합니다. 클라우드 비용을 정확하게 이해하고 예측하기 위해서는, 이런 사항들을 정기적으로 탐색하고 업데이트하는 작업이 반드시 필요합니다.

세 번째, 클라우드 비용 데이터는 일종의 BigData입니다. 혹시 여러분들은 AWS의 CUR(Cost and Usage Report) 데이터를 직접 보신 적이 있나요? 아마도 없을 겁니다. CUR은 간단히 말해 AWS가 제공하는 상세 버전의 비용 데이터인데요. 보통 하루에 한 번 이상 갱신되며, (S3에 저장되는) 원본 데이터의 크기는 생각보다 매우 큽니다. 그렇기 때문에 보통 수백 개의 열, 수십만 개의 행으로 구성된 CUR 데이터를 ‘가공 없이 그대로 보는 것’은 비용 파악에 별 도움이 되지 않습니다.

결국 사용자가 비용 패턴을 파악하기 위해서는 CUR 데이터를 (다양한 기준으로 묶고 다듬어) 가공하는 작업이 필요합니다. 이 역할을 CSP가 도움을 주면 AWS의 Cost Explorer같은 서비스가 되고요. MSP가 도움을 주면 CMP(Cloud Management Platform)같은 솔루션이 됩니다. 때에 따라서는 사용자가 Custom Query를 짜거나 데이터분석 솔루션을 통해 CUR 데이터를 직접 가공해야 할 수도 있습니다.

앞선 내용을 종합하면 클라우드 비용은 1) 복잡하고 2) 가변적이며 3) 실시간으로 파악이 어려운 특성을 갖고 있습니다. 그럼에도 불구하고 현재 언제 어느 지점에서 비용이 발생하는지를 명확하게 이해하는 작업은 반드시 필요합니다. 이 선결조건을 충족하지 않고서는 ‘각자의 최적화 포인트를 찾고 시뮬레이션하는’ 다음 단계로 넘어갈 수 없기 때문입니다.

마치며. 단순히 비용만 줄인다는 착각

오늘은 클라우드 비용 최적화와 접점에 있는 3가지 질문을 정리해 보았습니다. 관련 내용들을 한번 쭉 읽고 나서 여러분은 어떤 느낌을 받으셨나요? 재미있다더니 하나도 재미없는데? 너무 어려워 보이는데? 그래서 구체적으로 어떻게 하라는 거지?

이번 글에서 제가 전달드리고 싶었던 메시지는 "클라우드 비용 최적화는 단순히 비용만을 줄이기 위한 활동이 아니다"라는 것입니다. 분석과 개선을 위한 여정에는 기술적인 영역을 포함한 수많은 공수가 필요하고, 그 결과 전반적인 클라우드 사용 수준을 끌어올리고 관리체계를 반복적으로 개선할 수 있게 됩니다. 그래서 일정 규모 이상의 클라우드를 운용하고 있는 사용자(회사)라면 반드시 요구되는 활동입니다.

다음 회차에는 클라우드 과금체계를 한번 더 보충하고, 실제 영역별 최적화 활동의 전체적인 그림을 한 번 보여드리겠습니다. 그리고 이어서 각 영역별로 어떤 최적화 전략이 있고, 각 단계에서 어떤 것을 고려해야 하고, 어떤 구체적인 반영 사례가 있는지를 순차적으로 다뤄 볼 예정입니다. 연재물이 지속될 수 있도록 많은 관심을 부탁드립니다. 끝.

▶ 최준승님 / Cloud Architect 팀 / jsch@sk.com