MSA [1편]

MSA(Micro Service Architecture)란?

MSA(Micro Service Architecture)는 하나의 거대한 애플리케이션을 작은 단위의 서비스들로 나누어 개발하고 운영하는 아키텍처 스타일을 의미한다.

기존의 모놀리식(Monolithic) 구조에서는 하나의 애플리케이션 안에 모든 기능이 들어 있기 때문에, 시스템 규모가 커질수록 유지보수와 배포가 어려워지는 문제가 있었다.

MSA에서는 이러한 문제를 해결하기 위해 애플리케이션을 여러 개의 **독립적인 서비스(Micro Service)**로 분리한다. 각 서비스는 독립적으로 배포되고 실행될 수 있으며, 서로 API 통신을 통해 협력하여 하나의 시스템을 구성한다.

예를 들어 쇼핑몰 서비스를 생각해 보면 다음과 같이 나눌 수 있다.

• 회원 서비스 (Member Service)
• 주문 서비스 (Order Service)
• 결제 서비스 (Payment Service)
• 상품 서비스 (Product Service)

이처럼 각각의 기능을 독립적인 서비스로 분리하여 개발 및 운영하는 것이 MSA의 핵심이다.

 

MSA를 만든 회사

MSA라는 개념 자체를 특정 회사가 처음 만든 것은 아니지만, 실제로 대규모 시스템에서 MSA를 적극적으로 활용하면서 이 아키텍처를 널리 알린 대표적인 회사는 Netflix이다.

특히 Netflix는 기존의 모놀리식 구조에서 발생하던 문제를 해결하기 위해 서비스를 수백 개의 마이크로서비스로 분리하였다. 이 과정에서 다양한 기술들이 만들어졌는데, 대표적인 것이 다음과 같다.

• Eureka
• Ribbon
• Hystrix
• Zuul

이 기술들은 이후 Spring Cloud Netflix 프로젝트로 이어지며 많은 MSA 시스템에서 사용되었다.

또한 Amazon과 Netflix는 MSA를 활용한 대표적인 기업 사례로 많이 언급된다.

 

Digital Native와 Cloud Native

MSA를 이해하려면 함께 등장하는 개념인 Digital Native와 Cloud Native도 알아야 한다.

Digital Native

Digital Native는 처음부터 디지털 환경에서 태어나고 성장한 기업이나 서비스를 의미한다.

대표적인 예

• Netflix
• Amazon
• Uber
• Airbnb

이러한 기업들은 처음부터 대규모 트래픽과 빠른 서비스 확장을 고려한 아키텍처를 사용해야 했고, 그 과정에서 MSA와 Cloud 기반 기술들이 발전했다.

 

Cloud Native

Cloud Native는 클라우드 환경을 최대한 활용하여 애플리케이션을 개발하고 운영하는 방식을 의미한다.

Cloud Native 아키텍처의 대표적인 특징은 다음 네 가지로 설명된다.

1. DevOps
2. Continuous Delivery
3. Microservices
4. Containers

이 네 가지 요소가 함께 사용될 때 Cloud-Native한 시스템이라고 할 수 있다.

 

DevOps

DevOps는 Development + Operations의 합성어이다.

즉, 개발팀(Development)과 운영팀(Operations)의 협업을 통해 빠르고 안정적으로 서비스를 배포하고 운영하는 문화 및 방법론을 의미한다.

DevOps는 다른 말로 CAMS라고도 표현한다.

CAMS는 다음 네 가지 요소를 의미한다.

• C (Culture) : 협업 문화
• A (Automation) : 자동화
• M (Measurement) : 측정
• S (Sharing) : 공유

이러한 DevOps 문화를 구현하기 위해 가장 중요한 것이 바로 CI/CD 자동화 시스템이다.

 

CI/CD

CI/CD는 DevOps를 실현하기 위한 자동화된 배포 시스템이다.

CI (Continuous Integration)

CI는 지속적인 통합을 의미한다.

개발자가 코드를 수정하고 main branch에 push하면 자동으로

• 빌드
• 테스트

과정이 수행된다.

 

CD (Continuous Delivery / Continuous Deployment)

CD는 지속적인 배포를 의미한다.

CI 과정이 성공적으로 끝나면 다음 과정이 자동으로 이루어진다.

• 서버 배포
• 서비스 업데이트

즉, main branch에 push만 해도 자동 배포가 가능하도록 만드는 시스템이다.

대표적인 CI/CD 도구

• Jenkins
• GitHub Actions
• GitLab CI
• ArgoCD

 

Microservice에는 정답이 없다

MSA에서 중요한 특징 중 하나는 마이크로서비스를 나누는 절대적인 기준이 존재하지 않는다는 것이다.

어떤 시스템에서는

• 회원 서비스
• 주문 서비스
• 결제 서비스

이렇게 나눌 수도 있지만,

또 다른 시스템에서는

• 인증 서비스
• 사용자 관리 서비스
• 주문 처리 서비스

처럼 다르게 나눌 수도 있다.

즉, 비즈니스 도메인과 서비스 특성에 따라 마이크로서비스의 경계는 달라질 수 있다.

 

MSA를 사용하는 이유

MSA를 사용하는 이유는 다음과 같다.

1. 독립적인 배포

서비스가 분리되어 있기 때문에 특정 서비스만 수정하고 배포할 수 있다.

예

• 주문 서비스만 업데이트
• 결제 서비스만 수정

