클라우드 비용 최적화 로드맵 #6 - 컴퓨팅의 사용량을 최적화하는 법

여는 말

안녕하세요. SK텔레콤 최준승입니다. 오늘은 연재 6번째 시간입니다. 지난 회차까지 단가편이 마무리됐고, 사용량편을 새로 시작하는 회차입니다. 오늘의 주제는 컴퓨팅 영역의 사용량을 최적화하는 법인데요. "나는 주로 컴퓨팅 영역의 최적화에 관심이 있다"라는 독자분이 있다면 컴퓨팅-단가편(3회차)과 컴퓨팅-사용량편(6회차)을 번갈아 보시는 것도 좋을 것 같네요.

본론을 시작하기에 앞서 클라우드 환경에서 단가와 사용량 지표의 특수성에 대해 한번 생각해 봅시다. 레거시 환경의 지표와 어떻게 다른지를 떠올려 보시면 되는데요. 먼저 단가는 어떻습니까? 지난 회차에서 누누이 언급했던 것처럼 클라우드 환경의 단가 구조는 매우 복잡합니다. 과금 정책은 서비스별로 다르고, 이 중 개별 단가는 각 서비스의 자원 속성에 따라 달라지는 경우가 많습니다.

한편 사용량은 어떤가요? 클라우드는 동적으로 자원을 만들고 삭제하는 것이 (레거시에 비해) 훨씬 더 자유로운 환경이기 때문에 사용량 지표 또한 "예측되는 상수"가 아닌 “변수”에 가깝습니다. 따라서 이 사용량을 어떻게 제어하고 관리하느냐에 따라서 부과되는 비용이 크게 달라질 수 있습니다.

클라우드 환경에서 단가 및 사용량 지표의 특수성을 언급한 이유는, 이것이 곧 비용 최적화 접근 전략과 맞닿아 있기 때문입니다. 단가 최적화 전략은 클라우드 서비스별 과금 구조를 정확하게 이해하고 최적화 타입을 찾는 행위에 가깝습니다. 예를 들어 워크로드 특성에 맞는 서버 타입을 선정한다거나, 액세스 패턴(Hot/Cold)에 적합한 Storage Class를 선택하는 것들 말이죠.

반면 사용량 최적화 전략은 기술적인 운영과 좀 더 관련성이 높습니다. 예를 들어 컴퓨팅 자원의 스케줄링을 통해 구동 시간을 최소화한다거나 데이터 압축을 통해 저장소 크기를 최소화하는, 말 그대로 “실제 자원을 조금 쓰는" 전략을 고려하는 것이죠. 이쯤에서 여러분들이 이 내용을 잘 이해하셨는지 확인하기 위해 스페셜 퀴즈를 준비했습니다. 아래 4가지 전략 중 어느 것이 단가 관점이고 어느 것이 사용량 관점일까요?

정답은 다음과 같습니다. 1번과 2번은 단가 관점, 3번과 4번은 사용량 관점의 전략입니다. 약정 프로그램 등을 활용하는 1번은 단가를 낮추는 가장 쉬운 방법으로, 특히 컴퓨팅 자원을 대상으로 활용하기 좋은 전략입니다. 2번 Right-Sizing도 단가를 최적화하는 전략입니다. 실제 워크로드에서 요구되는 성능에 맞춰 대응하는 자원의 크기(or 성능)를 알맞게 생성하는 개념입니다. 사용자가 선택하는 자원의 크기나 성능값은 대개 단가와 비례하기 때문입니다. 4번은 "자원이 일정 시간 필요 없을 때 잠깐 꺼두는 개념"이고 3번은 "자원이 영원히 필요 없을 때 아예 없애버리는 개념"이기 때문에, 두 가지 모두 사용량을 최적화하는 전략이 됩니다. 특히 오늘 주로 다루는 내용은 4번 Suspending 전략과 관련성이 높습니다.

좀 더 단순하게 생각해 보면 컴퓨팅의 사용량을 최적화하는 것은 컴퓨팅 자원의 Running Time(=구동 시간)을 최소화하는 것입니다. 그렇다면 해당 자원의 구동 시간을 최소화하려면 어떻게 해야 할까요? 일단 자원이 필요 없을 때는 꺼두면 됩니다. 자원이 필요할 때는 공급이 수요에 대응하도록 적절하게 맞춰주면 됩니다.

