그림으로 공부하는 마이크로서비스 구조 / 다루사와 히로유키 외 6명

그림으로 공부하는 마이크로서비스 구조

마이크로서비스란 IaaS 이후 빨라진 인프라 구축 속도에 맞추어 애플리케이션 개발/운영을 신속하게 진행하기 위해 필요한 설계, 개발, 운영 기법을 모은 것.

클라우드 네이티브 컴퓨팅

컨테이너, 오케스트레이션, 마이크로서비스

• 개발/운영속도 향상 품질 개선
  • 컨테이너와 오케스트레이션을 이용한 빠른 기반 구축
  • 데브옵스는 인프라, 애플리케이션 배포를 자동화
    • 빠른 개발, 테스트, 배포를 가능하게 하고, 자동화를 통해 조작 실수를 최소화하여 품질 향상에 기여
• 확장성(scalability) 고가용성(high availability)
  • 오케스트레이션을 활용하여 클러스터를 쉽게 관리
  • 하이브리드 클라우드 환경 구축
  • 오케스트레이션이 제공하는 부하분산, 확장, 자가 복구 기능 활용
• 비용 절감
  • 다른 클라우드 서비스 플랫폼으로 손쉽게 마이그레이션 가능
  • 멀티 클라우드 환경 쉽게 구축

컨테이너

서버 가상화

리눅스 커널 기능을 이용해서 OS 수준의 가상 환경을 실현. 하나의 리눅스 OS상에 여러개의 가상 환경 호스팅.

• 각 가상환경 이미지가 OS를 가지고 있지 않아도 되므로 배포/실행이 빠르다

컨테이너 오케스트레이션

마이크로서비스 스타일로 설계한 경우 관리해야 할 클러스터 멤버가 늘어난다. 컨테이너 오케스트레이션은 컨테이너 클러스터의 관리/운영을 중심으로 컨테이너 클러스터 배포, name resolution, routing, service discovery, load balance, scalability, self-healing등의 기능을 제공한다. (컨테이너 애플리케이션의 생명주기 관리)

데브옵스

개발팀과 운영팀의 작업효율화

IT 시스템 개발/릴리즈 속도 향상과 유연한 변경을 애플리케이션 개발/운영의 효율화 관점에서 실현

개발팀과 운영팀의 연계를 위한 조직 혁신 : 데브옵스

• 연계를 위한 기법 : 애자일 개발 프로세스
• 원활한 연계를 위한 효율화 : CD 파이프라인

마이크로서비스

서비스(독립적으로 개발 및 실행되는 소프트웨어 컴포넌트)를 여러 개 조합해서 하나의 애플리케이션을 구축하는 소프트웨어 구조. 하나의 요청을 처리하기 위해 각 서비스는 REST나 메시징으로 통신하는 분산 컴퓨팅 환경을 구성한다.

필요 기술: 컨테이너, 오케스트레이션, REST, 메시징 등

필요 기법: 데브옵스, 애자일 개발 프로세스, CD, 도메인 주도 설계(Domain Driven Design)

장점

• 애플리케이션을 작은 단위로, 단계적으로 릴리즈 및 변경할 수 있어 유연함
• 작은 단위로 scale-out, scale-in 가능하다는 관점에서 시스템 리소스를 최적 사용
• 서킷 브레이커와 조합해 장애 범위를 국소화

단점

• 서비스간 통신 지연 우려
• 분산 배치된 DB간 일관성, 동기화 기법 필요
• 분산 컴퓨팅 환경의 운영 구조 정비 필요
• 시스템 전체의 설계 일관성 필요

콘웨이 법칙(Cornway’s law): IT 시스템의 구조는 프로젝트 체제를 반영한다. 즉, 하나의 서비스를 개발, 운영할 때 하나의 팀이 담당한다.

마이크로서비스는 대규모 비즈니스 도메인의 디지털 화, 100명 규모의 대규모 개발팀, 여러 시스템의 통합 등이 필요한 대규모 시스템 개발에 적합하다.

마이크로서비스 아키텍처 변형

