본문 바로가기
Spring Boot/Spring Cloud

Microservice와 Spring Cloud

by 몰라닉네임 2023. 10. 17.

면접 가기 전 공부해야할 내용이기도 하다.

 

클라우드 네이티브
: 클라우드의 이점을 최대로 활용할 수 있도록 애플리케이션을 구축하고 실행하는 방식

 

Cloud Native Architecture 특징 

확장 가능한 아키텍쳐, 탄력적 아키텍쳐 , 장애처리 

확장 가능한 아키텍처

  • 시스템의 수평적 확정에 유연하다
  • 확장된 서버, 시스템 부하분산 가용성 보장 
  • 시스템 또는 서비스 어플리케이션 단위 패키지(컨테이너 기반)

탄력적 아키텍처

  • 서비스 생성-통합-배포, 비즈니스 환경 변화에 대응 시간 단축 (CI/CD 파이파라인을 통해서)
  • 분활된 서비스 구조
  • 무상태 통신 프로토콜
  • 서비스 추가 삭제 자동 감지
  • 변경된 서비스 요청에 따른 사용자 요청처리

장애처리

  • 특정 서비스 오류 발생해도 다른 서비스 영향 않는다.

Cloud Native Application

클라우드 네이티브 아키텍쳐 에 의해 설계되고 구현되는 애플리케이션이다.

 

마이크로 서비스로 개발

CI/CD에 의해 자동으로 통합/빌드/테스/배포 과정을 거친다. 

 

DevOps

  • Development + Operations + QA
  • 고객의 요구사항은 계속 변경될 수 있음 따라서 바로 수정이 가능하도록 구성하는게 중요
  • 끊임없는 피드백과 수정사항 반영으로 고객의 요구사항에 맞도록 제작

Containers

하나의 애플리케이션을 구성하는 마이크로 서비스들을 클라우드 환경에 배포하고 사용하기 위해서는 컨테이터 가상화 기술을 사용하게 된다. 

  • 컨테이너 가상화 => 클라우드 환경으로 이전해서 탄력적으로 시스템 환경 구성

 


 

12Fators 

더보기

:  Cloud Native Application 구축함에 있어 고려해야 할 12가지 요인

  • Host System (물리적 시스템) + Container Runtime(공용라이브러리) + Container(개별라이브러리)클라우드 네이티브를 개발하거나 고려할 사항 12가지요소
  • https://12factor.net
  • 12Fators
  1. Codebase
  • 버전제어, 형상관리 목적으로 코드의 통일적 관리가 필요
  1. Dependencies 종속성 
  • 전체 시스템에 영향을 주지 않고 변경 가능하도록 코드 구성
  1. Config
  • 시스템 외부에서의 구성관리 서비스로 환경설정 가능해야함
  1. Backing services
  • 추가적 기능 지원 가능하도록 분리해야함
  1. Build, release, run
  • 빌드, 배포, 실행환경의 분리필요
  1. Processes
  • 자체 프로세서에서 실행되어야함, 서로다른 마이크로 서비스끼리 분리되어실행되어야 한다
  1. Port binding
  • 노출 포트, 마이크로 서비스끼리 통신하는 포트가있어야 한다
  1. Concurrency
  • 하나의 서비스가 여러 인스턴스에 복제되어 부하 분산이 가능하도록 한다
  1. Disposability
  • 서비스 인스턴스 삭제가 가능하고, 확장성 및 정상 종료가 되어야 한다
    10.Dev/prod parity
  • 개발, 프로덕션 단계 구별 필요
    11.Logs
  • 서비스 도중 생성된 로그를 출력 정상작동 해야한다
    12.Admin processes
  • 운영되고 있는 모든 마이크로 서비스들의 대한 파악하기 위한 관리도구가 필요하다

 

12 Factors +3 :

  • 3개의 항목을 더 더한다(피보탈회사가 추가한 항목)
  1. API first
  • 사용자가 어떤 목적으로 사용할 것인지 API위주로 구성
  1. Telemetry
  • 시각화 필요
  1. Authentication and authorization
  • 인증 절차를 통해 관리되어야 한다

 


 

Monolithic vs Microservice

 

Monolithic Architecture와 MSA(Microservice Architecture)의 차이점에 대해 설명해 주세요.
더보기

모놀리식 아키텍쳐는 모든 시스템의 구성요소가 한 프로젝트에 통합되어 있는 하나의 통합된 패키지로 개발하는 방식입니다. 반면에, 마이크로 서비스는 1개의 시스템을 독립적으로 배포가능한 각각의 서비스로 분할하는 개별 서비스 단위로 개발하는 방식입니다. 때문에 마이크로 서비스는 개별 서비스 단위로 나뉘어져 있어서 해당 부분만 수정 또는 배포하기 좋고, 필요한 부분만 확장하기에도 용이하다는 장점이 있습니다.

 

Monolithic 방식

애플리케이션에 모든 필요한 구성 요소를 하나의 소프트웨어 안에 담아 개발하는 방식이다,

서로 의존성을 갖고 있음

  • 문제점
    • 시스템 일부만 수정하더라도 전체 시스템을 모두 재실행 시켜야 함
    • 다운타임이 필연적으로 발생한다

장점도 있다. 

더보기

모놀리식 아키텍처의 장점에는 다음이 포함됩니다.

 

손쉬운 배포 – 실행 파일 또는 디렉토리가 하나여서 배포가 더 쉽습니다.

개발 – 하나의 코드 베이스로 애플리케이션을 구축하여 개발이 더 쉽습니다.

성능 – 중앙 집중식 코드 베이스 및 리포지토리에서는 대부분 하나의 API만으로 마이크로서비스에서 여러 API가 수행하는 것과 동일한 기능을 수행할 수 있습니다.

