1부
피셔 예이츠 셔플을 굳이 구현하지 않아도 된다 - lodash에 셔플이 있다
2부
ECR-ECS에 대해 알아볼 것 - 현업에서 대부분 이렇게 씀
ALB라고 아마존 로드밸런서 있음
turborepo나 library를 사용해서 여러 프로젝트를 한개의 리포지토리로 관리할 수 있다.
터보레포가 뭔가요? 참고 블로그
최종발표 피드백
가볍게 쓸거면 괜찮은데 트래픽 폭증 시 하프록시를 어떻게 클러스터링 할지 생각해야 한다.
하프록시가 단일실패지점 일 수 있다.
유저가 갑자기 10만명 몰린다고 하면 스케일링은 어떻게 할 것인가?
데이터는 비동기적으로 처리하는 것이 좋다. RDS고 레디스고 하프록시고 여기저기서 비명을 지를 것.
부하 테스트로 단순히 이렇게 저렇게 최적화를 했다고 하는 경우가 정말 흔하고 많은데, 스트레스 테스트 결과를 토대로 서버 사용과 요금전략을 세웠다는 점이 정말 인상깊었다.
슬라이딩 윈도우 알고리즘 - 연속된 중복 요청을 무시할 수 있는 알고리즘이 있다.
그래프에서 일정한 패턴이 보인다 - GC가 작동해서 그렇지 않나 하는 것으로 보인다. 그렇지만 원인을 찾아보는 것이 좋다. GC타이밍을 최대한 적게 오게 만드는 것이 좋다.
외부 심사평
채희원 심사위원님
낮밤 페이즈의 차이에 대해서 물어보심.
이 외 질문없이 게임 플레이 해보심.
하승우 심사위원님
-
로비서버가 굳이 소켓일 필요가 있나? API 서버여도 되지 않나?
-> 로비도 소켓으로 하는 게임도 많아서 상관은 없다. 다만 로비서버가 API서버인 경우 로비쪽에서는 절대 끊기지 않기 때문에 사업적 측면에서 좋다. -
모놀리식에서 분리를 했는데 어떻게 분리를 했나?
-> -
클라이언트와의 통신은 JSON으로 하나?
-
로비서버 패킷과 게임서버 패킷과 같은 프로토파일로 관리하나? 둘이 서버는 나뉘었지만 같은 프로토를 쓰나? 아니면 다른 프로토를 쓰나?
-> 프로토버프는 분리 안하는게 낫다. 클라이언트 사이드에서 하나로 쓰는게 더 낫다. -
제이미터 쓴 것 같은데 부하 테스트에 대해 알려줬으면 한다.
-
이동 동기화에 대해 설명해달라.
-
60프레임 정도면 너무 빡빡하지 않나? MMO도 보통 30프레임을 쓴다.
-
전에도 면접때 알려주신 방법 - 이동동기화 패킷이 버거우면 클라에서 방향만 주면 된다. int32를 8비트씩 쪼개서 상하좌우로 넣고, 서버는 방향벡터만 받아서 그 방향으로 가게 하면 된다.
-> 단점은 유저가 의도적으로 해드뱅잉을 하면 좀 애매해진다. 그러나 이것도 짧은 시간동안 너무 많은 패킷이 들어오면 무시한다던지 하는 방법으로 해결해볼 수 있다.
김대웅 심사위원님
-
5명짜리 방에 빈자리가 한개 남았는데 두명이 해당 방에 동시에 진입시도를 하는 경우 어떻게 되나?
[팀 답변: 현재로는 방에 6명 들어가게 될것]
-> 이건 불큐같은 걸 써도 되고 어몽어스처럼 방 진입 실패시키고 방 목록 한번 갱신해줘도 된다. -
사정거리 개념이 있고 서버가 좌표를 가지고 있으니까, 내가 쏜 애의 좌표와 타겟한 애의 좌표가 다르면 클라가 해킹되어도 서버에서 막을 수 있을 것이다.
-> -
개발할 때는 클라가 해킹당할 일이 없지만, 라이브에 나가면 클라에서 들어오는 클라 패킷은 무조건 해킹당한게 온다라고 가정하고 방어로직을 짜야한다. 라이브 나가면 클라는 무조건 해킹당한다.
-
유저 인풋에 관한 핵은 답이 없다. 데이터가 쌓이면 의심할 수는 있겠지만 그걸로 밴을 할 근거는 없다.
이것만은 꼭 공부해봐라 - 멀티쓰레드
쓰레드를 직접 만들어보고 메시지도 전해보고 해봐야 한다. 모든 작업은 쓰레드 단위로 돌아간다.
서버 개발자가 만드는건 서버 소프트웨어 프로세스다. 그게 어떻게 돌아가고 있는지를 잘 이해하는게 중요하다고 생각.
C++이나 C# 같은거 만들면 메인메서드가 덩그러니 하나 있는데, 그 메인함수가 메인 쓰레드다.
많고 많은 것 중에 왜 EC2를 골랐는가?
이 질문에 대한 답변을 고민해보는 것이 좋다.
기주 튜터님
빛기주 강림!
임영웅 콘서트 티켓을 예매한다고 하자. 그러면 인터파크는 이미 서버를 몇백대를 미리 증설해 놓는다. 그리고 예매가 끝나면 인스턴스를 다시 반납할 것이다. 그런 식으로 아래에 대해 생각해보아야 한다.
- 일시적으로 트래픽이 폭발적으로 증가할 때에 대한 대비가 되어있는가?
- 안 되어 있다면 앞으로 어떻게 대비할 것인가?
당장은 그렇게 트래픽 부하가 몰릴 만큼의 서비스를 런칭할 일이 없겠지만, 내가 현업에서 어떤 서비스에 투입될 지는 모르는 일이기 때문.