레이어 아키텍처

추상적인 것(애플리케이션)이 구체적인 것(인프라)에 의존

• 사용자 계층
  • 사용자 인터페이스 구축 및 렌더링
  • 요청/응답 전송
• 애플리케이션 계층
  • 애플리케이션 조율
  • 도메인 객체 접근
  • 트랜잭션 관리
• 도메인 계층
  • 도메인 상태와 동작(비즈니스 로직) 구현
• 인프라 계층
  • 외부 리소스가 다른 계층에 접근할 수 있도록 지원(데이터, 메시징 접근)

장점 : 간단하고 이해하기 쉬움

단점 : 확장성이 약하다. 추상적인 것이 구체적인 것에 의존하고 있어 인프라 구현이 변경될 경우 사용자 인터페이스나 애플리케이션에도 영향을 끼쳐 프로그램을 수정해야 한다.

헥사거널 아키텍처

레이어 아키텍처의 단점을 IoC로 보완하여 불특정 데이터 입출력에 대응하는 아키텍처.

도메인을 중심으로, 그 주변에는 도메인을 호출하는 입력 측과 도메인에 의해 실행되는 출력측이 있다.

외부 입출력과 도메인 사이의 ‘포트&어댑터’

어댑터는 외부 기능과 상호 작용하는 역할을 하며 외부 기능 단위로 교체할 수 있다. 그 예로 컨트롤러가 있다. 추상화 된 프로그래밍 인터페이스를 도메인에 제공하는 것이 포트이다(인터페이스). 포트를 사용해서 외부 기능에 접근하는 코드를 도메인 내에 구현해두면, 외부 기능을 변경해도 도메인은 영향 받지 않는다.

마이크로서비스 트랜잭션 처리

로컬 트랜잭션이란? 하나의 트랜잭션 컨텍스트내에서 처리 대상 리소스를 제한하는 것

예를 들어 마이크로 서비스에서 하나의 서비스가 하나의 데이터베이스를 포함하고 트랜잭션 컨텍스트 내에서 해당 데이터베이스만 대상으로 하는 것.

<-> 글로벌 트랜잭션이란? 하나의 트랜잭션 컨텍스트내에서 여러 리소스를 처리하는 것

글로벌 트랜잭션은 마이크로서비스의 목표인 단순함, 두 컴포넌트 사이의 느슨한 결합을 방해하므로 지양해야 한다.

데이터베이스간 동기화

Saga 디자인 패턴

분산 트랜잭션에서 마이크로 서비스 간 데이터 일관성을 관리하는 방법.

첫번째 서비스가 첫번째 데이터베이스를 변경, 메시징 구조를 이용해 다음 서비스로 이벤트를 전달하여 로컬 트랜잭션을 릴레이로 연결한다.

장애에 의해 서비스가 데이터베이스 변경에 실패한 경우 saga 패턴은 보상 트랜잭션을 실행한다. 트랜잭션 처리 결과를 원래대로 돌려놓기 위해 반대방향으로 처리하는 것이다.

단점은 각 로컬 트랜잭션이 독립되어 있다 보니 특정 시점에는 데이터베이스 간 일관성이 유지 되지 않는다는 것이다.

데이터 결합

여러 데이터베이스에 나누어져 있는 데이터들을 하나의 View로 제공하려면 어떻게 해야 할까?

API 컴포지션

어플리케이션 계층에서 인메모리로 도메인 계층의 집약 서비스와 인프라 계층의 리포지터리 서비스를 통해 얻은 복수개의 데이터베이스들로 얻은 데이터를 결합

장점 : 설계와 구현이 단순하다

단점 : 애플리케이션에서 운영환경의 메모리 내에서 결합을 하게 되면 시스템 리소스에 부담을 주게된다.

CQRS & 이벤트 소싱

CQRS(Command Query Relation Segregation, 명령 질의 책임 분리)

데이터 접근 처리를 갱신형 처리(command, C,U,D)와 참조형 처리(질의, R)로 구분하고 각 독립된 서비스 컴포넌트와 데이터 저장소를 두는 디자인 패턴.

