표준 MSA 아키텍처

위 사진에서 파란색 영역으로 구분된 부분을 Inner Architecture, 나머지 부분을 Outer Architecture라 부릅니다.

• Inner Architecture : 실제 구현하려는 서비스와 직접적으로 연관되어 있는 부분입니다. 해당 부분들은 Container 환경에 배포됩니다. (ex. 주문관리 API 서버, 고객관리 API 서버 등)
• Outer Architecture : 시스템이 원활히 돌아갈 수 있도록 시스템 전반적인 부분을 가리킵니다. 외부에서의 접근과 서버간의 연동을 일원화 시켜주는 External Gateway부터 MSA 환경의 데이터 동기화를 위해 사용되는 kafka와 DB서버와 같은 Backing Service 등이 이에 해당합니다.
  
  

본 글에서는 Outer Architecture를 구성하는 모듈을 하나씩 간략하게 알아보겠습니다.

A. External Gateway

External Gateway는 MSA환경의 내/외부에서 Micro 단위의 각 서버에 접근하는 것을 관리하는 모듈입니다.
Micro 서버의 가장 앞단에 위치하여 모든 API로의 호출을 받고, 인증처리를 진행한 후에 각 서비스에 알맞게 트래픽을 전달합니다.

B. Service Mesh

Service Mesh는 MSA환경에서 방대한 양의 인스턴스로 인해 야기되는 복잡성과 불안정성을 보완하기 위해 도입된 아키텍처입니다.
Service Mesh의 구현체인 경량화 Proxy를 통해 Load Balancing, Circuit Breaking 등과 같은 공통 기능들을 제공하여 복잡성과 불안정성을 해소합니다.

MSA 환경에서 야기되는 복잡성/불안정성

1. 방대한 양의 인스턴스로 인해 모니터링 및 로깅에 어려움이 발생합니다.
2. 내부 인스턴스간 통신이 기하급수적으로 증가함에 따라 내부 통신환경이 불안정할수록 MSA 시스템에 큰 타격을 줄 수 있습니다.
   
   

Service Mesh에서 제공하는 대표적 기능들

1. Service Discovery : MSA 환경에서 동적으로 IP/PORT가 변하는 인스턴스를 효과적으로 호출하기 위해 사용되는 패턴입니다. Eureka와 같은 Service Registry가 사용가능한 인스턴스의 목록을 관리하고, 호출할 인스턴스의 IP/PORT를 반환해줍니다. 대표적인 방식으로 Client-Side Discovery, Server-Side Discovery, registration 방식이 있습니다.
2. Load Balancing : Service Mesh로 들어온 트래픽을 적절하게 분배하여 인스턴스에 전달합니다. MSA 환경에서 하나의 서버는 여러 개의 인스턴스를 생성하여 Scale-Out할 수 있는데, Eureka와 같은 Service Registry가 적절한 규칙을 통해 부하를 분산시켜줍니다.
3. Circuit Breaking : Circuit Breaking기능은 이러한 점을 보완하기 위한 기술입니다. 각 인스턴스는 Close, Open, Half-open 세 가지 상태로 Circuit Breaking 공통 기능을 사용하게 되고, 호출하는 서비스에 문제가 발생할 경우 상태를 Open상태로 전환하여 해당 서비스로의 호출에 대한 응답을 대기하지 않게 됩니다. Circuit Breaking은 회로차단기에서 차용한 개념입니다. 기존에는 하나의 서비스에 장애가 발생하면 해당 서비스를 호출하는 서비스가 대기상태가 되고, 대기상태를 또 호출하는 서비스도 대기상태로 되어 많은 컴퓨팅 리소스를 잡아먹게 됩니다. 이로 인해 장애가 확산되어 전체 시스템에 악영향을 초래할 수가 있는데, Circuit Breaking기능을 활용하면 이를 방지할 수 있습니다.
4. Retry and Timeout : 타 인스턴스로의 요청이 실패할 경우, 재요청 보내는 Retry 시간을 설정할 수 있고, Timeout 시간을 설정하여 일정시간이 지난 요청을 종료할 수 있습니다.
5. TLS : 보안을 위해 인스턴스간의 트래픽을 암호화할 수 있는 기능입니다.
6. Distributed Tracing : 분산 시스템의 성능을 디버깅하기 위해 트래픽을 추적할 수 있습니다. 이를 통해, 병목 현상을 식별하고 요청 및 응답 시 내부에서 소요되는 시간을 확인할 수 있습니다.
   
   

