Peak Load Control with Serverless

1. 소개

1.1 개요

온라인 쇼핑몰의 경우, 연말 연시 또는 이벤트 시에 웹사이트 트래픽이 급증할 수 있습니다.

AWS의 AutoScaling 기능을 사용하여 서버를 자동으로 확장하고, Amazon DynamoDB와 같은 자동으로 확장되는 완전관리형 서비스를 사용하여 이러한 트래픽의 급증을 처리할 수 있습니다.

하지만 라이선스 또는 외부연동 등의 여러 요소로 인해 갑작스러운 트래픽 증가를 처리하기 어려운 Legacy 애플리케이션이 있을 수 있습니다.

이러한 경우 사이트에 도착하는 순서대로 번호표를 발급하고 사용자를 대기하도록 한 다음에, 순서대로 입장시키는 전략을 가져갈 수도 있습니다.

1.2 아키텍처

1.2.1 AS-IS Architecture

현재 아키텍처는 EC2 인스턴스에 설치된 일반적인 웹 애플리케이션을 나타내고 있습니다.
라이선스 또는 외부연동의 이슈로 쉽게 확장이 불가능한 상태의 애플리케이션을 가정하겠습니다.

1.2.3 시스템 구축 Idea

사용자가 많아지면 사이트에 입장하는 순서대로 번호표를 발급하고 사용자가 대기하게 하려고 합니다.

사이트를 구축하기 위한 아이디어를 얻기 위해서 맛집에서 손님이 입장하는 프로세스를 한 번 생각해 보겠습니다.

• 맛집에 손님이 많은 경우, 손님은 바로 입장할 수 없고 번호표를 발급받은 후 대기실에서 기다리게 됩니다.
• 그리고 입장가능여부를 체크하다가 입장이 가능한 상태가 되면 입장을 하고 식사를 마친 후에 퇴장을 하게 됩니다.
• 그러면 Legacy 시스템 앞단에 이런 기능을 가진 시스템을 추가하면 될 것 같습니다.

오늘 실습에서는 이런 프로세스를 AWS Serverless를 통해 구축하려고 합니다.
확장성 높은 AWS Serverless 아키텍처를 통해 확장이 불가능한 서버를 보완해 보겠습니다.

물론 시스템을 구축하기 위한 다른 다양한 방법이 있습니다. 그중에서도 이 핸즈온랩은 실행 가능한 하나의 구현 아이디어라고 보시면 됩니다.
또한 이 핸즈온랩은 상용환경에서 사용할 수 있을 정도의 테스트를 거치지 않았기에 그대로 고객분들의 워크로드에 적용할 수는 없다는 점 참고 부탁드립니다.

1.2.3 TO-BE Architecture

목표로 하는 최종적인 아키텍처는 아래와 같습니다.
아키텍처의 상세내용은 핸즈온랩을 진행하는 동안 차츰 역할을 이해할 수 있게 됩니다.

2. Hands-on 준비 사항

현재 해당 실습은 us-east-1 리전에서만 진행가능합니다.

2.1 IAM Role 생성하기

AWS Cloud9에서 실습에 필요한 권한을 확보 하기 위한 IAM Role을 생성합니다.
AWS 콘솔에서 IAM Service 콘솔로 이동합니다.

IAM 콘솔에서 Roles메뉴로 이동하고 Create role 버튼을 클릭합니다.

Create role 페이지의 Choose a use case 영역에서 EC2를 선택하고 하단의 Next:Permissions 버튼을 클릭합니다.

Create Role 페이지의 Attach permissions policies에서 아래와 같이 AdministratorAccess 를 선택하고 하단의 Next:Tags 버튼을 클릭합니다.

별도 변경없이 하단의 Next:Review 버튼을 클릭합니다.

Create Role 페이지의 Review에서 Role name을 dna-serverless-hol-cloud9-role 로 입력하고 Create role 버튼을 클릭하여 Role을 생성합니다.

정상적으로 Role의 생성이 완료되면 아래와 같은 메시지를 확인할 수 있습니다.

2.2 Cloud9 Environment 생성하기

Cloud9 서비스로 이동합니다.

Create environment 버튼을 클릭하여 Cloud9 Environment 생성을 시작합니다.

