DB부하 멈춰!

1. 들어가며

안녕하세요. 원더월 개발팀 한상진(y0on2q) 라고 합니다.
원더월은 클래스, 아트랩 등의 비디오 컨텐츠 사업을 진행중에 있습니다.
다양한 데이터 분석 및 통계 작업을 위하여, 유저의 동영상 시청 로그를 실시간으로 저장하고 있습니다.
해당 서비스의 변화 과정을 살펴보고, 현재 구조에 대해서도 알아보도록 하겠습니다.

1.1. 기존 구조 및 문제점

기존에는 동영상 시청로그를, 10초마다 RDB에 저장하고 있었습니다.
서비스 규모가 커지면서, 여러 문제점이 나타나기 시작했습니다.

• 첫 번째로, DB에 부하가 발생된다는 것입니다.
  하나의 유저가 10초 혹은 더 짧은 시간 동안 DB에 데이터를 추가하고 있었습니다.
  다수 유저의 동시 시청의 경우에도, RDB에 부하가 발생했습니다.
  또한 통계를 위한 쿼리를 사용하는 경우에도, production DB에 부하가 발생하고 있었습니다.

• 두 번째로, DB의 낭비가 발생한다는 점입니다.
  유저에게 직접 필요하지 않은 로그성 데이터를, RDB에 저장함으로 인한 비효율이 발생하고 있었습니다.

2. 새 기술 스택을 선택하며

이에 원더월 개발팀에서는, RDB에서 해당 테이블을 분리하기로 했습니다.
이 과정에서 다양한 제약 및 고려사항이 발생하였습니다.

1. 추후 통계등에 사용하기에 편리하여야 한다.
   해당 데이터를 기반으로 마케팅, 통계 분석 등 다양한 팀에서 데이터를 활용하여야 합니다.
   하여 통계에 용이하고, 추후 data warehouse 로의 확장가능성을 고려하여야 했습니다.

2. production DB에 부하를 주지 않아야 한다.
   다수의 사용자가 영상을 시청하는 동안에도, 다른 서비스들이 로그 저장으로 인한 병목의 영향을 받지 않는것이 필요했습니다.

3. 기술스택의 고려

이에 원더월 개발팀에서는, 총 4가지의 기술을 고려하고, 테스트하였습니다.

1. Atlas + MongoDB

처음으로 고려했던 것은, MongoDB 와 해당 데이터베이스 기반의 Atlas 였습니다.
NoSQL의 특성상, 비정형 데이터의 효과적인 저장이 가능하고, 실제 DB와의 격리도 가능하였습니다.
다만 Atlas의 관리 리소스가 추가로 필요한 점이 단점으로 작용하였습니다.
또한 NoSQL의 특성상 통계등의 작업을 할 때, 집계 함수의 부재 등으로 인한 퍼포먼스 및 통계 작업에서도 비효율적이라 판단하였습니다.

2. AWS DynamoDB

다음으로 고려했던 것은, aws DynamoDB 였습니다.
AWS 인프라와 통합 가능하다는 점과, 실제 DB 와의 격리도 가능하였습니다.
다만 트래픽을 기반으로 계산해본 결과, 높은 비용이 하나의 걸림돌이었습니다.
또한 문서나 레퍼런스가 아직은 풍부하지 못하다고 느껴 선택하지 않았습니다.

3. Google BigQuery

세번째로 고려한 것은, Google BigQuery였습니다.
빅쿼리는 구글에서 개발한 통계, 분석 용 도구입니다.
큰 규모의 데이터를 다룰때, 그리고 안정성도 어느 정도 보장된 기술이었습니다.
다만 로그성 데이터의 저장을 위해 gcp를 구성하여야 하여, 인프라 관리포인트의 증가가 단점으로 작용하였습니다.
또한, 실시간성 데이터를 바로 확인하고, 처리하기에도 조금의 단점이 발생하였습니다.

최종 기술스택

저희는 aws kinesis기반의 data stream 인 firehose를 사용하기로 결정했습니다.
결정한 배경은 아래와 같습니다

1. Full-managed Service

aws firehose는 full-managed service입니다.
이를 통해, 트래픽에 따른 인프라의 관리 등의 리소스를 더욱 줄일 수 있을 것으로 기대했습니다.
또한 다른 aws 기술과의 통합도 용이할것이라고 판단했습니다.

2. Glue + Athena를 통한 쿼리

firehose stream으로 온 데이터를, SQL로 다루기 위한 기술이 이미 존재합니다.
이를 통해, 통계 분석용으로 사용하면서, 실서버의 부하를 줄일 수 있을 것이라고 판단했습니다.

After.

완성된 아키텍쳐는 아래와 같습니다.

1. Client에서 요청이 오면, 해당 요청을 람다가 SQS에 전송합니다.
2. SQS를 구독 중인 handler 가 큐에 들어온 데이터를 firehose에 전송하게 됩니다.
3. firehose는 일정 시간, 혹은 일정 크기가 넘는 경우, S3로 데이터를 전송하게 됩니다.
4. lambda cron job 을 통해, glue를 통한 데이터 크롤러를 동작시킵니다.
5. glue를 통한 크롤링이 진행되면, s3에 데이터가 저장되게 됩니다.
6. 저장된 데이터는, Athena를 통해 쿼리하고, 필요한 데이터는 RDS에 저장하게 됩니다.
   
   

마무리하며.

지금까지, 원더월 개발팀에서 진행한 로그성 데이터베이스 아키텍쳐 구축에 대하여 설명드렸습니다.
이뿐만 아니라 원더월 개발팀에서는 다양한 개발적 고민과 챌린징이 기다리고 있습니다.
원더월과 함께하길 원하신다면, 채용공고를 통해 지원 부탁드립니다.
감사합니다 :)