물론 이러한 일련의 작업을 수행하기 위해서는 몇 가지 기술적인 방법들이 필요한데요. 자원을 끄고 켜는 것도, 자원을 수요에 맞춤 대응하는 것도, 사람이 직접 수행하면 관리 영역이 되고 이는 곧 비용으로 환산되기 때문입니다. 따라서 자동화를 통해 이러한 관리 비용을 최소화할 필요가 있습니다. 그리고 클라우드 환경은 이런 관리 작업을 손쉽게 자동화할 수 있도록 이미 다양한 관리 기능을 Built-In 방식으로 만들어 놓았습니다. 오늘은 컴퓨팅의 사용량을 최적화하는 기법과 함께 이러한 기법을 쉽게 구현할 수 있게 해주는 도우미 기능들을 집중적으로 살펴보도록 하겠습니다.

서버를 on-off 하는 스케줄링

컴퓨팅의 사용량을 최적화하는 첫 번째 기법은 스케줄링입니다. 스케줄링은 공학적으로 여러 가지 의미로 해석될 수 있는데요. 여기서 말하는 스케줄링은 컴퓨팅 자원을 끄고 켜는 작업의 스케줄링을 말합니다. 먼저 자원이 필요한 시간 패턴을 정의하고, 해당 패턴을 기반으로 일정한 규칙을 세우고, 그 규칙을 반복하는 것입니다. 예를 들면 아래와 같은 시간 패턴을 가정해 봅시다.

위 그림은 평일 업무시간에만 컴퓨팅 자원이 필요한 패턴의 예시입니다. 예를 들어 어떤 상황이 있을까요? 개발(dev) 환경이나 검증(stage) 환경은 굳이 주말에 비싼 자원을 켜놓을 필요가 있을까요? 평일 업무시간 외의 시간도 마찬가지입니다. "평일 업무시간에만 제한적으로 서비스"해도 되는 사내 인터페이스 같은 워크로드는 어떨까요? 만일 전통적인 물리 서버 기반의 레거시 환경이었다면 굳이 정성스럽게 서버를 내려놓을 필요가 없겠지만(비용과 무관하므로), 클라우드 환경은 서버를 꺼놓으면 그만큼의 비용을 줄일 수 있습니다. 왜냐면 사용량이 0으로 잡히는 시간에는 비용을 받지 않기 때문입니다. 그럼 그 효과가 어느 정도 되는지 간단히 따져보겠습니다.

서버를 평일 업무시간에만 제한적으로 켜놓을 경우 비용(사용량)을 무려 73%가량 줄일 수 있습니다. 만일 해당 값 모수가 1,000만 원이었다면 730만 원을 아낄 수 있는 거죠. 단순히 켜고 끄는 작업을 구현한 것만으로도 엄청난 효과 아닙니까? 단가 관점에서 컴퓨팅 자원을 1년간 약정했을 때 절감 비율이 기존 대비 20~30% 정도라는 것을 감안하면 엄청난 효율입니다. 물론 최적화 작업은 단가와 사용량 두가지 측면을 독립적으로 진행하기 때문에 서로 단순 비교할 대상은 아니긴 합니다.

시뮬레이션을 통해 "스케줄링은 사용량을 절감하는 효과적인 전략"임이 확인되었습니다. 이제 이 전략을 "무엇을" 대상으로 "어떻게" 해야 하는지를 고민할 차례입니다. 먼저 AWS 환경을 기준으로 "무엇을" 대상으로 할지 생각해 보겠습니다. AWS의 서비스별로 스케줄링을 구현하기 위한 전제 조건에는 어떤 것이 있을까요? 일단 중지 및 재시작이 가능해야 합니다. Amazon EC2? 가능합니다. Amazon RDS? 가능합니다. Amazon MSK? 지원하지 않습니다. Amazon DocumentDB? 가능합니다. 이렇게 서비스별로 (특히 관리형 서비스 계열은) 중지 및 재시작을 자체적으로 지원해야 스케줄링을 구현할 수 있습니다. 또한 관련 제약조건도 확인해야 합니다. 중지 및 재시작 횟수에는 제약이 없는지, 중지 상태를 최대 며칠간 지속 가능한지, 중지 기간 동안 "사용량이 0이 되는 자원"과 "사용량이 0이 되지 않는 자원"은 어떤 것이 있는지를 정확히 구분해서 이해해야 합니다.

