Spring Cloud + MSA 애플리케이션 개발 1(Microservice & Spring Cloud 소개)

Microservices 란?

• 각각의 서비스에 대한 관심사에 따라 하나의 서버는 하나의 관심사를 갖고 서비스들이 모여 하나의 커다란 궁극적 서비스를 이루는 아키텍처

Cloud Native Architecture

Cloud Native Architectrue 4가지의 핵심 요소

1. DevOps
2. CI/CD
3. Contatiners
4. Microservices

Cloud Native Architecture 3가지의 기본 핵심

1. 확장 가능한 아키텍처
   -> 시스템의 수평적 확정에 유연
   -> 확정된 서버로 시스템의 부하 분산 , 가용성 보장
   -> 컨테이너 기반 패키지
   -> 모니터링

2. 탄력적 아키텍처
   -> 서비스 생성 - 통합 - 배포 , 비즈니스 환경 변화에 대응 시간 단축
   -> 분활된 서비스 구조
   -> 무상태 통신 프로토콜
   -> 서비스의 추가와 삭제 자동으로 감지
   -> 변경된 서비스 요청에 따라 사용자 요청 처리 (동적 처리)

3. 장애 결리
   -> 특정 서비스에 오류가 발생해도 다른 서비스에 영향 주지 않는다.

12 Factors

• Cloud Native Application을 개발하거나 서비스를 운영할 때 고려해야할 항목 12개
• BASE CODE , DEPENDENCY ISOLATION , CONFIGURATIONS , LINKABLE BACKING SERVICES , STAGES OF CREATION , STATELESS PROCESSES , PORT BINDING , CONCURRENCY , DISPOSABLITY , DEVELOPMENT & PRODUCTION PARITY , LOGS , ADMIN PROCESSES FOR EVENTUAL PROCESSES
• +3 까지 더한 것도 있는 버전도 있다. (API first , Telemetry , Authentication and authorization)

Monolith vs Microservice Architecture

Monolith Architecture

• 모든 업루 로직이 하나의 애플리케이션 형태로 패키지 되어 서비스
• 애플리케이션에서 사용하는 데이터가 한 곳에 모여 참조되어 서비스되는 형태
• 문제점은 시스템의 일부만 바꿔도 전체 애플리케이션을 다시 빌드하고 테스트를 해야한다.

Microservice

• 하드웨어에서 강점을 가지는 부분은 C , C++ 를 사용하고 AI 를 활용한 빅데이터를 처리하는 부분은 Python 을 사용하고 비동기 처리를 하는 부분은 NodeJS 를 사용하는 이러한 것도 가능하다.
• 프로그래밍 언어 뿐만 아니라 DB 종류도 각 상황에 맞춰서 선택할 수 있다.

Front & Back

• Monolith 와 Microservice 의 중간정도인 Front 부분과 Back 부분을 나눠서 개발하는 방식도 많이 사용한다.
• Microservice 는 Front & Back 을 나누지만 Back 에서도 Product Service , Payment Service 처럼 또 나눠지고 , DB 또한 나눠진다.

Microservice 의 특징

• 독립적으로 배포 가능한 형태의 작은 서비스로 이루어진다.
• REST API 사용
• 환경 설정 정보는 외부에서 관리 권장
• Dynamic Scale Up And Scale Down
• CI/CD
• 시각화

모든 애플리케이션을 Microservice 로 만드는것이 정답이 아니다.

• Life Cycles 이 독립적인가?
• 독립적으로 확장할 수 있는가?
• 오류상황이 독립적인가? (오류에 최소한에 영향을 받으면서 다른 서비스로 우회할 수 있는가)
• 외부 종속성과 상호작용을 단순화시킬 수 있는가?
• 여러가지 프로그래밍 언어(Polyglot) 기술을 지원하는가?
• 위에 있는 질문을 충분히 준비되어 있다면 도입할만 하다.

Microservice Team Structrue

• Two Pizza team (피자 2판을 먹을 수 있는 인원이 가장 적합)
• 개발 , 테스트 , 운영을 독립적으로 서비스할 수 있어야 한다.

SOA vs MSA

• SOA (Service Oriented Archltiecture)
• MSA (Micro Service Archltiecture)

서비스의 공유 지향점

• SOA : 재사용을 통한 비용 절감
• MSA : 서비스 간의 결합도를 낮추어 변화에 능동적으로 대응
  -> API 를 통해서 데이터를 요청해야 하며 회원가입 서비스에 문제가 생겼다고 해도 결제 서비스에는 직접적인 문제가 발생하지 않고 우회할 수 있는 서비스
