[MSA] 마이크로서비스 개요 / 클라우드 네이티브 / MSA의 요소

 

 

마이크로서비스와 클라우드 네이티브 아키텍처

 

 

마이크로서비스는, 소프트웨어가 독립적인 서비스의 모음으로, API를 통해 통신하는 애플리케이션 아키텍처를 말한다.

마이크로서비스는

 

1. 확장 가능한 아키텍처

2. 탄력적 아키텍처

3. 뛰어난 장애복구

 

가 가능해야 한다.

 

 

 확장 가능한 아키텍처란,

 

-시스템의 수평적 확장에 유연하고, 확장된 서버를 통한 시스템의 부하 분산과 가용성 보장을 말한다.

 

탄력적 아키텍처란,

 

-통합과 배포에 시간이 단축되고

서비스의 추가와 삭제를 자동으로 감지해 처리할 수 있는 것을 말한다.

 

 

 

또한, 특정 서비스에 오류가 발생해도 다른 서비스에 영향이 가지 않아야 하는데,

이를 뛰어난 장애복구가 가능해야 한다고 표현한다.

 

 

 

서비스 디스커버리

 

마이크로서비스처럼 많은 서비스들이 분산되어, 서로 통신해야 할 때는

각 서비스의 위치를 자동으로 찾고 연결해 주는 중앙화된 서비스가 필요하다.

 

이런 역할을 해 주는 것을 서비스 디스커버리라 한다.

 

마이크로서비스는 독립적으로 배포되고, 없어지면 자동으로 동적인 생성/삭제가 될 수 있기 때문에

고정된 IP나 포트를 갖지 않고

컨테이너나 가상머신에서 실행될 때마다 바뀔 수 있따.

 

따라서 Discovery 서비스가 각 마이크로서비스의 위치 정보를 자동으로 관리해줘야 한다.

 

: 서비스들의 IP와 Port 정보에 대해서 저장하고 관리하는 것.

 

 

●  등록 : 서비스가 기동되면, Discovery 서비스에 자신의 이름, IP와 Port 등을 등록

●  검색 : 다른 서비스나 사용자에게서 요청이 오면 Discovery 서비스가 서비스 위치를 알려준다.

●  삭제 : 서비스가 중단되거나 종료되면, Discovery 서비스에서 해당 위치 정보를 삭제한다.

 

과정으로 마이크로서비스 배포 과정이 관리된다.

 

spring cloud 에서는 대표적으로 Eureka를 사용.

 

 

---

 

 

Cloud Native Application

 

클라우드 네이티브 환경에 적합한 애플리케이션

 

1. 마이크로서비스로 개발

2.CI/CD - 마이크로서비스를 파이프라인으로 통합

3. DevOps 로 바로 수정한 내용을 배포

4. Containers, 컨테이너 가상화 기술을 사용

 

 

 

 

배포의 종류

 

-Continuous Delivery(전달)

: 패키지화되어 있는 결과물을 수작업으로 배포가 필요할 때 사용한다.

운영자가 배포 여부를 결정함.

 

-Continuous Deployment(배포)

:Delivery + 배포 까지 자동으로 이어지는 프로세스.

운영자 관리자의 개입 (X)없이, 실행 환경까지 자동화되어 있는 배포를 쓰는 것이다.

 

-카나리 배포

 

새로운 버전을 일부 사용자에게만 먼저 배포해, 안정성을 학인한다.

이후 문제가 없으면 순차적으로 전체 전환한다.

 

-블루그린 배포

 

기존 버전-Blue

새 버전 - Green

 

기존 버전과 새 버전을 완전히 별도의 환경에 배포하고,

트래픽을 한 번에 전환한다.

 

-> 배포 환경을 두 개 유지하다가, Green이 충분히 테스트되면 

Blue -> Green으로 트래픽을 전환할 수 있다.

 

 

---

 

 

 

클라우드 네이티브를 위해 고려가 필요한 12 Factors

 

I. 코드베이스

버전 관리되는 하나의 코드베이스와 다양한 배포

II. 종속성

