240827 CS세션 - 서버/클라이언트, WAS/게임서버

LIHA·2024년 8월 26일

CS세션 내일배움캠프

내일배움캠프

목록 보기

27/54

서버 - 클라이언트

개념

웹을 공부할 때도 본 기억이 있다 싶었는데 항해때 WIL 에 있었다.

클라이언트가 request를 던져주고 response를 받아가고, 서버에서 그 request를 받아 처리를 위한 핸들러를 맵핑하고 비스니스 로직을 돌리고 결과를 response로 돌려준다는 큰 구조는 같지 않을까 생각된다.
그러나 정확한 정의를 말하라면 잘 모르겠다. 정확히 뭘 말하는걸까?

서버: 클라이언트의 요청에 응답하여 서비스를 제공하는 시스템
클라이언트: 서버에게 데이터를 요청하고 받아가는 사용자, 혹은 그 사용자가 이용하는 시스템

구조

참고한 블로그

DB가 서버 안에 있는 줄 알았는데 이 이미지를 보니 전혀 다르다.
네트워크를 통해 브라우저(클라이언트)에게 리퀘스트를 받은 서버는 이 요청을 처리하기 위해 웹 애플리케이션 서버와 통신하고,
웹 애플리케이션 서버는 DB에 접근해 서버가 받아온 리퀘스트에 부합하는 리스폰스를 만들어내 다시 서버에게 돌려준다.

WAS / 게임서버

웹 애플리케이션 서버

웹 서버가 아니라 웹 애플리케이션 서버? WAS와 게임 서버를 비교하려면 먼저 WAS가 뭔지부터 알아볼 필요가 있다.
AWS의 웹서버-애플리케이션 서버 차이 기술
요즘IT 매거진의 웹서버와 WAS

웹 애플리케이션 서버의 특성을 정리하면 다음과 같다.

웹 서버와 동일하게 HTTP 기반으로 동작하여, 웹서버가 할 수 있는 기능 대부분은 WAS에서도 처리할 수 있다.
비즈니스 로직(서버사이드 코드)를 처리할 수 있어 사용자에게 동적 컨텐츠를 전달할 수 있다. 이때 주로 DB서버와 같이 수행된다.
(그래서 애플리케이션 서버의 태스크가 보통 더 복잡하다)
인터넷 상에서 HTTP를 통해 사용자 장치에서 애플리케이션을 수행해주는 '미들웨어'로 볼 수 있다.
또한 사용하는 통신 프로토콜도 웹서버가 쓰는 것 + α 를 사용하여 다른 소프트웨어 구성요소와 통신한다.
웹 서버는 멀티스레딩을 지원하지 않지만 WAS는 멀티스레딩을 지원한다.
대표적인 예시로 아파치 톰캣, JBoss, Web Sphere 등이 있다. (!!! 톰캣이 웹 서버가 아니라 WAS였구나!!)

게임서버

게임은 많이 해 보았는데 게임서버에 대한 지식이 전무하여 큰일이다...
인프런 문답

참고한 인프런의 문답 내용은 다음과 같다.

우선 웹서버는 '연결을 끊는다'는 개념이 없습니다.
연결을 맺고 데이터를 주고받는 것은 TCP 서버 방식이고, 웹은 필요할때마다 요청을 쏘는 방식입니다.
서버를 꼭 한개만 연결해야 하는 것은 아니고 실제로 MMO에서 게임 플레이는 게임 서버로, 기타 정보는 웹서버로 받는 경우도 더러 있습니다.

매치메이킹 서버는 보통 TCP 서버 방식으로 하는 경우가 많습니다.
(Redis 등 별도의 실시간 DB 활용할 게 아니라면 그게 편합니다.)
일반적인 구조는 웹서버(로그인/인증/기타정보) - 매치메이킹(TCP) - 게임서버(TCP)
이렇게 3개의 서버를 두는 것이고 매치메이킹과 게임서버는 서로 Connection을 맺고 통신을 하면서 정보를 교환합니다.
매치메이킹에서 클라한테 몇번 방으로 가라고 클라에 알려주면, 클라가 다시 게임서버에 붙어서 게임을 진행하는 것이죠.

그런데 처음부터 서버 분산을 하면, 생각하던 것에 비해 작업이 생각보다 많고 어렵습니다.
그냥 서버 하나에서 매치메이킹-게임서버를 겸업하는 것도 시작할 때 괜찮은 방법이긴 합니다.
그리고 온라인 게임이라면 웹서버는 결국 붙어야 합니다.
초반 인증이나 결제 쪽을 웹으로 해줘야 하기 때문이죠.

생각해보면 당연한 거기도 한데, 게임서버는 한개로 돌아가는게 아니었구나.

WAS와 게임서버의 공통점과 차이점

내용들을 종합해보면... 아니 종합이 안 된다. 머리가 어지러우니 참고 블로그 를 통해 정리를 해보자...

