클라우드 비용 최적화 로드맵 #3 - 컴퓨팅의 단가를 최적화하는 법

여는 말

안녕하세요. SK텔레콤 최준승입니다. 오늘은 연재 세 번째 시간입니다. 앞선 2회차는 프롤로그 차원에서 클라우드 비용의 특징과 비용을 자세히 보는 법에 대해서 알아봤고요. 드디어 본론입니다. 총 6회차로 계획되어 있는 본론 시리즈 중에서 오늘은 첫 번째 영역인 ‘컴퓨팅의 단가를 최적화하는 법’을 살펴보도록 하겠습니다.

본론 시리즈의 대략적인 흐름을 알아볼까요? 일단 각 회차별로 목표가 있습니다. 오늘의 목표는 Compute 영역의 단가를 최적화하는 것입니다. 이 영역 내에서 최적화 방법론을 2-3개 정도 선정합니다. 이는 독립된 방법론 여러 개가 될 수도 있고, 하나의 방법론을 적용하는 대상이 복수로 확장될 수도 있습니다. 이어서 각 방법론의 핵심 개념과 적용 방식, 그리고 적용 전후의 고려 사항들을 위주로 내용이 전개됩니다. 가능하다면 상황 베이스의 적용 예시를 덧붙여서 독자의 이해도를 높여볼 생각이고요. 대부분의 예시는 AWS 환경 기준으로 다룹니다.

참고로 지엽적인 예시보다는 개념을 이해시키기 위한 용도의 추상화된 그림을 최대한 많이 활용했습니다. 상세한 방법론이나 구체적인 적용 예시의 장점도 분명 있겠지만, 이 시리즈의 목표와는 맞지 않기 때문인데요. 이 시리즈의 최종 목적은 각자의 환경에 맞는 정답을 스스로 찾을 수 있게 도와주는 것입니다. 이를 위해서는 특정 시점의 지엽적인 최적화 기술을 아는 것보다는, 그 기술을 파생시키는 근본적인 최적화 메커니즘을 이해하는 게 더 중요합니다. 따라서 AWS 서비스 레벨의 예시는 최적화 메커니즘을 설명하는 도구 수준에서 가공하려고 합니다. 독자 여러분들은 근본 메커니즘을 기반으로 각자의 세부 방법론을 해당 시점에 최적화된 것으로 탐색해서 적용하시면 됩니다.

첫 번째 방법론, 동일 계열 내 Size를 조정하는 수직적 이동

컴퓨팅 영역의 단가를 최적화하는 첫 번째 방법은 컴퓨팅 자원의 스펙을 수요에 맞게 조정하는 것입니다. 너무 뻔한 말이라고요? 맞습니다. 하지만 안타깝게도 이것이 가장 쉽고 효과적인 방법입니다. 클라우드 컴퓨팅 소개 자료에서 자주 등장하는 그림 하나를 같이 보시죠.

컴퓨팅 자원의 수요와 공급 그래프입니다. 자원의 수요량과 공급량이 교차합니다. 수요량은 워크로드 특성에 따라 일정할 수도 있고, 넓은 범위로 등락을 반복할 수도 있습니다. 아마 후자라면 여러분은 On Premise가 아닌 클라우드 환경을 고려했을 확률이 높습니다. 왜냐하면 공급량을 Dynamic하게 조정하기에는 클라우드 환경이 더 편하기 때문입니다. 공급이 수요를 초과하면 자원 낭비가 발생하고 수요가 공급을 초과하면 성능 이슈가 발생합니다. 현실적으로 성능 이슈를 감내하긴 어렵기 때문에 보통은 자원 낭비를 택하게 되고요. 그렇게 되면 수요와 공급 사이의 간격, 즉 잉여 자원(=손실 비용)의 폭을 어떻게 관리할지가 새로운 과제가 됩니다.

 

컴퓨팅 자원의 공급을 수요에 대응시키는 가장 안전한 방법은 ‘동일 계열 내에서’ Size를 조정하는 것입니다. 저는 이것을 수직적 이동이라고 정의했는데요. AWS 환경을 예로 들면, 같은 계열(Family) 내에서 인스턴스의 크기를 위아래로 조정하는 것입니다. 이를테면 M5 계열의 m5.2xlarge를 m5.xlarge 또는 m5.4xlarge로 변경할 수 있습니다. m5.xlarge로도 충족할 수 있는 수요를 m5.2xlarge로 커버하고 있었다면, 이 수직적 조정 작업(m5.2xlarge → m5.xlarge)을 통해서 자원과 비용을 최적화할 수 있습니다.