명시적으로 선언되고 분리된 종속성

III. 설정

환경(environment)에 저장된 설정

IV. 백엔드 서비스

백엔드 서비스를 연결된 리소스로 취급

V. 빌드, 릴리즈, 실행

철저하게 분리된 빌드와 실행 단계

VI. 프로세스

애플리케이션을 하나 혹은 여러개의 무상태(stateless) 프로세스로 실행

VII. 포트 바인딩

포트 바인딩을 사용해서 서비스를 공개함

VIII. 동시성(Concurrency)

프로세스 모델을 사용한 확장

IX. 폐기 가능(Disposability)

빠른 시작과 그레이스풀 셧다운(graceful shutdown)을 통한 안정성 극대화

X. 개발/프로덕션환경 일치

개발, 스테이징, 프로덕션 환경을 최대한 비슷하게 유지

XI. 로그

로그를 이벤트 스트림으로 취급

XII. Admin 프로세스

admin/maintenance 작업을 일회성 프로세스로 실행

 

 

참고)

The Twelve-Factor App (한국어)

The Twelve-Factor App (한국어)

 

 

---

 

 

모놀리식 서비스 VS 마이크로서비스

 

 

모놀리식	애플리케이션 개발에 있어서 필요한 모든 요소를 하나의 커다란 소프트웨어 안에서 전부 포함시켜 개발한다. 데이터베이스 또한 하나의 저장소에 들어간다.
마이크로서비스	마이크로서비스 아키텍처 HTTP 통신을 이용해 리소스 API에 통신할 수 있는 작은 규모의 여러 서비스들의 묶음이 모여서 하나의 어플리케이션을 구성한다. -중앙집중식 관리 -서로 다른 데이터 관리 -도메인의 특성을 사용해 구분한다.

 

 

 

마이크로서비스 아키텍처의 원칙

 

1. 모든 팀은 서비스 인터페이스를 통해 데이터 기능을 공개한다.

2. 팀은 이런 인터페이스를 통해서 통신한다.

3. 예외 없는 모든 서비스 인터페이스는 외부에 공개될 수 있도록 설계되어야 한다.

 

 

---

 

 

 

SOA, MSA

 

SOA - 서비스 오리엔티드 아키텍처

MSA - 마이크로서비스 아키텍처

 

둘 다 서비스를 지향하지만, MSA는 서비스 간 결합도를 낮추어 변화에 능동적으로 대응하고자 한다.

두 개의 서비스 간 데이터를 전달하려면, 연결되거나 직접 접속하는 방벙이 아닌

API를 통해서 데이터를 요청하고 사용해야 한다.

 

SOA는 공통 사용 서비스를 서비스 버스라는 개념을 통해 비즈니스에 필요한 하나로 만드는 것이고

 

MSA는 REST API를 통해 독립된 서비스 간 리소스를 제공한다.

 

 

 

 

 

MSA의 표준 구성요소/기술과 관리 요소

 

 

1. API 게이트웨이 (게이트웨이)

 

모든 클라이언트 요청을 받는 입구이며,

인증, 인가, 로드밸런싱, 요청 라우팅, 보안 등을 담당할 수 있다.

 

기술) spring cloud , Nginx 등

 

 

2. 서비스 디스커버리 (Service discovery)

 

서비스의 위치를 찾게 해주며, 동적으로 생성/종료될 때 위치를 자동으로 등록하고 해제한다.

 

기술) Eureka , Config

 

 

3. 중앙 관리

 

서비스별 설정값(DB연결정보, 환경변수)을 중앙에서 관리

설정 변경 시 서비스에 자동으로 반영되게 된다.

 

기술) spring cloud 의 Config.

 

 

4. 로깅/모니터링

 

서비스의 상태, 오류, 성능을 실시간으로 수집하고 모니터링한다.

 

기술) Elastic Search, Logstash, Kibana

 

5. 분산 추적

 

여러 서비스에 걸친 요청의 흐름을 분석해 병목과 오류를 분석한다.

 

기술) ZipKin, Jaeger 등

 

6. 서비스 메시

 

