비용 측면에서 워크로드에 AWS 컴퓨팅 플랫폼을 선택하는 것은 쉬운 일이 아닙니다. 나는 내가 작업하는 프로젝트 중 하나에 대한 계산을 수행했고 내 결과를 공유하기로 결정했습니다. 이 기사에서는 비교를 수행하는 방법을 설명하기 위해 매우 높은 수준의 단순화된 비교를 수행할 것입니다.

모든 컴퓨팅 옵션을 활용하는 데 전문가가 아니므로 의견 섹션을 사용하여 잘못된 가정을 수정하거나 비교 노력에 통합해야 할 개선 사항 및 아이디어를 제안하는 것이 좋습니다.

구성 설정

AWS 가격 계산기 를 사용하여 거의 동일한 컴퓨팅 성능 설정의 월별 서비스 비용을 비교할 수 있습니다. 나는 이미 이것이 까다로운 작업이라는 것을 알았습니다. 각 서비스에는 vCPU 및 메모리뿐만 아니라 네트워크 대역폭 제한, GPU 또는 EBS 볼륨 사용 제한 등 다양한 사양이 있어 선택할 수 있는 고유한 구성 유형이 있습니다.

단순하게 유지하기 위해 1개의 vCPU와 약 2GB의 메모리를 사용하기 위한 요구 사항과 서비스를 비교해 보겠습니다. Lambda의 경우 vCPU는 구성 가능한 메모리 크기와 함께 확장됩니다. Lambda는 메모리 1.769GB당 vCPU 1개를 가져오므 로 이것이 Lambda에 대한 우리의 선택이 될 것입니다. Fargate는 vCPU 수와 메모리 크기를 모두 구성할 수 있으므로 사용 가능한 vCPU 1개와 메모리 2GB를 정확히 선택할 수 있습니다. EC2의 경우 현재 세대 의 EC2 인스턴스 유형 에서 vCPU 및 메모리의 낮은 가치에 대해 우리의 유일한 옵션은 버스트 가능한 성능 을 가진 T 제품군을 사용하는 것입니다.. 이는 기준 CPU 성능 이하의 사용률을 기준으로 인스턴스 가격이 책정되고 사용량이 기준을 초과하면 추가 요금이 발생하므로 또 다른 수준의 복잡성을 가져옵니다. 그러나 이전 세대 인스턴스 유형에서 m1.small 인스턴스 유형은 vCPU 1개와 1.7GB 메모리로 요구 사항에 꽤 잘 맞으므로 T 제품군 인스턴스 유형 대신 사용할 것입니다. 또한 단순화를 위해 다음 옵션은 비교에서 고려되지 않았습니다.

• ARM 아키텍처 CPU
• 비 Linux OS
• 스팟 인스턴스 및 스팟 Fargate 작업
• 데이터 전송 및 저장
• 예약 인스턴스 및 컴퓨팅 절감 계획

직관적으로 EC2가 가장 저렴한 서비스여야 하고 Fargate와 Lambda가 그 뒤를 따릅니다. 그 이유는 각각의 다음 서비스는 이전 서비스보다 인프라 관리가 덜 필요하고 인프라 관리 작업은 AWS에 맡기기 때문입니다. 다음 그래프는 시간 사용률을 기준으로 각 서비스의 월별 가격을 보여줍니다.

EC2 가격은 실제로 가장 낮고 Fargate가 그 뒤를 약간 바짝 추격하는 반면 Lambda 가격은 Fargate의 약 두 배입니다. 워크로드의 실제 요구 사항에 따라 T 제품군 버스트 가능 인스턴스 유형을 활용하면 EC2 가격을 더 낮출 수 있습니다.

청구 및 시작 요소

위에서 본 것처럼 Lambda 실행 비용은 Fargate 및 EC2에 비해 상당히 높습니다. 이제 더 높은 가격에도 불구하고 컴퓨팅을 위해 Lambda를 선택할 수 있는 이유에 영향을 미칠 수 있는 요인을 살펴보겠습니다.

가장 먼저 고려해야 할 사항은 서비스의 청구 간격입니다. EC2는 최소 60초 동안 초당 요금이 청구됩니다. 청구는 인스턴스가 시작될 때 시작되고 인스턴스가 종료되거나 중지되면 중지됩니다. Fargate는 초당 요금이 청구되며 최소 기간은 60초입니다. 이미지를 가져오면 청구가 시작되고 작업이 종료되면 청구가 중지됩니다. 반면 Lambda는 최소 임계값 없이 밀리초 단위로 청구됩니다. 청구는 초기화 또는 핸들러 코드 실행이 시작될 때 시작되고 코드가 반환되거나 종료될 때 중지됩니다.

