Cloud Native, 12 factors, MSA

2010년대 이후부터 IT 시스템은 Antifragile 또는 Cloud Native Architecture 형태로 발전되어 왔다.

 

Cloud Native Architecture의 특징

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

(어떤 서비스를 수정한다 하면 전체 시스템 배포가 아니라 해당 서비스만 배포하면 됨)

 

Cloud Native Architecture로 개발된 Applicaiton은 4가지 형태를 갖는다.

 

 

 

Microservices

기존의 시스템들이 하나의 거대한 형태로 구축되어 서비스 되었다고 하면 마이크로서비스는 전체 서비스를 구축하고

있는 개별적인 모듈이나 기능을 독립적으로 개발, 배포, 운영할 수 있도록 세분화된 서비스

 

CI/CD

CI: 통합 서버, 소스 관리(SCM), 빌드 도구, 테스트 도구(Jenkins, Team CI, Travis CI)

CD: 지속적인 배포(카나리 배포, 블루 그랜 배포)

 

DevOps

Microservices에 문제가 발생하면 바로 수정하여 배포하는 과정을 반복할 수 있는 형태

-> 시스템이 개발, 테스트, 배포되는 과정을 시스템이 종료될 때까지 무한 반복

 

컨테이너 가상화

공통적인 라이브러리나 리소스만을 공유해서 사용. 나머지는 분리

 

 

Cloud Native를 구축하기 위한 12가지 항목(12 Factors)

코드 베이스(코드 통합)

코드를 한곳에 배포하는게 목적이며

배포하기 위해 코드의 통일적인 관리가 필요하다.

 

종속성 배제(Dependencies)

각 마이크로서비스는 분리가 되어있어서

전체 시스템에 영향을 주지 않는 상태에서 변경 및 내용 수정할 수 있어야 한다.

 

환경설정의 외부 관리(Config)

코드 안에 설정 정보가 하드코딩 되어있는게 아니라

시스템 코드 외부에서 관리 도구를 통해 관리할 수 있어야 한다.

 

백업 서비스의 분리

DB, 캐시, 브로커 등을 이용해 마이크로서비스의 기능들을 추가로 지원할 수 있어야 한다.

필요한 이펙팅 리소스를 분리함으로 인해 코드 의존성을 갖지 않는 상태에서 작업할 수 있다.

 

개발 환경과 테스트 환경의 분리(Release & Run)

개발환경에서 만들어진 코드를 배포 하기위해 실행단계까지 옮기는 과정을 분리해야된다.

각각 고유 id로 태그를 가지며, 롤백 기능을 지원해야하며, CI/CD를 이용해 자동화된 시스템을 구축하는게 좋다.

 

상태 관리(Processes)

각각의 마이크로서비스는 실행중인 다른 서비스들과 분리된채 자체 프로세스에서 운영될 수 있어야 한다.

 

포트 바인딩(Port Binding)

배포된 어플리케이션을 타 어플리케이션에서 접근할 수 있도록 포트바인딩을 통해 서비스를 공유해야 한다.

-> 백엔드간 커뮤니케이션

 

동시성(Concurrency)

하나의 서비스가 여러가지의 인스턴스(PC)의 동일한 형태로 복사돼서 운영되므로 동시성을 가지고 있어야 한다.

 

Disposability

서비스 인스턴스 자체가 삭제가 가능해야하며 확장성을 높혀야하며 정상적으로 종료할 할 수 있어야한다.

(프로세스 시작과 종료)

 

서비스의 올바른 상태유지와 개발, 운영환경의 통일

로컬 개발환경과 운영 환경은 같아야 한다.

 

로그의 분리

로그를 파일로 저장하는게 아니라 console.log를 통해 stdout 해야한다(이벤트 스트림처리)

어플리케이션이 실행되지 않는 상태여도 로그만은 정상적으로 작동할 수 있는 상태여야 한다.

 

관리 프로세스(Admin Processes)

현재 운영되고 있는 모든 마이크로서비스들이 어떤 상태인지 알아야한다(shell 언어)

 

최근에 추가된 3가지

API first

 

가지고 있는 모든 마이크로서비스는 api 형태로 제공한다.

Telementry

모든 지표는 수치화 시각화되며 관리된다.

Authentication and authorization

api 사용함에 있어서 인증 인가는 필수다.

 

 

Mononlithic & Microservice

Mononlithic

