DB에 쿼리 날리지 마라

 

입사한지 이제 정확히 50일 되었다.

 

처음으로 새로운 feature를 담당하여 맡게 되었고, 컨플루언스에 로드맵을 정리하여 올렸다.

아침 스크럼 이후, 슬랙에 피드백을 위해 로드맵을 올렸는데 CTO님이 내 글을 보시고 바로 댓글을 다셨다.

 

"이거 일을 좀 더 크게 벌리는게 좋을거 같네요"

 

이유는 group by와 order by 쿼리를 DB로 바로 날리는 식으로 짰는데, 이렇게 하면 DB 서버의 부담이 크기 때문이었다. 물론 데이터가 작다면 상관없겠지만...

 

 

그럼 도대체 어떻게 해결해야하는가?

 

 

그래서 내가 'Redis에 일별로 데이터를 저장하고 데이터 정리는 백엔드에서 하는게 어떨까요?'라고 제안했다.

그랬더니 그게 엘라스틱 서치에서의 aggeregation 방식이라고 하셨다(뭔지 몰랐다). 그것도 좋긴한데 메인 백엔드 api서버를 최대한 깔끔하게 비우는게 목표라고 다른 시니어분이 말씀해주셨고, 다른 DE분과 논의한 결과 아래와 같이 구조를 짜기로 했다. 회사에서 되도 않는 영어 쓰느라 힘듦.

 

이러저러한 사정이 있지만, 단순히 말하자면 기능 추가에 불과했던 것을 MSA로 빼기로 결정했다.

람다에서 데이터를 조인만 해서 가져오고 이걸 Redshift에 넣는다. 근데 S3에 데이터를 굳이 한 번 더 거치는 이유는, 데이터가 많을 경우 insert할 때 시간이 오래 걸리면 람다 타임 아웃에 걸릴 수 있기 때문에 S3에 데이터를 넣는 것이 첫 번째 이유고, 두 번째는 S3에서 spark API와 글루잡을 써서 레드시프트로 넣는게 속도가 빠르기 때문이다.

프론트에서 Request가 오면, Key값이 Redis에 있다면 Value를 넘겨주고, 없다면 계산된 Value를 Front로 넘겨주고 Redis에 저장한다.

현재 계획은 일일 데이터를 레드시프트에 넣어서 백엔드에서 단순 sum+sort해서 취합하는 방식으로 계획하고 있지만, 만약 이것조차 싫다면 람다에서 원하는 기간 별로 데이터를 정리해서 레드시프트에 넣으면 백엔드 서버는 완전하게 데이터 정리 로직으로부터 해방될 수 있을 것이다.

 

 

어쨌든 회사에서 현재까지의 오직 빠른 서비스 제공만을 위한 개발만을 추구했다면, 이제 MSA로 나아가면서 기존 레거시들을 정리하려고 있는 초기 단계기 때문에 나 같은 신입도 재밌는 걸 해볼 수 있는 기회가 있음에 감사한다.

 

 

 

------------------------------

12.21 아래와 같이 바뀌었다(람다 뺌)

확인해보니 AWS RDS에서 이미 S3으로 스냅샷이 떠지고 있어서 람다가 필요 없어졌다.