6부. Serverless Framework 으로 배포 및 API 테스트

JeungJoo Lee
CrocusEnergy
Published in
8 min readOct 27, 2019

지난 편 ▶︎ 5부. 처음부터 끝까지 CRUD 만들어 보기 (2)

이제 거의 막바지에 접어들고 있다. 조금 더 힘을 내서 배포까지 완료해 보도록 하자. 먼저, 필요한 것이 있다 바로 AWS 계정 생성과 Serverless Dashboard 에서 기본적인 App 과 Org 그리고 권한 설정이다.

AWS 계정 생성에 대해선 생략 하도록 하겠다… 먼저 Serverless Dashboard 에서 생성해야 되는 부분을 살펴보겠다

Serverless Dashboard 설정

CLI 로 아래와 같이 입력하자.

sls login

그럼 브라우저가 열리고 Serverless Framework Dashboard 에 로그인 창이 나올 것이다. 로그인을 하면 아래와 같은 Dashboard 화면이 출력된다.

Serverless Framework Dashboard 화면

이 화면에서 먼저 해야할 것들이 있다.

첫 째, profiles 에서 AWS IAM 역할 권한을 연결하라!

profiles 는 이 글의 초반 부분에서 설명 했었다. 다시한번 설명하자면 AWS IAM 에 role 을 만들어 연결 해줘야 한다. 그 권한이 있어야 CloudFormation 으로 작업이 가능하다. 어쩌면 당연한 얘기 일지 모른다. 권한이 부여된 값을 Serverless Framework 에 설정해야 CLI 작동 시 AWS 의 인스턴스들을 관리 할 수 있으니 말이다.

가장 쉽게 만드는 방법은 [Create a role wizard] 를 이용하면 IAM 에 role 과 정책이 알아서 만들어진다. 만약 기존 role을 사용하기 위해선 arn 을 복사하여 넣어주고 Save and Exit 버튼을 누르면 된다.

둘 째, Org 설정

Org 설정은 간단하다. 아래와 같이 + 버튼을 눌러 클릭 후 Org 명만 만들어 주면 된다.

셋 째, App 만들기

대시 보드에서 [add app] 버튼을 클릭하자. 그리고 이름은 본인이 다음과 같이 입력한다. 참고로 org 와 app 이름은 serverless.yml 의 상단과 일치해야 하니 유의하길 바란다. deployment profile은 위에서 만든 profile로 선택하면 된다. 마지막으로 [add application] 을 누르자.

serverless.yml app과 org 설정

완료가 되면 다음과 같이 app 이 하나 Dashboard에 생성 되었을 것이다. 우리가 만든 kstarlive-sample 서비스가 배포되면 kstarlive app 내부의 서비스로 등록되고 각 API와 람다 함수에 대한 정상 호출, Error, Cold Start 횟수 등 통계가 제공될 것이다.

자 이제 배포를 위한 사전 준비가 끝났으니 CLI 로 배포를 시도해 보겠다.

배포하기

도메인 레코드 생성

우선 배포하기 전 Route53 에 kstarlive.com 도메인에 sub 도메인으로 dev 용과 prod 용 각각을 만들어 보도록하겠다. dev 와 prod 도메인 생성은 아래의 명령어로 만들어 주면 된다. 아마 이 부분의 경우는 도메인을 가지고 있는 것이 다르니 serverless.yml 도메인 부분에서 다르게 설정해 주면 된다. 만약, 도메인이 없다면 serverless.yml 의 custom.customDomain 을 삭제해 주고 이 과정을 스킵하면 된다. 도메인이 없고 Cloud Front 를 사용하지 않더라도 기본적으로 API Gateway 에서 굉장히 긴 url을 제공해주고 있다.

# dev-sample.kstarlive.com 생성
sls create_domain --alias dev // 반대로 삭제는 delete_domain 이다.
# sample.kstarlive.com 생성
sls create_domain --alias prod

결과

CLI 로 도메인을 만들고 성공했을 때 터미널 로그 화면

console.aws.amazon.com Route53에서도 도메인이 생성 되었는지 확인해 보자.. 아래와 같이 IPv4, IPv6 에 대한 도메인 레코드가 생성된 것을 확인할 수 있을 것이다.

이제 본격적으로 람다와 API Gateway 등의 서비스를 배포 해보자.

개발(dev)

sls deploy --alias dev

개발은 다음과 같이 명령어를 치면 CloudFormation 을 통해 각 서비스별로 개체들이 배포가 된다.

결과

최종적으로 문제 없이 잘 배포가 되면 위와 같은 메시지가 터미널에 나오고 에러가 나면 왜 에러가 발생했는지 메시지가 나온다. 해당 메시지를 적절하게 복사하여 forum.serverless.com 이나 Github Issue 쪽에서 찾아보면 된다.

제대로 배포가 되었는지 아마존 Console 에서 확인할 수 있으나 그건 다음 편에서 살펴보도록 하겠고 Dashboard 로 다시 돌아 가보자.

위의 Dashboard 쪽에서 ALL Services 를 보면 kstarlive-sample 이라고 serverless.yml에 정의한 이름대로 서비스가 올라가 있는 것을 볼 수 있다. 해당 아이템을 클릭 해보자. 아래와 같이 API Endpoint 와 배포된 람다 함수 들의 이름을 확인할 수 있다.

아쉬운 것은 이 대시보드 화면에서 제공되는 것이 통계 기능인데 이 통계 기능은 Seoul Region 에선 지원이 되지 않는다…. 항상 AWS 를 쓰면서 느끼는 것이지만 Seoul Region 이 혜택을 많이 못 보는 것 같다는 생각이 든다.

운영(prod)

운영도 별반 다를 것 없다 위에 과정을 반복해서 보면 된다. 단, 명령어 중 alias 명이 prod 로 되어야 한다!

sls deploy --alias prod

성공적으로 처리가 되었다면 위의 개발(dev) 와 같은 방법으로 확인하면 된다.

자 이제 배포된 API를 개발과 운영으로 나누어 테스트 해보도록 하겠다. 전제조건은 DB 가 운영과 개발로 나누어져 있어야 운영과 개발을 나누어 볼 수 있기 때문에 사전에 준비 하도록 바란다.

API 테스트

이번에는 curl 이 아닌 Postman 으로 API 테스트를 진행해 보겠다.

개발(dev)

CloudFront 설정 시 Base API는 /api 로 설정했기 때문에 Path 에서 가장 상위 root Path 가 된다는 것을 참고하자.

POST /api/item

GET /api/items

GET /api/item/{itemId}

PUT /api/item

DELETE /api/item/{itemId}

운영(prod)

Domain 주소가 Dev와 다른 sample.kstarlive.com 으로 설정 되어있기 때문에 다른 결과 값이 나와야 한다. 살펴 동일한 테스트를 다시 진행해 보겠다.

POST /api/item

GET /api/items

GET /api/item/{itemId}

PUT /api/item

DELETE /api/item/{itemId}

여기까지 Serverless Framework을 통한 배포와 운영/개발 API 테스트를 진행하였다. 다음 편에는 CloudFormation으로 배포되는 과정을 설명하도록 하겠다.

다음 편 ▶︎ 7부. CloudFormation 으로 배포되는 과정 살펴보기!

--

--