표준 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 서비스 구현 실습을 진행해보겠습니다.