수직적 이동의 가장 큰 장점은 난도가 낮다는 것입니다. EC2를 비롯하여 대부분의 컴퓨팅 서비스에서 정의하는 계열(Family)은 대개 Host 서버의 특성을 따르게 되는데요. 수직적 이동은 같은 유형의 Host에서 배분하는 자원의 크기(Size)만 다르게 지정한 것이라 상호 호환성 이슈가 없습니다. 물론 스펙 변경 후에는 중지나 재시작으로 자원을 재할당 받는 과정이 필요할 수도 있습니다. (CSP와 서비스에 따라서 중지/재시작이 불필요한 경우도 있습니다.)

수직적 조정을 통해 컴퓨팅 자원의 공급량을 ‘적은 리스크로’ 조정할 수 있다는 사실을 확인했습니다. 그렇다면 자원의 수요량은 어떻게 측정할까요? 이것은 실제 서비스 환경의 워크로드 패턴을 보는 것이 가장 정확합니다. 물론 시나리오를 정의하고 부하 테스트 툴을 통해 스펙별로 성능을 측정하는 방법도 있습니다만, 사실 클라우드 환경에서 정밀한 사전 측정은 불필요합니다. 수요에 대응하는 공급 유형을 언제든지 (기회비용을 지불하지 않고) 조정할 수 있기 때문입니다.

 

그럼 이런 수직적 조정은 어떤 상황에 가장 적합할까요? 수직적 조정은 보통 예측 가능한 (그리고 어느 정도 일정한 패턴을 가진) 워크로드에 효과적입니다. 단일 노드 또는 고정된 노드 수로 구성된 클러스터 환경에서 스펙을 메뉴얼하게 조정할때 가장 적합한 전략입니다. 좀 더 동적인 수요에 대응하기 위해서는 단위 스펙이 아니라 노드수를 수평적으로 확장/축소하는(EC2 Auto Scaling 또는 컨테이너 환경에서 pod 수를 조정) 접근이 더욱 효과적이고요. 이 방법은 컴퓨팅 자원의 단가보다는 사용률을 조정하는 기법에 가깝기 때문에 여기서는 논외로 하려고 합니다. 물론 이때에도 어떤 단위 Unit이 효과적인지를 판단하기 위한 조정 작업은 필요할 수 있습니다.

 

다시 원점으로 돌아와서, 컴퓨팅 자원의 스펙을 조정하는 방법에는 계열 내 이동(=수직적 이동)과 계열 외 이동(=수평적 이동)이 있습니다. 혹시나 혼동되는 분이 계실까봐 중간 정리하면, 여기서 말하는 수평적 이동은 "다른 계열(Family)의 서버 타입으로 변경하는 것"을 의미하기 때문에 이전 문단에서 언급한 수평적 축소/확장과는 완전히 다른 개념입니다. 이어서 계열 외 이동의 특징과 효과에 대해 살펴보도록 하겠습니다.

두 번째 방법론, 타 계열로 전환하는 수평적 이동

이번엔 다른 계열(Family)로 스펙을 변경하는 수평적 이동에 대해 알아보도록 하겠습니다. ‘AWS가 제공하는 용도별 인스턴스 계열 예시’ 이미지에서 보신 것처럼, CSP는 보통 가상화된 환경에서 Host의 특성에 따라 사용자에게 다양한 계열의 노드 타입을 제공합니다. 계열별 특성을 구성하는 요소로는 CPU, Memory, GPU, Network, Storage 등이 있고요. 예를 들어 CPU-Optimized 계열은 상대적으로 CPU 코어 수를 Memory 크기에 비해 더 많이(=더 높은 Ratio로) 할당하기도 하고, GPU-Optimized 계열은 타 계열에 비해 높은 수준의 GPU 성능을 제공하기도 합니다. Storage-Optimized 계열은 하이퍼바이저 단에 바로 붙어있는 별도의 스토리지를 제공합니다. 즉 각 계열별로 자원 배분(성능) 특성이 다릅니다.

설명 편의상 옷을 교환하는 일로 비유해 보겠습니다. 수직적 이동은 같은 디자인의 옷을 크기(X/XL/XXL)만 다르게 바꾸는 작업입니다. 반면 수평적 이동은 체형(워크로드 특성)에 맞는 다른 디자인의 옷으로 바꾸는 행위에 가깝습니다. 물론 먼저 디자인을 바꾼 후에(=수평적 이동), 크기에 따른 조정(=수직적 이동)을 한 번 더 진행할 수도 있습니다.

