[MSA] 마이크로서비스 아키텍처란?

마이크로서비스 아키텍처(MSA)에 대해 알아보자.

 

NAVER Cloud Platform : 네이버 클라우드 플랫폼의 [Talk&Talk] 누구나 쉽게 이해할 수 있는 마이크로서비스 아키텍처(MSA)를 한번 보고 오면 이해가 쉽다.

더 자세히 알고 싶다면,  SK 플래닛의 11번가 Spring Cloud 기반 MSA로의 전환 - 지난 1년간의 이야기를 추천한다.

 

마이크로서비스 아키텍처 (MSA, MircroService Architecture)

마이크로서비스 아키텍처(MSA)는 소프트웨어 시스템을 작고 독립적인 서비스로 나누어 구성하는 디자인 패턴으로, 각 서비스는 특정 기능을 담당하며 서로 독립적으로 개발, 배포, 확장될 수 있다. 이러한 작은 서비스들이 모여 하나의 커다란 애플리케이션을 구성한다.

 

MSA는 서비스 지향 아키텍처(SOA)의 한 형태로, 서비스 간의 결합도를 최소화하고 서비스 간의 통신을 위한 표준화된 인터페이스를 제공하여 유연성과 확장성을 극대화한다. 또한 MSA에서는 각 서비스가 자체적으로 데이터베이스를 가질 수 있으며, 다양한 기술 스택을 사용하여 필요에 따라 적절한 도구나 프레임워크를 선택할 수 있다.

 

이를 통해 MSA는 개발자들이 더 빠르게 개발하고 배포할 수 있으며, 시스템의 유지보수와 확장이 용이해진다. 종합적으로 MSA는 기업의 현대적인 소프트웨어 개발과정에서 많은 이점을 제공하는 중요한 아키텍처 패턴 중 하나이다.

 

서비스 지향 아키텍처(Service Oriented Architecture(SOA))

• 애플리케이션 구성요소가 통신프로토콜을 통해 다른 구성요소에 서비스를 제공하는 아키텍처 접근 방식이다.
• 대규모 컴퓨터 시스템을 구축할 때의 개념으로 업무상에 일 처리에 해당하는 소프트웨어 기능을 서비스로 판단하여 그 서비스를 네트워크상에 연동하여 시스템 전체를 구축해 나가는 방법론이다.
• 여기서 '서비스'는 기능의 독립적 단위이다.

 

MSA 등장배경

 

 

Monolithic Architecture는 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어 있는 서비스이다. 현재 많은 회사들의 소프트웨어가 레거시 또는 필요로 인해서 Monolithic 형태로 구현되어 있다. 소규모의 프로젝트에서는 Monolithic 형태는 간단하며, 유지보수가 편하기 때문에 선호된다. 그러나 일정 규모 이상을 넘어가면 Monolithic은 많은 한계점에 봉착한다.

기존 Monolithic Architecture의 한계

• 부분 장애가 전체 서비스의 장애로 확대될 수 있다.
• 전체 시스템 구조 파악이 어렵다.
• 서비스 변경이 어렵고, 수정 시 영향도(사이드 이펙트 등) 파악이 힘들다.
• 빌드 시간 및 테스트, 배포 시간의 급증
• 서비스의 특정 부분만 스케일아웃(sacle-out) 하기 어렵다.

이러한 기존 모놀리식 구조 서비스의 한계점에서 MSA가 등장하게 되었다.

 

MSA 특징

MSA는 API를 통해서만 상호작용할 수 있다. 즉, 마이크로 서비스는 서비스의 end-point(접근점)을 API 형태로 외부에 노출하고, 실질적인 세부 사항은 모두 추상화한다. 내부의 구현 로직, 아키텍처와 프로그래밍 언어, 데이터베이스, 품질 유지 체계와 같은 기술적인 사항들은 서비스 API에 의해 철저하게 가려진다.

 

 

 

제대로 설계된 마이크로서비스는 하나의 비즈니스 범위에 맞춰 만들어지므로 하나의 기능만 수행한다. 즉, 애플리케이션 출시처럼 하나의 목표를 향해 일하지만 자기가 개발하는 서비스만 책임진다. 그리고 여러 애플리케이션에서 재사용할 수 있어야 한다.

애플리케이션은 항상 기술 중립적 프로토콜을 사용해 통신하므로 서비스 구현 기술과는 무관하다. 따라서 마이크로서비스 기반의 애플리케이션을 다양한 언어와 기술로 구축할 수 있다는 것을 의미한다. 

마이크로서비스는 SOA에서 사용되는 집중화된 관리 체계를 사용하지 않는다. 마이크로서비스 구현체의 공통적인 특징 중 하나는 ESB(Enterprise Service Bus)와 같은 무거운 제품에 의존하지 않는다는 점이다. REST 등 가벼운 통신 아키텍처, 또는 Kafka 등을 이용한 message stream을 주로 사용한다.

 

