NDC 참관기: 메이플스토리 개발스토리 – 더 잘되는 게임을 위한 라이브 코어 개발

훌륭한 엔지니어인 황의권 군의 발표. 오늘 들은 세 개 세션 중 가장 재밌게 들었다.

 

내용 요약:

라이브 서비스이기 때문에, 제일 중요한 것은 `방어’. 그렇지만 `공격적인 업데이트’를 통해서(빅뱅 업데이트) 재탄성 했다. 이를 위해 지속적인 개선과정과 그에 따른 이슈 처리가 필요했다.

1. 창모드와 해상도 확장

DX8이 화면 주파수 동기화가 안되는 문제. 그리고 일부 고성능 머신의 GPU의 경우, 과부하가 걸리는 문제가 생겼음. 그래서 DX 9으로 이전하고, 잘 점검하고 실험하는걸로 해결.

해상도 확장의 경우 게임 화면, View-port, 툴, 데이터를 변경하는 문제가 있어서 생각보다 일이 컸다고 한다. 의외로 뷰포트를 `유저에게 친화적인’ 화면 아래쪽, 상태 표시 줄 쪽에 중심을 두는 방식으로해서 작업량을 적당히 유지할 수 있어다 한다.

2. 동접 갱신과 이에 따른 서버 부하 관리

우선 장비를 업그레이드. 하지만 32bits OS의 한계로 메모리 제한(2GiB)에 부딪힘.
/3GB 플래그로 유저 스페이스를 늘렸더니 kernel I/O 퍼포먼스가 떨어지고, 이로 인해 MS SqlServer 성능문제가 심해서 이 방법은 포기 했다. 그리고 WoWx64의 경우 테스트에 필요한 시간이 모자라서 채택하지 않음(제일 중요한건 `방어’). 어떤 의미론 정석대로 코드를 분석해서 메모리 사용량을 줄이는 걸로 대응하고, 메모리 사용량에 따라 `동시 접속자 수 제한(대기)’을 구현해서 해결했다.

3. 개발 환경 개선과 신규 시스템 추가

다음과 같은 변화를 줌.

  • VC6에서 VS 2008로 이전
  • 락 순서에 대한 Assertion추가[1]
  • CC.net 을 사용해서 지속적인 빌드를 만듬
  • TBB의 concurrent_hash_map 도입
  • lua 스크립트를 도입

레거시 코드 문제 때문에,

  • VS 6 호환성 옵션 활용
  • (일부 상황에 대해) lock-order assertion을 끄고, 예외를 인정하기로
  • 라이브러리 리뷰/수정 및 일부 사항에 대해선 예외를 인정하고 타협

4. 의의 및 정리

* 검증이 중요 (라이브 서비스!)
* (비슷하게) 실수가 용납되지 않는다

검토가 중요하고, 현재까지 수정한 매몰 비용을 생각할게 아니라, 수정에 따른 총 비용을 생각해야 한다. 특히 남들이 말리는 리팩터링이나 패치 전 자잘한 수정은 금기사항.

정리: 개인의 만족과 조직의 발전 사이의 어떤 지점. 라이브 서비스를 만드는 구성원들에게 `더 나아지고 있다’는 느낌을 준다는게 중요하다.

 

촌평

라이브 서비스의 절대 목표 `서비스를 유지’하는 것을 전제로, 어떤 문제를 겪고, 이걸 해결하는 방법에 대한 이유를 잘 설명해 준 것 같다.

내용 요약에 추가할 점, 잘못된 점 등을 지적해주면 매우매우 감사하겠다.

  1. 이건 데드락을 피하기 위한 매우 표준적인 방법이다 []

Published by

rein

나는 ...

4 thoughts on “NDC 참관기: 메이플스토리 개발스토리 – 더 잘되는 게임을 위한 라이브 코어 개발”

  1. 안녕하세요.
    내용중에
    VC6에서 VS 2008로 이전
    VS 6 호환성 옵션 활용
    에 대해 궁금하고 더 자세히 알고 싶습니다.
    저희도 VC6 사용중인데 VS2008로 이전하고자 합니다만, 호환성 문제로 어려움을 겪고 있습니다.
    ‘VS 6 호환성 옵션’은 어디서 어떻게 설정하는 건지 알려주시면 큰 도움이 될 듯 합니다.^^

    1. 이건 제가 직접한게 아니라, 해당 발표자 분이 한 일에 대한 포스트모템입니다.

      제가 아는 범위 내에서 설명하자면, VS 프로젝트 옵션 어딘가에, VC 6.0에서 표준을 벗어난채로 쓰던 일부 문법 (for 문 안의 변수 선언 등)에 대해 VS 2008 등에서 오류가 나던걸 막아주는 기능이 있습니다.
      자세한 부분은 구글 등을 통해 검색하시면 될 듯 합니다.

      다만, VC 6.0에 대한 완벽한 호환성 옵션은 제가 아는 범위 내에선 없습니다.

  2. 이 세션에서는 은근히 찔리는게 많았네요. 특히나 남들이 반대하는 리팩터링은 하지 말라는 부분 (…) 사고 한번 치고 나서 그런지 설득력이 두 배였습니다. orz

    lock order assertion 같은 경우는 제가 오해했을지도 모르는 부분이 있어서 – 컴파일 시점에 체크한다는 이야기로 이해했었습니다 – 확인 차 질문을 했었는데, 고전적인 방법이었더군요. 예전에 특정 모듈/클래스에서 잡을 수 있는 락의 종류를 컴파일 시점에 제약하려는 삽질을 한창 했었는데 답을 못 냈었거든요.

    1. 저도 `패치 전 마이너 수정’에서 찔리는게 좀 많아서(……..후략)

      lock-order assertion같은 경우 컴파일 시점에서 알 수 없는 경우 (동적으로 생성되고 동적으로 순서가 결정되는) 락이 있으면 안되지 않을까요? (이건 깊게 생각해본건 아니라 안 나올지도 모르지만).
      저 세션에서 나온 방법을 실제로 구현만 해도 (linux kernel?) 몇 가지 버그는 쉽게 알 수 있게 되서 도움이 되는 거 같습니다.

Leave a Reply