Serverless Architecture

과거 IDC 기반에서는 단순한 로직하나를 수행하기 위해서도, Hardware가 필요했고, 이를 유지하고 관리하기 위한 리소스들 또한 필요로 했습니다. Cloud 세상이 오면서 새로운 페러다임이 생겨나고 그로 인해 많은 변화가 일어났다고 생각합니다. Cloud 세상이 도래하고 생겨난 Keyword중 하나 Serverless인 것 같습니다. 실제 Server가 존재하지 않고, 비지니스 로직만 구현하여 해당 프로그램이 특정 조건에 실행하도록 지정해두면, 실제 수행되는 만큼의 비용만 부담하는 AWS의 서비스 Lambda도 그중 하나일 것입니다.
개발자 입장에서는 Server에 대한 고민을 할 필요가 없어져 좋죠.
하지만 실제 Code가 수행된다는 건 CPU, RAM등의 Hardware리소스가 필요로 합니다.
이는 Lambda가 트리거될 때 AWS내부의 컨테이너 환경에서 동작된다고 합니다.

이번 포스트에서는 내가 사용해본 AWS Lambda 함수에 대해서 간략한 특징 및 사용법을 정리해두고자 합니다.

AWS Lambda Runtime

Node.js, Python, Ruby, Java, Go등(참고) AWS Lambda는 실제 여러 언어의 Runtime 환경을 제공합니다. 구현이 가능한 언어로 비지니스 로직을 작성하면 됩니다.

기본 구성

AWS에서 Lambda 함수를 생성하면 기본적으로 위와 같은 구조도가 보입니다.
아래에 Layer는 여러 Lambda 함수를 만들게 될 때, 공통 모듈 부분으로 합칠 수 있는 경우 사용하는 기능입니다. (실제 저도 사용해보진 않음)

왼쪽은 Trigger입니다. 해당 Lambda 함수가 실행될 조건을 설정하는 곳 입니다.
나는 S3에 특정 이벤트(파일 생성, 삭제)등이 발생했을 때나 SQS를 통해 메시지 큐에 이벤트 메시지가 등록될 때 등에 활용해본 경험이 있습니다. 정말 로직만 구현하면, 특정 조건에서 원하는 기능을 수행하기에 간편합니다. 어떤 트리거를 이용하느냐에 따라 전달되는 Parameter의 포멧도 조금씩 달라집니다. 실제로 AWS 서비스에서 많은 다양한 곳에 Lambda 트리거가 가능합니다. S3 Webhosting에서도 Routing시 전처리기로도 활용이 가능하며, AWS에서 제공하는 API gateway에 붙이거나, Loadbalancer 뒤에 실제 트레픽을 처리하는 비지니스 로직을 붙이는 걸로도 응용이 가능합니다.

오른쪽은 Destination 결과를 전달하는 방법들을 지정할 수 있는 데, 사실 Lambda를 수행하는 Role이 권한만 갖고 있다면 특별히 해당 Interface를 통해 지정을 하지 않고, AWS SDK를 통해서 어떤 형태로든 원하는 바를 수행할 수 있습니다.

런타임에 참조할 수 있는 환경 변수를 세팅 해두는 것이 가능합니다. Code와 환경변수를 분리하는 용도로 사용하여, Code 재배포 없이 특정 변수를 통해 동작을 변화시킬때 유용한 것 같습니다.
또한, Code안에 보안에 관련된 키 값들이 참조가 되어야 한다면, 해당 Env 변수에 KMS를 이용하여 encrypt 값을 전달하는 것도 가능하며 실제 동작시 decrypt해서 사용하는 형태로도 이용할 수 있습니다.

VPC를 지정하게 되면, 정해진 VPC 내부의 Subnet 환경에서 동작하도록 해줄 수 있으며 이 경우 Lambda 수행 과정에서 외부로의 접근을 시도하게 될 때, 외부로 나가게 되는 NAT IP를 지정할 수 있으며 수신 측에서의 Whitelist를 지정하는 용도로 사용될 수 있을 것 같습니다.
또한 특정 Subnet 안의 다른 서비스에 접근할 때도 보안관련 처리를 하기에 용이하게 구현이 가능합니다.

제가 생각하는 Lambda의 가장 아쉬운 점입니다.
Resource 제한을 선택해야합니다. 특히 타임은 현기준 15분이 max이며, 활용하기에 좋은 배치성 업무라도 소요시간이 많이 필요하다면 Lambda를 쓰기에는 어려운 조건이 될 수 밖에 없을 것 같습니다.

배포 Version 그리고 Alias

Lambda 함수는 코드를 반영하는 방법은 다양합니다. 직접 Upload를 할 수도 있고, S3에서 코드를 가져와서 사용할 수 있으며 언어에 따라서는 Console에서 직접 코딩을 할 수도 있습니다.
어떤 방식이든 Publish를 통해서 버전을 배포하면 ARN에서 postfix를 지정함으로써 원하는 버전의 트리거가 가능합니다.

위의 ARN은 ----:release라고 되어있는 데, 이 release는 버전이 아니라 Alias라고 하는 녀석 입니다.

여기서 Version과 Alias 2개의 차이점을 짚고 넘어가보면...
Publish를 하게 되면 지정한 Code가 특정 정해진 버전으로 배포가 됩니다.

배포가된 버전은 위의 설명과 같이 ARN 뒤에 명시함으로써 지정해서 수행이 가능합니다.
예를 들어 AWS의 Loadbalancer 뒤에 우리가 원하는 3번 버전을 지정했다고 한다면,
4번 버전을 배포하고나면 어떻게 될까요? Loadbalancer는 여전히 지정된 3번 ARN을 통해서 Call을 해줍니다. 그럼 배포때 마다 트리거 포인트를 수정해야하는 일이 발생합니다. 이때 사용할 수 있는 것이 Alias... 즉 별칭인 것 입니다. 실제 Call하는 측에서는 Alias를 지정해두는 것이 좋습니다.

release라는 Alias는 버전1로 Routing되도록 설정했으며 이는 한 포인트에서 쉽게 전환이 가능 합니다.

위와 같이 2개의 버젼에 Weight를 주어서 원하는 비율로 A/B 테스트도 가능 합니다.

Alias를 활용하면 상당히 유연하게 Production 환경에도 테스트 적용이 가능하다는 장점이 될 수 있습니다.

마치며...

가볍게 특정 기능을 서비스에 추가하거나 혹은 Infra관리에 자동화하고 싶은 포인트가 있을 경우 Lambda를 많이 활용하고 있습니다. 다양한 응용법과 기능을 알게될수록 정말 매력적인 기능이라고 자신있게 권유할 수 있을 것 같습니다.

실제 웹서비스도 Static파일은 S3를 통해 Hosting하고 DB로 접근하는 Backend를 Lambda를 통해서 구현하게되면, EC2 없이도 원하는 서비스를 제공할 수 있게 됩니다.

EC2가 없다라는 것은 항상 구동 중인 Computing resource가 없다는 의미가 되고 서비스 운용 비용에서 많은 이득을 볼 수 있는 방향이 됩니다.

물론 트레픽에 따라 돈을 받는 가격 책정 방식이기에 일정 수준 이상의 트레픽을 처리해야하는 서비스라면 EC2 베이스가 더 저렴할 수 있는 케이스도 생길 수도 있다고 판단됩니다.