MSA(Micro Service Architecture) | JeongKeepsCalm

MSA(Micro Service Architecture)

MSA

서비스 구축 방법

  • 모놀로식
    • 모든 비지니스 로직이 하나의 프로젝트에 들어있다.
  • MSA
    • 각각의 비지니스 로직을 분리하여 개별 프로젝트로 개발한다.
    • 가장 앞단에서 API Gateway를 통해 각 서비스에 요청을 분산하여 관리한다.

MAS 장단점

  • 장점
    • 서비스별 스케일링 가능
    • 서비스별 다른 프레임워크로 사용 가능
    • 하나의 서비스가 OFF 되더라도 나머지 서비스 동작 가능
    • 부분적으로 로직 업데이트 가능
  • 단점
    • 초기 구성의 난이도
    • 서버간 호출 비용
    • 분산 관리

MAS 요소

  • 서비스 로직
  • 게이트웨이
  • 모니터링 서버
  • 변수관리 서버

스프링 MSA 모식도

  • Spring Cloud Gateway: SCG
    • URL 주소에 대해서 아래 세부 경로에 따라 각각의 스프링 부트 어플리케이션에 분배하는 분배기 역할을 수행
  • Spring Cloud Eureka Server
    • Eureka Client 설정을 해둔 서버를 Eureka Server에 띄워준다.
    • 각 어플리케이션이나 Gateway가 활성화되어 있는지 확인하는 모니터링 서버
    • Spring Cloud Gateway에 목록을 전달하여 Gateway가 로드밸런싱 대상을 설정하도록 작업을 한다.
  • Spring Cloud Eureka Client
    • Eureka Server에 등록되는 요소로 스프링 부트 어플리케이션과 같은 여러 스프링 프레임워크 서버에 설정이 가능하다.
  • Spring Config Server
    • 변수 값들을 제공하는 서버로 특정 경로로 접근하면 미리 사전에 설정해둔 변수 값들을 제공 받을 수 있다.
    • MSA를 구축하면 각각의 스프링 부트 어플리케이션에 yml / properties에 값을 명시하는 것이 아닌 config server로 부터 데이터를 받아서 사용한다.
  • Config Repository
    • Config Server는 단순하게 데이터를 전달하는 매개체로 실제 데이터는 Config Server 뒷단에 깃허브 리포지토리와 같은 저장소를 물려서 사용한다.

Config Repository

Config 저장소의 종류

  • Git Service(github, gitlab, git bucket)
  • Redis
  • RDB
  • Document NoSQL
  • File …

깃허브 레퍼지토리 생성

  1. private 레퍼지토리 생성
  2. creating a new file
    • 이름-환경.yml
    • e.g. ms1-dev.yml
  3. 비대칭 키 생성(Spring Cloud Server가 생성된 private 레퍼지토리에 접근하기 위함)
    • Public Key: 깃허브 레퍼지토리에 등록
    • Private Key: Spring Cloud Server에 저장(데이터를 가져오기 위해 증명에 필요)
    • bash환경에서 Public & Private Key 생성
    • ssh-keygen -m PEM -t rsa -b 4096 -C “fdsafdsafdsanwelwn2132ssle2sfsnedfs” - Public Key 복사 > 깃허브 레퍼지토리 Settings > Deploy keys > add Deploy keys: 키 붙여넣기

Config Server

private 깃허브 레퍼지토리 접근

  1. 깃허브 레퍼지토리 ssh 주소
  2. 생성한 private key 복사
  3. 새 프로젝트 생성(Config Server 용도)
    • config-server, spring security 의존성 추가
    • @EnableConfigServer
    • yml 파일 변수 설정(privateKey 추가 등..)
  4. 시큐리티 설정(Config Server로의 외부 접속 차단)
  5. 프로젝트 빌드 후, http://IP:Port/이름/환경

Config Client

  • 서비스 로직 수행하는 스프링 부트 어플리케이션
  • 스프링 부트 어플리케이션에 Config Client 설정을 해줘서 Config Server에서 보내주는 데이터를 받는다.
  • Config Client 의존성 추가 후, yml 파일에 Config Server를 바라보게 설정한다.

