이 글은 네이버 클라우드 플랫폼에서 제공한 유튜브 영상을 보고 정리한 내용입니다.
해당 영상은 맨 아래 링크로 첨부하였으니 확인하시기 바랍니다.

MSA란?

MSA vs Monolithic Architecture

보통 MSA를 monolithic 아키텍처에 대해 비교를 많이 한다.

출처: https://medium.com/finda-tech/finda-msa를-위한-kubernetes-세팅과-ci-cd-pipeline-구성-그리고-monitoring-시스템-구축-1-783bf49af15b

• Monolithic은 애플리케이션 안에 모든 비즈니스 로직이 다 들어가 있는 구조이다.
• MSA(Micro Services Architecture)는 애플리케이션의 각각의 서비스들이 Microservice라는 단위로 쪼깨어 구성되는, 아키텍처이자 하나의 접근 방식이다.

예제

만약 쇼핑몰 앱을 구성하기 위해 다음의 기능들이 필요하다고 하자.

• 사용자 관리
• 상품 관리
• 주문 관리

Monolithic 아키텍처에서는 이 세 기능을 모두 한 덩어리로 묶어 관리한다면, MSA는 각 기능들을 별개로 관리한다.

MSA의 구조

출처: NCP 유튜브 강의 - [Talk&Talk] 누구나 쉽게 이해할수 있는 마이크로서비스 아키텍처(MSA)

• 마이크로서비스란, 서비스를 비즈니스 경계에 맞게 세분화하고, 서비스 간 통신은 네트워크 호출을 통해 진행하여 확장 가능하고 회복적이며 유연한 어플리케이션을 구성하는 것이다.
• 외부에서는 앞단의 API 게이트웨이를 통해 접근한다.
• 각각의 서비스들을 쪼개어 관리하고, 서비스는 고유 DB를 갖는다.
• 각 서비스는 API를 통해 관리된다.

MSA가 인기 있는 이유

기존의 Monolithic 방법론을 보완했기 때문에 인기를 얻게 되었다.

Monolithic 방법론의 문제점

여러 기능이 뭉쳐 강하게 결합되어 있기 때문에 다음 문제들이 비롯된다.

• 개발 유연성의 한계
• 요구사항 대처 시간 소요
• 장애 격리/신뢰성
• 배포/롤백 리스크
• 리소스 낭비

특정 서비스만 배포를 하거나, 서비스를 추가하기에 어려움을 겪게 된다.

MSA의 인기 있는 이유 네 가지

1. MSA는 각 서비스들이 느슨하게 결합되어 있어 새로운 기능 추가나 업데이트에 있어 Monolithic 방식보다 용이하다.
   • 기존 Monolithic 방식은 소프트웨어의 모든 구성요소가 한 프로젝트에 합쳐져 있어, 큰 변화에 대한 대응이 어려우며, 새로운 기능 추가 및 업데이트에 어려움이 있었다.
2. MSA는 각 서비스들이 분리되어 있기 때문에, 하나의 서비스에서 발생한 장애가 다른 서비스로 전파되는 점에 있어서 Monolithic 방식에 비해 용이하다.
   • Monolithic 방식은 여러 역할을 하는 시스템이 하나의 소프트웨어로 집합되어 있어, 특정 부분에 문제가 발생 시 큰 장애로 이어질 수 있다.
3. MSA는 특정 서비스에 대한 Scale-Out이 가능하기 때문에 리소스를 효율적으로 관리할 수 있다.
   • Monolithic 방식은 여러 역할을 하는 시스템이 하나의 서버에 함께 올라가있기에, Scale-Out 시 필요 없는 자원이 함께 증가된다.
4. MSA는 민첩하고 손쉬운 배포 및 업데이트가 가능하다.
   • 신규 기능을 추가한다면 Monolithic은 신규 업데이트가 추가된 코드의 바이너리 파일을 만들어 배포하지만, MSA는 Blue-Green 배포 방식을 사용하여 점진적으로 변경하기 때문에 Green으로 트래픽이 다 넘어가더라도 Blue를 남겨두어 롤백이 바로 가능하다.
   • 문제가 발생한다면 Monolithic은 잘못된 부분을 수정 후 다시 바이너리 파일을 만들어 재배포해야 하지만, MSA는 잘못된 기능(서비스)이 올라가 있는 부분만 소스 코드를 일부 수정한 뒤, 컨테이너화 하여 해당 부분만 재배포하므로 빠르고 정확하게 대응할 수 있다.

MSA를 위한 기술과 구성요소

MSA를 도입한다면 어느 부분을 고민해야 하는가?

MSA를 구성하는 주요 Component

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 Sleuth, Zipkin
6. Centralized Monitoring
   • 서비스별 매트릭 정보의 중앙집중화 (모니터링)
   • Netflix Spectator, Heapster
