실시간 스포츠 중계 플랫폼 개발을 통한 트래픽 급증 경험

스포티비나우는 자체 개발팀 없이 외주로 운영되던 서비스였고, 저희가 그 개발을 맡고 있었습니다. 그래서 아래에 나오는 서버 증설이나 인프라 전환 같은 결정은 저희가 판단해서 바로 실행할 수 있는 것이 아니라, 본사 쪽에 요청하고 승인을 받아야 하는 구조였습니다.

2017년 8월 27일 일요일 08시 - 메이웨더 vs 맥그리거

당일 신규 유저 유입 13,844

이 경기는 KBS 2TV에서도 지상파로 중계했습니다. (아카이브)

지상파가 함께 틀어준 날인데도 유료 가입만 13,844건이 들어왔습니다. 아래 차트의 수치는 무료·유료·무료체험 가입을 나눠 집계한 것입니다.

경기 당일 네이버 실시간 급상승 1위가 “kbs2”, 2위가 “메이웨더 맥그리거 중계”, 3위가 “스포티비 나우”였습니다.

2017년 12월 9일 토요일 - 동아시안컵 한중전

당일 신규 유저 유입 24,070

상황 정리 및 대처 시도 - 12월 9일 한중전

• 당시 상황
  • 신규 유입 유저 2만명대. DAU는 그 이상으로 추정. 당시 셋업된 서버 현황은 cafe24 퀵서버 호스팅 기반 웹서버 2대, CDN서버 2대, DB서버 2대, 신규 유저 가입이 많아 write DB에 먼저 무리가 갈 법했지만 그렇지는 않았습니다. 추후 원인은 엉뚱한 다른 곳에서 발견됩니다.
• 문제 발생
  • 시작 직후에 생각보다 빠르게 즉시 서버가 다운. 문제는 web1, DB, CDN서버는 거의 idle한 상태인데 web2 서버와 로드밸런서만 다운되는 현상을 발견.
  • 16시 27분에 장애가 발생해 복구 후에도 트래픽 제어를 걸어야 했고, 17시 50분에야 정상화되었습니다. 이후 환불 조치가 진행되었습니다.
• 사후 원인 점검
  • 로드밸런서가 정상적으로 동작하지 않아 web2에만 트래픽이 몰리는 것이 원인이었습니다. 로드밸런서가 http request를 보내 response code가 200으로 돌아와야 정상으로 간주하는데 당시 web1 서버로 root 주소에 request를 보내면 404를 리턴하여 비정상 상태로 간주하고 web2로만 트래픽을 보냈던 것이었습니다.
  • 당시에는 로드밸런서가 http로도 health를 체크한다는 생각을 못했으나 나중에 공부해보니 L7 스위치는 http로도 health-check를 합니다.
  • 즉 사전에 health-check를 어떻게 하는지에 대한 커뮤니케이션 혹은 리서치 후 동작여부를 체크했어야 하는데 ( 아니어도 보통 http로 많이 합니다 ) 그렇지 못함이 원인인 것 같습니다.
• 추후 대처
  • 각 서버를 3대씩 늘려 총 15대 서버 구축, 호스팅에서 제공하는 모니터링 정보 대신 직접 모니터링 시스템을 구축하였습니다.
  • 리팩토링, redis 캐시 도입, css/js merge, svg spriting, gzip 도입, fpm/MySQL/nginx 옵션값 조정 후 apache benchmark를 통한 부하 테스트를 추가로 실시했습니다.
  • 다만 이 정도로는 부족하다고 판단해 본사 쪽에 추가 증설을 요청했지만 반영되지 않았습니다.

사건 후 ab(apache benchmark)를 통해 실시한 부하 테스트 중 한 장면. 12월 12일 기준으로 web1과 web2가 고르게 트래픽을 받고 있습니다.

2017년 12월 23일 토요일 21시 - 엘 클라시코

당일 신규 유저 유입 100,852, DAU는 그 이상 추정

한중전의 4배 규모였습니다. 증설 요청이 반영되지 않은 채로 맞은 경기였고, 경기 시작 직후인 21시 10분에 서버 장애가 발생했고, 긴급 복구를 진행하면서 동시에 트래픽 제어를 걸어 21시 38분에 정상화되었습니다. 그 사이에는 유료 결제를 한 이용자도 중계를 보지 못했고, 이후 환불 조치가 진행되었습니다.

이 장애는 당시 기사로도 다뤄졌습니다. “몰리는 접속자들을 감당하지 못하며 서버관리에 실패했다. 일부 이용자들은 돈을 내고도 중계를 보지 못했다”고 적혀 있습니다.

포티비 ‘엘 클라시코’ 독점 중계가 남긴 아쉬움 (아카이브)

지상파 중계 없이 유료 독점이었다는 점도 경기 전부터 논란이었습니다.

스포티비 나우, 엘클라시코 생중계…축구 한일전처럼 유료라고? (아카이브)

회고

• 바닥부터 만든 서비스로 이 정도의 트래픽을 실시간으로 관찰해볼 수 있는 값진 경험이었습니다. 소규모 서비스 및 토이 프로젝트만으로는 겪기 어려운 상황이기 때문입니다.
• 사내에서는 서버 호스팅 업체로 항상 cafe24를 사용했습니다. 초기 유저가 없을 때 굳이 러닝커브를 감수하고 AWS를 도입하는 건 자원 낭비라는 것이 개발팀장의 판단이었고, 그래서 가성비가 좋은 8만원짜리 퀵서버호스팅을 도입해왔습니다. 소규모 서비스에는 맞는 말이기도 합니다.
• 실제로 제가 이전 직장에서 프로토타입용 서비스를 만들 때를 생각하면 기본적인 기능만 이용해도 약 10만원 조금 넘게 나왔는데 퍼포먼스는 더 떨어졌기 때문에, 그게 맞다고 생각해왔습니다.
• 그러나 스포티비나우 같은, 서비스가 커지고 scale-out이 필요한 상황에서는 cafe24 엔지니어와 직접 조율하는 등 불편함과 커뮤니케이션 오류 리스크가 있습니다. 그래서 저는 이런 리스크를 감당하는 것보다는 AWS를 도입 및 공부를 하여 대응 및 관리를 하는 것이 지출이 더 커 보여도 리스크를 감안하면 더 낫다고 개발팀에 제안했습니다.
• 하지만 팀 내에서 논의한 끝에 AWS 도입은 추후를 기약하는 것으로 결론지었습니다. 이유는 아래와 같습니다.
  1. 어차피 반복 작업을 하다보면 cafe24 엔지니어들과 조율 과정은 루틴화 될 것
  2. AWS를 적용하게 되면 분명 추가적인 AWS 공부가 필요
  3. 개발팀장과 개발팀에서 구축해둔 배포 프로세스 및 코드에도 수정 소요가 들어가는데 굳이 그렇게 할 메리트가 없음
  4. 서버 비용 증가