Microservice Architecture

Single Ko·2023년 10월 17일

msa

목록 보기

1/3

Cloud Native Architecture

cloud native architecture의 핵심인 Microservice

1. 확장 가능한 아키텍처

시스템의 수평적 확장에 유연 (Scale up, Scale out)
확장된 서버로 시스템의 부하 분산, 가용성 보장
시스템 또는, 서비스 애플리케이션 단위의 패키지(컨테이너 기반 패키지) - 가상화 기술
모니터링

scale up - 하드웨어의 사양을 높이는 것
scale out - 같은 사양의 서버를 여러 대 늘리는 것

2. 탄력적 아키텍처

서비스 생성- 통합-배포, 비지니스 환경 변화에 대응 시간 단축 - 분리되 개발된 애플리케이션
분활 된 서비스 구조
무상태 통신 프로토콜
서비스의 추가와 삭제 자동으로 감지
변경된 서비스 요청에 따라 사용자 요청 처리(동적 처리)

3. 장애 격리(Fault isolation)

특정 서비스에 오류가 발생해도 다른 서비스에 영향을 주지 않음
어느 시스템을 배포하더라도 다른 시스템에는 영향이 가지 않고 있기 때문에 괜찮음.

cloud navtive architecture 관련

Challenges
Small Well Chosen Deployable Units
Bounded Context
RESTful
Configuration Management
Cloud Enabled
Dynamic Scale Up And Scale Down
CI/CD
Visibility

모든 것을 마이크로서비로 개발해야 하나?

Q1) Multiple Rates of Change

Q2) Independent Life Cycles

Q3) Independent Scalability

Q4) Isolated Failure

Q5) Simplify Interactions with External Dependencies

Q6) Polyglot Technology

Microservice Team Structure

Two Pizza team
Teams communicating through API contracts
Develop, test and deploy each service independently
Consumer Driven Contract

12 Factors

코드 통합 - BASE CODE
- 버전 제어, 형상관리를 위해 코드를 한곳에서 관리하는 것이 목적
종속성 배제 - DEPENDENCY ISOLATION
- 각 마이크로 서비스는 자체 종속성을 가지고 패키지 되어 있어 전체 시스템에 영향을 주지 않은 상태에서 변경되고 수정할 수 있어야 한다.
환경설정의 외부관리 - CONFIGURATIONS
- 구성 정보, 코드 외부에서 구성 관리 도구를 통해서 마이크로 서비스에 필요한 작업들을 제어
서비스 지원 - LINKABLE BACKING SERVICES
- 보조 서비스(DB, Messaging)를 마이크로서비스가 가져야하는 기능을 추가 지원
개발 환경과 테스트 환경의 분리 - STAGES OF CREATION
- 이전 상태로 돌아가는 롤백 기능 지원, CI/CD 기능 지원 등...
상태 관리 - STATELESS PROCESSES
- 각각의 마이크로서비스는 실행중인 다른 서비스와 분리 된 체 각각의 서비스에 운영 될 수 있어야 한다. 독립적!, 필요한 자원은 캐시라던가 데이터 저장소를 이용해 외부와 데이터 동기화
포트 바인딩 - PORT BINDING
- 각각의 마이크로서비스는 자체 포트에서 노출되는 인터페이스및 기능과 함께 자체 포함되는 기능이 있어야 한다.
동시성 - CONCURRENCY
- 서비스는 가장 강력한 인스턴스로 확장하는 것 보다는 아주 많은 작은 수의 서비스를 동일한 프로세스를 복사해서 확장해 나간다. 하나의 서비스가 동일한 여러 서비스의 프로세스로 복사됨으로서 부하 분산을 이루어 낼 수 있다.
서비스의 올바른 상태 유지 - DISPOSABILITY
- 서비스 인스턴스 자체가 삭제가 가능해야 한다. 확장성 기화를 높여야 하며, 정상적으로 종료 할 수 있는 상태여야 한다.
개발과 운영환경의 구분 - DEVELOPMENT & PRODUCTION PARITY
- 운영프로그램의 수명주기 전반에 걸쳐 서비스에 직접 엑세스 하는 기능을 자제해서 다른 서비스에 종속되지 않는 상태로서 서비스를 유지할 수 있어야 한다
로그의 분리 - LOGS
- 마이크로서비스에 의해 서 생성된 어떤 로그를 이벤트 스트림으로 처리해야 한다. 기존의 시스템과 분리되서 시스템이 작동되지 않는 상태더라도 로그만은 정상적으로 작동할 수 있어야 한다.
- 별도의 모니터링 도구를 사용하기도 한다.
관리 프로세스 - ADMIN PROCESSES FOR EVENTUAL PROCESSES
- 현재 운영되고 있는 모든 마이크로서비스들을 파악하기위한 적절한 관리도구가 필요하다. 리포팅 할 수 있는 기능, 데이터 적립및 분석 기능.

12 Factors + 3

API first
- 마이크로서비스에 대해서는 API 형태로 구축. 사용자측에서 어떻게 쓸 것인가를 고민해서 개발해야 한다.
Telemetry
- 개발 관리자 항목과 유사. 모든 지표는 시각화 되서 관리할 수 있어야 한다
Authentication and authorization
- API를 사용함에 있어서 인증과 인가가 필수. 분리된 형태로 개발된다 하더라도, 인증을 가지고 있는 서비스라던가 외부 시스템에서는 데이터를 전달하고 교환하는 작업이 가능해 져야한다.

MSA vs Monolithic

Monolithic

하나의 소프트웨어 안에 전부 포함시켜 개발
비지니스로직 및 데이터 로직, 화면 로직까지 전부 하나의 애플리케이션에서 개발되고 의존
하나의 커다란 건축물
모든업무 로직이 하나의 애플리케이션 형태로 패키지 되어 서비스
애플리케이션에서 사용하는 데이터가 한곳에 모여 참조되어 서비스되는 형태

문제점

서비스 하나만 수정되어도 관계없는 전체 서비스 자체가 다시 패키징되어 배포되는 과정을 거쳐야 한다.

MSA(Microservices)

애플리케이션을 구성하는 각각의 서비스 및 요소를 분리해서 개발
유지보수나 변경사항을 적용하는데 유리하다
애플리케이션 전체가 다운되는 타임을 없앨 수 있다.

What is MSA?

Small auutonomous services that work together (함께 작동하는 작은 규모의 서비스)
Single Application, Small Service, Buusiness Capabilities 중심으로 개발. 완전 자동화된 배포 시스템을 사용해야 한다.

Martin Fowler 마이크로서비스의 창시자로

Minimun of Centralized management (최소한의 중앙 집중식 관리)
Use diffrent programming languages and different data storage technologies (다른 언어, 저장소 사용)
서비스의 종류와 기능에 맞춰 언어와 저장소를 사용 가능하다. (최적의 기술 사용 가능)

MSA Architecture