이 밖에도 Monitoring, Logging 등의 많은 기능을 수행할 수 있습니다.

Service Mesh 구현

각 Micro Service 앞단에 사이드카 형태로 경량화 Proxy를 배치하여 Retry and Timeout, Circuit Breaking 등과 같은 공통기능을 수행하게 함으로써 비즈니스 로직과 공통기능을 분리시키고, 공통기능을 통해 방대한 양의 인스턴스 환경을 안정적으로 운영할 수 있습니다.

대표적인 Service Mesh 툴로 Istio와 linkerd 등이 있습니다. 해당 툴은 Eureka와는 달리 Java에 종속적이지 않다는 장점이 있어 널리 활용되고 있습니다.

C. Backing Services

Backing Services모듈은 시스템의 데이터 관리를 담당하는 모듈입니다.

1. Persistence : RDBMS와 NoSQL 데이터를 영구히 저장할 수 있는 공간을 제공합니다. (ex. oracle, postgres 등) 이를 통해 DB 인스턴스가 예기치 못하게 종료되어도 데이터는 유지할 수 있습니다.
2. Cache: 데이터 캐쉬를 저장할 수 있는 공간을 제공합니다. (ex. redis) 마찬가지로 캐싱처리를 담당하는 인스턴스가 종료되어도 데이터를 유지할 수 있습니다.
3. Message Broker: Message Queue 등과 같은 기술을 활용하여 인스턴스간 데이터 정합성 유지를 도모할 수 있습니다. (ex. kafka)
   
   

D. Runtime Platform

관리해야하는 인스턴스의 양이 증가함에 따라 관리의 복잡성을 해결하기 위해 Container Orchestration이 해당 모듈에서 사용될 수 있습니다.
대표적인 툴로 Kubernetes가 있습니다.

방대한 인스턴스로 서비스를 운영하기 위해 Container기술을 도입하게 되었습니다.
해당 기술은 서비스간 독립적인 배포와 운영이 가능하고, 인스턴스의 빠른 생성과 제거가 가능하여 빠른 오토스케일링 기능과 배포를 도모할 수 있게 되었습니다. 그리고 Container환경으로 구성되어 있는 방대한 양의 인스턴스를 관리하기 위해 Container기술에 초점이 맞춰져 있는 Container Orchestration툴이 사용되기 시작했습니다.

위에서 언급된 Service Mesh와 Container Orchestration은 방대한 양의 인스턴스로 인해 야기되는 복잡성을 해소한다는 공통점이 있지만, Service Mesh는 MSA 환경의 안정성을 위해 공통기능을 제공한다는 데에 초점이 맞춰져있는 반면,
Container Orchestration은 Container기술에 초점을 맞추어 서비스 운영을 위한 경량화된 환경을 제공하여 운영효율성을 높이는 데에 초점이 맞춰져 있습니다.

E. Telemetry

Telemetry는 MSA환경에 배포되어있는 인스턴스들의 로그와 지표들을 한데 모아 관리하는 모듈입니다.
이를 통해 서비스 호출 트래픽을 추적할 수 있고, 로깅기능과 모니터링 기능을 제공할 수 있습니다.

대표적인 툴로 Elastic Search와 Prometheus, Grafana 등이 있습니다.

F. CI/CD Automation

• CI : Continuous Integration, 지속적 통합, 새로운 코드의 변경사항이 지속적으로 빌드 및 테스트 되어 공유 레포지토리에 통합되는 것을 의미합니다. 이를 위해 필요한 대표적 형상관리 툴로 Git이 있습니다.
• CD : Continuous Deployment, 지속적 배포, 새로운 코드의 변경사항이 CI 과정을 거쳐 공유 레포지토리에 통합되면 이를 Production환경까지 자동배포하는 것을 의미합니다. 이를 위해 필요한 대표적인 툴로 Jenkins가 있습니다.
  
  

