AWS Lambda 살펴보기

serverless 를 활용하려고 하는 환경에서 작성한 코드를 실행하려고 하는 경우 활용할 수 있는 컴퓨팅 자원 중 하나로 AWS Lambda 를 생각해볼 수 있다. 특정 시점에 빠르게 스케일업하고 그 외 사용하지 않는 시점에는 스케일 다운을 해야 하는 경우에 람다 사용을 고려해볼 수 있다. 개발자는 코드만 신경써주게 되면 그 외 메모리, CPU 와 같은 환경은 AWS에서 알아서 관리해주게 된다.

 

Lambda Function

코드를 람다로 실행시키려 하면 가장 먼저 마주하는 것은 Function 이다. 람다에서의 Function 은 애플리케이션을 구현하기 위한 하나의 단위로 취급된다. 즉 특정 이벤트에 반응해 실행되는 코드의 일부 조각이다.

이벤트가 발생하면 Function 에 설정해놓은 handler 함수가 실행된다. 이 때 이벤트가 포함하고 있는 데이터가 handler 함수에 전달되어 이벤트에 따라 원하는 동작을 수행할 수 있게 된다.

 

VPC

모든 람다 함수는 AWS Lambda 서비스가 관리하는 별도 VPC 에서 실행 및 관리된다. 이는 개발자에게 노출되지 않기 때문에 개발자는 이런 부분을 신경쓰기 않고 편하게 코드에 집중할 수 있다는 장점이 생긴다.

 

만약 RDS, EC2 와 같은 리소스가 별도로 생성한 VPC 내에서 사용중이고 여기에 람다가 접근해야 한다면 그에 맞는 처리가 필요할 수 있다. 예를 들어 private subnet 에 존재하는 자원이라면 외부에서 접근이 불가능할 수 있는데 이 경우에는 해당 VPC에 람다를 붙혀서 사용해야 한다.

VPC에 람다 함수를 붙히기 위해서는 네트워크 인터페이스를 생성하고 관리할 수 있는 권한을 람다에 부여해야 한다. 가장 간단한 방법은 AWS 에서 제공하는 AWSLambdaVPCAccessExecutionRole 을 부여해주면 된다.

 

외부에서 오는 접근이 아닌 내부 서비스의 일부분을 처리하기 위해 람다를 사용한다면 VPC와의 통합을 잘 고려해야 한다.

 

비동기 호출

람다도 다른 AWS 서비스와 마찬가지로 비동기로 호출할 수 있다.

만약 람다의 결과를 받아 바로 처리해야하는 경우가 아니라면 비동기 호출을 통해 좀 더 빠르게 요청을 처리할 수 있게 된다.

 

비동기 호출이 전달되면 람다는 해당 이벤트를 event queue 에 넣고 성공 응답을 반환해준다. 이후 별도 프로세스가 동작하여 큐에서 이벤트를 읽어 Lambda function 에 전달해주고 처리하게 된다.

 

비동기 호출을 처리할 때 에러가 발생하는 경우를 살펴보자.

• 람다가 event queue 에 있던 이벤트를 꺼내 함수를 호출할 때, 함수가 에러를 반환했다면 기본적으로는 1분 간격으로 retry 를 수행하게 된다. 함수가 에러를 반환하는 경우는 실행하는 코드가 에러를 반환한 경우부터, execution runtime 에서 timeout 이 발생하는 것까지 대부분의 경우를 포함한다.

event queue 는 대부분의 큐 서비스와 비슷하게 eventually consistent 정책을 따른다. 이 경우 함수가 동일한 이벤트를 여러번 전달받을 수 있는 확률이 존재하게 된다. 그렇기 때문에 람다 함수의 코드를 작성하는 경우에는 중복된 이벤트를 전달받는 경우가 있다는 점을 염두해두어야 한다. 

 

만약 event queue 가 너무 길어지게 되면 내부의 이벤트가 만료되어 실제로 처리되기 전에 이벤트가 제거될 수도 있다.

 

테스트

serverless 서비스를 사용해서 구현할 때 가장 어려움을 겪는 부분 중 하나는 테스트이다.

 

가장 확실하게 테스트 하는 방법은 클라우드 환경에서 수행하는 것이다. 로컬 환경과 클라우드 환경에서 오는 차이가 있기 때문에 아무리 로컬 환경에서 테스트가 잘 동작하더라도 실제 클라우드 환경에 배포되었을 때는 문제가 발생할 수 있기 때문에 이런 환경을 맞춘 뒤 테스트 하는 것이 좋다.

 

