about me
20'S LIFE IN SYDNEY and BUSAN
API 디자인과 프로세스 간 통신
”마이크로서비스 간의 통신”이라고 이름 붙이지 않고, “프로세스 간 통신(Inter-process communication, IPC)”이라고 이름 붙인 것은, 결국 마이크로서비스는 하나의 프로세스 단위로 실행되기 때문입니다. IPC라는 용어가 개발 도메인에서 보다 대중적으로 쓰이는 용어이므로, “마이크로서비스 간의 통신”임을 염두해두고, 이 챕터를 학습하기를 바랍니다.
프로세스 간의 통신
서비스와 서비스가 서로 통신하기 위해서는 인터페이스(interface)가 존재해야 하고, 인터페이스가 요구하는 방식대로 커뮤니케이션 해야 합니다.
우리는 앞서 클라이언트/서버 아키텍처를 통해 HTTP라는 프로토콜을 배우고, HTTP 위에서 작동하는 메소드와 엔드포인트로 구성된 REST API(Application Programming Interface), 즉 인터페이스를 이용한 통신을 배웠습니다.
동기/비동기
HTTP 프로토콜은 기본적으로 TCP(또는 UDP) 연결을 만들고, 이 위에서 요청에 따라 즉시 응답이 오는 형태로 구현이 되어 있습니다. 즉 동기적인 응답을 제공합니다.
그런데 세상에는 요청에 따른 응답이 즉시 도착하는 커뮤니케이션만 존재하지 않습니다.
현실 세계를 생각해봅시다. 문자 메시지를 생각해보면 발신자는 수신자가 즉시 메시지를 보고 답장하리라고 기대하지 않습니다.
또다른 예로 뉴스레터와 같은 구독 서비스를 생각해봅시다. 구독을 해놓으면 콘텐츠 생산자가 메시지를 정해진 때에 보냅니다. 푸시 알림등으로 우리는 이를 인지하고 소비할 수 있죠.
이러한 패턴은 비동기적인 커뮤니케이션입니다.
HTTP는 비동기 아닌가요?
프로그래밍 언어를 먼저 배우신 분들은 이러한 의문을 가질 수도 있습니다. 어쨌든 HTTP는 컴퓨터와 컴퓨터 사이의 네트워크 통신이고, 이는 네트워크 지연에 따라 즉시 응답이 오지 않을 수도 있기 때문에 이를 비동기로 인식할 수 있습니다. 이는 프로그래밍 언어의 관점에서 틀린 말은 아닙니다.
하지만 프로세스 간 통신의 관점에서 HTTP는 동기적인 메커니즘으로 분류합니다. 왜냐하면, 어쨌든 서로 통신하는 두 컴퓨터는 모두 켜져 있어야 하며, 클라이언트는 서버가 제 때 응답을 줄 것이라고 기대하기 때문입니다.
서비스작업| 동기 | 요청/응답 |
| 비동기 | 비동기 요청/응답 단방향 알림 (예를 들어, 푸시 알림) |
일대일 및 일대다 통신
시간의 관점이 아닌 다른 관점에서도 살펴봅시다. 1:1로 작동하지 않는 커뮤니케이션 방식도 세상에는 많이 존재합니다. 앞서 설명한 뉴스레터 구독 서비스는 1:1로 커뮤니케이션 하지 않고 구독자 모두에게 동일한 메시지를 제공하는 형태, 즉 일대다 커뮤니케이션 방식을 취합니다.
HTTP는 일대일인가요? 아니면, 일대다인가요? 요청/응답으로 이뤄진 한번의 트랜잭션(transaction)에서 서버는 여러 클라이언트에게 동시에 응답을 전달하지 않습니다. 서버가 여러 클라이언트를 상대할 수는 있지만, 그것은 여러번의 1:1 커뮤니케이션이지, 동시에 여러 클라이언트를 상대하는 1대다 커뮤니케이션이 아닙니다. 따라서 일대일 통신이라고 볼 수 있습니다.
프로세스 간의 직접/간접 연결
앞서 클라이언트/서버 아키텍처를 통해 두 프로세스 간의 직접 연결을 구현했지만, 중간에 메시지 브로커가 두 프로세스 사이에 위치해서 오고가는 메시지 자체를 관리하는 형태의 연결 방식도 있습니다. 이 경우 비동기적인 처리는 물론이고, 설사 둘 중 하나의 프로세스가 실행중이 아니더라도 서로 메시지를 주고받을 수도 있습니다.
댓글