‍

이번 아티클에서는 서버 증설에 필요한 것. 직관과 데이터를 기반한 결정에 대해 이야기 해보려고 합니다. 더 들어가서는 사용 중인 인프라의 정보(서버타입, 개수, 사용량)를 AWS Firehose로 수집 후 Athena 로 분석하고 시각화 하여 데이터를 통해 서비스 운영에 통찰력를 넣는 과정을 설명하려고 합니다.

‍

목차

• FANDOM 서비스 운영 이야기
• 데이터 수집 및 시각화 아키텍쳐
• 생각해보기

‍

FANDOM 서비스 운영 이야기

‍

팬덤 유저 이야기

스테이지랩스는 “더 많은 아티스트와 팬들이 일상에서 소통하고 즐거운 경험을 공유할 수 있는 플랫폼”을 만들어가고 있는 스타트업입니다. 저희는 youmeOn, tin, Mnet Plus 등의 아티스트와 팬을 이어주는 다양한 서비스를 운영하고 있습니다. 그 중에 Mnet Plus 서비스를 예시로 팬덤 서비스의 특징을 이야기 해보려고 합니다.

팬(fan)이라는 유저들은 활동적이며 능동적이고 단합력과 화력이 좋은 고객들입니다. 나의 최애(아티스트)의 활동에 관심이 큽니다. 예를들어 “나의 최애가 커뮤니티에 일상을 공유 했다.”, “나의 최애가 음악 방송에서 다른 아티스트와 투표 경쟁을 한다.” 등의 이벤트가 생기면 엄청난 관심과 화력으로 참여합니다. Mnet Plus 의 투표 이벤트를 이용하여 조금 더 팬덤 유저의 행동 패턴을 더 이해해 보겠습니다.

투표하는 유저는 충분한 시간이 있더라도 오픈과 동시에 초반에 참여합니다. 실시간 투표는 음악 방송과 함께 1시간 ~ 2시간 동안 유저가 좋아하는 아티스트에게 투표하여 응원하는 기능입니다. 아래의 그림은 투표가 진행되는 시간 동안 1분 단위로 투표양을 집계한 그래프입니다. 1시간 30분의 투표 기간 중 20분안에 70%의 유저 참여가 발생한 것을 알 수 있습니다. 이런 유저 화력은 아티스트를 응원하는 팸덤의 규모, 팸덤의 성향, 방송의 이슈 정도에 따라 추이가 달라 지지만, 초반 유저 참여도 만큼은 50%~70% 정도로 유지가 됩니다.

‍

‍

서버 증설 이야기

이렇듯 팬덤 서비스 유저들의 활동은 평소 대비 크고 갑작스럽게 치솟는 트래픽이 되어 돌아오게 됩니다. 이 때 적당한 성능의 서버가 준비 되어 있지 않다면, 곧바로 서비스 장애로 이어질 것 입니다. 우리에게 필요한 것은 서버 증설입니다! 서버를 증설한다는 것은 10개의 일을 할 수 있는 1개의 서버를 2개로 늘리거나, 10개의 일을 할 수 있는 서버를 100개의 일을 할 수 있는 서버로 교체하는 것을 의미합니다.

‍

추가적인 서버를 증설 해야 할 만큼의 트래픽이 들어오는 경우는 두가지의 패턴이 있습니다. 미리 예정 되어 있는 이벤트에 유저의 큰 관심이 몰릴 것이라는 첩보가 들어온 경우, 한밤중에 인기 아티스트가 팬들과 소통을 시작했을 경우 등 예측이 가능 하거나 예측이 불가능한 패턴을 가지게 됩니다.(당연하게도) 예측이 불가능한 트래픽 유입은 평소 대비 여유롭게 서버 증설을 해두고 자동 서버 증설(Auto Scaling) 기능으로 추가적인 서버를 확보합니다. 예측 가능한 트래픽 유입은 과거에 진행했던 비슷한 이벤트의 규모와 비교하여 추론하고 직관을 통해 서버를 증설 하게 됩니다.

(인기 아티스트의 팬덤간에 투표 경쟁이 예상 되어 서버를 증설하는 과정)

서버를 적게 증설한다면 비용을 아낄수 있지만 안정성이 떨어집니다. 서버를 많이 증설한다면 안정성이 올라가지만 비용도 같이 올라가게 됩니다. 그렇기 때문에 이벤트에 유입 될 트래픽을 지난 이벤트와 비교하여 적절히 예측하고 지난 이벤트에서 증설한 서버와 비교하여 적절한 증설양을 찾는 것이 중요합니다. 즉, 데이터를 기반으로 과거를 통해 미래를 추론해야합니다.

‍

‍

과거에 100의 트래픽이 들어 왔고 중간 사양의 서버 2대를 사용해 평균 서버 사용률이 50% 미만이었다. 현재는 과거와 비교해 2배의 트래픽이 예상 되는데 어떤 사양의 서버를 몇대 사용해야 할까? 를 판단 할수 있는 데이터가 필요 합니다!!

서버 증설을 하기 위해 필요한 과거의 데이터는 아래의 항목이 있습니다.

• 서버의 성능 타입
• 서버의 개수
• 서버의 자원 사용량
• 서버에 유입된 절대적 수치의 트래픽 양
• 유저들의 이벤트 참여 양

‍

데이터의 문제점

