Weitere ähnliche Inhalte Ähnlich wie 임태현, 서버점검 제로에의 도전, NDC2011 (20) Mehr von 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. 신뢰핛 수 있는 코드를 작성하여
작업의 효율을 높이고 결과적으로
높은 수죾의 서비스를 제공핛 수
있게 된다