❓ IPC란?

Inter-Process Communication(=프로세스 사이의 통신) 즉, 프로세스 간 통신을 의미한다. 주로 클라이언트-서버 애플리케이션, 멀티스레드 프로그램 등에서 프로세스 간 데이터 공유, 동기화, 작업 분배 등을 위해 사용된다.

🤔 IPC는 왜 사용하는걸까?

일반적으로 Process는 운영체제에서 독립적으로 실행되는 프로그램의 인스턴스이다. 즉, 각 프로세스는 고유한 메모리 공간, 파일 디스크립터, 프로세스 ID 등을 가진다. 이렇게 독립되어 있다는 특징은 다른 프로세스의 영향을 받지 않아 한 프로세스의 오류가 전체 시스템을 마비시키는 것을 방지할 수 있다는 장점이 있다.

하지만 이러한 독립성은 동시에 고립되어 있다는 의미와 같다. 프로세스는 별도의 통신 수단 없이는 서로 정보를 주고받을 수 없고 통신이 어렵다.

그렇기 때문에, 운영체제의 커널이 IPC를 제공하는 것이다! 프로세스는 커널이 제공하는 IPC 기능을 사용해서 프로세스간 통신을 할 수 있고, 필요할 때 안전하고 효율적으로 정보를 교환할 수 있게 된다.
예를 들어, 웹 브라우저에서 파일을 다운로드할 때도 UI 프로세스 ➡️ IPC ➡️ 다운로드 관리자 프로세스 이런식으로 다운로드 요청을 한다. 이 과정에서 IPC가 두 프로세스 사이의 통신을 중재하며, 각 프로세스는 독립적으로 실행한다.

즉, IPC가 필요한 이유는 프로세스 간 통신이 필요한 이유와 같다. 따라서, IPC가 필요한 이유는 아래와 같다.

1. 데이터 공유

여러 프로세스가 동일한 데이터에 접근하고 작업할 수 있게 한다. 여러 사용자가 동일한 정보에 엑세스 할 수 있어 실시간 협업과 정보 동기화가 가능해진다.

2. 성능 최적화

복잡한 작업을 여러 개의 작은 프로세스로 분할하여 병렬 처리할 수 있어 전체 시스템의 처리 속도와 효율성이 향상된다. (왜냐하면 메인 작업과 서브 작업이 서로 통신해야 하므로 IPC가 통신을 도와줘야지 가능하다!)

3. 모듈성

각 기능을 독립적인 프로세스 또는 스레드 단위로 분리하여 모듈 방식으로 시스템을 구성할 수 있다.

(이때도 모듈간의 통신이 필요하므로 IPC가 필요하다!)

4. 편의성

여러 사용자가 동시에 다양하고 많은 작업을 수행할 수 있다. 즉, 멀티태스킹이 가능하다!

5. 자원관리의 효율성

프로세스 간 자원 공유와 조율을 가능하게 하여 시스템 자원의 효율적인 분배와 사용이 가능해진다.

🤓 IPC의 구현 방식

IPC에는 전통적으로 두 가지 기법이 있다.

출처 : https://velog.io/@coastby/운영체제-IPC-Inter-Process-Communication-프로세스-간-통신

a. 공유 메모리 기법, Shared memory

b. 메세지 전달 기법, Message Passing

공유 메모리 기법은 프로세스들이 공통의 메모리 영역을 공유하여 통신하는 방식이다.

협력적 프로세스들이 공유 메모리 영역을 통해 데이터를 교환하고, 주로 전역 변수, 공유 변수, 공유 파일을 통해 통신이 이루어진다. 일반적으로 더 빠르고 커널의 도움이 거의 필요 없다. 고속 통신이 가능하다는 장점이 있지만 통신 책임(Ex) 프로세스간의 동기화 문제)이 응용 프로세스에게 있고 운영체제는 단지 공유 메모리만 제공한다.

메세지 전달 기법은 프로세스들이 메시지를 주고받아 통신하는 방식이다.

협력적 프로세스 간에 메시지를 교환한다. 주로 적은 양의 데이터 교환에 사용된다고 한다. 공유 메모리 방식과는 달리 통신 책임 및 수단이 운영체제에 의해 제공된다. OS가 동기화를 해주기 때문에 충돌하지 않는다는 장점이 있지만 시스템 콜을 사용하기 때문에 공유 메모리 방식에 비해 상대적으로 속도가 느릴 수 있다는 단점이 있다.