이어서

다음 글에서는 간단한 MSA 서비스 구현 실습을 진행해보겠습니다.

본 글은 "MSA 이해와 구현"이라는 사내 강의 수강 후,
여러 MSA 관련 글을 참고하여 작성한 글입니다.

1. MSA란?

MSA는 Micro Services Architecture의 약자로 이름에서 유추할 수 있듯이 하나의 서비스를 Micro 단위로 쪼개서 관리하는 아키텍처를 의미합니다.

커머스 서비스를 예로 들면, 커머스라는 도메인 아래 하나의 서비스로 개발되고 운영되고 있었던 모놀리스(Monolith)형태가 아닌
주문, 정상, 회원, 상품 등 커머스 도메인 아래 여러 서비스로 추가 분리 및 개발하여 분리한 각 서비스를 각각의 서버에 배포하여 관리하는 MicroServices형태가 있을 수 있습니다.

위 사진은 가트너에서 제시한 표준 Micro Services Architecture 입니다.
MSA로의 구현 및 전환을 시도하는 많은 기업들에서 위 사진에서 제시된 표준 아키텍처를 따르고 있다고 합니다.
해당 아키텍처에 대해서는 다음글에서 다뤄보도록 하겠습니다.

2. Why? MSA

한눈에 보기에도 복잡한 이 MSA를 저희가 왜 써야할까요?
MSA를 쓰는 궁극적인 이유는 Loose Coupling, 느슨한 결합 특성때문이라고 볼 수 있습니다.
즉, 하나의 통합된 형태로 관리되던 서비스(ex. 커머스)를 여러 나눌 수 있는 최소한의 단위인 micro 단위의 서비스(ex. 주문, 정산, 회원 등)로 나눔으로써 각 서비스 간의 영향을 최소화할 수 있고(낮은 의존성), 이로 인해 모놀리스의 High Cohesion, 높은 응집력 특성으로 야기되는 다양한 문제(ex. 기능 단위 장애의 전체 확산 등)를 보완할 수 있게됩니다.

MSA의 이러한 Loose Coupling 특성은 다양한 기대효과를 낳을 수 있습니다.

장점

장애의 확산 차단

특정 Micro 서비스에서 장애가 발생하면, 전체 서비스로 확산되지 않습니다.

기존 모놀리스 구조에서는 특정 기능의 장애가 발생하면 전체 서비스가 마비되는 일이 흔했는데,
MSA에서는 Micro단위로 서비스를 세분화하여 각 기능을 독립시켰기 때문에
하나의 Micro 서비스가 타 서비스에 영향을 주지 않아 장애의 전체 확산을 막을 수 있습니다.

각 서비스의 개별 배포

각 Micro 서비스별로 개별 배포가 가능합니다.

기존 모놀리스 구조에서는 특정 기능에 대한 변경사항이 적용되려면, 서비스가 하나의 서버로 관리되었기 때문에 전체 서비스 배포가 불가피하였습니다.
MSA에서는 이러한 서비스를 여러 Micro 서비스로 나누어 별도의 서버로 각각 배포하는 구조이기 때문에
각 Micro 서비스별로 개별 배포가 가능합니다.

신속한 기능 수정 및 요구사항 반영

긴급하게 특정 기능에 대한 요구사항이 발생했을 때, 신속하게 반영할 수 있습니다.

위에서 언급했던 것처럼 MSA는 Micro 서비스 단위로 개별 서버에 배포되기 때문에, 서버의 크기가 비교적 작습니다.
이로 인해 배포 시간이 줄어들고 기능 수정이 신속하게 진행될 수 있습니다.

용이한 유지보수

용이한 유지보수가 가능합니다.

특정 서비스에 대한 장애나 이상징후 발생 시, 해당하는 서비스만 점검하면되기 때문에 대처할 영역이 좁아지므로
유지보수가 용이합니다.

Loose Coupling과는 별개로 다양한 기술 수용 등과 같은 장점이 존재합니다.

