MSA: Micro Service Architecture 적용기(2)

간단한 AI과 합쳐진 블로그 서비스에서 MSA 구조를 도입하면서 서비스를 어떤식으로 나누고 아키텍쳐를 설명했는지

 

서비스 ERD

GLUE ERD

해당 서비스를 기능적인 구조로 살펴보면 총 4가지로 나눌수 있다.

 

1. 멤버 관리: 우리의 서비를 사용하는 유저들을 관리하는 기능. JWT 토큰 인증, 카카오 소셜 로그인등이 사용된다. 

 

2. 본인 블로그 홈 관리: 인스타 프로필 처럼 본인 블로그 홈을 꾸밀 수 있는 기능이다.

 

3. 게시글 작성 관리: 가장 대표적인 게시글 작성 기능으로 작성하면서 스티커를 생성하고 본인이 원하는 위치 어느 곳에나 붙일 수 있다.

 

4. 스티커 생성 관리: Dalle-2 생성형 AI를 사용하여 사용자 프롬프트를 통해 원하는 스티커를 생성할 수 있는 기능이다.

 

5. 추천 시스템: Elastic search vector DB를 사용하여 사용자, 블로그 사이의 코사인 유사도를 통해 추천해주는 기능이다.

 

여기서 이제 가장 서버 사용량이 많은 서비스는 (4)번과 (5)번이다. 

특히 (4)번의 생성형 AI를 사용하여 스티커를 생성하는 기능은, 하나의 스티커를 생성하고 가져오는데 총 8초의 시간이 걸리게 된다. 특히 특정 프롬프트에 따라 오류가 발생하는 경우도 잦았다. 

 

때문에 우리는 Micro Service를 위의 기능에 따라 총 5개로 나누기로 하였다. 

 

이렇게 되면 다음과 같은 장점이 있었다. 

 

첫번째로, 요청이 분산되기에 서버에 과부하가 걸릴 확률이 낮아졌다.

 

두번째로, 추천시스템 서버 혹은 스티커 생성 서버 처럼 요청 시간이 길거나 오류가 나더라도 나머지 게시글, 블로그와 같은 메인 기능을 담당하고 있는 서버에는 영향이 없었기에 독립적으로 돌아갈 수 있었다.

 

세번째로, 우리의 서비스가 오류가 나더라도 책임소재를 확실하게 할 수 있었다. 즉 바로 어떤 서비스에 오류가 났는지 알 수 있었기에 트러블 트래킹이 쉬웠다.

 

마지막으로는, 개발하기 매우 수월했다. 해당 프로젝트 같은 경우에는 총 4명의 백엔드 개발자에서 하나의 서버를 맡아 개발을 했다. 그렇기 때문에 깃 레포지토리도 각자 하나씩 도맡아 개발을 하였기 때문에 Cluster만 잘 설정해주면 Merge 충돌이나 버전관리가 훨씬 수월했다.

실제 레포지토리 구조(본인은 post service 개발)

---