• 참조형 처리 : 일반적으로 요청량이 방대하며 빠른 응답을 필요로 한다.
• 갱신형 처리 : 요청량이 많지 않지만 안전하고 확실한 트랜잭션을 필요로 한다.

이벤트 소싱

갱신형 저장소와 참조형 저장소는 동기화되어야 한다.

이벤트 소싱에서는 비즈니스 데이터를 분할하지 않고 모아서 하나의 데이터 저장소(event source)에 저장한다. 이벤트 소스는 대상 비즈니스에 대한 하나의 데이터 저장소이므로 글로벌 트랜잭션을 피할 수 있다.

그러나 빠른 검색에는 적합하지 않다. 그래서 필요에 따라 메시징 기반 미들웨어의 비동기 메시징을 사용해 이벤트 소스와 검색용 데이터 저장소를 동기화한다. 이벤트 소스에 갱신 트랜잭션이 발생할 때 마다, 또는 이벤트 소스의 갱신 트랜잭션 수가 일정수에 도달하거나 일정 시간 간격으로 동기화하는 방법이 있다.

장점:

• 쿼리 구현의 용이성
• 데이터 감시와 접근 제어 구현의 용이성
• 서비스 모델링과의 친화성
  • 온라인 쇼핑의 발주 처리와 과거 주문 이력 검색 처리를 다른 컴포넌트로 분리할 수 있다.

단점: 기존 설계방식과 상이하기 때문에 적합한 사용처라는 것을 검증해야 한다.

서비스 간 연계

REST

동기형 프로토콜이기 때문에 서비스 로직이 복잡하고 처리 완료까지 시간이 걸리는 처리에는 적합하지 않다. 응답 지연이 발생하고, 클라이언트 요청이 쌓이며 서버 리소스를 고갈시켜 장애를 발생시킬 수 있기 때문이다.

메시징

MOM(Messaging Oriented Middleware)을 통해서 생산자와 소비자가 메시지를 주고 받는 통신 모델.

• 단방향&비동기형
• 요청/응답&동기형
• 요청/응답&비동기형

마이크로 서비스에는 비동기 메시징을 사용해야 하는 경우가 자주 있다. (CQRS의 결과적 일관성, Saga)

서비스화 진행 방법

마이크로 서비스의 애플리케이션 개발/운영 기법

• 애자일 개발 프로세스
  • 애플리케이션을 신속하게 단계적으로 릴리즈하는 것에 기여한다
• 콘웨이 법칙에 기반한 팀 체계
  • 팀 규모를 작게 유지하고 비즈니스, IT 전문가들이 모두 같은 팀에 속하게 한다.
• DDD
  • 도메인 모델을 설계 및 개발 작업의 중심에 두고 반복적으로 변경 및 진화시켜 프로그램 구현으로 이어지게 하자
  • 유비쿼터스 언어 : 팀 멤버가 오해없이 커뮤니케이션하기 위해 만드는 공통 용어집

큰 단위로 시작하자

세분화 정도나 경계가 있는 컨텍스트가 최적화되어있는지는 시스템 운영 직전에 알 수 없다. 따라서 모노리스 우선으로 개발해서 필요에 따라 서비스화를 진행하자.

세션 정보 유지

여러 방면에서 처리 상태를 유지해야 하는 경우,

• 세션 영구화
  • 처리 중인 상태를 데이터베이스 등의 영구적 데이터 저장소에 저장
• 스티키 세션
  • 처리 상태가 저장되어 있는 서버에 클라이언트 요청을 전송
  • 쿠버네티스의 Ingress가 세션 어피니티 기능 제공
• 상태의 서비스화 기법
  • 상태를 유지하기 위한 서비스를 신설하고 데이터베이스 등의 영구 저장소에 저장한다
  • ex) 장바구니 서비스

마이그레이션 기간 중의 의존관계