Name에 dna-serverless-hol-cloud9-env 를 입력하고 Next step 버튼을 클릭합니다.

Configure settings 에서는 변경사항 없이 기본값으로 설정하고 Next step 버튼을 클릭합니다.

Review 페이지에서 Create environment 버튼을 클릭합니다.

AWS Cloud9의 프로비저닝이 완료되면 다음과 같은 통합개발환경(IDE) 화면을 보실 수 있습니다.

2.3 Cloud9 인스턴스에 Role 생성하기

AWS Cloud9을 프로비저닝하면 AWS Cloud9은 제한된 권한만을 가지도록 구성됩니다. 우리는 Hands-on을 위해서 AWS Cloud9 인스턴스에 1.1 IAM Role 생성하기 생성하기 에서 생성한 IAM Role을 연결할 것입니다.

우선 Cloud9이 실행되면 하단에 터미널영역이 보일 것입니다.

aws configure list 명령을 사용하여 현재 AWS Cloud9 환경에서 사용중인 Credential 정보를 다음과 같이 확인 합니다.
Type이 shared-credentials-file 인것을 확인 할 수 있습니다. AWS Cloud9 이 프로비저닝 될 때 제한된 권한을 갖는 AWS managed temporary credential이 ~/.aws/credentials 에 생성된 것을 알 수 있습니다.

AWS Cloud9 콘솔 우측 상단의 톱니바퀴 아이콘을 눌러서 Preferences 메뉴로 들어 갑니다.

AWS Settings 메뉴에서 'AWS managed temporary credential'을 disable 합니다.

다시 aws configure list 명령을 실행하여 현재 AWS Cloud9 환경에서 사용중인 Credential 정보를 확인 하면 다음과 같습니다.

이제 미리 만들어 두었던 IAM Role을 Cloud9 인스턴스에 연결하겠습니다. 우측 상단의 Share 좌측에 표시된 둥근 버튼을 클릭하고 Manage EC2 Instance 를 클릭합니다.

EC2 콘솔로 자동으로 이동하고 AWS Cloud9 인스턴스가 검색됩니다.
검색된 인스턴스를 선택하고 Actions 버튼을 클릭 후 Security -> Modify IAM role 을 선택합니다.

팝업에서 dna-serverless-hol-cloud9-role 을 선택하고 저장합니다.

AWS Cloud9 에 ROLE이 연결된 것을 확인하기 위해 다시한번 aws configure list 명령을 사용하여 Credential 정보를 확인합니다. Type의 값이 iam-role 인 것을 확인할 수 있습니다.

이제 region 정보를 aws configure set region us-east-1 명령어를 사용하여 us-east-1로 지정합니다.
다시 한 번 aws configure list 를 입력하여 Credential 정보를 확인합니다. 아래와 같이 표시되면 정상적으로 완료된 것입니다.

2.4 EC2 Key Pair 생성

추후 성능테스트 시에 사용할 인스턴스에 접속하기 위한 Key Pair를 생성하겠습니다.

AWS 콘솔에서 EC2 서비스로 이동하여 좌측의 Network & Security -> Key Pairs 메뉴로 들어갑니다.
Create key pair 버튼을 클릭하여 새로운 Key Pair를 생성합니다.

Name에 dna-serverless-hol-keypair 를 넣고 Create key pair 버튼을 클릭하여 생성을 완료합니다.
이름은 반드시 동일한 이름을 넣어야 CDK 스택을 생성할 때 오류가 나지 않습니다.

자동으로 다운로드되는 pem파일은 이후 사용을 위해 로컬PC에 저장합니다.

2.5 실습코드 다운로드 및 CDK 환경설정

Cloud9 환경으로 하단 터미널에서 아래의 명령어를 실행하여 실습코드를 다운로드합니다.

cd ~/environment
git clone https://github.com/skipio11/dna-serverless-hol.git

실습환경은 Cloud9에 기본적으로 설치된 CDK CLI를 통하여 배포를 진행합니다. 우선 아래의 명령어를 실행하여 cdk를 환경을 초기화합니다.

cd ~/environment/dna-serverless-hol/legacy
npm install
cdk bootstrap

3. Hands-on: Legacy System 생성