예를 들어 일반적인(=Aurora 엔진이 아닌) RDS 인스턴스를 스케줄링한다고 생각해 봅시다. 참고로 제약조건은 언제든지 변할 수 있으므로 기준일은 24년 8월로 하겠습니다. 1) 중지 가능한 DB 엔진에 제약이 있을까요? 거의 없습니다. 다만 Multi-AZ 환경에 배포된 SQL Server 인스턴스는 중지를 지원하지 않습니다. 2) 중지 상태는 최대 몇 시간까지 유지할 수 있을까요? 연속 시간 기준으로 최대 7일까지만 중지할 수 있습니다. 7일 경과 시 인스턴스가 자동으로 재시작됩니다. 3) 중지 기간 동안 과금되는 항목과 과금되지 않는 항목은 어떤 것이 있을까요? 중지 기간 동안 RDS 인스턴스의 노드 비용은 과금되지 않습니다. 다만 해당 인스턴스에 붙어 있는 EBS 볼륨은 여전히 활성화 상태이므로 기존과 동일하게 과금이 발생합니다.

앞서 "무엇을" 대상으로 스케줄링을 반영할 것인지를 살펴봤고요. 이번에는 스케줄링을 "어떻게" 구현할지를 고민해 보겠습니다. 서버를 끄고 켜는 작업은 동일 패턴으로 반복되기 때문에 관리 및 위험 비용 측면에서 당연히 자동화해야 할 대상입니다. AWS에는 Instance Scheduler라고 부르는 도우미 솔루션이 있는데요. 정식 서비스 형태는 아니고 AWS 서비스 컴포넌트들을 엮어서 마치 하나의 솔루션처럼 엮어놓은 형태입니다.

• 출처: https://www.amazonaws.cn/en/solutions/instance-scheduler/

Instance Scheduler의 구성 서비스별 역할과 동작 방식은 아래와 같습니다.

1. 먼저 CloudFormation 등의 배포 서비스를 통해 위 아키텍처를 AWS 환경에 배포합니다.

2. Lambda 함수는 실제 서비스 자원을 중지하고 재시작하는 주체입니다. 해당 함수의 실행은 CloudWatch(또는 EventBridge)가 Trigger합니다.

3. DynamoDB 테이블에는 스케줄링 일정과 스케줄링 자원의 상태 정보를 기록합니다.

4. 보통 스케줄링 대상은 태그 기반으로 구분합니다. 사전에 스케줄링 대상을 식별하는 규칙을 정의하고, 적용 대상은 태그 기준으로 동적으로 관리합니다.

참고로 이런 자동화 계층을 운영하는 데에도 약간의 추가 비용이 발생합니다. 해당 비용은 스케줄링하는 대상의 규모에 따라 적게는 몇십 달러에서 많게는 수백 달러까지 발생할 수 있고요. 스케줄링으로 절감되는 전체 비용에 비해서는 아주 미미한 수준입니다. 그럼 첫 번째 주제는 이 정도로 정리하고, 다음 장에서는 좀 더 복잡한 형태의 자원 배분 전략을 살펴보도록 하겠습니다.

다차원의 복합 스케줄링, Auto Scaling의 활용

컴퓨팅의 사용량을 최적화하는 두 번째 기법은 Auto Scaling입니다. 스케줄링이 시간 기반으로 "자원의 상태를 0 또는 1"로 만드는 작업이라면, Auto Scaling은 실제 서비스 수요를 기반으로 자원의 배치를 1부터 2,3(~n)까지 만들어 주는 기능입니다. 이때 크기 조정(=Scaling)의 방향성은 보통 (수직적인 아닌) 수평적으로 확장/축소한다고 보시면 됩니다.