시스템 개선에 마이크로서비스를 이용할 경우 신규 서비스가 기존 모노리스에 의존하지 않게 하자. 반대는 괜찮다. 기존 모노리스가 미래에 신규 서비스로 교체되거나 파기될 수 있기 때문.

마이크로서비스 패턴

데이터 관리 : 데이터베이스 배치 모델

분산 데이터베이스에서 데이터 접근 모델을 설계하려면 아래 과제들을 해결해야 한다.

• 데이터베이스 배치 모델
• 데이터 동기화
• 데이터 결합
  • API 컴포지션, CQRS&이벤트 소싱

서비스별 데이터베이스 패턴

• 데이터베이스 인스턴스를 서비스 단위로 작성/운영한다.
• 장점 : 유연하고 빠르게 애플리케이션, 데이터베이스 제품 및 기술을 유연하게 선택 가능
• 고려 사항
  • 결과 일관성이 허용되는지
    • 분산 트랜잭션을 권장하지 않으므로
  • 데이터간 동기화 구조
    • 사가 패턴 이용
  • 여러 데이터베이스에 걸쳐있는 데이터를 검색 및 집약하는 구조
    • API 컴포지션, CQRS&이벤트 소싱

공유 데이터베이스 패턴

• 결과 일관성이 허용되지 않는 경우
• 통합된 하나의 데이터베이스 인스턴스를 복수의 서비스 및 애플리케이션, 시스템이 공유할 수 있는 데이터베이스 배치 패턴
• 장점
  • 로컬 트랜잭션을 사용한 ACID 특성을 유지하고 데이터 일관성 확보
• 단점
  • 애플리케이션과 데이터베이스를 신속하고 유연하게 변경하는 것이 어렵다
  • 단일 데이터베이스에 처리가 집중된다
  • 비관적 락(pessimistic locking)을 건 후 변경을 처리해야 해서 순차적으로 처리해야 한다

사가 패턴

• 로컬 트랜잭션 이벤트와 보상 트랜잭션을 활용하여 여러 데이터베이스에 걸쳐 있는 데이터를 동기화하는 기법
• 구현 기법
  • 코레오그래피(choreography)
    • 각 서비스가 자립적으로 메시지 제품상에서 데이터를 동기화. 이벤트를 이용해 로컬 트랜잭션과 보상 트랜잭션 흐름을 제어한다.
    • 장점 : 구조가 단순하다
    • 고려사항
      • 각 서비스 내부에는 서비스 간 연계 흐름 제어 로직이 구현되어 있으므로 사가 전체를 파악하기 어렵다
      • 트랜잭션 실행 시의 진행 상태 확인이나 추적이 어렵다
      • 관심사 분리가 저해됨
        • 비즈니스 로직을 구현해야할 서비스 내부에 사가 제어 로직이 들어가기 때문
  • 오케스트레이션
    • 사가 오케스트레이터가 트랜잭션 처리를 조율한다
    • 장점 :
      • 서비스의 역할분담이 명확하다
      • 각 서비스와 DB의 연계 파악이 쉽다 (프로세스 진행 상황을 파악하기 쉽다)
    • 고려사항
      • 오케스트레이터가 무거워지지 않도록 역할분담에 유의해야한다

트랜잭션 메시징

서비스 내의 데이터베이스와 메시징 간 일관성

트랜잭셔널 아웃박스 패턴

• 트랜잭셔널 아웃박스 : 비즈니스 데이터를 저장하는 데이터베이스와 동일한 데이터베이스 내에 테이블을 만들어, 비즈니스 데이터 처리를 통지하는 이벤트 정보를 저장 및 공유할 때 사용한다.
• 비즈니스 데이터와 로컬 트랜잭션으로 동기화

폴링 퍼블리셔 패턴

• 아웃박스 테이블을 읽는 메시지 릴레이가 아웃박스 테이블을 폴링
• 장점 : 애플리케이션으로 구현이 쉽다.
• 고려할 점 : 퍼블리셔는 사용자가 정의한 아웃박스 테이블에 의존하므로 아웃박스 테이블 유지/관리도 고려해야한다.

트랜잭션 로그 테일링 패턴