MSA 장점

1. 배포
   •  서비스별 개별 배포가 가능하다. (배포시 전체 서비스의 중단이 없다.)
   • 특정 서비스의 요구사항만을 반영하여, 빠르게 배포 가능하다.
2. 확장
   
   • 특정 서비스에 대한 확장성(scale-out)이 유리하다.
   • 클라우드 기반 서비스 사용에 적합하다.
3. 장애
   • 일부 장애가 전체 서비스로 확장될 가능성이 적다.
   • 부분적으로 발생하는 장애에 대한 격리가 수월하다.
4. 그 외
   
   • 새로운 기술을 적용하기 유연하다. (전체 서비스가 아닌 특정 서비스만 별도의 기술 또는 언어로 구현 가능)
   • 각각의 서비스에 대한 구조 파악 및 분석이 모놀리식 구조에 비해 쉽다.

 

MSA 단점

1. 설계의 어려움
   
   • MSA는 모놀리식에 비해 상대적으로 많이 복잡하다.
   • 서비스가 모두 분산되어 있기 때문에 개발자는 내부 시스템의 통신을 어떻게 가져가야 할지 정해야 한다.
   • 또한, 통신의 장애와 서버의 부하 등이 있을 경우 어떻게 transaction을 유지할지 결정하고 구현해야 한다.
2. 성능
   • 서비스 간 호출 시 API를 사용하므로, 통신 비용이나 Latency에 대해 이슈가 존재한다.
3. 테스트/데이터 트랜잭션
   
   • 모놀리식에서는 단일 트랜잭션을 유지하면 됐지만 MSA에서는 비즈니스에 대한 DB를 가지고 있는 서비스도 각기 다르고, 서비스의 연결을 위해서는 통신이 포함되기 때문에 트랜잭션을 유지하는 게 어렵다.
   • 통합 테스트가 어렵다.
   • 개발 환경과 실제 운영환경을 동일하게 가져가는 것이 쉽지 않다.
4. 데이터 관리
   
   • 데이터가 여러 서비스에 분산되어 있어 조회하기 어렵다.
   • 데이터를 관리하기 어렵다.

반응형

MSA 구성요소

MSA를 구성하는 주요 Component

MSA 구성

1. Config Management
   
   • 서비스의 재빌드, 재부팅 없이 설정사항을 반영
   • 환경 변수를 별도의 객체로서 관리한다.
   • Netflix Archaius, Kubernetes Configmap
2. Service Discovery
   
   • MSA 기반 서비스 배포 시 서비스 검색 및 등록
   • 각각의 서비스가 서로를 호출할 때, 서비스에 대한 위치 정보를 관리할 수 있는 객체이다.
   • Netflix Eureka, Kubernetes Service, Istio
3. API Management
   
   • 클라이언트 접근 요청을 일원화
   • 외부에서 요청을 할 때 허용된 요청인지, 트래픽을 제한하는 등 API를 관리한다.
   • Netflix Zuul, Kubernetes ingress
4. Centralized Logging
   • 서비스별 로그의 중앙집중화
   • ELK Stack
5.  Distributed Tracing
   • 마이크로서비스 간의 호출 추적
   • Spring Cloud Steuth, Zipkin
6. Centralized Monitoring
   • 서비스별 메트릭 정보의 중앙집중화
   • 서비스는 분산되어 있더라도 결국 모니터링은 하나의 대시보드 형태로 중앙집중화해서 관리하는 것이 필요하다.
   • Netflix Spectator, Heapster
7.  Resilience & Fault Tolerance
   • MSA 구조에서 하나의 실패한 서비스가 체인에 연결된 전체 서비스들에 파급 효과를 발생시키지 않도록 하기 위한 계단식 실패 방지 구조
   • 서비스가 체인에 연결된 전체 서비스에 파급 효과를 발생시킬 수 있기 때문에 서비스 간 서킷 브레이커를 둬서 서비스가 응답하지 않으면 다른 메시지를 보내는 등 서비스 하나의 장애가 전체적인 장애로 연결되지 않도록 해야 한다.
   • Netflix Hystrix, Kubernetes Health check
8.  Auto-Scaling & Self-Healing
   • 자동 스케일링, 복구 자동화를 통한 서비스 관리 효율화

 

---

참고 자료

https://cloud.google.com/learn/what-is-microservices-architecture?hl=ko

https://ko.wikipedia.org/wiki/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4

https://hahahoho5915.tistory.com/71

https://good-or-bad.tistory.com/52

https://dzone.com/articles/deploying-microservices-spring-cloud-vs-kubernetes#:~:text=Spring%20Cloud%20is%20a%20quick,wider%20range%20of%20microservices%20concerns.