• 즉 MSA 는 서비스 공유를 최소화 하고 , SOA 는 서비스 공유를 최대화 한다.

SOA 와 MSA 와의 차이점 (기술방식)

• SOA : 공통의 서비스를 ESB (Enterprise Service Bus) 에 모아 사업 측면에서 공통 서비스 형식으로 서비스 제공
• MSA : 각 독립된 서비스가 노출된 REST API 를 사용
• MSA 는 REST API 통신을 통해서 Service 에 접근하고 SOA 는 Service Bus 를 통해서 Service 에 접근을 한다.

결론적으로 SOA 와 MSA는 서비스를 공유를 어디까지 하는지 , Service 를 어떻게 사용하는가의 차이가 있다.

• MSA 는 예를 들어 Customer 에서는 JAVA+Redis 를 사용하고 Order 에서는 NodeJS + MongoDB 를 사용하고 Shopping Cart 는 .NET+MySQL 을 사용할 수 있다.

각 서비스는 Kafka 를 통해 데이터 동기화를 한다.

• 하나의 데이터베이스에 어떠한 자료가 변경이 된다면 Kafka 로 전달 한다.
• 카프카에서는 이 데이터에 관심 있어했던 서비스들에게 지금 등록된 데이터를 전달해준다.
• 예를 들어 Customer 에서 자료가 바뀐다면 카프카는 이 자료를 Order , Shopping Cart 에게 넘겨주면 Order , Shopping Cart 는 자신의 DB 에 업데이틑 한다.

*클라이언트가 요청한 데이터가 없을떄 : 404 에러*

Microservice Architecture Structures

MSA 는 독립적으로 배포되고 확장될 수 있는 서비스들을 조합해서 하나의 거대한 어플리케이션을 구성하는 아키텍처 패턴

Functional Components of a Microservice Platform, 2018 by Gartner

클라이언트들은 API Gateway 라는 진입점을 통해 서비스 요청을 한다.

• API Gateway 는 Service Router 로 이동을 하고 여기에서 어디로 가야할지 결정한다.
• Service Discovery 에 물어본다. (어디에 존재하는지도)
• 어디로 가야할지 결정됐다면 해당 Microservice 로 이동하는데 여거래의 Instance 가 있을 수 있기 떄문에 Load Balancing 으로 결정한다.
• Microservice 에서 사용하는 환경 설정 정보는 COnfig Stroe 에 저장을 한다.
• Microservice 는 컨테이너 가상화를 통해서 구성이 된다.
• 완성된 애플리케이션은 CI/CD Automation 기술을 사용
• 외부에 있는 시스템에 배포 -> 해당 기술은 DevOps 들이 사용할 수 있게 API 가 공개되어 있을 것
• Telemerty 에는 진단 또는 모니터링 기능이 있다.
• Backing Services 에는 MS 에 저장되어 있는 다양한 스토리스 , 메시징 처리 시스템 존재

Serivce Mesh

• 위에 그림을 보면 Service Mesh 부분이 있다.
• 프록시 역할 , 권한 부여 , 암호화 , 서비스 검색 , 요청 라우팅 , 로드 밸런식
• 자가 치유 복구 서비스
• 서비스간의 통신과 관련된 기능을 자동화
• 추상적인 개념

MSA 기반 기술

1. Gateway : NGINX , KONG 등
2. Resilient Service Mesh / Meta Services
3. Runtime : docker , kubernetes , aws lambda 등
4. Frameworks : SpringBoot , Spring Cloud , Flask 등
5. Automation : Gradle , maven , Jenkins 등
6. Backing Services : kafka , redis , cassandra
7. Telemetry

Spring Cloud 란?

• 환경 설정 관리, 서비스 검색 , 회복성 처리, 라우팅 , 프록시 기타 등등의 필요한 분산 시스템 빠르게 어플리케이션 개발을 하는데 목적
• 그 중에서 Config , Netflix , Security , Security , Sleuth , Starters , Gateway , OpenFeign 를 사용해서 프로젝트 진행 예정

Spring Cloud 에서 사용할 프로젝트

Centralized configuration management

• Spring Cloud Config Server 사용

Location transparency

• Naming Server (Eureka)

Load Distribution (Load Balancing)

• Ribbon
• Spring Cloud Gateway

Easier REST Clients

• FeignClient

Visibility and monitoring

• Zipkin Distributed Tracing
• Netflix API gateway

Fault Tolerance

• Hystrix

참고자료