수평적 이동은 수직적 이동에 비해 전환 난이도가 더 높습니다. 왜냐하면 Host의 특성이 바뀌기 때문입니다. 예를 들어 하이퍼바이저 또는 가상화 유형이 달라질 수도 있고, CPU의 아키텍처(x86/ARM)가 바뀔 수도 있습니다. 만약 이런 유의미한 차이점이 있다면 옮기는 계열에 맞춰서 OS 호환성이나 각종 드라이버의 Dependency를 사전에 검토해야 합니다. 물론 수평적 이동임에도 불구하고 출시된 세대(Generation)가 비슷하다면 전환 이슈가 전혀 없는 경우도 있습니다. 

결국 수평적 이동은 손이 좀 더 가는 단점이 있지만, 체형에 맞는 디자인의 옷을 찾아가는 과정과 유사하기 때문에 최적화 측면에서 더욱 효과적인 방법이 될 수 있습니다. 물론 수평적 이동과 수직적 이동은 병용할 수 있는 전략입니다. 일반적으로 수평적 이동으로 워크로드 패턴을 먼저 최적화한 후, 수직적 이동으로 할당 자원의 크기를 한 번 더 조정하는 것을 권고합니다.

그렇다면 수평적 이동은 어떤 방향으로 진행하는 게 좋을까요? 오늘은 2가지 전략을 소개해 드리려고 하는데요. 첫 번째는 최신 세대의 계열로 이동하는 전략, 두 번째는 CSP 맞춤형 계열로 이동하는 전략입니다.

클라우드는 여러 방면에서 다이내믹한 환경이기 때문에 제공하는 컴퓨팅 자원의 종류도 자주 변경됩니다. 특정 스펙이 일몰 되는 경우도 있지만 드물고, 보통은 새로운 최신 스펙이 새로 출시되는 경우가 많은데요. 예를 들어 AWS에서 Memory-Optimized 군에 속한 R계열의 히스토리를 보면 R3 → R4 → R5 순으로 새로운 세대(Generation)가 순차적으로 출시되었습니다. 동일한 크기(Size)를 기준으로 비교해 봤을 때 최신 세대일수록 성능은 더 좋고 단가는 동일하거나 오히려 낮습니다. 따라서 최신 세대의 계열로 주기적으로 변경하는 것은 가성비나 차후 관리(메인터넌스) 측면에서 매우 효과적인 전략이 됩니다.

수평적 이동에 효과적인 두 번째 전략은 CSP 맞춤형 계열로 전환하는 것입니다. AWS 환경의 경우에는 Grativion 계열이 있는데요. Gravition의 경우 AWS가 해당 회사를 인수해서 자체적으로 생산하는 칩이기 때문에 가성비 측면에서 단가 정책이 좋을 수밖에 없습니다. 24년 5월 기준으로 Gravition은 4세대까지 출시되어 있고요. 워크로드 특성에 따라 효율은 다를 수 있지만 전반적으로 가성비가 훌륭합니다. 다만 Gravition 계열은 ARM 기반의 아키텍처로 설계되어 있기 때문에, x86 계열로부터의 변경이라면 전환 난이도가 생각보다 높을 수도 있습니다.

*이미지 출처 : https://aws.amazon.com/blogs/compute/powering-net-5-with-aws-graviton2-benchmark-results/

 

EC2와 같은 IaaS 레벨의 서비스 외에도, RDS 같은 관리형 서비스 또는 Lambda 같은 FaaS 레벨의 서비스에서도 다양한 스펙(계열)의 컴퓨팅 자원을 제공합니다. 이 경우도 워크로드 맞춤형으로 컴퓨팅 자원을 배치하는 전략을 통해 컴퓨팅 자원의 단가를 최적화할 수 있습니다.

 

컴퓨팅 영역의 단가를 최적화하는 방법이 결국 자원의 스펙 변경이라니, ‘너무 뻔한 방법이 아니냐’고 생각하시는 분이 있을지도 모르겠습니다. 하지만 앞서 말씀드린 대로 클라우드 환경은 레거시 환경에 비해 스펙 변경에 따른 기회비용이 거의 발생하지 않고, 높은 가성비의 New 타입이 지속적으로 출시된다는 측면에서 주기적인 스펙 변경 작업은 필수입니다. 또한 이런 장점을 누리기 위해 클라우드 환경으로 이전했음에도 불구하고, 실제 초기 셋업 이후 스펙 변경 작업이 전무한 곳도 생각보다 많습니다. 다음 세 번째 주제에서는 컴퓨팅 자원의 스펙을 변경하지 않고 단가를 최적화하는 법을 알아보도록 하겠습니다.

세 번째 방법론, 약정(Commitment) 관리하기