테스트 간소화 – 모놀리식 애플리케이션은 하나의 중앙 집중식 장치이므로 분산된 애플리케이션보다 엔드투엔드 테스트를 더 빠르게 수행할 수 있습니다.

간편한 디버깅 – 모든 코드가 한 곳에 있으므로 요청을 따라가서 문제를 찾기가 더 쉽습니다.

Microservice란

 

마이크로서비스란 독립적인 서비스들의 모음이 경량화 API를 통해 통신하는 애플리케이션 아키텍처의 한 유형을 말한다.

클라우드네이티브에서 가져야할  4가지 조건

1.CI/CD

2.마이크로서비스

3. DevOps

4.컨테이너 기반

 

각각 구성하고 있는 어플리케이션 서비스등을 분리하여 개발, 배포

  • 최소한의 중앙 집중식 관리
  • 서로 다른 언어와 서로다른 데이터베이스가 사용 가능해야 한다특징
  • 프론트앤드 + 백앤드(프로덕트, 베스킷 페이먼트 ...등으로 각 서비스가 분리)

 


 

Microservice 특징

  • Challenges : 기존의 개발 방식이나 패러다임을 상당 수 바꿔야 한다. 
  • Small Well Chosen Deployable Units : 독립적으로 배포 가능한 형태의 작은 서비스로 이루어짐
  • Bounded Context : 서비스 경계를 잘 구분해야하며, 이 서비스 경계로 인해 두 개의 서비스가 하나의 서비스가 되기도 함
  • RESTful : 각 서비스들은 서로 상태에 대해 REST API로 통신해야한다.
  • Configuration Management : 마이크로서비스와 관련된 설정 정보들은 코드 내에 있는게 아니라 외부에 두어 관리한다.
  • Cloud Enabled : 클라우드 네이티브 기술을 최대한 활용해서 서비스 제공
  • Dynamic Sacle Up And Scale Down : 인스턴스들의 부하분산을 Sacle Up이나 Scale Down 등을 동적으로 처리할 수 있어야 한다.
  • CI/CD : 자동화 된 배포 시스템
  • Visibility : 마이크로서비스와 관련된 것들을 시각화해서 관리할 수 있어야 한

 

무조건 마이크로서비스로 개발되어야 하나 ?

NO

여러 조건 따져봐야함 ! 

 

단점 

더보기

복잡성, 설계의 어려움

- MSA는 모놀리식에 비해 상대적으로 많이 복잡하다. 서비스가 모두 분산되어 있기 때문에 개발자는 내부 시스템의 통신을 어떻게 가져가야 할지 정해야합니다. 또한, 통신의 장애와 서버의 부하 등이 있을 경우 어떻게 transaction을 유지할지 결정하고 구현해야한다.

 

2. 성능

- 서비스 간 호출 시 API를 사용하므로, 통신 비용이나 Latency에 대해 이슈가 존재한다.

 

3. 테스트/데이터 트랜잭션

- 모놀리식에서는 단일 트랜잭션을 유지하면 됐지만 MSA에서는 비즈니스에 대한 DB를 가지고 있는 서비스도 각기 다르고, 서비스의 연결을 위해서는 통신이 포함되기 때문에 트랜잭션을 유지하는게 어렵다
- 통합 테스트가 어렵다. 개발 환경과 실제 운영환경을 동일하게 가져가는 것이 쉽지 않다.

 

4. 데이터 관리

- 데이터가 여러 서비스에 분산되어 있어 조회하기 어렵다.

- 데이터를 관리하기 어렵다.

 

 

 


SOA(Service Oriented Architecture) vs MSA(Micro Service Architecture)

  • SOA : 재사용을 통한 비용 절감
  • MSA : 서비스 간의 결합도를 낮추어 변화에 능동적 대응

특징

SOA 는service bus 같이 한 곳에 서비스를 집중시켜 제공

MSA : API를 통해 개별 제공 


MSA 표준 구성요소

 

Client 

API Gateway로 요청 ->

서비스 라우터로 분배 ->

필요한 마이크로서비스가 어디에 저장되어있는지 서비스 디스커버리의 등록서비스에 물어봄->

로드밸런서를 바탕으로 인스턴스로 분배 ->

 

인스턴스는 백 서비스와 연동 ->

CI/CD를 통해 서비스 배포/업데이트 등등

 

서비스 매시

마이크로 서비스 아키텍처를 적용한 시스템 내부 통신을 말한다. 

서비스 메쉬를 통해 서비스간 통신을 추상화하고 안전하고 빠르고 신뢰성 있게 만들어 주는 인프라스트럭쳐 레이어이다.

 

 

 

 

 

 

Spring Cloud

 

  • 환경설정관리
    => Spring Cloud Config Server
  • 서비스 등록과 위치 정보 확인
    => Eureka(naming server)
  • 로드밸런싱 기능 제공
    => Ribbon(Client Side)
    => Spring Cloud Gateway(recommend)
  • REST
    => FeignClient
  • 시각화, 모니터링
    => Zipkin Distributed Tracing
    => Netflix API gateway
  • 장애복구
    => Hystrix
 

 

참고  

- https://hahahoho5915.tistory.com/71

- 인프런 Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA) 

 

'Spring Boot > Spring Cloud' 카테고리의 다른 글

API Gateway Service 1  (0) 2023.10.23
터미널로 gradle build 실행  (0) 2023.10.23
Service Discovery  (0) 2023.10.18
참고 velog & git  (0) 2023.10.17
Spring Cloud와 쿠버네티스  (0) 2023.10.16