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

당일 신규 유저 유입 13,844

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

당일 신규 유저 유입 24,070

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

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

사건 후 ab(apache benchmark)를 통해 실시한 부하 테스트 중 한 장면

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

• 당시 상황
  • 신규 유입 유저 2만명대. DAU는 그 이상으로 추정. 당시 셋업된 서버 현황은 cafe24 퀵서버 호스팅 기반 웹서버 2대, CDN서버 2대, DB서버 2대, 신규 유저 가입이 많아 write DB에 먼저 무리가 갈 것을 법했지만 그렇지는 않았습니다. 추후 원인은 엉뚱한 다른 곳에서 발견됩니다.
• 문제 발생
  • 시작 직후에 생각보다 빠르게 즉시 서버가 다운. 문제는 web1, DB, 이미지 서버는 거의 idle한 상태인데 web2 서버와 로드밸런서만 다운되는 현상을 발견.
• 사후 원인 점검
  • 로드밸런서가 정상적으로 동작하지 않아 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를 통한 부하 테스트를 추가로 실시했습니다.
• 회고
  • 바닥부터 만든 서비스로 이정도의 트래픽을 실시간으로 관찰해볼 수 있는 값진 경험이었습니다. 소규모 서비스 및 토이 프로젝트만으로는 겪기 어려운 상황이기 때문입니다.
  • 사내에서는 서버 호스팅 업체로 항상 cafe24의 서버 호스팅을 사용했습니다. 가성비가 매우 좋았기 때문에 소규모 서비스 구축에는 매우 적합한 선택이라고 생각합니다.
  • 그러나 스포티비나우 같은, 서비스가 커지고 scale-out이 필요한 상황에서 cafe24 엔지니어와 직접 조율하는 등 불편함과 커뮤니케이션 오류 리스크가 있습니다. 그래서 저는 이런 리스트를 감당하는 것 보다는 AWS를 도입 및 공부를 하여 대응 및 관리를 하는 것이 지출이 더 커 보여도 리스크를 감안하면 더 낫다고 주장했습니다.
  • 하지만 결국 AWS 도입은 추후를 기약하는 것으로 결론지었습니다. 이유는 아래와 같습니다.
    1. 어차피 반복 작업을 하다보면 cafe24 엔지니어들과 조율 과정은 루틴화 될 것
    2. AWS를 적용하게 되면 분명 추가적인 AWS 공부가 필요
    3. CTO가 구축해둔 CI/CD 스크립트에도 수정 소요가 들어가는데 굳이 그렇게 할 메리트가 없음
    4. 서버 비용 증가