NDC Replay

테라 서버의 Modern C++ 활용기
이상헌
블루홀
2014 - 현재: 블루홀 테라 서버팀에서 성실히 국방의 의무를 수행하는 중 2012 - 2014: M.S. Programming Languages Lab, KAIST
C++03 기반으로 개발 되었던 테라 서버에서 현재 Modern C++(11/14)를 어떠한 필요에 의해, 어떻게 활용하고 있는지 소개합니다. 언어의 새 기능에 대한 자세한 설명보다는 적용 과정에서 겪었던 일들을 중심으로 흥미롭게 발표를 풀어나갈 예정입니다. 1. 스마트 포인터의 오남용과 Move Semantics 적용기 2. Variadic Template를 활용한 오래된 매크로 제거: 인자 추론과 튜플 활용을 중심으로 3. Future-Promise 패턴을 활용한 서버로딩 시간 개선
[새 창에서 슬라이드 보기]
안녕하세요 저는 Bluehole에서 TERA 서버 개발을 맡고 있는 이상헌이라고 합니다. 반갑습니다. 오늘 발표할 주제는 TERA 서버의 Modern C++ 활용기고요.

목차는 다음과 같습니다. Introduction이 있고요. 크게 세 가지 컨셉에 대해서 이야기할 건데요. Move Semantics 그리고 Variadic Template 그리고 Future-Promise 패턴이 있고 끝엔 Q&A가 있습니다.

발표자 소개고요. 당연히 개발자고요. C++와 Concurrency 그리고 Server-Side 기술들에 관심이 있습니다. 프로그래밍 언어 연구실에서 석사 과정을 했고요. 현재 Bluehole에서 테라 본부에서 서버 개발하고 있고 제가 경력이 짧다 보니깐 “뭐 넣을 거 없나?”하고 봤는데 여기 안 보이네요? 전국 이야기 말하기 대회 대구 지역에서 2등 했습니다. 2004년에 지역대표였어요. Contact고요. 혹시나 뭐 발표 관련이나 물으실 게 있으면 일로 연락 주시면 되겠습니다.

테라고요. Nontargeting Action MMORPG, Free Targeting Action MMORPG고요. 2007년에서 2011년까지 개발을 했고 11년 1월부터 한게임에서 서비스했고 이제 16년부터는 현재 넥슨에서 서비스하고 있습니다. 현재 북미와 유럽 지역을 포함해서 7개 지역에서 서비스를 하고 있습니다.

발표하기에 앞서서요. 이 발표는 C++ 03 기준으로 작성된 기존 코드에서 Modern C++를 활용한 사례를 소개하는 세션이고요. 더 많은 활용 예가 조금 소개되었으면 하는 바람에 발표하게 되었습니다. 과거의 코드가 잘못되었다. 흔히들 앞사람들의 깐다고 그러죠? 그게 아니라 이제 더 나은 길이 열렸다는 걸 소개하는 게 목적이고요. 보안 문제로 테라 서버 코드는 이 안에 정확히는 없습니다. 그리고 별표가 표시된 슬라이드는 부연 설명을 위한 슬라이드고요. 발표 땐 시간 관계상 다루지 않을 수도 있으니깐 집에 가서 한 번 보시면 될 것 같고요. 아래는 저작권법 관련 이야기입니다.

네 리빙 포인트, 발표 중간중간에 있는 이런 슬라이드는 진행 상황을 알려주고요. 앞으로 이렇게 하게 될 겁니다. 미리 스포를 좀 드리고 시작할게요. 파트가 세 개다 보니깐 이게 언제 끝나고 언제 시작했는지 헷갈리시는 분들이 있을 것 같아서 이번에는 Smart Pointer에 Move Semantics를 적용해서 불필요한 복사를 막고 Reference Count의 증감을 감소시켜서 성능 향상을 이룬 이야기를 할 겁니다.

필요한 사전 지식, 혹시 학생분들 얼마나 계신가요? 손 한 번 들어주시겠어요? 많네요. C++의 Smart Pointer 아시는지 모르겠는데 객체의 생성과 소멸 관리를 위해서 사용하는 객체고요. 표준에는 shared_ptr과 unique_ptr이 있습니다. t_ptr이라는 녀석이 나올 건데 이거는 shared_ptr과 같은 것이고요. 테라 서버 안에서 자체적으로 사용하고 있는 Smart Pointer고 침습형 카운터를 사용하고 있어요. shared_ptr 같은 경우에는 Pointer 외부에 Reference Count를 관리하는 공간이 있는데 저희 같은 경우에는 어떤 Reference Count를 가지고 있는 개체를 상속받아서 t_ptr에 담아서 사용합니다. 이 외에도 Move Semantics, Rvalue Reference, Perfect Forwarding 이런 거 알면 이해가 더 잘 될 텐데 몰라도 크게 문제는 없다고 생각합니다. 혹시 모르겠으면 가서 공부하시면 될 것 같습니다.

시작은 이걸로 할게요. C++ Conference 2015에서 Stroustrup 할아버지께서 이런 발표를 하셨어요. “좋은 C++ 14 코드 쓰기.” 그런데 그중에 이런 말이 있었어요. “Smart Pointer가 유용한데 굉장히 Overused 되고 있다. 그중에서 shared_ptr은 비쌀 수 있다.” 이런 말을 했어요. 이 말은 shared_ptr이 Reference Count를 가지고 있는데 이 증감 연산이 쓸데없이 많이 일어날 수가 있다. Overused 했을 때. 이런 얘기고요.