• 서비스가 로컬 트랜잭션을 이용해 업무 테이블을 갱신함과 동시에 처리내용을 DBMS가 제공하는 트랜잭션 로그에 기록. 트랜잭션 로그 마이너는 트랜잭션 로그에 기록된 로그 엔트리를 취득하여 MOM에 발행한다.
• 장점 : 아웃박스 테이블 유지/관리할 필요가 없다. DBMS가 제공하는 트랜잭션 로그를 사용하기 때문
• 고려할 점 : 데이터베이스 제품마다 트랜잭션 로그 사양이 다르기 때문에 제품 단위별로 트랜잭션 로그 마이너를 구현해야한다.

서비스 검색

서비스 배포 시마다 도메인명과 IP 주소가 변경될 위험이 있다. 클라이언트는 서비스 호출 이전에 서비스의 정확한 주소를 파악해야 한다.

클라이언트 측 검색(client-side discovery)

• 서비스의 주소 파악을 클라이언트가 한다.

서버 측 검색(server-side discovery)

• 서비스의 주소를 서버측 컴포넌트에 위임한다.
• 업무 프로그램과 분리된 컴포넌트이며, 애플리케이션 코드 구현 없이 외부장치로 구현할 수 있다.
  • 부하분산기, 프록시 등

서비스 레지스트리 패턴

• 마이크로서비스에서 서비스명을 해석하는 컴포넌트. 서비스명 해석을 위한 영구 데이터 저장소

자가 등록 패턴(self registration)

• 배포 시에 서비스가 자신의 도메인 명과 주소 정보를 매핑한 위치정보를 서비스 레지스트리에 등록하는 패턴
• 장점 : 애플리케이션 로직으로 등록 처리를 구현해, 모든 요건에 유연하게 대응할 수 있다
• 고려할 점 : 서비스 헬스 체크나 장애 발생 시 복구처리에 대한 유지/관리 필요

외부자 등록 패턴(3rd-party registration)

• 서비스 레지스트리 위치 정보 등록을 3rd party에게 위임하는 패턴
  • 쿠버네티스같은 오케스트레이션 프레임워크에게 위임
• 장점 : 정보 등록 작업을 줄여줄 수 있다

외부 API

마이크로서비스에서 클라이언트와 서비스 연동 시에 발생하는 문제들을 해결한다.

API Gateway 패턴

• 도메인 경계에 클라이언트 처리를 담당하는 전용 API 게이트웨이를 배치하는 것
  • 클라이언트와 서비스 간에 목적 단위로 전용 API 게이트웨이를 배치하여 애플리케이션의 조율, 트랜잭션 제어 등의 처리를 구현한다
  • 도메인 주도 설계의 애플리케이션 서비스, GoF 디자인 패턴의 파사드에 해당한다
• 장점 :
  • 클라이언트와 서비스간 호출 횟수를 줄여 네트워크 지연 최소화
  • 서비스측 변경 시에도 API 게이트웨이가 완충하여 클라이언트 측 영향을 최소화한다.
  • 인터넷과 인트라넷 간 통신 프로토콜 교환을 담당할 수 있다.
• 고려할 점 :
  • 특별한 요건이 없는, 인증과 허가, 로그, 메트릭스, 부하분산, 캐시 등 비기능 요건을 API 게이트웨이 제품 사용이 아닌 사용자 애플리케이션으로 구현하는 것은 시간 낭비다.

프론트엔드용 백엔드 패턴(BFF, Backends For Frontend)

• 클라이언트 종류별로 게이트웨이 처리를 적용한다
• 장점 :
  • 다양한 클라이언트 종류를 지원한다.
    • 특정 클라이언트에 대해 게이트웨이 처리 로직을 변경해야 하는 경우 다른 클라이언트가 영향을 받지 않도록 한다.
  • API 게이트웨이와 클라이언트 고유의 게이트웨이 기능을 분할할 수 있다.

통신

