읽은 책/[책] 마이크로 서비스 패턴

[3장] 프로세스 간 통신 - 1편

코드몬스터 2024. 12. 8. 10:04
728x90

 

※ 열심히 작성하고 있습니다.. 기다려 주세욧..!! ※

3장. 프로세스 간 통신

챕터 설명

  • 1편: 통신 스타일, API 명세서 및 메세지 포맷 내용
  • 2편: RPI 패턴의 REST와 gRPC, 비동기 메시징 패턴 내용

용어 설명

  • 프로세스 간 통신(Inter-Process Communication, IPC)이란 프로세스들 사이에 서로 데이터를 주고받는 행위 또는 그에 대한 방법이나 경로
  • 원격 프로시저 호출(Remote Procedure Inovacation, RPI): 프로세스 간 통신 기술로 별도의 원격 제어 코딩 없이 다른 주소 공간에서 함수나 프로시저를 실행
  • 정적 타입 언어(statically typed language): 자료형이 컴파일 타임에 결정되는 언어(예: C, C++, C#, JAVA)
  • 동적 타입 언어(dynamic typed language): 코드 실행시, 런타임에 타입이 결정되는 언어(예:Python, Javascript 등)

3.1 마이크로서비스 아키텍처 IPC 개요

서비스에 적용 가능한 IPC 기술의 선택 폭은 넓다.

  • HTTP 기반 REST나 gRPC 등 동기 요청/응답 기반의 메커니즘
  • AMQP, STOMP 등 비동기 메시지 기반의 통신 메커니즘
  • 메세지 포맷 역시 JSON, XML 처럼 인간이 읽을 수 있는 텍스트 포맷부터
  • 아브로(Abvro)나 프로토콜 버퍼(Protocol Buffer)처럼 효율이 우수한 이진(Binary) 포맷까지 다양

3.1.1 상호 작용 스타일

클라이언트/서비스 상호 작용 스타일은 다양하지만 두 가지 기준으로 분류 가능

  1. 일대일/일대다 여부
    • 일대일: 각 클라이언트 요청은 정확히 한 서비스가 처리
    • 일대다: 각 클라이언트 요청을 여러 서비스가 협동하여 처리
  2. 동기/비동기 여부
    • 동기(synchronous): 클라이언트는 서비스가 응답하리라 기대하고 대기
    • 비동기(ansynchronous): 클라이언트가 블로킹 하지 않는다. 응답을 즉시 전송하지 않아도 됨.

일대일 상호 작용 종류

  • 요청/응답: 클라이언트는 요청을 하고 응답을 기다린다.
  • 비동기 요청 응답: 클라이언트는 요청을 하고 서비스는 비동기적으로 응답
  • 단방향 알림: 클라이언트는 일방적으로 요청만 하고 서비스에 서비스는 응답을 보내지 않음

일대다 상호 작용

  • 발행/구독: 클라이언트는 알림 메시지를 발행하고, 0개 이상의 서비스가 메세지를 소비
  • 발행/비동기 응답: 클라이언트는 요청 메세지를 발행하고 주어진 시간 동안 서비가 응답하길 기다림.

3.1.2 API 정의 및 발전시키기

API와 인터페이스는 소프트웨어 개발의 핵심이다.

 

애플리케이션은 여러 모듈로 구성되며, 각 모듈마다 자신의 클라이언트가 호출하는 작업이 정의된 인터페이스가 있다.

잘 설계된 인터페이스는 기능을 표출하되 그 구현체는 감추어져 있기 때문에 클라이언트에 영향을 미치지 않는다.

 

어떤 IPC를 선택하든, 서비스 API를 IDL(Interface Definition Language, 인터페이스 정의 언어)로 정확하게 정의를 해야한다.

책에서는 반드시 API를 먼저 설계해야 한다고 한다.(API 우선 개발)

 

1) 시맨틱 버저닝

시맨틱 버저닝 명세(Semvers, Sementic Versioning specification)은 API 버저닝에 관한 유용한 지침서이다.

(원래 소프트웨어 패키지의 버저닝 용도로 쓰였지만, 분산 시스템의 버저닝에도 사용할 수 있다.)

버전 번호를 사용하고 증가시키는 규칙들이 명시되어 있다.

  • MAJOR: 하위 호환되지 않는 변경분을 API 적용 시
  • MINOR: 하위 호환되는 변경분을 API에 적용 시
  • PATCH: 하위 호환되는 오류 수정 시

REST API라면 메이저 버전을 URL 경로의 첫 번째 엘리먼트로 사용

메시징 기반의 서비스라면 발행한 메시지에 버전 번호를 넣을 수 있다.

 

2) 하위 호환되는 소규모 변경

변경을 하더라도 가급적 하위 호환성을 보장하는 방향으로 해야 한다.

  • 옵션 속성을 요청에 추가
  • 속성을 응답에 추가
  • 새 작업을 추가

위와 같은 종류의 변경은 새 서비스에 적용해도 기존 클라이언트 역시 문제 없이 동작해야 한다.

 

"당신이하는 일은 보수적으로, 다른 사람들이 하는 일은 관대하게 바라보라"는 견고성 원칙(Robustness principle)을 지키자. 

 

3) 중대한 대규모 변경

기존 버전과 호환이 안 되는 변경을 API에 적용해야 할 때가 있다.

HTTP 기반의 REST API라면 URL에 메이저 버전 번호를 삽인할 수 있다.

(버전 1 경로는 앞에 /v1/, 버전 2 경로는 /2/ 를 붙임)

3.1.3 메세지 포맷

1) 텍스트 메시지 포맷

텍스트 메시지의 단점은 메세지가 다소 길고 메시지에 속성값 이외에 속성명이 추가되는 오버헤드가 있고, 덩치가 큰 메시지는 텍스트를 파싱하는 오버헤드도 있다.

  • JSON 메세지는 네임드 프로퍼티로 메시지 프로퍼티의 이름/타입 및 필수/옵션 여부가 정의된 JSON 스키마 표준이 제정되었음.(http://json-schema.org)
  • XML 메시지는 네임드 엘리먼트와 그 값을 모아 놓는 구조로 XML 스키마로 명시한다.

2) 이진 메시지 포맷

종류가 다양하지만 프로토콜 버퍼와 아브로가 유명하다.