1. 비동기 통신은 어디서 필요할까?
•
User
•
Content
•
Group
•
Game
•
Notification
Kafka를 쓰려면?→ 실시간 이벤트, 대용량 데이터, 이벤트 소싱
한 서비스에서 이벤트가 발생하면, 이를 구독하는 다른 서비스에서도 실시간으로 데이터 변경을 수행해야함. 예를 들어, 주문 서비스가 주문 완료 이벤트를 발행하면, 재고 서비스와 결제 서비스가 이 이벤트를 구독하여 필요한 작업을 수행하는 것처럼..
→ 대안 : RabbitMQ와 같은 메시지 큐 활용. kafka에 비해 지연 시간이 짧음.
간단한 통신에 적합함. but 메시지 순서, 처리 상태를 관리해야 함.
내 서비스에 Kafka를 적용시켜야 할 이유를 찾아보자..
1.
실시간성이 필요한 경우
2.
하나의 서비스에 대해 연결된 서비스가 많을 경우
•
게임 종료시 유저 점수 업데이트
•
유저 탈퇴시 group 정보 업데이트
•
로그인 시, SSE 수행
2. NoSQL?
→ 비정형 데이터를 쉽게 처리하기 위해. 읽기 성능이 매우 좋음. 데이터 변경이 적고, 읽기 작업을 자주 수행하는 경우.
만약 무결성, 정합성이 조금이라도 필요하다면 RDB를 쓰는것이 맞음.
1.
일단 게임쪽 데이터 처리는 모두 redis로 할 생각. 다 일회성이니까. 하나 영구적으로 저장할만한게 전적데이터를 활용할 경우. 데이터 변경이 없고, 기능이라 해도 전적 조회만 할 것이기에 NoSQL이 적합. → Game Service에서는 NoSQL를 사용하는게 좋아보임.
2.
유저, 그룹, 컨텐츠의 경우에는 RDB를 활용해야함.
3. 코드 아키텍처
•
헥사고날
•
레이어드
→ 헥사고날은 도메인 영역의 의존성에 대한 분리가 장점.
근데 MSA라 서비스 다 다른데, 하나의 서비스 내에서 의존성이 존재해봐야 그렇게 클 것 같진 않음.
만약 모노레포로 멀티모듈아키텍처를 써서 모든 서비스를 하나의 프로젝트 상에서 빌드한다면 코드가 복잡해지고 의존성 관리를 해야하니까 헥사고날이 맞겠지만, 이미 MSA로 외부 아키텍처면에서 서비스 독립성이라는 장점을 가졌기 때문에, 내부적으로는 직관적이고 쉽게 개발할 수 있는 레이어드 아키텍처가 훨씬 유용하다고 생각.
4. CI/CD
CI
•
Jenkins
•
Github Actions
→ Jenkins : 따로 젠킨스 서버 파고 설정해줘야함. 대신 빠름
→ Github Actions : 사용법이 간단, 자체 서버 제공, UI가 예쁨
CD
•
ArgoCD → K8s manifest 파일의 변경점을 자동으로 감지하여 배포 수행
→ K8s manifest 파일의 변경점을 자동으로 감지하여 배포 수행
5. Kubernetes
실시간성이 중요한 게임서비스인 만큼 장애복구에 대한 부분을 민감하게 대응해야 함.
이번에 발표하면서 서버터졌을 때 바로 대응하기 힘들었던 것 처럼.. 단일 인스턴스 내에서 전체 마이크로서비스를 운영하게 되면, 스케일 관리, 리소스 할당 등 서비스 운영 측면에서 어느 정도의 자동화가 필요함. 서비스가 많아지고 커질수록 이 부분에 대한 필요성도 커짐. 때문에 인스턴스 내부 쿠버네티스 클러스터 안에 서비스를 올려서 애플리케이션과 필요한 자원을 관리하는 것이 효율적이라고 생각함.
6. 기능 추가
•
대기방, 게임 로직을 통합
•
그룹 기능, 그룹 게임 기능 활성화
•
랭크 게임 기능 활성화
정도..? 그래도 어느 정도 기능적인 규모가 있어야 지금 쓰려는 기술 의사결정에 대한 합리성을 찾을 수 있을 것 같아서..