1부. Day34 Serverless 기존 개발 프로세스 (V1) 에 대한 이해

JeungJoo Lee

Published in

CrocusEnergy

7 min readOct 24, 2019

지난 편 ▶︎ Intro. Serverless 로 하루만에 개발하기

먼저, 기존 개발 방법 및 아키텍처에 대해 살펴 보도록 하자. Serverless 개발 환경과 서비스 아키텍처는 간단하게 표현하면 아래와 같다.

Serverless 서비스를 위한 아마존 아키텍처

위의 그림은 AWS 제품을 이용한 Day34의 Serverless V1 아키텍처다. 만약 어떤 아이템을 조회하는 API를 만든다고 가정해도록 하자.

Route53

첫 번째로, IP 로 서비스를 할 수 있겠지만 해당 API를 호출할 도메인이 필요하다. 도메인은 Verisign 이나 여러 대행 도메인 등록 대행 업체를 통하여 구매 후 Route 53에 등록한다. 그 후, 서비스의 목적에 맞게 서브 도메인을 생성하거나 정책을 만들어 관리한다.

예를 들어, 서비스할 API 도메인이 만약 https://sample.kstarlive.com 이라면 sample.kstarlive.com 을 Route53을 통해 A 레코드를 생성 하면 된다. 등록할 때 로드 밸런싱(ALB)으로 연결할 것인지 Public IP로 등록 할 것인지 CloudFront로 연결할 것인지 별칭을 선택을 할 수 있다.

별칭 대상에서 Serverless 환경을 구축하기 위해선 CloudFront는 사실상 필수조건은 아니다. 우리 34일에서는 Edge나 Regional한 Caching을 클라우드 프론트를 통해 구현을 하기 위해 사용한 것 뿐이지 실제로 ALB나 EC2 등을 통해 API Gateway에 연결하셔도 무방하다.

Cloud Front

클라우드 프론트는 https 서비스가 필수적이기 때문에 HTTPS의 인증서를 포함해야 하는데 아마존 ACM(Amazon Certification Manager)을 통해 인증서를 발급 후 Cloud Front Distribution Setting 에서 도메인과 인증서를 설정 해 주면 된다.

CloudFront를 설정할 때 중요한 점은 API Gateway 와 연결고리를 만들어야 한다. CloudFront 의 Origin 설정 부분으로 가보면 Origin을 추가할 수 있다. 아래와 같이 Origin 을 추가할 때 Path를 적어 주는 란이 있는데 이 부분은 API Gateway 에서 리소스를 배포하면 Stage 가 생기게 된다. 이 Stage 시 떨어지는 주소를 넣어 주면 API Gateway 주소 뿐만 아니라 클라우드 프론트를 통해 등록된 Domain 주소 로도 API 가 접속이 가능해 진다. 이 부분을 잘 체크 하시기 바란다~

API Gateway

API Gateway는 실제로 RestFul 하게 Lambda 쪽에서 만든 각각의 기능들을 API로 접근 할 수 있게 해 주는 Path 를 생성해 주는 녀석이라 보면 될 것 같다. Node에선 Express 모듈의 Route 역할이거나 Java Spring MVC 에선 Controller 의 역할이라 보면 될 것이다.

자 이제 /items GET 메서드로 연결되는 람다의 기능을 정의해야 한다. 해당 items 리소스의 GET 메서드를 클릭하면 메서드 실행 쪽에서 Lambda 함수를 연결할 수 있다. 아래 그림과 같이 kstarlive-sample-readAllItems 라는 람다 함수를 해당 /items GET 메서드에 연결 할 수 있다.

Lambda 함수

자 이제 마지막으로 람다 함수이다. 람다 함수를 만들 때 언어를 뭘 사용할 지 버전을 몇 버전으로 사용할 지 선택할 수 있다.

Java, Python, Node JS, Go, Ruby등 다양한 언어를 지원하고 있다. 우리는 기본적으로 Node JS 10.x 를 타겟으로 작업을 하고 있다. 해당 버전을 체크하고 함수 명을 입력한 다음 Create Function을 누르면 함수가 만들어 진다. 이 함수에서 이제 코딩을 하면 되는데 아마존에서는 기본적으로 Web Editor를 아래와 같이 제공하고 있다.

람다 함수 에서는 다양한 기능을 같이 사용할 수 있다. 기본적으로는 CloudWatch 에 로그를 기록하고 S3에 소스 들을 저장한다. API Gateway는 아까 위에서 API 메서드에 람다 함수를 연결해 주기만 하면 위의 디자이너 툴 에서 API 게이트웨이를 쓰고 있다는 표시가 나오게 된다.

람다의 코드이다. 해당 handler 함수를 export하고 있다. 이 함수가 API 를 통해 Call 이 되면 실행되는 함수이다. return 을 줄 때 Http Status Code와 Data Payload를 같이 Response 해주는 것을 확인 할 수 있다.

NodeJS 함수에서 process.env 로 환경 변수 값을 불러오는 부분이다. 위에서 보시는 바와 같이 사용 용도는 Amazon RDS의 접속 정보이다. 그외 태그를 사용할 수 있는데 잘 사용하진 않는다. -ㅇ-

네트워크 VPC 서브넷과 보안 그룹도 설정이 가능하다. 또한 현재 함수를 메모리를 몇 으로 할 것인지 Timeout은 몇 초로 할 것 인지에 대한 설정도 할 수 있다.

Lambda 계층(Layer)와 Cloud Watch

그 외 언급하지 않은 람다 계층(Layer) 와 Cloud Watch 에 대해 설명을 하자면 레이어는 각 함수들이 공통적으로 사용하는 라이브러리 같은 역할을 하는 놈이다. 우리 서비스의 경우 이러한 역할을 담당하는 놈들은 Athentication 에서 JWT 토큰을 생성/검증 기능과 RDS 접속 클라이언트 등의 공통적인 기능을 계층(Layer)로 뺀 다음 람다 함수에서 부를 수 있도록 공통화 하여 사용하였다. 아래와 같이 Versioning 도 가능하다.

계층의 Versioning은 상당히 유용한데 공통 라이브러리가 업데이트 되더라도 이것을 사용하는 함수에서는 계층이 자동으로 업데이트 되지 않는다. 물고 있는 계층을 Latest 로 배포된 버전을 올려줘야 가능하다.

CloudWatch의 경우 대부분 Error 로그나 사용 패턴, 데이터 활용에 대한 로그를 쌓게 된다. CloudWatch의 경우 보관 기한을 설정하지 않고 무한히 사용하게 되면 Amazon 사용 요금 지불 시 현재까지 사용된 누적Storage 기준으로 납부를 해야 되니 적절한 사용 기한 설정이 필요하다. 해당 기한이 되면 이전 것은 삭제 되거나 상대적으로 요금이 저렴한 S3로 이관을 하는 노하우가 필요하다.

이상으로 현재 AS-IS 아키텍처에서 Serverless 를 구성하는 각 요소에 대한 설명을 저희 현재 서비스의 예제를 통해 살펴보았다. 개발을 할 때 항상 이러한 과정을 통해 Amazon 콘솔에서 작업을 하였다. 이 과정에서 생기는 문제점과 개선 방안이 무엇인지 다음 화에서 살펴 보도록 하겠다. 끄읏~

다음 편 ▶︎ 2부. 기존 개발 방법에 대한 문제점 및 개선 방안