shared_ptr의 문제는 곧 t_ptr의 t Pointer의 문제와 같습니다. 이런 코드가 있는데요. GUserManager에서 GetUser를 했는데 이것은 t_ptr로 받는 게 올바른 코드입니다. 왜냐하면 언제 이 게임 객체가 소멸될지 모르기 때문에 반드시 이런 식으로 Reference와 생명주기를 보장해 줘야 되죠. 그런데 이런 코드 같은 경우에는 좋지 않은 코드에요. 왜 좋지 않으냐?

type_cast라는 걸 저희가 만들었었는데요. 이게 미리 타입의 상속 관계를 다 array에 저장해뒀다가 정적으로 static cast, dynamic cast 대신에 이런 식으로 빠르게 타입 변환을 하려고 테이블 먼저 사용을 하고 있었는데 요거는 생Pointer라고 하는 Raw Pointer죠? 그런데 이거를 t_ptr 버전으로 고치면 요렇게 됩니다. 그런데 이걸 성능 측정을 해보면 이런 식으로 나와요. 여기서 29.9%가 걸렸고 여기서 70%가 걸렸다. 왜냐하면 여기서 복사 연산이 일어나기 때문에 Reference Count가 하나 늘어나고요. 여기서는 여기서 만든 S라는 객체가 사라질 거기 때문에 Reference Count가 줄어드는 연산이 일어날 거고. 여기서는 새 Pointer를 만들었기 때문에 또 Reference Count가 하나 늘어날 겁니다. 뜻밖의 복사 생성자와 소멸자가 호출됩니다. 

그래서 제가 고쳤어요. 그냥 간단하게 원래 여기 const가 있어야 되는데 이거 하면 여기 넘어가기 때문에 이렇게만 했고요. 그래서 이쪽은 Lvalue Reference를 받고 이쪽은 Rvalue Reference를 받아서 호출 줄을 없앴어요. 그런데 이런 게 좋지 않았던 예, 쓸데 없이 복사 연산을 호출하는 그런 예 중에 하나고요.

제가 이걸 고치고 나서 이런 생각을 했어요. 아 이게 Atomic한 Increment/Decrement 연산이 생각보다 비싼 거구나. 그래서 그냥 int i++처럼 가볍게 쓰지 말아야겠구나. 그래서 뭔가 본의 아니게 거의 dynamic_cast만큼 느린 type_cast를 저희가 쓰고 있었고요. t_ptr에 한해서. 물론 서비스에 문제가 없었고 이거는 거의 0.1ms이냐? 0.09ms이냐? 이런 문제고 호출양도 적었고 괜찮았어요. 하지만 이런 식으로 Smart Pointer의 복사 생성이 의미 없이 발생할 때가 많다. type_cast도 그 하나의 예제였을 뿐이고요.

두 번째 예제에요. Vector. 저는 Vector를 굉장히 좋아하는 사람입니다. GatherGameObjectList라는 함수가 굉장히 오래 걸리는 걸 제가 프로파일링 했어요. 근데 이건 뭐 하냐 하면 게임 Object의 Pointer들을 Vector에 저장하는데 “아니 뭐 Vector에 저장하는데 왜 느려?”하고 봤더니 보이시나요? 여기가 Reallocate에요. Reallocate. 어? 왜 Vector에 Reallocate가? 왜 오래 걸리지? 이거 인정할 수가 없어요. Vector는 빨라야 돼요. 아 이게 Reallocate 안으로 들어가 보니까 Reference Count가 늘어나고 줄어드는 걸 확인할 수 있었습니다. 그러면 이제 학부 시절로 돌아가서 Vector의 Reallocation을 봅시다.

객체에 E를 추가하려 할 때 메모리 영역 R1이고요. 그러면 R2를 새로 생성하겠죠? 2배 크기의. 그리고 여기다 복사합니다. 그럼 Reference Count가 4번 늘어나죠. 그리고 기존 건 없앱니다. 4개 줄어들죠. 그리고 E를 추가합니다. 하나 늘어나죠. 그런데 따지고 보면 이건 필요가 없어요. 이걸 왜 합니까? 어차피 4개 늘고 4개 줄어들 건데.

그래서 이걸 해결하기 위해서 나타난 게 Move Semantics죠. Move Semantics. Rvalue Reference란 개념이 나오는데요. 임시 객체의 Reference를 받는 겁니다. GetObject라면 GetObject는 이름이 없죠? 변수에. 근데 이거의 Reference는 Object, Rvalue Reference 연산자를 쓰고 Object라고 써주면 되고요. 비교하기를 이거는 Lvalue이기 때문에 이거는 Lvalue Reference입니다. 기존에 보던 Obhect는. 그래서 Move Semantics가 뭐냐? 아 생성자와 대입 연산자가 Rvalue를 사용할 땐 소유권을 넘겨주는 것만으로 충분하다. 여기 예제를 보면 other, Rvalue Reference를 받을 때는 이걸 받아서 그냥 nullptr로 바꾸고 소유권만 넘겨받는 거고요. 만약에 Lvalue Reference였을 때는 예전처럼 DeepCopy를 해야겠죠?

