대량 트래픽 처리를 위한 Virtual Waiting Room

Virtual Waiting Room

안녕하세요. 원더월에서 백엔드 서비스를 개발하고 있는 유근수라고 합니다. 이번 블로그의 주제는 Virtual Waiting Room(이하 VWR) 입니다.

원더월에서는 인기 아티스트의 굿즈 판매, 페스티벌 티켓 판매 등 사용자들이 특정 시간에 몰리는 이벤트들이 자주 발생합니다. 그래서 순간 급증한 요청들을 잠시 대기시키는 대기열 시스템이 필요해졌습니다.

여타 다른 서비스에서도 흔하게 접할 수 있는, 사용자에게 몇명이나 대기중인지, 서비스되기까지 얼마나 걸릴지 등을 보여주기 위한 시스템입니다.

기존에 해당 기능을 제공해주는 유료 서비스를 사용하다가, 재밌을 것 같아서 (사실은 비용절감), AWS에서 21년 말에 소개한 Virtual Waiting Room 아키텍처를 도입하기로 결정했습니다.

기존 원더월 백엔드는 대부분 Serverless Framework를 이용하여 서버리스 아키텍처로 구성되어 있어서 VWR도 서버리스로 구현하게 되었습니다.

VWR 구조

AWS 문서에 있는 아키텍처를 그대로 구현하지는 않고, 불필요한 부분들은 제거하고 필요한 부분들은 추가하는 등 저희 입맛에 맞게 재구성하게 되었습니다.

구조를 좀 간략하게 소개를 해드리자면, 아래 그림처럼 동작하게 됩니다.

1. ApiGateway를 통해 사용자의 요청이 들어오면, SQS 로 요청 정보를 쌓아둡니다.
2. 사용자는 SQS 를 통해 받은 응답의 MessageID 로 서비스가 가능한지, 얼마나 기다려야 하는지를 계속 polling 합니다.
3. SQS 에 쌓인 request 들을 10개 단위 배치로 Lambda를 통해 request 별로 대기 번호를 할당합니다.
4. 대기 번호 중, 서비스가 가능한 대기 번호인 경우는, polling 요청이 오면 서비스 토큰을 발급해줍니다.
5. 서비스 토큰을 받은 사용자는 해당 토큰으로 실제 서비스를 요청하고, 굿즈 구매나 티케팅 등 원하는 서비스를 이용할 수 있습니다.
6. 서비스 이용이 끝난 사용자는 완료 api 를 보내고, 완료 api 를 처리하는 Lambda 는 서비스 가능한 대기 번호를 늘려줍니다.

위에서 말씀드렸듯이 VWR 의 아키텍처는 서버리스를 기반으로 하고 있습니다. (ApiGateway + Lambda)
그리고 SQS와 Redis(ElasticCache)가 이 아키텍처에서 핵심적인 역할을 하고 있습니다.

SQS는 ApiGateway Integration 기능을 통해, ApiGateway로 들어오는 요청을 바로 저장하고, 해당 메시지에 대한 응답을 줌으로써 대량의 트래픽에 대한 버퍼 역할을 하게 됩니다.

그리고 Redis의 atomic increment 기능을 이용해서 대기열을 COUNTER 개념으로 구현합니다.

QUEUE_COUNTER	요청이 들어오면 +1씩 증가합니다. 요청마다 atomic한 하나의 대기 번호를 갖게 됩니다.
SERVING_COUNTER	초기값은 서비스를 허용할 수로 설정합니다. 그리고 서비스가 완료된 사용자가 생길때마다 +1씩 증가합니다.
TOKEN_COUNTER	서비스 토큰을 발급한 개수를 추적합니다.

예를 들어, 한번에 100명의 서비스로 제한한다고 가정하면,
SERVING_COUNTER=100, QUEUE_COUNTER=0 으로 시작합니다.

만약 300명의 요청이 들어오면, QUEUE_COUNTER=300 까지 올라가고,
그 중 SERVING_COUNTER 값보다 작거나 같은 1~100번의 사용자들은 서비스 토큰을 받게 됩니다.

서비스를 완료한 사용자가 생기면, SERVING_COUNTER는 +1이 되어서 101이 되고, 그러면 101번 사용자는 서비스 토큰을 받게 됩니다.

실제 서비스를 구현하면서 헤멨던 부분을 2가지 말씀드리고 싶습니다.

