마이크로서비스 역량 모델

마이크로 서비스 구현에 필요한 역량은 상황에 따라 다를 수 밖에 없다. 그래서 마이크로서비스 설계 시 필요한 역량 모델에 대해 정리해보자.  

마이크로서비스의 역량 모델은 크게 4 개의 영역으로 분류할 수 있다. 

• 핵심역량
• 지원역량
• 인프라스트럭처 역량
• 프로세스 및 통제 역량

1. 핵심역량 (Core capabilities)

- 핵심 역량은 하나의 마이크로서비스 안에 패키징 되는 컴포넌트이다. 이곳에서 서비스 리스너, 실행 라이브러리, 서비스 구현 코드, 서비스 API와 종단점이 들어있다.

※ 서비스 리스너와 라이브러리

• 서비스 리스너는 마이크로 서비스로 들어오는 서비스 요청을 접수하는 종단점 리스너이다.
• 주로 사용 되는 리스너는 AMQP나 JMS 같은 메시지 리스너가 주로 사용된다.

※ 저장 기능

• 데이터를 저장 하는 RDBMS나 NoSQL에 저장 할 수 있다.

※  서비스 구현 (Service implementation)

• 실제로 사용 되는 비즈니스 로직 으로 자바, 스칼라 등등으로 어떤 언어로도 구현할 수 있다.

※ 서비스 종단점 (end-point)

• 외부의 서비스 소비자가 서비스에게 요청을 전송할 수 있게 외부에 공개한 API를 말한다.
• 종단점은 동기 또는 비동기일 수 있다. 비 동기인 경우에는 AMQP, 스프링 클라우드 스트림과 같은 메시지 리스너를 통해 요청을 받아서 백엔드에 있는 RabbitMq나 다른 메시징 서버 또는 제로엠큐 같은 다른 방식의 메시징 구현체를 통해 처리한다.

2. 인프라스트럭처 역량

- 성공적인 배포를 위해 인프라스트럭처 역량도 필요하다,

※ 클라우드

• 인프라스트럭처를 프로비저닝하는 데 오랜시간이 소요되는 전통적인 데이터 센터 환경에서는 마이크로서비스를 구현하는데 어렵다.
• 많은 애플리케이션이 분리되어 실행되는 마이크로서비스에경우 별도의 데이터 센터에서 관리하면 너무 관리 비용이 크기 때문에 클라우드 인프라스트럭처가 더 나은 선택이다.
• 클라우드 방식의 인프라스트럭처는 컨테이너나 가상머신을 탄력적으로 늘리고 줄이는 오토스케일링이 가능하다.

 

※ 컨테이너 런타임

• 다수의 마이크로서비스를 대용량 물리 장비에 배포하는 것은 비용이 많이 든다. 그래서 물리적인 장비만으로는 자동화된 장애 대응성을 갖추기 어렵다.

※ 컨테이너 오케스트레이션

• 컨테이너나 가상머신의 수가 많으면 자동으로 유지 관리하기 어렵다.
• 컨테이너 오케스트레이션 도구는 컨테이너 런타임 위에서 일관성 있는 운영환경을 제공하며 가용한 자원을 여러 컨테이너에 분배한다. 대표적 도구로 아파치 메소스, 쿠버네티스 등이 컨테이너 오케스트레이션 도구로서 널리 사용된다.
• 수작업으로 하면 번거롭고 오류 발생도 높다. 그래서 컨테이너 오케스트레이션 도구를 사용하면 애플리케이션 배포, 트래픽 제어, 인스턴스 복제, 무 중단 업그레이드를 자동으로 수행할 수 있다.
• 컨테이너 오케스트레이션 도구는 가용성확보와 데이터 센터에 걸친 배포 인스턴스 최소 사용 등의 관리 활동에 도움이 된다.

3. 지원역량 (Supporting Capabilities)

- 지원 역량은 마이크로서비스와 직접적으로 연결되지는 않지만 대규모 마이크로 서비스 배포에 필수적이다.

※ 서비스 게이트웨이

• 서비스 게이트웨이 또는 API 게이트 웨이는 서비스 종단점에서 프록시 역할과 종단점을 조합하는 역할을 담당한다.
• 대표적으로는 스프링 클라우드 zual, Mashery, Apigee, Kong, WSO2, 3scale 등 다양한 제품들이 있다.

※ 소프트웨어 정의 로드 밸런서

• 로드 밸런서는 유동적으로 변형되는 상황에서 적절하게 대처가 가능하도록 설계가 되어야 한다.
• ribbon, Eureka, zuul등을 사용해서 지능적인 소프트웨어 정의 로드 밸런서를 구현할 수 있다.
• 컨테이너 오케스트레이션 도구에서도 로드밸런싱 기능을 잘 사용할 수 있도록 제공하는 방법이 있다.

※ 중앙 집중형 로그 관리

• 로그파일은 분석과 디버깅에 중요한 정보를 제공한다. 로그는 각각의 인스턴스 디스크에 저장된다. 그래서 분산된 로그를 통합 관리해야한다.
• 그렇게 하기 위해서 마이크로서비스에서 각 애플리케이션에서 발생한 로그를 중앙 로그 저장소에 저장되도록 해야한다.

※ 보안서비스

• 분산 마이크로서비스 생태계에서 서비스 인증이나 토큰 서비스 같은 서비스 보안을 담당하는 중앙의 서버를 만들어야 한다.
• 스프링 부트 OAUTH를 사용해서 인증 방식을 추가할 수 있다.

※ 서비스 환경설정

• 마이크로 서비스를 사용하여 각자 애플리케이션이 배포 되면서 모든 애플리케이션 관련 설정을 따로따로 관리하기가 쉽지 않다.
• 그래서 각 환경 설정을 외부화 해야한다. 이런 환경설정 관리 서버로 스프링 클라우드 config 서버, Archaius를 사용할 수 있다.
• 소규모 마이크로 서비스같이 동적으로 설정을 변경할 필요가 없는 경우 Spring Boot의 프로퍼티로 해도 된다.

4. 프로세스 및 통제역량

- 프로세스 및 통제 역량은 마이크로 서비스 구현에 필요한 프로세스, 도구, 가이드라인등을 의미한다.

※ 데브옵스

• 애자일 개발, 지속적 통합, 자동화 QA, 자동화된 전달 파이프라인, 자동배포, 자동화 인프라스트럭처 프로비저닝 등을 도입 해야 한다.

※ 자동화 도구

• 테스트 자동과 자동 배포 등과 같은 자동화 도구 관리를 잘해야 한다.

※ 컨테이너 레지스트리

• 마이크로서비스의 버전관리를 위한 artifactory 저장소를 사용한다.

※ 마이크로서비스 문서화

• 마이크로서비스에서 개발된 종단점에 대한 정보를 어떻게 보여줄것인지를 보관하는 문서를 가지고 있어야한다.
• 효과적인 마이크로 서비스 문서는 웹 브라우저에서 접근할 수 있어야 하며, API를 쉽게 탐색하고, 샘플 테스트가 가능해야 한다.
• 가장 많이 사용하는 라이브러리는 Swagger를 사용한다.

※ 참조 아키텍처 및 라이브러리

• 마이크로 서비스는 여러 애플리케이션이 독릭접으로 구성되는데 라이브러리를 가지각색으로 사용하면 문제가 된다.
• 그래서 중앙에서 공용으로 사용할 수 있는 공용 라이브러리를 만들어서 사용해야 한다.