V1 런칭

 

(런칭은 11월 30일에 하였지만 글을 1월에 작성..)

 

V1 런칭

 

V1을 만들어서 런칭했다.

 

예상작업보다 7일 정도 딜레이 되었지만 결국 해냈다는 거에 의의를 두고 있다.

 

 

 

 

 

 

모든 큐브데이터를 저장하였고

현재는 통계를 보여주고 있다.

 

 

샤딩은 디비 서버를 여러대로 분리하는 건데

지금 우리는 디비 서버를 여러 대 두기에는 비용적 측면에서는 부족하여

논리 디비 샤딩을 채택하였다.

mysql 내에서 스키마를 여러 개 만들어 데이터를 분산해서 처리하고 있다.

 

현재 기준으로 1억 4천만 건이 저장되고 있고 데이터를 가공하고 통계데이터를 만들고 보여주고 있다.

 

---

 

회고

 

저장은 jdbctemplate 조회는 jpa를 사용하여 데이터를 서빙중에 있는데

샤딩을 직접 로직을 생각해서 만들어본게 처음이라 내가 예상한것보다 개발 기간이 오래걸렸다.

데이터를 나눠 저장하다보니 정합성에 대해서 생각하는것도 너무 많고

고려해야할게 너무 많았다.

 

저장을 할 때 jdbctemplate를 이용하여 샤딩된 데이터베이스를 찾아주는 거는 어렵지 않았다.

쿼리문을 만들 때 유저의 id 기반으로 데이터를 찾아주고 쿼리문을을 만들어주면 되었다.

 

문제는 jpa 에서 쿼리문을 어떻게 동적으로 샤딩된 디비를 찾아가게 해 줄지가 고민이었다.

그렇다고 모든 스키마별로 커넥션을 맺기에는 너무 비효율적인 거 같았다.

그래서 동적으로 Jpa의 쿼리문을 변경해 줄 거를 찾고 있었고, 나는 hibernate의 StatmentInspector 를 이용하기로 했다.

(이게 올바른 해결법인지는 모르겠다.)

 

해당 클래스를 이용하여 쿼리문을 검사하고 다른 쿼리로 대체할 수 있다.

 

 

jpa동적 쿼리에 대한건 해결을 했는데 이제 다른 문제가 또 생겨버렸다.

 

아직은 문제가 없는데 하루하루가 지나갈수록 문제가 분명 생길 것이다.

현재 플로우는 신규 유저가 가입하면 2022년 11월 25일 ~ 오늘날짜 -1 일까지의 데이터를 전부 가져와서

저장해주고 있다. 최소 1년 치 이상의 데이터를 가져온다

약 1년 치의 데이터를 외부에서 가져와서 저장해주다 보니 트랜잭션 범위에 대한 지정 및 트랜잭션을 날짜 단위로 쪼개서 저장한다는지

고민할 게 진짜 많았다.

 

여기서 문제는 크게 3가지다

1. 외부 데이터 통신에 트랜잭션 걸지 않기

2. 날짜가 지나갈수록 1년 이상의 데이터를 한 번에 가져옴으로써 out of memory heap 이 뜰 것이다.

3. 범위를 쪼개면 발생할 retry 처리방식 

 

1번에 대해서는 레이어를 분리하였고

2번은 아직은 괜찮지만 해결해야 할 이슈다.

일단은 한 달 또는 일단위로 끊어서 처리를 하고 성공 실패 여부를 디비에 기록하여 retry도 진행해 주는 방식으로 진행할 예정이다. 

 

이것 말고도 많은 이슈가 있었지만 기록하는 게 어렵다.

앞으로는 기록을 해두고 블로그에도 작성해 두어야겠다.

(본인이 까먹어서 추후 이슈를 다시 찾아보고 싶기에)