programmer.cwchoiit

Canary Release

Canary Release는 배포 전략 중 하나이다. 이 배포 전략은 새롭게 배포되는 버전의 리스크를 줄이는 방법인데 기존 버전과 새로운 버전이 있을 때 기존 버전에서 바로 새로운 버전을 출시하는게 아니라 기존 버전과 새로운 버전 두 개 모두를 프로덕션 환경으로 올리지만 가중치를 두어 사용자들이 겪는 새로운 버전에 대한 오류나 문제점에 대한 비율을 줄이는 방식이다. 예를 들어, 기존 버전이 있고 새로운 버전이 새로 출시될 때 기존 버전에 가중치를 60% 새로운 버전의 가중치를 40%로 할당해서 사용자들이 접속할 때 가중치에 따라 60%는 기존 버전을 그대로 사용하게 하고 40%는 새로운 버전을 사용하게 하므로써 새 버전에 대한 문제를 40%로 낮추는 방법이다. 이렇게 최초에 40%로 가중치를 두다가 점점 안정화가 되면 그 가중치를 점점 높여 새 버전이 안정적이게 자리잡을 수 있게 배포하는 방법이라고 생각하면 된다.

다음 그림이 이 내용을 완벽하게 설명한다.

이렇듯 대부분의 유저를 기존에 버전으로 접속하게 하고 5% 정도의 유저만 새로운 버전을 경험하게 하면서 새 버전이 가질 수 있는 문제점이나 예상하지 못한 문제를 줄이는 방법이라고 생각하면 된다. 이 방법을 AWS Lambda와 API Gateway도 사용할 수 있다. 바로 사용해보자.

Lambda 버전 생성하기

우선 다음은 가장 기본 형태의 람다 함수 코드이다. 소스 코드가 중요한 게 아니고 버전에 따른 가중치를 두는것을 중점으로 봐보자.

이러한 형태의 결과를 뱉는 람다 함수가 있고 이에 대한 버전을 만들어보자. 

버전을 만들기 위해 우측 상단 Actions > Publish new version 클릭

Version description을 다음과 같이 old로 작성해보자.

Publish 버튼을 클릭하면 버전이 만들어지고 다음과 같이 Versions 탭을 클릭해보면 새로 생긴 버전이 보인다.

이 상태에서 소스 코드를 다음과 같이 변경해보자. 리턴하는 문자열을 "New Version !!!" 이라고 작성했다. 이 상태에서 Deploy 버튼을 클릭한다.

이제 다시 버전을 만들어보자. 이번엔 new 라는 Description을 지어주자.

그럼 버전 리스트에 두 개의 버전이 보인다.

이렇게 만들고 별칭을 생성하자. Actions > Create alias 클릭

설정 부분은 다음과 같다.

- Name: production

- Description: prod via canary

- Version: 1

- Weighted alias

     - Additonal version: 2 / 40%

이렇게 설정하면 버전 1에 대한 가중치가 60%, 2에 대한 가중치가 40%로 이 람다 함수가 실행된다는 의미다. 이렇게 만든 alias를 API Gateway에 등록하면 퍼센티지에 맞게 유저가 실행하는 람다 함수가 정해진다.

API Gateway에서 원하는 리소스 내 메서드를 만든다. 메서드를 만들 때 다음과 같이 새로 만든 별칭을 넣어줘야 한다.

Lambda function을 선택 후 생성된 람다함수를 클릭한다음 그 뒤에 ":<alias-name>"를 입력해준다.

이렇게 리소스와 메서드를 만들었으면 이제 배포를 하면 된다. 우측 상단 Deploy API 버튼 클릭 

설정 부분은 다음과 같다.

- Stage: New stage

- Stage name: v1

Stage를 만들면 다음과 같이 해당 스테이지로 접속할 수 있는 URL을 알려준다. 이 URL에 아까 만든 리소스대로 접속해보자.

그럼 다음과 같이 각 가중치에 맞게 해당 버전을 응답으로 돌려준다. 60% / 40% 이니까 두번에 한번 정도 낮은 가중치의 버전이 노출됐다.

결론

이렇게 Canary Release를 Lambda와 API Gateway를 이용해서 수행할 수 있었다.

API Gateway 생성

AWS Console에 API Gateway를 입력하고 나오는 서비스를 클릭

종류는 다음과 같이 3가지에 + REST API Private 형태가 있다. 나는 REST API 타입을 선택하겠다.

설정 부분은 다음과 같이 설정한다.

- New API

- API name: cwchoiit-api-gateway

- API endpoint type: Regional

만들고 나면 다음과 같은 화면이 노출된다.

좌측 'Create resource' 버튼을 클릭하면 새로운 path를 생성할 수 있고 현재는 그게 아니라 이 기본 루트 path에 메서드를 생성해서 내가 만든 람다 함수를 연결해보자. 우측 'Create method' 버튼 클릭

설정 부분은 다음과 같다.

- Method type: GET

- Integration type: Lambda fuction

- Lambda function: ap-northeast-2 / 만든 람다 함수

만들고 나면 다음과 같이 "/" path에 GET으로 호출하는 API 하나가 보여진다.

이제 이 API Gateway를 배포해보자. 우측 Deploy API 버튼 클릭

설정 부분은 다음과 같다.

- Stage: New stage

- Stage name: prod

배포하면 다음과 같이 API Gateway가 만들어진다. 아래 URL로 접속해보자. 

우리가 만든 람다 함수가 실행되고 응답하는 모습을 볼 수 있다.

이렇게 간단하게 람다를 사용해서 서버가 필요없이 REST API 서버를 구축할 수 있다.

AWS Lambda