하지만 MSA의 Loose Coupling, 느슨한 결합 특성으로 인한 단점도 존재합니다.

단점

높은 복잡성

MSA를 활용하면 복잡성이 커집니다.

기존 모놀리스 기반 시스템은 하나의 서비스를 하나의 UI, 하나의 서버, 하나의 DB로 개발하고 관리해왔기 때문에,
타 모듈간 연동도 간단한 함수 호출로 이루어졌고, 데이터 동기화에 관한 부분도 단일 트랜잭션 처리로 간단하게 관리될 수 있었습니다.

하지만 MSA로 구현이 되는 서비스는 Micro 단위의 서비스마다 별개의 서버와 DB로 관리되고 있고,
이로 인해 타 모듈간 연동에 Rest나 gRPC 등과 같은 기술이 활용되어야 하고
데이터 동기화에 있어서도 분산 트랜잭션 환경의 메세지큐 기술이 도입되어 활용되어야하기 때문에,
개발 및 운영에 대한 복잡성이 커지게 되었습니다.

통신 비용 증가

MSA를 활용하면 통신비용 또한 증가됩니다.

여기서 말하는 통신비용은 latency에 따른 통신효율을 의미합니다.
위에서 언급한 것처럼 모놀리스 방식에서는 단순 메소드/함수 호출로 끝나는 연동이
MSA에서는 Rest나 gRPC와 같은 통신 기술이 활용되어야 합니다.
이로 인해 서비스 성능상의 비효율이 발생할 수 있습니다.

데이터 동기화의 어려움

MSA 기반 환경에서는 데이터 동기화를 위한 다양한 기술이 도입되어야 합니다.

서비스의 데이터가 하나의 DB로 관리되는 것이 아닌 Micro 단위의 서비스로 분리되어 각각 별도의 DB로 관리되는 형태이기 때문에,
데이터 일관성 또한 MSA환경에서 주요하게 다뤄야할 이슈라고 볼 수 있습니다.
이를 위한 기술도입 사례로 kafka 메세지큐 기술 도입 사례가 있는데,
특정 Micro 서비스에서 데이터 변경이 발생하여 kafka 메세지 큐에 이벤트를 발행하면,
kafka의 해당 이벤트를 구독하고 있는 Micro 서비스들이 이에 맞게 데이터 변경을 진행하는 방식이 있을 수 있습니다.

분산 트랜잭션 처리 필요

먼저 분산 트랜잭션 환경이란?
2개 이상의 네트워크 시스템간 트랜잭션 환경이라고 보면 됩니다.
모놀리스 환경에서 데이터베이스의 특성 ACID(원자성, 일관성, 고립성, 지속성)를 보장하기 위해 단일 서버/DB내 트랜잭션 처리를 하는 것처럼
MSA 환경의 여러 서버/DB 간에 ACID를 보장하기 위해 단일 트랜잭션이 처리되는 것처럼 여러 기술과 패턴이 도입되어 트랜잭션이 처리되어야 합니다.

이를 위한 대표적인 패턴으로 Saga패턴이 있습니다.

Monolith vs MSA

위와 같은 단점들이 있기 때문에 무조건적으로 모놀리스 방식이 아닌 MSA가 활용되어야 한다고 말할 수 없습니다.
MSA를 활용해야 하는지에 대해서는 구현해야 하는 도메인이나 비즈니스 환경, 사용기술, 해당 서비스를 관리해야하는 조직 등 특성에 따라 선택되어야 합니다.

1. 모놀리스

• 단일 코드베이스
• 쉬운 디버깅
• 쉬운 배포
• 상대적으로 좋은 성능
• 시스템 업데이트 시, 전체 시스템 배포 필요
• 코드 재사용의 어려움 (다른 시스템 모듈에서의 재사용)
• 변경 필요사항에 대한 유연한 대처 어려움
• 다양한 기술 사용에 제약
• 스케일링이 어려움

2. MSA

