## Loosely Coupled (느슨한 결합) MSA의 마이크로서비스는 다른 마이크로서비스와 독립적으로 구성되어야 한다. 서로 의존하게 구성될 경우 마이크로서비스 하나에 장애가 생겼을 때, 그 장애가 연쇄적으로 전파되는 [[IT 용어 정리 📕#`단일 장애 지점`|단일 장애 지점]] 문제가 생긴다. 이는 마이크로서비스별로 별개의 데이터 저장소를 가져야 하는 이유이기도 하다. 하나의 데이터 저장소를 공유할 경우, 데이터 저장소가 단일 장애 지점이 될 수 있다. ![[IT 용어 정리 📕#`단일 장애 지점`]] ## Fine-Grained (적절한 분리) MSA의 마이크로서비스는 기능과 성격에 맞게 적절히 분리되어야 한다. 너무 세밀하게 분리할 경우 관리해야 할 마이크로서비스가 많아져 운영과 관리가 어려워진다. 반대로 기능을 너무 크게 분리할 경우 하나의 마이크로서비스에 많은 기능이 집중되면서 분산과 확장이라는 MSA의 장점이 사라진다. 현실적으로 한 번에 서비스 기능을 잘 분리하여 MSA를 설계하는 것은 어렵기 때문에 운영 도중 마이크로서비스를 다시 쪼개거나 합치기도 한다. ## Lightweight Protocol (가벼운 프로토콜) 각 마이크로서비스는 API를 통해 서로 데이터를 주고받는다. 이 과정에서 [[IT 용어 정리 📕#`직렬화`|직렬화]]된 데이터가 원래 객체의 크기보다 훨씬 커질 경우 네트워크 성능 저하가 발생할 수 있다. 따라서 시스템의 전반적인 성능 최적화를 위해 가벼운 프로토콜을 사용해야 한다. 예를 들어, RESTful API나 gRPC와 같은 경량 프로토콜을 사용하는 것이 좋다. ![[IT 용어 정리 📕#`직렬화`]] ## Asynchronous Communication (비동기 통신) 비동기 통신은 서비스 간의 시간적 결합을 줄여준다. 동기 통신은 호출한 서비스가 응답을 기다려야 하므로 네트워크 지연이나 장애 시 전체 시스템에 영향을 줄 수 있다. 비동기 통신을 통해 이러한 문제를 완화할 수 있다. ## 참고 - [GS ITM 기술 블로그 - 코드로 살펴보는 MSA 이야기](https://www.gsitm.com/pr/techblogdetail?prTechBlogSeqId=13) - [Medium - Service-Oriented Architecture vs Event-Driven Architecture vs MSA](https://medium.com/@hoon33710/service-oriented-architecture-vs-event-driven-architecture-vs-msa-b7909c2356e1)