(b) 그림을 보면 각 프로세스들이 커널에 있는 메세지 큐 공간으로 자원을 전송하는 것이 보인다. 즉, 메시지 전달 방식은 운영체제가 대신 전달하는 방식인 것이다.

또한, 직접 통신(direct communication), 간접 통신(indirect communication) 라는게 있는데 둘의 차이는 커널의 메시지 큐에 저장된 자원을 다른 프로세스에게 직접 전달을 해주는지(직접 통신), 찾으러 오라고 하는지(간접 통신)라고 간단하게 알아두자!

정리하자면, 공유 메모리 방식은 빠른 통신이 필요할 때 유용하고, 메시지 전달 방식은 데이터 일관성과 안정성이 중요한 경우에 적합하다.

공유 메모리 방식와 메시지 전달 방식과 같은 IPC 구현 메커니즘을 구체화한 것이 우리가 알고있는 파일, 신호, 소켓, 메시지 큐, 파이프 등이다. 이들에 대해 자세히 알아보자. 🔍

🗄️ 공유 메모리(Shared Memory)

공유메모리는 이름 그대로 프로세스간 메모리 영역을 공유해서 사용할 수 있도록 해준다. 각 프로세스는 보통 자신만의 독립된 메모리 공간을 가진다. 하지만 때로는 프로세스들이 정보를 효율적으로 공유해야 할 필요가 있다. 이때, 여러 프로세스가 동일한 메모리 영역에 접근할 수 있게 해주는 것이 바로 공유 메모리이다.

1. 한 프로세스가 커널에 공유 메모리 영역 생성을 요청(시스템 콜)하면
2. 커널은 이 요청을 승인하고 특정 메모리 공간을 할당한다.
3. 그럼 해당 메모리 영역에 대한 접근 권한을 가진 모든 프로세스는 이 공간을 읽거나 쓸 수 있다.

이렇게 권한만 있으면 접근이 가능하므로 중개자가 없이 곧바로 메모리에 접근할 수 있기 때문에 다른 IPC들 중에서 가장 빠르게 작동할 수 있다. 그러나 동시성 문제를 고려해야 한다. 여러 프로세스가 같은 메모리 영역을 동시에 수정하려 할 때 데이터 일관성이 깨질 수 있기 때문에, (뒤에 나올)세마포어나 뮤텍스 같은 동기화 메커니즘을 함께 사용해야 한다.

---

📂 파일(File)

파일은 우리가 흔히 알고 있는 파일이며, Shared Memory 모델을 사용한다. 여러 프로세스가 같은 파일에 접근하는 것을 떠올리면 Shared Memory 모델을 사용한다는 것을 쉽게 떠올릴 수 있을 것이다.

---

🪈 파이프(Pipes)

2개의 프로세스 입출력을 연결하여 하나의 공유 페이지를 제공하는 방식이며, Message Passing 모델을 사용한다. 프로세스 간에 대용량의 데이터를 전달하기보다는 짧고 간단한 메시지를 교환할 때 유용하다. 메시지 큐, 공유 메모리 등 다른 IPC 방식에 비해 사용이 간편하지만, 기능은 제한적인 것이 특징이다.

예시를 들어보자면,

ls | pr

위 명령어는 ls 명령어의 결과(표준 출력)를 pr 명령어의 입력(표준 입력)으로 전달한다. 여기서 | 가 파이프이다.

파이프는 크게 이름 없는/있는 파이프로 나눌 수 있다.

• 이름 없는 파이프 (Anonymous Pipe)

  상호 관련 있는 프로세스 간 통신에 사용되는데, 부모-자식 프로세스 간의 통신에서만 사용할 수 있다. 조금 헷갈릴 수 있는데, 같은 PPID(같은 부모 프로세스)를 가지는 프로세스들 사이에서만 가능하다는 의미이다. 파일 시스템에 존재하지 않고 메모리 상에서만 유지되고, 단방향 통신만 지원한다. 즉, 한 방향으로만 데이터를 전송할 수 있다는 것이다! (양방향 통신을 위해서는 두 개의 파이프가 필요)

• 이름 있는 파이프 (Named Pipe)

  FIFO(First In, First Out)라고도 불리며, 장치 파일을 통해 상호 관련 없는 프로세스 간의 통신을 가능하게 하는데 사용된다. 이름 있는 파이프는 파일 시스템 상에서 존재하는 특수 파일이며, 생성된 후 두 개 이상의 프로세스가 이를 통해 데이터를 주고받을 수 있다. 양방향 통신이 가능하지만, 기본적으로는 단방향으로 동작하므로 필요한 경우 양방향으로 설정해야 한다. 하지만 이것도 통신선로가 파일로 존재하니까 하나를 읽기 전용으로 열고 다른 하나를 쓰기전용으로 여는 것이라 하므로 결국은 PIPE와 같이 두개의 FIFO파일이 필요하다.
  