불필요한 비용을 방지하기 위해 Legacy System은 초반에 나타낸 아키텍처와는 다르게 DB는 제외하고 Spring Petclinic 샘플 애플리케이션을 EC2 한대에 배포하고 ALB와 연결하여 Public DNS를 통해서 테스트를 진행합니다.

3.1 생성

아래의 명령어를 실행하여 Legacy System을 생성합니다.

cd ~/environment/dna-serverless-hol/legacy
cdk deploy --all --require-approval never

작업이 실행되면 아래와 같이 진행상황을 확인할 수 있습니다.
생성작업은 대략 10분 내외의 시간이 소요됩니다.

3.2 생성확인

Legacy는 2개의 스택으로 구성되며, 스택의 생성이 완료되면 CLI의 결과화면에서 생성된 ALB의 Domain Name을 확인할 수 있습니다.

CDK는 CloudFormation을 기반으로 동작하므로 AWS 콘솔에서 CloudFormation 서비스로 이동하여 LegacyAppStack의 Outputs 탭에서도 ALB의 Domain Name을 확인할 수 있습니다.

Outputs에 있는 loadBalancerDnsName의 Value를 복사하여 브라우저에서 접속하면 샘플로 구성된 Spring Petclinic 애플리케이션을 확인할 수 있습니다.
단, EC2에서 애플리케이션이 구동되어 초기화되기까지는 조금의 시간이 소요될 수 있습니다.

이제 아래와 같은 Legacy 환경이 만들어졌습니다.
물론, 처음에 기술한대로 실습환경에서는 불필요한 비용을 방지하기 위해 DB를 제외하고 한대의 EC2로만 구성되어 있습니다.
이 환경은 확장이 불가능해 부하가 늘어나면 자주 장애가 발생하는 시스템이라고 가정합니다.

4. Hands-on: Peak Load Control 환경 생성

이제 앞서 보았던 Peak Load Control 환경을 생성해보겠습니다.

4.1 설정 변경

환경 생성에 앞서 ~/environment/dna-serverless-hol/plc/deploy-env.sh 파일을 수정합니다.

수정하기 전의 파일의 내용은 아래와 같습니다.

#LEGACY_ENDPOINT=xxxxxxxxxxxx.us-east-1.elb.amazonaws.com
LEGACY_ENDPOINT=REPLACE_THIS
#ADMIN_EMAIL=testuser@example.com
ADMIN_EMAIL=REPLACE_THIS

LEGACY_ENDPOINT에서 REPLACE_THIS로 된 부분을 앞서 생성한 Legacy Stack의 생성결과로 만들어진 ALB의 loadBalancerDnsName로 변경합니다.
이 때 http:// 부분은 넣지 않고 도메인만 입력합니다.

ADMIN_EMAIL은 추후 SNS로 알림을 받을 관리자 이메일 주소입니다. REPLACE_THIS 부분을 실습자 본인의 이메일 주소로 변경합니다.

4.2 환경 생성

설정 변경이 끝났으면 아래의 명령어를 실행하여 Peak Load Control 환경을 생성합니다.

cd ~/environment/dna-serverless-hol/plc && npm install \
&& cd ~/environment/dna-serverless-hol/plc/src/lambda && npm install \
&& cd ~/environment/dna-serverless-hol/plc && ./deploy.sh

ADMIN_EMAIL에 기입했던 이메일 계정으로 이동합니다.
환경생성이 완료되면 ADMIN_EMAIL에 기입했던 이메일로 아래와 같은 Subscription Confirmation 이메일을 받게 됩니다.

Confirm subscription 링크를 클릭하여 Confirmation을 완료합니다.이후 CloudWatch Alarm이 발생하면 SNS를 통해 해당 이메일로 Notification을 받을 수 있게 됩니다.

스택의 생성이 완료되면 아래와 같이 CloudFront의 도메인을 cloudfrontPublicDnsName 값에서 확인할 수 있습니다.

해당 CloudFront 도메인으로 들어가면 Legacy Stack을 통해 생성했던 샘플 애플리케이션을 CloudFront를 이용하여 접속할 수 있습니다.

4.3 Runtime 환경 검토

4.3.1 요청제어 영역

이제 AWS콘솔로 들어가서 CloudFront 서비스로 이동합니다.

CloudFront 콘솔의 좌측 Distributions 메뉴로 들어갑니다.

