2. MSA의 이해
2.1 리액티브 선언: 현대 애플리케이션이 갖춰야 할 바람직한 속성들
리액티브 선언문
응답성 (Responsive) : 사용자에게 신뢰성 있는 응답을 빠르고 적절하게 제공
탄력성 (Resilient) : 장애가 발생하거나 부분적으로 고장 나더라도, 시스템 전체가 고장 나지 않고 빠르게 복구하는 능력
유연성 (Elastic) : 시스템 사용량에 비례해서 자원을 늘리거나 줄이는 능력
메시지 기반 (Message Driven) : 비동기 메시지 전달을 통하여 위치 투명성, 느슨한 결합, 논블로킹 통신을 지향
2.2 강 결합에서 느슨한결합의 아키텍처로의 변화
클라우드 네이티브 컴퓨팅 재단 (CNCF)에서 제공하는 클라우드 네이티브 재형도
2.3 마이크로서비스의 외부 아키텍처와 내부 아키텍처
마이크로서비스 아키텍처
인프라 : 기반이 되는 하드웨어 인프라
플랫폼 : 애플리케이션을 운영 및 구동하기 위한 플랫폼
애플리케이션 : 서비스
MSA 외부 아키텍처
마이크로서비스가 운영되는 환경을 정의
인프라 영역과 플랫폼 영역, 애플리케이션 영영에 있는 구성요소 및 그것들의 관계를 정의
MSA 내부 아키텍처
실제로 비즈니스가 실행되는 비즈니스 애플리케이션 정의
마이크로서비스가 제공하는 API, 비즈니스 로직, 이벤트 발행, 데이터 저장 처리 등을 어떻게 구조화해야 하는가를 정의
2.4 MSA 구성요소 및 MSA 패
아키텍처 패턴
문제 영역에 대해 여러 사람들에 의해 검증되어 정리된 유용한 해법
아키텍처 스타일이라고도 함
마이크로서비스 아키텍처에도 이 같은 패턴이 존재
크리스 리처드슨 (Chris Richardson : 소프트웨어 아키텍트)
마이크로서비스 아키텍처 패턴을 아래와 같이 분류
인프라 패턴
애플리케이션 인프라 패턴
애플리케이션 패턴
MSA 구성요소 및 패턴의 유형
인프라 구성요소 : 마이크로 서비스를 지탱하는 인프라를 구축하는 데 필요한 구성 요소
플랫폼 패턴 : 인프라 위에서 마이크로 서비스의 운영과 관리를 지원하는 플랫폼 차원의 패턴
애플리케이션 패턴 : 마이크로 서비스 애플리케이션을 구성하는 데 필요한 패턴
2.4.1 인프라 구성요소
IT 업계에서의 ‘인프라’
엔터프라이즈 IT환경을 운영하고 관리하는데 필요한 근간이 되는 것 모두 포함
하드웨어, 소프트웨어, 네트워킹 구성요소, 운영체제, 데이터 스토리지
클라우드 환경에서는 이러한 인프라 구성요소가 가상화 되어 제공
퍼블릭 클라우드와 베어메탈, 프라이빗 클라우드 환경
플랫폼
AWS, Google, 마이크로소프트, IBM
서비스
IaaS (Infrastructure as a Service)
PaaS (Platform as a Service)
시스템의 자원 구성, 자원 할당, 자원 관리, 모니터링 등
VM과 컨테이너
가상 머신
하이퍼바이저라는 소프트웨어를 이용해 하나의 시스템에서 여러 개의 운영체제 사용
게스트 OS 유
이는 운영체제 패치 설치나 관련 라이브러리 같은 오버헤드 발생
컨테이너
장점
이식성 : 어떤 호스트 커널이나 플랫폼 버전에 상관없이 도커만 실행 가능하면, 사용 가능하며 동일하게 동작
신속성 : 크기가 작고 가벼워 빠른 배포가 가능하며, 문제 발생 시 수정 필요 없이 새로 기동하면 됨
재사용성 : 동일한 환경을 재사용해서 쉽게 설정 가능하기 때문에 대발, 테스트, 스테이징, 프로덕트 환경을 동일한 환경으로 구축하기 용이
마이크로서비스 같이 독립적으로 배포되고 수정되기 위한 환경은 가상 머신보다는 컨테이너가 더 적절
Docker가 유명.
레이어 단위의 이미지를 포개는 방식
애플리케이션 구동을 위한 기반 이미지, 운영체제, 런타임, 애플리케이션 이미지
가상 머신 제품군
AWS EC2, Azure VM
컨테이너 기술
Docker, Unlikernels, LXD, OpenVZ, RKt
컨테이너 오케스트레이션
컨테이너 관리를 위한 기술
필요성
컨테이너가 많아질수록 그에 따른 컨테이너 자동 배치 및 복제, 장애 복구, 확장 및 축소, 컨테이너 간 통신, 로드 밸런싱 등으 컨테이너 관리를 위한 기능 필요
도구
도커 스윔, 아파치 메소스, 쿠버네티스
컨테이너 배포의 기본 단위
파드, 디플로이먼트, 레플리카셋
쿠버네티스 주요 기능
자동화된 자원 배정
셀프 치유
수평 확장
2.4.2 마이크로서비스 운영과 관리를 위한 플랫폼 패턴
개발 지원 환경 : 데브옵스 인프라 구성
Devops
서비스를 빌드하고 테스트한 뒤 배포할 수 있게 도와주는 개발 지원 환경
개발과 운영이 분리되지 않은 개발 및 운영을 병행할 수 있는 문화
여기서는 빌드, 테스트, 배포를 위한 자동화 환경
수동 배포 절차
개발 환경에서 애플리케이션을 완성하고, 컴파일 하고 수동으로 테스트한 후 발생한 오류를 수정한 뒤 스테이징 환경에 배포
운영 환경에 배포하기 전에 스테이징 환경에서 다시 수동으로 테스트. 그러다 오류가 발생하면 첫 환경인 개발환경으로 돌아와 오류를 수정한 뒤 스테이징 환경에서 다시 체스츠 수행
이 과정이 무사히 끝나면 배포 승인을 받고 승인 완료 후 배포 담당자가 애플리케이션 운영 환경에 배포
단점
많은 시간 소요 → 비즈니스 민첩성이 없음
CI/CD
자동화된 빌드나 배포 작업
CI
지속적 통합
자동으로 통합 및 테스트하고 그 결과를 리포트로 기록하는 활동
CD
지속적 제공
빌드된 소스코드의 실행 파일을 실행 환경에 반영하기 전 단계까지 진행하는 방식
자동 빌드 및 배포 절차
개발자들이 퇴근할 때 매일 자신이 작성한 소스코드와 그것을 테스트한 테스트 코드를 형상관리 시스템에 보냄(Push)
빌드 도구에서 매일 밤 형상관리 서버의 코드를 가져와 (Pull) 통합한 다음, 자동으로 빌드하고 테스트 코드를 실행해 테스트를 수행
테스트 수행 결과를 리포트 문서로 기록하고, 빌드된 소스코드를 스테이징 환경에 자동 배포
다음날 테스터가 스테이징 환경에서 테스트 수행. 또는 빌드 단위 테스트 결과를 개발자가 확인하고 문제가 있다면 즉시 소스코드를 수정
빌드/배포 파이프라인 설계
빌드/배포 파이프라인
빌드/배포되는 동안 수행해야 할 태스크가 정의된 것
통합 및 배포까지 이어지는 일련의 프로세스를 하나로 연계해서 자동화하고 시각화된 절차로 구축하는 것
빌드/배포 파이프라인 설계
어떤 단계를 거치고 어떤 도구로 그 단계를 구성할지 결정
빌드, 단위 테스트, 정적 분석, 배포 과정
어떠한 도구를 활용할지 결정하고, 도구 사이의 연계 방법을 정의
IaC (Infrastructure as Code)
인프라 구성을 코드로 프로그래밍하여 처리
형상관리 리포지토리에서 소스코드를 가져와 빌드해서 실행 파일을 만드는 작업
실행 파일을 실행 환경에 배포하는 작업
이런 작업들을 통제하고 연결해서 전 작업이 성공하면 다음 작업이 자동으로 수행되게 하는 연계 자동화 작업
MSA 시스템
마이크로서비스는 각각 별도의 리포지터리를 가지고 있고 독립적으로 수정 및 빌드, 배포
마이크로서비스 생태계와 운영 관리 요소의 탄생
운영 관리를 위한 요소란
배포된 마이크로서비스가 실제로 구동되는 환경에서 문제 없이 동작될 수 있게 해줌
넷플릭스는 모노리스에서 마이크로서비스 아키텍쳐로 전환하며 여러 문제점을 겪음.
그 결과로 다양한 서비스와 도구를 개발
넷플릭스 OSS :
줄 (Zuul), 리본 (Ribbon) : 여러 마이크로서비스 간의 라우팅과 로드 밸런싱
히스트릭스 (Hystrix) : 모니터링
유레카 (Eureka) : 서비스 등록
. . .
결론적으로 AWS의 클라우드 환경, 도커 컨테이너, 넷플릭스가 공유한 오픈소스, 스프링 프레임워크, 구글의 쿠버네티스 같은 것들이 마이크로서비스 생태계의 발전을 이끔
경험으로 획득한 지혜 : 마이크로서비스 관리/운영 패턴
넷플릭스 OSS : 마이크로서비스를 개발하고 운영하면서 생긴 노하우를 다른 사람들도 쉽게 사용할 수 잇도록 공유한 오픈소스
스프링 클라우드 (Spring Cloud) : 넷플릭스 OSS 모듈들을 스프링부트에서 잘 돌아갈 수 있도록 스프링 프레임워크로 감쌈
스프링 클라우드: 스프링 부트 + 넷플릭스 OSS
스프링 클라우드 : 스프링 프레임워크를 개발하고 있는 피보탈에서 넷플릭스가 공개한 줄, 유레카, 히스트릭스, 리본 등의 넷플릭스 오픈소스를 스프링 부트 프레임워크 기반으로 사용하기 쉽게 통합한 것
모든 마이크로서비스는 인프라에 종속되지 않도록 데이터베이스, 파일 등에 저장된 환경 설정 정보를 형상관리 시스템에 연계된 ‘Config 서비스'에서 가져와 설정 정보를 주입한 후 클라우드 인프라의 개별 인스턴스로 로딩
로딩과 동시에 ‘서비스 레지스트리’에 자신의 서비스명과 클라우드 인프라부터 할당받은 물리 주소를 매핑해서 등록
클라이언트가 ‘API 게이트웨이'를 통해 마이크로서비스에 접근하고, 이때 API 게이트웨이는 적절한 라우팅 및 부하 관리를 위한 로드 밸런싱을 수행
또한 API 게이트웨이는 클라이언트가 마이크로서비스에 접근하기 위한 주소를 알기 위해 ‘서비스 레지스트리’ 검색을 통해 서비스의 위치를 가져옴
동시에 API 게이트웨이는 클라이언트가 각 서비스에 접근할 수 있는 권한이 있는지 ‘권한 서비스'와 연계해 인증/인가 처리를 수행
이러한 모든 마이크로서비스 간의 호출 흐름은 ‘모니터링 서비스’와 ‘추적 서비스'에 의해 모니터링 되고 추적됨
다양한 서비스의 등록 및 탐색을 위한 서비스 레지스트리, 서비스 디스커버리 패턴
줄 (Zuul)
라우팅 기능
리본 (Ribbon)
로드밸런싱 기능
라우터는 최적 경로 탐색을 위해 서비스 명칭에 해당하는 IP주소를 알아야 함
라우팅 정보를 클라이언트가 가지고 있는데, 그러면 클라우드 환경에서 동적으로 변경되는 백엔드의 유동 IP 정보를 매번 전송받아 변경해야 함 → 비효율적
제 3의 공간에서 이러한 정보를 관리 → 효율적
즉 백엔드 마이크로서비스 서비스의 명칭과 유동적인 IP정보를 매핑해서 보관할 저장소 필요
넷플릭스 OSS의 유레카(Eureka)
서비스 레지스트리 패턴
각 서비스 인스턴스가 로딩될 때 자신의 서비스 이름과 할당된 IP 주소를 레지스트리 서비스에 등록
클라이언트가 해당 서비스명을 호출할 때 라우터가 레지스크리 서비스를 검색해 해당 서비스의 이름과 매핑된 IP 정보를 확인 후 호출
이 레지스트리 서비스는 모든 마이크로서비스의 인스턴스의 주소를 알고 있는 매핑 저장소가 됨
모든 마이크로서비스가 처음 기동할 때 자신의 위치 정보를 저장하고 종료될 때 위치 정보가 삭제
서비스 레지스트리에는 업무 처리를 위한 마이크로서비스뿐 아니라 관리와 운영을 위한 기반 서비스의 주소도 함께 보관. (Config 서비스, 모니터링 서비스, 추적 서비스도 모두 이름을 가지고 있기 때문에 주소를 가지고 있어야 함)
서비스 단일 집입을 위한 API 게이트웨이 패턴
문제 : 여러 클라이언트가 여러 개의 서버 서비스 호출하게 되면 매우 복잡
해결 : API 게이트웨이
다양한 서비스에 접근하기 위해 단일 진입점을 만들어 놓음
다른 유형의 클라이언트에게 서로 다른 API 조합을 제공할 수 있음
각 서지스에 접근할 때 인증/인가 기능을 한 번에 처리 가능
서비스 흐름 제이를 위한 서비스 라우팅 기능은 L4같은 하드웨어 장비로도 구현 가능하고 소프트웨어로도 구현할 수 있음
소프트웨어로 구현할 경우
API 게이트웨이가 애플리케이션 레벨의 라우팅 기능을 수행
여러 인스턴스로 부하를 분산하는 로드 밸런싱도 수행
라우팅 시 필터를 둬서 라우팅 전과 후에 각각 수행되는 선행 처리와 후행 처리, 에러 처리를 손쉽게 구현 가능
API 게이트웨이
레지스크리 서비스와 연계한 동적 라우팅, 로드 밸런싱
보안 : 권한 서비스와 연계한 인증/인가
로그 집계 서비스와 연계한 로깅. 예: API 소비자 정보, 요청/응답 데이터
메트릭(Metrics). 예: 에러율, 평균/최고 지연시간, 호출 빈도 등
트레이싱 서비스와 연계한 서비스 추적. 예: 트래킹 ID 기록
모니터링 서비스와 연계한 장애 격리 (서킷 브레이커 패턴)
이러한 API 게이트웨이 패턴은 스프링 클라우드의 스프링 API 게이트웨이 서비스라는 제품으로 구현 가능
(스프링 게이트웨이 서비스는 스프링 웹사이트에서 내려받아 간단한 스프링 애너테이션 설정으로 적용 가능)
다른 클라우드 플랫폼에서도 이러한 API 게이트웨이 패턴을 지원하느데, 쿠버네티스의 경우 자체 기능인 쿠버네티스 서비스와 인그레스 리소스로 제공
BFF 패턴
목적 : 다양한 클라이언트를 위해 특화된 처리를 위한 API 조합 구현
API 게이트웨이와 같은 진입점을 하나로 두지 않고 프런트엔드의 유형에 따라 각각 두는 패턴
외부 구성 저장소 패턴
애플리케이션 구성 정보 설정 관련 패턴
문제
데이터베이스 연결 정보, 파일 스토리지 정보 같은 내용을 애플리케이션에 포함하면 변경 시 반드시 재배포를 해야함. 이 경우 서비스를 중단해야하는 문제.
여러 마이크로서비스가 동일한 구성 정보를 사용하는 경우에도 일일이 변경하기가 번거롭고, 일부 마이크로서비스의 구성 정보가 불일치할 수도 있음
외부 저장소 패턴
애플리케이션이 배포되는 환경이 매번 달라지기 떄문에 코드에서 사용하는 환경 설정 정보는 코드와 완전히 분리되어 관리해야 함
스프링 컨피그
환경 정보를 코드에서 분리하고 컨피그 서비스를 통해 런타임 시 주입 가능
환경 정보는 Git 같은 별도의 형상관리 리포지토리에 보관하고 컨피그 서비스는 해당 서비스에 특정 환경에 배포될 떄 적절한 환경 정보를 형상관리 리포지토리에서 가져와 해당 서비스에 주입
쿠버네티스에서는 이러한 외부 구성 저장소 패턴을 쿠버네티스 컨피그맵으로 제공
인증/인가 패턴
마이크로서비스에서의 인증/인가 처리
중앙 집중식 세션 관리
클라이언트 토큰
API 게이트웨이를 사용한 클라이언트 토큰
장애 및 실패 처리를 위한 서킷 브레이커 패턴
모니터링과 추척 패턴
중앙화된 로그 집계 패턴
MSA 기술 변화 흐름
서비스 메시 패턴
2.4.3 애플리케이션 패턴
UI 컴포지트 패턴 또는 마이크로 프런트엔드
마이크로서비스 통신 패턴
저장소 분리 패턴
분산 트랜잭션 처리 패턴
읽기와 쓰기 분리 : CQRS 패턴
API 조합과 CQRS
쓰기 최적화 : 이벤트 소싱 패턴
Last updated
