[NDC 2017] 4. 1일차 4섹션 마비노기 영웅전, 무탈한 라이브 서비스를 위한 여정 Conference..♪

서버 개발자가 말하는 인프라 개선 팁

발표자: 이영득 From 넥슨코리아
큰 주제: 장애 및 트러블 대응 / 개발 프로세스
16
9월까지의 경험을 강연에 담았다.
라이브 서비스를 한 방에 안정화시킬 획기적인 기능은 찾지 못했다.
서버 / 개발 환경 / 유저


다양한 분야의 전문가들과 함께 개발
안정적인 서비스 / 불안정한 서비스
>>
사람, , 시간 투자..
개선방법에 대해 고민 시작
라이브 서버+라이브 클라이언트에대해 다시 고민.

전반전: 대응
1) 문제 파악하기, 이미 벌어진 문제 수습하기
장애 발생>>각 국가의담당자들이 원인 추론, 수정
점검 보고서 작성: 긴급, 연장, 임시 점검 시 사후에 작성(예정되지않은 점검 이후)
심플, 담백하게 사실만 기록.
특정 사람이 잘못했다는 뉘앙스가 되지 않도록 작성, 모르겠으면 모르겠다고 작성한다.
작성한 보고서 링크를 담아 메일로 발송> 국가 담당 개발/PM
추후 예방을 위한 고민을 유도, 장애기록을 보존, 타 국가에 동일한 문제가 발생하지 않도록
이 기록을 토대로 집중해야 할 우선순위를 정하고 지속적인 관심이 중요하다.
cf)
마비노기 듀얼 라이브서비스작년 강연 참고

2)
원인파악

3)
덤프 서비스
크래쉬 / 메모리 릭 -> 덤프 내리기 > 덤프 분석  문제 코드 수정
C#
언어를 사용, 초기 몇년동안엔 크래쉬가 나지 않았다
덤프를 생성해주는툴 ms debugdiag
디버그가 하나씩 생성됨. 런타임프로세스에 디버그를 뗐다 붙였다 할 수 있음
: 덤프를 여러 개 만들어놓고, 시간단위로

분석도구: Visual Studio
익숙하고 편하다, 심볼이나 모듈로딩이 편함
눈이 불편함, 메모리를 타고 들어가다보면 손가락 관절이 아프다

정리
게임 규모가 커질수록 크래쉬나 메모리 릭처럼 명확한 문제들은 허둥지둥 하지말고 덤프를 열어보는 것이 빠르다
예측 수정이 아닌 정확한 원인 파악 후 수정을 추천

4)
응답속도정보 모으기
서버 개발자로서 제일 힘들었던 ''
상세 정보를 획득하기 어려운 리포트.
유저의 입장에서는 정확히 어디서 렉이 발생되는지 알 수 없고, 실제로렉이 아닌 경우도 있다
<>프론트<>
300
개의 프로세스가하나의 머신에서 돌아감
각 프로세스는 싱글 스레드 처리

렉이 있는지 알아낼 수 있는지 확인

인큐 양 > 디큐 양 >>>지연 현상으로 판정
큐에 쌓인 태스크 개수는 결국 처리해야 할 양.
최소 실행 단위는 프로세스!
(
밑에 있는그래프가 렉)

각 태스크는 얼마나 걸리는가?
프로파일링 데이터 < 특정주기마다 write
콜카운트,

QueueLength
를 이용해병목 프로세스 구간 체크
해당 서비스의 오퍼레이션 퍼포먼스 데이터를 쿼리
DIFF:
정상 서비스시점 데이터 vs 현재 문제가 생긴 데이터
but,
이렇게 해도문제점이 있었다
사진
국가별 개별 작업 > 비용문제 > 한 번 작업해서 모든 국가에 배포
하나의 IDC안에 단일머신을 넣음

정리
데이터를 어떤 형태로라도 묶어서 편하게 볼 수 있게 한다.
지연 현상을 파악할 데이터가 필요
렉의 징후 시 개발팀에 얼럿!
렉의 이슈는 정상/비정상 데이터를비교하면 추적이 쉽다. //로그인이 10초가 걸렸다: 이것만으로는 정상인지 비정상인지 알 수가 없다
성능 데이터 없이 서버 최적화를 진행할 수 없다!

5)
실시간으로수정하게 해주세요
기존에 마영전 팀에 있던 기능.
장점: 실시간으로 문제를 제어
단점: 태스크를 무조건 두 번이상 해줘야 함, 기능과 기능 사이에 의존성이 생기면 예측하지 못한 결과가 발생할 수 있다, 가독성이 떨어지기 쉬움(중복코드가 쉽게 발생 >> 최대한 다형성으로 해결을...)


후반전: 개발프로세스
코드 리뷰: 원래 없다가 도입한 시스템
세 단계로 구분
1) Performance Shelve,
오프라인으로 하니까 공유가 안됨 혼자선 시간이 모자람
2)
전체 작업 대상으로변경, 리뷰어 지정을 팀장이, 지정된 사람이 리뷰를
3)
리뷰보드 투입, 코멘트를 한 눈에 체크 가능, 라인 단위 코멘트 가능
=>
완벽은 아니지만완성도가 증가했다
팀원들이 서로 배울 점을 가진다.
단점: 시간, 추가 업무

대규모 컨텐츠 작업시, 한번에 많은 양을 리뷰어에게 전달 >> 못함

6)
버그의 인지시점을 당기자
배포용 클라이언트를 생성할 떄 사용하는 데이터 >> 문제 감지가 배포용을 만들고 나서 된다

콘솔커맨드에 에러를 그냥 출력하는 것만이 아니라 메시지박스를띄웠다 >> 귀찮긴하지만 이렇게 해야 고치는게 확실해진다.

정리
버그가 있다는 것을 인지하는 시점을 파악

7)
대화하기
개발 환경의 사용자는 개발팀(+협업부서)

빨리 가려면 혼자 가고,멀리 가려면 함께 가라. (의견 수렴)

총정리
문제가 발생했을 때, 쉽고빠르게 원인을 파악하는 주변 도구가 필요하다

아인슈타인


덧글

댓글 입력 영역


D-DAY