클라우드 네이티브 애플리케이션 디자인 패턴

MSA는 클라우드 네이티브 애플리케이션의 기본

VM은 호스트의 자원을 사용하여 게스트 OS를 띄움

컨테이너는 호스트 자원을 다른 컨테이너와 공유하며 사용함

MSA를 구성할 때 DDD를 사용하여 서비스를 나눌 수 있다.

CNA에 사용할 수 있는 패턴이 여러 개가 있다.

통신 패턴

동기 패턴에는 용청 응답 패턴이 있다. 쉽게 HTTP 통신이 있다.

RPC라는 패턴이 있는데 TCP위에서 동작하며 타 서비스의 메서드를 사용하는 것이다. 위임된 서비스를 호출하는 것이지만. 

굳이 Rest가 있는데 써야 하나 싶다. 그래서 퇴보되다가 gRPC가 등장해서 많이 사용하는 듯하다. 더 효율적이면서 타입 안정성을 지킬 수 있다고 한다.  Rest는 여러 사용자에게 노출될 때 좋고 RPC는 서버 간에 효율적인 통신과 처리량이 많을 때 좋다고 한다.

 

비동기-응답 패턴이라는 것이 있는데 소비자가 메시지 처리 후에 응답을 보내는 것이다.

이는 단일 수신자  point to point처럼 구현할 수 있다. 응답 큐를 사용하는 것.

MSA 간 서비스 정의/인터페이스 정의는 서비스 레지스트리라는 곳에서 이뤄진다. 자동 or 개발자가 수동 등록할 수 있다.

레지스트리에서 스키마를 가져와서 검증에 사용하는데 언어 차원에서 지원하는 것을 사용하면 안 되나? 너무 많이 연동이 있기 때문에 레지스트리를 사용하는 것일까.

동기패턴 중 하나인 웹 소켓은 handShaking 이후에 TCP 소켓처럼 동작한다. gRPC는 프로토콜버퍼라는 이진 직렬화 포맷을 통해 서비스 인터페이스를 정의한다고 한다. 

 

연결성 패턴은 MSA 간 혹은 외부 SasS와 같은 서비스와 연결하는 방법. 

MSA 간 연결이 잦다면 애초에 서비스를 잘게 나눈 것.

통신 패턴은 비즈니스 기능별로 결정해야 한다.

쿠버네티스 같은 플랫폼은 서비스 추상화를 기본적으로 제고. LoadBalancer 같은 기능도 제공하는 듯하다.

서비스 추상화는 MSA에서 필요한 패턴. 서비스 정보는 서비스 레지스트리에 저장한다.

 

네트워크는 믿을 수 없다. 방어책을 구축하자.

타임아웃, 재시도, 데드라인 - 특정 시각까지 호출이 완료되어야 한다. 서비스에 대한 요청이 여러 서비스로 퍼질 때 유용할 듯하다. 각 서비스는 데드라인이 지났는지 확인하는 절차가 있다.

회로차단기 - 실패의 임계를 넘으면 끝. 복구는 정책에 맞게.

패일 패스트 - 서비스 연결성과 관련된 비정상 동작 or 오류를 빠르게 탐지하는 것. 타 서비스 호출 전에 검증이 선행되어야 함. 서비스 간 연결 OR DB 등 검증..

 

사이드카는 보조기구 역할을 하며 주컨테이너와 함께 배포된다.

복잡한 통신을 사이드카에서 구현할 수 있다. 멀티 컨테이너 파드라고 한다. 하지만 관리 포인트가 증가한다.

이벤트 주도 아키텍처는 아키텍처 패러다임 중 하나. 이벤트는 정보 공유가 목적이다. 생성자는 대부분 응답을 기대하지 않는다. kafka, nats는 로그기반으로 계속 이벤트를 보관한다.