3장 프로세스간 통신
3장 프로세스간 통신
목차
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
3장 프로세스 간 통신
3.1 마이크로서비스 아키텍처 IPC 개요
3.1.1 상호 작용 스타일
3.1.2 마이크로서비스 API 정의
3.1.3 API 발전시키기
3.1.4 메시지 포맷
3.2 동기 RPI 패턴 응용 통신
3.2.1 동기 RPI 패턴: REST
3.2.2 동기 RPI 패턴: gRPC
3.2.3 부분 실패 처리: 회로 차단기 패턴
3.2.4 서비스 디스커버리
3.3 비동기 메시징 패턴 응용 통신
3.3.1 메시징 개요
3.3.2 메시징 상호 작용 스타일 구현
3.3.3 메시징 기반 서비스의 API 명세 작성
3.3.4 메시지 브로커
3.3.5 수신자 경합과 메시지 순서 유지
3.3.6 중복 메시지 처리
3.3.7 트랜잭셔널 메시징
3.3.8 메시징 라이브러리/프레임워크
3.4 비동기 메시징으로 가용성 개선
3.4.1 동기 통신으로 인한 가용성 저하
3.4.2 동기 상호 작용 제거
3.5 마치며
정리 전략?
- 전부 정리는 NO
- 핵심중에서 꼭 적고 가야겠다 싶은 것만!
- 나의 생각을 섞어서 적을것..!
- 떠오르는 것 먼저 간단하게..!
내용 정리 3장 프로세스 간 통신
3.1 마이크로서비스 아키텍처 IPC 개요
- 3.1.1 상호 작용 스타일
- 동기 방식 vs 비동기 방식.
- 동기 방식 - REST, GRPC
- 비동기 방식.
- 요청과 응답받을 채널을 명시해서 비동기 호출하기.
- 메세지 브로커를 사용해서 큐에 메시지 보내기.
- 3.1.2 마이크로서비스 API 정의
- 3.1.3 API 발전시키기
- 시멘틱 버저닝
- 메이저, 마이너, 패치로 나뉜다.
- path에 넣을 수도 있고, 헤더에 정보를 담을 수 도 있다.
- 시멘틱 버저닝
- 3.1.4 메시지 포맷
- JSON, XML 등이 있음.
3.2 동기 RPI 패턴 응용 통신
- 3.2.1 동기 RPI 패턴: REST
3.2.2 동기 RPI 패턴: gRPC
- REST보다 데이터가 훨씬 컴팩트함.
- gRPC는 성능, 효율성, 다양한 언어 지원, 스트리밍 기능 등이 필요한 경우에 특히 유용합니다. 마이크로서비스 아키텍처나 다양한 언어 환경에서의 통신, 그리고 높은 성능을 요구하는 애플리케이션에서 gRPC를 사용하는 것이 좋습니다.
3.2.3 부분 실패 처리: 회로 차단기 패턴
- 부분 실패 처리 방법. 아래에 해당하면 일정 시간 해당 서비스 차단
- 타임아웃
- 횟수 제한
- 에러룰 기준치 넘을 경우(회로 차단기 패턴)
- 부분 실패 처리 방법. 아래에 해당하면 일정 시간 해당 서비스 차단
- 3.2.4 서비스 디스커버리
- 서비스 호출시, 실제 ip를 얻어내기위해 사용해야하는 기능.
- 애플리케이션 수준에서 제공한는 것(스프링 유래카), 플랫폼 수준에서 제공하는 것(쿠버네티스), 클라우드 수준에서 제공하는 것이 있음.
3.3 비동기 메시징 패턴 응용 통신
- 3.3.1 메시징 개요
- 3.3.2 메시징 상호 작용 스타일 구현
- 2가지 - 요청과 응답받을 채널을 명시해서 비동기 호출하기.
- 메세지 브로커를 사용해서 큐에 메시지 보내기.
- 채널.
- 요청 응답
- 비동기 요청 응답
- 단방향 알림
- 발행/구독
- 발행/비동기 응답
- 3.3.3 메시징 기반 서비스의 API 명세 작성
- 3.3.4 메시지 브로커
- 플랫폼
- 레빗엠큐
- 카프카
- 클라우드
- aws 키네시스
- aws sqs
- 플랫폼
- 3.3.5 수신자 경합과 메시지 순서 유지
- id를 기준으로 샤딩된 채널을 이용하는 방식으로 메시지 순서를 유지하면서 확장성을 높임.
- ex) 주문 아이디를 기준으로 샤딩.
- id를 기준으로 샤딩된 채널을 이용하는 방식으로 메시지 순서를 유지하면서 확장성을 높임.
- 3.3.6 중복 메시지 처리
- 이것을 위해 아웃박스 패턴이라고, 메시지를 db에 저장해 놓고 쓸수 있음.
- 멱등한 메시지 헨들러 작성
- 메시지 추적과 중복 메시지 솎아 내기.
- 3.3.7 트랜잭셔널 메시징
- 이것을 위해 2가지 방식이 있음.
- 일단 DB테이블을 메시지 큐로 활용
- 아웃 박스 디비를 주기적으로 폴링해서 쓴다.
- db 트랜잭션널 로그를 직접 읽어서 연동된 채널에서 처리한다.
- 패턴 : 트랜잭셔널 아웃박스 패턴, 폴링 발행기, 트랜잭션 로그 테일링 패턴.
- 3.3.8 메시징 라이브러리/프레임워크
- 책의 저자가 만든거 소개. 이름 까먹음.
3.4 비동기 메시징으로 가용성 개선
- 3.4.1 동기 통신으로 인한 가용성 저하
- 동기 통신은 의존하는 수만큼, 블로킹이 되고, 그렇기에 가용성 저하(단위시간동안 응답 가능한 개수가 한정됨.)
- 3.4.2 동기 상호 작용 제거
- 가용성 늘리기 위해 동기 상호작용을 제거할것.
- 주문 예시.
- 주문은 빠르게 생성하고. 주문의 검증을 비동기로 처리.
- 모든 검증이 완료되었을때 해당 주문 데이터를 validate 되었다고 업데이트 하는 방식.
3.5 마치며
참고 자료
- https://bryceyangs.github.io/various/2023/03/03/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4%ED%8C%A8%ED%84%B4-3%EC%9E%A5/
- https://freeend.tistory.com/108
생각 정리
- 참 부끄럽게도 지금 회사의 주문 처리 로직은 그런 유효성 체크가 전혀 되어있지 않다.
- 그럼에도 돌아가니까 유지를 하는 거겠지만, 참으로 애석한 일이다.
- 알고 있고, 비동기로 처리가능할때 그것들을 시도해보자. 물론 오버 엔지니어링은 하지 말자.
추후 해야할것.
- 해당 글을 내가 밑줄 친것 위주로 내용 보강하기.
- 모르는 것을 전부 우겨넣는 미친 짓이 아닌, 핵심을 파악할것.
This post is licensed under CC BY 4.0 by the author.