Process - 프로세스간 통신(IPC < Socket < RPC)

1.  강의 링크

https://www.inflearn.com/course/%EC%9A%B4%EC%98%81%EC%B2%B4%EC%A0%9C-%EA%B3%B5%EB%A3%A1%EC%B1%85-%EC%A0%84%EA%B3%B5%EA%B0%95%EC%9D%98/lecture/65271?tab=curriculum&speed=1.25 

운영체제 공룡책 강의 - 인프런 | 학습 페이지

 

2.  정리

프로세스는 서로 독립적인 주소 공간을 OS로부터 할당받는다. 기본적으로 서로 다른 프로세스끼리는 서로의 주소 공간에 접근할 수 없다.(접근하게 되면, 보안상 많은 위험이 발생하게 된다.)

 

그런데, 독립적으로 실행되는 것만으로도 충분한 프로세스가 있는 반면, 프로세스끼리 상호작용을 해야만 하는 상황이 있다. IPC는 보안상의 이유로 서로의 주소 공간을 접근할 수 없는 상황에서 프로세스끼리 상호작용을 하기 위한 방법을 제공한다. 

 

IPC의 기본적인 아이디어는 [공유가 가능한 특수한 메모리 블록(공유 메모리) / 혹은 파일]을 만드는 것이다.

 

이 공유 메모리는 주로 버퍼(큐)의 형태를 따른다. 

공유 메모리 버퍼에 데이터를 쓰는 프로세스를 프로듀서, 읽는 프로세스를 컨슈머라고 일반적으로 부른다. 그리고, 프로세스끼리 통신에서 발생하는 여러 문제를 프로듀서 & 컨슈머 문제라고 부른다. 프로듀서 & 컨슈머 문제의 대표적인 예시는 아래와 같다.

 

1. 일반적으로 컴퓨터 자원은 한정되어 있고 때문에 공유 메모리 버퍼의 크기 또한 한정되어 있다. 버퍼가 가득 차서 프로듀서가 데이터를 생산하더라도 더 이상 버퍼에 쓸 수 없거나, 버퍼가 비어 있어서 컨슈머가 소비하지 못할 경우 waiting을 할지 말지에 대한 문제가 있다.
2. 프로세스 입장에서 버퍼를 통해 통신하는 것은 결국 IO다. 이러한 IO를 동기적으로 처리할지, 비 동기적으로 처리할지에 대한 문제가 있다.
3. 1:1 관계의 프로세스 통신뿐 아니라 n:n 관계에서 하나의 공유 메모리 버퍼를 두고 통신이 발생할 수도 있다. 이럴 때 버퍼를 통한 IO는 race condition이 발생할 수 있다. 이에 대한 처리 정책을 어떻게 가져갈지에 대한 문제도 있다.

위에서 언급한 것뿐 아니라 공유 메모리 버퍼를 원형 큐로 가져갈지, 버퍼 크기는 어떻게 가져갈지, 버퍼를 메모리에 둘지 파일 형태로 둘지 등등의 많은 문제를 풀어야 한다.(이 문제는 일반적인 서버 & 클라이언트 아키텍쳐의 문제로 까지 확장될 수 있다..)

 

다행히도 이러한 고민은 대부분의 애플리케이션 개발자가 할 필요가 없다. OS 수준에서 api를 제공해 주기 때문이다. OS 수준에서 제공해 주는 방식은 대표적으로 pipe가 있다. pipe api를 사용하면 file discripter를 포인터 형태로 제공해 주고 프로듀서와 컨슈머는 이를 사용해 파일을 read & write 하듯이 통신할 수 있다.

 

pipe는 결국 프로세스 간 통신을 파일에 대한 read & write로 추상화한 것이라고 할 수 있다.

 

더 나아가, 하나의 컴퓨터가 아니라 원격의 컴퓨터끼리의 통신 즉, 인터넷 통신을 위해서 Socket이 탄생했다. Socket은 Ip + port로 바인딩된 일종의 pipe이다. 결국 원격 프로세스끼리의 통신을 파일에 대한 read & write로 추상화한 것이다.

 Socket에는 UDP Socket과 TCP Socket이 있고 대부분 TCP 기반을 사용한다. 즉, api상으로는 파일에 대한 read & write의 형태로 통신이 이루어지고, 내부적인 구현은 TCP 방식을 사용한다. 

 

Socket은 서로 다른 PC의 프로세스 간 통신을 추상화한 것이다. 데이터 통신뿐 아니라 특정 작업을 수행하는 함수 수준까지 추상화한 것이 RPC이다. 

RPC 수준으로 추상화 하기 위해선, 통신을 위해 데이터를 어떤 형식으로 직렬화 하여 주고받을지, 해당 데이터로 어떤 작업을 수행해서 응답할지와 같은 것들을 미리 정의하는 작업이 추가된다. 이런 작업을 미리 해 두고 실제로 api를 사용할 때에는 함수를 호출하듯이 원격 프로세스와 통신할 수 있다.

 

 

3.  느낀점

최근에 apache kafka에 대해 아주 간략하게 공부했던 적이 있었다.

https://www.youtube.com/watch?v=catN_YhV6To 

 

마이크로 서비스 간 통신을 효과적으로 수행하기 위해 문제를 프로듀서 & 컨슈머 문제로 재 정의하고 그에 맞는 효과적인 방법을 도출하는 과정에서 apache kafka가 탄생한 것 같다.

이러한 최신 기술도 결국 기본 아이디어는 IPC와 비슷하지 않을까? 생각이 들고, 왜 CS가 기초가 되는지 다시 한번 느낄 수 있었다.

또한, Socket이 결국 파일이라는 것이 어떤 의미를 갖는지 다시 한번 상기할 수 있었다. 

Socket과 TCP의 개념을 섞어서 생각하는 경향이 있었는데, TCP는 network에서 구체적으로 데이터를 어떻게 송 수신할지에 대한 개념이고 Socket은 TCP를 통해(혹은 UDP를 통해) 전송된 데이터를 프로세스 관점에서 어떻게 사용할 지에 대한 개념이라는 것을 알게 되었다.