MSA 마이크로서비스 아키텍처(Microservice architecture) 정리

MSA 마이크로서비스 아키텍처(micro service architecture) 정리

 - 아키텍처란? -> 건축학 -> 최적화
    문제 영역에 대한 솔루션을 제공하는것 

 - 시스템 아키텍처
  최적화를 목표로 두고 시스템 구성과 동작원리, 시스템의 구성환경등을 설명 및 설계하는 청사진 또는 설계도

 - 프로그램 최적화
  컴퓨터 과학에서 시스템을 수정하여 어떠한 면의 작업이 더 효과적으로, 또는 자원을 덜 사용하도록 만드는 작업을 말한다. 

마이크로서비스 외부 아키텍처 
  - 클라우드 인프라 패턴 -> 마이크로서비스를 지탱하는 하부구조 인프라를 정의하는 패턴
  - 플랫폼 패턴 -> 인프라 위에서 마이크로서비스를 운영 관리를 지원하는 플랫폼 차원의 패턴들

마이크로서비스 내부 아키텍처
- 마이크로서비스 관계 패턴 -> 마이크로서비스 유형 간의 관계를 정의하는 패턴들
- 마이크로서비스 내부 패턴 -> 마이크로서비스 내부의 구조를 정의하는 패턴들

1. 클라우드 인프라 패턴
- 유연하고 확장성 있는 인프라 영역 구성
- 가상인프라(쉽게 확장 가능)
- 베어 메탈과 클라우드 제품들
- 가상머신(vm) vs 컨테이너
- 마이크로서비스 같은 작은 서비스를 패키지하고 배포하기에 컨테이너(도커)가 적합하다. 
- 컨테이너 오케스트레이션(Orchestration) => 컨테이너를 관리하기 위한 기술 -> 도커 스웜(docker swarm)
- 구글에서 나온 쿠버네티스 -> 사설 컨테이너 플랫폼 환경을 구축할 수 있음
- 데브옵스 인프라(DevOps Infra)구성
    I. 개발과 운영이 분리되지 않는 개발, 운영을 병행 할 수 있는 조직, 그러한 문화
    II. 빠르고 높은 품질로 소프트웨어를 개발 지원하는, 빌드, 테스트, 배포를 위한 자동화 환경
- 자동화된 빌드, 배포 작업
    I.  CI = 지속적 통합(Continuous Integration) 
         - 개발자가 퇴근 시에 매일 자신이 작성한 소스 코드와 그것을 테스트한 테스트 코드를 형상 관리해 체크인(Check-in)
         - 빌드 도구에서 형상 관리 서버의 코드를 가져와서 (Check-out)
         - 매일 밤 결과를 리포트 문서로 남기고 빌드 된 소스를 실행 환경에 자동으로 배포
         - 다음날 테스터가 실행 환경에서 테스트를 바로 실행 
         - 자동으로 통합, 테스트 하고 그 결과를 리포트로 남기는 활동을 CI
   II.  CD = 지속적 배포(Continuous Deployment and Continuous Delivery)
         - Continuous Delivery = 지속적 전달은 빌드 된 소스 코드의 실행 파일을 실행 환경 반영 전 단계까지 배포하는 방식
             실행 환경 반영을 위해서는 승인 및 배포 담당자의 허가를 받아야 배포할 수 있으며 배포도 수동으로 처리
         - Continuous Deployment = 소스 저장소에 빌드 된 소스 코드의 실행 파일을 실행 환경까지 자동으로 배포
  III. 배포 파이프라인 설계
         - 인프라 구성을 마치 소프트웨어를 프로그래밍하는 것처럼 처리하고 소수의 인원으로 많은 컨테이너 배포 처리를 할 수 있게 함
            =>Infrastructure as Code

 

2. 플랫폼 패턴

- 스프링 클라우드 : 스프링부트 + 넷플릭스 OSS
=> 모든 마이크로서비스는 인프라의 종속되지 않기 위해 DB, File등 환경 설정 정보를 형상 관리에 연계된 
   Config서비스에서 가져와서 설정정보 주입