---

🚀 소켓(Sockets)

네트워크를 통한 프로세스 간 통신의 종착점을 의미하며 Message Passing 모델을 사용한다. 주로 원격에서 프로세스 간의 데이터를 공유할 때 사용되고, 파이프 개념을 네트워크로 확장시킨 것으로 볼 수 있다.

소켓 통신은 IP 주소와 포트 번호를 통해 연결되며, TCP/IP와 UDP 프로토콜을 사용한다. 이를 통해 같은 시스템 내의 프로세스뿐만 아니라 다른 시스템에 있는 프로세스 간에도 데이터를 주고받을 수 있다. 소켓은 로컬 통신(Ex) localhost:8080)뿐만 아니라 원격 통신도 가능하게 하며, 네트워크 상에서의 프로세스 간 통신을 가능하게 한다.

소켓은 서버/클라이언트 환경 구축이 용이하고, 양방향 통신이 가능하다는 점이 장점이다. 파이프 개념을 네트워크로 확장시킨 것이 소켓이라고 했는데, 파이프는 거의 단방향 통신만 가능했던 것과 차이점이 있다. 👀

---

🔒 세마포어(Semaphores)

공유 리소스 접근 제어 or 통제를 위한 동기화 메커니즘을 의미하며, Message Passing 모델을 사용한다.

아까 공유메모리를 설명할때 말했듯이 프로세스들의 공유 자원 접근을 조절하는, 즉 공유자원에 대한 "접근 제어"를 통해 프로세스간 통신을 지원하는 방식이다. Semaphore를 번역기로 돌려보면 “신호기”로 나온다. 마치 기차역에서 깃발로 기차의 통행을 제어하듯이, 공유 자원의 수를 나타내는 정수 변수를 사용하여 프로세스들의 공유 자원 접근을 조절한다.

세마포어는 공유 자원의 충돌을 막아준다는 장점이 있지만, 프로세스들이 자원을 기다리며 블록될 수 있어 CPU 대기 시간이 발생할 수 있다는 단점도 있다. (스케줄링에 따라 다르다!)

+) 세마포어와 뮤텍스
세마포어는 뮤텍스와 유사하지만, 세마포어가 더 넓은 범위의 동기화 문제를 다룰 수 있다. 뮤텍스는 주로 스레드 간의 상호 배제를 위해 사용되고, 세마포어는 여러 프로세스 간의 동기화를 처리할 수 있다.

---

⚡️ 시그널(Signal)

프로세스 ID를 통해 특정 프로세스에 메시지를 전달하는 방식이며, Message Passing 모델을 사용한다. 주로 실시간으로 프로세스에 이벤트 발생을 알리기 위해 사용한다.

간단히 말하자면, 프로세스에 특정 이벤트가 발생했음을 알리는 메시지이다!

우리가 알고있는 kill -9 는 Signal 관점에서 SIGKILL 신호를 프로세스에 보내는 것이다.

서버를 백그라운드로 실행하기 위해 종종 사용하는 nohup명령어도 시그널과 관련이 있다. nohup은 터미널 세션이 종료되어도 프로세스가 계속 실행되도록 할 수 있는데, 이는 SIGHUP 신호를 무시하게 만드는 것이다.

• SIGHUP 신호란?
  터미널 연결이 끊어졌을 때(사용자가 로그아웃하거나 네트워크 연결이 끊어졌을 때) 운영 체제가 해당 터미널에서 실행 중인 프로세스들에게 보내는 신호이다. 이 신호를 받으면 프로세스들은 종료된다.

---

📮 메시지 큐(Message Queues)

출처 : https://www.youtube.com/watch?v=7NZW0BEfpUU

프로세스 간의 메시지 기반 통신이며 메시지 큐 ID를 통해 통신한다. Message Passing 모델을 사용한다.

메시지가 발생하면 고정 크기의 메시지를 연결리스트를 통해 프로세스 간 통신 수행하는데, 이때 메시지는 FIFO 순서로 처리된다! 메시지의 우선순위를 설정할 수 도 있다.

😯 메시지 큐는 왜 필요하며, 어떤 점이 좋을까?

