적진 않았지만 구현한 내용 : Redis로 구현한 스핀락 >> Redisson을 이용한 분산 락그냥 길게 적을 내용 아닌거 같아서 뻈다. 나중에 배포하면서 노드 수가 늘어나면 다시 포스팅 주제로 할애하겠음  nlohmann/json 라이브러리 도입을 통해 JSON 타입 처리 개선 GitHub - nlohmann/json: JSON for Modern C++JSON for Modern C++. Contribute to nlohmann/json development by creating an account on GitHub.github.com 난 그동안 뭘했던걸까... 그냥 라이브러리 쓰면 편한데...  Kafka 메시지 유실에 대비한 후처리로 사용자 경험 개선사실 난관은 '메시지의 유실을 어떻게 인지하는가..

매칭 시스템은  가장 성능이 중요한 비즈니스인 만큼 검증은 필수적이다.  매칭 비즈니스 흐름도기본 골자는 다음과 같다.registerMatchQueue : 회원 서비스에게 요청을 보내서 현재 게임중인 사용자인지 검증하고, 매칭 큐에 등록한다.getRank : 현재 매칭중인지 확인하는 APIcalcelMatchQueue : 매칭 큐에 등록된 사용자인지 확인하고 취소한다.  매칭 큐에 등록될때 ZSet 자료구조를 통해 사용자의 Elo 점수를 score로 정렬해서 비슷한 실력대의 사용자들끼리 매칭시켜준다. 마이크로 서비스로 분해하면서 회원 정보의 Nickname에 접근하기 까다로워졌기에, 맨 처음 매칭 큐에 등록할때 사용자 정보를 받아서 HSet 타입으로 캐싱해둬서 가져오도록 했다.    매칭하는데 결과가 줄..

비정상적인 좌표 이동에 대한 검증(Validation)아직 패킷 암호화 등의 처리를 하지 않았다. 어차피 막아도 뚫린다는 생각이 있어서 먼저 로직상의 검증부터 구현했다. 객체의 좌표 이동시 이전 위치와 speed를 고려해서 검사하고, 통과해야 움직여준다.로직상 비용이 드는 연산이 아니라 부담은 없다. 그러나 시작할때 생성되는 병종들과 충돌해서 사용자가 밀려나는데, 서버에서는 위치 검증에 실패해서 비정상적인 이동으로 판단함.물론 안 겹치게 병종들을 떨어트려서 생성하면 당장은 그럴듯하겠지만 근본적인 문제를 해결하진 못한다. 충돌(Collision) 등의 물리 연산도 서버에서 진행해야하는건지 의구심이 들기 시작함..   Csharp ↔ Cpp 마샬링 문제std::string과 C#의 string 간에 충돌로 ..

들어가기에 앞서리그오브레전드의 전적 검색이나 통계 시스템을 생각해보자. ​각 사용자의 전적에서는 사용한 챔피언별로 판수나 승률이 함께 조회된다. 심지어 각 챔피언별 판수나 승률, 아이템과 어떤 스펠을 사용했을때 가장 승률이 높은지도 알 수 있다.op.gg ​보이는거만 해도 각 챔피언당 몇 백만 판수씩 나오는데, 고작 플레이 수나, 승패에 따른 승률을 연산하기 위해 일일이 DB에서 꺼내와 더할건가?​예시가 너무 게임이라 다시 들자면 토스에서 제공하는 서비스중에서 서초구에 위치한 20대들의 평균 잔고가 얼마인지 제공하는게 있다.   모든 사용자들 중에서 서초구, 20대인 사람들을 쿼리문으로 조회해서 평균 잔고를 모두 더했겠는가? 그 사용자들이 100만 명이어도 평균을 계산하기 위해 모든 잔고를 더할건가? ...

당근마켓도 100만 MAU 뜨고 나서야 MSA를 도입했다는거 보면, 사실 그정도 규모 이하는 모놀리식으로 충분하다는 소리다.​도대체 왜 이렇게 MSA에 목메이게 되었는가..​이길 수 없다면 합류해라​나도 MSA하겠다​​이거말고 진짜 MSA를 결심한 이유원래 C++로 이뤄진 게임 서버와 통신하기 위해 Kafka를 사용했었다.   매칭 결과나 전적 결과를 저장하기 위해서라도 전달 과정에서 최소 한번은 디스크에 기록되어야 했다.​1. 매치메이킹의 결과를 받아서 게임 서버에 방을 생성2. 게임이 끝나면 그 결과를 다시 웹서버로 전달 대충 목적인데 닭 잡는데 소 칼 쓰는 느낌이다. 그래서 kafka를 좀 더 효율적으로 쓰기 위해서 고도화를 고민해봤다. ​일단 Redis를 이용하던 매치메이킹 기능이 스케줄러로 동작..