v1 런칭을 위한 디비구조 변경 및 멀티모듈 적용

v1 런칭을 위해 필요한것들

v1에 새로운 기능들이 추가되었다.

1. 캐릭터 정보

2. 랭킹

3. 큐브 사용 모든 raw 데이터들

 

캐릭터 정보 기능

캐릭터 정보 기능은 현재 메이플스토리에서 제공하는 api가 없다

그래서 우리는 크롤링을 하여 가져오기로 결정 하였고

 

메이플 사이트를 매번 크롤링 하면 블락을 먹게 될테니 아래 구조로 시스템을 만들기로 했다.

 

1. 초기 데이터 저장시 캐릭터 따로 저장

2. 캐릭터 명을 aws sqs에서 전송

3. aws lambda가 "제한된" 개수 만큼 sqs에서 꺼내가서 크롤링

4. aws lambda가 api 서버에 전송

5. 저장

 

이렇게 한다면 lambda가 일정 주기 및 동시 실행 제어로 메이플 스토리 크롤링을 매번 안하게 되고

사이트에서 블락을 당하지 않을거라는 판단이었다.

 

 

사용 이력 데이터 저장 고민

결국 초기 데이터를 저장하기로 했다.

현재 기준 초기데이터는 약 1억1천만건이다.

유저수는 6100명이다.

 

확인해보니 6천명 기준 매일 큐브데이터가 약 30~40만씩 증가한다.

 

v1을 런칭 을 한다면 데이터 수도 많아질거라고 예상했다

 

데이터 베이스 테스트 진행

이부분은 테스트한내용을 순서대로 작성해본다.

1. 도커로 로컬에 mysql 생성

2. mysql에 2코어 4기가로 제한 (rds와 동일하게)

3. 7700만건의 데이터 insert

4. 인덱스는 4개

5. 7700만건 기준으로 30만건 (평균 하루 데이터) bulk insert시 약 3분 소요

6. 200만건 (가장 많은날의 데이터) 약 18분

7. 평균 유저의 사용량 1만건 약 3~5초

8. 테이블 데이터 사이즈 10기가

9. 인덱스 사이즈 9기가

10 합 20기가

11. 혹시 실수로 where 및 group by 인덱스가 없는컬럼 등으로 쿼리 질의 당연히 오래걸리고 안나옴

12 인덱스 있는 데이터를 조건으로 조회 시 약 1~1.5초

13 한번 조회후에는 바로 조회됨 -> 캐시여서 이건 내가 똑같은 요청을 나만 하기 떄문에 의미가 없어보임

 

결론

계속해서 데이터가 늘어날거 같고 

최소 3억건 까지는 늘어날거같아 "샤딩"을 진행하기로함

 

이유

1. 데이터는 계속 늘어날것

2. 조회하는 데이터도 늘어날거고

3. 매일 수십만건 및 새로운 유저의 수만건 십만건등을 insert 해야 하는데 하나의 테이블에서 이걸 모두 저장하고 정렬하기엔
자원이 너무 부족하여 정렬해야하는 데이터양을 줄이고 조회속도와 저장속도를 얻어보려고 한다.

 

결과물

1. 모듈러 샤딩

2. 논리디비 30개 물리 2개

3. JPA로 샤딩 진행

 

JPA로 샤딩한 내용과 코드는 따로 글을 작성해보려고 한다.

 

멀티 모듈 적용

스프링 배치를 적용하기로 해서 공통 코드가 많아질거 같아

멀티 모듈을 적용하고 아래와 같이 구성하려고 한다

 

api, batch, domain persistence, util

 



멀티 모듈 설정법도 따로 블로그에 작성해야겠다

build.gradle.kts로 구성하였다.