Eureka Server

  • Eureka Server
    • MSA를 구성하는 서비스들을 모니터링
    • 가동되는 모든 Config Client의 모든 서버 정보를 목록으로 가지고 Cloud Gateway에 해당 목록을 전달한다.
  • 구현 방법
    • Eureka Server, Spring Security 의존성 추가
    • @EnableEurekaServer 추가(Eureka Server로 동작하기 위한 어노테이션)
    • 환경파일 설정
    • 시큐리티 설정

Eureka Client

  • 각 어플리케이션을 Eureka Client 로 등록하여 Eureka Server 가 관리하게 한다.
    • Eureka Discovery Client 의존성 추가
    • @EnableDiscoveryClient 추가
    • Eureka 서버와 연결(yml 파일)

Spring Cloud Gateway

  • Spring Cloud Gateway란?
    • MSA 제일 앞단에서 클라이언트의 요청을 받아 경로와 조건에 알맞은 마이크로 서비스 로직에 요청을 전달한다.
    • 무중지 상태로 모든 요청을 받아야하기에 설정이 까다롭다.
  • Spring Cloud Gateway 특성
    • 논 블로킹 방식으로 동작하는 WebFlux 프레임워크와 네티엔진 사용
  • 구현 방법
    • gateway 의존성 추가
    • 마이크로 서버 어플리케이션 2개 준비
    • 환경설정(yml / class)

Gateway & Eureka

  • Gateway & Eureka 연동 이유
    • 서비스 디스커버리: 각 서비스의 위치를 동적으로 발견하고, 게이트웨이가 이를 기반으로 요청을 적절한 서비스로 라우팅할 수 있다.
    • 자동 스케일링 지원: 각 서비스 인스턴스의 추가 및 제거를 감지하고, 게이트웨이가 이를 기반으로 동적으로 라우팅을 조정할 수 있다.
    • 로드 밸런싱: 각 서비스의 인스턴스를 파악하고, 게이트웨이가 이를 기반으로 로드 밸런싱을 수행할 수 있다.
    • 서비스 상태 모니터링: 각 서비스의 상태를 모니터링하고, 게이트웨이가 이를 기반으로 요청을 건강한 서비스 인스턴스로 라우팅할 수 있다.
  • Gateway & Eureka 연동 방법
    • Gateway 서버에 Eureka Client 의존성 추가하여 연동
    • 설정파일에서 같은 url 접근시 라우팅 유레카 로드 밸런싱이 가능하다.

Actuator를 활용한 라우팅

  • Actuator
    • gateway 동작 중에 서버를 멈추지 않고 라우팅을 추가한다. (예를 들어 msa 하나를 추가할 때 gateway를 중지하지 않고 서버 하나를 추가시킨다.)
  • 구현 방법
    • Spring Boot Actuator 의존성 추가
    • 설정파일
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      
        # 일단 msa 1개만 설정 
        spring:
          cloud:
            gateway:
              routes:
                - id: ms1
                  uri: http://localhost:8081
                  predicates:
                    - Path=/ms1/**
      
        # Actuator 설정
        management:
          endpoint:
            gateway:
              enabled: true
          endpoints:
            web:
              exposure:
                include: gateway
      
    • 라우팅 명령어
      • 존재하는 라우팅 확인
        • GET: /actuator/gateway/routes
      • 라우터 추가
        • POST: /actuator/gateway/routes/{id}
          1
          2
          3
          4
          5
          6
          
            {
                "predicate": "Paths: [/msa/**]",
                "filters": [],
                "uri": "http://localhost:8082",
                "order": 0
            }
          
      • 리프레쉬(라우터 추가/제거 시 리프레쉬 필요)
        • POST : /actuator/gateway/refresh
      • 라우터 제거
        • DELETE : /actuator/gateway/routes/{id}
      • 특정 라우터 확인
        • GET : /actuator/gateway/routes/{id}
      • 글로벌 필터 목록
        • GET : /actuator/gateway/globalfilters
      • 특정 라우터 필터 목록
        • GET : /actuator/gateway/routefilters/{id}

Filter

  • Gateway Global Filter
    • 모든 라우팅에 대해서 적용되는 필터
    • 주로 로깅, 인증, 권한 검증 등의 작업
  • Gateway Local Filter
    • 특정 ms에 적용되는 필터
    • 특정 서비스에 대한 요청 변환, 응답 변환, 특정 헤더 추가 등의 작업
  • 모든 요청은 기본적으로 한 필터당 pre, post 각각 한 번씩 총 2번 필터를 거친다(설정으로 변경 가능)