• 업데이트가 필요한 모듈만 배포 가능
• 코드 재사용이 쉬움 (다른 시스템에서의 코드 재사용)
• 변경 필요사항에 대한 유연한 대처 가능
• 특정 서비스의 장애로부터 독립 가능
• 다양한 기술 적용 가능
• 스케일링이 쉬움
• 개발난이도 증가
• 상대적으로 복잡한 배포
• 네트워크 지연으로 인해 상대적으로 떨어지는 성능
• 데이터 부정합에 취약
  
  

3. Cloud Native

MSA와 함께 많이 언급되는 개념인 Cloud Native에 대해 간략히 짚고 넘어가겠습니다.

Cloud Native란? 클라우드 환경에 맞게 서비스를 구축하여 클라우드의 이점을 최대한 활용한 환경이라고 보면 됩니다.
CNCF(Cloud Native Computing Foundation)에서 정의한 내용에서는 Cloud Native를 클라우드 네이티브 기술은 조직이 퍼블릭, 프라이빗, 그리고 하이브리드 클라우드와 같은 현대적이고 동적인 환경에서 확장 가능한 애플리케이션을 개발하고 실행할 수 있게 해준다. 컨테이너, 서비스 메쉬, 마이크로서비스, 불변(Immutable) 인프라, 그리고 선언형(Declarative) API가 이러한 접근 방식의 예시들이다. 이 기술은 회복성, 관리 편의성, 가시성을 갖춘 느슨하게 결합된 시스템을 가능하게 한다. 견고한 자동화 기능을 함께 사용하면 엔지니어는 영향이 큰 변경을 최소한의 노력으로 자주, 예측 가능하게 수행할 수 있다. 라고 정의하고 있습니다.
쉽게 말해서 Cloud 환경의 컨테이너, 서비스메쉬 등과 같은 기술들을 활용하면 관리편의성, 느슨하게 결합된 시스템 등과 같은 효과를 볼 수 있는 것이라고 보면 됩니다.

Cloud Native는 MSA로 구현되는 서비스에 적용되어야 하는 환경이라서 해당 개념을 더 자세하게 알고가면 좋을 것 같습니다.

아래 나열한 기술들은 Cloud Native의 4가지 핵심기술입니다.

1. CI/CD : Continuous Integration and Continuous Delivery(또는 Deployment), 각자가 작업한 코드를 하나의 결과물로 통합하여 테스트 빌드 지속적 수행(CI), 빌드된 결과물을 최종 배포하여 최종 사용자가 이용가능하도록 지속적 수행(CD), 이러한 과정을 지속적 자동 수행
2. DevOps : Development and Operation, 소프트웨어의 개발과 운영의 스피드와 품질을 향상하기 위한 새로운 조직 문화이자 접근방식. 개발계획 수립부터 비즈니스 타당성 검토, 개발, Build, Release, 서버 쪽에 Deploy , Operation, Monitoring까지 일련의 과정을 뫼비우스 띠처럼 반복
3. MicroServices : 하나의 서비스를 Micro 단위로 쪼개서 관리하는 아키텍처
4. Containers : 애플리케이션 구동을 위해 필요한 라이브러리나 구성파일들을 이미지라는 패키지 형태로 묶어서 구동시키는 환경. 해당 기술을 활용하면 서비스별 독립적인 구동이 가능하고, 효율적인 배포 및 Autoscale 가능
   
   

각 기술에 대한 설명을 간단하게 커멘트 남겼지만,
각 기술 하나하나 다룰내용이 많은 기술들입니다. 해당 기술들은 앞으로 작성될 글에서 더 자세하게 다뤄보겠습니다.

이어서

본 글에서 다양한 키워드가 소개되었습니다.
MSA, 모놀리스, Rest, gRPC, kafka, Saga, Cloud Native...
해당 키워드는 이어지는 글에서 MSA에 대해 상세히 다뤄보며 더 알아보겠습니다.

Reference

• MSA 이해와 구현방법 (사내강의)
• KT Enterprise - https://enterprise.kt.com/bt/dxstory/1007.do
• #2. 마이크로서비스 아키텍처, MSA가 주목 받고있는 이유 (tistory) - https://medium.com/twolinecode/2-마이크로서비스-아키텍처-msa가-주목-받고있는-이유-59092da625cd