공통점

서버 - 클라이언트 간 통신을 한다 (WAS의 경우 직접 하는 것은 아니고 웹서버를 경유해 받지만)
DB와의 통신을 한다

차이점

웹에서의 통신은 보통 단방향 통신이 대부분이다.
Stateful Server 게임과 비교하면 WAS는 항상 Stateless라 통신이 종료되면 연락이 끊어진다.
Stateful Server 게임은 실시간 통신이 아주 중요하다.
WAS는 반드시 response를 돌려줘야 하지만, 게임서버는 그렇지 않아도 된다.
혹은 한 개의 response를 복수의 client에게 돌려줘야 할 때도 있다. (한 유저의 상태 변화 - 모두에게 적용되도록)

게임 서버에서 중요하게 다루어야 하는 것?

화두를 들었을 때 대강 대용량 트래픽 처리, 패킷 암호화, 분산 처리... 등이 떠오른다.
그러나 엄밀히는 게임 서버도 한 종류가 아니라고?

웹서버와 소켓서버의 차이?

게임 서버직군 공고가 웹서버 / 소켓서버로 나뉘는구나. 그러면 둘이 분명히 다르단 얘기겠지.
위 페이지에 정리된 내용은 다음과 같았다.

소켓 서버?

TCP/IP, UDP/IP의 소켓을 직접 다루거나, 그것을 직접 다루는 엔진을 사용한 프로그래밍

특성

커넥션 풀을 직접 관리. 서버가 원할 때 클라이언트에 패킷을 보낼 수 있음
서버 자체의 메모리에 유저 데이터들을 들고 처리할 수 있음
보통 MMORPG나 MO FPG등 실시간성이 중요시되는 게임개발에 사용
소켓을 다룬다는건 OS의 기능을 직접 다룬다는 의미
주로 멀티스레드로 개발됨
메모리에 들고있음 + 멀티스레드 = 잘 못 다루면 대환장파티
최적화 = 서버 머신 한대 당 몇 명의 동시접속자 처리가 가능한가 = 돈
수평 확장 어려움. 직접 CAP중 일부 컨셉을 차용해 개발할수도 있지만 충분한 돈과 시간과 노하우가 필요함

그렇다면 게임에서 쓰는 웹서버는?

아파치, node.js, iis등 웹 서버 프로그램을 띄우고, 그 안의 컨텐츠를 작업함
모든 요청은 웹 리퀘스트로 들어오며 라우팅 된 주소가 각각의 함수, 인자값이 됨

특성

모든 요청마다 별도로 커넥션을 맺고 끊는 방식. 웹 요청과 동일
서버 자체의 메모리에 유저 데이터를 들고있지 않도록 개발됨 (수평 확장 때문)
보통 실시간성이 적은 게임개발에 사용.
매번 커넥션 맺음 + 메모리에 없음(디비 항상 다녀옴) = 상대적으로 성능이 느릴수밖에 없음
수평 확장이 비교적 용이. 메모리에 없기 때문에 그냥 웹서버를 여러대 띄우는걸로 부하 분산
성능, 실시간처럼 보이는 처리를 위해 각종 미들웨어를 공부하고 사용해야 함
그래도 캐싱정도는 해야지 싶어서 레디스 등을 사용하기도 함
내부 요청에 대한 완벽한 보장을 하기 위해 카프카 등을 사용하기도 함
여러 웹서버의 로그를 잘 모아서 처리하기 위해 몽고디비 등을 사용하기도 함

그리고 코멘트의 첨언

socket 서버가 http 웹 서버를 포함 하는 것입니다. 소켓 서버는 패킷내용을 개발자가 원하는 대로 지정할 수 있습니다. 하지만 브라우저와 같이 넓은 범용성으로 작동하려면 미리 통신 규약을 지정해야 겠죠?

아무래도 http/s가 미리 구현되어있는 기능들이 많아 쉽게 사용하실 수 있습니다.
반면에 소켓은 최적화에 더 자유도가 있겠지만 패킷 유실이라던가 암호화 방식 등 신경 써야할 것이 많습니다

실시간 VS 비실시간 온라인 게임

참고

실시간 온라인 게임 / Stateful Server - 고성능의 처리능력과 안정성이 보장되어야 하며 개발 자체의 난이도가 높은 편.
-> C++ / Socket / Realtime / MMORPG. 의외로 브롤스타즈도 Stateful 게임.
비실시간 온라인 게임 / Stateless Server - 대부분의 모바일 게임에서 사용하는 기술로, 클라이언트 기기에서 싱글 플레이 후 결과만을 서버에 저장하는 방식. 서버와의 실시간 연동이 없어 간헐적인 단발성 컨텐츠 로직만을 서버가 처리하게 된다. 서버 개발과 유지보수가 간편하다. 많은 개발사가 이 기술로 게임을 제작한다.
-> HTTP / Web / Java / Node.js