• 프론트엔드, 백엔드 같은 모든 서비스의 내용들이 하나의 어플리케이션에서 모두 의존성을 가지며 동작.
• 하지만, 조그만 수정사항이 있어도 전체를 다시 빌드해서 배포해야 하며,
• 많은 양의 코드가 다 몰려있어 유지보수의 단점이 있음
• 또한, 일부 코드가 전체 코드에 영향을 미칠 수 있게 된다.

Microservice

• 어플리케이션을 구성하는 각각의 구성요소 및 서비스의 내용을 분리해서 개발하여 운용하는 방식이다.
• 기능별로 나누어서 개발자들이 마이크로서비스를 개발할 수 있으며 이에 따른 DB 저장소나 기술 언어도 선택해서 사용.
• 변경되거나 새롭게 추가되는 마이크로서비스만 빠르게 빌드 및 배포 가능.
• 어느 부분에 오류가 생겼을 때 전체 시스템에 영향을 미치지 않으며 그 부분만 수정하여 빠르게 정상화 가능.

 

Front & Back 이라는 Monolith와 Microserves와의 중간단계인 개발 환경도 존재

 

The Monolith: 하나의 팀에서 전체 서비스를 개발

Front & Back: http 통신 api를 이용해 Front 단과 Back 단을 나누어서 개발

Microservices: Front 단과 Back 단의 세부 서비스들로 나누어서 개발

 

Microservices 구조

 

1. Mobile App, Browser App 같은 클라이언트나 Other Services들이

API Gateway라는 곳에서 필요한 서비스 요청을 한다.

 

2. API Gateway에서 수집된 요청은 Service Router에게 어디로 가야할지 물으며

필요한 마이크로서비스가 어디에 저장되어있는지 Service Discovery에 묻게된다.

 

3. A, B 마이크로서비스는 여러개의 인스턴스들을 가지고 있기 때문에

Load Balancing에 의하여 어떤 서비스로 갈지 결정을 하게 된다.

(Service Router, Load  Balancing을 하나로 묶어서 사용하는 경우도 있다)

 

4. 마이크로서비스에서 사용하는 환경 설정 정보들은

Cloud Configuration 서비스를 통해 외부 시스템에 저장한다(Config)

 

5. 각 마이크로서비스들은 Spring, node.js, python등 다양한 언어로 개발할 수 있다.

 

6. 완성된 어플리케이션은 CI/CD Automation을 통해 배포할 때

DevOps관리자들이 사용할 수 있게 api가 공개되어 있어야 한다.

 

7. Backing Service의 Persistence는 마이크로서비스들에 저장되어 있는 다양한 storages를

모아서 사용할 수 있는 방법들이다.

 

8. Backing Service의 MOM(Message Oriented Middleware, 카프카 등)을 통해

하나의 서비스와 다른 서비스가 같이 연결될 수 있다.

 

9. Telemetry 기능을 통해 마이크로서비스의 진단 기능과 모니터링 기능을 이용할 수 있다.

 

Backing service란, 어플리케이션이 실행되는 가운데 네트워크를 통해 사용할 수 있는 모든 서비스를 말한다.

MySQL과 같은 데이터베이스, 캐시 시스템, SMTP 서비스 등 어플리케이션과 통신하는

attached Resource들을 지칭하는 포괄적인 개념.

 

MSA에서는 Message Queue를 활용하여 트랜잭션을 분리하는 전략을 많이 취함.

(MSA에서 Orchestration이 진행되면서 진행 중인 트랜잭션이 끊어지게 되고, 해당 서비스 요청 보존이 불가능하기 때문)

 

 

Service Mesh 자세히

 

서비스간의 통신을 추상화하고 빠르고 신뢰성있게 만들어주는 레이어인데

이런 추상화를 통해 복잡한 내부의 네트워크를 제어하며 추적한다.

내부 네트워크 관련 로직을 추가하면서 신뢰성, 안전성, 가시성, 보안성 등을 확보할 수 있다.

 

Service Mesh는 URL 경로, 호스트 헤더, API 버전 또는 기타 응용 프로그램 수준 규칙을 기반으로 하는

계층 7 네트워크 Layer이다.

 

Service Mesh에는 설정정보, 라우팅, 인증에 관련된 정보, 로드밸런싱 기능, 서비스 검색, 암호화등의

기능들을 제공한다.

 

페이지에 대한 사용자 요청이 들어오면 프록시 객체가 이를 먼저 수신하고

보안 조취를 취한후

서버로 전송하며

다시 프록시 객체로 전달되고 보안 조취를 취한 후

최종적으로 사용자에게 전달되게 된다.

 

 

 

학습 블로그

https://blog.naver.com/qjawnswkd/222306768374

Cloud Native,12factors, Microservices