앞서 소개 드린 수직적 이동이나 수평적 이동은 모두 컴퓨팅 자원의 스펙을 바꾸는 작업입니다. 따라서 경우에 따라 인프라 레벨의 영향도가 발생할 수 있습니다. 간단하게는 중지 후 재시작이 필요할 수도 있고 아주 복잡한 형태의 마이그레이션이 필요할 수도 있습니다. 최적화 작업도 결국 ROI가 나오는 영역만 의미가 있기 때문에, 전환 과정에서의 위험(Risk)이나 작업비용(Investment)이 상대적으로 너무 크다면 굳이 진행할 필요가 없어집니다.

 

컴퓨팅 영역의 단가를 최적화하는 세 번째 방법은 CSP의 약정 프로그램을 적극적으로 활용하는 것입니다. 약정은 인프라 레벨의 변경 작업을 수반하지 않기 때문에 쉽고 간편하게 컴퓨팅 영역의 단가를 낮출 수 있습니다. 난도가 낮은데도 불구하고 할인율은 비교적 높기 때문에 ROI가 꽤나 잘 나오는 전략입니다.

약정의 기본 개념은 정해진 기간 동안 사용자가 물량을 약속(Commitment) 하고 CSP로부터 낮은 단가를 적용받는 것입니다. 약정한 자원의 종류나 기간에 따라서 할인율은 각기 다르게 책정되어 있습니다. 할인율은 On Demand 단가 기준으로 적게는 10%에서 최대 6-70%까지 더 저렴한 단가로 동일한 자원을 사용할 수 있습니다.

 

약정의 기본 원리는 간단하지만, 실제 약정을 어떻게 구매하고 어떻게 적용되는지는 CSP에 따라 매우 복잡한 영역입니다. AWS의 경우 Reserved Instance(RI)라고 하는 약정 프로그램이 서비스(EC2, RDS 등)별로 있고, Savings Plan이라는 약정 프로그램도 있습니다. 연재의 목적은 특정 CSP의 약정 프로그램을 설명하는 것이 아니기 때문에, 오늘은 약정 프로그램의 기본 메커니즘을 이해할 수 있는 수준으로만 예시를 다듬어 설명하겠습니다.

약정을 구매할 때는 사용자가 몇 가지 항목을 미리 정의할 필요가 있습니다. 예를 들어 AWS의 EC2 RI 프로그램은 사용자가 아래 사항들을 확정해서 CSP에 알려줘야 합니다.

사전에 정의하는 항목을 최소화하고, On Demand 사용량에 좀 더 탄력적으로 적용되는 Savings Plan 같은 약정 프로그램도 있습니다. Savings Plan의 경우 RI와 달리 복수의 서비스(EC2, Lambda 등)에 동시에 적용되거나, 할인율만 상이할 뿐 OS / AZ / Tenancy 등을 가리지 않는 장점이 있습니다.

약정은 꼭 한 가지 형태로만 구매할 수 있는 것은 아닙니다. AWS의 경우 여러 개의 RI를 섞어서 구매할 수도 있고, 동시에 Savings Plan을 구매해도 됩니다. 가장 중요한 것은 On Demand 사용량 이상으로 약정을 구매하면 안 된다는 것인데요. 이것을 판단하기 위해서는 약정이 적용되는 메커니즘을 정확하게 이해할 필요가 있습니다.

약정은 기본적으로 이월되지 않는 특성이 있습니다. 시간 단위로 On Demand 사용량과 매칭되지 못한 약정 물량은 축적되지 않고 그냥 버려집니다. 예를 들어 m5.large 2개의 RI를 구매했는데, on demand로 10시간 동안 m5.large x 1대 + 그다음 10시간 동안 m5.large x 3대를 사용했다면 아래와 같이 과금이 발생합니다.

• 첫 10시간 : 1대는 RI가 매칭되어 약정 단가로 과금되고, 남은 1개의 RI는 이월되지 않고 버려집니다.
• 다음 10시간 : 2대는 RI가 매칭되어 약정 단가로 과금되고, 1대는 On Demand 단가로 과금됩니다.

조금은 이해가 가시나요? 사실 약정 물량을 산정하는 공식이나 약정 Share에 따른 최적화 전략까지 커버하려면 설명이 너무 길어지기 때문에 오늘은 이 정도 수준의 내용만 다루고 넘어가려고 합니다. 상세한 내용은 CSP별로 제공하는 약정 프로그램 안내 문서를 참고하시고요. 마지막으로 한 가지만 팁을 더 드리자면, 각 약정 프로그램이 커버할 수 있는 범위(Flexibility)를 제대로 파악하는 것이 중요합니다. 이것을 제대로 이해해야 유형별 약정 물량을 효과적으로 조합할 수 있습니다.

