Lambda 대 Step Functions: 비용과 성능의 싸움

Lambda 대 Step Functions: 비용과 성능의 싸움

 

Lambda보다 Step Functions를 사용하려는 큰 움직임으로 인해 "어느 것이 더 비용 효율적"인지 궁금할 수 있습니다. 대답은 당신을 놀라게 할 수 있습니다.

Wiki에서 이미지 · Pixabay의

지난 몇 주 동안 표준 개발 프로세스의 일부로 Step Functions로 전환하는 방법에 대한 분석을 수행했습니다. 완전히 비동기식 워크플로로 "스토리지 우선"으로 이동하거나 Express 상태 시스템과 완전히 동기식으로 전환할 수 있는 옵션이 있습니다.

둘 다에 대한 사용 사례가 있지만 프로덕션 개발에 대한 합의는 하이브리드 접근 방식을 따릅니다. 기본 작업 세트를 동기적으로 수행하고, 유효성 검사 및 ID 생성과 같은 그리고 나머지 처리를 비동기적으로 시작합니다. 그런 다음 WebSocket을 사용하여 워크플로가 완료되면 사용자에게 알립니다.

개발자는 본질적으로 호기심이 많습니다. 많은 사람들이 LinkedIn에서 내 게시물에 응답했고 트위터 Lambda와 Step Functions 간의 비용 차이가 무엇인지 묻습니다. 결국, 나는 람다를 완전히 버리기 위해 투구를 하고 있었습니다. 타당한 질문 같습니다.

지갑에 미치는 영향을 파악하려면 이러한 각 서비스가 청구되는 방식을 결정해야 합니다. AWS에는 서버리스 서비스 요금을 부과하는 여러 가지 방법이 있지만 투명성과 전체 숨겨진 비용 없음 물건.

AWS Lambda와 AWS Step Functions의 비용 및 성능에 대해 자세히 살펴보겠습니다.

오늘 우리는 세 가지 다른 접근 방식을 비교할 것입니다. 람다, 익스프레스 워크플로그리고 표준 워크플로 단계 기능과 함께. 다음은 각 서비스의 사용 요금이 어떻게 청구되는지에 대한 표입니다.

가격은 미국 동부 1 지역을 기준으로 합니다.

Lambda가 소비하도록 허용된 메모리 양을 조정할 수 있으므로 consumed GB/sec 구성된 항목에 따라 다를 수 있습니다. Step Functions를 사용하여 소비하는 메모리 양은 다음 공식으로 계산할 수 있습니다.

50MB + 상태 머신 정의 크기 + 실행 데이터 크기 x 병렬 또는 매핑 단계 수

위에서 계산한 숫자를 가져옵니다. 가장 가까운 64MB로 반올림 그리고 그것을 워크플로우의 평균 지속 시간으로 나누어 익스프레스 워크플로우에 대해 소비된 GB/초를 구합니다.

보시다시피 익스프레스 워크플로는 Lambda와 유사하게 청구됩니다. 그러나 표준 워크플로는 완전히 다릅니다. 청구 금액은 상태 전환 횟수에만 따릅니다.

Lambda가 익스프레스 워크플로와 어떻게 비교되는지 알아보려면 성능에 대한 측정값을 얻어야 합니다.

동기 비교

익스프레스 워크플로를 구축하는 대안은 동일한 작업을 수행하는 거대한 Lambda를 사용하는 것입니다. 또는 Lambda 대상을 사용할 수 있지만 이는 비동기식이며 우리가 수행하는 비교에 직접 적용되지 않습니다.

벤치마크의 경우 익스프레스 상태 머신에 대한 내 게시물의 API 키 워크플로를 사용합니다.

API 키 생성 워크플로

보다 포괄적인 비교를 제공하기 위해 Node.js의 AWS SDK v2와 AWS SDK v3 모두에 작성된 동일한 Lambda에 대해 익스프레스 워크플로를 테스트할 것입니다.

각 Lambda는 다음을 통해 aws-lambda-power-tuning을 거쳤습니다. 알렉스 카살보니 성능에 최적화되었습니다.

테스트를 위해 각 끝점은 1000번 실행됩니다. 결과는 평균 실행 시간을 얻기 위해 평균을 냅니다. 평균을 구하면 비용 분석을 수행할 수 있습니다.

성능 테스트 결과

보시다시피, 전반적으로 승자는 Step Functions를 사용한 익스프레스 워크플로입니다.! Lambda를 사용하면 가장 느린 시간은 콜드 스타트 때문일 수 있습니다. 그러나 콜드 시작 시간에 대한 비용은 청구되지 않으며 함수 실행 시간일 뿐입니다.

Step Function 경로를 사용할 때의 좋은 이점은 콜드 스타트가 없다는 것입니다(Lambda를 상태로 사용하지 않는 한). 직접 SDK 통합을 사용하면 상태 머신이 놀라운 속도로 실행됩니다.

다시 말하지만, 이러한 Lambda는 최적의 성능을 위해 조정되었으므로 가능한 한 빨리 실행되도록 설계되었습니다. Step Functions와 비교할 때 성능은 거의 무시할 수 있습니다.

익스프레스 워크플로에 대한 직접 비용 비교를 위한 수학 100만 호출당 이다:

1.00 + (가장 가까운 64MB/1024MB로 반올림된 64 소비 메모리) x 1M 호출 x 1.8초 평균 지속 시간(다음 100ms로 반올림) x .00001667 = $2.87

