Outer Architecture와 Inner Architecture의 이해

Inner Architecture vs Outer Architecture

Outer Architecture : MSA가 운영되는 환경을 정의, 예시는 아래와 같다.

우리가 생각하는 일반적인 인프라 아키텍처 구조라고 할 수 있다.

Inner Architecture : 실제 비즈니스가 실행되는 각 MSA내 구조를 정의한 아키텍처이다.

Inner Architecture는 위에서 설명한 Outer Architecture와는 다른 차이점이 있는데 차이점으로는 위에서 설명한 Outer Architecture는 인프라 기반의 아키텍처를 설명한 반면 Inner Architecture는 실제 비지니스가 실행되는 구조를 정의한 것이다.

내부 서비스와 관련된 architecture. 쉽게 말해 내부 서비스를 어떻게 잘 쪼개는지에 대한 설계이다.

고려사항

MSA를 어떻게 정의할 것인가?
비즈니스나 시스템의 특성에 따라 여러 기능들을 같은 서비스에 넣을 것인지, 여러 기능들을 다른 서비스에 넣을 것인지를 정의해야 한다.

DB Access 구조를 어떻게 설계할 것인가?

MSA가 사용하는 데이터는 일반적으로 일관된 API를 통해서 접근한다. 또한 각 마이크로 서비스는 자체 데이터베이스를 가질 수 있는데 일부 비즈니스 트랜잭션은 여러 MSA에 걸쳐서 존재하기 때문에 각 서비스에 연결된 데이터베이스의 정합성을 어떻게 보장해줄 수 있는지 고려해야 한다.

그렇다면 MSA내에 API를 어떻게 설계할까?

Outer Architecture와 External Gateway

외부로부터 들어오는 접근을 내부 구조를 드러내지 않고 처리하기 위한 요소이다 즉, 사용자 인증, 권한 정책 관리를 수행하며 API Gateway가 가장 핵심적인 역할을 수행한다고 볼 수 있다. API Gateway는 서버 가장 앞단에 위치하며 받은 API 호출을 인증한 후, 적절한 서비스에 메세지 전달이 되도록 한다. LB 역할을 수행한다고 볼 수 있고, 실제로 EKS 에서는 ALB, Ingress 에서 직접 컨트롤을 수행한다.

Service Mesh

MSA 구성 요소 간 네트워크를 제어하는 역할을 한다. 

service discovery, service routing, 트래픽 관리 및 보안 등을 담당한다.

Container Management

컨테이너 기반 운영은 유연성과 자율성을 장점으로 가져 MSA에 적합하다고 평가 받고 있다.
대표적으로 Kubernetes가 많이 사용되고 있으며, Container 기반의 운영을 위해서는 요즘 추세로는 k8s가 필수라고 보여진다.

Backing Service

어플리케이션이 실행되는 동안 네트워크를 통해 사용할 수 있는 모든 서비스를 말한다.
DB, Cache System, SMTP 서비스 등 어플리케이션과 통신하는 모든 Resource를 말한다고 볼 수 있다.
MSA의 Backing Service 중 핵심 서비스는 Messeage queue이다. MSA는 메세지의 송신자와 수신자가 직접 통신하는 것 보다 카프카 등의 서비스를 활용하여 Message Queue를 비동기적으로 통신하는 것을 지향한다.
이러한 구조를 사용하기 때문에 하나의 서비스가 죽어도 전체 서비스가 죽지 않는다.

Telemetry

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

대표적으로는 그라파나와 프로메테우스와 같은 서비스들이 존재한다.

CI/CD Automation

애플리케이션 개발 단계를 자동화 하여, 어플리케이션을 보다 짧은 주기로 고객에게 제공하는 방법이다.
지속적인 통합(Continuous Integration), 지속적인 전달(Continuos Delivery), 지속적인 배포(Continous Deployment)가 CI/CD의 기본개념으로서 보통 k8s에서 이미지를 자동으로 배포하고 업데이트 하여 소스를 최신의 상태로 유지한다.