분산 프로세스 아키텍처에서 가장 철학적이고 실무적인 논쟁이 바로 통신방식입니다. 통신방식은 중앙 관리형 통신방식(Orchestration & Gateway), 분사형 통신 방식(Cherography & Message Broker) 정도로 확인하였습니다.
프로세스를 여러 개로 분리를 시작하면, 가장 먼저 마주하는 거대한 벽이 "통신 복잡성"입니다. 다수의 프로세스가 직접 통신한다면 관리해야 항목(커넥션, URL)이 늘어납니다. 그래서 프로세스간 직접 통신방식은 많이 언급하지 않을려고 합니다.
1. 중앙 관리형 통신방식(GateWay & Orchestration)
- 중앙집권과 명령입니다. 각 프로세스는 스스로 판단하지 안혹, 오직 중앙의 지휘자가 내리는 명령에 따라서면 움직입니다. 요청->대기->응답 과정을 거치는 것입니다.
- 비지니스 로직과 흐름이 한눈에 보임, 중앙 관리 프로세스가 병목이 될 수 있음
2. 분산형 통신방식(Choreography & Message Broker)
- 지방자치와 이벤트입니다. 중앙의 통제관이 없으며, 각 프로세스는 시스템이 발생한 "사건"을 듣고 로직을 수행합니다.
- 시스템 확장(프로세스 추가)이 자유로움, 흐름이 사방으로 진행되어 모니터링이 어려움
- RabbitMQ, Kafka, Redis Pub/Sub
중앙 관리형 통신방식이든 분산형 통신방식이든 해당 프로세스가 문제가 발생하면, 전체 시스템이 마비되는 것은 동일합니다. 이런 것을 피하려면 프로세스간에 직접 통신방식으로 해야 해야 하는데, 프로세스가 늘어날 수록 관리가 상당히 어렵습니다.
중앙 관리형 통신방식(GateWay & Orchestration), 분산형 통신방식(Choreography & Message Broker) 모두 해당 프로세스가 죽으면 마비되는 것은 동일합니다. 장애 발생했을 때 '데이터 유실'과 '인프라 수준에서 이 문제를 어떻게 극복(복구)' 관점에서 분류된 것으로 보입니다.
1. 데이터 영속성 관점 (메시지 보관 창고 유무)
- 수동 중앙 관리 프로세스 : 중앙 관리 프로세스가 장애 시, A프로세스가 B 프로세스로 요청을 보내면, 프로세스 연결자체가 실패하면서 에러 발생하고, A 프로세스가 메시지를 저장하지 않았다면 유실됩니다.
- 메시지 브로커 : 메시지 브로커는 단순한 통로가 아니고, '디스크 보관 기능이 있는 메모리 창고' 개념입니다. 프로세스 2,3 모두 죽어있더라도 메시지 브로커만 살아있다면 메시지를 큐(Queue)에 안전하게 쌓아두고, 프로세스 2,3 실행되면 밀려있던 메시지를 순서대로 처리할 수 있습니다.
2. 고가용성과 클러스터링의 난이도
- (직접 구현한) 중앙 관리 프로세스 : 비즈니스 로직, 세션 상태, 흐름 제어 코드등이 포함되어 있고, 변화가 있을 때 개발자가 직접 코드로 다 구현해야 합니다.
- 전문 메시지 브로커(RabbitMQ, Kafka 등) : 전세계 천재 개발자들이 만든 전문 인프로 소프트웨어이고, "우리는 절대로 죽으면 안 된다" 목표로 제작된 것입니다.
3. 시스템의 결함도와 부하 분산
- 중앙 관리 프로세스 : 프로세스들이 중앙 관리자에 철저히 종속됩니다.
- 메시지 브로커 : 예를 들어서, A프로세스는 브로커에 메시지르 초당 10,000개씩 던지고 자기 할 일을 하러 갑니다. 브러커 뒤에는 B 프로세스의 성능이 부족해 초당 1000 만 처리하더라도, 시스테밍 터지지 않고 브로커 큐에 안전하게 저장됩니다.(Buffer, Load Balacing)
처음부터 메시지 브로커를 도입하면 인프라 관리 비용이 들기 때문에, 시스템 초기에는 단순한 중앙 관리자로 시작하고, "절대 데이터 유실되면 안 된다"거나 "특정 구간에 트래픽이 몰려 서버가 버티지 못한다"는 신호가 올 때 RabbitMQ나 Kafka 같은 브로커 도입을 검토하는 것이 가장 현실적인 개발 방향입니다.
개발 초기에는 데이터 유실까지 고려하지 않고 메시지 전달만 잘 되도록 중앙 관리자를 만들면서 전문SW(메시지 브로커) 적용을 고민해보는 것도 좋을 것 같습니다. 전문 SW가 오픈소스를 사용한다고 해도, 사용능력도 향상시키거나, 해당인력이 배정하거나 해야할 것 같네요.
댓글 없음:
댓글 쓰기