Lambda는 AWS에서 제공해주는 서버리스 서비스이다. 서버리스(Serverless)란 말 그대로 서버가 없다는 의미고 그 말은 진짜 서버가 아예 없다는게 아니라 관리할 서버가 없다. 즉, 관리할 필요가 없다란 의미가 된다.

개발자는 서버를 관리할 필요없이 애플리케이션을 빌드하고 실행할 수 있도록 하는 클라우드 네이티브 개발 모델을 서버리스 아키텍트라고 한다. 이 구조의 장점은 항상 대기하고 있는 전용 서버가 없어서 실행이 끝나면 자원을 반납하고 사용할 때만 자원을 가져다가 사용하는 구조라고 할 수 있다. 그러나 장점만 있는 구조는 없다. 장점과 단점을 둘 다 알아보자.

• 장점
  • 서버 관리(자동 확장, 장애 방지)가 불필요
  • 관리보다 개발에 집중이 가능
  • 사용한 만큼 과금
  • 급격한 트래픽 변화에 유연
• 단점
  • 다른 클라우드 컴퓨팅 자원보다 비쌈
  • 느림(호출과 동시에 서버가 세팅되기 때문)
  • 장기적인 작업에는 적합하지 않음
  • 함수의 처리 결과에 따라 상태를 따로 저장

단점 중 장기적인 작업에는 적합하지 않다라고 되어 있는데 이 말은 한 작업이 1시간, 2시간 또는 그 이상의 시간을 소요하는 작업이라면 그 시간만큼 과금이 되기 때문에 다른 클라우드 컴퓨팅 자원보다 비싼 과금을 내는 서버리스보단 온프레미스나 클라우드 컴퓨팅 서버를 사용하는게 더 유리할 수 있다는 소리다. 

서버리스의 2가지 서비스 형태

• BaaS(Backend As a Service)
  • 클라우드 공급자가 제공하는 서비스를 이용해 백엔드 기능들을 쉽게 구현
  • Customizing이 어렵다
  • Google Firebase
• FaaS(Function As a Service)
  • FaaS는 기능을 하나의 함수로 구현
  • 함수가 실행할 때마다 서버 자원을 할당받아 사용
  • 로직을 개발자가 작성하므로 Customizing이 가능
  • AWS Lambda

AWS Lambda 구축하기

이제 람다가 어떤것인지 알았으니 한번 만들어보고 사용해보자.

우선 AWS Console에 "Lambda"를 입력하고 나온 서비스를 클릭한다.

Create a function 버튼 클릭

설정화면은 다음과 같이 설정한다.

- Author from scratch

- Function name: cwchoiit-first-lambda

- Runtime: Python 3.12

Runtime은 어떤 환경을 사용할 것인지를 의미한다. NodeJS, Java 등등 다양하게 있다. 본인은 Python을 선택했다.

이 상태로 Create function 버튼을 클릭하면 Lambda가 만들어지면서 다음 화면이 노출된다.

아래 코드를 보자. 간단한 파이썬 코드로 된 함수 하나가 있다. 이 코드가 곧 하나의 람다 함수가 된다. 이 소스를 실행하기 위해 "Test" 버튼을 클릭해보자.

그럼 이러한 화면이 보여지는데 우선 Event name만 입력해보고 "Save" 버튼을 클릭해보자.

그러면 이렇게 내가 만든 이벤트 하나가 리스트에 보여진다. 이 이벤트를 클릭하면 아까 구성한대로 이벤트가 트리거될 준비가 된 상태이고 "Test" 버튼을 클릭하면 그 이벤트가 실행된다.

다음은 테스트 실행 결과다. 이벤트 이름, 응답 등등이 보여지고 코드에서 리턴하는 내용처럼 응답에는 statusCode와 body값이 있다.

그럼 아까 이벤트를 만들 때 이 부분이 무엇인지 알아보자.

람다 함수는 이 함수로 들어오는 데이터 같은 것들을 이벤트로 받아준다. 그 이벤트를 출력해보자.

이렇게 소스를 변경하면 Deploy 버튼을 클릭해서 새롭게 소스를 배포해야 한다.

배포가 끝나면 다시 테스트 버튼을 클릭해보자. 이 이벤트에 대한 내용이 출력될 것이다.

이렇게 이벤트를 출력하면 테스트 구성시에 작성했던 데이터가 담겨있는 것을 알 수 있다. 이렇듯 람다 함수에 뭔가를 전달할 때 이벤트라는 파라미터안에 그 데이터들이 담긴다고 생각하면 된다.

그리고 이 실행에 대한 로그를 볼 수 있는데 로그는 CloudWatch에 기록된다. 한번 확인해보자. 위에 탭 중에 Monitor 탭이 있다. 해당 탭을 누르면 다음 화면이 보이는데 여기서 View CloudWatch logs 버튼을 클릭하자.

그럼 이러한 화면이 보여진다. 내가 만든 람다 함수에 대한 로그가 기록되어있다. 그리고 저 아래 빨간 표시로 해둔것은 배포 버전별로 다르게 기록되는 로그이다. 처음 람다함수를 만들면 그게 최초 배포버전이고 내가 중간에 이벤트를 찍어보겠다고 소스를 변경하고 배포를 다시했기 때문에 저렇게 두 개의 다른 로그가 쌓인다고 보면된다. 배포를 새로 또 하면? 3개가 된다.

안으로 들어가보면 다음처럼 화면이 보여진다. 내가 찍은 "print(event)" 역시 로그로 남게 된다. 이렇게 로그도 확인이 가능하다.

이렇게 간단하게 AWS Lambda 함수를 생성해서 서버리스 서비스를 구현해보았다. 이 서버리스를 API Gateway에 붙여서 실제 서버가 있는것처럼 실행하게 만들수도 있다. 그 부분을 다음 포스팅에서 해보자.