• 출처: https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html

위 그림은 수요(Actual Capacity)의 최대치 기준으로 투입하는 자원(Provisioned Capacity)의 수량을 일정하게 유지하는 예시입니다. 예를 들어 매주 수요일마다 하는 이벤트에 대응하기 위해서는 100대의 EC2가 필요하다고 가정해 보겠습니다. 이때 100대의 EC2 수량을 일주일간 그대로 유지한다면, "매시간 공급이 수요를 초과하는 만큼"의 자원이 불필요하게 소모됩니다. 여기서 낭비되는 자원은 곧 컴퓨팅의 사용량으로 환산되고, 해당 값에 단가를 곱하면 낭비 비용이 됩니다. 이 낭비되는 사용량을 최소화할 수 있도록 "동적으로 자원의 수를 조정"해 주는 기법이 Auto Scaling입니다.

• 출처: https://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html

Auto Scaling의 기본 개념은 단순하지만 실제 이를 구현하기 위해서는 몇 가지 사전 작업이 필요합니다. 예를 들어 WEB/WAS 계층에 Auto Scaling을 구성한다고 생각해 봅시다. 사용자의 개입 없이 해당 계층의 EC2 수량을 동적으로 조절하기 위해서는 아래 사항들을 미리 설계해야 합니다.

1. 새로운 EC2가 추가되었을 때 배포 동기화

2. 기존 EC2가 삭제되었을 때 필요한 데이터(로그 등) 보관 처리 로직

3. 신규 EC2가 추가되는 기준값, 기존 EC2가 삭제되는 기준값

4. 가동하는 EC2 수량의 최솟값과 최댓값 등

1번은 기준 이미지(OS+필수 패키지)를 마련하는 작업부터 실제 웹 소스나 이런 것들을 동적으로 재배포할 수 있는 파이프라인이 있어야 합니다. 2번은 EC2 자원이 동적으로 삭제될 때 웹 로그 같이 보관이 필요한 데이터를 외부로 넘겨주는 로직이 필요할 수 있고요. 3번은 "원하는 EC2의 수량"을 늘리고 줄이는 기준을 수립하는 영역으로, 실제 Auto Scaling의 효율을 결정하는 영역이기도 합니다. 확장/축소를 결정하는 기준값은 보통 "EC2의 CPU 사용률 평균값"이나 "공용 Queue의 메시지 수" 같은 지표를 사용합니다. 4번은 최소/최대 수량을 정해서 서비스가 구동되는 최소 수준과 최대 수준을 정의합니다. 특히 최댓값은 전체 비용을 통제하는 값으로 사용하기도 하고, 연관 컴포넌트(DB 등)의 성능 이슈를 방지하는 제어장치로 활용하기도 합니다.

위 내용들은 사실 지엽적인 방법론이라 중요한 내용은 아닙니다. 여기서 중요한 메시지는 이런 작업들에 사용자의 공수가 든다는 것입니다. 전체적인 배포 파이프라인을 재설계하고, 스케일링 기준값을 부하 테스트를 통해 검증하고, 실제 Scaling 이력을 보고 값을 재조정하고 이런 일련의 과정에는 난이도에 비례하는 초기 투자비용이 발생할 수 있습니다. 정상적으로 설계안이 동작하지 않을 때의 위험 비용도 생각해야 하고요. 물론 어느 정도 안정화가 된 이후에는, 비용 없이 효과만 발생하는 지점이 오게 됩니다.

• 출처: https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html

"수요에 공급을 동적으로 대응시킨다"라는 관점으로 보면 EC2 서비스 외에도 다양한 Auto Scaling 기법이 존재합니다. DynamoDB에서 읽기/쓰기 성능값을 "수요와 마진 값"에 따라 동적으로 조정할 수 있고, Aurora 클러스터에서 읽기 부하에 따라 "Replica 노드 수량"을 자동으로 조정할 수도 있습니다. Sagemaker 같은 서비스에서도 Inference Endpoint 수를 동적으로 관리할 수 있습니다. EKS나 ECS 서비스 같은 컨테이너 환경에서도 Cluster Autoscaler나 Karpenter를 활용해 "Worker Node 수"를 동적으로 조정할 수 있습니다.

