[Case Study] 빅히트엔터테인먼트
The Customer
The Challenge
아티스트의 새로운 앨범 출시, 공개방송 신청, 팬 클럽 전용 앱 등 아티스트와 관련된 많은 이벤트를 수행합니다. 각 이벤트는 글로벌하게 진행되며, 전 세계에 흩어져 있는 수많은 팬들이 이벤트 서비스에 접근하게 됩니다. 현재 이 아티스트들의 팬클럽 수는 글로벌하게 1000만여명이 넘습니다. 따라서 우리는 글로벌한 위치에서 동시에 보내지는 요청들을 처리해야 합니다. 이벤트 유형으로는 선착순 접수, 정시 신규 콘텐츠 출시 등 동시간에 많은 사용자들이 몰리는 경우가 대부분입니다. 원본 서버는 서울 리전에 보유하며 전 세계 이용자들의 수요에 맞는 인프라를 준비해야 하며, 예상치 못한 수요에도 대응해야 합니다.
The Solution
고객이 제공하는 서비스의 워크로드 특성은 다음과 같이 파악합니다. 가장 먼저 과거에 수 차례 진행되었던 이벤트의 CloudWatch Metric 값 추이를 분석합니다. 분석 결과에 기반하여 예상되는 실 수요 사용자들의 요청을 커버 할 만한 인프라 크기 및 수량을 결정합니다. 예상되는 수요에 맞게 인프라 부하 테스트를 진행합니다. 부하 테스트에 따라 Web, Was, DB 각 티어별 사이즈 및 수량을 결정합니다. 최초 구성하였던 m4.4xlarge 2대이용시 CPU 사용률이 50%미만에서 원하는 목표치를 이루었기 때문에 사이즈를 하향조정하였습니다. 그러나 CPU, MEM 사용률보다 Network In/Out 사용량이 많았고, Peak Network Bandwidth가 0.5Gbps 미만 이었기 때문에 더 작은사이즈인 m4.large 사이즈로 조정하였고, 수량은 6대로 조정하였습니다.
웹서버의 External End-Point로 사용중인 ALB에 대하여 Pre-Warming 신청을 하였습니다. 이벤트 시작시기부터 종료시 까지 예상되는 ALB 사용량을 전달하여 ALB 자원을 미리 확보 합니다. 글로벌 사용자의 요청을 수용하려면 CloudFront의 역할이 큽니다. Static Contents와 Dynamic Contents를 구분하여 Behavior를 결정하였습니다. CDN과 웹 Origin구조를 잘 모르시는 고객을 위하여 Origin 분석을 통한 CloudFront 정책 적용 컨설팅을 제공해 드렸습니다. 또한 CloudFront사용의 최적화를 위하여 Pre-Caching을 적용하였습니다. Pre-Caching은 AWS CloudFront에 공식적으로 나오지 않은 기능입니다. 그러나 유사한 결과를 가져올 수 있도록 세계 각국에 퍼져있는 REC(Regional Edge Cache)에 사용자와 동일한 구조로 1회 이상 Request하여 Edge에 미리 캐싱될 수 있도록 사전 작업을 하였습니다.
그럼에도 불구하고 예기치 못한 원본부하가 발생할 수 있습니다. 이에 따른 서비스 장애를 방지 하기 위하여 Auto-Scaling을 본 서비스에 활용하였습니다. 미리 작성한 AMI를 활용하여 임계치로 지정한 NW I/O 를 넘길경우 새로운 인스턴스를 AZ별 1대씩 증설하도록 설계하였습니다. 가장 중요한것을 이벤트시 인프라에 대한 모니터링입니다. 모니터링 환경을 고객 및 파트너사에 구비하여 실시간 모니터링을 지원하였고, 이벤트 종료 후 인프라 사용량에 대한 리포트와 개선사항에 대하여 전달해 드렸습니다.
빅히트엔터테인먼트에서 이벤트간 운영하였던 인프라 현황 중 일부 구성도 입니다.
The Result
이벤트 초기에는 예기치 못한 부하로 서비스의 장애가 일부 발생하였습니다. 그러나 수차례 경험한 끝에 정확한 수요예측에 의한 인프라 설계를 할 수 있었고, 예기치 못한 부하에도 장애를 최소화할 수 있는 구성을 만들 수 있었습니다. 이벤트 종료 후 에도 꾸준한 피드백과 개선사항 수행으로 보다 안정적인 서비스와 높은 사용자 만족도를 확보 할 수 있었습니다.
최신 댓글