7부. CloudFormation 으로 배포되는 과정 살펴보기!
지난 편 ▶︎ 6부. Serverless Framework 으로 배포 및 API 테스트
이번 Chapter 에서는 저번 시간에 CloudFormation 을 통해 배포한 개체들을 하나씩 살펴볼 예정이다. 초반에 첨부한 그림을 다시 한번 상기 시켜 보도록 하자.
초반 그림과 달라진 부분은 S3 가 추가되었다는 점이다. S3는 실제로 람다 함수를 배포할 때 어플리케이션 리소스를 먼저 Webpack으로 Bundle 작업을 하고 zip으로 압축을 해서 S3 개체에 올리게 된다.
함수 별로 압축해서 S3 개체에 업로드 된 파일 들이다.
Serverless Framework 을 통해 다양한 AWS 의 제품들을 Orchestration 할 수 있지만 저자가 다룬 것은 위의 아키텍처 도식화에 대한 부분만 다룬 것이라 이게 표준이라고 오해 없길 바란다. 각자 깜냥 만큼 쓰는 것이기 때문에 무엇이 맞다 틀리다 할 순 없다. 추가적으로 더 있는 것은 VPC 설정이다.
그렇다면 아마존 Console 로 들어가서 CloudFormation 을 보도록 하자.
CloudFormation
지난 시간에 sample 프로젝트를 prod와 dev 로 배포하는 과정을 살펴보았다. 콘솔 중 CloudFormation 제품에 들어가보면 위의 3개의 스택이 생겼을 것이다. kstarlive-sample 의 경우 Master 적인 역할을 하고 실제 alias 에 따라 dev 를 실행할 것인가 prod 를 실행할 것인가 선택 되어지는 것 같다.
자 그렇다면 한번 Serverless 로 개발에 deploy 를 해보자.
로그를 보면 알겠지만 가장 먼저 Webpack 으로 Bundling을 하고 소스와 node_modules 를 압축한다. 그리고 CloudFormation에서 kstarlive-sample 스택과 kstarlive-sample-dev 스택의 상태가 UPDATE_IN_PROGRESS 가 되면서 작업이 진행된다. 작업의 순서는 대략적으로 로그로 보아서 S3 Bucket에 압축된 application 을 업로드하고 API 와 람다를 차근차근 반영해 주는 것으로 보인다.
사용 되고 있는 각각의 제품들을 콘솔에서 확인해 보자.
참고로 Route53 과 S3는 제외하겠다 이전에 이미 봤기 때문에… 그리고 CloudFront 의 경우에는 Console 에서 아예 리스트에 나오지는 않는 것 같다. 하지만 Route53 도메인에 별칭으로 맵핑 되어 있는 CloudFront 인스턴스는 존재한다. 왜 안 나오는지는 잘 모르겠다. 이들을 제외하고 한번 살펴보자.
API Gateway
우선 아래와 같이 API Gateway 의 하나의 개체가 생겼다. 이름은 kstarlive-sample로 yml 에 정의한 대로 생겼다.
그리고 리소스와 스테이지를 각각 살펴보자.
리소스를 보면 각 Path 의 메서드를 클릭하면 어떤 람다 함수하고 연결이 되었는 지 확인이 가능하다. 또한, 스테이지에서는 우리가 alias 를 주고 deploy 했던 명 대로 stage 가 생겼다. 이 부분은 바로 람다 함수를 호출할 때 운영이나 개발이냐의 핵심 Key 되는 부분이다 이 부분은 뒤에서 다시 자세하게 다루도록 하겠다.
Lambda Function
이제 람다 함수를 확인 해보자.
총 6개가 생겼는데 dev-custom-resource 블라블라 라고 생긴 놈은 뭐하는 놈 인지는 모르겠으나 Serverless Framework 으로 작업하면 기본적으로 하나 추가되는 함수이다. 그리고 의도 한대로 총 5개의 람다 함수가 생겼다. 하나를 클릭 해보자.
우리가 serverless.yml 에 정의한 대로 모든 옵션들을 토대로 생성되었다. 실제로 Serverless Framework 을 쓰지 않고 콘솔로 작업 했을 때 보단 불친절하게 코드에 손을 대지 못한다. 현재는 코드가 간단해서 보이긴 하나 나중엔 아예 코드 조차도 나오지 않는다. 하지만 함수는 제 역할을 잘하고 해당 코드는 로컬 PC 에 있으니 상관없다. 그리고 환경변수와 VPC 설정도 제대로 들어 간 것을 확인할 수 있다.
CloudWatch
API Gateway , Serverless 환경 그리고 Lambda 함수에서 발생하는 모든 로그는 기본적으로 CloudWatch 에 저장된다.
우선 람다 로그는 위와 같이 자동으로 CloudWatch 에 생성이 되고 하나를 클릭해서 들어가보면 함수를 실행할 때 생기는 로그를 확인할 수 있다. 이 부분을 토대로 유의미한 데이터 적재나 디버깅을 할 수 있을 것이다.
결론
사실 저자도 AWS 를 이용하고 있지만 CloudFormation 에 대해 아는 바가 없었다. 무엇에 쓰는 것인지도 잘 판단이 안되었는데 Serverless Framework 를 쓰면서 yml(야믈)로 모든 인스턴스들을 자동화하여 배포할 수 있다는 것을 알게 되었다. (느낌은 Docker Composer 의 느낌? )… 굉장히 단순했지만 가장 강력한 제품이라는 것을 새삼 이 프로젝트를 진행하면서 알게 되었다.
다음 시간에는 어떻게 운영과 개발이 람다 함수 하나를 별도로 호출 할 수 있는지 확인하여 보도록 하자.. 참고로 저자는 이 부분에서 엄청난 많은 시간이 소모가 됐었다.. 도대체 어떻게 Lambda Function를 하나로 운영과 개발로 나누어 사용할 수 있을까에 대해서 말이다.. 그 답은 다음 편에서 이어서 하도록 하겠다.