즉, Auto Scaling과 같은 메커니즘을 효율적으로 구성하면 (컴퓨팅을 포함한) 자원의 사용량을 지속적으로 최적화할 수 있습니다. 하지만 이런 파이프라인을 만들고 정책을 설계하는 과정마저 귀찮다면 어떻게 할까요? 그냥 모든 것을 서비스에 위임하고 자원의 사용량도 알아서 조정하게끔 누군가에게 위탁하는 방법은 없을까요? 네, 있습니다. 그 방법은 다음 주제에서 살펴보도록 하겠습니다.

Auto Scaling의 완전 자동화, Serverless 서비스

컴퓨팅 자원의 사용량을 최적화하는 세 번째 기법은 Serverless입니다. 클라우드 환경에서 "Server-less"는 참 다양한 의미로 쓰이는데요. AWS Lambda 같은 FaaS(Function as a Service) 서비스를 지칭하기도 하고, Amazon SQS나 SNS처럼 사용자 레벨에서 서버 자원을 식별할 수 없는 서비스를 뜻하기도 합니다. 또 Aurora Serverless처럼 (Server 기반 타입을 지원함과 동시에) 새로운 Serverless 옵션을 추가적으로 제공하는 서비스를 말하기도 하죠.

그렇다면 위에서 말한 Serverless 서비스들은 정말 물리적인 Server(또는 컴퓨팅 자원)가 없는 것일까요? 물론 있습니다. 다만 사용자에게 해당 서버 자원의 가시성을 제공하지 않을 뿐입니다. 그럼 수요에 맞게 해당 자원을 확장하고 축소하는 작업은 누가 하는 것일까요? 서비스가 알아서 해줍니다. 다시 말하면, 서비스 자체적으로 "확장/축소 메커니즘이 내장"되어 있습니다. 오늘 두 번째 주제인 Auto Scaling 관점으로 본다면, Auto Scaling 기능은 물론이고 해당 기능에서 정의해야 하는 확장/축소 기준값까지도 내장되어 있는 셈입니다.

결과적으로 Serverless 계열의 서비스들은 "사용자가 자원의 Scaling 과정에 관심을 갖지 않아도" 알아서 수요에 대응하게 되어 있습니다. 즉, 컴퓨팅 자원의 사용량을 조정(=최적화) 한다는 관점에서 사용자가 신경 쓸 것이 거의 없습니다. 그러므로 컴퓨팅 자원의 크기를 결정하고, 자원의 확장-축소 기준을 수립하고, 결과를 모니터링하고 정책을 최적화하는 이런 일련의 과정들마저 관리 비용이라고 생각한다면 Serverless의 선택은 훌륭한 대안이 됩니다. 특히 일부 서비스들은 Server 타입과 Serverless 타입 두 가지를 동시에 제공하기 때문에, 사용자의 선택지가 있다는 점에서 더더욱 그렇습니다.

위 대상은 Server 타입과 Serverless 타입을 동시에 지원하는 AWS 서비스들입니다. 주로 DB 계열의 관리형 서비스가 많고요. 예를 들어 Server 타입은 "m5.large의 시간 단가는 100원" 같은 방식으로 과금 구조가 되어 있지만, Serverless 타입의 경우 고정된 서버 자원이 없기 때문에 동일한 구조로 비용을 매길 수 없습니다. 그래서 보통 과금의 기준이 되는 새로운 단위(Capacity Unit)가 등장하고요. 이 값은 고정 값이 아니라 수요에 대응하는 동적인 값입니다. Aurora Serverless는 ACU(Aurora Capacity Unit), DMS Serverless는 DCU(DMS Capacity Unit) 같은 별도 단위가 정의되어 있고요. 서비스별 요금 페이지를 자세히 살펴보시면 1 Capacity Unit이 어느 수준의 자원 레벨인지를 추상적으로 정의해 놓았습니다.