CDK 스택을 통해서 생성된 CloudFront Distribution의 ID를 클릭하고 Origins 탭에 들어가면 3개의 Origin과 연결이 되어 있습니다.

Behaviors 탭에 들어가면 경로를 기준으로 waiting/static/* 컨텐츠는 s3로, waiting/api/* 는 API Gateway로 나머지 컨텐츠는 Legacy의 ALB로 처리되고 있습니다.

Default(*)에 해당하는 Behavior를 클릭하고 Edit 버튼을 클릭하면 상세 내용을 볼 수 있습니다.

하단까지 스크롤을 하면 Origin Request와 Origin Response에 해당하는 곳에 Lambda@Edge 함수가 연결되어 있는 것을 확인할 수 있습니다.

콘솔에서 Lambda 서비스로 이동합니다.

상단의 검색창에서 edge라고 입력하고 엔터를 입력합니다.

아래와 같이 2개의 함수가 검색됩니다. PlcStack-edgeRequestFilterLambdaXXX 함수는 CloudFront에서 Origin으로 요청할 때 호출되는 함수이며, PlcStack-edgeResponseFilterLambdaXXX 함수는 Origin에서 CloudFront로 응답할 때 호출되는 함수입니다.

PlcStack-edgeRequestFilterLambdaXXX 함수를 클릭해서 살펴보겠습니다. 해당 함수는 브라우저에서 전달된 쿠키에 tokenId가 없으면 새로 발급하여 DynamoDB에 저장하고 사용량이 많은 경우 Origin으로의 요청을 제어하는 역할을 수행합니다.

edgeResponseFilterLambdaXXX 함수를 살펴보면 해당 함수는 발급된 tokenId를 브라우저가 유지할 수 있도록 Response 헤더에 쿠키값을 설정해주는 역할을 수행합니다.

이제 아래 그림과 같이 Legacy Stack을 통해서 만들어진 ALB와 사용자 사이에 CloudFront와 Lambda@Edge가 위치하고 이를 이용하여 사용자의 요청을 중간에 제어할 수 있게 되었습니다.

핸즈온랩에서는 직접 브라우저에서 CloudFront를 바라보도록 도메인을 변경하여 접속하였습니다.
하지만 실제 대고객 서비스를 하는 환경에서는 Route 53과 같은 DNS를 이용하여 ALB에 연결된 커스텀 도메인을 관리할 것입니다.
이때 사용자의 브라우저가 바라보는 Domain의 목적지를 ALB가 아닌 CloudFront로 설정하면 사용자가 URL을 직접 바꾸지 않고도 적용이 합니다.
하지만 이번 실습에서는 Route 53은 사용하지 않고, CloudFront의 기본 도메인을 사용합니다.

이제 토큰을 저장하는 저장소를 살펴보겠습니다.
AWS 콘솔에서 DynamoDB 서비스로 이동합니다.

다음 DynamoDB 콘솔의 Tables 메뉴에 접속하면 2개의 테이블이 만들어져 있습니다.

PlcStack-tokens로 시작하는 테이블은 번호표(token)를 관리하는 테이블입니다. PlcStack-status로 시작하는 테이블은 현황을 관리하는 테이블입니다.

PlcStack-tokensXXX 테이블을 클릭하고 우측 상단의 View items 버튼을 클릭합니다.

Run 버튼을 클릭하고 조회된 아이템을 살펴보면 하나의 토큰이 만들어져 있습니다.
이 토큰은 CloudFront를 통해 샘플 애플리케이션에 접속할 때 Lambda@Edge를 통해서 생성된 것입니다.
만약 생성된 토큰이 없다면 CloudFront 도메인으로 다시 접속을 하고 확인을 해보시면 됩니다.

아래와 같이 토큰 저장소가 만들어 진 것을 확인하셨습니다.

4.3.2 Heartbeat처리 영역

웹환경에서의 사용자는 언제든지 브라우저를 닫거나 다른 사이트로 이동하는 행위를 할 수 있습니다.
따라서 사용자가 아직 사이트에 접속하고 있는지를 확인할 방법이 필요합니다.
이 실습에서는 사용자가 브라우저에서 사이트에 접속해 있는 동안 백그라운드로 동작하는 자바스크립트를 통해 5초 간격으로 heartbeat를 수집합니다. 이를 위해 S3, API Gateway, Lambda를 이용합니다.

AWS 콘솔에서 S3 서비스로 이동합니다.

Buckets 에 있는 목록에 3개의 S3 버킷이 생성되어 있습니다.

plcstack-staticwebbucket로 시작하는 S3 버킷에 들어갑니다.

waiting/static 폴더에 들어가면 아래와 같은 정적컨텐츠가 배포되어 있습니다.
앞서 살펴보았던 CloudFront에서 이 S3를 Origin으로 지정을 하고 있고, S3 버킷에 있는 정적 컨텐츠가 호스팅 됩니다.

이제 AWS 콘솔에서 API Gateway 서비스로 이동합니다.

API Gateway 콘솔에서 APIs 메뉴에 들어가서 runtimeApi를 클릭합니다.

좌측 Resources 메뉴에서 /heartbeat 리소스의 POST 메소드를 클릭합니다.

우측 끝에 연결된 람다함수를 클릭합니다. 아래와 같이 API Gateway를 통해서 호출되는 것을 확인할 수 있습니다. 이 함수는 브라우저에서 주기적으로 호출되는 heartbeat 요청을 받아서 DynamoDB에 있는 토큰의 heartbeatTime을 갱신합니다.
이를 이용하여 뒤에서 살펴볼 별도의 로직에서 일정시간 이상 heartbeat가 오지 않는 토큰을 삭제할 수 있습니다.

API Gateway 서비스로 돌아가서 좌측에 Stages 메뉴로 들어가서 default를 클릭합니다.
아래와 같이 API를 처리하기 위한 Endpoint를 가지고 있고 이를 통해서 heartbeat를 업데이트하는 Lambda 함수가 호출됩니다.
마찬가지로 앞서 살펴보았던 CloudFront에서 이 API Gateway의 Endpoint를 Origin으로 지정을 하고 있고, 클라이언트 코드에서는 이 Endpoint로 바로 접근하지 않고, CloudFront의 도메인을 통하여 heartbeat를 전송하도록 되어 있습니다.

4.3.3 토큰체크 및 관리 영역

이제 웹사이트를 떠난 사용자를 체크해서 이미 떠난 경우는 토큰을 삭제하고, 새로운 사용자를 입장시키는 역할을 처리하는 로직이 필요합니다. 이를 위해 DynamoDB의 stream과 Lambda, SQS를 이용합니다.

흐름은 아래와 같습니다.

1. DynamoDB에 새로운 토큰이 생성되면 stream을 통해서 Lambda가 실행됩니다.
2. 이 Lambda는 SQS에 10초의 DelaySeconds를 추가하여 토큰을 입력합니다.
3. 이후 이 SQS를 바라보고 있는 Lambda는 해당 토큰을 검사하여 20초 이상 heartbeat요청이 없으면, 해당 토큰을 삭제하고 새로운 사용자를 입장시킵니다.
4. 만약 heartbeat이 요청이 정상적인 토큰이라면 다시 10초의 DelaySeconds를 추가하여 SQS에 입력하고 이후 다시 토큰을 체크하는 과정을 거칩니다.

AWS 콘솔에서 DynamoDB 서비스로 이동합니다.

좌측 Tables 메뉴를 선택하고, PlcStack-tokensXXX 테이블을 선택합니다.

Exports and streams 탭을 클릭하고 하단까지 스크롤하여 Trigger 부분을 살펴봅니다.

PlcStack-tokenCreateListenerLambdaXXX Lambda 함수를 클릭하면 해당 Lambda 함수로 이동합니다.
이 Lambda 함수는 DynamoDB에 변경사항이 발생하면 자동으로 트리거 됩니다.

하단의 Code 영역을 살펴보면 DynamoDB에 데이터가 새로 입력되는 경우 이 함수는 SQS에 데이터를 입력합니다.
이때 DelaySeconds를 10초로 주어 10초 동안은 Queue에서 데이터를 꺼낼수 없도록 설정합니다.

이제 AWS 콘솔에서 SQS 서비스로 이동하겠습니다.

2개의 Queue가 생성되어 있습니다.

PlcStack-tokenCheckQueueXXX 를 클릭하고 하단의 Lambda triggers 탭을 선택합니다.

Trigger를 선택하고 View in Lambda 버튼을 클릭합니다.

아래와 같이 SQS의 데이터를 기반으로 호출되는 Lambda 함수를 확인할 수 있습니다.
이 함수는 SQS에 있는 토큰 데이터를 확인해서 주기적으로 heartbeat가 발생하지 않는 데이터를 삭제하는 역할을 합니다.

그럼 현재 사이트를 사용중인 접속자, 대기중인 접속자가 얼마나 되는지를 어떻게 알 수 있을까요?
DynamoDB는 집계쿼리를 바로 실행하는데는 적합하지 않습니다. 따라서 이를 위해 별도의 통계테이블을 구성합니다.
이때 DynamoDB의 stream을 통하여 Lambda를 트리거하고 이 Lambda에서 데이터를 집계하여 status 테이블에 저장합니다.

AWS 콘솔에서 DynamoDB 서비스로 이동합니다.

좌측 Tables 메뉴를 선택하고, PlcStack-tokensXXX 테이블을 선택합니다.

Exports and streams 탭을 클릭하고 하단까지 스크롤하여 Trigger 부분을 살펴봅니다.

PlcStack-statusUpdaterLambdaXXX Lambda 함수를 클릭하면 해당 Lambda 함수로 이동합니다.
이 Lambda 함수는 DynamoDB에 변경사항이 발생하면 자동으로 트리거 됩니다.
이 함수는 DynamoDB의 변경사항을 이용하여 별도의 DynamoDB 테이블인 PlcStack-statusXXX에 통계 정보를 저장합니다.

4.4 Management 환경 검토

이제는 관리자가 모니터링하고 관리하기 위한 환경을 살펴보겠습니다. 아키텍처는 아래와 같습니다.

흐름은 아래와 같습니다.

1. CloudWatch의 Schedule 이벤트를 통하여 1분단위로 Step Functions를 호출합니다.
2. Step Functions은 10초 마다 6회 동안 Lambda를 호출합니다.
3. Lambda는 앞서 살펴보았던 status 테이블의 데이터를 주기적으로 조회하고 CloudWatch의 Custom 메트릭으로 저장합니다.
4. 이후 CloudWatch Alarm 통해 메트릭이 임계치를 초과하는 경우 Alarm이 발생합니다.
5. 이 CloudWatch Alarm은 SNS와 연동되어 리소스를 프로비저닝 할 때 입력했던 관리자 이메일로 Notification을 발송하게 됩니다.

AWS 콘솔에서 CloudWatch 메뉴로 이동합니다.

좌측 메뉴에서 Events -> Rules 메뉴를 선택합니다.

생성되어 있는 Rule을 선택하고 Actions –> Edit 버튼을 클릭합니다.

Rule을 살펴보면 1분 마다 호출되도록 되어 있고, Target으로 Step Functions state machine이 지정되어 있습니다.

이제 Step Functions를 살펴보겠습니다.
AWS 콘솔에서 Step Functions 메뉴로 이동합니다.

State macines메뉴에서 목록내에 이미 생성되어 있는 State Macnine의 이름을 클릭합니다.

상세화면에서 Definition 탭을 클릭합니다.

해당 State machine은 10초마다 PlcStack-metricGeneratorLambdaXXX 함수를 호출합니다.

실행과정은 Executions 탭으로 들어가서 목록 중에 하나를 클릭하면 아래와 같이 작업 상태를 시각화 해서 볼 수 있습니다.

이제 AWS 콘솔에서 Lambda 서비스로 이동합니다.

상단의 검색창에서 metric 이라고 입력하고 엔터를 입력하면 아래의 PlcStack-metricGeneratorLambdaXXX 함수가 검색됩니다.

클릭해서 들어가면 주기적으로 DynamoDB에서 status 테이블을 조회하여 CloudWatch로 메트릭을 저장하는 로직을 살펴볼 수 있습니다.

그럼 이 CloudWatch 메트릭 데이터는 어떻게 확인 할 수 있을까요?

AWS 콘솔에서 CloudWatch 메뉴로 이동합니다.

좌측에 Metrics -> All metrics 메뉴로 이동합니다.
Custom Namespaces에 있는 plc 항목을 클릭하고, domain 항목을 클릭합니다.

아래와 같이 좌측의 체크박스를 클릭하면 상단의 그래프를 확인 할 수 있습니다.
InUse는 현재 사용중인 사용자수, Waiting은 대기하고 있는 사용자수, MaxInUse는 스로트링의 기준이 되는 사용자수 입니다.

이제 CloudWatch메뉴에서 좌측의 Alarms -> All alarms 메뉴를 클릭합니다.

조회된 Alarm을 클릭합니다.

하단으로 스크롤해서 상세내역을 살펴보면 알람의 조건과 알람이 발생했을 때 실행될 Actions이 기술되어 있습니다.

그러면 Actions에 기술된 SNS 토픽을 살펴보겠습니다.
AWS 콘솔에서 SNS 메뉴로 이동합니다.

좌측에서 Topics 메뉴를 선택합니다.

Subscriptions에 CDK를 이용하여 리소스를 생성할 때 입력했던 관리자 이메일이 입력되어 있습니다.
이를 통하여 이메일로 알림을 받을 수 있습니다.
또한 Lambda나 SQS 등의 다른 AWS 서비스와도 연동이 가능하고 AWS Chatbot을 통해서 Chime이나 Slack로도 알림을 받을 수 있습니다.

마지막으로 이러한 환경은 실습에서 직접 실행해보신 것처럼 CDK를 통하여 프로비저닝하고 관리합니다.

이제 환경구성이 완료되었습니다. 다음 부하테스트를 통해 실제로 동작하는지 확인해보겠습니다.

5. Hands-on: 부하테스트

5.1 RDP Client 설치

부하테스트 환경은 별도의 Windows서버를 생성하여 해당 서버에서 jmeter를 실행하여 처리합니다. 따라서 이 Windows서버에 접속하기 위한 RDP Client가 필요합니다.
실습자의 PC환경이 Windows인 경우 기본적으로 RDP Client가 내장되어 있으므로 해당 Client를 사용하시면 됩니다.
하지만 실습자의 환경이 Mac 등의 환경인 경우 별도의 RDP Client 설치가 필요합니다.
RDP Client가 설치되지 않으신 경우 아래 링크를 통해 Microsoft에서 제공하는 RDP Client를 설치하고 실습을 진행하시기 바랍니다.

• https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-clients

아래 내용은 Mac에 별도로 설치한 RDP Client 기준으로 안내합니다.

5.2 jmeter 환경 생성

Cloud9으로 접속하여 터미널에서 아래의 명령어를 실행하면 EC2 Windows를 생성하고 Jmeter를 설치합니다.

cd ~/environment/dna-serverless-hol/jmeter
npm install
cdk deploy --all --require-approval never

5.3 jmeter 환경 접속

환경 생성이 완료되면 AWS콘솔 EC2 메뉴에 들어가서 좌측 Instances 메뉴로 이동합니다.
그리고 Name이 JmeterStack/jmeterServer로 표시된 EC2를 선택하고 Connect 버튼을 클릭합니다.

팝업에서 RDP client 탭을 선택하고 Get password 버튼을 클릭합니다.

아래와 같은 메시지가 나올 경우 잠시 기다렸다가 다시 접속합니다.

Browse 버튼을 클릭하고 2.4 EC2 Key Pair 생성에서 다운로드 받았던 Key Pair 파일을 선택합니다.

Decrypt Password 버튼을 클릭합니다.

이제 Administrator의 비밀번호를 확인할 수 있습니다.

RDP client를 실행하고 Public DNS을 입력하고 User name은 Administrator로 입력합니다.

Password 를 입력하고 Windows서버에 접속합니다.

바탕화면에 있는 jmeter아이콘을 클릭하여 jmeter를 실행합니다.

파일열기 아이콘을 클릭하여 사전에 만들어놓은 bin 디렉토리에 있는 dna-serverless-hol.jmx 파일을 오픈합니다.

User Defined Variables 에 선언된 변수에서 ENDPOINT에 해당하는 부분을 CloudFront의 도메인으로 변경합니다.

이 때 http:// 부분은 넣지 않고 도메인만 입력합니다.

CloudFront 도메인을 찾으려면 AWS 콘솔에서 CloudFront 서비스로 이동한 후 Distributions 메뉴에서 목록에 있는 Distribution ID를 클릭하면 아래와 같이 확인할 수 있습니다.

이제 Jmeter에서 상단의 시작 아이콘을 클릭하면 부하가 발생되기 시작하며, 부하는 500개의 Thread를 통하여 5분간 지속됩니다.

정상적으로 부하가 발생되고 있는지 확인하려면 아래의 Aggregate Report 메뉴를 클릭하여 현재 진행상황을 확인할 수 있습니다.

부하테스트가 진행중인 상황에서 CloudFront URL을 이용하여 시스템에 접속하면 사용자는 대기페이지로 자동으로 전환됩니다.
만약 정상적으로 접속이 된다면 브라우저에서 Private 모드로 창을 띄운 후 접속을 시도하시면 됩니다.

이후 백그라운드에서 token의 상태를 체크하다가 입장이 가능한 상태가 되면 메인페이지로 자동으로 이동하게 됩니다.

CloudWatch의 커스텀 메트릭을 통해 현재의 상태를 확인할 수 있습니다. CloudWatch 콘솔은 다음의 순서로 확인을 하시면 됩니다. Metrics -> All metrics -> Custom Namespaces -> plc -> domain -> 전체체크 -> Graphed metrics 탭 -> 하단 우측에 Period 10 Seconds 선택
시간은 custom을 클릭해서 15분으로 설정합니다.

하단의 Period를 반드시 10초로 설정해야 메트릭을 정확히 확인할 수 있습니다.

CloudWatch의 Alarms -> In Alarm 메뉴로 이동하면 알람이 발생한 것을 확인할 수 있습니다.

그리고 입력했던 실습자의 이메일로 CloudWatch Alarm이 전달된 것을 볼 수 있습니다.

5분이 지나서 Jmeter의 부하발생이 종료되면 점차적으로 사용자에게 발급되었던 토큰이 삭제되고 사용자는 정상적으로 입장할 수 있습니다.

6. 마무리

6.1 CloudFormation Stack 삭제

• 스택을 선택하고 Delete 버튼을 클릭하여 삭제합니다.
  

• 스택은 아래의 순서로 삭제하시면 됩니다.

  • JmeterStack 삭제
  • PlcStack 삭제
  • LegacyAppStack 삭제
  • LegacyInfraStack 삭제
  • CDKToolkit 삭제

• 아래와 같이 삭제가 진행되며 PlcStack에서 생성하는 Lambda@Edge의 경우 바로 삭제가 되지 않습니다.
  

• 이와 같은 오류메시지가 나오는 경우 다시 Delete 버튼을 클릭하면 자원을 유지할 것인지에 대하여 선택하는 체크박스가 나오게 됩니다. 이 때 체크박스를 선택하고 Delete stack 버튼을 클릭합니다. 해당 자원은 이후 수작업으로 삭제를 진행해야 합니다.
  

6.2 Cloud9 환경 삭제

• 생성한 환경을 선택하고 Delete 버튼을 클릭하여 삭제합니다.
  

6.3 나머지 자원 삭제

• S3 버킷 삭제

  • S3 버킷은 안에 파일이 있는 경우 바로 삭제가 불가능합니다.
  • 반드시 실습에 사용된 S3 버킷 만 삭제하시기 바랍니다.
  • 먼저 버킷을 선택하고 Empty 버튼을 클릭하여 버킷의 내용을 지운 다음, 순차적으로 삭제를 진행하시면 됩니다.
    
    
    

• Lambda@Edge 삭제

  • CloudFormation으로 삭제되지 않은 Lambda@Edge는 Lambda 콘솔메뉴에서 직접 삭제해야 합니다.
  • 하지만 아래의 메시지와 같이 Lambda@Edge의 경우 일정시간 동안은 삭제를 할 수 없으므로 1시간 정도 이후에 삭제를 진행하시기 바랍니다.
    

• IAM Role 삭제

  • IAM 콘솔에서 Roles 메뉴에 들어갑니다.
  • dna-serverless-hol-cloud9-role을 선택하고 Delete role 버튼을 클릭해서 삭제를 진행합니다.

• 이제 모든 실습이 완료되었습니다. 수고하셨습니다.