Computation suite

blocking / non-blocking Blocking socket mode 소켓 함수 호출 시, 조건이 만족되지 않으면  함수가 r eturn하지 않고 스레드 실행이 그 위치에서 정지 한다. 조건이 만족될 때, socket 함수가 return하며 정지 상태의 스레드가 깨어난다.(wake-up) 그리고 작업을 재개한다. 조건이 만족되는 시점이 길어지면 교착 상태로 인해 스레드가 오랜 시간 정지할 수 있다. 다른 스레드가 있다면 TerminateThread() 함수를 호출해 강제 종료시키거나 주 스레드가 종료되어 모든 스레드가 종료되기를 바래야한다. Non-blocking socket mode 소켓 함수 호출시, 조건이 만족되지 않아도 일단 함수가 return 한다. (이 때, 조건이 만족되지 않았다는 오류를 리턴한다.) 때문에 중단 없이 다음 코드를 계속 수행한다. 멀티스레드를 사용하지 않고도 싱글스레드로 여러 소켓을 번갈아가며 입출력 처리를 할 수 있으며 중간에 다른 작업을 수행할 수 있다. 그러나 위에서 말한 '조건이 만족되지 않았다는 오류'를 처리해야한다. 클라이언트가 없어도 계속 cpu자원을 소모하여 함수 return 로직을 수행하기 때문에 blocking 소켓보다 CPU 사용률이 높다. 윈도우에서 제공하는 Select 모델을 사용하면 소켓 함수 호출 성공시점을 미리 알 수 있다. 블록킹 소켓의 단점인 교착상태 돌입 위험과 넌블록킹 소켓의 단점인 '조건 불충족 오류' 처리 로직을 해결할 수 있다. 동기 입출력 / 비동기 입출력 동기 입출력 ( synchronous I/O ) 1. 응용 프로그램이 입출력 함수를 호출하고,    입출력 작업이 끝날 때까지 기다린다. 2. OS는 입출력 작업을 커널 모드에서 수행한다. 3. 커널 모드의 입출력 작업이 완료되면 입출력 함수가 리턴한다. 4. 응용 프로그램은 리턴된 값을 처리하거나     다른 작업을 진행한다. 입출력 작업이 완료될 때까지 기다린다. 비동기 입출력 (...

이런 저런 채용공고를 둘러보다가 이런 개발 세상도 있구나~ 하고 잠깐 조사했다. 윈도우 운영체제에서 제공하는 기술이라 생소한 용어들이 많다. 윈도우의 소켓 입출력 모델을 사용한다는 것은? 윈도우는 다양한 소켓 입출력 모델을 제공한다. - Select, WSAAsyncSelect, WSAEventSelect - Overlapped(1), Overlapped(2) - Completion Port 윈도우에서 제공하는 소켓 입출력 모델을 활용한다는 것은 새로운 전송 프로토콜을 작성하는 것이 아니다. TCP나 UDP와 같은 전송 프로토콜은 유지하되, 종단에서 Socket(구조체/인터페이스)이 어떻게 데이터를 Read/Write 할 지 로직을 작성하는 것이다. 즉, 여기서 데이터를 인출하고, 데이터를 쓸 때의 효율 을 따지는 과정이다. 많은 연결이 서버에서 이뤄지고 연결당 계산이 무거운 경우, User 모드와 Kernel 모드에서 자원 분배가 효율적으로 이뤄진다면 ( CPU/메모리 ) Response time을 줄일 수 있다. Raw Socket과 차이 앞서 설명한 소켓 입출력 모델의 전제는 소켓으로서 TCP 소켓이나 UDP 소켓을 사용한다는 것이다. 데이터를 전송할 때, 네트워크 계층을 내려가며 운영체제가 프로토콜 헤더를 붙여서 패킷을 제작한다. Raw socket을 사용하면 애플리케이션 단에서 직접 프로토콜의 헤더 일부를 생성할 수 있다. 헤더 일부를 직접 생성함으로서 세부적으로 제어할 수 있지만 그만큼 동작이 복잡해진다.

서비스 분리 채팅과 같은 소셜 기능을 담당하는 서버는  게임 서버와 분리하는 것이 성능과 확장성 측면에서 좋다. 채팅 서비스, 게임 서버 서비스를 분리해서 운영한다면 마이크로서비스 지향 아키텍처를 더 관리하기 쉬워진다. monolithic 아키텍쳐에서 멀티플리어 게임 서버를 구축하는 경우 같은 기술 스택-데이터베이스-개발 환경을 사용해야한다. monotlithic 아키텍쳐에서는 서비스의 한 부분이 망가지면 모든 게임 서비스가 망가지게된다. 게임이라는 서비스를 마이크로서비스화 한다면 전체를 구성하는 하나의 서비스가 망가지더라도 다른 서비스는 정상 운영할 수 있고 고치기 쉽다. 게임 서버는 유저의 움직임 및 상태를 실시간으로 수신해서 처리하는 것이 목적이다. 위의 예시와 같이 하나의 서버에 두가지 목적을 가진 프로그램이 돌고 있다면 탈중앙화한 컴포넌트로 전환하여 관리하는 것이 유지보수 측면에서 좋다. 채팅 서비스 뿐 아니라 게임 서버와 분리하면 좋은 서비스들은 인증-통계-리더보드 서비스 등이 있다.   서비스 분리를 하지 않는다면 멀티플레이어 게임의 게임 서버는 성능이 중요하다. 사내 테스트에서는 잘 돌아갈 지몰라도 프로덕션 환경에서 채팅+게임 서버 프로세스가 같이 돌아간다면 지연 시간이 늘어날 것이다. 때문에 마이크로서비스화 한 후에도 cpu와 네트워크 자원을 지속적으로 모니터링하고 효율적으로 사용할 전략을 세울 필요가 있다. 사용자가 100명 정도로, 다수가 참여하는 멀티플레이어 서버를 예를 들면 게임 서버로 동시에 수 천개의 메시지가 전송될 수 있다. 사용자도 많거니와 사용자: 사용자 상태 정보는 1:N이기 때문이다. 채팅 서버가 같이 돌고 있다면 악의적으로 채팅 서버로 채팅을 많이 보내서 전체적인 게임 서버의 성능을 하락시킬 수 있다. 게임 서버는 이미 게임 플레이를 위해 물리/그래픽/사운드 처리를 cpu intensive하게 하고 있어서 대응하기 어렵다. UDP 대 TCP 게임 서버 턴제 게임같은 경우가 아닌 빠른 페이스로 진행되는 멀티플...