[AWS] EC2 서비스를 활용한 A/B Testing

리브·2022년 9월 16일
0

AWS

목록 보기
1/1
post-thumbnail

안녕하세요?
마이스터고에 다니는 3학년 개발자 리브입니다.

드디어 첫 게시물을 올리는데, 그 주제로 선택한 것은 A/B Testing입니다!

제가 가장 처음 제대로 구현해본 AWS architecture라는 사실이 선택의 이유입니다.

그럼 시작해볼까요?


0. 기본환경 Setting

A/B Testing Github repository

실습을 원하신다면 위의 repository에 필요한 source file을 올려놓았으니 사용하셔도 좋습니다 : )


1. VPC 구축

AWS Infra를 구축할 때, 가장 먼저 해야되는 것은 당연히 VPC setting입니다.

어떤 Rigeon, 몇개의 AZ를 사용할지 선택해야하죠. AZ를 한개만 사용하는 것은 추천드리지 않습니다. 낮은 확률이지만 AZ가 터질 가능성도 고려를 해야하기 때문이죠.

한마디로 고가용성을 고려한다면 최소 2개이상의 AZ를 선택해주는 것이 좋습니다. 물론 너무 많은 AZ를 사용한다면 비용의 문제가 생길 수 있겠죠?

위의 git repository에 있는 vpc.yaml 로 CloudFormation Stack을 만들어보겠습니다.

VPC와 함께 public subnet에 위치한 bastion Instance 역시 함께 생성되기 때문에 awscli 실행 시 ec2 서비스에 등록된 keypair를 지정해줘야해요!

aws cloudformation create-stack --stack-name a-b-testing --template-body file://A-B-Testing/vpc.yaml example template --parameters ParameterKey=Keypair,ParameterValue=MyKeypairName

위의 명령어를 통해 awscli로 Stack을 생성하면, VPC 환경 세팅이 완료됩니다.


2. Test Instance

ASG를 만들기 위해서는 userdata의 작성이 필요해요.

하지만 어떤 명령어가 필요한지 정확하게 알 수 없기 때문에 test용 instance를 하나 만들어서 script를 작성해야합니다.

#!/bin/bash

yum install -y git
yum install -y docker 
systemctl start docker

cd /opt
git clone https://github.com/JeongAnNa/A-B-Testing.git
cd A-B-Testing/app-a/

AZ=$(curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone)

docker build --build-arg LOCAL_AZ=$AZ -t app .
docker run -p 80:3000 -d app

userdata A Ver

위의 script는 test를 통해 작성한 Userdata script입니다.

version B의 경우에는 app-a를 app-b의 경로로 바꿔주기만 하면 돼요!


3. Lanch Template

Auto Scaling Group에 사용할 Lanch template을 만들어보겠습니다.

우선 EC2Lanch Templates console에 접속합니다.

위 사진에 있는 Create Lanch Template 버튼을 클릭해 템플릿을 만들어줍니다. 템플릿의 이름과 버전을 입력해주세요. AMI와 Instance type, ssh 접속 시 사용할 keypair를 선택해줍니다.

저는 amazon linux 2, t2.micro 를 선택해줬어요!

subnet은 private subnet을 선택해주세요. a version이면 private-a subnet, b version이면 private-b subnet을 선택하면 됩니다!

Security Group의 경우 하나의 sg를 공유해도 됩니다. Inboud rule은 bastion과 alb의 sg id를 명시해주면 좋아요!

보안을 고려해 SSH는 Bastion host에서만, HTTP는 ALB에서만 접근할 수 있도록 설정해주세요.
Resource tag를 지정해줍니다. Instance의 Name tag를 설정해야 나중에 어떤 instance가 a인지 b인지 알 수 있어요!마지막으로 미리 테스트해봤던 Userdata를 입력해주고 Create Lanch Template 버튼을 눌러 템플릿을 만들어주세요.
B version을 만들때는 새로운 템플릿을 만들지 않고 새로운 버전을 만들어줄거에요.

Details에 들어가 Action -> Modify template를 통해 새로운 버전을 만들면 됩니다. a라고 써져있는 부분들을 모두 b로 바꾸고, private-c subnet을 선택해주면 됩니다.

