올해 초(2023년 4월쯤) 자사 게임이 오픈을 했다.
게임에 들어가는 Push Service를 급하게 개발 했었는데 당시 선행 개발 진행하시던 분께서 시간을 다 쓰시고 오픈 한달 남짓 남은 상황에서 개발을 넘겨받은 상황에서 처음부터 개발하게 되었었다.
'어흙'
SDK는 일정이 없고 본인은 Game Service를 잘 모르는 상황해서 이전에 Batch 서버 운영했던 경험을 토대로 모든 Push 구독을 배치로 처리하게 개발을 했었다.
DB는 RDBMS로.. SDK는 아무 처리도 안하고 모든 작업(부담)을 Batch서버에서 처리하게 했었는데 문제는 서비스 초기에 예상보다 많은 트래픽이 몰리면서 Push 구독이 최대 5일까지 지연되는 상황이 발생했었다.
'게임이 이렇게나 잘 될줄이야..'
이후 최적화 작업을 지속적으로 진행했고 또 전체 로직 중 구독 대상을 분류하는 작업을 API에서 처리하도록 이관해서 겨우 안정화가 되었다.
그렇지만 또다른 게임이 Push Service에 런칭을 앞두고 있고 오픈했던 게임도 Global Service를 런칭한다고 한다. 이미 국내에서도 잘된 게임이라 당연 글로벌에서도 잘될것이 예상된다. 그렇다면 아마.. 어마어마한 트래픽을 감당해야 할것..
현재 단일 서비스 운영 시에는 스펙에 문제가 없지만, 게임 수가 계속 증가하고 글로벌 런칭을 준비하는 과정에서 배치 서버의 부담이 늘어날 것이 당연한 상황.
Push Subscribe Service의 개선이 필요했다.
구독 및 구독 해제의 데이터 관리가 RDBMS 로 이루어져있었다.
한번에 처리해야 할 데이터가 많아진다면 누적 속도와 빼야 하는 속도가 맞춰지지 않고
아무리 DB index 가 이용되어서 조회를 한다고 하더라도. RAW 데이터가 많으면 느려질 수 밖에 없는 구조이기 때문에 이를 Kafka로 대체 하기로 결정하였다.
Spring boot의 Scheduler를 사용해서 개발을 했었다.
여기에 대량의 데이터 처리에 대응할수 있게 Spring Batch를 적용하기로 하였다.
Spring Batch는 각각의 Job이 tesklet을 가진 Step으로 돌아간다.
Step을 multi thread로 실행 할 수도 있고 또 각 Step이 동시 다발로 실행된다.
(A step이 할일 다 하고 B step이 처리중이면 기다려줌.)
이런것 뿐 아니라 chunk 등 사용할수 있는 기능들이 많다.
때문에 성능 향상이 목적인 이 프로젝트에서 Spring Batch 도입도 결정되었다.
Team 내부에서 꾸준히 Kotlin에 대한 니즈가 있었다.
내부에서 Study를 진행하곤 했었는데 이것을 이번 개발에 사용해보기로 했다.
사실 PHP만 10년개발 해왔던 나에게 지난 1년 (+2개월?) 간의 JAVA 개발은 재미있지만 큰 허들이기도 했다. 그래도 앞으로 먹고 살려면 Kotlin도 할줄 알아야지.. 라는 마음도 있고 다시한번 도전하기로 결정했다.
현 직장에서는 Azure를 사용한다.
그리고 우리팀은 Mysql을 사용중이나 (우리만 AWS를 사용했었다..) 회사의 정책으로 mssql을 강제 변경하게 되었다. '크으..'
사용해본적은 없지만 또 뭔가 불편해 보이지만 이것도 해야한다.
뭐하나 쉬운게 없을것 같다.
언어부터 Kotlin에 Db는 ms-sql에 Kafka도 처음이고 거기에 Spring Batch까지 사용해야한다.
그런데? 재미있을것 같다.
정말 다행인 것은 이 모든 상황을 이해한 선임이 나에게 시간을 많이 주었다는 것이다.
중간에 다른일들이 많이 오지 않는다는 가정하에..
여하튼 간만에 재미있을것 같고 나 또한 성장 할수 있을것 같아 좋은 기회인것 같다.