Lambda의 경우 AWS SDK v3의 실행 시간을 단축하고 다음과 같이 100만 호출당 청구 비용을 계산할 수 있습니다.

.2 + (평균 88MB 메모리 사용/1024MB) x 1M 호출 x 1.881초 평균 지속 시간 x .00001667 = $2.89

결과를 종합해보면 다음과 같은 놀라운 수치가 있습니다.

이상하게도 AWS SDK v2 함수는 가장 적은 메모리를 사용하여 백만 호출당 비용을 낮췄습니다. 어느 쪽이든, 100만 건당 비용은 몇 센트에 불과합니다. 매우 흥미로운!

비동기식 비교

표준 워크플로를 고려하면 비용을 다른 방식으로 분할할 수 있습니다. Lambda 함수에서 실행 중인 비동기 프로세스가 있는 경우 처리가 15분 내에 완료되도록 보장하거나 처리를 계속하기 위해 다른 Lambda를 시작해야 합니다(대상을 통해 자신의 상태 머신을 효과적으로 구축).

이 접근 방식의 대안은 EC2 인스턴스를 프로비저닝하고 시스템 가동 시간 비용을 지불하거나 Step Functions 및 전환당 지불을 사용하여 표준 워크플로를 생성하는 것입니다.

예를 들어 Textract를 통해 이미지를 실행하여 텍스트를 가져오고 결과를 S3에 드롭한 다음 Rekognition 작업을 실행하여 이미지에 포함된 객체를 식별하고 최종적으로 통합된 결과를 DynamoDB에 저장하는 이미지 처리 작업을 예로 들어 보겠습니다.

Lambda를 사용하면 이는 다소 비쌉니다. 약 2분 안에 작업을 완료하고 모든 처리를 완료할 수 있다고 가정합니다. 1024MB의 메모리를 프로비저닝하고 평균적으로 256MB의 처리 능력을 사용했다면(큰 이미지임) 다음 공식을 보고 있습니다. 100만 호출당:

.20 + (1백만 x 120초) x (256MB/1024MB) x .0000166667 = $500

동일한 작업을 수행하는 상태 시스템이 완료하는 데 15개의 상태가 필요하다고 가정해 보겠습니다. 작업을 시작하고 완료될 때까지 루프에서 상태 확인을 수행합니다. 100만 회 호출 비용을 계산하는 공식은 다음과 같습니다.

100만 x 15 x .000025 = 375달러

이 경우 워크로드를 표준 상태 머신으로 실행하는 것이 월별 비용이 조금 더 저렴할 것입니다.

직접 비용을 이야기할 때 Step Functions vs Lambda를 선택하는 한 무시할 수 있는 것처럼 보입니다. 하지만 고려할 때 총 소유 비용, 이야기가 약간 바뀝니다. 서버리스 애플리케이션 리팩토링에 대한 이전 게시물에서 논의한 바와 같이, 문자 그대로 비용이 드는 금액은 계산할 때 단지 하나의 요소일 뿐입니다. 사업 비용.

클라우드에서 코드 조각을 실행하는 데 월 1000달러의 비용이 들지만 유지 관리가 잘 되지 않아 버그를 수정하는 데 개발자 시간이 20시간 걸린다면 비즈니스 비용이 훨씬 더 많이 듭니다.

반면에 클라우드에서 동일한 코드를 실행하는 데 월 2000달러의 비용이 들지만 유지 관리 용이성으로 인해 개발자 시간이 버그를 수정하는 데 4시간밖에 걸리지 않는다면 전체 비즈니스 비용이 낮아집니다.

비용은 달러와 센트보다 훨씬 많습니다.

"모든 경우에 적용되는" 솔루션은 없습니다. 한 팀에서 효과가 있는 것이 다른 팀에서는 효과가 없을 수 있습니다. 서버리스 모험을 할 방법을 결정할 때 이것을 고려하십시오.

로 전환하여 코드를 통한 구성 Step Functions를 사용하는 모델에서는 코드 실행 책임을 클라우드 공급업체에 맡깁니다. 소프트웨어 회사로서의 책임이 적을수록 더 높은 투자 수익을 얻을 수 있습니다.

제 사용 사례의 경우 동기 및 비동기 실행 모두에 Step Functions가 더 적합합니다.

일부 상태 머신은 잘 설계된 일부 Lambda 함수보다 용량이 커지고 비용이 훨씬 더 많이 증가할 수 있기 때문에 항상 그런 것은 아닙니다.

균형을 찾으십시오.

다음 주요 프로젝트에 착수하기 전에 비용 추정을 하는 데 시간을 할애할 가치가 있습니다. 복잡한 워크플로를 단계 기능 다이어그램으로 시각화하면 도움이 될까요? 아니면 팀워크가 코드를 살펴보는 것이 더 낫습니까?

Step Functions는 미래에 판도를 바꾸는 서비스가 될 것입니다( 젠장, 벌써!). 채택률이 증가하고 기능이 계속 성장함에 따라 계속해서 개선되고 기존의 "Lambda 개발"은 먼지가 될 것입니다.

Step Functions를 통해 더 나은 추적 가능성, 더 낮은 책임 및 멋진 디자이너를 얻을 수 있습니다. 일부 시나리오에서는 Lambda보다 저렴한 서비스로 보이기도 합니다.

아직 시도하지 않았다면 시도해 보시기 바랍니다. 보고 싶은 내용이 마음에 드실 수도 있습니다.

즐거운 코딩!