REST 프로토콜의 경우 요청/응답 및 동기형 통신 고유의 다양한 문제점들이 있다. 클라이언트와 서비스, 서비스간 연동을 최적화하기 위해 REST 프로토콜의 문제점을 해결하는 프로토콜을 살펴보자.

원격 프로시저 호출 패턴(RPI, Remote Procedure Invocation)

• 요청/응답 및 동기형 통신
  • REST가 대표적인 구현
• 장점 :
  • 쉽고 간단하고 범용적
• 고려할 점:
  • 확장성이 약하다
  • 복잡하고 시간이 오래 걸리는 처리에 적합하지 않다
    • 지연이 있으면 응답 연장, 클라이언트 요청이 쌓이며 서버 리소스가 고갈된다

메시징 패턴

• 비동기적 통신. 발행자와 구독자가 이벤트를 통해 통신하는 모델. MOM 또는 메시지 브로커를 통해 이벤트나 메시지를 비동기적으로 전달한다.
  • 발행자가 이벤트를 생성할 때 구독자를 항상 실행할 필요가 없으며, 구독자가 원할 때 MOM 토픽에 저장되어있는 이벤트를 가져올 수 있다.
• 일방향&비동기형, 요청/응답&동기형, 요청/응답&비동기형 세가지 통신 사용 가능

도메인 특화 프로토콜 패턴(domain-specific protocol)

• 특정 상황에 맞는 프로토콜을 적용하는 패턴
  • 메일 발신 - SMTP
  • 메일 수신 - POP, IMAP

멱등 소비자 패턴(idempotent consumer)

• 의도하지 않은 작업에 멱등성을 보장하는 통신 패턴
  • 작업 단위별 고유 ID를 할당해 같은 작업의 중복 실행을 방지한다

배포

호스트별 다중 서비스 인스턴스(multiple service instance per host)

• 한대의 호스트에서 다중 서비스를 실행하는 모델
• 장점 :
  • 호스트 관리가 용이하다
  • 하나의 가상 머신에서 여러 서비스를 실행해 전체 리소스를 줄일 수 있다
• 고려할 점 :
  • 모니터링과 장애 관리 관점에서 개별 서비스의 상태를 확인하기 어렵다
  • 특정 서비스에 큰 부하가 걸린 경우, 다른 서비스가 사용할 수 있는 리소스가 줄어들어 성능에 영향을 끼칠 수 있다
  • 한대의 호스트가 단일 장애 지점이 되므로 서비스 전체에 영향을 줄 수 있다
  • 여러 서비스들이 의존 관계에 있는 경우, 배포나 확장성 설계가 복잡해진다

호스트별 단일 서비스 인스턴스

• 호스트마다 하나의 서비스를 가지는 모델
• 장점 :
  • 장애 관리 효율이 높다. 특정 호스트가 정지되어도 다른 서비스들은 영향을 받지 않으므로
  • 독립적으로 서비스 확장이 가능하다
• 고려할 점 :
  • 호스트 수가 늘어나면 비용도 함께 늘어난다

VM별 서비스 인스턴스

• 배포 대상으로 하이퍼바이저형 가상 머신(하드웨어 수준의 가상화)을 사용하는 패턴
• 서비스 수가 적은 애플리케이션에서는 컨테이너 가상화 기반보다 적은 비용으로 쉽게 배포할 수 있는 경우가 있다
• 장점 :
  • 서비스 인스턴스를 패키지화할 수 있다
    • 하나의 가상 머신 이미지로 서비스 인스턴스 실행에 필요한 OS, 각종 미들웨어, 애플리케이션 설치, 설정, 검증 완료된 상태로 패키지화하여 배포가 용이해진다.
    • 배포 시기를 단축한다
  • 서비스 인스턴스를 분리할 수 있다
    • 서비스 인스턴스 성능을 독립된 형태로 유지할 수 있다. 각 가상 머신 리소스를 고정해서 할당할 수 있으므로
• 단점 :
  • 배포에 시간이 걸린다
    • 가상머신은 OS를 포함하고 있어서 이미지 사이즈가 커진다
  • 리소스 사용법이 비효율적이다
  • 시스템 관리 비용이 높아진다

