우리 회사에서 기존 모놀리스 방식의 패키지를 MSA 방식으로 전환하기로 하였다.
하지만 몇 달간 신중하게 생각하고 고려한 결과 MSA를 진행하지 않기로 하면서 공부하고 이해했던 내용들을 회고하며 블로그에 기록하려고 한다.

많은 블로그와 사이트들에서 MSA와 관련된 기본적인 개념들은 많이 나와있기 때문에 내가 공부하고 경험한 내용만 최대한 적을 예정이다.

📘 MSA 하려했던 이유

기존 Oracle 사용으로 인한 비용이 엄청나기에 오픈소스 DB를 사용하고 싶었다.
또한 이벤트 행사가 한달에 하루정도 있다하면 하루 사용한 만큼의 비용만 지불하는 것이 아니라 한달 내내 스케일 아웃을 해야해서 클라우드화 시켜 사용한 만큼만 돈을 지불하고 싶었다.
마지막으로 사용량의 증가로 인한 DB 장애 발생 시 전면 장애를 예방하고 싶었기에 MSA를 추진하려 했다.

📜 MSA의 장단점

일단 MSA의 장단점을 먼저 알아봤다.

✏ 장점

• 배포시간의 단축 (유연한 배포)
• 신기술 수용 및 서비스에 맞는 DB 사용 가능
• 한 서비스 장애 시 다른 서비스에 전파될 가능성이 낮다.
• 부분적인 Scale-out으로 자원을 효율적으로 사용이 가능하다. (확장성 높음)

✏ 단점

• 유지보수의 어려움 (MSA로 마이그레이션하면 운영 도메인에 많은 복잡성이 추가된다.)
• API Gateway로 모든 요청이 거쳐가기 때문에 성능 저하
• API Gateway 방식 사용 시 단일 장애 포인트가 생길 수 있다.
• 트랜잭션 관리가 매우 어렵다.

이렇듯 여러 방안으로 생각했을 때 여러 기업들의 사례를 열심히 찾아보고 조사한 결과 진행 해보자! 하고 여러 기술들을 공부했다.

일단 흔하게 다들 사용하는 방식으로 생각을 해보기로 했다.

API Gateway / Service Discovery / Config Server / Message Queue / JWT 등등
많은 기업들에서 적용한 방식으로 공부를 했었다. 결론을 얘기하자면 Message Queue 빼고는 다 사용하지 않는 방식으로 결론을 지었다.

클라우드화는 제일 나중으로 생각하고 바로 적용할 수 있는 것들에 초점을 맞추었고 여러 이유들로 사용하지 않았던 것이다.

다음부터 MSA의 구성 요소들과 경험한 것들을 마저 정리하자.