Monolithic Archi

하나의 서비스로 하나의 애플리케이션을 만드는 것으로, 통합 시나리오 테스트에 용이하고, 배포도 간단해진다는 장점이 잇있지만, 코드의 수정 및 추가가 어렵다는 것과 부분적인 서버 장애가 전체 서비스의 장애로 이어질 수 있다는 단점, 더군다나 Scale Out이 불가하다는 큰 단점이 있다.

Scale Out은 서버를 운영 중인 상태에서 사용자가 급격히 증가할 경우, 더 많은 서버 용량과 성능을 위해 서버를 여러 대 추가하여 확장하는 방법인데, Monolithic은 결합도가 높아 특정 한 부분만 n개로 확장할 수 없으며 통합 서버를 사전에 많이 배포한다면 가능할 것이다. scale up 또한 특정 한 부분만 확장 불가하다. 확장되지 않아도 되는 부분까지 확장해야 한다.

따라서 이는 소규모 애플리케이션, 소규모 협업의 경우에 사용하면 좋다.

MSA(Micro Service)

하나의 큰 애플리케이션을 작은 애플리케이션으로 나눠서 만드는 아키텍처로 각 모듈은 하나의 독립적인 역할을 수행하기에 의존성이 낮고, 장애가 발생해도 다른 서비스에 영향을 미치지 않는다(단일 책임 원칙)

모듈의 독립적 배포가 가능하기 때문에 개발 주기가 짧으며 각 서비스의 부하에 따라 개별적인 Scale out이 용이하다.(부하가 생기는 부분만 n개로 늘리기 가능)

하지만 각 모듈간 통신에 있어 API를 사용한 통신 비용 및 지연시간이 발생하며 분산된 서비스마다 분산된 트랜잭션 관리가 필요하다(정합성 문제 발생가능).

때문에 API Gateway를 통해 프록시 서버처럼 맨 앞단에서 모든 api에 대한 endpoint를 통합하여 모듈간 통신 문제를 해결한다.

Summary

무엇이 좋다고 말할 수는 없다. 프로젝트와 회사 규모에 따라 상황에 맞는 적절한 아키텍처를 잡아가는 것이 바람직한 선택이다.

ref) monolithic vs msa