8부. Lambda 함수 하나로 운영과 개발을 같이 나누어 쓸 수 있다고?
지난 편 ▶︎ 7부. CloudFormation 으로 배포되는 과정 살펴보기!
저번 시간까지 Serverless CLI 로 배포 후 AWS Console 을 통해 CloudFormation으로 어떻게 배포가 되었는지를 간단하게 살펴보았다.
자 그럼, 우리가 일반적으로 테스트를 할 때 개발 서버에 반영한 App 을 테스트 후 운영에 배포하여 서비스를 하는 과정을 거치곤 한다 (세밀한 차이가 있을 수 있겠지만…). 기존 방식과 별반 차이 없이 Serverless 로 어떻게 이와 할 수 있을까? 이다.
이에 대한 답변은 참고로 정답은 없다. 어떤 Serverless 개발 방법으론 람다를 각각 나누어서 할 수 도 있고 API Gateway를 나누어서 관리할 수도 있고 방식은 여러 가지로 존재한다. 독자보다 Serverless 를 조금 더 빨리 사용해 본 경험자로서 최고의 방식은 아니지만 최적의 방식이다 라고 생각하고 설명해보고자 한다. 또한, 그 방법이 어떤 방식으로 가능한 지를 알려주도록 하겠다.
이 물음에 대한 답을 먼저 이야기 하자면 serverless-aws-alias 플러그인에 존재한다. 실제 AWS Serverless 제품인 API Gateway 와 Lambda 를 위주로 설명할 것인데 우리가 이미 배포 했던 Sample 프로젝트를 토대로 설명하고자 한다.
serverless.yml
serverless-aws-alias 플러그인의 프로젝트를 확인하려면 해당 Github으로 가서 보면 된다. 사실 이 중에서 우리는 일부분을 사용하고 있다. 더 많은 기능을 사용하기 위해서는 아래 주소로 가서 Readme 를 참고하면 된다.
https://github.com/serverless-heaven/serverless-aws-alias
먼저 지난 글을 살펴 보았을 때 Serverless Framework 으로 배포할 때 옵션으로 — alias 라는 옵션을 준 것으로 잘 따라온 독자라면 기억하고 있을 것이다. 또한, 이 옵션이 Dev와 Prod 를 나누는 핵심적인 Key 라고 지난 시간 설명하였다.
먼저, 이 옵션은 RDS 주소를 src/sample/utils/DBManager.js 에서 DBClient 객체를 만들 때 DB 정보를 어떤 것을 넣어 줄 것인지 변수가 된다. 아래 serverless.yml 을 살펴보자.
custom.env 를 보면 opt 라는 옵션에서 alias 가 무엇이냐에 따라 json 파일을 다르게 호출하는 것을 확인할 수 있다. 자 그렇다면 우리는 배포할 때마다 Lambda 로 들어가는 환경 변수는 alias 에 따라 같은 람다 함수에 다른 값을 Setting 할 수 있다는 뜻이다.
자 그렇다면 여기서 질문이 생길 것이다. 배포할 때 dev와 prod 두개로 alias 가 구분되어서 같은 기능을 다른 DB를 바라보게 하는데 어떤 방법으로 되는 것이지요? 이 물음에 답하기 위해서는 먼저 AWS Lambda Function을 Console 에서 확인할 필요가 있다.
Lambda Function 콘솔에서 확인하기
먼저 우리가 sample 프로젝트에서 개발했던 readAllItems ( GET /items ) 라는 함수를 확인 해보자.
여기서 구분자를 클릭 해보자.
별칭이라는 탭이 보일 것이다. 그리고 아이템으로 dev 와 prod 두 개의 별칭으로 이루어져 있다.
버전은 내가 sls deploy — alias “dev or prod” 를 할 때마다 해당 별칭에 버전이 순차적으로 올라가게 된다. 단, dev 와 prod 각각 버전이 따로 올라가진 않고 하나로 통일되어 Versioning 이 된다. 현재 위의 그림에서 가장 최근에 업데이트 된 버전은 dev 로 버전:26 이다. AWS Console 에서 소스와 환경 변수를 확인했을 때는 아마 dev 환경 변수와 소스로 보일 것이다. 하지만, API-Gateway 를 통해서 람다가 호출 되고 있을 때는 각각 별칭에 따라 람다의 해당 alias 의 가장 최신 Latest 버전을 호출 하는 것이니 운영과 개발로 나누어 호출 할 수 있게 된다.
그렇다면 API-Gateway 에서는 어떻게 람다를 별칭에 따라 호출 할 수 있지 라고 생각이 들것이다. API Gateway 를 확인하러 가보자.
API Gateway
GET /items 리소스에서 확인해보면 가장 우측에 Lambda kstarlive-sample-readAllItems:${stageVariable.SERVERLESS_ALIAS} 라는 것이 보일 것이다. 여기서 람다 함수 readAllItems 함수 뒤에 세미콜론 뒤 붙은 stageValiable.SERVERLESS_ALIAS 가 dev or prod 로 넘겨 어떤 별칭의 Latest 버전 함수를 호출할 지 결정하게 된다. 이 부분이 핵심이다. 자 그럼 APIGateway Stage 쪽으로 넘어 가보자.
스테이지에서 prod 를 선택한 다음 [스테이지 변수] 탭을 클릭 해보면 Key / Value 쌍으로 설정이 되어있는 것을 볼 수 있을 것이다.
SERVERLESS_STAGE는 dev 로 fix 가 되어있는데 이 부분은 사실 serverless.yml provider.stage와 연결되는 부분이다. 이 부분은 아마 람다 함수를 별도로 운영과 개발을 구분하기 위해 사용 되는 것으로 보이나 현재 우리가 하는 프로젝트와 맞지 않으니 일단 Skip 하도록 하겠다. 그냥 무시해도 된다.
자 그럼 다시 본론으로 돌아와서 SERVERLESS_ALIAS 가 prod 스테이지에서는 prod 값으로 되어있는 것을 확인할 수 있다. 이 부분이 바로 람다 함수의 별칭이 된다. 그렇다면 결론적으로 API Gateway 에서도 스테이지에 따라 하나의 람다 함수에서 각각 다른 별칭의 버전을 호출 할 수 있다는 말이 된다. 이 부분이 저자가 설명하고자 하는 핵심 Key 이자 개발과 운영을 나누어 관리하는 전략이다.
결론
실제 개발과 운영을 나누어 배포를 하고 테스트/운영할 때 일반적인 서비스와 Serverless 로 할 때 별반 차이가 없지 않는가? 만약 배포된 버전이 잘못되거나 다시 예전 버전으로 되돌려야 한다면 serverless rollback 이라는 CLI를 사용하면 될 것이다. 그러한 Detail 과정들은 이 튜토리얼을 완성하고 여러분들이 차근차근 Add On 해서 나아가면 될 것 같다. 이제 다음 편에서는 Serverless Framework 에서 제공하는 Dashboard 를 살펴보도록 하겠다.
