IPC(Inter Process Commuication) - 4

IPC(Inter Process Commuication) Async(비동기) 패턴의 한계

→ 특정 상황들에서는 필연적으로 2번이상 데이터를 받을 가능성이 있다.

 Async(비동기) 통신을 활용해서 중요한 비즈니스를 하기는 어려울까?

 

Q. Async에서는 2번이상 수신되는 것을 해결하고 싶으며, Sync에서의 장점으로 설명되었던 중요한 비즈니스에서도 리소스 활용을 최적화 해서 사용하고 싶다면 어떤 방법이 있을까?

 

A. 멱등성(Idemptotent)이 필요한 상황을 식별한다.

멱등성(Idemptotent) 이란?

 

→  특정 호출이 1번 혹은 여러번 호출되더라도 서버의 상태는 1번 호출된 것과 동일해야 한다는 특성이다.
      일반적으로 Update, Delete 요청은 멱등성을 가지며, Create 요청은 멱등석을 가지지 않는다.

Async(비동기) 통신에서의 멱등성

 

Async 통신은 기본적으로 멱등성이 보장되지 않는 통신 방식이다.

그럼에도 멱등성을 구현하기 위해서는 "무언가" 가 필요하다.

 

예를들어,

 

1. 멱등성 구현을 위한 DB Table(RDB)를 사용해서 멱등성을 구현
2. 여러 메시징 오픈소스

 

결론

• IPC(Inter Process Commuication) 는 다수의 Process 이다.
• 일반적으로 Process는 서비스간의 통신이다.
• IPC의 방식에는 크게 Sync(Http, gRPC), Async(Message Queuing)방식이 존재한다.
• Async 통신에는 위와 같은 한계를 해결하기 위해 멱등성을 식별해야 하고,
  최근의 메시징 시스템은 멱등성 기능을 내제하는 Exactly Once 기능을 제공한다.