이것이 드물게 실행되고 수명이 짧은 워크로드에 Lambda가 좋은 선택인 이유 중 하나입니다.

둘째, 새 EC2 인스턴스를 가동하는 데는 새 Fargate 작업 시작과 유사하게 약 1분 이상이 걸립니다. 이에 비해 새 Lambda 인스턴스를 생성하는 데는 해석된 언어가 있는 런타임의 경우 일반적으로 수백 밀리초가 걸리고 컴파일된 언어가 있는 런타임의 경우 최대 몇 초가 걸립니다.

워크로드에 따라 EC2 인스턴스 또는 Fargate 작업을 시작하기 위해 1분도 기다릴 수 없어 인스턴스 또는 작업을 계속 실행해야 하는 경우가 있을 수 있습니다. 일반적으로 새 인스턴스를 시작하기 위해 몇 초를 기다리기 때문에 Lambda의 경우에는 그렇지 않습니다. 또한 CloudWatch 이벤트에 의해 몇 분마다 핑하여 작은 가격으로 Lambda 인스턴스를 따뜻하게 유지할 수 있습니다.

위에서 설명한 두 가지 요소를 강조하기 위해 이제 웹 API 처리기 유형의 컴퓨팅에 대한 서비스 요금 청구를 비교할 수 있습니다. 이 경우 시작 지연이 없고 언제든지 트래픽을 제공할 준비가 되어 있어야 합니다.

시작 문제가 발생하지 않으려면 EC2 인스턴스와 Fargate 작업을 100% 활용해야 합니다. 반면 Lambda 청구는 웹 API에 트래픽을 제공하기 위해 핸들러 코드가 실행되는 실제 시간에 따라 달라집니다. 따라서 동일한 컴퓨팅 성능에 대해 더 높은 가격에도 불구하고 Lambda가 약 40~50%의 시간 동안 활용될 때까지 Lambda를 사용하는 것이 좋습니다. 따라서 Lambda는 빠른 처리 작업(예: DynamoDB에서 데이터 읽기 등과 같은 IO 작업)에 적합합니다.

실제 사례

우리는 프로젝트 중 하나에서 Lambda 함수를 활용하여 API 요청을 처리합니다. 주로 콜드 스타트 ​​지연을 최소화하기 위해 2GB의 메모리 구성을 가지고 있습니다. 그렇지 않으면 더 낮은 구성을 가질 수 있습니다. 4MB가 넘는 .NET 라이브러리를 사용하므로 예를 들어 512MB의 메모리와 2GB 사이의 콜드 스타트 ​​차이가 눈에 띕니다.

Lambda에 대한 트래픽은 지난 몇 달 동안 꾸준히 증가했으며 다른 서비스로의 마이그레이션을 고려해야 할 때인지 확인하고자 합니다.

일일 사용률 메트릭에 따르면 이 함수는 하루 평균 약 250,000회 호출되며 이는 초당 2.89 요청입니다. 평균 실행 시간은 약 250ms입니다. 2.89 곱하기 250은 약 723입니다. 이는 함수가 약 70%의 시간 동안 사용됨을 의미합니다.

보다 세분화된 1분 간격 메트릭은 호출 패턴이 뾰족하지만 일반적으로 로드는 10개 미만의 함수 동시 인스턴스에 의해 처리됨을 보여줍니다.

수집된 메트릭 신호는 Lambda 청구가 최적인 임계값을 통과했음을 나타냅니다. 잠재적으로 동일한 컴퓨팅 성능으로 트래픽을 처리하고 확장할 공간을 확보하기 위해 각각 vCPU 0.5개와 메모리 1GB가 있는 2개의 다중 AZ Fargate 작업을 활용할 수 있습니다. 위의 그래프에 따르면 이렇게 하면 월별 청구 비용이 $53.50에서 $36.04로 줄어듭니다. 적절한 크기의 버스트 가능한 EC2 인스턴스를 활용하고 거기에 컨테이너 또는 앱을 호스팅하여 비용을 더 낮추려고 시도할 수 있습니다. 이것은 물론 실제 응용 프로그램에 대한 검증이 필요한 대략적인 이론적 아이디어일 뿐입니다.

마지막으로, 복잡성과 인프라 관리 비용을 고려하여 원시 청구 비용을 확장해야 한다는 점을 언급하고 싶습니다. 특정 시나리오의 경우 예를 들어 EC2 청구 비용이 Fargate 또는 Lambda보다 몇 퍼센트 낮을 수 있지만 그 차이가 아직 솔루션의 추가된 복잡성을 보상하지 못한다는 것을 의미할 수 있습니다.

우리는 ACTUM Digital 이며 이 글은 Apollo Division의 .NET 기술 책임자인 Milan Gatyas 가 작성했습니다. 부담 없이 연락하세요.