7. Resilience & Fault Tolerance
   • MSA 구조에서 하나의 실패한 서비스가 체인에 연결된 전체 서비스들에 파급 효과를 발생시키지 않도록 하기 위한 계단식 실패 방지 구조
   • 예를 들어, 서비스 A를 호출하는 서비스 B가 있을 때, 서비스 A가 응답하지 않는다면 스레드가 대기 상태가 된다. 지속적으로 스레드가 대기 상태로 쌓이면 전체적인 장애로 이어질 수 있다. 따라서, A와 B 사이에 응답이 오지 않으면 다른 메시지를 준다던지 하는 식으로 장애로 이어지지 않도록 한다.
   • Netflix Hystrix, Kubernetes Health check
8. Auto-Scaling & Self Healing
   • 자동 스케일링, 복구 자동화를 통한 서비스 관리 효율화

MSA를 구현하는 기반 기술

• 크게 Spring Cloud와 Kubernets를 볼 수 있다.

출처: NCP 유튜브 강의 - [Talk&Talk] 누구나 쉽게 이해할수 있는 마이크로서비스 아키텍처(MSA)

• Spring Cloud와 Kubernetes는 둘 다 마이크로 서비스를 개발하고 실행하기에 최적의 환경이지만, 그 특징이 서로 상이하다.
• 자바 기술에 익숙하다면 Spring Cloud가 나을 수 있다.
• Kubernetes는 오픈소스로 굉장히 활발하게 사용되고 있기 때문에, 트러블 슈팅이나 활용 사례 등을 쉽게 찾아볼 수 있다.
  • 네이버 클라우드 플랫폼을 비롯한 다양한 클라우드 벤더 사에서 관리형 서비스로 제공해서 손쉽게 구축할 수 있다.
• 가지고 있는 기술력을 따져서 도입하는 것이 나을 것이다.

Kubernetes를 이용하여 구축할 경우

• Service Mesh에 대한 이해도 필요하다.
  • 마이크로 서비스 간 통신을 위해 각 서비스를 식별(Discovery)하고
  • 경로를 파악(Routing)하며
  • 로드밸런싱(Load-balancing)을 하고
  • 전체 서비스의 장애 전파를 차단(Circuit Break)하며
  • Telemetry와 통합되어 로깅, 모니터링, 트래이싱 기능을 담당
• 예전에는 마이크로서비스 간의 통신 로직을 마이크로서비스 안에 모두 넣었었다.
• 이러한 통신 부분을 마이크로서비스를 배포할 때, 프록시 컨테이너를 띄워서 프록시가 통신과 관련된 부분을 전담하도록 하는 것이 Service Mesh 구조이다.
• 개발자가 통신 구조를 가져가는 걸 원활히 할 수 있고, 통신 정책이나 보안적인 통신이 가능하도록 설정하는 등 다양한 기능을 제공해준다.
• ISTIO, LINKED 2, CONSUL, Traefik mesh, KUMA, Open Service mesh 등 다양한 Service Mesh 서비스들이 있다.

MSA 적용 사례

• Netflix
  • 높은 재생 품질을 다운타임 없이 서비스하는 것을 목표로 MSA 적용
  • 테크 블로그를 운영 중이다.
• 배달의 민족
  • 하나의 테이블에서 발생한 문제가 전체 DB의 장애로 이어진 적이 있다.
  • 하나의 시스템이 장애가 발생하더라도 전체적인 장애로 이어지지 않도록 MSA 도입
• 11번가
  • 거대한 Monolithic 시스템이어서 많은 개발팀의 코드를 한 번에 배포해야 하고, IDE에 띄우는 것조차 버거웠으며 버전을 업그레이드하는 것도 쉽지 않았다.
  • Netflix OSS와 Spring boot를 기반으로 한 MSA로의 전환을 시도

MSA를 구축하며 직면할 수 있는 어려움

MSA를 꼭 도입해야 하는가?

• 시스템의 복잡도가 높으면 MSA가 적합하다.
• 복잡하지 않으면 Monolithic이 적합하므로, 잘 고려해야 한다.

Service Mesh 적용 시 고려사항

1. 서비스 메쉬를 사용하면 런타임 인스턴스 수가 증가한다.
2. 각 서비스는 서비스 메쉬의 사이드카 프록시를 통해 호출되므로 개별 프록시 수가 증가하게 된다. 이에 따른 부하로 서비스 운영에 문제가 발생할 가능성이 있는지에 대해 아키텍처 구조 측면에서 사전에 검토해야 한다.
3. 빠르게 발전하고 있으나 아직은 새롭고 미성숙한 기술에 속한다. 또한 많은 기업이 서비스 메쉬에 대한 경험이 없는 실정이다.

Reference

[Talk&Talk] 누구나 쉽게 이해할수 있는 마이크로서비스 아키텍처(MSA) #1편

당신의 MSA는 안녕하신가요? MSA를 보완하는 아키텍처 EDM[Event Driven MicroService] | 인사이트리포트 | 삼성SDS