소유권 계승하는 중입니다. 그래서 사라진 객체는 소유권을 위임하는 것만으로 충분합니다. 그러니깐 어차피 사라질 객체에 대해서는 Reference를 늘리고 줄이는 일을 하지 않아도 돼요. 그런 일을 하지 않게끔 이런 식으로 Move Constructor와 Move Assignment Operator를 구현해 줬습니다. 캬 멋있죠? 이제 Rvalue를 계승하는 거고요. 그래서 이제 Vector reallocation 때 Move Constructor가 호출될 거라고 믿었어요. 오잉? 네 아니었어요.

보니깐 저희가 Custom Memory Allocator를 만들어 쓰고 있었는데 여기 있는 Construct 함수가 과거 03 버전의 Memory Construct에요. 이렇게 되면 Lvalue Reference가 호출되기 때문에 앞에서 뭘 만들었든 이 new 안에 Lvalue가 들어갈 거기 때문에 소용이 없어지죠. 아, Lvalue Reference가 들어가기 때문에. 그래서 Perfect Forwarding이라고 해서 Lvalue Reference였던 거는 Lvalue Reference로 Rvalue였던 거는 Rvalue Reference로 이렇게 바꿔주는 개념을 사용해서 이런 식으로  Universal Reference를 사용해서 Forwarding 해줬고요. 그래서 R은 R, L은 L로 처리 이렇게 적혀 있죠.

그렇게 해서 Happy하게 됐습니다. 그래서 CPU 점유율 변화를 볼 건데요. 저희가 내부적으로 사용하고 있는 과부하 테스트가 있고 정확한 유저 수나 채널 수나 NPC 수는 대외비이기 때문에 말씀드릴 수가 있고 제 머신에서 테스트했고 어차피 대충 보면 뭐 몬스터 수가 N일 때는 주위의 몬스터 수, PC가 이렇게 많은 NPC들과 뭉쳐서 스킬을 쓸 거예요. 그때 원래는 12.5%였는데 7.8%로 줄었죠? 이게 몬스터 수를 점점 늘릴수록 CPU 사용률 늘어나고요. 이것도 똑같이 많이 감소하는 걸 볼 수 있죠. 꽤나 150% 성능의 향상이 있는 것 같습니다. 특수한 케이스긴 해요. 이렇게 몬스터와 뭉쳐서 싸울 일이 실제로 없거든요. 별로. 라이브 서버에선 대충 1번? 요 정도 케이스의 CPU 사용률을 사용한다고 보시면 될 것 같습니다.

Sample Rate를 볼게요. 이제 어떤 함수가 오래 걸렸는가 Rate를 측정해보면 Reference Count의 Sample Rate 같은 경우가 원래 47.5%였는데 3번 캐릭터 수에서 26.5%로 줄었고요. 이제 reallocation이 없어진 걸 확인할 수 있습니다. Happy해졌습니다.

그래서 이것과 관련해서 2015년에 아까 말했던 Conference에서 Stroustrup 할아버지께서 이런 얘기를 하셨어요, “지나치게 남용되고 있다. shared_ptr을 Parameter로 쓰고 Return하고 Reference Count가 쓸데없이 올라갔다 내려갔다 하고 그런다. 그런데 어떤 룰을 따르면 Dangling Pointer를 잡을 수 있으니깐 굳이 shared_ptr을 경우에 따라서 사용하지 않아도 된다.” 이런 얘기를 하시고요.

이건 그 예제고요. 넘어갈게요. 그래서 GSL이라고 Guideline Support Library라는 걸 보여주셨습니다. 저는 예전에 GSL이 곰TV 스타 리그인 줄 알았어요. 그런데 Global Star2 League더라고요. 처음 알았어요. 그래서 이것들을 여기 보시면 확인할 수 있고. Owner라는 컨셉으로 정적 분석을 하고 문서화를 해서 Dangling Pointer를 잡을 수 있다. 뭐 이런 얘기를 하셨습니다. 보너스였어요.

네 리빙 포인트입니다. 과거에 작성된 Smart Pointer엔 Move Semantics를 구현해주자. 물 한 잔만 마실게요. 다음은 Variadic Template과 Variadic Template을 활용할 수 있는 기술들을 소개할까 합니다.

사전 지식이에요. 아주 간단하죠 이번엔? C++에서 Template은 이렇게 씁니다. 이거는 아셔야지만 할 수 있어요. 자세한 설명은 생략하고요.

제가 처음에 회사 입사했을 때 테라 서버 코드에 대해서 리뷰를 하게 됐는데 그러면서 제일 처음 보라 그러면서 이 tenw라는 함수를 보여주셨어요. 사수 님께서 그런데 보니깐 이게 뭐 하는 거냐 하면 Custom Memory Allocator에서 new 대신에 쓰는 tnew라는 녀석인데요. 메모리를 할당받고 여기다가 place new를 동해서 뭔가를 대입하는 그런 건데 이렇게 봐서 뭐 하는 건지 잘 모르겠죠?