첫번째로 애먹었던건, ApiGateway 와 SQS 를 바로 연결하는 설정이었습니다.

해당 기능을 해주는 serverless plugin을 2개 발견했지만, 작동하지 않게 된지 오래된 상태였습니다. 그리고 기존에 저희가 이미 사용하던 ApiGateway v1 버전에서 해당 기능을 테스트해보려고 구글링을 했지만 쉽게 찾을 수 없었습니다.

결국 serverless.yml 파일에서는 설정하지 못하고, ApiGateway 에서 직접 resource와 method를 생성하고, request 를 SQS로 연결하고, 일부 설정들을 바꿔주는 식으로 테스트를 해볼 수 있었습니다.

하지만, ApiGateway v2 에서는 serverless.yml 에서 손쉽게 설정이 가능합니다.
설정 정보는 아래와 같습니다.

provider:
    httpApi:
        name: VirtualWaitingRoom

functions:
    AssignQueue:
        handler: src/assign_queue/lambda.handler
        events:
            - sqs:
                  arn:
                      Fn::GetAtt:
                          - VWRQueue
                          - Arn
                  batchSize: 10
                  maximumBatchingWindow: 5

resources:
    Resources:
        VWRQueue:
            Type: AWS::SQS::Queue
            Properties:
                QueueName: VWRQueue

        VWRApiRoute:
            Type: AWS::ApiGatewayV2::Route
            Properties:
                ApiId:
                    Ref: HttpApi
                RouteKey: 'POST /start'
                Target: !Join
                    - /
                    - - integrations
                      - !Ref VWRApiIntegration

        VWRApiIntegration:
            Type: AWS::ApiGatewayV2::Integration
            Properties:
                ApiId:
                    Ref: HttpApi
                CredentialsArn:
                    Fn::GetAtt:
                        - VWRRole
                        - Arn
                RequestParameters:
                    MessageBody: '$request.body'
                    QueueUrl:
                        Ref: VWRQueue
                PayloadFormatVersion: '1.0'
                IntegrationType: AWS_PROXY
                IntegrationSubtype: SQS-SendMessage
                ConnectionType: INTERNET

        VWRRole:
            Type: 'AWS::IAM::Role'
            Properties:
                RoleName: VWRRole
                AssumeRolePolicyDocument:
                    Version: '2012-10-17'
                    Statement:
                        - Effect: 'Allow'
                          Principal:
                              Service: 'apigateway.amazonaws.com'
                          Action:
                              - 'sts:AssumeRole'
                Policies:
                    - PolicyName: VWRPolicy
                      PolicyDocument:
                          Version: '2012-10-17'
                          Statement:
                              Action:
                                  - sqs:SendMessage
                              Effect: Allow
                              Resource:
                                  - Fn::GetAtt:
                                        - VWRQueue
                                        - Arn

v1에서 테스트할때와는 다르게, v2에서는 SQS의 응답이 저희에게 익숙한 json이 아닌 xml을 반환하기 때문에,
클라이언트에서 xml 파싱이 필요합니다.

두번째로 고생했던건, 서비스 토큰을 발급 받고 이탈한 사용자가 생겼을때의 처리였습니다.

AWS 문서에서는 발급한 토큰을 DynamoDB에 저장을 해두고, 배치로 만료된 토큰을 처리하고 있었지만, 저희는 해당 기능을 Redis keyspace notifications 를 이용하기로 하고, 토큰을 Redis에 저장했습니다.

expire 알림을 받기 위해서, expire 이벤트를 subscribe하는 Lambda를 만들었는데, 결론부터 말씀드리면 Lambda를 통해 expire 알림을 처리할 수 없었습니다.

subscribe에 등록해둔 handler 함수의 async 로직이 제대로 동작하지 않았고, 외부 호출도 잘 동작하지 않았습니다. 결국은 해당 로직은 ECS를 통해 서비스하도록 변경하였습니다.

마무리

이번 프로젝트를 진행하면서 그동안 많이 다뤄보지 않았던 서버리스나 SQS, Redis, ECS 에 대해 좀 더 알게 됐고, 많이 배울 수 있는 계기가 되었습니다. 개인적으로 굉장히 재밌고 의미있던 프로젝트였던 것 같습니다.

다음에 또 다른 흥미로운 주제로 만날 기회를 기대하겠습니다. 앞으로도 많은 관심 부탁드립니다.

끝까지 읽어주셔서 감사합니다. :D