IPC, 메시지 브로커, CQRS

1. IPC (Inter-Process Communication)

• 프로세스 간 통신: 마이크로서비스 간의 통신이라고 부르지 않고, IPC라고 부른다. 마이크로서비스는 하나의 프로세스 단위로 실행되기 때문이다.
• 서비스와 서비스가 서로 통신하기 위해서는 인터페이스가 존재해야 하고, 인터페이스가 요구하는 방식대로 커뮤니케이션을 해야 한다.
• HTTP 프로토콜은 기본적으로 TCP(또는 UDP) 연결을 만들고, 요청에 따라 즉시 응답이 오는 형태로 구현되어 있어 동기적인 응답을 제공한다. 또한 HTTP는 일대일 통신이다. 한번의 transaction에서 서버는 여러 클라이언트 또는 그 반대로 응답을 전달하지 않기 때문이다.

2. 메시지 브로커 특징

• 프로그램 간의 직접 연결이 없다: less dependency, fault tolerant
  • 소비자 프로세스가 죽어있어도 생산자는 메시지를 보낼 수 있다.
  • 생산자 프로세스가 죽어있어도 소비자는 메시지를 수신할 수 있다.
• 메시지 브로커에 있는 메시지는 소비자가 꺼낼 때까지 안전하게 보관된다 : durability
  • (프로세스가 죽어있어도) 메시지는 소비하기 전까지는 사라지지 않는다.
  • 따라서, 프로그램 간 통신은 시간과 독립적이다.
• 통신이 이벤트에 의해 구동될 수 있다.
  • 큐의 상태에 따라 프로그램을 제어할 수 있다. 예를 들어 메시지가 큐에 도착하는 즉시 프로그램이 시작되도록 설정할 수 있다. 또는 예를 들어 큐에서 특정 우선 순위 이상의 메시지가 10개나 되거나 임의의 우선 순위의 메시지가 10개가 될 때까지 프로그램이 시작되지 않도록 지정할 수 있다.
• 확장에 용이하다.
  • 메시지 브로커는 여러 큐를 만들거나, 수평적으로 확장하여 메시지 부하 증가를 처리 할 수 있다.
• 프로세스 간의 직접 연결에 비해 아키텍처가 복잡하다.
• 종류에는 Apache Kafka, AWS Kinesis, AWS SQS 등이 있다.

3. CQRS란

• Command Query Responsibility Segregation: 명령과 조회의 책임 분리; 이름처럼 명령을 처리하는 책임과 조회를 처리하는 책임을 분리하는 것이다.
• 명령은 상태를 변경하는 작업을 의미하며, 조회는 상태를 반환하는 작업을 의미한다.
• CQRS는 초기 CQS에서 시작되어 확장되었다.CQS는 Command Query Separation의 약자로 시스템에서 처리되는 명령과 조회, 이 두 작업을 정의하는 핵심 개념이자, 이 둘을 분리 시키는 디자인 패턴이다.
• 서비스 성능 향상을 위해서 인스턴스를 스케일 아웃하여 여러 개로 실행할 경우 빈번한 명령과 조회 작업으로 리소스 교착 상태가 발생 할 수 있다. 뿐만 아니라 통상적으로 명령보다는 조회 요청이 훨씬 많이 사용되기 때문에, 하나의 서비스 내에 이러한 기능을 모두 넣어두면, 조회 요청 빈도가 증가함에 따라 명령 기능도 함께 확장되어야 하기 때문에 도메인의 복잡도가 높아진다. 이러한 문제를 해결하기 위해 CQRS 패턴을 사용한다.
• CQRS는 요청을 크게 명령(Create, Update, Delete)과 조회(Read)로 나누어 처리한다.
• 명령과 조회를 각각 분리하면 명령(쓰기) 요청의 부하를 줄이고, 조회(Read) 대기 시간을 줄이는 등 다양한 이점을 누릴 수 있다.
• CQRS 패턴은 이벤트 소싱 패턴과 함께 사용되기도 한다. 메시지 브로커를 이용한 이벤트 주도의 아키텍처의 경우, 이벤트로 인해 상태가 변경되면 이를 데이터 모델로 처리하고 최종값을 반영한다. 이벤트 소싱 패턴이란 이를 데이터로 저장하는 것이 아니라 상태 변경 이벤트 자체를 저장하는 기법을 의미한다.