System Architecture - 마이크로서비스와 모놀리식(Microservice and Monolithic)

마이크로서비스

출처: https://medium.com/gsretail/마이크로서비스-미니서비스-매크로서비스-2cd5a01bfae6

 

마이크로서비스는 소프트웨어가 잘 정의된 API를 통해 통신하는 소규모의 독립적인 서비스로 구성되어 있는 경우의 소프트웨어 개발을 위한 아키텍처 및 조직적 접근 방식이다. 이러한 서비스는 독립적인 소규모 팀에서 보유한다.

 

마이크로서비스 아키텍처는 애플리케이션의 확장을 용이하게 하고 개발 속도를 앞당겨 혁신을 실현하고 새로운 기능의 출시 시간을 단축할 수 있게 해준다.

 

1. 마이크로서비스는 주변 서비스에 대한 인식 없이 독립적으로 개발, 배포 및 관리된다.

2. Publish-Subscribe Patter 혹은 HTTP 기반 RESTful 방식으로 서로 통신한다.

3. 단일 책임이 있다.

4. 느슨하게 결합되어있다.

 

모놀리식 아키텍처

출처: https://medium.com/gsretail/마이크로서비스-미니서비스-매크로서비스-2cd5a01bfae6

반면 모놀리식 아키텍처의 경우 모든 프로세스가 긴밀하게 결합되어 있고 단일 서비스로 실행된다. 따라서 애플리케이션의 한 프로세스에 대한 수요가 급증하면 해당 아키텍처 전체를 확장해야 한다. 코드 베이스가 증가하게 되면 모놀리식 애플리케이션의 기능을 추가하거나 개선하기가 더 복잡해진다. 또한 그러한 복잡성으로 인해 실험에 제한을 받을 수 있으며, 새로운 아이디어를 구현하기가 어려워진다. 종속 관계를 이루며 긴밀하게 결합된 수많은 프로세스로 인해서 단일 프로세스의 실패로 인한 영향이 증가함에 따라 모놀리식 아키텍처는 애플리케이션 가용성에 대한 위험을 가중시킨다.

 

모든 비즈니스 서비스가 애플리케이션 서버에 단일 패키지로 배포되고 동일한 데이터베이스를 공유한다. 따라서 덜 복잡하고 서비스 간 긴밀한 결합을 허용한다.

 

무엇을 사용하지?

 

출처: https://www.samsungsds.com/kr/insights/msa.html

"모놀리식으로 관리하기에 특별히 복잡할 시스템을 운영할 상황이 아니라면 마이크로서비스는 고려할 필요조차 없다." 디자인 패턴으로 유명한 마틴 파울러가 남긴 말이다.

 

개발 생산성은 시스템 복잡도 단계에 따라서 아키텍처마다 달라진다. 만약 마이크로서비스 기반 애플리케이션을 도입하거나 또는 전향을 고민한다면 다음 사항들을 고려해 볼 필요가 있다.

 

1. 비용: 특정 서비스 아키텍처를 도입할 경우 비용을 얼마나 절감할 수 있는가?

2. 개발 생산성: 마이크로서비스가 사용될 만큼 시스템 복잡도가 높은가? 또는 복잡도를 지나치게 높인 마이크로서비스가 오히려 생산성을 저해하고 있지는 않은가?

3. 운영: 개발팀에게 개발과 운영을 동시에 요구할 만큼 인프라가 준비되어 있는가?

 

출처

https://www.samsungsds.com/kr/insights/msa.html

https://medium.com/gsretail/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EB%AF%B8%EB%8B%88%EC%84%9C%EB%B9%84%EC%8A%A4-%EB%A7%A4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-2cd5a01bfae6

https://aws.amazon.com/ko/microservices/#:~:text=%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4%EB%8A%94%20%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4%EA%B0%80,%EC%86%8C%EA%B7%9C%EB%AA%A8%20%ED%8C%80%EC%97%90%EC%84%9C%20%EB%B3%B4%EC%9C%A0%ED%95%A9%EB%8B%88%EB%8B%A4.