컨테이너별 서비스 인스턴스

• 컨테이너(OS 수준의 가상화 기술)를 사용해 서비스 인스턴스를 구성하는 패턴
• 장점 :
  • 배포 속도가 빠르다
  • 리소스 효율이 높다
    • 컨테이너들이 호스트 OS의 커널을 공유
  • 이동성이 좋다
• 단점
  • 컨테이너 기반 구축 운영이 쉽지 않다
    • 구축한 컨테이너 기반을 계속 운영하는 Day2 작업이 필요
      • 오케스트레이션 자체의 보수나 컨테이너가 실행되는 워커 노드 자체의 유지/관리가 필요하다

서버리스 배포

• 퍼블릭 클라우드가 제공하는 서버리스 서비스를 사용해 서비스를 배포하는 패턴
• HTTP를 사용하는 웹앱이나 모바일 앱에서 이벤트나 호출을 받으면 서버리스 서비스를 사용해서 애플리케이션 로직을 실행
• 장점 :
  • OS와 런타임 유지/관리가 불필요해서 애플리케이션 개발에 집중할 수 있다
  • 서비스 부하에 따라 자동으로 확장/축소 된다
  • 서비스 요청량을 기준으로 과금된다
• 단점
  • 지연이 발생한다
    • 애플리케이션 인스턴스를 프로비저닝하므로 애플리케이션 실행까지의 시간이 걸린다
  • 이벤트/요청 기반의 프로그래밍 모델로 제한된다
    • 기본적으로 지연 시간 때문에 이벤트/요청 기반의 서비스에만 사용이 가능하다.

관찰 가능성(observability, 가시성)

마이크로서비스의 논리적 물리적으로 분산 배치된 각 서비스와 관련 컴포넌트를 어떻게 빠짐없이 감시할 수 있을까?

분산 추적

• 각 요청 또는 이벤트 단위로 고유 ID를 할당하고 로그나 트레이스에 기록하는 패턴
  • 처리 상황과 장애 원인을 추적하게 쉽게 한다

로그 통합

• 마이크로서비스와 같은 분산 컴퓨팅 환경에서의 로그 분산 문제를 해결하기 위해 로그를 한곳에 모으는 패턴
  • Stslog, Fluentd

예외 추적(exception tracking)

• 예외를 관리해서 운영 담당자에게 통지하는 패턴
  • 사전에 설정한 키워드를 포함하는 로그를 감지한 경우, 운영담당자에게 알린다

애플리케이션 매트릭스

• CPU 사용률과 메모리 등 시스템 리소스 사용 상태, 처리수와 응답시간 등의 메트릭 수집해서 감시하는 패턴
  • 오케스트레이션 프레임워크에서 분산 배치된 서비스의 확장을 관리하기 위해 애플리케이션 런타임 상태를 파악한다

audit logging

• 마이크로서비스의 사용자 활동 통계와 분석을 목적으로 하는 패턴
  • 문제 발생 시 지원, 문제 재현을 통한 분석에 사용
  • 보안 방어, 기업 규정 위반 확인에 사용
    • audit log와 함께 마이크로 세그멘테이션에 의한 제로 트러스트와 같은 대책이 사용된다

health check API 패턴

• 각 서비스의 호출 가능 상태를 파악하는 패턴
  • 감시 주체
    • 라우팅이나 부하분산을 담당하는 컴포넌트가 담당
    • 서비스 레지스트리가 담당
      • 서비스 레지스트리가 서비스의 각 인스턴스 상태에 따라 클라이언트나 라우터에 반환하는 서버 주소를 변경
      • 클라이언트는 정상적으로 실행되고 있는 서비스 인스턴스로 요청을 전달할 수 있다

리팩터링

개발이 끝난 시스템을 클라우드 네이티브 애플리케이션으로 마이그레이션할 때

부패방지 계층(anti-corruption layer)

