개요
- MSA 전체 구성 요소에 대해 파악한다
- MSA 구성을 위한 외부 아키텍처 구성 요소를 자세히 알아본다
MSA 구성 요소
- 크게 외부 아키텍처, 내부 아키텍처로 구분
- Monolithic 구조에서 MSA로 변화하면서 관리포인트가 늘어남에 따라 관련된 운영 시스템이 필요하게 됨 (Auto scailing, Logging, Monitoring, CI/CD)
- MSA를 도입하기 위해서는 외부 아키텍처의 DevOps, Cloud 인프라에 대한 이해 필요
외부 아키텍처 인프라 패턴
- MSA 구성을 위한 시스템 아키텍처
1. CI/CD
- DevOps 인프라
- Cloud 인프라에서 자동 배포 시스템 CI/CD 구성하는 환경이 더 효율적이게 되었음
- Jenkins에 테스트케이스 코드를 통과하는지 여부를 확인하는 과정을 넣거나 소나큐브로 정적분석 결과 리포팅을 연동할 수 있음
- 배포 파이프라인
- Repository → Build / Unit test → 정적 분석 → 통합 테스트 → 배포 → 마이크로서비스
2. Container Orchestration (k8s의 컨테이너 관리)
- 컨테이너 환경 서버 관리
- 컨테이너 오케스트레이션 대비 필요
- 매니저 노드 → 워커노드 1,2,…
- 같은 이미지에서 생성된 컨테이너의 집합을 Replica라고 함
- 쿠버네티스 환경
- 위와 같은 Replica를 자동 스케줄링 해주기 위해 사용
- Deployment 파일로 Pod(≒Container와 유사한 개념)의 Replica Set 구성
- Pod은 부가적인 기능을 사이드카 컨테이너로 제공
- Replica set
- 정해진 수의 동일한 Pod이 항상 실행되도록 관리
- Deployment
- Pod과 Replica set을 한번에 설정 가능
- 무중단 배포를 위한 롤링업데이트 기능을 제공
- revision 관리를 통한 배포 장애 시 이전 버전으로 자동 롤백
- Service
- Pod를 연결하고 외부에 노출시킴
- 여러 개의 Pod에 접근할 때 요청을 분산하는 로드밸런서 기능 수행
- O’REILLY 에서 쿠버네티스 테스트 환경을 지원
- Ingress
- URL로 라우팅 및 로드밸런싱 해주는 도구
- 위의 "쿠버네티스 리소스" 페이지의 라우팅에 해당
- Config 패턴
- 가변적인 환경 설정 값을 컨테이너의 재배포 없이 적용할 수 있는 방법
- 컨테이너 이미지 안에 config파일을 담지 않음
- Configmap - 설정값
- Secret - 비밀값 (암호화 기능)
- 쿠버네티스 설정 시 이러한 값을 설정할 수 있음
- 쿠버네티스 배포 전략
- Rolling Update와 Blue/Green 전략을 주로 사용
3. 중앙화 - Logging, Tracing, Metric, Circuit Breaker
- Logging
- 컨테이너는 Imutable. 죽으면 새로 만들기 때문에 로컬 로그는 소멸되므로 ELK Stack같은 로그 중앙화 도구가 필요함
- ELK Stack
- E - 분석엔진, 데이터베이스
- L - 로그 집합기 → 요즘은 Filebeat씀
- K - 대시보드
- Tracing
- 서비스 간 호출이 일어날 때 구간 모니터링 및 분석 (지연 구간 및 장애 포인트 체크)
- 예) Zipkin, Spring Cloud Sleuth, Jaeger
- Trace Id 및 Span Id(구간1,2,3)를 전달
- Circuit Breaker
- 장애 격리를 위한 장치
- Spring Cloud Circuit Breakers + Resilience4J or Netflix Hystrix
- REST 요청 시 임계치 이상의 예외가 발생했을때 Fallback? 해주는 처리
- 위 처럼 서비스 하나하나 서킷브레이크 처리를 할 수도 있고 쿠버네티스 환경 같은 경우에는 서비스 메쉬 단위로 서킷브레이크를 적용할 수 있음
- Metric
- 상태 정보(CPU, Memory) 및 네트워크 사용량 등 모니터링
- k8s + Prometheus + Grafana
4. MSA 관리 및 운영을 위한 플랫폼 패턴
- 필요 배경
- 기존 Monolithic 구조로는 대규모 트래픽에 있어서 문제점이 발생하기 시작(L4, L7 로드밸런서에 계속 늘어나는 인스턴스)
- 모듈형 Monolithic → Microservice화 됨
- Microservice의 문제점 - Cascading failure 발생
- Netflix OSS 탄생하여 위 문제점 관리하는 오픈소스가(Eureka?) 생김. tech blog 참고
- Spring Cloud 아키텍처
- BFF
- API Gateway
- 비즈니스 로직이 들어가지 않음
- 공통 인증 인가 처리
- 각 기능을 지원하는 여러 솔루션을 사용하여 아래 역할을 추가하여 활용함
- 라우팅 & 로드밸런싱
- 라우팅 :서비스가 올라가는 컨테이너의 IP정보가 고정되어 있지 않기 땨문에 이런 서비스 이름과 IP 정보를 매핑하여 보관할 저장소 필요
- 라우팅 라이브러리 예: Zuul
- 로드밸런싱 라이브러리 예: Ribbon
- 서비스 레지스트리 라이브러리 예: Eureka
→ 스프링 클라우드 등장으로 통합 기능 제공?
- 서비스 탐색
- A 마이크로 서비스에서 B 마이크로 서비스를 호출해야 한다고 할 때, Pod 그룹을 관리하는 서비스 인스턴스 B에 대한 정보를 서비스 레지스트리(예:Eureka)에서 관리하기 때문에 서비스 인스턴스의 엔드포인트? 를 알기 위해서는 A→ B 직접 호출이 아닌 API Gateway 를 통해 호출하는 방식으로 진행된다.
- 인증과 인가
- 인증 : 내가 누구인가?
- 인가 : 내가 어떤 권한을 가지고 있는가?
- MSA에서 인증/인가 처리 방법
- 개별 마이크로 서비스마다 인증인가 로직 추가 → 수정사항 발생 시 각각 다 수정해야하는 불필요함 발생
- 별도의 인증/인가 서비스 인스턴스를 통하도록 하는 방법 → 네트워크 latency 늘어나게 됨
- Gateway에서 공통 처리
- Stateless - JWT
- Stateless는 인증은 게이트웨이에서, 인가는 개별 마이크로서비스에서 처리함
- Stateful - Session clustering
- Stateful은 상태를 갖기 때문에 BFF나 게이트웨이에서 처리를 하고 Redis에서 세션에 접근
- 일반적인 인증 방법
- Config 관리
- 클라우드 플랫폼에 갖춰야 할 조건
- 데이터베이스 등 접속 정보에 대한 정보들은 어플리케이션에 독립적으로 운영하기 위해 코드와 분리해서 관리해야함
- Spring Cloud Config 지원
- 쿠버네티스에서는 ConfigMap, Secret을 사용
