웹을 공부할 때도 본 기억이 있다 싶었는데 항해때 WIL 에 있었다.
클라이언트가 request를 던져주고 response를 받아가고, 서버에서 그 request를 받아 처리를 위한 핸들러를 맵핑하고 비스니스 로직을 돌리고 결과를 response로 돌려준다는 큰 구조는 같지 않을까 생각된다.
그러나 정확한 정의를 말하라면 잘 모르겠다. 정확히 뭘 말하는걸까?
서버: 클라이언트의 요청에 응답하여 서비스를 제공하는 시스템
클라이언트: 서버에게 데이터를 요청하고 받아가는 사용자, 혹은 그 사용자가 이용하는 시스템
DB가 서버 안에 있는 줄 알았는데 이 이미지를 보니 전혀 다르다.
네트워크를 통해 브라우저(클라이언트)에게 리퀘스트를 받은 서버는 이 요청을 처리하기 위해 웹 애플리케이션 서버와 통신하고,
웹 애플리케이션 서버는 DB에 접근해 서버가 받아온 리퀘스트에 부합하는 리스폰스를 만들어내 다시 서버에게 돌려준다.
웹 서버가 아니라 웹 애플리케이션 서버? WAS와 게임 서버를 비교하려면 먼저 WAS가 뭔지부터 알아볼 필요가 있다.
AWS의 웹서버-애플리케이션 서버 차이 기술
요즘IT 매거진의 웹서버와 WAS
웹 애플리케이션 서버의 특성을 정리하면 다음과 같다.
게임은 많이 해 보았는데 게임서버에 대한 지식이 전무하여 큰일이다...
인프런 문답
참고한 인프런의 문답 내용은 다음과 같다.
우선 웹서버는 '연결을 끊는다'는 개념이 없습니다.
연결을 맺고 데이터를 주고받는 것은 TCP 서버 방식이고, 웹은 필요할때마다 요청을 쏘는 방식입니다.
서버를 꼭 한개만 연결해야 하는 것은 아니고 실제로 MMO에서 게임 플레이는 게임 서버로, 기타 정보는 웹서버로 받는 경우도 더러 있습니다.
매치메이킹 서버는 보통 TCP 서버 방식으로 하는 경우가 많습니다.
(Redis 등 별도의 실시간 DB 활용할 게 아니라면 그게 편합니다.)
일반적인 구조는 웹서버(로그인/인증/기타정보) - 매치메이킹(TCP) - 게임서버(TCP)
이렇게 3개의 서버를 두는 것이고 매치메이킹과 게임서버는 서로 Connection을 맺고 통신을 하면서 정보를 교환합니다.
매치메이킹에서 클라한테 몇번 방으로 가라고 클라에 알려주면, 클라가 다시 게임서버에 붙어서 게임을 진행하는 것이죠.
그런데 처음부터 서버 분산을 하면, 생각하던 것에 비해 작업이 생각보다 많고 어렵습니다.
그냥 서버 하나에서 매치메이킹-게임서버를 겸업하는 것도 시작할 때 괜찮은 방법이긴 합니다.
그리고 온라인 게임이라면 웹서버는 결국 붙어야 합니다.
초반 인증이나 결제 쪽을 웹으로 해줘야 하기 때문이죠.
생각해보면 당연한 거기도 한데, 게임서버는 한개로 돌아가는게 아니었구나.
내용들을 종합해보면... 아니 종합이 안 된다. 머리가 어지러우니 참고 블로그 를 통해 정리를 해보자...
공통점
차이점
화두를 들었을 때 대강 대용량 트래픽 처리, 패킷 암호화, 분산 처리... 등이 떠오른다.
그러나 엄밀히는 게임 서버도 한 종류가 아니라고?
게임 서버직군 공고가 웹서버 / 소켓서버로 나뉘는구나. 그러면 둘이 분명히 다르단 얘기겠지.
위 페이지에 정리된 내용은 다음과 같았다.
소켓 서버의 특성
- 커넥션 풀을 직접 관리. 서버가 원할 때 클라이언트에 패킷을 보낼 수 있음
- 서버 자체의 메모리에 유저 데이터들을 들고 처리할 수 있음
- 보통 MMORPG나 MO RPG등 실시간성이 중요시되는 게임개발에 사용
- 소켓을 다룬다는건 OS의 기능을 직접 다룬다는 의미
- 주로 멀티스레드로 개발됨
- 메모리에 들고있음 + 멀티스레드 = 잘 못 다루면 대환장파티
- 최적화 = 서버 머신 한대 당 몇 명의 동시접속자 처리가 가능한가 = 돈
- 수평 확장 어려움. 직접 CAP중 일부 컨셉을 차용해 개발할수도 있지만 충분한 돈과 시간과 노하우가 필요함
게임에서 쓰이는 웹서버의 특성
- 모든 요청마다 별도로 커넥션을 맺고 끊는 방식. 웹 요청과 동일
- 서버 자체의 메모리에 유저 데이터를 들고있지 않도록 개발됨 (수평 확장 때문)
- 보통 실시간성이 적은 게임개발에 사용.
- 매번 커넥션 맺음 + 메모리에 없음(디비 항상 다녀옴) = 상대적으로 성능이 느릴수밖에 없음
- 수평 확장이 비교적 용이. 메모리에 없기 때문에 그냥 웹서버를 여러대 띄우는걸로 부하 분산
- 성능, 실시간처럼 보이는 처리를 위해 각종 미들웨어를 공부하고 사용해야 함
- 그래도 캐싱정도는 해야지 싶어서 레디스 등을 사용하기도 함
- 내부 요청에 대한 완벽한 보장을 하기 위해 카프카 등을 사용하기도 함
- 여러 웹서버의 로그를 잘 모아서 처리하기 위해 몽고디비 등을 사용하기도 함
socket 서버가 http 웹 서버를 포함 하는 것입니다. 소켓 서버는 패킷내용을 개발자가 원하는 대로 지정할 수 있습니다. 하지만 브라우저와 같이 넓은 범용성으로 작동하려면 미리 통신 규약을 지정해야 겠죠?
아무래도 http/s가 미리 구현되어있는 기능들이 많아 쉽게 사용하실 수 있습니다.
반면에 소켓은 최적화에 더 자유도가 있겠지만 패킷 유실이라던가 암호화 방식 등 신경 써야할 것이 많습니다
실시간 온라인 게임 / Stateful Server - 고성능의 처리능력과 안정성이 보장되어야 하며 개발 자체의 난이도가 높은 편.
-> C++ / Socket / Realtime / MMORPG. 의외로 브롤스타즈도 Stateful 게임.
비실시간 온라인 게임 / Stateless Server - 대부분의 모바일 게임에서 사용하는 기술로, 클라이언트 기기에서 싱글 플레이 후 결과만을 서버에 저장하는 방식. 서버와의 실시간 연동이 없어 간헐적인 단발성 컨텐츠 로직만을 서버가 처리하게 된다. 서버 개발과 유지보수가 간편하다. 많은 개발사가 이 기술로 게임을 제작한다.
-> HTTP / Web / Java / Node.js