그래서 좀 더 먼 과거 사수 님께서 와 계시는데 헷갈리다면 이 리비전의 코드를 보고 공부하거라. 이런 말씀을 하셨어요. 그래서 딱 보여주신 게 이거예요. 오, 깔끔하죠? 그래서 인자 세 개짜리에 대해서 이런 식으로 Template을 선언해서 사용하고 있었습니다. 보기 좋죠? 오 이게 더 깔끔한 것 같은데요? 왜 굳이 앞에 걸로 했어요?

이게 인자 수가 많아지면 이만큼 다 구현해줘야 합니다. 그래서 과거에 계셨던 어떤 선구자님께서 앞의 코드로 고쳐주셨습니다.

그런데 저는 싫었어요. 매크로가. 디버깅이 잘 안 됐거든요. 그래서 이런 녀석을 공부하게 됐습니다. Varidadic Template이라고 11부터 지원하고요. Visual Studio에서는 2013부터 지원하는데요. 임의의 인자 개수를 지원하는 Template 형식이고요. Ellipsis operator라는 걸 사용하는데 말 줄임표, 생략자 이런 뜻이고요. 이런 곳에서 사용하실 수 있어요. 그래서 보시면 두 Function에서 args... args하면 이렇게 사용할 수 있고요. 예제 보면 Do Func(1, "hi")라고 쓴 거는 이런 식으로 표현할 수 있고요. 여기 아무것도 없어도 되는 인자 개수가 0인 것도 지원이 됩니다. 이런 식으로.

당연히 되는 것들 방금 말했던 요런 거 되고요. 이제 여기서 Reference도 다 붙일 수 있고요. 중요한 건데 sizeof라고 이 args에 들어가는 이 Variadic Template의 인자가 몇 갠가를 sizeof...으로 정적으로 알 수 있어요. 이런 식으로 사용하시면 되고 이걸 사용할 일이 있는지 모르겠는데 다중 상속을 이런 식으로 할 수도 있습니다.

그래서 이렇게 고쳤어요. 비교해볼까요? 뭔가 좀 코드 같아졌죠? 그런데 이렇게 간단한 거를 제가 소개하려고 여기 나오면 안 되겠죠? 

그래서 이걸 가지고 여기저기 고쳤습니다. TypeList라고 Modern C++ 디자인 빨간 책이라 불리는 그 책 지금 절판됐는데 그 책에 있는 TypeList고요. 원래 TypeList를 선언하려면 뭔가 재귀적으로 T1 안에 T2, T2 안에 T3, T3 안에 T4 이런 식으로 생겼고 이렇게 정규 모양은 이런 식인데요. 이거를 Variadic Template으로 잘 잘 고치면 이런 식으로 깔끔하게 처리할 수 있습니다. 이제 힘을 얻어서 좀 더 어려운 걸 해보겠다 생각을 했어요.

이런 녀석이 있어요. 이제 이 녀석을 고쳐야 되는데 딱 봐도 뭔지 모르겠죠? 이거는 저희 코드 내에서 비동기 함수를 처리하는, 비동기 함수 관련 코드인데요.

보이나요? 이건데 이게 뭘 한 것, 궁극적으로는 Function Pointer랑 인자들을 받아서 미래에 실행하겠다는 그런 의미입니다. 그래서 이 노란색으로 칠한 게 진짜 이 긴 코드가 하고 싶은 일이고요. 이걸 비동기적으로 하기 위해서 그래서 그 실행한 함수의 인자들이 미리 이 클래스 안에 저장해 주고요. Member Function과 함께. 그래서 나중에 실행하고 그런 방식입니다. 그래서 job이라는 객체를 만들어서 넣어뒀다가 나중에 Thread가 돌면서 실행하겠죠. 좋아 이거를 한 번 고쳐보자 했습니다. 그런데 문제가 생기죠. 이 arg1, 2, 3, 4, 5, 6 이런 식으로 있을 텐데 얘를 어떻게 처리하지? 

그래서 살펴보니 또 tuple이라는 게 또 생겼어요. tuple은 이런 거예요. 학교에서 배웠던 여러 가지 레코드라고 그러나요? 그런 여러 가지 타입을 가진 녀석들의 묶음이죠. 그래서 이런 식으로 정의가 되고 이런 식으로 쓰면 됩니다. int, bool, strng 덮투플 하면 3, true, hi 이런 식으로 쓸 수가 있어요. 그래서 두 번째 인자, 컴퓨터에선 0, 1, 2로 시작하죠? 여기를 가져오고 싶으면 정적으로 get Template 2, <2> 이렇게 해주면 파일을 가져올 수 있어요. 왜 이렇게 돼야 되냐 하면 C++는 정적 타입을 지향하는 언어기 때문에 이렇게 할 수밖에 없습니다. 구현은 대충 이런 식으로 돼 있고요. 재귀적으로 head 안에 tail 있고 tail 안엔 다시 head가 있고 이런 방식이고요. 이거를 뭐라 해야 되죠? Sequence하게 표현하는 구현도 있다고 합니다. 

그래서 이거를 tuple로 고쳤어요. 오 그럼 이걸 tuple로 한 걸 성공했는데 그럼 이 tuple을 가지고 이 녀석들을 어떻게 할 거냐? 함수를 실행하고 또 인자로 써야 되는데 만약에 정대만 선수가 있었다면 이런 말을 했을 거예요. 아 감독님 tuple의 각 원소들에 대해서 함수를 수행하고 싶고 함수의 인자로도 사용하고 싶어요. 네, 저는 하고 싶었습니다.