• 서비스와 모노리스 연계 시 통신 프로토콜 또는 애플리케이션 프로토콜 차이를 해결하기 위해 어댑터를 두는 패턴
  • 서비스가 모노리스에 의존하지 않고 양쪽을 연계한다

스트랭글러 애플리케이션(strangler application)

• SOE(System of Engagement)와 클라이언트의 경계인 스트랭글러 포드(strangler pod)를 개발 및 배치한다. 각 단계의 마이그레이션이 끝나면 애플리케이션 요청이 마이크로서비스화된 서비스로 라우팅 되도록 스트랭글러 포드의 메뉴 아이템이 가리키는 URI를 변경한다.
• 장점 :
  • 마이그레이션 작업 후 바로 서비스를 릴리즈한다
    • 사용자가 서비스를 빠르게 접할 수 있도록 함
    • 경영진에게도 구체적인 성과를 보여주는데 효과적
  • 신규 릴리즈한 클라우드 네이티브 애플리케이션에서 장애 발생시 모노리스로 다시 되돌리기 쉽다
    • 스트랭글러 포드상의 메뉴 아이템 URI를 변경
  • 작업을 단계적으로 진행 가능

서비스 메시

서비스 간 상호 통신이 그물 형태로 연결되어 있어서 마이크로 서비스 간 통신을 관리해주는 구조

• 서비스 메시는 control plain, data plain 두개의 컴포넌트로 구성
  • control plain : 서비스 메시를 관리
    • 서비스 검색 등 관리에 필요한 정보 보관하거나 구성 변경 등의 관리 명령을 내린다.
  • data plain :
    • control plain이 내린 지시를 받아 서비스 통신을 제어하거나 관리에 필요한 정보를 control plain에 전송한다.
    • 서비스 구현에 내장되는 것이 아니라 별도의 컴포넌트로 배포 (사이드카 패턴)
• 서비스 메시로 할 수 있는 것
  • 서비스 검색과 부하 분산
  • 트래픽 제어
  • 서킷 브레이커
  • 분산 추적을 위한 원격 측정 데이터 수집
  • 보안

서비스 검색과 부하 분산

1. 각 서비스가 배포나 재시작 시에 IP주소가 변경되면 data plain이 IP주소를 control plain에 통지한다.
2. control plain은 각 서비스의 주소를 관리한다.
3. 서비스에 접근하는 쪽의 data plain은 control plain에서 접근할 서비스의 주소 정보를 입수한다.

트래픽 제어

서비스에 접속을 할당하기 위한 설정을 변경하거나 서비스가 반환하는 값을 변경하는 드으이 서비스간 통신을 제어할 수 있다.

1. data plain이 요청을 control plain에 전달
2. control plain은 요청에 따라 다음과 같은 제어가 가능하다
   1. 트래픽 분할 : 요청 접속 위치를 비율로 나눈다
   2. 조건에 따른 트래픽 분리 : 요청 내용 관련 조건을 설정해 접속 위치를 변경
   3. 장애 주입 : 장애 상태를 만들어 효과적으로 테스트 할 수 있다
3. data plain이 실행

서킷 브레이커

특정 서비스에 장애가 발생했을 때 영향 범위를 최소화 하기 위한 도구

• 장애발생을 감지해 일정시간 장애가 발생한 서비스 접근을 절단, 서비스 호출 측에 오류를 바로 반환한다
  • 타임아웃 대기를 배제하여 시스템 전체 지연을 방지
• 서비스 회복을 감지하면 해당 서비스 접근을 원래대로 복구한다

분산 추적을 위한 원격 측정 데이터 수집

하나의 요청이 여러 서비스에서 사용될 때 호출되는 순서나 각 서비스에서의 처리 시간 등 요청을 추적하는 구조

보안

서비스 메시는 서비스가 다른 서비스를 호출할 때 인증 및 허가 등의 보안 기능을 제공한다.

• control plain은 data plain에 인증 및 허가 방침을 배포한다
• control plain은 data plain에 전자 인증서를 배포한다
• 서비스 호출 측과 호출되는 서비스 측이 상호 TLS 인증으로 통신할 수 있다