genieus와 함께하는 MSA (Micro Service Architecture)

MSA (Micro Services Architecture)

1. MSA란?

정의 : 하나의 거대한 어플리케이션을 다수의 작은 어플리케이션으로 나누어 변경과 조합이 가능하도록 만든 아키텍처

위 그림에서 왼쪽은 Monolithic 형태의 아키텍처이고 오른쪽은 Micro 형태의 아키텍처 입니다.

만약 서비스가 계속 추가된다고 가정해봅시다. 2가지의 아키텍처는 어떻게 될까요?
모놀리틱 아키텍처(MA)는 하나의 프로젝트 안에 서비스가 계속 추가되어 매우 복잡한 형태가 되고 아래와 같은 부작용을 얻게됩니다.

• 서비스및 프로젝트의 크기가 커질수록 시스템 전체 구조를 파악하는데 어려움이 있습니다.
• 빌드 시간, 테스트 시간,  배포 시간이 기하급수적으로 늘어나게 됩니다.
• 어느 한 부분에서 장애가 일어나면 전체 서비스에 문제가 생길 가능성이 커집니다.

하지만 MSA는 각 서비스들이 독립적으로 존재하고 있어 서비스가 지속적으로 추가되더라도 간편한 모습을 나타낼 것 입니다. (SOA의 특징을 가짐)

위 예시에서 회원 - 상품 - 주문은 각각의 서비스로 구현되어 end-point를 API 형태로 외부에 노출하여 외부에 통신하게 됩니다.
내부의 구현 로직은 서로 의존하지 않고 독립되어 내부에 감춰진 상태를 유지하고 있습니다.

 

비교점	Monolithic Architecture	Micro Service Architecture
배포	한번에 배포해야 함. 배포 시간이 오래 걸림	서비스마다 독립적인 배포 가능. 배포 시간이 빠름
장애	부분 장애가 전체 서비스의 장애가 될 수 있고 오류 파악이 어려움	부분 장애는 부분 서비스에서만 발생하여 전체에 영향 X 오류 파악이 용이
변경	서비스의 변경이 어려움	서비스의 변경이 쉬움
확장	서비스 확장이 전체 프로젝트에 영향을 미치므로 확장이 어려움	서비스가 추가될 때 마다 확장이 용이
구조	하나의 프로젝트 안에서 완성되기 때문에 간단	서비스가 모두 분산되어 있기 때문에 복잡함
트랜잭션	단일 트랜잭션만 유지하면 됨	서비스에 따라 여러 개의 트랜잭션이 필요
테스트	통합 테스트가 용이	통합 테스트가 어려움
운영 환경	운영 환경과 개발 환경을 동일하게 맞추기가 쉬움	운영 환경과 개발 환경을 동일하게 맞추기가 어려움

2. MSA 구조 알아보기

MSA는 Inner 부분과 Outer 부분으로 구분할 수 있습니다.

아래 그림에서 남색 부분은 Inner / 회색 부분은 Outer 입니다.

출처 : https://velog.io/@tedigom/MSA-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-2-MSA-Outer-Architecure

 - Inner Architecture : 내부 서비스와 관련된 아키텍처입니다. Inner는 내가 어떤 비즈니스 로직으로 구현하는 지에 
                             따라 달라지는 부분이므로 정해진 정답은 없습니다.
 - Outer Architecture : 운영환경과 분산된 마이크로서비스를 관리하는 역할하는 아키텍처입니다.

                              'Gartner' 에서는 총 6개의 영역으로 분류하여 설명하고 있습니다.

---

• External Gateway
• Service Mesh
• Container Management
• Backing Services
• Telemetry
• CI/CD Automation

  ---

1) External Gateway

External Gateway는 전체 서비스 외부로부터 들어오는 접근을 처리하기 위한 역할을 합니다.
외부에서는 내부 구조를 파악할 수 없으며 내부 구조로 접근하고 싶다면 Gateway를 통과해야 합니다.
주로 사용자 인증이나 정책 관리 역할을 수행하는 데 사용 됩니다.

API Gateway는 서버 가장 앞에 위치하여 모든 API의 호출을 받습니다. 
받은 API 호출을 인증한 후 적절한 서비스가 응답할 수 있도록 하는 라우팅 역할을 수행합니다. 

2) Service Mesh

Service Mesh는 Micro Service 구성 요소 간 네트워크를 제어하는 역할을 수행합니다.

3) Container Management

Container Management는 개발자가 쉽게 접근하고 운영할 수 있는 인프라를 제공하는 역할을 합니다.
현재는 Kubernetes라는 오픈 소스가 컨테이너 관리 환경으로 자주 사용되고 있습니다.

4) Backing Service

Backing Service는 애플리케이션이 실행되는 가운데 네트워크를 통해서 사용할 수 있는 모든 서비스를 의미합니다.

예를 들어 Mysql이나 MongoDB와 같은 데이터베이스, RabbitMQ나 Beanstalkd와 같은 메시지/큐 시스템,
Postfix와 같은 메일 송신을 위한 SMTP 서비스, Memcached와 같은 캐시 시스템이 있습니다.

 

각각의 벡엔드 서비스는 리소스입니다. 리소스는 언제든지 붙이거나 떼어낼 수 있습니다.

예를 들어 하드웨어에 문제가 발생해 어플리케이션이 정상적으로 작동하지 않는다면 관리자는 백업 파일로부터 새로운 데이터베이스 서버를 실행시킬 것입니다. 데이터베이스가 실행되면 기존의 프로덕션 데이터베이스를 떼어내고(detach), 새로운 데이터베이스를 어플리케이션에 붙입니다(attach). 이 과정에는 어떠한 코드 수정도 필요 없습니다.

출처 : http://the-twelve-factor-app.herokuapp.com/backing-services

5) Telemetry

Telemetry는 서비스들을 모니터링하고 서비스 별로 발생하는 오류에 대응할 수 있도록 환경을 만드는 역할을 합니다.

또한, 로그를 찍어 어떤 오류가 발생했는 지 알려줍니다.

Telemetry는 Grafana, Prometheus, EFK와 같이 오픈소스로 직접구현하는 방법, Datadog와 같은 상용 솔루션을 이용하는 방법, 그리고 AWS Cloud watch, GCP Stackdriver와 같이 public cloud의 SaaS를 이용하는 방법으로 구현할 수 있습니다.

출처 : https://velog.io/@tedigom/MSA-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-6Telemetry

6) CI/CD Automation

CI/CD Automation은 애플리케이션 개발 단계를 자동화하여 보다 짧은 주기로 고객에게 제공하는 방법입니다.
CI/CD의 기본 개념은 지속적인 통합, 지속적인 서비스 제공, 지속적인 배포입니다. CI/CD는 새로운 코드 통합으로 인해 개발 및 운영팀에 발생하는 문제(일명 "integration hell")을 해결하기 위한 솔루션입니다.

특히, CI/CD는 애플리케이션의 통합 및 테스트 단계에서부터 제공 및 배포에 이르는 애플리케이션의 라이프사이클 전체에 걸쳐 지속적인 자동화와 지속적인 모니터링을 제공합니다.

출처 : https://www.redhat.com/ko/topics/devops/what-is-ci-cd

 

이렇게 MSA의 특징과 구조에 대해 알아봤습니다.

MSA는 현재 다양한 형태로 사용되고 있습니다. 

다음 시간에는 Netlix에서 개발한 "Zuul" 이라는 이름의 MSA 구조를 살펴보겠습니다!