이렇게 Verison 탭을 선택했을 때, 2개의 버전이 나온다면 Lanch Template 만들기는 끝입니다!


4. Auto Scaling Group

다음으로는 Auto Scaling Group 를 만들어보겠습니다.
먼저 EC2Auto Scaling Groups 탭에 들어가 Create Auto Scaling group 버튼을 클릭해주세요.
ASG의 이름을 입력해주고, Lanch tmplate을 선택합니다. A 버전의 ASG는 A 버전의 템플릿을, B ASG는 B 템플릿을 선택해줘야해요!
Network 옵션은 아까 만들어뒀던 VPC의 Private subnet을 모두 선택해주면 됩니다.

Load balancer와 ASG를 연결해줍니다. 만들어둔 lb가 없으니 Attach to a new load balancer를 선택해줍니다. 2번째 ASG를 만들때는 기존에 만들어둔 alb와 연결해주면 돼요.

외부에서도 접속 가능하게 만들기 위해서 Scheme는 Internet-facing 으로 선택해주고, subnet은 전부 public subnet으로 선택해주세요.
ALB의 Target group 도 새로 만들어줍니다. tg 역시 2번째 asg는 지금 만든 것과 연결해주면 됩니다!
ASG의 Size 역시 지정해주어야 합니다. 최소, 최대, 그리고 처음 만들어질 Instance의 갯수를 지정해줍니다. 저는 Desired: 2 , Minimum: 1 , Maximum: 3 으로 지정해줬어요!

나머지는 모두 특별히 지정하지 않고 넘어가도록 하겠습니다.

Review Page에서 Create Auto Scaling Group 버튼을 클릭하면 ASG 생성도 끝입니다!

위와 같은 방식으로 B ASG까지 만들어주세요.


5. Application Load Balancer

이제 만들어놓은 ALB의 세부 설정을 해주어야합니다.

우선 Target Group의 health check의 경로를 수정해주겠습니다.

Health check path를 /health 로 수정하고 Save changes 버튼을 눌러 저장해주세요.

다음으로는 ALB의 sg를 새로 만들겠습니다.

Inbound Rule은 http만 어디서나 접근 가능하도록 열어주면 됩니다. 그리고 app의 sg의 Inbound Rule을 http를 alb에서만 접근 가능하도록 새로운 규칙을 추가해주세요.
EC2Load Balanvers 에 들어가 만들어놓은 alb를 선택해주세요 DescriptionSecurity 탭에서 sg를 default sg에서 방금 만든 alb sg로 변경해줍니다.

EC2Target groups에 접속하여 만들었던 tg의 targets 탭을 선택하면 모두 healthy 상태인 것을 확인할 수 있습니다.

이제 ALB의 DNS로 접속하면 이렇게 총 4 종류에 인스턴스가 랜덤으로 나타나는 것을 확인할 수 있습니다!

Target GroupEdit attributes 옵션에 들어가 Stickiness 를 활성화 해주면 지정한 시간동안 한 Instance에 고정되어 새로고침을 해도 같은 화면만 보이는 결과를 얻을 수 있습니다.


6. Scale In / Out

이제 마지막 단계인 Scale in/out 설정을 해볼게요!

먼저 Cloud Watch 서비스의 Alarm 탭으로 접속해 Create Alarm 버튼을 클릭해주세요.

첫 단계는 지표를 선택해야합니다. 선택할 지표는 CPU 사용률에 관련된 지표입니다.

EC2 -> By Auto Scaling Group -> ab-testing-asg-a: CPUUtilization

위의 경로대로 Metrics를 선택한 후 Select metrics 버튼을 클릭해 주세요.

이제 알람을 발생시킬 조건을 설정해주어야 합니다.

위 사진같은 경우는 CPU 평균 사용률이 50% 이상일 때 알람이 생성돼요.

Alarm 이름을 ab-testing-a-scale-in 으로 설정해주고 Create Alarm 버튼을 클릭해 Alarm을 만들어주세요.

이번엔 Scale Out을 위한 Alarm을 만들어보겠습니다.