마지막으로 약정의 성숙도를 평가하는 2가지 지표를 소개해 드리겠습니다. 첫 번째 지표인 Utilization 값은 구매한 약정 물량의 몇 %가 On Demand와 매칭되었는지(=할인 단가가 적용되었는지)를 평가합니다. 해당 값은 원칙적으로는 100%가 되도록 설계하는 게 좋습니다. 두 번째 지표인 Coverage는 On Demand의 몇 %를 약정 물량으로 커버했는지를 알려주는 값입니다. 이 값은 향후 워크로드의 규모가 얼마나 증감하느냐에 따라 목표치가 좀 달라질 수 있는데요. 보수적으로 잡으면 1차 목표치를 6-70% 수준으로 설계하는게 바람직합니다.

좀 더 깊이 들어가면 Utilization과 Coverage 값이 일부 상충되는 케이스도 있습니다. Utilization이 100%에 못 미치더라도, Coverage를 극단적으로 높여서 전체적인 할인율을 낮추는 방안도 생각해 볼 수 있고요. 약정을 한 번에 구매하는 것이 아니라 시기별로 나눠서 구매함으로써, 약정 물량이 순차적으로 일몰 되게 하는 리스크 헷징 전략도 구사할 수 있습니다.

약정 파트에서 다룬 내용들을 요약하면 다음과 같습니다.

1. CSP 별로 약정 프로그램이 적용되는 메커니즘을 이해한다.
2. 지난 몇 달간 On Demand 사용량 패턴을 분석한다. 이를 기반으로 향후 On Demand 사용량을 예측해 본다.
3. On Demand 예측 양을 기반으로, 필요한 약정 물량을 계산하여 구매한다.
4. 이후 Utilization과 Coverage 값을 주기적으로 평가하여, 약정 물량을 재산정(반영)한다.

마치며

오늘은 컴퓨팅의 단가를 최적화하는 3가지 전략을 소개해 드렸습니다. 3가지 전략의 공통점이 있다면 ‘최적화 작업에는 일정 수준의 투자(또는 리스크 감수)가 필요하다’는 것입니다. 낮은 단가를 취하는 대신 일종의 Trade-off를 감수해야 합니다. 수직적 이동이나 수평적 이동은 스펙 변경에 소요되는 시간을 감내하거나 전환 및 테스트 작업이 필요할 수 있습니다. 약정은 ‘약정 기간 내에 On Demand 사용량이 크게 감소했을 때의 Risk’를 감수해야 할 수 있습니다. 결국 모든 것은 일종의 Deal이기 때문에 최적화 전략에 장점만 존재하는 것은 아닙니다.

 

오늘 다루는 주제에 AWS의 Spot Instance 와 같은 (비교적 극단적인) 전략을 포함하지 않은 것도 비슷한 이유입니다. Spot Instance가 제공하는 단가는 드라마틱하게 낮지만, Spot 특성상 컴퓨팅 자원을 예상치 못한 시점에 반환해야 할 수도 있습니다. 따라서 Application 구조의 변경이 필요할 수도 있고, 전반적으로 전환 작업의 난도가 높습니다. 난도가 높으면 전체적인 최적화 작업의 ROI를 뽑아내기가 어렵기 때문에 내용의 확장성 측면에서 너무 난해한 주제는 가급적 생략했습니다.

 

오늘 소개해 드린 3가지 전략은 사람의 손을 타야 하는 메뉴얼한 활동이지만, 그 과정에서 CSP에서 제공하는 여러 가지 추천 서비스를 참고할 수 있습니다. AWS의 경우 Compute Optimizer는 기존 자원 사용량을 기반으로 적합한 스펙의 컴퓨팅 자원을 추천해 줍니다. RI/SP Recommendation에서는 On Demand 사용량을 기반으로 적절한 약정 물량을 추천해 줍니다. 약정 추천의 경우 MSP사에서 제공하는 빌링 솔루션을 활용할 수도 있는데요. 적합한 약정물량 추천은 물론, 현재의 Utilization과 Coverage를 계산해 주는 기능을 대부분 갖고 있으니 참고하시기 바랍니다.

 

다음 편에서는 스토리지의 단가를 최적화하는 법을 살펴보겠습니다. 클라우드 환경에 이해도가 조금 있는 독자분이라면 어떤 내용을 다룰지 예측도 한번 해보시고요. 정말 그 내용이 다음 편에서 등장하는지 확인해 보셨으면 좋겠네요. 그럼 다음 편에서 만나요. 제발~!

 

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