Async와 Job방식의 차이가 궁금합니다.

Question

이전 강의에서 PacketHandller 부분에서 Async를 사용하지 않고 Blocking 방식을 사용하는 이유가 EAP 기반이기 때문에 이미 패킷마다 할당된 쓰레드에 의해 I/O가 이루어지기 때문이라고 이해했습니다. 하지만 GameRoom같은 경우엔 GameRoom 담당 쓰레드가 존재하고 GameRoom 쓰레드의 동기화를 위해 JobSerialize를 이용하여 각 쓰레드가 GameRoom의 Job을 Push하여 동기화를 진행하는데 이때 Job 안에서 DB I/O가 Blocking으로 이루어질 경우 GameRoom 쓰레드가 Blocking이 되고 그렇게되면 GameRoom이 느려지는 상황이 되기때문에 DB I/O 전용 쓰레드(JobSerialize)를 만들어 쓰는것으로 이해했습니다. 결국 개념적으로 봤을때 GameRoom 쓰레드는 메인쓰레드 역할을 하고 DB I/O 처리는 서브쓰레드에게 맡기고 완료됐을때 결과만 다시 메인쓰레드에 돌려받는 NonBlocking I/O 방식인데 Async/Await 역시 호출한 쓰레드를 Blocking 하지 않고 서브쓰레드에게 I/O를 맡긴뒤 작업이 완료되면 메인쓰레드에 결과를 반환하여 Await 이후에 처리한다고 이해하고 있습니다. 그렇다면 복잡하게 DB I/O 전용 쓰레드를 만들어주지 않고 Async/Await만 사용해도 될것같은데 이렇게 하는 이유가 있을까요? 아니면 이후에 강의에 이에 대한 개선이 나오는걸까요?

Rookiss · Answer

그냥 간단하게 답변 드리자면, 이런 부분은 자꾸 정답이 있다 생각하여 질문을 하실 필요 없고 원하시는 대로 하시면 됩니다. 기본적으로 서버는 C++로 만드는 비중이 높아왔고 그렇기 때문에 DB도 async/await 방식이 아닌 블로킹으로 하되 따로 쓰레드를 빼는 것이 정석이지만, 요즘은 DB 부분만 REST API 웹으로 빼서 하는 경우도 있습니다. 중요하게 지킬 부분은 그냥 <로직 쓰레드에서 DB 처리를 기다리느라 대기하면 절대 안 된다>는 절대 원칙 하나 정도이고 그 나머지는 정말 하고 싶으시다면 async/await 방식으로 하거나 다른 방식으로 하거나 그것은 중요하지도 않고 사실 리드 프로그래머가 정책을 결정하면 따르면 됩니다. (서버 쪽은 보수적이라 async 기반으로 하는 프로젝트를 보지는 못했지만..) 컨텐츠를 만들다 보면 특정 DB 요청이 끝난 후에야 다음 요청을 처리해야 하는 경우가 많기 때문에 저라면 여전히 블로킹 DB 쓰레드를 선호할 것 같고 그리고 실전 MMO에선 DB 쓰레드를 4개 이상 배치하긴 합니다.