728x90
12Factors +3
Cloud Native Application 개발 하거나 서비스를 운영할 때 사용되는 항목들
- BASE CODE
- 자체 레퍼 지토리에 저장된 각 마이크로 서비스에 대한 단일 코드 베이스, 버전을 관리하기 위한 목적이고 형상관리를 위해 코드를 한 곳에서 배포하기 위한 목적, 코드의 통일적 관리
- DEPENDENCY ISOLATION(종속성)
- 마이크로서비스는 자체 종속성을 가지고 패키지 되어 있다. 전체 시스템에 영향을 주지 않고 변경되 고 수정 될 수 있어야 한다.
- CONFIGRATIONS(구성정보)
- 시스템 내부가 아닌 시스템 코드 외부에서 구성관리 도구를 통해서 마이크로서비스에 필요한 작업들을 지원 하는 것. 동일한 배포가 올바르게 구성된 환경에 배포 될 수 있다.
- LINKABLE BACKING SERVCIE(서비스 지원)
- DB 캐시 메시지큐잉 등 마이크로서비스가 가져야 할 기능들을 추가로 지원하는 것 을 말한다. 프로그램 자체에서 필요한 서비스를 분리 함으로 써 서로 상호작용하고 코드 디펜던시를 가지지 않은 상태에서 작업을 할 수 있다.
- STAGES OF CREATION (운영환경 분리)
- 개발부터 운영까지 엄격하게 분리 되어야 하며 각각은 고유한 태그를 가지고 있어야 하며 롤백기능을 가지고 있어야한다.
- STATELESS PROCESSES (독립성)
- 각각의 마이크로서비스는 실행중인 다른 서비스와 분리된 상태로 운영 될 수 있어야 한다.
- PORT BINDING
- 각각의 마이크로서비스는 자체 포트에서 노출되는 인터페이스 및 기능 과 함께 자체 기능이 있어야 한다. 이런 방법을 사용하면 다른 마이크로서비스와 격리가 가능하다.
- CONCURRENCY(동시성)
- 많은 수의 수 많은 서비스를 동일한 프로세스를 복사해 확장해 나간다. 하나의 인스턴스가 동일한 서비스로 복사가 되어 운영 됨으로써 부하분산을 이루어 낼 수 있다.
- DISPOSABILITY
- 서비스 인스턴스 자체가 삭제가 가능해야 한다. 확장 기회를 높혀야 하고 정상적으로 종료를 할 수 있어야 한다.
- DEVELOPMENT & PRODUCTION PARTY
- 5번과 비슷한 개념
- 서비스 인스턴스를 등록/삭제/확장/종료 가능해야 함
- LOGS
- MS에 의해 생성된 로그를 관리하는 도구 필요
- ADMIN PROCESSES FOR EVENTUAL PROCESSES
- 현재 운영되고 있는 마이크로서비스에 대한 리소스 및 환경을 관리할 수 있는 관리도구 가 있어야 한다. 리포팅, 데이터정리 데이터 분석 등이 있어야 한다.
- API FIRST
- API를 구축함에 있어서 사용자 측에서 어떤 형태로 쓸 것인가 먼저 고민
- TELEMENTRY
- 개발 관리자 항목과 유사
- 모든 지표는 수치화, 시각화되어 관리할 수 있는 항목
- AUTHENTICATUOIN AND AUTHORIZATION (인증)
- 마이크로서비스 간에 분리가 되어 있더라도 적절한 인증을 거치거나
- 외부시스템에서는 데이터를 전달하고 교환하는 작업이 가능해야한다.
Monolithic vs. Microsevice
- Monolithic
- 모든 업무 로직이 하나의 애플리케이션 형태로 패키지 되어 서비스
- 애플리케이션에서 사용하는 데이터가 한곳에 모여 참조되어 서비스되는 형태
- 어느 한 서비스를 수정 및 변경하려면 모든 서비스를 전체적으로 다시 패키징하여 배포해야한다는 단점
- MicroServices
- 어플리케이션을 구성하는 각각의 구성요소 및 서비스의 내용을 분리해서 개발하고 운영하는 방식
- 각각의 용도에 맞는 컨테이너를 연결하여 만드는 방식
- 특징
- 모노리스 방식에 비해 유지보수나 변경사항을 적용하는데 유리하다.
- HTTP Resource API 통신을 할 수 있는 작은 규모의 여러 서비스들의 묶음 → 이게 모여 하나의 어플리케이션이 된다.
- 이러한 서비스들은 비즈니스 기능을 중심으로 구축되어야 한다.
- 완전하게 자동화 된 배포 시스템을 사용해야 한다(CI/CD)
- 각각의 서비스들은 최소한의 중앙 집중식 관리가 되어야 한다.
- 서로 다른 프로그래밍 언어와 서로 다른 데이터 베이스를 사용할 수 있다.
- Monolith vs Front&Back vs MSA
Microservice Architecture란?
- MicroService 특징
- Challenges - 기존방식에서 상당 수 많은 부분을 변경 해야 한다.
- Small Well chosen Deployable Units - 독립적으로 배포 가능한 형태의 작은 서비스로 이루어진다.
- Bounded Context - 서비스의 경계를 잘 구분해야하며, 이 서비스 경계로 인한 두 개의 서비스가 하나의 서비스가 되기도 함
- RESTful - 각 서비스들은 서로 상태에 대해 REST API로 통신해야한다.
- Configuration Management - 마이크로서비스와 관련된 설정 정보들은 코드 내에 있는게 아니라 외부에 두어 관리한다.
- Cloud Enabled - 클라우드 네이티브 기술을 최대한 활용해서 서비스 제공
- Dynamic Scale Up And Scale Down - 인스턴스들의 부하분산을 Scale Up이나 Scale Down 등을 동적으로 처리할 수 있어야 한다.
- CI/CD - 자동화 된 배포 시스템
- Visibility - 마이크로서비스와 관련된 것들을 시각화해서 관리할 수 있어야 한다.
- MicroService 적합성
- Multiple Rated of Change - 기존개발 대비 어느 정도 변화가 생길 것 인가
- Independent Life Cycle - 어플리케이션이 동작하는 서비스 들이 독립적으로 운영될 수 있도록 경계가 잘 구성되어 있는가.
- Independent Scalability - 독립적인 확장성 이 가능한가.
- Isolated Failure - 격리된 오류
- Simplity Interaction with External Dependencies - 외부 종속성과의 상호작용을 단순화 시켜야 한다.
- Polyglot Technology - 여러 가지 프로그래밍 언어와 같이 쓸 수 있게 지원
SOA vs. Microservice
서비스 공유 지향점
공통점
service 제공
차이점
SOA : 재사용을 통한 비용 절감
MSA : 서비스 간의 결합도를 낮추어 변화에 능동적으로 대응
기술방식
SOA : 공통의 서비스를 ESB에 모아 사업 측면에서 공통 서비스 형식으로 서비스 제공
MSA : 각 독립된 서비스가 노출된 REST API를 사용
RESTful 성숙도 모델
- Consumer first : 소비자 입장에서 간단 명료하고 직관적인 API를 설계해야 함
- Make best use of HTTP : HTTP Method와 header값 등의 HTTP의 장점을 최대한 살려서 개발
- Request methods
- GET
- POST
- PUT
- DELETE
- Response Satus : API 요청에 따라 적절한 응답 코드를 보내줘야 함
- 200번대 : 클라이언트의 요청이 정상적으로 처리됨
- 400번대 : 클라이언트쪽에서 발생된 오류
- 500번대 : 서버쪽에서 발생된 오류
- No sevure info in URI
- Use plurals : 복수 형태의 uri 사용
- prefer /users/1
- User nouns for resoureces : 모든 리소스는 되도록 명사 형태로 표현
- For exceptions
- define a consistent approach : 일관된 endpoint를 사용하는 것이 좋음
- PUT /gists/{id}/star
- DELETE /gists/{id}/star
Microservice Architecture Structures
MSA 표준 구성요소
- 마이크로서비스는 독립적으로 배포되고 확장될 수 있는 서비스들을 조합해서 거대한 어플리케이션을 구성하는 아키텍쳐 패턴
- 넷플릭스, 트위터, 아마존, 나이키 등의 회사에서 채택한 아키텍처로서 소개되면서 주목받음
- 요청 전달 흐름
- 다양한 디바이스나 다른 마이크로서비스의 요청이 API Gateway를 통해 한 곳으로 모아진다.
- 수집된 요청들을 Service Router에게 전달하고, Service Router는 Service Discovery에서 목적기 관련 정보를 찾는다.
- 목적지를 찾았다면 Load Balancing을 통해 마이크로 서비스들(진한 남색 표시)에게 요청을 전달한다.
- Backing Service
- 마이크로 서비스에 저장되어 있는 다양한 스토리지들을 모아서 사용할 수 있는 방법
- MOM(Message-oriented middleware) : 메시징 처리 시스템을 통해 하나의 서비스와 다른 서비스 연결
Service Mesh Capabilities
- Service Mesh
- 하나의 제품이나 서비스를 지칭하는 것이 아니라 추상적인 개념
- 서비스 메시 계층에서 다양한 기능과 서비스를 제공함으로써 안정적이고 효율적인 마이크로 서비스 운영을 지원하는 데에 목적
- MSA 인프라 → 미들웨어
- 프록시 역할, 인증, 권한 부여, 암호화, 서비스 검색 요청 라우칭, 로드밸런싱
- 자가 치유 복구 서비스
CNCF(Cloud Native Computing Foundation)
CNCF를 통해서 가지고 잇는 독립적인 구성요소가 어떤 제품, 어떤 구성으로 되어 있는지 간단하게 볼 수 있다.
서로 interacive하게 상호 연관될 수 있는 서비스들이 어떤 게 있는 표시
Cloud Native Interctive Landscape
간단하게 핵심적인 제품만 봐보자.
Spring Cloud
Spring Cloud를 이용해서 어플리케이션을 구출하려고 할 때 기본적으로 어떤 서비스가 사용되는지(사용할 프로젝트)
- Centralized configuration management(환경 설정 관리) → Spring Cloud Config Server
- 다양한 마이크로서비스에서 사용할 수 있는 환경 정보들(gateway IP, token 등)을 Spring Cloud Config Server를 통해 외부 저장소(Git 등)에 보관 할 수 있다. → 유지관리 편하다.
- 환경 정보들을 외부 저장소가 아닌 내부에 하드 코딩으로 저장하게 되면 설정이 변경될 때마다 재배포를 해야한다.
- Location transparency → Naming Server(Eureka)
- 서비스의 등록과 위치정보 확인 검색과 같은 기능 사용
- Load Distribution(Load Balancing) → Ribbon(Client Side), Spring Cloud Gateway
- 최신 스프링 클라우드 이전 : Ribbon, 넷플릭스의 줄 사용
- 최신 스프링 클라우드 : Gateway 사용
- NamingServer : 마이크로서비스뿐만 아니라 게이트웨이 서비스도 네이밍 서버에 등록 해놓고 위치를 검색하는 용도로 사용
- Easier REST Clients → FeignClient
- 마이크로서비스 간의 통신을 위해 사용
- Visibility and monitoring(시각화, 모니터링) → Zipkin Distributed Tracing, Netflix API gateway
- Fault Tolerance → (넷플릭스의) Hystrix
- 장애가 발생했을 시 복구를 위한 회복성 패턴
출처 : inflearn - Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA)