마이크로서비스

마이크로서비스(microservice)는 서비스 지향 아키텍처(SOA) 구조 스타일의 일종으로 애플리케이션을 느슨하게 결합된 서비스 모음으로 구조화하는 소프트웨어 개발 기법입니다.

• 서비스들은 섬세(fine-grained)하고 프로토콜은 가볍습니다.
• 통신 요구 사항이 적습니다. 그러나, 디커플링을 유지하려면 비용이 듭니다.
• 인터페이스는 신중하게 설계하고 공개 API로 취급해야 합니다.
• Continuous Delivery(Deployment)를 가능케 한다.

느슨한 결합

느슨한 결합의 서비스는 개발자가 사용자에 대해 신경 쓸 필요가 없고 변경 사항을 사용자에게 강요하지 않기 때문에 모든 유형의 종속성과 그 주변의 복잡성을 줄입니다.
따라서, 소프트웨어를 개발하는 조직이 빠르고 크게 성장할 수 있을 뿐만 아니라 기성품 서비스를 더 쉽게 사용할 수 있습니다.

유지보수

애플리케이션을 더 조그마한 여러 서비스로 분해할 때의 장점은 모듈성을 개선하고 애플리케이션의 이해, 개발, 테스트를 더 쉽게 해주고 애플리케이션 침식에 더 탄력적으로 만들어 준다.

독립적 서비스

규모가 작은 자율적인 팀들이 팀별 서비스를 독립적으로 개발, 전개, 규모 확장을 할 수 있게 함으로써 병렬로 개발할 수 있게 합니다.
목표는 팀이 다른 팀과 독립적으로 서비스를 제공할 수 있도록 하는 것입니다.

서비스로서의 컴포넌트화

소프트웨어를 여러 서비스로 분리하는 것을 말한다.

기존 사용자 코드를 손상시키지 않기 위해 동일한 서비스 또는 동일한 서비스의 여러 버전에 여러 인터페이스를 사용하는 것과 같은 기술입니다.

또, 지속적인 리팩터링을 통해 각각의 서비스가 하나로 병합될 수 있게 허용한다.

• 컴포넌트
  독립적으로 대체하거나 업그레이드 가능한 소프트웨어 단위

• 컴포넌트화
  시스템을 구성 요소(Component)를 나누고 이를 연결하여 구축하는 것

라이브러리 vs. 서비스

구분	라이브러리로서의 컴포넌트화	서비스로서의 컴포넌트화
특징	라이브러리는 프로그램 내 링크되어, 메모리상에서 함수 호출을 함	개별적인 프로세스로, 각 프로세스가 HTTP 또는 RPC로 서로 통신함
배포 편의성	전체 응용 프로그램을 재배포해야 함	서비스 단위로만 재배포해도 됨
컴포넌트간 결합 (약해야 좋음)	강함 외부 라이브러리를 사용하는 프로그램의 입장에서, 해당 프로그램을 작성할 때에 대부분 라이브러리의 코딩 규칙을 따라가야 하는 경우가 많습니다. 그러다보면, 컴포넌트간의 지나친 결합을 불러옵니다.	약함 서비스는 명시적인 원격 호출 메커니즘을 사용하므로 이러한 종속 및 결합을 방지합니다.
호출 비용 (적어야 좋음)	적음 프로그램 내에 라이브러리가 링크되어 있으며, 메모리 상에서 호출하므로 호출 비용이 적음	높음 프로세스간 호출은 원격 호출이며, 종종 네트워크를 통해 호출하므로 호출 비용이 높음

비즈니스 수행에 따른 구성

기능이 아니라 서비스 단위로 팀을 구성합니다.

Before

기술적 계층에 따른 팀 분류

• UI 팀, 비즈니스 로직 팀, 데이터베이스 팀
• 단순한 변경이 필요한 경우에도 팀 간의 협업 비용이 증가함

After

비즈니스 수행 능력에 따른 팀 분류

• 쇼핑몰의 경우 회원/상품/배송이 각각의 도메인이 된다.
  • 도메인: 하나의 온전한 시스템 단위
• 팀이 하는 일이 하나의 서비스로 나뉘어짐
  • 장점: 소프트웨어 스택, 데이터베이스 선택, 프로젝트 관리 등이 팀 별로 독립적이다.
  • 각 팀은 서비스에 대한 책임을 가져야 한다.
  • 각 서비스는 메시지 버스를 통해 통신해야 한다.
  • 메시지 버스: 통신 인터페이스

현명한 엔드포인트와 바보 파이프라인

마이크로서비스에서 프로세스간 통신 방식으로 리눅스 파이프라인 철학과 흡사하다.

특징

다른 말로 표현하면 '서비스(엔드포인트)는 일을 하게 하고, 통신(파이프라인)은 최대한 단순하게 한다.'

대표적인 방법

• REST API (HTTP)
• 메시지 버스를 이용한 메시지 전달 (메시지 큐)

분산화 거버넌스, 분산화된 데이터 관리

거버넌스(Governance)란 원문 그대로 해석하면 통치, 관리, 통치 방식 이라는 뜻이다.
IT용어로 해석하자면 시스템을 개발하는 조직의 구조나 프로세스를 의미한다.

표준 프로세스와 가이드를 기반으로 전체 팀을 운용하는 모델을 중앙 집중형 거버넌스 모델 이라고 하는데 이러한 중앙 집중적인 시스템은 기술을 표준화하는 경향이 있다.

"우리 회사는 Java 9와 Oracle만 사용합니다"
"간단한 리포트 만드는 서비스가 필요한데, node.js로 금방하는 걸 Java를 꼭 써야해?"

문제 해결에 오히려 방해가 될 수 있음!

해결책

• 분산화된 시스템
  • 소프트웨어 스택, 데이터베이스 선택, 프로젝트 관리 등이 팀 별로 독립적이다.

장애 방지 설계

(모놀리틱 설계에 비해 불리한 지점)

• 서비스는 언제든지 실패 할 가능성이 있다.
• 신속하게 장애를 감지하고 가능하면 자동으로 서비스를 복구할 수 있어야 한다.
• 대시보드와 모니터링은 필수적이다.

진화하는 설계

컴포넌트가 개별적으로 대체 가능해야 하고, 업그레이드를 할 수 있어야 한다.

장점

• 모놀리스
  작은 변경 사항도 응용 프로그램 전체의 재배포를 필요로 한다.
• 마이크로서비스
  변경한 서비스만 다시 배포하면 된다.
• 간단하고 신속한 출시 프로세스

단점

기존 서비스에 대한 변경이 다른 서비스에 영향을 주는지 여부를 신경써야 한다.

마이크로서비스 아키텍처 구현 단계

구분	Level 0: 전통적 방식	Level 1: 기본	Level 2: 중급	Level 3: 고급
애플리케이션 아키텍처	모놀리식	서비스 지향 통합	서비스 지향 애플리케이션	API 중심
데이터베이스	어떤 경우에도 들어맞는 크기의 엔터프라이즈 DB	엔터프라이즈 DB + NoSQL, 경량 DB	폴리글랏(다중 언어 지원), 서비스로서의 DB	Data Lake, 준실시간 분석
인프라스트럭처	물리적 서버(베어메탈)	가상화	클라우드	컨테이너
모니터링	인프라스트럭처	애플리케이션과 인프라스트럭처	애플리케이션 퍼포먼스(APM)	APM 및 중앙화된 로그 관리 시스템
개발 프로세스	워터풀	애자일, CI	CI/CD	DevOps

표. A Microservices Maturity Model, from “Spring 5.0 Microservices,” 2nd Edition”by Rajesh R V (O’Reilly)

• 항상 모든 경우에 마이크로서비스 아키텍처가 필요한 것은 아닙니다.
• 성숙도 모델 중 어떠한 방식을 Level 3단계로 전환한다고 해서 더 나은 서비스가 되는 것은 아닙니다.
• 무작정 마이크로서비스 아키텍처를 도입하기 전에 다음을 이해한 후에 도입해야 합니다.
  • 각 단계에 있어서 해당 방식이 갖는 장,단점
  • 기존(Legacy) 시스템의 작동 방식
  • 현재 시점의 요구사항