아아 그 게임끝나고 게임서버는 접속을 종료처리하고 api서버에서 db처리를 하다가 다시 게임시작하면 게임서버와 연결하는 방식으로 하셨나요? - dc App
글쓴 ㅇㅇ(1.228)2025-03-05 17:08:00
답글
프론트쪽은 HTTP 요청 처리할 서버랑 소켓서버를 따로뒀었어요. 아마 이게 질문자님이 말하는 API 서버 역할을 할것 같구요. DB처리는 따로 백엔드쪽 서버를 하나 더 뒀었어요. 게임 종료후 재접속 절차를 묻는거라면 그건 구현하기 나름일것 같아요.
ㅇㅇ 1(39.113)2025-03-05 17:16:00
답글
저라면 게임이 종료되어도 소켓서버쪽 연결은 안끊을것 같아요. 부하테스트하면서 확인해보니 소켓 연결할때마다 생기는 부하량이 생각보다 부담스럽더라구요. 1코어짜리 클라우드 컴퓨터에서 동시접속자 네자릿수 가까이 가면 CPU점유율이 순간적으로 100%씩 찍히는게 좀 아찔해 보여서... 턴제겜이라 통신량이 적어서 그런지 게임 하는동안에는 잠잠한데 한번에 접속이 몰릴때마다 사용률이 요동치는게 보기 싫어서 내린 조치였네요.
ㅇㅇ 1(39.113)2025-03-05 17:18:00
답글
그럼 유저는 소켓서버에 연결하고, 게임관련 패킷을 소켓서버에 보내면 그걸 redis에 쌓고 그걸 인게임이 가져다가 처리하는거? redis가 rdbms보단 빠르다고는 하지만, 그러면 실시간이 중요한 상황에서 레이턴시같은건없음?? 뭔가 신박해보여서 궁금함
소닉쫄따구테일즈(dcz3xv7zgu14)2025-03-06 10:52:00
답글
내가 말하는건 그냥 통신만 중개하는거임. pub,sub 기능으로 레디스에 구독된 서버들끼리 데이터 주고받는게 가능해서 그걸로 통신함. 소켓서버가 8개, 인게임서버가8개 있다고 가정하면 모든 서버들이 일일이 서로 연결하고 관리하는건 힘들잖아. 그래서 서버간의 통신을 중앙관리하는 역할로 Redis를 썻음, 그러면 Redis 자체가 캐싱 역할도 가능하니까, 게임내 핵심 데이터들을 실시간으로 보관해주면 유사시에 패일오버도 가능하고
ㅇㅇ 1(39.113)2025-03-06 14:11:00
답글
시험삼아 테스트했을때는 레이턴시에 유의미한 차이 없었음. 정확히는 노이즈가 많아서 측정값이 들쭉날쭉하더라, 오히려 Redis 중개하니까 더 빠를때도 많았고. IaaS쪽 파트너 끼고 직접 테스트하면 달라젔으려나? 어쨋든 인게임서버랑 소켓서버가 분리되 있으니까, 사용자수가 많아질수록 오히려 성능 이점이 많더라고.
ㅇㅇ 1(39.113)2025-03-06 14:18:00
답글
내가 쌉고수는 아니라서 내가한게 무조건 정답이다 라는건 아니고 난 이런식으로 만들었음. 성능 확장도 용이하고 장점도 많아서 더 연구해보고 싶긴한데... 저런식으로 해서 성능 이득 보려면 동접자수 다섯자리는 찍어야 되겠더라고 내 인생에 그런게임 만들 기회가 언제 올지 모르겠다.
ㅇㅇ
웹서버에서 유저를위한 인증토큰같은걸 만들거나 해서 redis에 넣어놓으면 유저가 게임서버에 접속할때 게임서버가 그걸보고 얠 받아들일지 말지 판단하겄지. 귀찮으면 그냥 웹서버에 쓰는 인증토큰 그대로 쓰던가. 그럼 인증에 redis도필요없을테고. 근데 어떤게 좋을진 모르겠네. 서버 고수한테물어봐
나는 온라인 턴제게임 만들때 인게임 서버랑 소켓서버를 아예 분리해서 만들었음. Redis를 중개자로 둬서 두 서버간에는 패킷 통신만하고. 이러면 인게임 서버가 외부에 노출안되서 좋긴하더라.
오 감사합니다. 게임 끝나고 처리는 어떻게 아셨나요? - dc App
질문이 너무 광범위해서 뭐라 답할지를 모르겠네요. 승패나 로그를 기록할려면 어쨋든 DB가 있어야할거구요 범용성이면 MongoDB같은 NoSQL쪽을 찾아보심이
아아 그 게임끝나고 게임서버는 접속을 종료처리하고 api서버에서 db처리를 하다가 다시 게임시작하면 게임서버와 연결하는 방식으로 하셨나요? - dc App
프론트쪽은 HTTP 요청 처리할 서버랑 소켓서버를 따로뒀었어요. 아마 이게 질문자님이 말하는 API 서버 역할을 할것 같구요. DB처리는 따로 백엔드쪽 서버를 하나 더 뒀었어요. 게임 종료후 재접속 절차를 묻는거라면 그건 구현하기 나름일것 같아요.
저라면 게임이 종료되어도 소켓서버쪽 연결은 안끊을것 같아요. 부하테스트하면서 확인해보니 소켓 연결할때마다 생기는 부하량이 생각보다 부담스럽더라구요. 1코어짜리 클라우드 컴퓨터에서 동시접속자 네자릿수 가까이 가면 CPU점유율이 순간적으로 100%씩 찍히는게 좀 아찔해 보여서... 턴제겜이라 통신량이 적어서 그런지 게임 하는동안에는 잠잠한데 한번에 접속이 몰릴때마다 사용률이 요동치는게 보기 싫어서 내린 조치였네요.
그럼 유저는 소켓서버에 연결하고, 게임관련 패킷을 소켓서버에 보내면 그걸 redis에 쌓고 그걸 인게임이 가져다가 처리하는거? redis가 rdbms보단 빠르다고는 하지만, 그러면 실시간이 중요한 상황에서 레이턴시같은건없음?? 뭔가 신박해보여서 궁금함
내가 말하는건 그냥 통신만 중개하는거임. pub,sub 기능으로 레디스에 구독된 서버들끼리 데이터 주고받는게 가능해서 그걸로 통신함. 소켓서버가 8개, 인게임서버가8개 있다고 가정하면 모든 서버들이 일일이 서로 연결하고 관리하는건 힘들잖아. 그래서 서버간의 통신을 중앙관리하는 역할로 Redis를 썻음, 그러면 Redis 자체가 캐싱 역할도 가능하니까, 게임내 핵심 데이터들을 실시간으로 보관해주면 유사시에 패일오버도 가능하고
시험삼아 테스트했을때는 레이턴시에 유의미한 차이 없었음. 정확히는 노이즈가 많아서 측정값이 들쭉날쭉하더라, 오히려 Redis 중개하니까 더 빠를때도 많았고. IaaS쪽 파트너 끼고 직접 테스트하면 달라젔으려나? 어쨋든 인게임서버랑 소켓서버가 분리되 있으니까, 사용자수가 많아질수록 오히려 성능 이점이 많더라고.
내가 쌉고수는 아니라서 내가한게 무조건 정답이다 라는건 아니고 난 이런식으로 만들었음. 성능 확장도 용이하고 장점도 많아서 더 연구해보고 싶긴한데... 저런식으로 해서 성능 이득 보려면 동접자수 다섯자리는 찍어야 되겠더라고 내 인생에 그런게임 만들 기회가 언제 올지 모르겠다.