Cloud Native Architecture?
확장 가능한 아키텍처
- 시스템의 수평적 확정에 유연하다
- 확장된 서버, 시스템 부하분산 가용성 보장
- 시스템 또는 서비스 어플리케이션 단위 패키지(컨테이너 기반)
탄력저 아키텍처
- 서비스 생성-통합-배포, 비즈니스 환경 변화에 대응 시간 단축
- 분활된 서비스 구조
- 무상태 통신 프로토콜
- 서비스 추가 삭제 자동 감지
- 변경된 서비스 요청에 따른 사용자 요청처리
장애처리
- 특정 서비스 오류 발생해도 다른 서비스 영향 안줌
Cloud Native Application?
마이크로 서비스로 개발
CI/CD
DevOps
- Development + Operations + QA
- 고객의 요구사항은 계속 변경될 수 있음 따라서 바로 수정이 가능하도록 구성하는게 중요
- 끊임없는 피드백과 수정사항 반영으로 고객의 요구사항에 맞도록 제작
Containers
-
컨테이너 가상화 => 클라우드 환경으로 이전해서 탄력적으로 시스템 환경 구성
-
Host System (물리적 시스템) + Container Runtime(공용라이브러리) + Container(개별라이브러리)
12Fators
클라우드 네이티브를 개발하거나 고려할 사항 12가지요소
- Codebase
- 버전제어, 형상관리 목적으로 코드의 통일적 관리가 필요
- Dependencies
- 전체 시스템에 영향을 주지 않고 변경 가능하도록 코드 구성
- Config
- 시스템 외부에서의 구성관리 서비스로 환경설정 가능해야함
- Backing services
- 추가적 기능 지원 가능하도록 분리해야함
- Build, release, run
- 빌드, 배포, 실행환경의 분리필요
- Processes
- 자체 프로세서에서 실행되어야함, 서로다른 마이크로 서비스끼리 분리되어실행되어야 한다
- Port binding
- 노출 포트, 마이크로 서비스끼리 통신하는 포트가있어야 한다
- Concurrency
- 하나의 서비스가 여러 인스턴스에 복제되어 부하 분산이 가능하도록 한다
- Disposability
- 서비스 인스턴스 삭제가 가능하고, 확장성 및 정상 종료가 되어야 한다
10.Dev/prod parity - 개발, 프로덕션 단계 구별 필요
11.Logs - 서비스 도중 생성된 로그를 출력 정상작동 해야한다
12.Admin processes - 운영되고 있는 모든 마이크로 서비스들의 대한 파악하기 위한 관리도구가 필요하다
- 3개의 항목을 더 더한다(피보탈회사가 추가한 항목)
- API first
- 사용자가 어떤 목적으로 사용할 것인지 API위주로 구성
- Telemetry
- 시각화 필요
- Authentication and authorization
- 인증 절차를 통해 관리되어야 한다
Monolithic vs Microservice
Monolithic 방식
모든 필요한 구성 요소를 하나의 소프트웨어 안에 담아 개발, 서로 의존성을 갖고 있음
- 문제점
- 시스템 일부만 수정하더라도 전체 시스템을 모두 재실행 시켜야 함
- 다운타임이 필연적으로 발생한다
Microservice
각가 구성하고 있는 어플리케이션 서비스등을 분리하여 개발, 배포
-
최소한의 중앙 집중식 관리
-
서로 다른 언어와 서로다른 데이터베이스가 사용 가능해야 한다
프론트앤드 + 백앤드(프로덕트, 베스킷 페이먼트 ...등으로 각 서비스가 분리)
특징
- Challenges
- 기존 개발 방식과 패러다임의 대한 도전
- Small well chosen deployable units
- 서비스 단위 및 배포 방법의 선택이 중요하다
- Bounded context
- 서비스의 경계 구분이 필요하다
- RESTful
- API 방식으로 통신이 중요
- Configuration Management
- 환경 및 설정에 대한 정보는 외부 시스템을 통해 관리 되야 한다
- Cloud Enabled
- 클라우드 네이티브 기술 사용
- Dynamic Scale up and Scale down
- 부하분산 처리는 동적으로 구성되어야 한다
8.CI/CD - 지속적인 통합 배포가 가능해야 한다
- Visibility
- 시각화 가능한 구성도구가 있어야 한다
SOA(Service Oriented Architecture) vs MSA(Micro Service Architecture)
- SOA : 재사용을 통한 비용 절감
- MSA : 서비스 간의 결합도를 낮추어 변화에 능동적 대응
특징
- SOA : service bus같이 한 곳에 서비스를 집중 시켜 제공
- MSA : API를 통해 개별 제공
REST API
성숙도 모델?
REST API 개발시 고려해야할 항목들
- Level 0
- Level 1
- 적절한 URI 수정 표현
- 적절한 URI 수정 표현
- Level 2
- Level 1단계 + Http methods
- Level 3
- Level2 + HATEOAS
- 데이터를 갖고 그다음 작업에 어떤 행위를 할 수 있는지 같이 전달
- 엔드포인트만 있으면 서버가 제공할수 있는 그다음 uri를 알 수 있다
- DATA + NEXT POSSIBLE ACTIONS
- Level2 + HATEOAS
MSA 표준 구성요소
API Gateway로 요청 -> 라우터로 분배 -> 로드밸런서를 바탕으로 인스턴스로 분배 -> 인스턴스는 백 서비스와 연동 -> CI/CD를 통해 서비스 업데이트/배업
서비스 매시
마이크로 서비스 아키텍처를 적용한 서비스 내부 통신
Spring Cloud
- 환경설정관리
=> Spring Cloud Config Server - 서비스 등록과 위치 정보 확인
=> Eureka(naming server) - 로드밸런싱 기능 제공
=> Ribbon(Client Side)
=> Spring Cloud Gateway(recommend) - REST
=> FeignClient - 시각화, 모니터링
=> Zipkin Distributed Tracing
=> Netflix API gateway - 장애복구
=> Hystrix
