1. 개요
- 목적
Virtual Wainting Room 사용 시 동시 처리량을 조절하는 Inlet strategy를 이해하고 활용한다.
- Virtual Waiting Room?
이 솔루션은 대량 트래픽 버스트 발생 시 웹사이트로 수신되는 사용자 요청을 버퍼링 할 수 있는 기능을 제공한다.
2. Inlet strategy
- 타겟 사이트에 더 많은 사용자를 수용하기 위하여 Virtual Waiting Room의 Serving counter에 대하여 증가 시점과 증가량을 결정할 때 사용되는 전략이다.
- Inlet strategy를 이해하기 위해서는 ElastiCache for Redis에서 관리하는 Serving count와 Queue counter의 의미를 알아야 한다. 참고로 각 Counter의 상한 값은 9,223,372,036,854,775,807이다. 만약 상한 값에 도달했다면 리셋을 해야 한다.
✓ Serving counter: 타겟 사이트에서 제공할 수 있는 요청 수
✓ Queue counter: 타겟 사이트에서 제공된 요청 수
✓ 서비스 가능한 요청 수 = Serving counter - Queue counter
- 솔루션에서 Inlet strategy로 Periodic과 MaxSize 2가지 예제를 제공하고 있다.
- Periodic
✓ CloudWatch 룰이 1분 주기로 PeriodicInlet 람다 함수를 호출하여 지정된 수만큼 Serving counter를 증가시키는 전략이다.
✓ 파라미터
▷ event start time, end time: 람다 함수가 실행되는 시간 범위
▷ increment ammount: Serving count 증가 단위
▷ CloudWatch custorm alarm (option): 설정된 alarm이 ok일 때 람다 함수 동작
- MaxSize
✓ MaxSizeInlet 람다 함수는 타켓 사이트가 동시에 수용할 수 있는 최대 클라이언트 수로 구성하는 전략이다.
✓ SNS 토픽({stack-name}-inlet-strategy-MaxSizeInletSns-*)에 퍼플리시되면 MaxSizeInlet 람다 함수가 호출된다.
✓ 람다 함수는 아래 메시지를 이용하여 얼마만큼 Serving counter를 증가시킬지 결정한다.
✓ SNS(Simple Notification Service) 토픽 메시지
▷ completed: list of request IDs to be marked completed
▷ abandoned: list of request IDs to be marked abandoned
▷ exited: number of transactions that have completed
3. Prerequisites
- AWS CloudFormation에서 aws-virtual-waiting-room-getting-started.template를 배포한다.
✓ 배포에 관한 자세한 내용은 Virtual Waiting Room on AWS를 참조하면 된다.
✓ https://solutions-reference.s3.amazonaws.com/aws-virtual-waiting-room/latest/aws-virtual-waiting-room-getting-started.template
- 배포가 완료되면 총 3개의 stack(CoreModule, AuthorizerModule, SampleModule)이 생성된다. 생성된 stack의 parameter와 output은 아래와 같다.
✓ CloudFormation stack parameters
✓ CloudFormation stack outputs
4. Sample Inlet strategy - Periodic
A. Periodic strategy 배포
- AWS CloudFormation에서 aws-virtual-waiting-room-sample-inlet-stragegy.template를 배포한다.
✓ https://solutions-reference.s3.amazonaws.com/aws-virtual-waiting-room/latest/aws-virtual-waiting-room-sample-inlet-strategy.template
- 배포시 다음과 같이 stack명과 파라미터를 입력한다.
✓ EventId와 PrivateCoreAPIEndPoint 파라미터는 각자 환경에 설치된 core stack의 parameter와 output 값을 참조해서 입력한다.
✓ Inlet strategy는 Periodic를 선택한다.
✓ IncrementBy 파라미터는 1분 주기로 Serving counter를 증가시킬 값으로 10을 입력한다. 각자 운영할 타켓 사이트의 처리 용량을 고려해서 적절한 값을 입력하면 된다.
✓ StartTime, EndTime 파라미터는 Periodic strategry가 수행될 시작 시간과 종료 시간이다. 디폴트 값을 사용해도 된다.
B. Periodic strategy 배포 리소스 확인
- CloudFormation stack이 배포한 리소스는 다음과 같다.
- 배포된 EventBridge rule로 PeriodicInlet 람다 함수를 1분 주기로 호출하도록 설정되어 있다. 주기는 변경할 수 있다.
- 배포된 PeriodicInlet 람다 함수는 아래와 같다. 람다가 실행 시 참조하는 Serving counter는 INCREMENT_BY 환경변수로 전달된다. 아래와 같이 해당 변수를 수정하면 람다 함수가 실행 시 바로 참조한다.
C. Periodic strategy 동작 확인
- CloudFormation SampleModule stack에서 설치된 Control Panel UI에 접속 후 Serving Position 값을 살펴보면 1분 단위로 10씩 증가됨을 확인할 수 있다.
D. Periodic strategy 개선 방안
- Sample Periodic strategy은 특정 조건에서 의도하지 않게 트래픽이 폭증할 수 있다. 예를 들어 Serving counter가 1분 단위로 10씩 증가하고 주기마다 요청이 10보다 적었던 상황에서 18:13분에 40개 요청이 발생되면 30개 요청이 Waiting room에서 빠져나가 서비스 요청을 하게 된다. 나머지 10개는 Waiting room에 머무르게 된다.
- Periodic stragegy에 아래 2가지를 적용하면 위와 같은 현상을 개선할 있다.
✓ 주기 단축: EventBridge rule에서 PeriodicInlet 람다 함수 호출 주기를 1분에서 각 사이트의 상황에 맞게 변경
✓ 증가 량 로직 변경: PeriodicInlet 람다 함수에서 주기마다 INCREMENT_BY 만큼 증가하는 로직을 변경
▷ 기존: Serving count + INCREMENT_BY
▷ 개선: Serving count + NEW_INCREMENT_BY = INCREMENT_BY - (Serving counter - queue counter)
0 < NEW_INCREMENT_BY <= INCREMENT_BY
- Virtual Waiting Room 솔루션에서는 Queue counter를 조회하는 API를 제공하지 않기 때문에 추가로 개발해야 한다. 해당 값은 ElastiCache for Redis에서 조회할 수 있다.
$ wget https://redismodules.s3.amazonaws.com/redis-stack/redis-stack-server-6.2.2-v4.rhel7.x86_64.tar.gz
...
$ tar xzf redis-stack-server-6.2.2-v4.rhel7.x86_64.tar.gz
...
$ sudo cp redis-stack-server-6.2.2-v4/bin/redis-cli /usr/bin
...
$ export REDISCLI_AUTH='Mpz5xAdJ3V$v$HvUn8W2WW2IK>>lA7nIc>^&$l!RDV!mN$-c95Ek!F>Xl>iGdULOk^<XC9lBYl1R5u79iase<5i&fy^QVbYqQJ52-#KB4Cd$J9tLAmoCfj275pPAZaNR'
$ redis-cli -h master.awr13mgas2awt4tf.odcoyh.apn2.cache.amazonaws.com -p 1785 --tls
master.awr13mgas2awt4tf.odcoyh.apn2.cache.amazonaws.com:1785> get queue_counter
“61”
master.awr13mgas2awt4tf.odcoyh.apn2.cache.amazonaws.com:1785> get serving_counter
"51"
master.awr13mgas2awt4tf.odcoyh.apn2.cache.amazonaws.com:1785>✓ 설치된 ElastiCache 클러스터명은 CloudFormation {stack-name}-CoreModuleStack의 리소스 탭에서 조회한다.
✓ ElastiCache 클러스터 엔드포인트(호스트) 명은 ElasitCache 콘솔에서 조회한다.
✓ Redis 암호는 Securets Manager 서비스의 Secret value 탭에서 조회한다.
✓ Redis의 키를 조회하는 로직은 '{stack-name}-CoreModuleSta-GetQueueNum-*'에서 참조할 수 있다.
5. Sample Inlet strategy - MaxSize
A. MaxSize strategy 배포
- CloudFormation에서 aws-virtual-waiting-room-sample-inlet-stragegy.template를 배포한 경우 업데이트를 통해 MaxSize strategy를 배포할 수 있다.
B. MaxSize strategy 배포 리소스 확인
- CloudFormation stack이 배포한 리소스는 다음과 같다.
- 배포된 MaxSizeInlet 람다 함수는 아래와 같다. 람다가 실행 시 참조하는 Max Size 값은 환경변수에 정의되어 있다.
C. MaxSize strategy 동작 확인
- Control panel UI의 Increment Serving counter를 이용하여 Serving counter를 MaxSize와 같게 한다.
- Waiting room UI를 이용하여 2개의 요청을 발생시킨다.
- Waiting room UI에서 ‘Check out now’를 클릭 시 Waiting room에서 나오게 되고 JWT 토큰이 발급된다. DynamoDB에서 각 요청에 대한 request_id와 JWT 토큰을 조회된다.
- MaxSize를 3으로 설정하였기 때문에 추가 요청이 발생될 경우 1개 요청은 Waiting room에서 나오게 되며, 나머지는 Waiting room에서 대기하게 된다.
- SNS topic에 Waiting room을 나온 2개의 요청에 대하여 완료 요청하면 {stack-name}-inlet-stragegy-MaxSizeInlet-* 람다 함수가 호출되며, 람다 함수는 발급된 JWT 토큰을 종료시키고 Serving counter를 증가시킨다.
✓ CloudWatch에서 람다 함수의 로그를 조회한 내용이다. Serving counter가 3에서 5로 증가하였다.
✓ DynamoDB에서 발급되었던 JWT 토큰의 상태는 완료로 변경되었으며, Active Token은 2에서 0으로 변경되었다.
- SNS topic에 abandoned 메시지를 전달할 경우 completed와 동일하게 동작된다. 다만 DynamoDB에서 조회하면 session_status 값만 다르다.
D. MaxSize strategy 고려사항
- 적용할 시스템의 처리 용량을 고려해서 MaxSize를 설정한다.
- 클라이언트 세션 사용이 완료되면 SNS에 Completed 메시지를 전달해서 세션에 발급된 토큰을 사용 중지시킨다.
- 클라이언트가 세션 완료 로직을 호출할 수 없을 경우를 고려하여, 적절한 세션 타임아웃을 설정한다.
6. 참고 사이트
- https://docs.aws.amazon.com/solutions/latest/virtual-waiting-room-on-aws/solution-components.html
- https://docs.aws.amazon.com/solutions/latest/virtual-waiting-room-on-aws/design-considerations.html
'AWS > Solutions' 카테고리의 다른 글
| Virtual Waiting Room on AWS (3) | 2022.08.09 |
|---|
댓글