그래서 또 뭔가를 알아야 되는데요. 여기서부턴 두 눈을 크게 뜨고 보셔야지 놓치지 않을 수 있습니다. 갑자기 얘를 왜 하느냐? 일단 볼게요. Sequence라는 애가 있고요. int... Remains입니다. struct고요. gen_seq라는 녀석은 int N, int... Remains입니다. 얘는 다시 N-1, N-1, Reamins... 이런 식으로 상속받아서 쓰고요. 이게 계속 내려가면 N-1이 언젠간 0이 되겠죠? 그럼 이 특수화가 존재하게 됩니다. 0, Reamins...은 다시 seq<Reamins...>이 됩니다. 뽑고 싶은 건 결국 이거예요. 그래서 gen_seq<3>을 하게 되면 여기 대입해보면 2, 2가 되고요. 다시 걔를 한 번 더 대입하면 1, 1, 2가 되고요. 그러면 여기서 0, 0, 1, 2가 됩니다. 그래서 마지막으로 이건 seq<0, 1, 2>를 상속받게 되니까 gen_seq<3>은 다시 말해 seq<0, 1, 2>를 베이스 클래스로 가지게 됩니다. 이 복잡한 과정을 14부터는 make_index_sequence라고 하면 그냥 됩니다. 여긴 11버전의 기준입니다.

어 갑자기 이걸 왜 하냐? 이걸 가지고 뭘 하면 되냐 하면 tuple에 각 원소들에 대해서 함수를 한 번씩 수행할 건데 여기 tuple이 있고요. 수행한 함수의 Member Function Pointer가 있고요. 그래서 gen_seq에다가 sizeof...(Args)를 넘겨주면 tuple의 사이즈만큼 seq를 생성할 거고요. 그럼 여기에 Is는 예를 들어 tuple 사이즈가 3이었다면 0, 1, 2가 들어가는 요런 게 나타나겠죠? 그럼 여기서 get을 할 때 Is를 여기 써주게 되면 0번 원소에 대해서 Function 한 번 1번 원소에 대해서 Function 한 번 요런 식으로 시행하게 됩니다. 쉽죠?

그래서 이제 Sequence 이용해서 tuple을 또 순회를 할 거예요. 이거는 뭐냐 하면 똑같이 for_each에 대해서 gen_sea<sizeof...(Ts)>를 할 건데요. 이거를 하고 나면 다시 요런 게 생길 거고요. 아우 제가 잘못 설명할 것 같네요.

이 녀석은 각각 실행하는 게 아니라 0, 1, 2를 각 Function의 Parameter로 넘기는 과정입니다. Function의 여기에 tuple의 0, tuple의 1, tuple은 2 원소가 들어가겠죠 그냥.

이게 아까 말했던 Function 각에 대해서 0번으로 한 번 1번으로 한 번 2번으로 한 번 실행하는 코드고요. 이쪽에 보시면 이런 괴기한 코드가 있어요. auto l은 Brace가 있고 func(get<Is>(tup))해서 갑자기 0을 써요. 네 이건 뭐냐 하면 이 녀석들을 Function을 Ellipsis Operator를 이용해서 사용하고는 싶은데 이 Operator를 쓸 수 있는 곳이 한정적이다 보니까 이런 야매 꼼수로 하게 되는 겁니다. 이게 어떤 방식인지는 다시 뒷장에 있어요

보시면 이런 일을 할 일은 없지만 int k = (0, 3)이라고 한다면 k는 얼마일까요? 네 3입니다. 이 뒤에 있는 게 오기 때문에. 그래서 마찬가지로 Brace-Init-List에다가 이런 식으로 써주게 되면 결국 이 auto l에는 0000000이 들어갈 거예요. 하지만 그 000을 넣는 과정을 통해서 func(get<Is>(tup)) tuple의 0번 원소에 대해서 한번 1번 원소에 대해서 한 번 이런 실행하는 과정을 모두 거치게 됩니다. 마찬가지로 Function의 Argument로도 똑같이 사용할 수 있어요. 그래서 이제 MagicFunc이라고 이런 걸 하나 만들어두고 같은 방법으로 이렇게 하면 Function의 Parameter로 0000이 들어가겠지만 계산은 한 번씩 다 수행하겠죠. 단 함수의 Parameter에서는 실행 순서가 보장이 안 되기 때문에 실행 순서가 꼭 보장되는 작업을 할 때는 이것을 쓰면 안 됩니다.

그래서 이렇게 뭔가 만들었어요. 아 이제 나는 뭔가 잘하는 것 같아. 이렇게 생각하고 칭찬받아야지 하고 딱 컴파일을 했는데

안 돼요. 이런 메시지가 떠요. 다 같이 읽어 볼까요? 아닙니다. 이게 무슨 뜻이냐 하면 Function이 Argument가 모호하니 니 Template Argument를 추론해 줄 수 없다. 이런 거고요. 그러니깐 이런 거예요. NDCSession이란 녀석이 있는데 end란 함수가 어떤 건 인자 2개가 있고 어떤 건 인자가 0개에요. 그래서 C++ 컴파일러가 모르겠다는 거예요. 이거를 추론할 때. 여기서 어떻게 해야 되지?

