좋은 강의 정말 감사합니다. 워커 쓰레드를 싱글 쓰레드로 두고 +로 데디케이트 쓰레드. 즉 보조 쓰레드?를 사용하는 방식이 가장 머리 안아프고 좋은 선택지인거 같습니다.(실제로 다른 서버 강의 ua-cam.com/video/LBo_rKN_e-I/v-deo.html 이곳에서도 이런 방식을 채택했더라구요) 근데 궁금한점은 이 패킷을 핸들링하는 워커 쓰레드가 DB접근시마다 Blocking이 되면 응답성이 떨어질테니.. 결국 DB처리를 위한 별도의 쓰레드를 둔다고 할 때 워커 쓰레드는 Block되지 않고빠르게 처리한다고 하지만 결국 패킷을 보낸 클라에게 응답성은 떨어지는게 아닌가 싶습니다. 1. A유저 아이템 획득 요청 패킷. 2. 패킷 수신 -> 패킷 핸들링 -> 유효 검사 -> DB 처리 요청 3. 다른 패킷 처리 4. DB처리 완료 처리 메시지를 받고 해당 클라에게 응답. 이런식으로 밖에 떠오르지 않는데 이를 좀 더 우아하게 처리하는 방식같은게 있을까요?
제가 좋아하는 프로그래밍 격언 중에 "늑대인간을 한방에 죽일수 있는 은총알은 없다" 라는 말이 있습니다. 이건 어떤 하나의 완벽한 솔루션은 없다는 겁니다. 모든 것은 게임마다 요구사항마다 상황마다 다 달라질수 있습니다. 여러가지 방식이 있을수 있기 때문에 각 상황에 맞는 트레이드오프를 고려하셔야 합니다. 만약 아이템 처리가 독립적으로 존재할 수 있다면, 아이템 처리만을 위한 쓰레드를 둘수도 있고, 만약 아이템 처리가 디터미니스틱하게 결정될 수 있다면 또는 클라에서 어떤 티켓을 발급하고 그 티켓이 Valid한지 여부에 따라서 DB 요청을 확정할 수 있다면 클라에서 직접 DB 업데이트를 때릴수도 있습니다. (이게 너무 위험하다면 다른 방식을 고려해야 겠죠) 만약 액터간 상관관계가 적은 게임이라면 액터별로 워크쓰레드를 따로 둘수도 있습니다. 만약, 게임의 정합성이 응답성보다 더 중요하다면 하나의 워커쓰레드에서 모든것을 처리해도 됩니다. (이때 DB요청이 블럭되는건 말씀하신대로 Async하게 Callback 처리하면 됩니다) 또는 DB처리만을 담당하는 별도 서버를 두고 그쪽으로 넘겨버릴수도 있습니다. 아니면 모든 스테이트를 DB로 넘겨버리고 요청이 올때마다 State를 받아서 다시 업데이트 하는 방법도 있습니다. (Redis같은 메모리DB를 이용할수 있습니다) 또는 반대로 모든 스테이트를 메모리에서 먼저 처리하고 DB업데이트는 나중에 한번에 업데이트 하는 방식도 있습니다. (이경우 서버가 죽으면 마지막 업데이트가 롤백되겠죠) 그외 다양한 방법이 있을수 있기 때문에 각각의 경우에 따라 요청에 따라 트레이드오프를 잘 계산해서 결정하셔야 합니다.
스타크래프는 전형적인 Deterministic 방식입니다. 턴방식을 실시간 형태로 턴을 1초에 10회이상 교환한다고 보시면 될것 같습니다. 즉 각 타임 프레임 마다 키보드 입력과 마우스 입력을 상호 교환해서 동시턴을 진행하는 방식이라고 보시면 됩니다. 저도 자세한 것은 스타크래프트 코드를 본적이 없어서 잘 모르겠네요.
그렇군요! 답변 정말 감사드립니다 :) 한가지만 더 여쭈어 보자면, 구상하고 있는 서버는 메타버스 공간에 많은 유저가 들어와서 커뮤니케이션 할 수 있도록 만들려고 하고 있습니다. 그래서 일정 부분 레이턴시 손해는 감수하지만, 어느정도는 자연스럽게 서로 인터랙션을 할 수 있도록 하는 것이 목표입니다. 제가 grpc는 고려하지 않았는데 액터들의 데이터를 머신 간 브로드 캐스팅해서 동기화를 할 때, redis보다 grpc가 더 효과적일까요??
gRPC와 Redis는 그 용도가 다릅니다. Redis는 in-memory DB로 데이터의 임시 저장소입니다. 그래서 데이터 동기화의 중간 역할을 할 수 있죠. gRPC는 통신에 관한 내용입니다. 프로세스간 통신을 도와주는 역할을 합니다. 그래서 gRPC로 서버간 동기를 하실려면 데이터를 각 프로세스에 보관하고 그것을 동기화하셔야 합니다. 제 생각에 서로 다른 용도를 가지고 있으니 서로 다르게 사용하시는게 맞고, 프로세스간 통신에서는 간편하게 gRPC를 이용할 수 있고, 데이터를 중간에 임시 저장할 경우 Redis를 이용할 수 있고, 데이터가 임시 저장이 아니라 프로세스가 종료되어도 저장되어야 한다면 DB를 이용해야 합니다. 한가지로 해결되는 경우는 잘 없죠.
안녕하세요 turcker님 좋은 강의 잘 들었습니다. 한 가지 여쭙고 싶은게 있어 댓글 달아봅니다. WOW를 예를들어 싱글스레드 멀티스레드를 잘 활용하면 상황에 따라 좋은점이 있다고 하셨는데 그럼 맵과의 로딩이 없는 심리스를 포기하고 싱글스레드 멀티프로세스를 활용하면 WOW처럼 5천명 동접도 가능 한 건가요?
결국은 하나의 프로세스가 몇명의 동접을 받을 수 있는지가 문제겠죠. 예를 들어 하나의 프로세스가 500명의 동접을 받는다고 하면 10개의 프로세스가 필요할 겁니다. 만약 100명의 동접을 하나의 프로세스가 받으면 50개가 필요한거죠. 프로세스 수가 늘어나면 이것들을 어떻게 관리할 건지 관리 문제가 생깁니다. 만약 프로세스가 죽으면 어떻게 되는가? 프로세스가 모자라면 어떻게 할건가? 또는 놀고 있는 프로세스가 있으면 어떻게 할 건가 문제가 생기겠죠. 그래서 관리가 필요하고 구글 Agones 같은게 이런 프로세스 관리를 위해서 만들어진 겁니다. 배틀그라운드 처럼 세션별로 100명의 유저가 들어갈 경우 세션 별로 서버를 만들수 있겠죠. 그러면 이론적으론 5천명이 아니라 5만도, 500만도 가능하죠.
안녕하세요. 전문적인 영상 잘 봤습니다. 영상 내용 중 질문 사항있어 댓글 남깁니다. 싱글 스레드 기반의 서버 프로세스를 지역 별로 구분할 때, A 지역에서 B 지역으로 넘어가는 순간, 서버가 클라이언트에게 B 지역의 서버 프로세스 Port를 알려주고, 클라는 기존 A 서버와의 연결을 끊고 B 서버에 연결을 요청하는 식인가요? 예전에 MMORPG 하다가 지역 이동 시 게임 팅긴 기억이 여러 번 있는데, 이런 이유가 아닌가 유추해봅니다. (이 경우에는 클라가 A 프로세스를 끊고 B 프로세스에 연결 요청을 하는 시점에서 다른 유저들도 B 프로세스에 연결 요청을 하면서, B프로세스의 BacklogQ가 꽉 차거나, 클라가 SYN에 대한 ACK를 받지 못해서 일정 횟수 시도하다가 포기하는 경우가 생각납니다.)
아... 추가로 질문드리고 싶은게 있습니다. 릴레이 서버의 사용 유무에 상관없이 프로세스가 변경되면 결국 연결 끊기 전에 유저의 정보를 DB에 저장하고, 다시 새로운 프로세스에 연결되면 해당 프로세스에서 유저의 정보를 읽어와야 하는데, 만약 여러 유저가 스위칭 되는 지역을 왔다갔다가하는 경우, 서버 처리 속도와는 별개로 DB 처리 속도 자체가 떨어져서 응답성이 떨어질 것 같은데 이러한 경우는 어떻게 처리하는지 궁금합니다.
안녕하세요 요즘 모바일에서 유행하는 자동사냥같은 경우 클라이언트에서 처리하나요 서버에서 처리하나요? 취미로 게임개발을 하는데 자동사냥을 클라이언트에서 구현하고 스킬을 쓸 때마다 플레이어 캐릭터의 스탯을 서버에서 불러오는데 밀림현상이 생겨서 로딩시에 스탯을 미리 클라이언트로 불러와도 되는지 알고싶습니다..
네 성능 향상을 위해서 그렇게 많이 합니다. 그러면 클라 변조를 통해 어뷰징을 할 수 있지만 어느정도 어뷰징은 감수하는 편입니다. 어쨌든 자동사냥을 하는 근본 이유를 보면 보상을 빨리 얻기 위해서 입니다. 그래서 스테이지 클리어 이후 나오는 보상과 걸린 시간만 서버에서 제대로 검증한다면, 중간 스테이지 중 스킬을 연사하더라도 큰 문제는 없습니다.
ua-cam.com/video/TSzUWl4r2rU/v-deo.html 네 요즘들어 이런 시도들이 있죠. SpatialOS 도 그런 종류로 알고 있습니다. 기본 개념은 월드를 분리하고 그 경계에서 데이터를 싱크하면서 경계처리를 하는 것입니다. 근데 말처럼 쉬운일은 아니라서 심리스, 퍼시스턴트 월드를 만들기가 쉽지 않죠
@@TuckerProgramming ua-cam.com/video/s4fE6Y1-2UQ/v-deo.htmlm41s 님께서 말씀하신 내용은 내년에 적용될 기술이고 검은사막이나 다른 mmo에서도 봤던것이라 저도 가능할거라 생각하지만이후에 나올 최종 목표인 동적 서버메싱 이라는 개념이 현실적으로 너무 와닿지 않아서 내가 이 게임에 돈을 써도 될까? 라는 고민 때문에 전현직 개발자들의 생각을 듣고 싶어서 다시 한번만 질문 드립니다. 위 영상은 스시 유저가 개발자들이 연례행사때 최종목표인 동적 서버메싱의 개념을 설명한걸 유저들이 알아듣기 쉽게 한국어로 번역해서 설명하는 영상 입니다. 한번만 봐주시고 현실적인건지 말같지도 않은 헛소린지 평가좀 부탁드립니다.
좋은 강의 정말 감사합니다! 스케일 아웃으로 서버를 구상하고 있는데 궁금한 점이 생겨 질문 하나 여쭙고 싶습니다 :) 프로세스가 분리되어 있으면 액터간 인터랙션이 불가능하다고 하셨는데, A유저는 1번서버에 B유저는 2번서버에 소켓으로 각각 다른 서버에 물려있고 Redis pub/sub로 서버간 데이터를 브로드 캐스팅해서 좌표값이나, 액션들을 공유할 수 있다고 가정하겠습니다. 이때 클라이언트 쪽에서는 같은 공간에 접속해 있다고 하고 물리적으로 A유저가 B유저를 타격했을 때, 타격한 정보를 1번 서버로 보내고 1번 서버에서 모든 클라이언트에게 그 정보를 브로드캐스팅하게된다면 인터랙션되는거 처럼 할 수 있을 것 같은데 그랬을 때 문제점이 있을까요??
네 머신이 분리되었든 프로세스가 분리되었든 어쨋든 데이터가 공유되는 구조가 필요합니다. Redis로 데이터를 공유하는 구조를 만들었다면 얼마든지 가능하죠. gRPC로 서버간 데이터를 공유하든 Redis나 memcache 같은 in-Memory db를 이용하든 아니면 Kafka 같은 pub-sub 서비스를 이용하실수도 있습니다. 문제는 언제나 latency죠. 프로세스 메모리상 없는 데이터면 공유하는데 시간차가 발생합니다. 이런 시간차를 얼마나 극복할 수 있느냐가 문제일거 같습니다. 그것은 어떤 게임을 만드느냐에 따라 다르겠죠.
![[NDC22-프로그래밍] 실시간 MMORPG의 플레이 감각을 날카롭게 벼려보자!](http://i.ytimg.com/vi/HSRo7TAV4T4/mqdefault.jpg)
뜬금 추천으로 떴는데 재밌어서 보는중
진짜 이 시리즈는
업계 밖 사람 입장에서
서버를 이해하는데 도움이 많이 되었습니다.
정말 김사합니다.
이 영상은 돈주고 봐야한다는 생각이 들 정도로 훌륭한 영상이네요 감사합니다.
감사합니다.
이사람은 고수다..
좋은 강의 너무 감사합니다.
좋은 자료 감사합니다 ^^
정말 도움 많이됩니다.ㅠㅠ 감사합니다
감사합니다
좋은 강의 정말 감사합니다.
워커 쓰레드를 싱글 쓰레드로 두고 +로 데디케이트 쓰레드. 즉 보조 쓰레드?를 사용하는 방식이 가장 머리 안아프고 좋은 선택지인거 같습니다.(실제로 다른 서버 강의 ua-cam.com/video/LBo_rKN_e-I/v-deo.html 이곳에서도 이런 방식을 채택했더라구요)
근데 궁금한점은 이 패킷을 핸들링하는 워커 쓰레드가 DB접근시마다 Blocking이 되면 응답성이 떨어질테니.. 결국 DB처리를 위한 별도의 쓰레드를 둔다고 할 때 워커 쓰레드는 Block되지 않고빠르게 처리한다고 하지만 결국 패킷을 보낸 클라에게 응답성은 떨어지는게 아닌가 싶습니다.
1. A유저 아이템 획득 요청 패킷.
2. 패킷 수신 -> 패킷 핸들링 -> 유효 검사 -> DB 처리 요청
3. 다른 패킷 처리
4. DB처리 완료 처리 메시지를 받고 해당 클라에게 응답.
이런식으로 밖에 떠오르지 않는데 이를 좀 더 우아하게 처리하는 방식같은게 있을까요?
제가 좋아하는 프로그래밍 격언 중에 "늑대인간을 한방에 죽일수 있는 은총알은 없다" 라는 말이 있습니다.
이건 어떤 하나의 완벽한 솔루션은 없다는 겁니다. 모든 것은 게임마다 요구사항마다 상황마다 다 달라질수 있습니다.
여러가지 방식이 있을수 있기 때문에 각 상황에 맞는 트레이드오프를 고려하셔야 합니다.
만약 아이템 처리가 독립적으로 존재할 수 있다면, 아이템 처리만을 위한 쓰레드를 둘수도 있고,
만약 아이템 처리가 디터미니스틱하게 결정될 수 있다면 또는 클라에서 어떤 티켓을 발급하고 그 티켓이 Valid한지 여부에 따라서 DB 요청을 확정할 수 있다면
클라에서 직접 DB 업데이트를 때릴수도 있습니다. (이게 너무 위험하다면 다른 방식을 고려해야 겠죠)
만약 액터간 상관관계가 적은 게임이라면 액터별로 워크쓰레드를 따로 둘수도 있습니다.
만약, 게임의 정합성이 응답성보다 더 중요하다면 하나의 워커쓰레드에서 모든것을 처리해도 됩니다. (이때 DB요청이 블럭되는건 말씀하신대로 Async하게 Callback 처리하면 됩니다)
또는 DB처리만을 담당하는 별도 서버를 두고 그쪽으로 넘겨버릴수도 있습니다.
아니면 모든 스테이트를 DB로 넘겨버리고 요청이 올때마다 State를 받아서 다시 업데이트 하는 방법도 있습니다. (Redis같은 메모리DB를 이용할수 있습니다)
또는 반대로 모든 스테이트를 메모리에서 먼저 처리하고 DB업데이트는 나중에 한번에 업데이트 하는 방식도 있습니다. (이경우 서버가 죽으면 마지막 업데이트가 롤백되겠죠)
그외 다양한 방법이 있을수 있기 때문에 각각의 경우에 따라 요청에 따라 트레이드오프를 잘 계산해서 결정하셔야 합니다.
감사합니다!
쉽게 잘 설명해주셔서 이해가 잘돼요. ㅎㅎ
혹시 가능하다면 ㅠㅠ 스타크래프트와 같은 게임은 서버구조를 어떻게 만드는지에 대해서 강좌 부탁드려요 될까요? ㅠ
지금까지 영상은 다 봤고 도움이 많이 됐습니다. 좋은 자료 감사합니다.
스타크래프는 전형적인 Deterministic 방식입니다. 턴방식을 실시간 형태로 턴을 1초에 10회이상 교환한다고 보시면 될것 같습니다. 즉 각 타임 프레임 마다 키보드 입력과 마우스 입력을 상호 교환해서 동시턴을 진행하는 방식이라고 보시면 됩니다. 저도 자세한 것은 스타크래프트 코드를 본적이 없어서 잘 모르겠네요.
답변 감사합니다.
그렇군요! 답변 정말 감사드립니다 :)
한가지만 더 여쭈어 보자면,
구상하고 있는 서버는 메타버스 공간에 많은 유저가 들어와서 커뮤니케이션 할 수 있도록 만들려고 하고 있습니다.
그래서 일정 부분 레이턴시 손해는 감수하지만, 어느정도는 자연스럽게 서로 인터랙션을 할 수 있도록 하는 것이 목표입니다.
제가 grpc는 고려하지 않았는데 액터들의 데이터를 머신 간 브로드 캐스팅해서 동기화를 할 때, redis보다 grpc가 더 효과적일까요??
gRPC와 Redis는 그 용도가 다릅니다.
Redis는 in-memory DB로 데이터의 임시 저장소입니다. 그래서 데이터 동기화의 중간 역할을 할 수 있죠.
gRPC는 통신에 관한 내용입니다. 프로세스간 통신을 도와주는 역할을 합니다. 그래서 gRPC로 서버간 동기를 하실려면 데이터를 각 프로세스에 보관하고 그것을 동기화하셔야 합니다.
제 생각에 서로 다른 용도를 가지고 있으니 서로 다르게 사용하시는게 맞고,
프로세스간 통신에서는 간편하게 gRPC를 이용할 수 있고, 데이터를 중간에 임시 저장할 경우 Redis를 이용할 수 있고, 데이터가 임시 저장이 아니라 프로세스가 종료되어도 저장되어야 한다면 DB를 이용해야 합니다.
한가지로 해결되는 경우는 잘 없죠.
@@TuckerProgramming 좋은 답변 정말 갑사합니다!
안녕하세요 turcker님 좋은 강의 잘 들었습니다.
한 가지 여쭙고 싶은게 있어 댓글 달아봅니다.
WOW를 예를들어 싱글스레드 멀티스레드를 잘 활용하면 상황에 따라 좋은점이 있다고 하셨는데
그럼 맵과의 로딩이 없는 심리스를 포기하고 싱글스레드 멀티프로세스를 활용하면 WOW처럼 5천명 동접도 가능 한 건가요?
결국은 하나의 프로세스가 몇명의 동접을 받을 수 있는지가 문제겠죠. 예를 들어 하나의 프로세스가 500명의 동접을 받는다고 하면 10개의 프로세스가 필요할 겁니다.
만약 100명의 동접을 하나의 프로세스가 받으면 50개가 필요한거죠. 프로세스 수가 늘어나면 이것들을 어떻게 관리할 건지 관리 문제가 생깁니다.
만약 프로세스가 죽으면 어떻게 되는가? 프로세스가 모자라면 어떻게 할건가? 또는 놀고 있는 프로세스가 있으면 어떻게 할 건가 문제가 생기겠죠.
그래서 관리가 필요하고 구글 Agones 같은게 이런 프로세스 관리를 위해서 만들어진 겁니다.
배틀그라운드 처럼 세션별로 100명의 유저가 들어갈 경우 세션 별로 서버를 만들수 있겠죠. 그러면 이론적으론 5천명이 아니라 5만도, 500만도 가능하죠.
@@TuckerProgramming 빠른 답변 감사드립니다!
안녕하세요. 전문적인 영상 잘 봤습니다. 영상 내용 중 질문 사항있어 댓글 남깁니다.
싱글 스레드 기반의 서버 프로세스를 지역 별로 구분할 때, A 지역에서 B 지역으로 넘어가는 순간, 서버가 클라이언트에게 B 지역의 서버 프로세스 Port를 알려주고, 클라는 기존 A 서버와의 연결을 끊고 B 서버에 연결을 요청하는 식인가요? 예전에 MMORPG 하다가 지역 이동 시 게임 팅긴 기억이 여러 번 있는데, 이런 이유가 아닌가 유추해봅니다. (이 경우에는 클라가 A 프로세스를 끊고 B 프로세스에 연결 요청을 하는 시점에서 다른 유저들도 B 프로세스에 연결 요청을 하면서, B프로세스의 BacklogQ가 꽉 차거나, 클라가 SYN에 대한 ACK를 받지 못해서 일정 횟수 시도하다가 포기하는 경우가 생각납니다.)
네 그렇게 하기도 합니다. 아니면 앞단에 릴레이 서버를 두고, 클라이언트는 커넥션을 변경하지 않고, 릴레이 서버에서 릴레이 되는 서버 위치를 바꾸기도 합니다. 하지만 이럴 경우 적절하게 서버를 변경해주는 릴레이 서버를 제작해야 하는 복잡도가 늘어납니다.
@@TuckerProgramming 답변 감사합니다. 그럼 클라가 선택하는 서버가 곧 릴레이 서버가 되겠네요.
서버는 개발 방법이 정말 다양해서 재밌는 것 같습니다.
아... 추가로 질문드리고 싶은게 있습니다.
릴레이 서버의 사용 유무에 상관없이 프로세스가 변경되면 결국 연결 끊기 전에 유저의 정보를 DB에 저장하고, 다시 새로운 프로세스에 연결되면 해당 프로세스에서 유저의 정보를 읽어와야 하는데, 만약 여러 유저가 스위칭 되는 지역을 왔다갔다가하는 경우, 서버 처리 속도와는 별개로 DB 처리 속도 자체가 떨어져서 응답성이 떨어질 것 같은데 이러한 경우는 어떻게 처리하는지 궁금합니다.
제가 하는 게임 중에 알비온이라는 게임은 지역 이동시 이전 지역으로 바로 넘어가려면 일정 시간을 대기(5초 였던걸로 기억합니다)하는데 제가 질문 드린 상황을 방지하기 위함일까요?
@@cov-qi9cv 네 맞습니다. DB가 병목이라면 Redis 같은 memory cache 를 이용해서 유저 정보를 캐쉬해서 전달하는 방법을 사용하기도 합니다.
안녕하세요 요즘 모바일에서 유행하는 자동사냥같은 경우 클라이언트에서 처리하나요 서버에서 처리하나요? 취미로 게임개발을 하는데 자동사냥을 클라이언트에서 구현하고 스킬을 쓸 때마다 플레이어 캐릭터의 스탯을 서버에서 불러오는데 밀림현상이 생겨서 로딩시에 스탯을 미리 클라이언트로 불러와도 되는지 알고싶습니다..
네 성능 향상을 위해서 그렇게 많이 합니다. 그러면 클라 변조를 통해 어뷰징을 할 수 있지만 어느정도 어뷰징은 감수하는 편입니다. 어쨌든 자동사냥을 하는 근본 이유를 보면 보상을 빨리 얻기 위해서 입니다. 그래서 스테이지 클리어 이후 나오는 보상과 걸린 시간만 서버에서 제대로 검증한다면, 중간 스테이지 중 스킬을 연사하더라도 큰 문제는 없습니다.
진짜 궁금한점 스타시티즌이라는 게임에서 서버메싱이라는 개념의 싱글샤드 서버를 목표로 개발중인데 이게 현실적인건지 한번 다뤄주실수 없나요?
다뤄주신다면 관련 링크 찾아서 오겠습니다.
ua-cam.com/video/TSzUWl4r2rU/v-deo.html
ua-cam.com/video/TSzUWl4r2rU/v-deo.html
네 요즘들어 이런 시도들이 있죠. SpatialOS 도 그런 종류로 알고 있습니다.
기본 개념은 월드를 분리하고 그 경계에서 데이터를 싱크하면서 경계처리를 하는 것입니다.
근데 말처럼 쉬운일은 아니라서 심리스, 퍼시스턴트 월드를 만들기가 쉽지 않죠
@@TuckerProgramming
ua-cam.com/video/s4fE6Y1-2UQ/v-deo.htmlm41s
님께서 말씀하신 내용은 내년에 적용될 기술이고 검은사막이나 다른 mmo에서도 봤던것이라 저도 가능할거라 생각하지만이후에 나올 최종 목표인
동적 서버메싱 이라는 개념이 현실적으로 너무 와닿지 않아서 내가 이 게임에 돈을 써도 될까? 라는 고민 때문에 전현직 개발자들의 생각을 듣고 싶어서 다시 한번만 질문 드립니다.
위 영상은 스시 유저가 개발자들이 연례행사때 최종목표인 동적 서버메싱의 개념을 설명한걸 유저들이 알아듣기 쉽게
한국어로 번역해서 설명하는 영상 입니다.
한번만 봐주시고 현실적인건지 말같지도 않은 헛소린지 평가좀 부탁드립니다.
@@별스타-d8q 네 보내주신 유튜브 잘봤습니다. 결국 동적메싱이라는건 서버가 담당하는 공간을 부하에 따라 동적으로 줄이거나 늘리거나 하는걸 말하네요. 네 충분히 가능합니다. 물론 까다로운 처리가 필요하지만 불가능한 것은 아니라고 보여지네요.
@@TuckerProgramming 답변 감사합니다. 덕분에 궁금증이 해소됐습니다.
구독박고 가겠습니다!!
좋은 강의 정말 감사합니다!
스케일 아웃으로 서버를 구상하고 있는데 궁금한 점이 생겨 질문 하나 여쭙고 싶습니다 :)
프로세스가 분리되어 있으면 액터간 인터랙션이 불가능하다고 하셨는데,
A유저는 1번서버에 B유저는 2번서버에 소켓으로 각각 다른 서버에 물려있고
Redis pub/sub로 서버간 데이터를 브로드 캐스팅해서 좌표값이나, 액션들을 공유할 수 있다고 가정하겠습니다.
이때 클라이언트 쪽에서는 같은 공간에 접속해 있다고 하고
물리적으로 A유저가 B유저를 타격했을 때, 타격한 정보를 1번 서버로 보내고 1번 서버에서
모든 클라이언트에게 그 정보를 브로드캐스팅하게된다면
인터랙션되는거 처럼 할 수 있을 것 같은데 그랬을 때 문제점이 있을까요??
네 머신이 분리되었든 프로세스가 분리되었든 어쨋든 데이터가 공유되는 구조가 필요합니다.
Redis로 데이터를 공유하는 구조를 만들었다면 얼마든지 가능하죠. gRPC로 서버간 데이터를 공유하든 Redis나 memcache 같은 in-Memory db를 이용하든 아니면 Kafka 같은 pub-sub 서비스를 이용하실수도 있습니다.
문제는 언제나 latency죠. 프로세스 메모리상 없는 데이터면 공유하는데 시간차가 발생합니다. 이런 시간차를 얼마나 극복할 수 있느냐가 문제일거 같습니다.
그것은 어떤 게임을 만드느냐에 따라 다르겠죠.
서버주소획득실패는 무슨뜻이죠?
감사합니다.