Microservice와 Spring Cloud 소개

소프트웨어 아키텍쳐의 변화

1960 ~ 1980s: Fragile

• 모놀리식

1990 ~ 2000s

• 분산화

2010s ~

• 클라우드 네이티브

Anti-Fragile

• Auto scaling
• Microservices
• Chaos engineering
• Continuous deployments

Cloud Native Architecture

• 확장 가능한 아키텍처
  • 시스템의 수평적 확장에 유연
  • 확장된 서버로 시스템의 부하 분산, 가용성 보장
  • 시스템 또는 서비스 애플리케이션 단위의 패키지
  • 모니터링
• 탄력적 아키텍처
  • 서비스 생성-통합-배포, 비즈니스 환경 변화에 대응 시간 단축
  • 분활 된 서비스 구조
  • 무상태 통신 프로토콜
  • 서비스의 추가와 삭제 자동 감지
  • 변경된 서비스 요청에 따라 사용자 요청 처리(동적)
• 장애 처리
  • 특정 서비스에 오류가 발생해도 다른 서비스에 영향 주지 않음

Cloud Native Application

클라우드 네이티브 아키텍처로 구현된 어플리케이션, 다음과 같은 형태로 구현된다.

1. 마이크로 서비스로 구현
2. CI/CD로 빌드, 테스트, 배포됨
3. DevOps: 마이크로서비스에 문제가 생길 경우 수정 후 바로 배포할 수 있는 형태
4. Containers

DevOps

• Development + Operation, 개발 조직과 운영조직의 통합으로 고객의 요구사항을 빠르게 받아들여 개발함
• 클라우드 네이티브 구조는 작은 단위로 나눠 자주 통합, 배포할 수 있음

Container(가상화)

• 하드웨어, 서버 가상화에 비해 비용이 적게듬
• 컨테이너 가상화에서 리소스를 공유할 수 있음

 

Monolith vs MSA

Monolith

• 모든 업무 로직이 하나의 애플리케이션 형태로 패키지 되어 서비스
• 애플리케이션에서 사용하는 데이터가 한곳에 모여 참조되어 서비스되는 형태

문제점

• 시스템의 한 곳에 문제가 생기면 전체를 테스트, 빌드해야함

MSA

• HTTP 통신을 이용하여 작은 서비스들의 묶음
• 비지니스 서비스 기준으로 구축되어야함
• 완전하게 자동 배포되어야함
• 각각 서비스들은 최소화의 중앙 집중화되어야함
• 각자 다른 데이터와 프로그래밍 언어를 사용할 수 있음 => 각 서비스에 맞는 DB와 언어, 프레임워크를 선택하자

SOA vs MSA

서비스의 공유 지향점

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

기술방식

• SOA: 공통의 서비스를 ESB에 모아 사업 측면에서 공통 서비스 형식으로 서비스 제공
• MSA: 각 독립된 서비스가 노출된 REST API를 사용

Spring Cloud

• Spring의 Cloud 프로젝트
• Spring Boot가 필수

이번 프로젝트에서는

• Config 서버
• Location transparency(유레카)
• Load Distribution(Spring Cloud Gateway 사용)
• Easier REST Clients
• 모니터링
• Fault Tolerance(Hystrix)