해결법으로 여러 가지 생각해봤어요. 명시적으로 이 함수의 타입을 변환해서 알려주던가 혹은 이게 좀 귀찮으면 decltype이라고 변수의 타입을 알려주는 게 있는데요. 이 녀석을 써서 하든가. 아니면 class Template에다가 요런 식으로 명시적으로 인스턴스화를 하던가 아니면 다시 매크로를 써서 이런 짓을 해볼까? 아니면 오버로드 함수를 다 지워버릴까? 막 고민을 하는데 일단 4번은 매크로를 지우자고 매크로를 만드는 거고 1, 2, 3을 하면 너무 노가다를 많이 해야 되고 코드 라인이 어마어마한데 그리고 5번은 말도 안 되고 아 어떡하지? 하다가

훈련소를 갔어요. 제가 전문 연구원이라서 가야 돼요. 나라에서 불러서 연말을 행복하게 보내고요. 갔다 왔더니

각개전투를 배웠는데 거기서. 이게 오버로딩이 존재하는 케이스에 대해서 특수화를 해주면 되겠다는 생각이 들었어요. 물론 논산에서 깨달은 건 아니고 재밌자고 한 얘기에요. 그래서 만약에 이런 Variadic Template이 있으면 두 개가 모호하다. 그러면 두 개짜리를 이렇게 만들어주면 됩니다. 그러면 컴파일이 돼요. 와 컴파일이 됐어요. 그런데 이러면 그 아까 먼 과거, 그 이상한 착각이었던 것 같다. 그 코드랑 비슷하게 되는 거 아니냐? 했는데 막상 보면 Async 함수 개수는 45개에서 6개로 줄었고 class 개수는 한 번만 선언하면 되기 때문에 이렇게 줄었어요. 그래서 깔끔하게 처리가 됐다.

이야기였고요. 콜스택 줄이기라고 만약에 여기서 this의 타입을 알고 싶을 때 몰라가지고 꼭 impl이라는 함수를 통해서 this 타입을 추론했었는데요. 과거에는

이제는 decltype(this)를 쓰고 저기 remove_pointer 요런 식으로 확인해서 this의 타입을 마음껏 추론할 수 있습니다. 자세한 설명은 생략할게요.

Variadic Template을 적절히 활용하면 가독성을 높일 수 있다. 어우 너무 빨리했네요. 질문을 한 번 보고 갈게요. 너무 시간이 많으니깐. 없으면 어떡하지? 좋네요. 뭔가 있네요. “중간중간 성능 평가 데이터를 공유해 주셨는데 성능 평가 툴을 무엇을 사용하셨나요?” 저희는 Windows Platform이기 때문에 Windows Performance Monitor를 사용하기도 하고 Visual Studio 내에 VTune을 잘 어떻게 해서 만든 성능 측정 툴이 있습니다. 그것을 활용했어요. “학부생입니다. Vector의 push_back을 이용한 이동 생성 과정에서 임시 객체가 생성되는데 resolve해야 하는 것으로 알고 있지만 실무에서 c++ 11에 추가된 emplace_back을 사용하지는 않는지는” 아아 이거는 조금 다른 얘기고요. emplace_back을 사용한다는 것은 어떤 객체를 새로 만들면서 거기에 대입하겠다는 이야기고요. push_back은 기존에 가지고 있는 데이터를 옮기는 거기 때문에 조금 다른 개념이죠. “이동 생성에서 임시 객체”, 제가 맞는 말하고 있는가요? 질문을 잘 이해했는지 잘 모르겠는데 “임시 객체가... 네 push_back을…” 무슨 말인지 잘 모르겠네요. “Core Guideline 한국어 번역이 있는지 궁금합니다.” 저도 잘 모릅니다. “Modern C++를 공부하기에 좋은 책을 추천해주세요.” 하하하하 셋째 날 발표 오시는 Scott 님의 Effective Modern C++를 꼭 읽어보세요. 그리고 인터넷도 좋고요. Stack Overflow도 좋고요. 아까 tuple 관련은 다 Stack Overflow에서 배웠습니다. 아 그분은 화상으로 만날 수 있다고 들었네요. “기존 코드를 고칠 때 다른 팀원의 반발은 없었나요?” 어 이거 중요한데요. 왜냐면 라이브 코드다 보니까 제가 조금만 잘못 고치면 뻥뻥 터지고 이제 인벤에 글 올라오고 욕먹고 오래 살 수 있을 거 같긴 하지만 무섭죠. 그래서 저도 그래서 코딩을 해서 다른 브렌치에서 트렁크에 머지를 한 후에 롤백을 한 두세 번씩 했습니다. 최대한 QA를 많이 겪고 올리려고 그리고 팀원들의 반발은 딱히 없었던 게 이 코드들은 팀원들이 사용하지 않는 굉장히 Core한 코드들이었기 때문에 딱히 반발은 없었고 특히 저쪽 Variadic Template 고친 것에서는 더 깔끔한 것 같다고 칭찬해줘서 고마웠습니다. 너무 사적인 질문이 많네요. 나중에 한꺼번에 할게요. 미래와 약속.

