[Re2020] 오랜만에 Lambda를 찾아온 한 남자의 최신 업데이트 탐방기
안녕하십니까. 이번 포스팅에서는 리인벤트에서 발표된 Lambda 관련 업데이트 몇가지를 한데 모아서 살펴보려고 합니다. 개수로는 4-5개 정도 되는 내용인데요. 옴니버스식으로 내용을 쭉 나열하기에는 너무 재미가 없을 것 같아서, 새로운 컨셉으로 소개를 해보려고 합니다. 한 남자가 Lambda 서비스를 몇년전에 사용해봤다가, 오랜만에 Lambda를 접하면서 그동안 업데이트가 이렇게 많았음을 깨닫는 감동적인 컨셉인데요. 물론 이렇게 새로운 컨셉으로 해도 재미가 없을것 같긴 합니다.
몇년전 한 남자는 AWS 플랫폼에서 아주 작은 쇼핑몰을 운영하고 있었습니다. Front-End는 따로 구현되어 있었고, Back-End 중 사용자별 장바구니/찜 내역은 DynamoDB에 Item 형태로 저장했습니다. 그리고 새로운 Item이 등록되면 DynamoDB Stream을 통해 관련된 후속 작업(재고 추정, 검색엔진 연동 등)을 Lambda 함수로 처리했습니다. 얼마뒤 매출이 줄어든 쇼핑몰은 망했고, 오랜만에 다시 AWS 관리콘솔을 찾아온 남자는 추억에 젖어 예전 구성을 그대로 복기하기 시작했습니다.
우선 예전에 만들어둔 Lambda 함수를 생성하려고 관리콘솔의 “Create Function”으로 들어간 순간 새로운 선택지가 하나 더 추가되어 있었습니다. Container Image라고? 예전에는 수동으로 올리거나 Serverless App Repository를 통해 함수를 가져와서 재사용하곤 했는데, 이제는 컨테이너 이미지 형태로 말려있는 것도 들고와서 쓸 수 있는 모양입니다. 문서를 좀 찾아보니, Lambda용 기본 이미지(base image)를 기반으로 원하는 부분을 덧붙여 패키징한 후 ECR 같은 레포지토리에 올려 쓰면 된다네요. 람다 함수를 등록하고 공유하는 방식과 범위에 선택지가 늘어난 셈입니다.
쇼핑몰 관리자 페이지에는 현재 사용자 장바구니에 등록된 물품의 종류와 갯수를 1분 단위로 보여주는 대시보드가 있었습니다. 이 부분을 구현하기 위해 DynamoDB Stream을 사용했는데요. 문제는 Lambda 함수가 Stateless한 서비스라 일정 시간 간격으로 데이터를 수집하고 타임스탬프를 끊고 하는 작업을 별도로 구현해야 했습니다. 그런데 이번에 람다 함수에 트리거로 DynamoDB를 연결하려고 했더니, 새로운 옵션이 보이네요? 바로 Tumbling window duration이라는 항목입니다.
찾아보니, 스트리밍 데이터의 상태를 지정한 시간 단위로 끊어주는 기능이네요. 즉, 해당 옵션값을 60초로 설정하면 60초간 모이는 스트리밍 데이터를 하나의 Window 단위로 다룰 수 있게 됩니다. 그럼 Lambda에서는 그냥 그 값들을 한데 모아 유의미한 값을 도출하는 로직만 구현하면 되는 것이지요. 적당한 예일지 모르겠지만, AWS의 EC2 Autoscaling을 생각해봅시다. 해당 그룹에 속한 EC2 인스턴스의 평균 CPU값을 구할때 사용자는 어떤 인스턴스가 해당 그룹에 속해 있고, 각 CPU값이 얼마인지 따로 고민할 필요가 없습니다. 왜냐하면 CloudWatch 내에서 Dimension이라는 단위로 값들이 이미 Group화되어 있기 때문이죠. 이번 람다 업데이트도 마찬가지입니다. 서비스 레벨에서 애초에 각종 데이터값을 구분지어 주면, 어플리케이션 레벨에서 별도로 고민해야 할 부분이 줄어듭니다.
Lambda 함수를 등록하고 트리거를 등록한 후에, 람다가 실행되는 환경의 스펙을 지정하는 부분을 살펴보니 또 놀라운 것이 하나 있었습니다. 기존에는 메모리를 3GB 정도까지 할당할 수 있었던 것으로 기억하는데, 10GB로 제한이 늘었네요? 참고로 이 쇼핑몰에는 물품 상세를 동영상으로 보여주는 기능이 있었는데요. 해당 영상을 사용자에게 노출하기에 앞서 사전에 커스텀한 트랜스코딩 작업이 필요했습니다. 예전에는 이 작업을 Lambda로 구현해 보려다가 제공하는 스펙에 한계가 있어서 EC2에서 해당 작업을 처리해왔는데요. 이 로직도 Lambda로 구현해 볼 수 있겠다는 생각이 들어서 테스트를 해볼 참입니다. 참고로 찾아보니 할당한 메모리 크기에 비례해서 vCPU도 최대 6개까지 할당(1,769MB 당 vCPU 1개)된다고 하네요. 예전에 Lambda 함수의 Timeout이 5분에서 15분으로 늘어났을때도 활용성이 급격히 좋아졌었는데, 이번엔 수평적이 아닌 수직적으로도 더 넓은 선택지를 제공하네요.
마지막으로 Lambda 함수의 실행로그를 문득 살펴보다가, 또 새로운 사실을 발견했습니다. Lambda가 실행된 시간이 Duration으로 측정되고, 실제 과금은 100ms 단위로 처리되었던걸로 기억하는데 이제는 1ms 단위로 처리되는 모양입니다. (예를 들어 실행 시간이 322.55ms면 기존에는 400ms 만큼 과금되었는데, 이제 323ms 만큼 과금됨) 일반적으로 생각하면 과금 단위가 작아지면 작아질수록, 사용자는 실제 사용치에 가깝게 과금이 되기 때문에 유리합니다. 예전에 EC2 인스턴스 요금이 1시간 단위에서 1초로 바뀌었을때도 마찬가지였던 기억이 나네요. 1시간 1초를 사용했을때 2시간 요금(7200초)을 내다가 바뀐 후에는 3601초 요금만 냈으면 되었으니까요.
자, 여기까지 여러분은 무리한 설정을 바탕으로 한 최신 Lambda 업데이트 내역을 한꺼번에 살펴보셨습니다. 소개드린 내용들은 각기 다른 범주의 것들이지만, 공통점이 있다면 모두 Lambda의 활용성을 개선하는 업데이트라는 점입니다. 활용성이 개선되었다는건 다시 말해 Lambda 레벨에서 처리할 수 있는 것이 늘어난다는 의미가 되구요. 기존에 Lamdba가 가지고 있는 여러가지 장점들(예를 들어 타 AWS 서비스와의 연동 / 편리한 자원 관리 / 낮은 과금 등)을 그대로 가져가면서 각종 어플리케이션 로직들을 원하는만큼 떼어낼 수 있다는 얘기가 됩니다. 보다 자세한 내용은 아래 링크를 확인하시구요. 앞에서 소개드린 업데이트 순으로 배열되어 있으니 참고하세요.
https://aws.amazon.com/about-aws/whats-new/2020/12/aws-lambda-now-supports-container-images-as-a-packaging-format/
https://aws.amazon.com/about-aws/whats-new/2020/12/aws-lambda-easier-build-analytics-amazon-kinesis-amazon-dynamodb-streams/
https://aws.amazon.com/about-aws/whats-new/2020/12/aws-lambda-supports-10gb-memory-6-vcpu-cores-lambda-functions/
https://aws.amazon.com/about-aws/whats-new/2020/12/aws-lambda-changes-duration-billing-granularity-from-100ms-to-1ms/
https://aws.amazon.com/about-aws/whats-new/2020/12/aws-lambda-launches-checkpointing-for-amazon-kinesis-and-amazon-dynamodb-streams/
최신 댓글