그렇다면 다시 원점으로 돌아와서 "컴퓨팅 자원의 사용량 최적화 관점"에서 이런 Serverless 계열의 서비스들은 어떤 상황에서 유용할까요? 예를 들어 DB 마이그레이션 서비스인 DMS를 사용한다고 생각해 봅시다. DMS는 Server 타입과 Serverless 타입을 동시에 지원합니다. 만약 2개의 DB 클러스터가 있고 각 클러스터 간에 CDC(Change Data Capture) 복제 등이 설정되어 있어 비슷한 부하의 Task가 지속적으로 반복된다면 어떤 타입이 적합할까요? 이 경우는 보통 Server 유형이 적합합니다. 반대로 Task가 매일 새벽 1시에 하루 한 번 돌아가는 짧은 배치 형태로 구성되어 있다면 어떨까요? 이 경우는 새벽 1시부터 몇 분간을 제외한 나머지 시간에는 굳이 복제 서버를 띄워 놓을 필요가 없기 때문에, Serverless 유형이 (비용 관점에서) 유리합니다. 가끔 그 배치 작업에 부하가 좀 많이 걸려도 괜찮을까요? 네, 괜찮습니다. Serverless 자원이 알아서 수요에 대응하기 때문입니다.

위처럼 Server 타입과 Serverless 타입 모두를 제공하는 서비스의 경우, 사용자는 이 중 어떤 형태로 자원을 구성할지를 선택해야 합니다. 단순히 "자원의 사용량을 관리할 필요가 없다"라는 측면에서는 Serverless 타입이 좋지만, 해당 타입이 항상 장점만 있는 것은 아닙니다. 예를 들어 Server 타입에서 지원하는 API를 Serverless 타입에서는 지원하지 않는다거나, Server 타입에서 지원하는 관리 기능을 Serverless에서 지원하지 않는 경우도 있기 때문입니다.

전통적인 방식으로 자원의 사용량을 모니터링하고 비용을 예측한다는 관점에서도 Serverless 유형은 태생적인 약점을 갖고 있습니다. Server 타입은 정해진 자원의 스펙이 있고(=단가가 있고), 정해진 범위 내에서 사용량을 조절할 수 있기 때문에 월 비용을 예측(통제) 하는 것이 비교적 쉽습니다. 반면 Serverless 타입은 비용 예측이 쉽지 않고, 자원의 사용량을 통제하는 것도 상대적으로 어렵습니다. 그리고 24/365 기간에 비슷한 부하로 동작하는 워크로드의 경우, 총비용을 계산해보면 Serverless 타입이 Server 타입에 비해 대부분 비쌉니다. 단가 정책이 그렇게 설계되어 있습니다.

이번 장을 요약하면 다음과 같습니다. 부하 패턴이 상대적으로 작고 불규칙하며, 관리 포인트를 최소화하고 싶은 경우 Serverless 유형을 한 번쯤 검토해 볼 필요가 있습니다. 반면 부하 패턴이 상대적으로 크고 규칙적이며, 다양한 관리 기능을 풍부하게 활용해야 한다면 Server 유형이 적합한 선택입니다.

마치며

오늘은 컴퓨팅의 사용량을 최적화하는 기법에 대해 알아보았습니다. 오늘 다룬 3개의 주제는 모두 같은 목적을 갖고 있습니다. 컴퓨팅 자원의 사용량 - 즉 구동 시간을 최소화하는 것입니다. 좀 더 정확한 표현으로는 "서비스 수요에 대응함과 동시에 구동 시간을 최소화“ 해야 합니다. 이를 위해서는 어떤 기준이 필요하고 그 기준을 충족하기 위한 기술적인 방법론(자동화 등)도 함께 준비해야 합니다.

첫 번째 주제인 스케줄링에서는 "필요 없을 때 컴퓨팅 자원을 선택적으로 꺼두는 것"이 얼마나 효과적인지를 계산해 봤습니다. 그리고 이런 스케줄링 작업을 자동화하는 솔루션 예시도 살펴봤고요. 두 번째 주제인 Auto Scaling에서는 수평적인 확장/축소를 자동화하는 개념을 다뤘습니다. 단일 지표를 기준으로 복수의 컴퓨팅 자원을 배분하는 기능이 곧 Auto Scaling이기 때문에, 스케줄링의 다차원 확장 개념으로 짚어 봤고요. 여기서 한발 더 나아가 세 번째 주제에서는 Auto Scaling 기능 자체를 내재화한 Serverless 계열의 서비스를 다루고, 어떤 상황에서 어떤 타입의 자원이 적합한지도 간단히 살펴봤습니다.