AWS에서 이러한 데이터들을 사용하는데 약간의 문제가 있습니다. 첫번째 문제는 “c6gn.2xlarge 인스턴스 유형을 5개 사용 했었다.” 등의 사용 했었던 서버 타입 별 개수를 쉽게 알수 있는 방법이 없습니다. (Cost Explorer/ Cloud Trail/ AWS Config 등)

두번째로, EC2 인스턴스의 CPU 사용량, 사용 가능 Memory 등의 서버의 사용량을 나타내는 지표들은 AWS Cloud Watch Metric 에 수집이 되어 집니다. 하지만, Cloud Watch Metric에 수집된 데이터는 시간이 지날 수록 기간의 해상도가 떨어지고, 15개월 이상의 데이터는 보관하지 않습니다. 이는 꽤 치명적인데 가령, 1년을 넘어 2년전에 진행 했던 블랙 프라이데이 이벤트 때 데이터는 남아 있지 않다는 뜻이죠.

‍

마지막으로, 서버 증설을 하기 위해 필요한 과거의 데이터 5가지가 한곳에 응집 되어있지 않아 가공 하기 어렵고 시각화 하여 통찰력를 도출하기 어렵다는 문제가 있습니다.

‍

데이터 수집 및 시각화 아키텍쳐

데이터의 응집력과 보관 기간의 문제를 해결 하고 인프라의 정보들을 집계 하여 시각화 하기 위해서 자체적인 시스템을 구축하였습니다. 최대한 빠르고 간편하게 만들 수 있는 것에 초점을 맞춰서 손에 익고 구축 되어 있는 도구들을 사용했습니다. 여러 케이스 중 한가지 사례로 봐주시면 좋을것 같습니다.

아래의 그림은 데이터를 수집하고 시각화 하는 아키텍쳐의 구성도 입니다. 프로세스를 따라가면서 이해해보겠습니다.

1. Event Bridge의 Cron 기능을 사용하여 Lambda를 1분 마다 트리거 시킵니다.
2. Lambda 에서 인프라의 Spec(서버 타입&개수) 과 Metric(CPU, RPS 등) 데이터를 수집합니다.
3. 수집한 데이터를 Firehose으로 전송 합니다.
4. Firehose는 S3 에 데이터를 적재합니다.
5. 새로운 파티션을 Glue Data Catalog 에 업데이트 합니다.
6. Athena 는 S3 에 적재된 데이터를 집계 합니다.
7. 집계된 데이터를 Redash 에서 시각화 합니다.
8. ‍

‍

인프라의 성능 타입과 개수는 AWS SDK 의 .describe{~} 메소드를 사용 하면 가져 올 수 있습니다. 아래의 코드는 RDS 클러스터와 인스턴스의 정보를 가져와서 정형화 된 데이터 스키마로 변형하는 코드 예시입니다.

‍

‍

아래의 코드는 RDS의 CPU 사용량을 AWS SDK 의 cloudwatch.getMetricData 를 사용하여 수집하고 정형화 하는 코드입니다. AWS SDK를 사용하면 RDS 뿐 아니라 EC2, Redis, Memcached등의 인프라 정보를 수집해 올 수 있습니다.

‍

수

집한 데이터를 Firehose 로 전송하면 Firehose에서 S3에 JSON 포멧으로 적재 해줍니다.

‍

‍

미리 만들어 둔 Glue 테이블에 신규 날짜(yyyy-mm-dd)에 대한 파티션을 추가해주면 Athena 에서 데이터를 쿼리 할수 있는 상태가 됩니다.

‍

‍

마지막으로 Redash 와 Athena 를 연동 하면 데이터들을 시각화 하여 통찰력를 도출 할수 있는 상태가 됩니다.

실제 데이터의 수치를 노출 할 수 없지만 아래의 대시보드를 통해서 다음과 같은 통찰력를 도출 할 수 있습니다. “저번 투표 이벤트 기간 중 최대 초당 요청양은 1000 이였고 RDS 2xlarge 4대를 운영 하였으며 RDS의 CPU 사용량은 50%로 비교적 안정적이었다.” 이러한 통찰력은 다음번 빅 이벤트로 인해 서버를 증설을 할 때 지표가 되어 줄수 있는 데이터가 되게 됩니다.

‍

‍

생각해보기

여기까지 서버 증설은 과거의 데이터를 기반으로 추론해야 한다고 말했고, 스테이지랩스에서는 어떻게 데이터를 수집하고 보관하여 시각화를 통해 서버 증설을 위한 통찰력을 얻기 까지의 이야기를 들려드렸습니다. 하지만 우리는 데이터만 준비 된다면 1년전 진행 했던 같은 이벤트로 현재 진행하는 이벤트의 서버 수요를 정확하게 맞출 수 있는 것인가 생각해 보아야 합니다.

1년전에 진행 했던 같은 이벤트라고 하더라도 그 사이 개발자가 추가한 새로운 코드나 변경한 코드가 있을 것이고 그것으로 인해 프로그램의 성능이 느려진 상태일 수 있습니다. 또는 1년 동안 쌓여온 데이터가 2배 혹은 10배가 되어 기존의 SQL 으로는 이전보다 느린 성능을 보이고 있을 수도 있습니다. 결국, 데이터를 기반 하되 개발자의 직관도 추가 하는것이 중요하다는 말을 하고 싶습니다. (또는 부하 테스트 등을 하여 현재 상태를 측정하거나!)

‍