전체 시스템을 다시 배포할 필요가 없다.

 

2. 확장성 (Scalability)

특정 서비스에 트래픽이 몰릴 경우 해당 서비스만 확장할 수 있다.

예

• 주문 서비스 서버 3개
• 결제 서비스 서버 1개

이처럼 서비스마다 필요한 만큼만 서버를 늘릴 수 있다.

 

3. 장애 격리

하나의 서비스에 문제가 발생해도 전체 시스템이 멈추지 않는다.

예

• 결제 서비스 장애
• 주문 서비스 정상 동작

 

하지만 단점도 존재한다

Micro Service로 쪼갤 정도라면 서비스 규모 자체가 큰 경우가 많다.

서비스를 잘게 나누면

• 네트워크 통신 증가
• 서비스 관리 복잡도 증가
• 운영 난이도 증가

등의 문제가 발생할 수 있다.

따라서 개발자 입장에서는 오히려 유지보수가 더 어려워질 수도 있다.

그래서 무조건 MSA가 좋은 것은 아니다.

 

Containers

Cloud Native 아키텍처에서 중요한 요소 중 하나가 Containers이다.

대표적인 컨테이너 기술이 바로 Docker이다.

Docker는 애플리케이션을 컨테이너 단위로 실행할 수 있도록 해주는 플랫폼이다.

 

Docker Image

Docker에서는 Image라는 개념이 있다.

Docker Image는 애플리케이션 실행에 필요한 환경을 포함한 실행 템플릿이다.

이 Image를 기반으로 여러 개의 Container를 생성할 수 있다.

즉,

Docker Image → Container 생성

 

Docker를 사용하는 이유

Docker를 사용하는 이유는 다음과 같다.

컴퓨터 한 대에 여러 개의 컨테이너를 동시에 실행할 수 있기 때문이다.

예를 들어

• member-service container
• order-service container
• payment-service container

이처럼 하나의 서버에서 여러 서비스를 실행할 수 있다.

또한 장애가 발생하면

• 장애가 발생한 컨테이너만 삭제
• 새 컨테이너 생성

과 같은 방식으로 빠르게 대응할 수 있다.

또한 특정 기간에만 트래픽이 몰리는 서비스가 존재한다.

예를 들어

• 쇼핑몰 이벤트
• 블랙프라이데이

이럴 때 컨테이너를 추가로 생성하여 트래픽을 처리할 수 있다.

이러한 확장을 Scale Out이라고 한다.

 

Micro Service와 Container의 관계

Micro Service로 서비스를 분리해야 각 서비스를 컨테이너 단위로 실행할 수 있다.

예를 들어

• member-service container
• order-service container
• payment-service container

이처럼 서비스마다 독립적인 컨테이너를 띄울 수 있다.

 

 

 

API Gateway

MSA에서는 클라이언트가 직접 여러 서비스에 접근하지 않는다.

대신 API Gateway를 통해 접근한다.

대표적인 기술

• Spring Cloud Gateway

구조는 다음과 같다.

Client → API Gateway → Micro Services

Client의 요청은 API Gateway로 전달되고, Gateway가 요청에 맞는 서비스로 전달해준다.

 

Load Balancer

예를 들어 member-service 서버가 3개 존재한다고 가정해보자.

• member-service-1
• member-service-2
• member-service-3

이때 Gateway는 어느 서버로 요청을 보내야 할까?

이 문제를 해결하는 것이 Load Balancer이다.

Load Balancer는 다음과 같은 역할을 한다.

• 트래픽 분산
• 서버 장애 대응
• 서버 상태 확인 (Health Check)

즉, 트래픽이 몰릴 경우 적절한 서버로 요청을 분산시켜준다.

네트워크 장비에서는 이를 L4 스위치라고 부르기도 한다.

 

Service Discovery

MSA 환경에서는 서비스 인스턴스가 계속 생성되고 삭제된다.

예

• 서버 확장
• 서버 장애
• 컨테이너 재생성

이 때문에 서비스의 위치(IP, Port)를 고정할 수 없다.

이 문제를 해결하기 위해 등장한 것이 Service Discovery이다.

 

Eureka

Eureka는 마이크로서비스의 위치 정보를 관리하는 서비스 레지스트리이다.

즉,

• Micro Service
• API Gateway

와 같은 서비스들이 자신의 위치 정보를 Eureka Server에 등록한다.

이 Eureka Server를 Service Registry라고 한다.

 

Eureka의 역할

Eureka는 다음 두 가지 역할을 한다.

1. Service Registry

서비스들을 등록하는 저장소 역할

2. Service Discovery

다른 서비스들이 등록된 서비스를 검색할 수 있도록 도와준다.

 

Eureka 동작 방식

1. Micro Service 실행
2. Eureka Server에 서비스 등록
3. API Gateway가 Eureka에서 서비스 조회
4. Gateway가 해당 서비스로 요청 전달

 

왜 Eureka Server를 먼저 실행해야 할까?

Eureka Server는 서비스들의 등록을 관리하는 중앙 서버이기 때문이다.

Micro Service와 Gateway는 자신의 위치 정보를 Eureka Server에 등록해야 한다.

만약 Eureka Server가 실행되지 않은 상태라면

• 서비스 등록 실패
• 서비스 탐색 실패

가 발생한다.

따라서 항상 Eureka Server를 먼저 실행해야 한다.