C++가 Modern C++에서 이제 비동기 키워드들이 추가됐어요. async, future, promise, packaged_task, thread 뭐 이런 게 있는데 과거에는 OS 차원에서 이런 것들을 다 지원했죠. OS의 pthread라든지 뭐 그런 것들? Windows면 Parallel Algorithm 뭐 이런 헤더가 또 있고요. 그런데 이제 Cross Platform으로 바퀴를 다시 만들지 않아도 되도록 또 이제 STL 내부의 알고리즘을 믿으면서 사용할 수 있는 그런 키워드들이 11부터 추가됐고요. 앞으로 할 이야기는 Future-Promise 패턴이 익숙하면 딱히 어려울 게 없는데 저는 이 개선 과정을 겪으면서 처음 배워서 이해가 잘 안 됐습니다. 혹시 이해가 안 돼도 슬퍼하실 필요가 없어요.

제일 간단한 Thread, 그래서 이렇게 thread t를 만들 때 Function을 이렇게 받아서 이 t는 이걸 실행하는 거고요. 이런 식으로 람다를 쓸 수도 있고요. “Do you know Sae-dol Lee~?” 이렇게 할 수 있습니다. 원래 Scott이 온다 그래서 여기다가 “Scott Meyers, Do you know Sae-dal Lee~?” 하려고 했는데 안 온다 그래서 지웠는데 네, 그렇습니다. 그래서 t.join을 하면 thread가 끝나는 걸 기다릴 수 있습니다.

어려운 개념인데요. 약속과 미래. 약속을 만들어 볼게요. prom을 하고 이제 prom에서 미래를 가져올 수 있어요. get_future() 미래를 저장해 둘게요. 그리고 언젠가 이 promise에서 set_value(1)을 하게 되면 미래에 그 값이 들어가게 돼요. 그래서 그 미래의 값은 아까 받아놓은 미래 객체에서 fut.get()을 하면 됩니다. 이게 무슨 말이야?

하시는 분도 있을 텐데 다시 한 번 볼게요. 약속을 통해서 미래라는 객체를 받을 수 있어요. 여기 promise에서 get_future() 그럼 이거를 우리가 들여다보는 거예요. 이게 future는 객체를 하나 가지고 있다가 어? 여기 값이 들어왔나? 열어보고 안 들어와 있으면 다시 닫고 아니면 들어올 때까지 기다려볼 수도 있고 안 볼 수도 있겠지만요. 그렇고 그다음에 promise에다가 다시 set_value 하게 되면 아까 우리가 받은 그 상자 안에 값이 들어가게 되는 거예요. 그리고 언제 행해질진 모르겠지만 결과가 담겼는지 확인할 수 있다. 확인하는 방법은 fut.get()을 하면 됩니다. get()을 하게 되면 어떤 값이 담길 때까지 기다리게 되고요. 저는 이걸 처음 보고 와 미래라는 관념을 CS에서 실체화했구나 해서 큰 감동을 받았습니다.

Async 함수는 이 future와 promise를 이용해서 비동기적으로 수행하는 패턴인데요. 예를 들어 async, launch::async 이게 뭔진 곧 설명할게요. foo, 1.0을 넘겼어요. 그러면 이 foo란 함수를 다른 Thread에서 실행해줍니다. 그리고 그 결과값을 담을 객체 이거 future가 되겠죠. auto는 을 내뱉게 되고 나중에 future에서 get을 통해서 값을 알 수 있습니다. 즉, promise와 어떤 function pointer 람다를 가지고 미래의 값을 계산하는 그런 방식이죠. 그래서 이것의 장점은 일단 언제 실행할지 실행을 쓰고 실행 결과값은 나중에 내가 원하는 시점에 받아올 수 있다. 이렇게 보시면 되고요. 정책이 두 가지가 있는데요. launch::async는 바로 이거를 부르자마자 다른 Thread에서 비동기로 실행되는 게 보장됩니다. 그런데 lauch::deferred는 나중에 값을 필요로 할 때 실행을 하게 되고요. 이것을 Lazy Evaluation이라고 부릅니다.

그래서 future 패턴을 어디서 쓰면 좋을까? 그래서 흔히들 비동기를 계속 사용하면 콜백, 콜백, 콜백을 해서 이런 식으로 무서운 코드가 만들어지는데요. 이걸 벗어나고 싶을 때 사용할 수 있고요. Single Thread Logic이 이 중에 있는데 중간중간에 분산 Logic을 섞고 싶을 때 사용하면 좋습니다. 이 이야기는 Futures For C++ 11 at Facebook이라고 페이스북에서 c++ 11의 future를 사용한 이야기를 담은 Article에서 봤고요. 이 그림도 거기 있는 것입니다.

그래서 예를 들면 요 쪽에서 원래 job을 순서대로 순서대로 실행하는 코든데요. job list에서 job을 돌면서 Execute하는 건데 만약에 Future-Promise 패턴을 쓰게 되면 future를 담을 Vector를 하나 만들어두고 여기에다가 async를 써서 future에 결과값을 담게 됩니다 그러면 얘는 lauch::async니까 어떤 다른 Thread에서 막 실행되고 있겠죠. 이제 그다음에 future vector를 순회하면서 get을 하게 되면 값을 다 얻어올 수 있게 됩니다.

