Server, Microservice Architecture

Monolith Architecture

  • s/w의 모든 구성요소가 한 프로젝트에 통합
  • 소규모 프로젝트일때 많이 사용된다

왜?MSA를 사용하지?

  • 서비스가 커질수록 전체 시스템 구조 파악이 어렵다
  • 빌드시간, 테스트 시간, 배포시간이 기하급수적으로 증가된다
  • 서비스를 부분적으로 scale-out하기 힘들다
  • 부분의 장애가 서비스 전체의 장애로 연결된다

  • SOA의 부분집합이라고 할수 있다

MSA (Microservice Architecture)

  • 하나의 큰 어플리케이션을 여러개의 작은 어플리케이션으로 쪼개서 변경과 조합이 가능하도록 만든 아키텍쳐
  • 스스로 돌아갈 수 있는 + 독립적인 배포가 가능한
  • 각각의 서비스는 다른 서비스에 대한 의존성이 최소화 되어야 한다

장점

  • 서비스 복잡도 줄일수 있다
  • 변경에 따른 영향도 최소화
  • 서비스 별 개별 배포 가능 (배포 시 전체 서비스 중단이 없다)
  • 부분적 장애에 의한 전체 장애 확장 가능성 적다
  • 특정 서비스에 대한 확장성이 용이

단점

  • 여러 서비스의 엔드포인트 관리
  • 성능 ; 서비스 간 호출 시 API를 사용하기 때문에, 통신 비용, Latency 증가
  • 테스트/트랜잭션 : 서비스가 분리되어 있어 테스트와 트랜잭션 복잡도가 증가, 많은 자원이 필요
  • 데이터 관리 : 데이터가 여러 서비스에 걸쳐 분산되어 있어 한번에 조회하기 어렵다

Inner/Outer Architecture

가트너MSAComponent

  • Inner Architecture : 내부 서비스 쪼개기 / 비즈니스,서비스 특징에 따라 표준없이 알아서 잘 정해야한다

Outer Architecture

1. External Gateway
2. Service Mesh
3. Container Management
4. Backing Services
5. Telemetry
6. CI/CD Automation

1. External Gateway (API Gateway)

apigateway

  • client대신 요청하고, client에게 요청을 전달하는 proxy 역할
  • 서버 앞단에서 모든 API 서버들의 엔드포인트를 단일화 해주는 서버
  • 외부로부터 들어오는 접근을 내부 구조를 드러내지 않고 처리하기 위한 요소

    ESB가 SOAP/XML 기반의 무거운 기능을 가졌다면, API Gateway는 REST/JSON 기반으로 보다 가볍게 설계된 것이 특징입니다.

API Gateway 주요기능

1. 인증/인가

  • 각각의 서비스가 해야하는 인증/인가를 api Gateway에서 처리

    인증 : 유저가 누구인지 확인하는 절차 / 인가 : 접근권한 있는지 확인

2. 서비스 오케스트레이션

  • 오케스트레이션 : 여러개의 마이크로 서비스를 묶어 새로운 서비스 만드는 개념

API Gateway 생성예제

블로그 서비스 : 3개의 엔드포인트로 서비스 구성 apigateway

  • account : 블로그 사용자들의 계정 정보 관리 서비스
  • post : 블로그 글 관리 서비스
  • storage : 포스트 첨부파일 관리 서비스
DELETE /accounts/{account-id}
PUT /accounts/{account-id}
GET /accounts/{account-id}
POST /accounts

2. Service Mesh

serviceMesh

  • 서비스 구성 요소간의 N/W를 제어하는 역할
  • 트래픽 관리, 보안등
  • N/W기능을 비즈니스 로직과 분리한 N/W통신 인프라

3. Container Management

container-management-diagram

  • Kubernetes

4. Backing Service

messagequeue

  • 어플리케이션과 통신하는 리소스를 지칭
  • Message Queue를 활용하여 비동기적으로 통신하는 것을 지향한다

Message Queue

  • 비동기/약결합
  • Redundancy : 서비스가 실패해도, 재처리 가능
  • Resilence : 전체 시스템에 대한 영향이 적고, 회복 탄력성이 높다
  • 보장성 : 메시지 큐에 들어간 메시지는 최소 한번은 처리된다
  • 확장성 : 다수의 메시지 큐를 두어 많은 요청에 대해 유연하게 확장 가능

5. Telemetry

  • 서비스 모니터링, 서비스별 발생 이슈 대응 하는 환경 구성

6. CI/CD Automation

  • 지속 통합, 지속배포

참고