서비스 간 통신을 트래픽 제어, 보안, 로깅 등 더욱 정교하게 관리한다.

기본적으로 사이드카 프록시를 서비스마다 붙여 통신을 관리하게 된다.

 

※사이드카 프록시 : 메인 애플리케이션 컨테이너(서비스) 옆에 붙어 있는 보조 컨테이너, 프로세스를 말한다.

서비스마다 1:1로 붙으며, 네트워크 통신을 대신 처리해준다.

 

-서비스 메시를 구현할 때 필수이다. 이 서비스 메시가 각 서비스에 사이드카를 붙여

네트워크 보안, 트래픽, 제어, 모니터링 등을 수행하는 것.

 

7. 보안

 

인증,인가, 암호화, API보안, 토큰/OAuth 등

API 게이트웨이 또는 서비스 메시에서 보안 정책을 통합하고 관리한다.

 

8. CNCF

Cloud Native Computing Foundation

 

클라우드 네이티브 기술을 표준화하는 오픈소스 재단으로

MSA 구현에 필요한 오픈포스 도구들이 CNCF 프로젝트로 관리된다.

 

○ Kubernetes

○ Prometheus

○ Envoy

○ Helm (패키징 및 배포 자동화)

 

9. 텔레메트리

 

텔레메트리란 로그, 매트릭, 트레이싱 데이터를 모두 모아 시스템의 상태를 한눈에 볼 수 있게 하는 것을 말한다.

서비스가 수백, 수천 개로 늘어나면 장애나 성능 문제를 찾는 데 텔레메트리가 중요하다.

 

Prometheus이나 ELK스택, Zipkin/Jaeger 등.

 

 

---

 

 

Spring Cloud의 사용

 

분산 시스템을 빠르게 개발할 수 있도록 하는 Spring 프레임워크.

 

-springboot 버전을 맞춰야 사용할 수 있다.

 

 

 

1. 환경설정을 위한 config

 

spring cloud config server

 

-각 서비스의 설정파일을 중앙에서 관리하며,

Git등의 원격 저장소를 사용

(DB연결정보나 API 키 등 환경변수 또한 설정파일에서 관리한다)

 

2. location transparency

 

Eureka 네이밍 서버를 사용한다.

(서비스 디스커버리)

 

 

3.로드밸런싱

 

spring cloud gateway, Ribbon

 

로드밸런싱으로 여러 서비스 인스턴스가 있을 때

요청을 골고루 분산하게 된다.

 

4. FeignClient

 

-서비스 간 소통을 위한 HTTP 클라이언트이다.

Eureka에서 서비스 위치를 찾아서 요청한다.

 

5. Fault Tolerance

 

-Hystrix

-서비스 일부가 장애가 생겨도 전체 장애로 번지지 않도록 하는 역할

예시) 요청 실패시 fallback 처리

 

fallback 처리를 위해 서킷 브레이커를 사용한다.

fallback 은 장애 확인 시 , 돌려주어야 하는 B 대신 기본응답나 캐시데이터 등 응답을 돌려주는 것으로 생각하면 된다.

 

-Hystrix이 서킷 브레이커 도구이다.

 

 

 

 

서킷 브레이커

 

장애 감지를 위해 사용되는 디자인 패턴이다.

 

 

[디자인패턴] 서킷 브레이커 패턴(Circuit Breaker Pattern)의 필요성 및 동작 원리 - MangKyu's Diary

[디자인패턴] 서킷 브레이커 패턴(Circuit Breaker Pattern)의 필요성 및 동작 원리

 

 

 

---

 

참고)

[Spring Cloud] Eureka 개념 및 예제

[Spring Cloud] Eureka 개념 및 예제

 

 

[SC09] Spring Cloud Hystrix 란 ?

[SC09] Spring Cloud Hystrix 란 ?

 

 

kim.dragon :: [DevOps] CloudNative란? CNCF란?

[DevOps] CloudNative란? CNCF란?

 

서비스 메시란? - 서비스 메시 설명 - AWS

서비스 메시란? - 서비스 메시 설명 - AWS