저희 서버에서 어떤 데이터가 많을 건데 데이터들을 읽어오는 과정은 이렇습니다. 그룹이 많이 있고요. 어이고 어디 갔지? 그룹이 많이 있고요. 그래서 더 있는데 이게 각 Thread마다 이 그룹을 하나씩 실행합니다. 그룹을 나누는 기준은 서로 종속성이 없어야 돼요. 예를 들어 NPC 스킬 데이터 같은 경우에는 반드시 NPC 데이터를 다 읽고 읽어야 됩니다. 왜냐하면 NPC 스킬 데이터를 읽고 가공할 때 NPC 데이터가 필요하기 때문이죠. 마찬가지로 유저 데이터는 유저 스킬 데이터 이런 것들도 마찬가집니다. 그런데 문제가 이런 게 생겨요. NPC 스킬 데이터를 읽는 과정이 엄청 오래 걸리는데 얘는 반드시 NPC 데이터 이후에 와야 되고 NPC 파티 데이터는 이거 다음에 와야 돼. 그래서 아무리 Thread를 잘 나눠서 잘 분산해도 이 과정 때문에 전체 로드 과정이 오래 걸리게 되는 거죠. 그룹 1, 2, 3은 다 하고 놀고 있는 거예요. 그래서 종속성 때문에 더는 분산이 안 되고 휴리스틱한 방법으론 확실히 개선이 힘들구나. 그래서 NPC 스킬 데이터에 Future-Pormise 패턴을 적용해보면 어떨까? 그러니까 여기 여러 파일들이 있는데 이 파일들을 다 Future-Promise를 써서 Async를 써서 다 나눠서 보면 어떨까? 처리하면 어떨까? 생각을 했습니다.

그래서 std::async를 바로 사용해서 아까 말했던 launch::async를 사용해서 바로 프로토타이핑을 해봤어요. 와 효과는 굉장했습니다. 나중에 얼마큼 좋아졌는지 말씀드릴 건데 하지만 새로운 Thread를 생성하기 때문에 엄청나게 많은 Thread들이 찍혀서 덤프에 남게 되는 거를 확인할 수 있습니다. 어 이게 문제가 되는 상황은 아닌데 왠지 저희 구성원들이 이거를 덤프를 열고 이거를 봤을 때 야 이게 뭐냐? 이렇게 말할 것 같아서 그리고 이왕 하는 김에 제대로 공부해보자. 해서 내가 구현을 해야겠다.

그래서 이렇게 하는 거예요 async랑 똑같고요. 여기서 미리 읽는 작업들에 대해서 promise를 다 만들어두고 다른 Thread들로 다 분산해줍니다. 그다음에 이 Thread에서는 future를 기다리기만 해요. 이렇게 하면 이 작업이 다 끝난 이후에 NPC 파티 데이터를 읽기 때문에 종속성이 해쳐지지 않죠. 간단한 개념인데 이렇게 작업을 했습니다.

그래서 이런 식으로 뭔가 구성원들이 익숙한 아까 봤던 그 async랑 비슷하게 생긴 Member Function Pointer를 받고 인자를 받고 여기서도 아까처럼 Variadic Template을 썼죠? 그래서 이렇게 람다로 만들어서 나중에 실행하고 이런 과정들을 거쳐서 만들었습니다.

그래서 예를 들어 LoadNPCSkillData가 있으면 각 파일들에 대해서 future work를 해서 future를 담고요. 저쪽에 있는 어떤 work Thread에서 막 얘를 처리해 줄 거예요. LoadSkillData라는 함수를. 물론 여기서 LoadSkillData 안에다가 적당히 Lock을 걸어서 자료가 잘 안전하게 저장되는 걸 보장해줘야겠죠. 그리고 마지막에 여기서 get을 통해서 값을 가져오면 1열의 Single Thread Logic 같지만 결과론적으로 분산해서 잘 처리할 수 있습니다.

그래서 개선 결과를 보면요. 기존에 이게 보통의 경운데 xml 데이터를 읽어서 원래 150초가 걸렸는데 77초로 줄었어요. 그래서 원래 2분 30초쯤 걸리면 화장실 한 번 갔다 와야 되는데 이제 화장실을 못 가게 됐다. 이렇게 불평하시는 분도 있고요. 이쪽 바이너리는 미리 xml 데이터를 덤프화해서 사용하는 방식이고요. 이런 식으로 나아졌는데 근데 저도 사실 150보다 훨씬 많이 걸렸던 기억이 나요. 성능 측정할 땐 이랬는데. 그래서 팀장님이 그랬어요. 어 나는 Before도 저렇게 안 걸려. 난 한 500초 걸려. 이걸 봐야 됩니다. 그 Windows 전원 관리 옵션에 보시면 균형 조정이라고 돼 있을 거예요. 저희 팀 10명 중 8명이 균형 조정이었습니다. 이거를 하고 이제 이게 300~150이 되고 다시 77이 돼서 체감상 아주 좋아졌는데요. 네 그렇습니다. 

오늘 Windows PC 사용하시는 분은 전원 관리 옵션을 살펴보십시오. 농담 아닙니다. 드디어 Q&A가 왔네요.

Reference는 이렇고요. 저작권 잘 밝혀야 된다 그래서.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
