NDC 11 자이언트 서버의 비밀

NDC 11 자이언트 서버의 비밀

• 1.
  마비노기 영웅전자이언트 서버의비밀㈜넥슨영웅전 런칭팀 양승명sequoia@nexon.co.kr
• 2.
  발표자 소개@sequoiaxp양승명2002~2005 “다크에덴”서버 프로그래머2007~2010 “마비노기 영웅전” 서버 프로그래머2010~현재 “마비노기 영웅전” 개발 매니저
• 3.
  마비노기 영웅전 소개
• 4.
  자이언트 서버?자이언트 노예
• 7.
  이 발표의 목적자랑(x)단일서버 아키텍처 구현 및 운용 노하우 공유뼈 아픈 자아 성찰 자이언트 서버 구현 결산
• 8.
  경고!!이 발표는 프로그래밍세션입니다.미디어, 업계 외에 계시거나 프로그래밍에 전문 지식이 없을 경우 유용한 내용이 적을 수 있습니다.
• 9.
  목차01. 소개 (이미했음)02. 초기 계획03. 구현 중 이슈04. 런칭 후 알게 된 것05. 결산
• 10.
  일단 자랑
• 12.
  자랑 아님
• 13.
  깜짝 퀴즈이 날문제가 된 요소는 무엇이었을까요?
• 14.
  초기 계획2007년 초
• 15.
  “단일 서버로 만들자”커뮤니티단절신규 유저 장벽운영 비용기술적 도전과제
• 16.
  사실은개발 초기 기획에는MMO요소가 없었어요.단일 서버를 결정할 수 있었던 자신감의 근원
• 17.
  설계 목표Scale-out아키텍처서버를 추가하면성능이 증가하는분산 처리 아키텍처
• 18.
  분산 처리 아키텍처?서로다른 서버들 간의 역할분담이 핵심
• 19.
  기존의역할 분담로그인 서버,게임 서버, 캐시 서버, NPC서버1채널, 2채널, 3채널K대륙 서버, E대륙 서버, 인스턴스던전 서버
• 20.
  기존 아키텍처들특정 서버가병목이 될 수밖에 없거나,늘어난 서버를 유저에게 노출시켜야 하거나,게임 디자인 상 서버를 추가하기가 어렵다.
• 21.
  설계 목표추가 구현이나디자인 변경 없이서버 추가만으로수용량을 증가시킬 수 있는 아키텍처
• 22.
  실마리 발견
• 23.
  GPG 5권 6.1“서비스기반 아키텍처”아이템 서비스, 전투 서비스, AI 서비스…
• 24.
  ServiceFrontendService통합네트워크Service
• 25.
  역할을 서비스로 분담가능한작은 기능 단위를 서비스로 구현한 서비스에 대한 부하 최소화부하가 심할 것 같은 서비스는 여러 개 띄워서 부하 분산“통합 네트워크”가 서비스 간 통신을 중개
• 26.
  액션 플랜통합 네트워크만구현하면,필요한 기능들을 서비스로 추가해서,아키텍처를 확장할 수 있겠다.
• 27.
  통합 네트워크 구현
• 28.
  통합 네트워크 라이브러리서비스구현 및 서비스 간 통신 지원서비스의 물리적인 위치를 게임 로직이 몰라도 되도록 구현
• 29.
  오퍼레이션서비스가 제공하는 기능단위항상 성공하거나 실패하는 것을보장
• 30.
  ServiceOperationFrontendService통합네트워크ServiceBackend
• 31.
  위치 서비스서비스의 실제위치를 다루는 서비스서비스가 뜰 때 위치 서비스에 직접 등록오퍼레이션을 요청할 때 통합 네트워크 라이브러리가 위치 서비스에 자동으로 접속
• 32.
  LocationExecution클라이언트FrontendServiceBackendService
• 33.
  네트워크 레이어 구현오퍼레이션을지원하는 네트워크 모듈 구현하나의 TCP연결을 통해 여러 오퍼레이션 동시 처리 필요서비스 간 TCP 연결 내에서 멀티플렉싱 가상 “파이프”구현파이프를 통해서 오퍼레이션 처리
• 34.
  Operation LayerPipe LayerTCP/IPCORE
• 35.
  “Process” Operation Processor“Request”Operation ProcessorPIPE“yield” 코루틴 사용TCP Connection
• 36.
  게임 로직 코드(예:아이템 파기 코드)DestroyItem op = new DestoryItem(cid, slot);op.Success += () =>{ 성공 메시지 전달; };op.Fail += () => { 실패 메시지 전달; };RequestOperation(“ItemService”, op);실제 코드와는 차이가 있습니다.
• 37.
  개발 프로세스책임을 맡은서비스를 구현그 서비스가 처리할 오퍼레이션들을 구현클라이언트의 요청에 따라 적당한 오퍼레이션을 호출  결과를 클라이언트에 전달
• 38.
  그리고 게임 로직을열심히만들었습니다.
• 39.
  1년여 뒤(2008년)
• 40.
  사내테스트 당시Party ServiceFrontendServiceUnified NetworkStory ServiceCharacter ServiceMicroplay ServiceItem ServicePostal ServiceQuest Service
• 41.
  사내 서비스 후생각보다저조한 성능서비스 1종 = 물리적 서버 1대로도 부족 이대로는 단일서버 서비스 불가
• 42.
  그래서통합 네트워크 개선작업1) 성능 향상  다루지 않음2) 동일한 서비스를 여러 개 띄운 경우 분산 매커니즘 구현 병목이 되는 서비스를 여러 서버 기계에 걸쳐서 여러 개 띄울 수 있도록
• 43.
  분산 매커니즘 구현
