그랑 블루 판타지를 뒷받침하는 인프라 기술

일본의 데브서밋 컨퍼런스에서

그랑 블루 판타지에 대해서

특징

  • 스마트 폰 RPG
  • 브라우저 게임
  • 협력 플레이, 멀티 플레이

시스템 규모

  • 등록 유저 수 1400만명
  • 월간 300억 PV
  • 100만 query/sec
  • 8만 req/sec
  • 트래픽 12Gbps(CDN 제외)

시스템 구성

  • LB는 BIG-IP
  • CDN은 Akamai

  • HTTP/WebSocket이 프런트 인터페이스

  • Web:Apache+mod_php+mysqli
  • Node:Node.js+twemproxy
  • DB:MySQL+MHA

on-premises, 가상화 환경은 사용하지 않는다

  • 네트워크 통신량이 매우 많다
  • 저 레이턴시를 요구되고 있다
  • 하이 퍼포먼스를 실현하기 위해
    • NVMe SSD나 Fusion-io를 채용
    • 네트워크 IRQ의 멀티 코어 스케일링에 대응한 NIC을 채용

로그 데이터의 대처

소셜 게임과 로그

  • CS 대응, 보충 대응 등의 유저 대응
    • CS 최우선, 몇달 전의 로그를 조사할 필요 있다
  • KPI 지표 취득
  • 시스템 오류 조사
    • 오류 로그 및 SQL 로그
  • 백업
    • 문제 발생 시의 재현(스냅 샷 복원)

로그 데이터의 양은 5TB/day

  • 텍스트 로그(4.8TB/day)
  • DB 인서트 로그(180GB/day)

로그 비대화에 따른 문제

  • 당초는 로그 집약 서버에 전송하고, 로그 저장소에 심야에 rsync를 했었다
  • 로그 비대화로 로그 집약 서버를 분산했지만 로그 전달이 지연되고 CS 대응에 차질을 빚기 시작했다
  • DB에서도 로그가 비대화하여 디스크 용량이 고갈되거나 삽입 처리가 지연

로그 시스템 개선

  • Amazon S3에 로그를 집약
  • 자체 로그 전송 에이전트를 개발
    • 텍스트 로그 전송
      • 1행으로 전송할 수 있는 사이즈 제한을 걷어치우기 위해
      • S3 객체의 프레 픽스를 달다
    • 비동기 MySQL 로그 전송
      • TSV를 S3에 전송, SQS에 메시지 큐를 작성, EC2의 아그리게이터를 모아서 Aurora로

로그를 활용

  • 로그 전송 에이전트 => S3 => BQ, Mackerel, Kibana, Aurora, DWH 분석 등

Kibana

  • 액세스 로그, AP 로그, 오류 로그에서 통계 정보를 비주얼화
    • 응답 시간이나 느린 URL이나 오류 수 등
    • 특정 지역별 오류를 가시화
      • 특정 구역의 통신 장애 등을 특정시키기 위해

Mackerel

  • Apache 응답 시간을 집계
    • 2초 이상의 분포를 가시화
    • twitter의 키워드 검색도 가시화
      • “그랑 불루 무거운 “등의 tweet

로그 데이터의 대처 정리

  • Amazon S3에 집약
  • 비동기 마이크로 서비스화
    • 비동기 처리로 게임 시스템과는 분리
  • 독자 에이전트의 개발
    • 핵심 기술은 자체적으로 개발하는 정책

실시간 통신 고속화

쌍방향 실시간 통신이 필요한 곳

  • 채팅에서 메시지 교환
  • 멀티 배틀에서의 파라미터 반영

쌍방향 실시간 통신

  • WebSocket 도입
  • Node.js로 구현

실시간 통신 서버 구성

  • 서버에서는 복수 Room이 붙어 있다
    • 클라이언트는 Room 단위로 그룹화
  • 아키텍처
    • 밸런싱 관리 서버 모델
    • Pub/Sub 메시지 모델

밸런싱 관리 서버 모델

  • 관리 서버가 클라이언트나 Room의 이력을 관리
  • 관리 서버의 redundancy를 고려해야 해서 복잡해진다

Pub/Sub메시지 모델

  • 메시지 큐를 통해서 서버 간에 교환
  • 메시지 큐가 보틀 넥이 되기 쉽다
  • 브로드캐스트에 의한 통신량 증가
  • Redis Pub/Sub가 보틀 넥이 되었다. 또 스케일 아웃에 과제
    • 세트 구성으로 스케일 하도록 8세트까지 증대

Room 대응 L7 로드밸런스를 개발

  • 애플리케이션은 RoomID를 URL 쿼리 문자열에 붙인다
  • RoomID의 해시 값을 사용하여 분산

Nginx L7로드 밸런서+Lua

  • Nginx는 WebSocket의 LB
  • RoomID에서 Node.js프로세스로 라우팅
  • Lua로 분산 로직 구현
  • Consistent Hashing을 활용
  • Node의 헬스 체크도 한다(자동 분리)

Nginx 자원 상황

  • 동시 19,000 TCP 세션으로 서버의 CPU 사용률은 3% 정도
  • 부하 낮아서 집약한 결과, 포토 고갈로
  • 커널 파라미터 조정하거나 TIME_WAIT의 잔류 시간을 짧게 하기 위해서 커널 리빌드를 해도 따라잡지 못했다
  • 서버에 복수의 IP 주소를 부여하고, 많은 포토를 사용할 수 있도록 하였다
  • 현재는 12만 세션/1대를 다루도록 되어 있다

Cygames 인프라가 중요하게 여기는 것

  • 당연한 것을 당연하게 한다
    • 보틀넥을 만들지 않는 시스템 설계
    • 마른 기술(검증된 기술)을 채용하여 안정화를 목표로
  • 어플리케이션 로직을 추상화한다
    • redundancy, 분산 등의 로직은 시스템에서 흡수·추상화
    • 다른 프로젝트에 대한 전개를 용이하게 한다
  • 핵심 기술은 자신들이 구현한다



출처: http://d.hatena.ne.jp/rx7/20170216/p1


이 글은 2017-07-05에 작성되었습니다.