[Server] 마이크로 서비스 아키텍처(MSA, MicroService Architecture)란?

1. 마이크로 서비스 아키텍처(MSA, MicroService Architecture)에 대한 이해

---

[ 마이크로 서비스 아키텍처(MSA, MicroService Architecture)란? ]

애플리케이션 개발 초기에는 전체 애플리케이션의 소스 코드를 하나의 배포 유닛(war 또는 ear)으로 내장시키는 '모놀리식' 방식을 이용하였다. 하지만 기존 애플리케이션에 최소한의 변경 사항이 있어도 자체적인 QA(Quality Assurance) 주기에 따라 대규모 업데이트를 해야 하거나 일부 애플리케이션의 업데이트로 오류가 발생한 경우 전체를 오프라인으로 전환하고 문제를 해결하는 등 다운타임이 발생하게 되었다.

이러한 문제점을 해결하기 위해 전통적인 모놀리식(monolithic) 접근 방식과 다르게 애플리케이션을 핵심 기능으로 세분화하여 하는 MicroService(MS)라는 아키텍처 기반의 접근 방식이 탄생하게 되었다. 여기서 각 기능을 서비스라고 부르며, 독립적으로 구축하고 배포할 수 있게 되었다.

 

 

예를 들어 온라인 쇼핑몰 사이트에서 제품을 검색하기 위한 검색 기능도 하나의 서비스가 되며, 구매를 추천해주는 추천 내역 역시 하나의 서비스가 될 수 있다. 마찬가지로 장바구니 역시 하나의 서비스가 될 수 있다. 이렇게 MS는 애플리케이션의 핵심 기능으로, 다른 서비스들과 독립적으로 작동한다. 또한 다른 서비스들과 유연하게 결합하며 향후 확정 및 새로운 기능 통합 등에 대비할 수 있다.

 

 

[ 마이크로 서비스 아키텍처(MSA, MicroService Architecture) 장점 ]

• 분산형 개발을 통해 효율적인 개발 가능(출시 기간 단축)
• 개별 서비스가 다른 서비스에 부정적인 영향을 주지 않으면서 작동할 수 있음(뛰어난 복구 능력)
• 다른 서비스들과 유연하게 결합하며(언어의 제약 X) 향후 확장 및 새로운 기능 통합 등에 대비할 수 있음(높은 확장성)
• 기존의 모놀리식에 비해 더욱 모듈화되었기 때문에 배포에 따른 우려 사항들이 적어짐(손쉬운 배포)
• 개발자들이 각각의 서비스를 파악하고 개선하기에 용이해짐(편리한 액세스)

 

[ 마이크로 서비스 아키텍처(MSA, MicroService Architecture) 단점 ]

• 큰 프로젝트에는 많은 서비스들이 존재하므로, 모든 서비스를 모니터링 하는 오버헤드가 증가함
• 서비스에서 다른 서비스를 호출하므로 서비스에 장애가 발생한 경우 경로 및 장애 추적이 힘들 수 있음
• 서비스별로 로그가 생성되기 때문에 중앙 로그 모니터링은 존재하지 않음
• 각 서비스는 API를 통해 통신하므로 네트워크 통신에 의한 오버헤드가 발생

 

참고자료

 

• https://www.redhat.com/ko/topics/microservices/what-are-microservices