한편 컴퓨팅 자원의 사용량을 최적화하려고 할 때 좀 더 복합적인 고민이 필요한 경우도 있습니다. 보통은 컴퓨팅 자원의 단가와 사용량은 독립적인 변수인 경우가 많은데요. "비용 = 단가 x 사용량"이니 비용을 최소화하기 위해서는 "단가 최적화 작업"과 "사용량 최적화 작업"은 따로따로 진행하면 됩니다. 하지만 단가와 사용량이 서로 영향을 끼치는 경우도 있는데요. Lambda 함수의 스펙(=단가)와 실행 시간(=사용량)이 그렇습니다. Lambda 함수의 스펙을 올리면 보통 실행 시간이 줄고 스펙을 줄이면 실행 시간이 늘어납니다. 따라서 2차 함수처럼 두 변수를 곱했을 때 최솟값이 되는 지점을 찾아야 합니다. 이때 Lambda Power Tuning 같은 시뮬레이션 툴을 활용할 수 있습니다.

• 출처: https://aws.amazon.com/blogs/compute/optimizing-your-aws-lambda-costs-part-1/

복합적인 고민이 필요한 또 하나의 사례는 스케줄링과 약정의 상관관계입니다. 앞에서 예를 들었던 DEV/STG 환경의 스케줄링을 생각해 봅시다. 스케줄링이 적용된 환경에 Savings Plan이나 Reserved Instance 같은 약정 프로그램을 적용하면 어떻게 될까요? 약정은 기본적으로 매시간마다 적용할 수 있는 capacity가 있고, 해당 시간에 on demand 자원이 있으면 적용 / 없으면 버려지는 특성을 갖고 있습니다. 따라서 스케줄링 정책에서 자원이 on인 상태일 때는 문제가 없지만, off인 상태일 때는 약정분이 사용되지 못하고 버려집니다. 이는 스케줄링의 효과(또는 약정의 효과)를 반감시키는 부작용을 낳기 때문에, 두 가지 전략을 동시에 사용할 때는 전체적인 이득과 절충 지점을 정밀하게 계산해 볼 필요가 있습니다.

컴퓨팅의 사용량을 최적화하는 회차에서 왜 "미사용 자원을 정리" 하는 내용은 다루지 않는지 궁금해하시는 분이 있을지 모르겠습니다. 현재 사용하지 않고 앞으로도 사용할 계획이 없는 미사용 자원을 개별적으로 찾아내서 사용량을 영원히 0으로 만드는(삭제하는) 일은 물론 비용 최적화 관점에서 좋은 전략입니다. 다만 이 주제는 9회차 특집 편에서 좀 더 자세하게 다룰 예정입니다. 미사용 자원의 기준을 정하고 이를 찾아서 삭제하는 전략은 컴퓨팅뿐만 아니라 스토리지, 네트워크 관점에서도 함께 다룰 수 있는 주제이기 때문입니다.

다음 연재 일곱 번째 시간의 주제는 스토리지의 사용량을 최적화하는 법입니다. 클라우드 환경에서 스토리지의 (단가가 아닌) 사용량을 줄이기 위한 방법은 어떤 것들이 있을까요? 데이터를 관리한다는 측면에서 실제 스토리지에 더 적은 데이터를 쌓기 위한 방안을 한 번쯤 떠올려 보시면 좋을 것 같고요. 자세한 정답지는 7회차에서 만나 뵙도록 하겠습니다~! 그럼 끝.

 

▶ 더 읽어보기

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

• 클라우드 비용 최적화 로드맵 #2 - 비용을 자세히 보기 위한 준비

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

• 클라우드 비용 최적화 로드맵 #4 - 스토리지의 단가를 최적화하는 법

• 클라우드 비용 최적화 로드맵 #5 - 네트워크의 단가를 최적화하는 법

 

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