Microservices Architecture

Microservices Architecture Components

MicroService Architecture는 Inner Architecture와 Outer Architecture로 구분할 수 있다.

---

Inner Architecture

Inner Architecture는 내부 서비스와 관련된 아키텍처이다.

Inner Architecture에서 고려해야 할 부분

• 서비스를 어떻게 정의할 것인가?
  • 쇼핑몰에서 주문하기 부분과, 카트에 넣기 기능을 같은 서비스로 넣을 것인지, 다른 서비스로 분리할 것인지는 그 비즈니스나 시스템의 특성에 따라 정의되어야 한다.
  • 서비스를 정의하기 위해 고려해야 할 사항은 비즈니스 뿐만 아니라, 서비스 간의 종속성, 배포 용이성, 장애 대응, 운영 효율성 등 굉장히 많다.
• DB Access 구조를 어떻게 설계할 것인가?
  • Microservice가 사용하는 데이터는 일반적으로 일관된 API를 통해서 접근한다.
  • 또한 각 마이크로서비스에는 자체의 데이터베이스를 가질 수 있는데, 일부의 비즈니스 트랜잭션은 여러 마이크로서비스를 걸쳐 있기 때문에, 각 서비스에 연결된 데이터베이스의 정합성을 보장해 줄 수 있는 방안이 필요하다.
• 서비스 내 API를 어떻게 설계할 것인가?
• 논리적인 컴포넌트들의 Layer를 어떠한 방식으로 설계할 것인가?
• 등등...

Inner Architecture는 비즈니스, 서비스, 시스템마다 각각의 특성이 있기 때문에 딱히 정해져 있는 표준이 없다.

따라서 이 부분은 MSA를 설계하는 데에 가장 어려운 부분이다.

---

Outer Architecture

Outer Architecture는 총 6개의 영역으로 분류하고 있다.

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

External Gateway

전체 서비스 외부로부터 들어오는 접근을 내부 구조를 드러내지 않고 처리하기 위한 요소이다.

사용자 인증(Consumer Identity Provider)과 권한 정책관리(policy management)를 수행하며, API Gateway가 여기서 가장 핵심적인 역할을 담당한다.

API Gateway는 서버 최앞단에 위치하여 모든 API 호출을 받은 후 API 호출을 인증하고 적절한 서비스들에 메세지를 전달될 수 있도록 한다. (routing)

Service Mesh

Service Mesh는 마이크로서비스 구성 요소간의 네트워크를 제어하는 역할을 한다.

서비스 간에 통신을 하기 위해서는 service discovery, service routing, 트래픽 관리 및 보안 등을 담당하는 요소가 있어야 한다.

Service Mesh는 위에 언급된 기능들을 모두 수행한다.

Container Management

컨테이너 기반 애플리케이션 운영은 유연성과 자율성을 가지며, 개발자가 손쉽게 접근 및 운영할 수 있는 인프라 관리 기술이기 때문에 MSA에 적합하다고 평가받고 있다.

 

대표적인 컨테이너 관리 환경인 Kubernetes가 Container management에 많이 사용되고 있다.

특히 AWS의 EKS, Google cloud platform의 GKE는 Kubernetes를 지원하는 클라우드 서비스로, 앞으로의 애플리케이션 운영 환경을 많이 변화시킬 것으로 예상되지만, 아직은 많은 개선이 필요한 서비스이다.

Backing Service

Backing Service는 애플리케이션이 실행되는 가운데 네트워크를 통해서 사용할 수 있는 모든 서비스를 말하며, MySQL과 같은 데이터베이스, 캐시 시스템, SMTP 서비스 등 애플리케이션과 통신하는 attached Resource들을 지칭하는 포괄적인 개념이다.

MSA에서의 특징적인 Backing Service들 중 하나는 Message queue이다.

MSA에서는 메세지의 송신자와 수신자가 직접 통신하지 않고 Message Queue를 활용하여 비동기적으로 통신하는 것을 지향한다.

 

만약 Message Queue를 사용하지 않는 강한 결합 구조의 경우, 여러 서비스를 걸치는 실시간 트랜잭션을 처리할 때, 하나의 서비스가 죽어버린다면 트랜잭션이 끊어지기 때문에 해당 서비스 요청을 보존할 수 없고 큰 에러가 발생하게 됩니다.

또한, REST 통신으로 트랜잭션 실패에 대한 처리를 구현하는 방법을 굉장히 복잡하다.

MSA에서 데이터 변경이나, 보상 트랜잭션과 관련된 처리는 Message Queue를 활용한 비동기 처리가 효율적이다.

Telemetry

Telemetry의 어원은 Tele(먼 거리) + metry(측정)이다.

즉, 실시간으로 먼 거리에서 원격으로 측정할 수 있다는 의미로 생각할 수 있다.

 

MSA에서는 상당수의 마이크로서비스가 분산환경에서 운영되기 때문에 서비스들의 상태를 일일이 모니터링하고, 이슈에 대응 하는 것은 굉장히 힘들고 오랜 시간이 걸린다.

Telemetry는 서비스들을 모니터링하고, 서비스 별로 발생하는 이슈들에 대응할 수 있도록 환경을 구성하는 역할을 한다.

CI/CD Automation

CI/CD는 애플리케이션 개발 단계를 자동화하여, 애플리케이션을 보다 짧은 주기로 고객에게 제공하는 방법이다.

지속적인 통합, 지속적인 전달, 지속적인 배포를 자동화하는 것은 배포가 잦은 MSA 시스템에 꼭 필요한 요소 중 하나이다.