새로운 팀프로젝트를 만들기 전에 어떤 아키텍쳐로 개발하는 것이 좋을지 생각해보자는 의견이 나왔다.
마이크로서비스 아키텍쳐를 들어보긴 했지만 사실 그때는 뭐가뭔지 어렵고 가늠이 되지않아서 넘어갔는데, 이번 기회에 간단하게 나마 알게 되었고, 우리 팀프로젝트에 어떻게 적용해야 할 지 생각해보았다.
결론부터 말하면 우리는 약 2~3개월의 단기 프로젝트이고, 학습을 위한 프로젝트이기 때문에 FE 라이브러리는 React를 BE 프레임워크는 Nest, 데이터베이스는 MySQL을 사용하기로 했다. 따라서 아키텍쳐를 선택한다면 빠르게 개발할 수 있고, 기능이 엄청 많지는 않을 것이기 때문에 MS 아키텍쳐를 선택하게 될 것같다.
또 내가 일하는 회사는초기스타트업인데 이 개념을 적용해보니 MS였다.
회사에서 지금 프로젝트가 아닌, 예전에 만든 다른 MVP 서비스는 포인트 시스템은 Go랭과 db는 MySQL로, 나머지 시스템은 node와 mySQL로 짜서 지금 서비스 보다는 더 MSA 스럽다고 할 수 있을 것 같다.( 그렇다구 MSA라고는 할수 없는거같은..)
(MSA와 MA에 대한 개념은 많은 블로그에 많이 잘 나와있기 때문에 내가 알게 된 내용을 기억 할 수 있을 정도로만 간단하게 정리!)
MS
특징
- 하나의 서비스 또는 어플리케이션이 하나의 거대한 아키텍쳐를 가질 때
- 단일 어플리케이션에 계속 기능을 붙인다.
장점
개발 속도가 빠르고, 배포가 쉽고, 기능 개선이 쉽다
단점
사업이 커지면 단점이 된다.
서비스의 크기가 커지면 관련 기능의 결합이 커진다.
시스템이 커지면 배포파일의 크기가 커지고 시간이 오래걸리다.
장애가 발생하며 모든 서비스가 모두 죽는다.
MSA
API를 통해 통신하는 작고 독립적인 서비스의 모임
쪼개는 방식에 대해서는 왕도가 없다 (이런게 제일 어려움 ㅠㅠ)
특징
API를 통해 통신하는 작고 독립적인 서비스의 모임
Api로 서비스가 나뉘어져서, 모놀리식에 비해 어플리케이션의 모듈성을 유지하기 쉽다.
예시
예를 들어 결제는 mySQL을, 고객 관리는 nodejs - mongoDB를 사용하는 등, 서비스 마다 알맞은 기술스택을 선택하여 개발
장점
시스템에 장애가 발생하면 장애가 발생한 곳만 죽는다.
서비스 자체가 작으니, 어플리케이션 실행시간이 짧다
단점
1. 도입이 어려움. 2. 서비스 호출이 단순 시스템보다 복잡한 운영, 3. 트랜젝션 유지의 어려움(db가 엄청 분산). 4. 디버깅 어려움
---
이건 추가로 도움되는 영상 ㅋ
https://www.youtube.com/watch?v=saxHxoUeeSw