• 44.
  서비스에 오퍼레이션 요청DestroyItemop = new DestoryItem(cid, slot);RequestOperation(“ItemService”, op);아이템 서비스가 여러 개면? 둘 이상의 서비스가 같은 아이템에 접근한 아이템은 한 서비스가 처리하도록 보장하는 매커니즘 필요
• 45.
  엔티티분산 처리의 단위“한캐릭터의 인벤토리 전체”“한 캐릭터의 우편함 전체”“전투 1회”등을 하나의 엔티티로 구현하나의 엔티티는 한 서비스에서 담당
• 46.
  엔티티 오퍼레이션ServiceServiceOperationEntityEntityEntityEntityOperationEntityEntityEntityEntity
• 47.
  엔티티 획득같은 종류의서비스가 여러 개 있는 경우 엔티티 중복 로드 방지 프로토콜DB를 통해 동기화 유지
• 48.
  엔티티 간 연결유지엔티티 찾기 매커니즘이복잡하고 비싸다 오퍼레이션을 보낼 때마다 엔티티를 새로 찾으면 낭비엔티티 간에 파이프를 열어두고 유지엔티티가필요없어지면 모든 연결을 닫고 엔티티언로드  로그아웃, 전투 종료 등
• 49.
  변경된 게임 로직코드(로그인할 때)ItemConnection = service.Connect(clientEntity, cid, “ItemService”);(아이템 파기)DestroyItem op = new DestoryItem(slot);op.Success += () => { 성공 메시지 전달; };op.Fail += () => { 실패 메시지 전달; };ItemConnection.Request(op);CID가 오퍼레이션에서 사라짐
• 50.
  크게 보면 이런모양
• 51.
  엔티티 모델 구현성공이제아이템 서비스가 느리면 아이템 서비스를 열 개 띄우고, 캐릭터 서비스가 느리면 캐릭터 서비스를 열 개 띄우고…
• 52.
  추가 기능오퍼레이션 싱크:다른오퍼레이션이 끝날 때까지 기다렸다가 그 결과를 사용해서 처리엔티티옵저버:엔티티가 변경되면 다른 서비스의 엔티티에 알림
• 53.
  어쨌든이 상태로 그랜드오픈2010년 1월
• 55.
  자랑 아님
• 56.
  깜짝 퀴즈이 날문제가 된 요소는 무엇이었을까요?
• 57.
  답 : DB로그DB에 과량의 로그가 INSERT모든 서비스가 같은 DB에 접속
• 58.
  DB의 scale out을간과!!사실은 방법이 없었던 건 아니지만…아직도 DB는 영웅전 게임서버의 병목타개하기 위해 여러 가지 시도 중일단 좋은 사양의 서버로 커버
• 59.
  아키텍처의 문제서버라고 문제없는 건 아니에요…
• 60.
  엔티티릭커넥션 카운팅으로언로드 순환 참조문제언로드 조건 변경 댕글링엔티티분산 GC를 돌릴수도 없고…
• 61.
  랙 전파오퍼레이션이 다른오퍼레이션을 기다림한 서비스만이라도 느리면 연쇄적으로 모든 서비스의 대기 큐가 길어짐일부 오퍼레이션은 근본적으로 많은 오퍼레이션을 기다림 캐릭터 로그인, 배 띄우기등 항해노기, 배 띄우다 시간 초과…
• 62.
  오퍼레이션 폭발한 엔티티에너무 많은 옵저버엔티티의 변경이 너무 많은 서비스에 영향엔티티가 자주 바뀌면 DOS효과
• 63.
  오퍼레이션 오버헤드메시지 시리얼라이즈가여전히 부담실제 프로세싱보다 오퍼레이션 자체가 늘어나는 게 성능에 악영향서비스를 너무 세분화한 게 역효과
• 64.
  서비스 간 로드밸런싱같은 종류의 서비스 사이의 로드 밸런싱랜덤에 의존한 유니폼 로드 밸런싱 서버 머신 간에 사양 차이가 있는 경우?적응형 로드 밸런싱 필요
• 65.
  프론트엔드 비대화클라이언트가 요청프론트엔드가 오퍼레이션으로 변환 프론트엔드가 오퍼레이션 결과 처리프론트엔드가 거의 모든 로직을 내장 메시지 시리얼라이즈만도 바쁜데… I/O 로드와 CPU로드가 모두 과다지금도 프론트엔드가 가장 바쁜 서비스
• 66.
  기타 알 수없는 문제아키텍처의 복잡도에 비해 진단 프레임워크가 약함  문제 발생 시 추적이 어려움실제로 런칭 후 수 개월 간 서버 불안정
• 67.
  자이언트 서버 총평바닥부터만든 닷넷 기반 엔진유연한 scale out이 가능한 아키텍처 구현성능은 만족스럽지 못하다
• 68.
  더 잘할 수있었는데…네트워크 부하를 줄이는 방향으로 서비스 분할병목/부하 실시간 모니터링 및 제어DB 최적화 및 분산투명 프론트엔드 기반 컨텐츠 아키텍처
• 69.
  다루지 못한 주제들닷넷언어로서버 만들기섀도우 채널 및 MMO 마을단일 스레드로직아키텍처 및 멀티스레딩P2P 지원 아키텍처 및 미들웨어컨텐츠로직 프레임워크닷넷 메시지 시리얼라이즈 최적화
• 70.
  Q&A게임 서비스 운영관련 질문, 게임 디자인 관련 질문이나 세션 내용과 관계없는 질문은 삼가 주시기 바랍니다.
• 71.
  영웅전 관련 세션5월30일 월요일5월 31일 화요일6월 1일 수요일6월 3일 금요일