클라우드 기반 테스트

람다 함수를 테스트 하는 가장 간단한 방법은 AWS Management Console 에 들어가 test event JSON 을 넣고 실행하는 것이다. 나도 최근 람다 함수를 작성할 때 이 방법을 사용했는데 가장 확실하기도 하고 문제가 발생했을 때 CloudWatch 로 로그를 확인하고 수정할 수 있어서 초반 환경을 세팅할 때는 잘 활용할 수 있었다.

 

다만 이 방법의 단점은 사용자가 손수 콘솔에 들어가 함수를 실행시켜야 하기 때문에 개발 속도가 느려진다는 점이다. 이 부분을 보완하기 위해서는 자동화를 수행해볼 수 있다. 

SAM CLI 를 잘 활용하면 콘솔에 접근하지 않고 동일한 동작을 로컬에서 자동으로 수행할 수 있다. 이렇게 하면 CI/CD 과정에 통합해서 빠르고 쉽게 클라우드 기반으로 테스트를 수행할 수 있다.

• https://github.com/aws-samples/serverless-test-samples

GitHub - aws-samples/serverless-test-samples: This repository is designed to provide guidance for implementing comprehensive tes

 

클라우드 기반의 테스트는 다음과 같은 장/단점을 갖는다.

 

장점

• 프로덕션 환경과 동일한 환경에서 테스트를 수행할 수 있다.
• 모든 개발자가 자신의 로컬 개발 환경과 무관하게 동일한 테스트 환경을 빠르고 쉽게 구성할 수 있다.
• 사용하는 모든 서비스에 대한 테스트가 가능하다.

단점

• 로컬 테스트 보다 시간이 더 오래 걸린다.
  • 클라우드 환경에 실제 서비스를 띄워야 하기 때문에 시간이 좀 더 걸린다.
• 비용이 더 많이 소모된다.
  • 실제 클라우드 자원을 사용해야 하기 때문에 테스트 과정에서도 리소스 사용을 위한 비용이 추가된다.

Mock 기반 테스트

실제 클라우드 자원을 사용하지 않고 코드로 해당 자원의 동작을 흉내내 동작을 테스트 하는 방법을 말한다.

범용적인 Mock 프레임워크 (e.g. Mockito) 를 사용하거나 AWS SDK 처럼 특정 클라우드 솔루션에 대한 mock 을 제공하는 라이브러리를 활용해서 구현할 수 있다.

 

어떻게 보면 유닛 테스트를 작성할 때 떠올릴 수 있는 가장 간단한 방법을 그대로 적용한 방식이다.

 

Mock 을 활용한 테스트는 다음과 같은 장/단점을 갖는다.

 

장점

• 서비스 장애와 같은 상황을 쉽게 테스트 해볼 수 있다.
  • 클라우드 기반의 테스트에서는 서비스 장애를 손수 일으키는 것은 꽤 복잡한 작업이고 때로는 다른 곳에 영향을 줄 수 있기 때문에 테스트가 어렵지만, Mock 을 활용한다면 이런 부분들을 좀 더 쉽게 테스트할 수 있다.
• 범용 Mock 프레임워크를 사용한다면 클라우드 서비스의 신규 기능이 추가되었을 때도 이를 직접 구현할 수 있기 때문에 빠르게 대응해 테스트 해볼 수 있다.

단점

• 서비스의 동작을 Mocking 하는 작업에 시간이 많이 소요된다.
  • 특정 서비스의 특정 행동에 대한 mock response 를 직접 설정해주어야 하는데 이 과정이 꽤나 귀찮고 오래걸린다.
  • 또한 개발자가 이를 담당해야 하기 때문에 관리해야 하는 영역이 넓어진다.
• Mock test 가 성공하더라도 실제 클라우드 환경에서는 그 외의 원인들로 인해 실패할 수 있다.

 

최근 람다를 활용해서 작업을 수행해야 하는 일이 있었는데 테스트를 하는 과정도 쉽지 않았고 응답 속도를 빠르게 하기 위해 비동기 처리를 진행했는데 내부적으로 어떻게 동작하는 가에 대한 의문점들이 많이 있었다. 공식 문서를 좀 더 주의깊게 보면 이렇게 다양한 정보를 얻을 수 있으니 앞으로는 개발하기 전에 좀 더 잘 읽어보는 습관을 들여야겠다