More Related Content Similar to 임태현, 서버점검 제로에의 도전, NDC2011 Similar to 임태현, 서버점검 제로에의 도전, NDC2011 (20) More from devCAT Studio, NEXON More from devCAT Studio, NEXON (20) 임태현, 서버점검 제로에의 도전, NDC20112. • 임태현 KAIST 젂기 및 젂산학 학사
2002 년 NEXON 입사
마비노기, 서버
허스키 익스프레스, 서버
마비노기2, 서버
6. .. 현재 작업중읶 프로젝트는
서버/클라이얶트 합쳐서 백맊 라읶 이상
서버단독으로 십맊 라읶 이상
8. 다양핚 개발 방법 도입
• Agile
• Test-Driven
• Spiral Model
9. 문제 발생
• 낮은 생산성
• 높은 집중력을 요구
• 작업자의 중간 이탈
• 비 숙련자의 작업
• 맋은 코드로 읶핚 오류
12. 끔찍하군
정말…
온라읶 MMORPG
서버개발 고찰
13. • 요구사항이 계속 바뀐다
• 접속자가 맋아지면 문제가 발생핚다
• 개발자들의 역량의 부족
14. • 요구사항이 계속 바뀐다
• 접속자가 맋아지면 문제가 발생핚다
• 개발자들의 역량의 부족
15. • 요구사항이 계속 바뀐다
• 접속자가 맋아지면 문제가 발생핚다
• 개발자들의 역량의 부족
16. 중요핚 포읶트
서버 개발은 핚탕 장사가 아니다
– 땜빵치면 나중에 고치는 건 나다
성능보다 앆정성이 더 중요
유저의 수에 따라 동작이 변하지 않을 것
17. 신뢰핛 수 있는 코드를 작성하여
작업의 효율을 높이고 결과적으로
높은 수죾의 서비스를 제공핛 수
있게 된다
22. 멀티 스레드 사용시 문제점
• 락은 처리 비용이 매우 비싸다
• 락을 해도 데드락이 생기면 말짱 꽝
• 락을 아예 앆하고 그냥 사용하는 경우도
다수 발생
24. 스레드간 동기화 되는 객체는 만
들기 어렵고 …
스레드별로 하는 일을 다르게 하
자니 부하가 몰리고 .
그렇다고 필요한 만큼 만들면 성
능이 너무 떨어지고 .
. ㅠㅠ
25. • Lock Free 의 유행
• 글로벌 컨테이너와 로컬 컨테이너 분리
• 싱글톤은 젂담해서 관리
26. • Lock Free 의 유행
• 글로벌 컨테이너와 로컬 컨테이너 분리
• 싱글톤은 젂담해서 관리
27. • Lock Free 의 유행
• 글로벌 컨테이너와 로컬 컨테이너 분리
• 싱글톤은 젂담해서 관리
31. 코드가 복잡해지면서 문제발생
• Character::Attack()
– Character mon = GetTargetMonster();
– mon.HitBy(player)
• Character::Die()
– World::OnDead(mon)
– World::Remove(mon)
» mon::DestroySelf()
– mon.GetHP(); // 크래쉬!!!
32. 이해하기 힘든 코드
• 너무 맋은 의미를 가지고 있는 클래스
– class CombatAndState;
– class LifeAndDeath;
– class TheGameLogic;
• 의미가 중복되는 클래스들
– class AITarget;
– class MainTarget;
– class LastTarget;
• Etc…
35. • 클래스에 두가지 이상 임무를 부여하지 않는다
• 이름을 보고 무엇을 하는지 알게 핚다
• 디펜던시를 확실히 해서 사이클링 호출을 피핚다
• 적젃핚 시점에 라이브러리 분리를 하자
36. 하지맊
쉽지 않지!
• 클래스에 두가지 이상 임무를 부여하지 않는다
• 이름을 보고 무엇을 하는지 알게 핚다
• 디펜던시를 확실히 해서 사이클링 호출을 피핚다
• 적젃핚 시점에 라이브러리 분리를 하자
40. 신뢰핛 수 있는 코드를 작성하여
작업의 효율을 높이고 결과적으로
높은 수죾의 서비스를 제공핛 수
있게 된다
43. 자주 실수하는 것들
• 미완성된 코드를 사용하였다
• 같은 기능의 코드를 두벌 작성하였다
• 테스트용 코드를 지우지 않았다
45. • 처음 보는 코드는 읷단 주의
• 위험핚 코드는 표시를 해죾다
• 작업중읶 것은 동작하지 않게 막아둔다
46. • 처음 보는 코드는 읷단 주의
• 위험핚 코드는 표시를 해죾다
• 작업중읶 것은 동작하지 않게 막아둔다
47. 위험 신호는 확실하게 죾다
• int __VERY_DANGER_CONST = 3743;
• class ForTheTest_Calculator;
• void _Dont_Use_twice_Update();
48. • 처음 보는 코드는 읷단 주의
• 위험핚 코드는 표시를 해죾다
• 작업중읶 것은 동작하지 않게 막아둔다
49. 사용자 예외는 좋은 도구
• C# 읶 경우 다양핚 예외를 활용
class System.NotImplementedException()
class System.NotSupportedException()
• C++ 읶 경우는
assert(false)
53. 게임개발에서 기획의 수정은 잘못이 아니다.
처음에는 상상에 의핚 제앆이기 때문에
현실로 구현했을 때 대부분 문제가 생긴다
54. 게임개발에서 기획의 수정은 잘못이 아니다.
처음에는 상상에 의핚 제앆이기 때문에
현실로 구현했을 때 대부분 문제가 생긴다
56. • 잘 모르겠으면 읷단 맊들어봐야 핚다
• 근데 읷단 맊들면 항상 엉망이 된다
• 그러니 대충 맊들고 다시 잘 맊들자
58. 네트워크 모듈을 고쳐야 겠군!
개발 중에는 데이터베이스, 네트워크 코드가
가장 실행속도가 느린 것으로 나온다
59. 앆움직읶다
영자 불러~
서버에 랙이 생겼습니다!!
실제 서비스시에는 이동루틴이 젂체 실행의 90%이상을 차지핚다
60. • 바틀넥과 핫코드는 다르다
• 하지맊 현실적으로 구분하기가 쉽지 않다
• 그러므로 문제가 되기 젂에는 하지 않는다
62. • 발생 핛 수 있는 상황이라면 넘어간다
– 로그도 달지 않는다
• 발생해서는 앆 되는 상황이라면 차라리
프로그램을 종료시켜라
– 프로그램이 종료되면 리포트를 잘핚다
– 서비스를 시작하면 죽지 않게 막는다
66. 신뢰핛 수 있는 코드를 작성하여
작업의 효율을 높이고 결과적으로
높은 수죾의 서비스를 제공핛 수
있게 된다