IPC 패턴 (Sync 통신 vs Async 통신)

MSA 에서 서비스간 통신을 하게 되면 네트워크 통신을 하게 된다. 즉 프로세스간 통신을 하게 되는데 이를 IPC( Inter-Process Communication ) 라고 한다. IPC는 단일 시스템 내의 프로세스 간이든, 분산 시스템의 서로 다른 노드 간이든, 동기(Synchronous)와 비동기(Asynchronous) 통신 패턴을 지원한다. 시스템 설계와 기능의 요구사항에 맞게 각각의 패턴을 고려해서 사용해야 한다. 사용자가 기능의 결과를 즉각적으로 받아봐야하는 경우는 동기패턴을 사용하고 즉각적이지 않고 실행 한 뒤 나중에 완료 알림을 받는 경우라면 비동기 통신을 고려할 수 있을 것이다.

동기 방식을 기본으로 사용하지만, 특정 작업(예: 대규모 데이터 처리, 장시간 작업)은 비동기 작업으로 처리할 수 있다.

또한 REST API와 같은 동기 호출에서, 백엔드 서비스 간의 통신은 비동기 메시지 큐로 처리할 수 있다.

 

 

 

 

동기(Synchronous) 통신

동기 통신을 요청-응답 모델로써 요청과 응답 사이의 흐름이 순차적으로 이루어지는 방식이다.

Synchronous Blocking 모델로 같이 사용되면서 프로세스 A가 프로세스 B에 요청을 보내면, 응답을 받을 때까지 프로세스 A는 작업을 멈추고 기다린다. 요청-응답이 순차적으로 처리되기 때문에 작업 순서가 보장됩니다.

 

장점

1. 요청-응답 구조로 직관적이라 구현이 쉽다.

2. 요청이 순차적으로 처리되기 때문에 데이터의 일관성을 유지하기 쉽다.

 

단점

1. 응답을 기다리는 동안 자원이 블록(Block)되기 때문에 효율이 낮아질 수 있다.

2. 두 프로세스 간의 강한 의존성 때문에 한쪽의 지연이 전체 시스템 성능에 영향을 줄 수 있다.

 

대표적 사용 사례

1. 요청-응답 모델 API : RESTful API, GraphQL, gRPC

2. 데이터베이스 쿼리: 클라이언트는 쿼리 결과를 반환받기까지 대기.

3. 동기식 파일 I/O: 파일을 읽거나 쓰는 동안 프로세스가 대기.

 

비동기(Asynchronous) 통신

비동기 통신은 요청과 응답이 독립적으로 이루어집니다. 즉, 요청을 보낸 후 응답을 기다리지 않고 다음 작업을 계속 수행할 수 있다. 따라서 응답의 순서가 요청 보낸 순서와 다를 수 있다.

비동기 Non-Blocking 통신 경우 프로세스 A가 프로세스 B에 요청을 보낸 후, 응답을 기다리지 않고 다른 작업을 수행한다. 즉 요청을 보낸 직후 서버(프로세스 B)로부터의 응답을 기다리지 않고 제어권이 호출자(프로세스 A)에게 즉시 반환된다. 호출자는 다른 작업을 계속 수행할 수 있다. 결과는 나중에  콜백(callback), Future, Promise 이나 이벤트 핸들러를 통해 비동기적으로 처리된다.

 

장점

1. 요청-응답이 비동기로 처리되므로, 시스템 자원이 효율적으로 사용된다.

2. 프로세스 간 의존성이 낮아지고, 응답 시간에 관계없이 작업을 계속 수행할 수 있음.

3. 비동기 방식은 대규모 분산 시스템에서 높은 동시성(Concurrency)을 제공.

 

단점

1. 응답을 콜백, Future, Promise 등을 사용하여 처리해야 하기 때문에 코드가 복잡해질 수 있음.

2. 요청과 응답이 비동기적으로 처리되기 때문에, 오류 추적 및 디버깅이 어렵습니다.

 

대표적 사용 사례

1. 메시지 큐(RabbitMQ, Kafka) : 요청을 메시지로 발행하고, 소비자가 이를 비동기로 처리한다.

2. WebSocket : 클라이언트-서버 간의 실시간 양방향 비동기 통신.

3. 비동기 파일 I/O: 파일 작업을 비동기적으로 수행하여 프로세스가 블록되지 않음.