메시지 큐와 관련된 자료를 찾다가, 이 영상을 보게 되었다. 쉽고 간단하게 설명하므로 꼭 보길 추천한다!
이 영상이 너무 설명이 잘되어있어, 참고하여 간단하게 설명을 해보겠다.

고객이 주문할 때마다 결제를 처리한 다음 재고를 업데이트하는 온라인 쇼핑몰이 있다고 해보자. 우리가 보통 온라인 스토어에서 결제를 하면 결제가 완료되고, 결제 주문 내역이 이메일로 날라온다. 이런 것들이 모두 “이벤트”인 것이다.

그런데, 갑자기 90% 세일을 해서 엄청나게 많은 수의 사용자가 동시에 이 스토어에 접속한다면 어떻게 될까? 이 경우에는 갑자기 많은 양의 애플리케이션 이벤트가 발생하고, 모든 이벤트를 한 번에 처리할 수 없기 때문에 사용자 입장에서는 사이트가 느려지는 경험을 할 수 있다.

이런 경우는 어떻게 해결할 수 있을까? 물론 이러한 경우 대량 트래픽을 처리할 수 있도록 서버를 확장할 수 있다. 하지만 서버를 확장한다는 것은 쉬운 것이 아니다. 데이터 관리부터 모니터링, 보안, 성능 등등 ,,, 고려해야할 사항이 너무 많고 무엇보다도 비용이 든다.

여기서 생각해보자. 애플리케이션 이벤트를 한번에 모두 처리할 필요가 있을까? 이러한 이벤트에 신호를 주고 나중에 처리해도 되지 않을까? 사용자 입장에서는 느리더라도 자신이 정상적으로 기다리고 있다는 것만 확인받으면 기다릴 수 있을 것이다. (Ex) 티켓팅)

이때 사용할 수 있는게, 바로 메시지 큐이다!
메시지 큐는 메모리에 저장되어 있으며, 비동기 통신을 지원하는 내구성 있는 구성 요소이다. 주로 데이터의 버퍼 역할을 하며, 시스템 간의 커뮤니케이션을 효과적으로 관리하는 용도로 사용한다.

보통 메시지 큐에서는 아래와 같은 pub/sub 방식을 사용한다.

여기서 메세지를 발행하고 전달하는 부분을 Producer 라고 하며, 메세지를 받아서 소비하는 부분을 Consumer 라고 한다. 여기서 메세지 큐는 Producer 와 Consumer 의 메세지 전달 역할을 하는 매개체이다. 이 구조는 여러 생산자를 가질 수 있고 반대편에는 이 대기열에서 읽는 많은 소비자나 서버가 있을 수 있다.

이 메시지 큐가 제공하는 장점은 이러한 이벤트를 분리한다는 것이다!
즉, 이 메시지 대기열을 통해 이러한 이벤트를 비동기식으로 처리할 수 있으며 소비자(서버)가 이벤트를 처리할 수 없는 경우 소비자에서 처리할 수 있을 때까지 대기열에 넣을 수 있다.
또한, 생산자가 메시지를 게시할 수 없는 경우에도 소비자는 여전히 대기열에서 메시지를 읽은 다음 처리할 수 있다.

하지만 생산자나 소비자 대신 메시지 큐가 손상되면 모든 기록이 다 날라가나? (Ex) 결제 요청 등등..)

여기서 알아야할 것은 메시지 큐의 주요 특성 중에 내구성(Durability)이라는 것이 있다.
즉, 큐가 데이터를 RAM이 아닌 디스크에 저장하기 때문에 시스템 충돌이나 전원이 꺼지는 등의 상황에서도 데이터가 손실되지 않는다.
따라서 소비자(메시지를 받는 프로세스 or 서버)가 메시지를 처리하는 도중에 문제가 발생하더라도 메시지는 안전하다! 예를 들어, 서버가 갑자기 종료되어도 메시지는 큐에 그대로 남아있다.

+) 유명한 메시지 큐 시스템들에는 Apache Kafka, RabbitMQ, Redis 등이 있다.

참고 자료

IPC

[운영체제] IPC (Inter Process Communication), 프로세스 간 통신

Message Queues in System Design

IPC의 종류와 특징

05-2 프로세스간 통신 (IPC)

카프카, 레빗엠큐, 레디스 큐의 큰 차이점! 이벤트 브로커와 메시지 브로커에 대해 알아봅시다.

[서버] 메세지 큐(Message Queue) 을 알아보자

Message Queue