위와 같은 방식으로 만들면서 알람 생성 조건만 조금 바꿔주면 돼요.
먼저 Scale-in alarm과 같은 metrics를 선택하고, CPU 사용량 평균 10% 이하로 조건을 설정해주기만 하면 됩니다.

Alarm 이름은 ab-testing-a-scale-out으로 설정해주고, Create Alarm 버튼을 클릭해 alarm을 만들어주세요.

B Version의 알람도 위와 같은 방식으로 만들면 됩니다. 단, metrics를 ab-testing-asg-bCPUUtilization으로 선택해줘야 해요.

이제 ASG를 설정하도록 하겠습니다.

먼저 Sacle-In, 즉 사용량 증가 시 새 Instance를 만들어주는 정책을 만들어볼게요.

EC2 -> Auto Scaling GroupAutomatic Scaling 탭에서 Create Dynamic scaling policy 버튼을 클릭합니다.
Policy type는 Simple scaling 으로, policy name은 Scale-In, alarm은 ab-testing-a-scale-in을 선택합니다. alram은 b asg일 경우 ab-testing-b-scale-in를 선택해주세요.

Take the action은 알람 발생 시 무엇을 할지 결정하는 옵션입니다. Scale-In의 경우는 Add 옵션을 선택하여 Instance 1개를 새로 만드는 action을 선택하면 됩니다.

이제 Create 버튼을 눌러 조정 정책을 생성하겠습니다.

다음은 Scale-out 설정을 해보겠습니다.

위 사진처럼 alarm은 A asg의 scale out Alarm을, action은 Remove를 선택하여 Alarm 발생 시 한 개의 인스턴스를 종료시키도록 설정하고, Create 버튼을 눌러주세요.

ab-testing-asg-b 역시 위와 같은 방식으로 Scaling Policy를 만들어주면 됩니다.


7. Overload Test

마지막으로 부하 테스트를 해보도록 하겠습니다.

많은 요청을 보내 CPU의 사용량이 50%까지 늘어났을 때, 새로운 Instance가 만들어지는지를 확인하는 것이죠!

저는 부하 테스트를 위한 도구로 Locust 를 선택했습니다.

pip install locust

우선 pip 명령어로 locust 를 설치해주세요.

locust -f asg-test.py

그리고 제 github repository에 있는 asg-test.py 파일을 위 명령어로 실행시킵니다. 그럼 사진처럼 locust 가 실행되고 있는 port 번호가 나오게됩니다.

http://0.0.0.0:8089 로 접속해주세요!

접속하면 위 사진같은 사이트가 보일거에요. Host 입력 칸에 Alb DNS를 입력하고 Start swarming 버튼을 클릭해주세요.

위 화면이 뜬다면 부하가 발생되고 있는거에요! 부하 테스트를 할 때는 Stickiness 옵션을 비활성화 시키는게 좋아요...
그리고 Cloud Watch 서비스에 접속해 아까 만들어두었던 Alarm을 확인하면 부하가 발생되고 있는 것을 확인할 수 있습니다.

Alarm의 조건을 수정해주세요! Scale-In: 20 , Scale-Out: 5
이렇게 수정해줘야 빠른 테스트가 가능합니다!

2개의 Scale-in Alarm이 In alarm 상태가 되었다면, EC2Auto Scaling Groups 콘솔로 이동해주세요.

위 사진처럼 Instance의 갯수가 Max Size만큼 늘어났다면 Scale-In 정책이 정상적으로 작동한다는 것을 알 수 있습니다.

이제 Locust 콘솔에 들어가 Stop 버튼을 눌러 부하 발생을 종료시켜주세요.

2개의 Scale-out Alarm이 In alarm 상태가 됐다면, 다시 EC2Auto Scaling Groups 콘솔로 이동해주세요.
사진처럼 Instance의 갯수가 1개로 줄어들었다면 Scale-Out 정책 역시 정상적으로 작동한다는 뜻입니다.

이렇게 Scale In/Out이 정상 작동한다면, 부하테스트는 성공입니다.


이상으로 A/B Testing 에 대한 실습은 끝입니다! 실습 완료한 Resouce들은 비용 발생을 막기 위해 모두 삭제해주세요:)

profile
안녕하세요 리브입니다!

0개의 댓글