2010년 이후부터 Resilient/Anti-Fragile, Cloud Native 로 시스템 구축 -> 확장성, 안정성 강화
- Anti-Fragile의 핵심
- Auto scaling (자동 확장성)
- Microservices
- Chaos enineering (변동, 예견된 불확실성, 예견되지 않은 불확실성에 대해서도 안정적인 서비스 제공)
- Continuous deployments (CI/CD 지속적인 통합/배포)
Cloud Native Architecture
- 확장 가능한 아키텍처
- 시스템의 수평적 확장에 유연 -> 더 많은 사용자
- 확장된 서버로 시스템의 부하 분산, 가용성 보장 [스켈업(하드웨어 업그레이드), 스켈 아웃(동일한 하드웨어 갯수 증가]
- 시스템 또는 서비스 애플리케이션 단위의 패키지 (컨테이너 기반 패키지)
- 모니터링
- 탄력적 아키텍처
- 서비스 생성 - 통합 - 배포, 비즈니스 환경 변화에 대응 시간 단축
- 분활된 서비스 구조
- 무상태 통신 프로토콜
- 서비스의 추가와 삭제 자동으로 감지
- 변경된 서비스 요청에 따라 사용자 요청 처리 (동적처리)
- 장애 격리
- 특정 서비스에 오류가 발생해도 다른 서비스에 영향 주지 않음
Cloud Native Application
- Microservices
- CI/CD
- 지속적인 통함
- 통합 서버, 소스 관리(SCM), 빌드 도구, 테스트 도구
- ex) Jenkins, Team CI, Travis CI
- 지속적인 배포 (시스템의 정상적인 운영, 다운 타임 최소화 중요)
- Continuous Delivery (실행 파일을 수동으로 실행환경에 배포)
- Continuous Deployment (실행 환경까지 자동으로 배포)
- Pipe Line
- 카니리 배포와 블루그린 배포
- 95% 이전버전 서비스 5% 새버전 서비스
- 점진적으로 새버전으로 이전
DevOps
Development + Operations (개발조직과 운영조직 통합 -> 고객의 요구사항을 빠르게 반영하고 만족도 높은 서비스 제공)
개발 서비스를 자주 테스트하고 자주 피드백하고 자주 업데이트하는 과정
Cloud Service은 DevOps환경에 맞춰서 서비스를 작은 단위로 만들어서 더 자주 통합, 테스트 배포할 수 있는 구조가 될 수 있다.
Containers (가상화)
가성 머신에서 작동하는 어플리케이션은 호스트 머신에 부하를 주게 된다. -> 시스템 확장에 문제
운영체제 위에 컨테이너 가상화를 위한 소프트웨어 서비스를 작동
컨테이너 가상화는 공통적인 라이브러리나 리소스 등을 공유해서 사용한다.
각자 필요한 부분에 대해서만 독립적인 부분에 대해서만 실행가능 -> 더 가볍고 빠르게 운영가능
Cloud Native Application을 구축하기 위해 고려해야할 12가지
BASE CODE (코드 통합)
자체 레포지토리에 저장된 단일 코드 베이스, 버전을 제어하기 위한 목적, 형상 관리를 하기 위해서 한곳에서 배포하는게 목적, 코드의 통일적인 관리 필요
DEPENDENCY ISOLATION (종속성 배제)
각 마이크로서비스는 자체 종속성을 가지고 있어서 전체 시스템에 영향을 주지 않고 변경, 수정할 수 있어야 함
CONFIGURATIONS (환경 설정 외부 관리)
구성 정보, 시스템 코드 외부에서 구성 관리 도구를 통해서 마이크로서비스에 필요한 작업들을 제어, 동일한 배포가 올바른 구성이 적용된 구성환경에서 배포
LINKABLES BACKING SERVICES (서비스 지원)
보조 서비스(데이터 베이스, 캐싱, 메시징 서비스)를 이용해서 마이크로 서비스가 가져야할 기능들을 지원, 서로 상호가능한 서비스 작업
STAGES OF CREATION (개발 환경과 테스트 환경의 분리)
빌드, 릴리즈, 실행 환경 엄격하게 분리
각각은 고유한 ID 로 태그를 가지고 있어야 하고 이전 상태로 돌아가는 롤백, CI/CD를 이용해서 자동화된 서비스 구축
STATELESS PROCESSES (상태 관리)
각각의 마이크로 서비스는 분리된 체 자체 프로세스에서 운영될 수 있어야 함, 독립성
하나의 마이크로 서비스는 독립적으로 실행될 수 있는 상태이어야 함
PROT BINDING (포트 바인딩)
자체 포트에서 노출되는 인터페이스 및 기능과 함께 자체 포함되어있는 기능이 있어야 함
CONCURRENCY (동시성)
아주 많은 수의 동일한 프로세스를 복사해서 확장, 하나의 서비스가 여러가지 인스턴스에 복사되서 운영됨
DISPOSABILITY (서비스의 올바른 상태 유지)
서비스의 인스턴스 자체가 삭제가능해야하고 확장성, 정상적으로 종료 가능해야함
EVELOPMENT & PRODUCTION PARITY (개발과 운영환경의 구분)
개발단계와 운영단계를 구분 (종속 X)
LOGS (로그의 분리)
하나의 시스템안에 구성되고 있는 로그를 출력하는 로직은 어플리케이션 로직과 분리되서 어플리케이션이 동작하지 않는 상태이더라도 로그만은 정상적으로 작동되어야 함
ADMIN PROCESSES FOR EVENTUAL PROCESSES (관리 프로세스)
현재 운영되고 있는 마이크로 서비스들을 파악하기 위한 관리 도구가 필요
리포팅, 데이터 정리 및 분석 기능 가지고 있어야함
12가지 + 3가지
API first
마이크로 서비스는 API 형태로 구축
Telemetry
관리자와 유사, 모든 지표는 시각화 되서 관리 가능해야함
Authentication and authorization
API를 사용함에 있어서 인증은 필수
어플리케이션 개발 방법
시스템 운영방식 중 Monolith, Microservices
Monolith
개발함에 있어서 필요한 모든 요소를 하나의 커다란 소프트웨어 안에 포함 (모든 업무 로직이 하나의 어플리케이션 형태로 패키지되어 서비스)
데이터베이스, 비지니스, 프론트엔드 로직 모두 하나의 어플레케이션에 유기적으로 연결되어 작동하고 배포되기 위해 서로 의존성을 가진 상태로 패키징되고 운영서버에 배포
하나의 큰 건축물과 비슷
문제점 : 일부 기능만 수정하더라도 전체 애플리케이션을 빌드하고 배포해야함
Micorservcies
어플리케이션을 구성하는 각각의 구성요소 및 서비스의 내용을 분리해서 개발하고 운영하는 방식
유지보수나 변경사항을 적용하는 데에 유리
만약 새로 개발되어야 한다고 가정했을때 필요한 부분에 대해서만 개발하고 분리된 서비스가 기존 서비스에 영향을 주지 않거나 최소화하면서 독립적으로 배포가 가능
어플리케이션 전체가 다운타임이 되는 상황을 없앨 수 있다.
각각의 용도에 맞는 컨테이너들을 모아서 개발하는 서비스 방식
HTTP 통신을 이용해서 리소스 API 통신할 수 있는 작은 여러 서비스들의 묶음
비지니스 기능을 중심으로 개발되어야 하고 완전하게 자동화된 배포 시스템을 사용해야함
최소한의 중앙집중식 관리가 되어야하고 서로 다른 프로그래밍 언어와 데이터 기술을 사용할 수 있다.
Monolith, Microservice Architecture의 중간정도로 Front & Back 생각할 수 있다.
Microservice Architecture란?
아마존, 넷플릭스는 Cloud를 이용한 Microservice Service를 가장 잘 이용하는 회사
아마존에서 테크 팀에게 전달한 내용
모든 팀은 서비스 인터페이스를 통해서 데이터, 기능을 공개해야 한다.
각각 팀은 서비스 인터페이스를 통해서 통신해야 한다. (데이터 베이스에 접속해서 저장, 읽기를 사용하지 않고 서비스 인터페이스를 통해서 접근해야함)
각 팀이 어떤 기술을 사용하는 중요하지 않음
모든 서비스 인터페이스는 외부에 공개될 수 있도록 초기 설계 되어야 함
Microservice 의 특징
Challenges (기존의 개발 방식을 상당수 바꿔야함)
Small Well Chosen Deployables Unit (독립적으로 배포가능한 작은 서비스로 이루어져야 함)
Bounded context (서비스 경계를 잘 구분해야 함)
RESTful (서로 상태에 대해서 REST API로 통신하는 것을 권장)
Configuration Mangement (마이크로서비스들이 가지고 있는 환경, 설정에 대한 정보는 외부에 있는 시스템을 통해 관리)
Cloud Enabled (Cloud Native 기술을 최대한 활용해서 서비스를 제공)
Dynamic Scale Up And Scale Down (서비스를 제공하는 인스턴스들은 부하 분산 처리나 스케일업, 스케일다운 등을 동적으로 처리할 수 있도록 구성
CI/CD (자동화 배포 중요)
Visibility (시각화해서 관리할 수 있는 도구 필요)
모두 다 Microservice로 개발되어야 하나??? 그렇지 않다.
고려해야 할 사항
기존 개발 대비 어느정도의 비용
독립 라이프 사이클(서비스의 경계가 잘 만들어져 있는가?)
서비스의 유지보수 및 확장성이 가능한가??
격리된 오류(오류 사항이 독립적인가??)
외부 종속성과 상호작용을 최소화해야하고 각 서비스는 응집력을 높일 수 있는가?
여러가지 프로그래밍 언어와 데이터 기술을 지원하는가???
Microservcie Architecture와 Service Orientied Architecture(SOA)
둘다 서비스를 중시
차이점
SOA : 재사용을 통한 비용절감 (서비스 공유 최대화)
MSA : 서비스 간의 결합도를 낮추어 변화에 능동적으로 대응 (서비스 공유 최소화)
서비스를 공유하지 않고 독립적 실행
기술방식
SOA : 서비스를 공유하기 위해 ESB(Enterprise Serivce Bus)라는 서비스 서비스 채널 이용 (middle ware)
ESB에 공통의 서비스를 모아 제공
MSA : 각 독립된 서비스가 노출도니 REST API 를 사용
각 서비스의 데이터가 변경되면 이벤트 스트림(메시징)을 이용해서 동기화(예: kafka)
REST API
level 0 :
기존의 서비스를 웹으로 공개
http://server/getPosts
http://server/deletePosts
level 1 :
자원을 의미있고 적절한 url로 표현
http://server/accounts
http://server/accounts/10
사용자의 요청을 단순하게 get, post로 처리
level 2 :
level 1 + HTTP Methods(GET, POST, DELETE, PUT)
level 3 :
level 2 + HATEOAS
DATA + 다음 어떠한 액션하는지(추가적으로 어떻게 다른 작업으로 넘어가는지)
RESTful 고려사항
API를 사용하는 사용자 중심에서의 설계
HTTP methods, header, request, response type 등 http 의 장점을 최대한 살림
Request methods (GET, POST, PUT, DELETE) 최소한 level 2 로 개발
Response Status (적절한 상태 코드 전달해야함)
200, 400, 404, 201, 401...
사용자의 비밀번호와 같은 critical한 내용은 URI에 들어가면 안됨
제공하려는 데이터에 대해서 복수형태로 쓰는게 일반적임
가능하면 명사 형태로 표현
일관적인 End Point
PUT /gists/{id}/star
DELETE /gists/{id}/start
MAS 표준 구성요소
Service Mech
추상적인 개념을 다양한 서비스를 제공함으로써 안정적인 마이크로 서비스를 운영하는 목적
MSA 인프라 -> 미들웨어
프록시 역할, 인증, 권한 부여, 암호화, 서비스 검색, 요청 라우팅, 로드 밸런싱
자가 치유 복수 서비스
서비스간의 통신과 관련된 기능을 자동화
CNCF(Cloud Native Computing Foundation)
서로 상호 연관된 서비스들이 어떠한 것이 있는지 확인
MSA 기반 기술
Spring Cloud란?
https://spring.io/projects/spring-cloud
환경 설정관리, 서비스 검색, 회복성 처리, 라우팅, 프록시 등 분산 시스템을 사용해서 빠르게 어플리케이션을 만드는 목적
환경 설정 관리 -> Spring Cloud Config Server
서비스의 등록과 위치정보확인, 검색 -> Naming Server (Eureka)
로드 밸런싱(분산) -> Ribbon (Client Side), Spring Cloud Gateway
각 마이크로 서비스들의 통신을 위해서 -> FeignClient
시각화, 모니터링 -> Zipkin Distributed Tracing, Netflix API gateway
장애 복구 (회복성 패턴) -> Hystrix
필수 SW 설치
인텔리제이, git, vscode, postman
'Spring > [인프런] Spring Cloud' 카테고리의 다른 글
Catalogs, Orders Microservice (0) | 2022.06.19 |
---|---|
Users Microservice (0) | 2022.06.18 |
E-commerce 어플리케이션 (0) | 2022.06.18 |
API Gateway Service (0) | 2022.06.17 |
Service Discovery (0) | 2022.05.29 |