=> 로딩과 동시에 서비스 레지스터 서비스에 자신의 서비스명과 클라우드 인프라부터 할당 받은 물리 주소를 매핑하여 등록
=> 클라이언트가 마이크로서비스를 API게이트웨이를 통해 접근하고 이때 API게이트웨이는 적절한 라우팅 및 부하 관리를
   위한 로드 밸런싱 처리를 한다. 
=> 이때 서비스레지스트리 검색을 하여 서비의 위치를 가져온다.
=> 또한 API 게이트웨이는 이때 각 서비스접근을 위해 권하서비스와 연계해 인증/인가 처리를 한다.
=> 그리고 이러한 모든 마이크로서비스는 모니터링되고 추적된다. 


3. Service registry, Service discovery 패턴

   서비스 디스커버리 패턴
      - 클라이언트가 여러 개의 마이크로서비스를 호출하기 위해서 최적 경로를 찾아주는 라우팅 기능과, 
      적절한 부하 분산을 위한 로드 벨런싱 기능이 제공되어야함
       ex) 넷플릭스 OSS에서 라우팅기능 = 줄(Zuul), 로드벨런싱 = 리본(Ribbon)
       - 라우터 = 최적 경로를 탐색하기 위해 서비스명칭에 해당되는 IP주소를 알아야한다.

   서비스 레지스트리 패턴
    - 라우팅 정보를 클라이언트가 가지고 있지 않고 제 3의 공간에서 정보를 관리해 주는것
    - 백엔드 마이크로서비스 서비스 명칭과 유동적인 IP 정보를 매핑하여 보관할 저장소가 필요함
      ex) 넷플릭스 OSS유레카 => 서비스 레지스트리 패턴

4. 서비스 단일 진입을 위한 API 게이트웨이(gateway) 패턴

- 클라이언트가 여러 개의 서버 서비스를 각각 호출하게 된다면 매우 복잡한 호출 관계가 생성됨
- 이를 통제하기 위한 방법이 API 게이트웨이.
- API 게이트웨이가 어플리케이션 레벨의 라우팅 기능과 여러 인스턴스로 부하를 분산하는 로드밸런싱 처리도 수행


5. BFF(Backend For Frontend) 패턴

- 특화 클라이언트를 위해서 특화된 처리를 위한 API조합과 처리가 필요함
- 프론트 엔드를 위한 백 엔드
- 각 프론트엔드 에 관한 처리 만을 위한 BFF를 두고 이후에 통합적인 API GW를 두고 공통적인 인증/인가 처리

6. 외부 구성 저장소 패턴

- Spring Cloud Config 를 사용하면 이러한 환경정보를 코드에서 분리하여 컨피그 서비스를 런타임에 주입
- 환경 정보는 GIT같은 별도의 형상관리 레파지토리에 보관되고 컨피그 서비스는 해당 서비스에 특정 환경에
  배포될 때 적절한 환경 정보를 형상관리 레파지토리에 가져와서 해당 서비스에 주입한다.

7. 마이크로서비스 인증/인가 패턴

- 중앙 집중 식 세션 관리
=> 기존 모노리스 방식 서버 세션에 사용자의 로그인 정보 및 권한 정볼르 저장해 인증/인가 판단 
=> 마이크로서비스는 서비스에 세션을 저장하지 않고 공유 저장소에 세션을 저장함
=> 세션 저장소는 레디스(Redis), 맴캐쉬드(Memcached)를 사용함

- 클라이언트 토큰
=> 세션은 서버의 중앙에 저장되고, 토큰은 사용자의 브라우저에 저장됨
=> JWT(Json Web Token)은 토큰 형식을 정의하고 암호화 하며 다양한 언어에 라이브리를 제공
- 브라우저가 서버에 로그인이름과 패스워드로 인증을 요청함
- 서버는 인증후 토큰을 생성하고 브라우저에 토큰에 사용자 정보의 인증/인가 정보를 포함해 전송함
- 브라우저는 서버 리소스 요청 시 토큰을 같이 보낸다. 서버의 서비스는 토큰 정보를 확인후 자원
  접근 허용함