현대의 분산 시스템 설계에서 통신 미들웨어는 애플리케이션 간의 원활한 정보 교환을 위한 핵심적인 역할을 수행한다. 전통적인 메시지 중심(Message-Centric) 또는 객체 중심(Object-Centric) 패러다임이 특정 수신자에게 메시지를 보내는 행위 자체에 초점을 맞추는 반면, 데이터 분산 서비스(DDS)는 근본적으로 다른 접근 방식을 채택한다.1 DDS의 핵심 철학은 ‘데이터 중심(Data-Centricity)’으로, 이는 통신의 주체를 애플리케이션이 아닌 ‘데이터’ 그 자체로 간주하는 패러다임의 전환을 의미한다.
이러한 철학을 구현하는 핵심 개념이 바로 ‘글로벌 데이터 공간(Global Data Space)’이다.3 이는 물리적으로 분산된 노드들이 공유하는 가상의 거대 데이터베이스와 유사하다. 각 애플리케이션(DDS에서는 ‘Participant’로 지칭)은 이 공간에 데이터를 ‘발행(Publish)’하거나 필요한 데이터를 ‘구독(Subscribe)’함으로써 통신에 참여한다. 개발자는 더 이상 소켓 프로그래밍, 데이터 직렬화, 네트워크 주소 관리와 같은 저수준의 네트워크 프로그래밍에 대해 고심할 필요가 없다.3 DDS 미들웨어가 데이터의 효율적인 배포를 전적으로 책임지기 때문이다. 애플리케이션은 단지 “어떤 데이터를 원하는가” 또는 “어떤 데이터를 제공할 것인가”에만 집중하면 된다.
이러한 추상화는 개발 과정을 극적으로 단순화하지만, 동시에 새로운 과제를 제시한다. ‘글로벌 데이터 공간’이라는 강력한 추상화는 그 아래에 놓인 복잡한 네트워크의 실체를 감춘다. 개발자는 네트워크 동작을 직접 제어하는 대신 미들웨어의 ‘발견(Discovery)’ 메커니즘에 의존하게 된다.3 이 발견 메커니즘이 원활하게 작동하는 환경에서는 문제가 없지만, 서브넷 경계를 넘어서거나 방화벽이 존재하는 등 네트워크 환경이 복잡해지면 ‘글로벌 데이터 공간’은 분절되고 추상화는 깨지기 시작한다. 이처럼 추상화로 인해 발생하는 문제는 종종 더 지능적이고 관리되는 계층의 추상화, 즉 ‘라우터(Router)’를 통해 해결된다. 이 지점에서 DDS 라우터의 필요성이 대두되며, 본 보고서의 핵심 주제로 이어진다.
DDS의 데이터 중심 아키텍처를 이해하기 위해서는 그를 구성하는 핵심 객체들의 역할과 관계를 명확히 파악해야 한다. 이 구성 요소들은 이후 라우터 설정에서 반복적으로 등장하므로 그 개념을 숙지하는 것이 필수적이다.
DDS는 발행-구독(Publish-Subscribe) 통신 모델을 기반으로 한다.4 이 모델의 가장 큰 특징은 발행자와 구독자 간의 ‘완전한 분리(Decoupling)’이다.
데이터를 생성하는 발행자는 자신의 데이터를 누가, 어디서, 몇 명이나 구독하는지 알 필요가 없다.3 단지 정의된 토픽에 데이터를 발행할 뿐이다. 마찬가지로, 데이터를 소비하는 구독자 역시 데이터가 어디서, 누구에 의해 생성되었는지 알 필요 없이 관심 있는 토픽을 구독하기만 하면 된다. 이들 사이의 연결, 즉 메시지 라우팅은 전적으로 DDS 미들웨어가 자동으로 처리한다.5
이러한 분리(Decoupling)는 시스템의 유연성과 확장성을 극대화한다. 새로운 애플리케이션(참여자)이 시스템에 추가되거나 기존 애플리케이션이 제거되어도, 다른 애플리케이션의 코드를 수정할 필요가 없다. 이는 ‘플러그 앤 플레이(Plug-and-Play)’ 특성을 가능하게 하여, 동적으로 변화하는 대규모 분산 시스템 구축을 용이하게 한다.2
서비스 품질(QoS)은 DDS의 단순한 부가 기능이 아니라, 데이터 전달의 ‘방법’을 제어하는 핵심적인 표준 기능이다.7 DDS는 20개 이상의 세분화된 QoS 정책을 제공하여 개발자가 애플리케이션의 요구사항에 맞춰 통신의 신뢰성, 실시간성, 자원 사용량 등을 정밀하게 제어할 수 있도록 한다. 라우팅과 관련하여 특히 중요한 몇 가지 QoS 정책은 다음과 같다.
발행-구독 모델에서 통신이 성립되기 위해서는 데이터 작성자와 데이터 판독기가 토픽의 이름과 타입뿐만 아니라, 호환되는 QoS 정책을 가져야만 한다. 예를 들어, 작성자는 RELIABLE로 데이터를 보내는데 판독자가 BEST_EFFORT로 받으려고 하면 둘 사이의 연결은 성립되지 않는다. 이러한 QoS 불일치는 다른 모든 설정이 완벽하더라도 통신 실패의 주된 원인이 된다.8 DDS 라우터는 시스템에 도입될 때 내부적으로 입력단에서는 구독자(DataReader)로, 출력단에서는 발행자(DataWriter)로 동작한다. 따라서 라우터의 QoS 설정은 원본 발행자와 최종 구독자 양쪽 모두와 호환 가능해야 한다. 이는 라우터 설정에서 QoS 관리가 매우 중요하고 복잡한 작업이 되는 이유이며, 5장과 7장에서 심도 있게 다룰 것이다.
DDS는 표준화된 API 명세이며, RTPS(Real-Time Publish-Subscribe)는 DDS 구현체 간의 상호운용성을 보장하기 위한 표준 유선 프로토콜(Wire Protocol)이다.9 즉, RTI, eProsima, OpenSplice 등 서로 다른 벤더가 만든 DDS 구현체들이 RTPS라는 공통의 언어를 사용하기 때문에 서로 데이터를 주고받을 수 있다. DDS 라우터가 서로 다른 네트워크나 도메인을 연결하는 역할을 수행할 수 있는 근본적인 이유도 바로 이 RTPS 프로토콜의 존재 덕분이다. 라우터는 이 표준 프로토콜을 기반으로 데이터를 수신하고 전달함으로써 벤더에 종속되지 않는 유연한 시스템 통합을 가능하게 한다.
DDS의 데이터 중심 발행-구독 모델은 단일 로컬 네트워크(LAN) 환경에서는 매우 효율적이고 강력한 성능을 발휘한다. 그러나 시스템의 규모가 커지고 네트워크 경계를 넘어서면서 DDS의 기본 발견(Discovery) 메커니즘은 명백한 한계에 부딪힌다. 이러한 한계점들이 바로 DDS 라우터의 필요성을 역설한다.
DDS의 표준 발견 메커니즘은 기본적으로 P2P 방식에 기반한다. 각 도메인 참여자는 자신의 존재(자신이 발행하거나 구독하는 토픽 정보 등)를 네트워크에 알리고, 동시에 다른 참여자들을 탐색한다. 이 과정은 주로 IP 멀티캐스트를 통해 이루어지며, 이를 ‘자동 발견(Automatic Discovery)’이라고 부른다.2
이 P2P 방식은 중앙 관리 서버가 없어 단일 장애점(Single Point of Failure)이 없고 내구성이 높다는 장점을 가진다.2 하지만 시스템이 복잡해지면서 다음과 같은 약점들이 드러난다 2:
표준 DDS 발견 메커니즘이 가장 큰 난관에 부딪히는 시나리오는 바로 광역 네트워크(WAN)를 통해 지리적으로 분산된 시스템을 연결해야 할 때이다.
이러한 WAN 환경의 문제점을 해결하기 위해 DDS 라우터는 통신 패러다임을 근본적으로 변환한다. 라우터는 일반적으로 WAN 통신을 위해 TCP 프로토콜을 사용한다.9 반면, DDS는 본래 실시간성과 낮은 지연 시간을 위해 UDP를 선호한다.13 라우터를 사용함으로써 시스템 아키텍처는 효과적으로 분리된다. 각 LAN 내부의 참여자들은 효율적인 UDP 멀티캐스트를 사용하여 통신을 계속할 수 있다. 각 LAN의 경계에 위치한 라우터는 이 로컬 UDP 트래픽을 구독하는 ‘프록시’ 또는 ‘게이트웨이’ 역할을 한다.13 그리고 수신한 데이터를 안정적이고 방화벽 통과가 용이한 TCP 터널을 통해 원격지의 다른 라우터로 전송한다. 원격지 라우터는 이 데이터를 다시 자신의 로컬 LAN에 효율적인 UDP로 재발행한다. 결과적으로 DDS 라우터는 각 네트워크 구간의 특성에 가장 적합한 전송 프로토콜을 선택적으로 사용하는 ‘최적의 전송 전략’을 가능하게 한다. 이는 표준 DDS 참여자만으로는 쉽게 구현하기 어려운 수준의 제어 능력이다.
시스템에 참여하는 노드 수가 수백, 수천 개로 증가하면 P2P 발견 메커니즘은 성능 병목을 유발한다.
이러한 문제들은 P2P DDS 모델에 ‘관리자’ 또는 ‘브로커’ 역할의 부재에서 기인한다.2 DDS 라우터는 전략적으로 배치될 때 바로 이 부재한 관리자 역할을 수행한다. 네트워크 간 트래픽을 라우터라는 중앙 지점(또는 몇 개의 핵심 지점)을 통과하도록 제어함으로써 다음과 같은 이점을 얻을 수 있다. 첫째, 트래픽 제어가 가능해진다. 라우터는 네트워크 경계에서 데이터를 필터링하여 필요한 데이터만 네트워크 간에 전달할 수 있다.9 둘째, 발견 범위(Discovery Scope)를 제한할 수 있다. 발견 트래픽을 각 로컬 네트워크 내부에 국한시켜 디스커버리 스톰이 전체 시스템으로 확산되는 것을 방지한다.9 마지막으로, 보안 관리가 단순화된다. WAN을 통해 연결될 수 있는 모든 P2P 링크에 대해 보안 자격 증명과 접근 제어를 관리하는 대신, 라우터 대 라우터로 연결되는 지점에서 보안을 집중적으로 강화할 수 있다.
DDS 라우터는 일반적인 네트워크 라우터와는 근본적으로 다르다. 프로토콜에 관계없이 IP 패킷을 전달하는 네트워크 장비가 아니라, DDS 생태계 내에서 동작하는 특수한 목적의 DDS 애플리케이션이다. 라우터의 동작 원리를 이해하기 위해서는 이러한 핵심 원칙들을 먼저 파악해야 한다.
DDS 라우터의 가장 기본적인 정체성은 하나 이상의 DDS 도메인에 동시에 참여하는 ‘특수 목적의 DDS 참여자’라는 점이다. 라우터는 내부에 여러 개의 DomainParticipant를 가지며, 이를 통해 서로 다른 도메인이나 네트워크에 연결된다. 데이터 흐름의 관점에서 보면, 라우터는 한쪽 도메인에서 데이터를 구독하기 위한 내부적인 DataReader를 생성하고, 이 데이터를 다른 쪽 도메인으로 발행하기 위한 내부적인 DataWriter를 생성하여 둘을 연결하는 역할을 수행한다. 이 개념은 라우터의 설정 파일이 왜 DomainParticipant와 관련된 파라미터(예: 도메인 ID, QoS)를 정의하는지를 설명해준다.
DDS 라우터는 단순히 데이터를 한 곳에서 다른 곳으로 전달하는 것 이상의 정교한 기능을 제공한다.
allowlist)을 만드는 것부터 14, 데이터의 내용(값)을 기반으로 필터링하는 복잡한 기능까지 포함할 수 있다.9 이를 통해 네트워크 대역폭을 절약하고 수신측 애플리케이션의 부하를 줄일 수 있다.DDS 라우터는 다양한 아키텍처 패턴을 구현하는 데 사용될 수 있다.
eProsima Fast DDS Router는 오픈 소스 DDS 구현체인 Fast DDS를 기반으로 하는 라우팅 솔루션이다. 성능, 효율성, 그리고 사용 편의성에 중점을 두고 설계되었으며, 특히 로보틱스 및 자율 시스템 커뮤니티에서 널리 채택되고 있다.
eProsima Fast DDS Router는 분산된 DDS 네트워크를 연결하기 위해 설계된 최종 사용자 소프트웨어 애플리케이션이다.14 이 라우터의 핵심 설계 철학은 ‘경량화’와 ‘고속 데이터 전달’에 있다. 공식 문서에서 강조하는 ‘데이터 내성(introspection) 회피’ 및 ‘제로카피(zero-copy) 시스템’과 같은 특징들은 라우터가 데이터를 복잡하게 처리하기보다는 최대한 빠른 속도로 전달하는 데 집중하고 있음을 보여준다.14 이러한 접근 방식은 실시간성이 중요한 시스템에서 라우터 자체의 오버헤드를 최소화하는 데 기여한다.
eProsima Fast DDS Router는 다음과 같은 핵심적인 특징을 제공한다.
eProsima DDS Router의 아키텍처는 여러 종류의 ‘참여자(Participant)’를 설정하는 것을 기반으로 한다. 참여자는 라우터가 외부 네트워크와 통신하는 인터페이스 역할을 한다.22 설정 파일에서 정의할 수 있는 주요 참여자 종류(kind)는 다음과 같다.
local (또는 simple): 라우터가 실행되는 로컬 머신 또는 로컬 네트워크의 표준 DDS 도메인에 연결하기 위해 사용된다. 특정 도메인 ID를 지정하여 해당 도메인에 참여한다.wan: WAN(Wide Area Network)을 통해 다른 DDS 라우터와 통신하기 위해 사용된다. 주로 Discovery Server 메커니즘을 기반으로 동작하며, 원격 라우터의 주소와 포트를 지정하여 연결을 설정한다.데이터는 한 참여자의 내부 엔드포인트(DataReader)에서 수신되어, 설정된 토픽 허용 목록에 따라 다른 참여자의 내부 엔드포인트(DataWriter)로 전달된다. ‘제로카피’ 메커니즘은 이 과정에서 데이터가 메모리상에서 복사되지 않고 참조를 통해 전달됨을 의미하며, 이는 지연 시간을 줄이고 처리량을 높이는 데 결정적인 역할을 한다.21
eProsima Fast DDS와 DDS Router는 아파치 2.0 라이선스(Apache 2.0 License) 하에 배포된다.19 이는 상업적 사용, 수정, 배포가 자유로운 매우 허용적인 오픈 소스 라이선스로, 사용자는 라이선스 비용 부담 없이 솔루션을 도입하고 필요에 따라 코드를 수정할 수 있다.
eProsima의 솔루션은 특히 로봇 운영체제(ROS 2) 생태계와 매우 밀접한 관련이 있다. eProsima Fast DDS는 ROS 2의 기본(default) DDS 미들웨어로 채택되었으며 11, DDS Router는 eProsima가 제공하는 로보틱스 개발 플랫폼인 Vulcanexus의 핵심 구성 요소 중 하나이다.25 이러한 긴밀한 통합은 DDS Router가 로보틱스 및 자율 시스템 분야의 요구사항을 충족시키기 위해 적극적으로 개발되고 검증되었음을 의미한다. 예를 들어, 여러 대의 로봇으로 구성된 로봇 플릿(fleet)을 클라우드 백엔드와 연결하는 시나리오에서 DDS Router는 단일 LAN을 넘어 ROS 2 시스템을 확장하기 위한 자연스럽고 강력한 솔루션을 제공한다.26 따라서 ROS 2 기반의 시스템을 개발하는 아키텍트에게 eProsima DDS Router는 매우 매력적인 선택지가 될 수 있다.
이 장에서는 eProsima Fast DDS Router를 실제 시스템에 설치하고, 설정하며, 실행하는 구체적인 방법을 단계별로 안내한다. 개발자 중심의 소스 코드 컴파일 방식부터 다양한 시나리오에 맞는 YAML 설정 파일 작성법까지 다룬다.
eProsima DDS Router는 소스 코드를 직접 컴파일하여 설치하는 방식을 권장한다. 이를 통해 최신 기능을 사용하고 시스템에 최적화된 빌드를 생성할 수 있다.
먼저, 컴파일에 필요한 기본적인 도구들을 설치해야 한다. 우분투(Ubuntu) 기반 시스템에서는 다음 명령어를 사용한다.27
sudo apt update
sudo apt install cmake g++ python3-pip wget git
또한, 의존성 관리 및 빌드 도구인 colcon을 설치한다.27
pip3 install -U colcon-common-extensions vcstool
작업 공간을 생성하고, ddsrouter.repos 파일을 이용해 DDS Router와 모든 의존성 패키지(Fast DDS, Fast CDR 등)의 소스 코드를 다운로드한다.27
mkdir -p ~/DDS-Router-Workspace/src
cd ~/DDS-Router-Workspace
wget https://raw.githubusercontent.com/eProsima/DDS-Router/main/ddsrouter.repos
vcs import src < ddsrouter.repos
colcon을 사용하여 모든 패키지를 한 번에 빌드하고 설치한다.
cd ~/DDS-Router-Workspace
colcon build --symlink-install
컴파일된 실행 파일을 사용하기 위해, 터미널 세션마다 다음 명령어를 실행하여 환경을 설정해야 한다. 편의를 위해 .bashrc 파일에 추가하여 자동으로 로드되게 할 수 있다.28
source ~/DDS-Router-Workspace/install/setup.bash
eProsima DDS Router의 모든 동작은 YAML 형식의 설정 파일을 통해 제어된다. 파일의 구조는 직관적이며, 주요 섹션은 다음과 같다.21
version: 설정 파일의 버전 (예: v4.0).participants: 라우터의 통신 인터페이스를 정의하는 배열. 라우터의 핵심 설정 부분이다.allowlist / blocklist: 특정 토픽의 라우팅을 허용하거나 차단하는 규칙을 정의한다.builtin-topics: DDS의 내장 토픽(Discovery 정보 등)을 라우팅할지 여부를 설정한다.다음 표는 participants 설정에 사용되는 주요 파라미터를 요약한 것이다. 이 표는 개발자가 빠르게 설정을 구성할 수 있도록 돕는 빠른 참조 가이드 역할을 한다.
표 5.2.1: eProsima DDS Router Participant 주요 설정 파라미터
| 파라미터 | 설명 | 예시 값 |
|---|---|---|
name |
참여자의 고유한 이름. | local_participant_0 |
kind |
참여자의 종류. 로컬 DDS 도메인, WAN 연결 등을 결정한다. | local, wan, discovery-server |
domain |
kind가 local일 때, 참여할 DDS 도메인 ID. |
0, 1,… |
listening-addresses |
WAN 참여자가 외부 연결을 수신 대기할 주소와 포트 목록. | ip: 0.0.0.0, port: 11666 |
connection-addresses |
WAN 참여자가 연결을 시도할 원격 라우터의 주소와 포트 목록. | ip: 203.0.113.10, port: 11666 |
transport |
사용할 전송 프로토콜. | udp, tcp |
external-port |
NAT 환경에서 외부에서 접근 가능한 공용 포트. | 34567 |
다음은 일반적인 사용 사례에 대한 완전한 YAML 설정 파일 예제이다.
가장 기본적인 시나리오로, 로컬 네트워크 내의 DDS 도메인 0과 도메인 1을 연결한다. 이 설정은 두 도메인 간의 모든 토픽 트래픽을 양방향으로 전달한다.
# file: simple-bridge.yaml
version: v4.0
participants:
- name: participant_domain_0
kind: local
domain: 0
- name: participant_domain_1
kind: local
domain: 1
위의 도메인 브리지 시나리오에서, ‘HelloWorldTopic’이라는 특정 토픽만 라우팅하도록 allowlist를 추가한다. blocklist가 명시되지 않으면, allowlist에 없는 모든 토픽은 차단된다.
# file: selective-filter.yaml
version: v4.0
allowlist:
- name: HelloWorldTopic
type: HelloWorld # 데이터 타입 이름
participants:
- name: participant_domain_0
kind: local
domain: 0
- name: participant_domain_1
kind: local
domain: 1
지리적으로 떨어진 두 개의 LAN을 연결하는 시나리오이다. 각 사이트에 라우터가 하나씩 배포된다고 가정한다.
라우터 1 (Site A) 설정:
# file: router-A.yaml
version: v4.0
participants:
# 로컬 LAN (도메인 0) 인터페이스
- name: lan_participant
kind: local
domain: 0
# WAN 인터페이스
- name: wan_participant
kind: wan
transport: tcp
listening-addresses:
- ip: 0.0.0.0
port: 11666
connection-addresses:
- ip: 198.51.100.20 # 라우터 2의 공인 IP
port: 11666
라우터 2 (Site B) 설정:
# file: router-B.yaml
version: v4.0
participants:
# 로컬 LAN (도메인 5) 인터페이스
- name: lan_participant
kind: local
domain: 5
# WAN 인터페이스
- name: wan_participant
kind: wan
transport: tcp
listening-addresses:
- ip: 0.0.0.0
port: 11666
connection-addresses:
- ip: 203.0.113.10 # 라우터 1의 공인 IP
port: 11666
DDS Router는 터미널에서 간단한 명령어로 실행할 수 있다. -c 또는 --config-path 옵션으로 설정 파일의 경로를 지정한다.30
ddsrouter -c /path/to/your/config.yaml
라우터가 정상적으로 동작하는지 검증하기 위해, ShapesDemo와 같은 시각화 도구나 간단한 발행/구독 애플리케이션을 사용할 수 있다.31 예를 들어, ‘단순 도메인 브리지’ 시나리오에서는 한 터미널에서 도메인 0으로 ShapesDemo 발행자를 실행하고, 다른 터미널에서 도메인 1로 구독자를 실행한다. 라우터가 실행되면, 이전에는 통신할 수 없었던 두 ShapesDemo 인스턴스 간에 도형 데이터가 전달되는 것을 확인할 수 있다.
RTI Connext Routing Service는 상용 DDS 솔루션의 선두주자인 RTI(Real-Time Innovations)가 제공하는 라우팅 솔루션이다. 대규모의 복잡하고 지리적으로 분산된 시스템을 확장하고 통합하는 데 초점을 맞춘 강력한 기능을 제공하며, 고도의 신뢰성과 성능이 요구되는 미션 크리티컬 산업 분야에서 널리 사용된다.
RTI Routing Service는 단순한 데이터 전달 도구가 아니라, RTI Connext 제품군(Product Suite)의 핵심 구성 요소이다.9 이 제품군에는 시스템 모니터링을 위한 Admin Console, 데이터 기록 및 재생을 위한 Recording Service, 그리고 강력한 보안 기능을 제공하는 Security Plugins 등이 포함되어 있으며, Routing Service는 이 모든 도구와 긴밀하게 통합되어 동작한다.32 이러한 생태계 접근 방식은 개발, 배포, 운영, 유지보수에 이르는 시스템의 전체 수명 주기에 걸쳐 일관되고 강력한 관리 기능을 제공하는 것을 목표로 한다.
RTI Routing Service는 eProsima DDS Router와 같은 오픈 소스 솔루션과 차별화되는 여러 고급 기능을 제공한다.
데이터 변환(Data Transformation): 이는 RTI Routing Service의 가장 강력하고 독보적인 기능이다. 라우터는 데이터를 전달하는 과정에서 실시간으로 내용을 변환할 수 있다.9 단순히 토픽 이름을 바꾸는 수준을 넘어, 서로 다른 데이터 타입(Type)을 사용하는 시스템 간의 통신을 가능하게 한다.15 예를 들어, 구형 시스템에서 사용하는
LegacySensorData 타입을 신형 시스템에서 사용하는 ModernSensorData 타입으로 필드를 매핑하고 단위를 변환하여 전달할 수 있다.
콘텐츠 필터링(Content Filtering): 단순한 토픽 기반 필터링을 넘어, 데이터의 내용(값)에 기반한 필터링을 지원하고 이 필터 조건을 원격 네트워크로 전파할 수 있다.17 예를 들어, 원격지의 구독자가 “온도가 100도 이상인 데이터만 필요하다”는 필터를 설정하면, 라우터는 이 조건에 맞는 데이터만 WAN을 통해 전송한다. 이는 불필요한 네트워크 대역폭 낭비를 최소화하는 데 매우 효과적이다.
플러그형 아키텍처 (어댑터 및 프로세서): Routing Service는 플러그인을 통해 기능을 무한히 확장할 수 있는 구조를 가지고 있다. RTI는 MQTT, 파일, JMS 등 비-DDS 시스템과 연동하기 위한 다양한 어댑터(Adapter)를 제공하거나 개발할 수 있도록 SDK를 지원한다.18 또한, 사용자는 커스텀 프로세서(Processor)를 C/C++/Java 등으로 직접 개발하여 복잡한 라우팅 로직이나 데이터 처리 알고리즘을 라우터 내부에 구현할 수 있다.18 이를 통해 Routing Service는 단순한 DDS 브리지를 넘어 강력한 ‘통합 허브(Integration Hub)’로 기능할 수 있다.
이러한 고급 기능, 특히 데이터 변환 기능은 시스템의 수명 주기 관리 측면에서 매우 중요한 의미를 가진다. 국방, 항공우주와 같이 수십 년간 운영되는 시스템에서는 필연적으로 구형 컴포넌트와 신형 컴포넌트가 공존하게 된다. 9 문서에서 언급된 “데이터 모델의 진화(Data model evolution)”와 17의 “송신과 수신 애플리케이션이 동일한 데이터 구조를 사용할 필요가 없도록 데이터 타입을 변경할 수 있다”는 설명은 바로 이 점을 지적한다. 신형 컴포넌트가 새로운 데이터 모델을 사용하더라도, 기존의 구형 컴포넌트를 수정하는 것이 불가능하거나 엄청난 비용이 드는 경우가 많다. 이때 RTI Routing Service를 ‘번역 계층(Translation Layer)’으로 배치하면, 구형과 신형 데이터 모델 간의 변환을 라우터가 담당하게 된다. 이는 각 하위 시스템이 서로의 개발 주기나 데이터 모델에 종속되지 않고 독립적으로 발전할 수 있도록 하는 ‘디커플링 에이전트(Decoupling Agent)’ 역할을 수행하는 것이다. 이는 단순한 데이터 전달과는 차원이 다른, 아키텍처 수준의 유연성을 제공하는 핵심적인 가치이다.
Routing Service는 RTI의 강력한 툴링 생태계와 완벽하게 연동된다. RTI Administration Console을 사용하면 원격에서 실행 중인 Routing Service에 접속하여 라우트 상태, 데이터 처리량, 지연 시간 등의 성능 지표를 실시간으로 모니터링하고, 동적으로 설정을 변경할 수도 있다.33
또한, RTI Security Plugins와 완벽하게 통합되어 인증, 접근 제어, 암호화 등 DDS-Security 표준을 준수하는 강력한 보안 기능을 라우팅 경로 전체에 적용할 수 있다.34 이를 통해 민감한 데이터가 여러 네트워크 경계를 넘어 전달될 때 종단 간(end-to-end) 보안을 보장할 수 있다.
RTI Connext Routing Service는 상용 소프트웨어로, 사용을 위해서는 라이선스 구매가 필요하다.15 이는 초기 도입 비용이 발생함을 의미하지만, 동시에 미션 크리티컬 시스템에 필수적인 여러 이점을 제공한다. RTI는 전문적인 기술 지원(Professional Support), 상세하고 체계적인 공식 문서, 그리고 제품의 지속적인 유지보수 및 업데이트를 보장한다.17 안정성과 신뢰성이 최우선인 시스템에서는 이러한 상용 지원의 가치가 매우 크다.
이 장에서는 RTI Connext Routing Service를 시스템에 배포하고 설정하는 실질적인 절차를 다룬다. 환경 설정부터 복잡한 XML 파일 작성, 그리고 배포 후 모니터링까지의 과정을 상세히 설명한다.
RTI Routing Service는 RTI Connext DDS Professional 제품군에 포함되어 배포된다. 설치 과정 자체는 일반적인 소프트웨어 설치와 유사하지만, 실행을 위해서는 몇 가지 중요한 환경 설정이 필요하다.
RTI Connext DDS가 설치된 디렉토리 경로를 NDDSHOME 환경 변수로 지정해야 한다. Routing Service 실행 파일과 관련 라이브러리들이 이 경로를 기준으로 동작한다.36
# 예시: Linux 환경
export NDDSHOME=/opt/rti_connext_dds-6.1.1
RTI 제품은 유효한 라이선스 파일(rti_license.dat)을 필요로 한다. 이 파일은 RTI로부터 발급받아 지정된 위치에 두거나, RTI_LICENSE_FILE 환경 변수를 통해 파일의 경로를 명시해야 한다.15
RTI Routing Service의 모든 설정은 XML 파일을 통해 이루어진다. 그 구조는 계층적이며, 주요 태그들의 역할을 이해하는 것이 중요하다.34
<routing_service>: 특정 라우팅 서비스 구성을 정의하는 최상위 태그. name 속성으로 고유한 이름을 가진다.<domain_route>: 데이터가 흐르는 경로의 양 끝, 즉 도메인 또는 커넥션을 정의한다.<participant>: <domain_route> 내에서 DDS 도메인에 대한 연결을 정의한다. domain_id와 QoS 설정을 포함한다.<session>: 동일한 QoS와 처리 방식을 공유하는 라우트들의 그룹이다.<topic_route>: 실제 데이터 라우팅 규칙을 정의하는 가장 핵심적인 태그. 입력(input)과 출력(output)을 지정한다.다음 표는 RTI Routing Service의 핵심 XML 태그들을 요약하여 구조를 쉽게 파악할 수 있도록 돕는다.
표 7.2.1: RTI Routing Service 핵심 XML 설정 태그
| 태그 | 설명 | 주요 속성/하위 태그 |
|---|---|---|
<routing_service> |
라우팅 서비스 전체 설정을 감싸는 루트 요소. | name |
<domain_route> |
두 개 이상의 참여자(네트워크) 간의 라우팅 경로를 정의. | name, <participant>, <connection> |
<participant> |
DDS 도메인에 대한 참여를 정의. | name, domain_id, <participant_qos> |
<session> |
라우트들의 논리적 그룹. | name, <topic_route> |
<topic_route> |
특정 토픽에 대한 라우팅 규칙을 상세히 정의. | name, <input>, <output>, <transformation> |
<input> |
데이터 소스를 정의. | participant, topic_name, registered_type_name |
<output> |
데이터 목적지를 정의. | participant, topic_name, registered_type_name |
<transformation> |
데이터 변환 로직을 정의. | <script>, <transformation_plugin> |
다음은 RTI Routing Service의 강력한 기능을 보여주는 XML 설정 예제들이다.
도메인 0에서 발행되는 Square 토픽을 도메인 1로 라우팅하는 기본 설정이다.16
<dds>
<routing_service name="SimpleDomainBridge">
<domain_route name="Route_0_to_1">
<participant name="Domain0_Participant">
<domain_id>0</domain_id>
</participant>
<participant name="Domain1_Participant">
<domain_id>1</domain_id>
</participant>
</domain_route>
<session name="ForwardingSession">
<topic_route name="Route_Square">
<input participant="Domain0_Participant">
<topic_name>Square</topic_name>
<registered_type_name>ShapeType</registered_type_name>
</input>
<output participant="Domain1_Participant">
<topic_name>Square</topic_name>
<registered_type_name>ShapeType</registered_type_name>
</output>
</topic_route>
</session>
</routing_service>
</dds>
도메인 0의 Square 토픽을 수신하여, 토픽 이름을 Circle로 변경하고 데이터 내용의 x 좌표 값을 100만큼 더해서 도메인 1로 발행하는 예제이다. 이는 <transformation> 태그의 강력함을 보여준다.39
<dds>
<routing_service name="TransformingBridge">
<session name="TransformationSession">
<topic_route name="Transform_Square_To_Circle">
<input participant="Domain0_Participant">
<topic_name>Square</topic_name>
<registered_type_name>ShapeType</registered_type_name>
</input>
<output participant="Domain1_Participant">
<topic_name>Circle</topic_name>
<registered_type_name>ShapeType</registered_type_name>
</output>
<transformation>
<script>
<language>lua</language>
<code>
-- 입력 데이터의 x 좌표에 100을 더함
output.x = input.x + 100
-- 나머지 필드는 그대로 복사
output.y = input.y
output.shapesize = input.shapesize
output.color = input.color
return output
</code>
</script>
</transformation>
</topic_route>
</session>
</routing_service>
</dds>
두 개의 라우터가 WAN을 통해 보안 TCP 연결을 맺는 설정이다. 멀티캐스트를 비활성화하고, TCP 전송 속성을 설정하며, 보안 플러그인을 활성화하는 위치를 보여준다.16
라우터 1 (Site A) 설정:
<dds>
<routing_service name="Secure_WAN_Router_A">
<domain_route name="WAN_Link">
<participant name="Local_LAN">
<domain_id>0</domain_id>
</participant>
<participant name="WAN_TCP">
<domain_id>99</domain_id> <participant_qos>
<discovery>
<initial_peers>
<element>tcpv4://198.51.100.20:7401</element>
</initial_peers>
</discovery>
<transport_builtin>
<mask>TCPV4_WAN</mask>
</transport_builtin>
<property>
<value>
<element>
<name>com.rti.serv.secure.enable</name>
<value>true</value>
</element>
</value>
</property>
</participant_qos>
</participant>
</domain_route>
</routing_service>
</dds>
(라우터 B는 initial_peers에 라우터 A의 주소를 명시하여 유사하게 설정)
Routing Service는 다음 명령어를 통해 실행한다. -cfgFile로 XML 파일 경로를, -cfgName으로 실행할 <routing_service>의 이름을 지정한다.
rtiroutingservice -cfgFile my_config.xml -cfgName Secure_WAN_Router_A
실행 후, RTI Admin Console을 실행하여 라우터의 관리 도메인(설정 파일의 <administration> 태그에 정의된 domain_id)에 접속하면, 라우터의 상태, 데이터 흐름, 성능 지표 등을 그래픽 인터페이스를 통해 실시간으로 확인하고 관리할 수 있다.33
지금까지 eProsima Fast DDS Router와 RTI Connext Routing Service의 아키텍처와 사용법을 각각 살펴보았다. 이 장에서는 두 솔루션을 직접적으로 비교 분석하고, 라우팅 시스템 구축 시 공통적으로 고려해야 할 보안, 성능, 문제 해결과 같은 고급 주제들을 다룬다.
두 라우터는 분산된 DDS 네트워크를 연결한다는 동일한 목표를 가지지만, 그 철학과 기능, 대상 시장에서 뚜렷한 차이를 보인다. 시스템 아키텍트가 프로젝트의 요구사항에 가장 적합한 솔루션을 선택하기 위해서는 이러한 차이점을 명확히 이해해야 한다.
표 8.1.1: 기능 및 아키텍처 비교: eProsima vs. RTI
| 항목 | eProsima Fast DDS Router | RTI Connext Routing Service |
|---|---|---|
| 라이선스 | Apache 2.0 (오픈 소스, 무료) 19 | 상용 라이선스 (유료, 기술 지원 포함) 32 |
| 설정 방식 | YAML 14 | XML 34 |
| 핵심 철학 | 경량, 고성능 데이터 포워더 14 | 엔터프라이즈급 통합 플랫폼 9 |
| 데이터 변환 | 지원하지 않음 (단순 전달에 집중) | 강력한 기능 제공 (타입, 토픽, 값 변환) 9 |
| 확장성 | 제한적 (기본 기능에 충실) | 플러그인 아키텍처 (Adapter, Processor)로 높은 확장성 18 |
| 툴링/모니터링 | Fast DDS Monitor 등 별도 오픈 소스 도구와 연동 41 |
Admin Console과 완벽히 통합된 원격 관리/모니터링 33 |
| 주요 생태계 | ROS 2, 로보틱스, 오픈 소스 커뮤니티 25 | 국방, 항공, 의료, 산업 자동화 등 미션 크리티컬 산업 9 |
| 보안 통합 | Fast DDS 보안 기능 활용 (XML 프로파일) 42 | Connext Security Plugins와 완벽 통합 (XML 직접 설정) 34 |
이 비교표는 의사 결정의 핵심적인 기준을 제공한다. eProsima Fast DDS Router는 라이선스 비용이 없고 ROS 2와의 통합이 뛰어나므로, 오픈 소스 기반의 프로젝트, 특히 로보틱스나 자율주행 연구 개발 단계에 매우 적합하다. 핵심 기능인 데이터 전달 성능에 집중하여 가볍고 빠르게 동작하는 것이 장점이다.
반면, RTI Connext Routing Service는 이종 시스템 간의 데이터 변환, 레거시 시스템 통합, 그리고 강력한 중앙 관리 및 모니터링 기능이 필수적인 대규모 엔터프라이즈 및 미션 크리티컬 시스템에 적합하다. 초기 도입 비용이 있지만, 보장된 기술 지원과 시스템의 장기적인 진화 및 유지보수를 지원하는 강력한 기능은 그 가치를 상쇄하고도 남는다.
분산된 네트워크를 연결할 때 보안은 가장 중요한 고려사항 중 하나이다. DDS Security 표준은 이를 위해 인증, 접근 제어, 암호화의 세 가지 핵심 플러그인을 정의한다.4
<participant_qos> 섹션에 보안 관련 프로퍼티를 직접 명시하여 인증, 암호화, 접근 제어 플러그인을 활성화하고 상세하게 설정할 수 있다.34 이는 라우팅 설정과 보안 설정을 하나의 파일에서 일관되게 관리할 수 있다는 장점이 있다.라우터는 데이터 경로의 중간에 위치하므로, 그 자체의 성능이 전체 시스템의 성능에 큰 영향을 미친다.
eProsima의 경우, 고속 데이터 전송 시 운영체제의 소켓 버퍼 크기를 늘려주는 것이 성능 향상에 도움이 될 수 있다. Fast DDS 문서에서는 send_socket_buffer_size와 listen_socket_buffer_size 파라미터 조정을 권장한다.45 또한, 제로카피 및 공유 메모리(Shared Memory) 전송을 활용하면 프로세스 간 통신 오버헤드를 극적으로 줄일 수 있다.46
RTI의 경우, 성능 문제의 가장 흔한 원인 중 하나는 QoS 불일치이다. 라우터의 DataReader와 DataWriter의 QoS가 원본 발행자 및 최종 구독자와 호환되지 않으면 불필요한 재전송이나 통신 실패가 발생할 수 있으므로, QoS 설정을 신중하게 검토해야 한다.8 RTI 역시
FlatData 및 Zero Copy 전송과 같은 고성능 기능을 지원하며, 이를 활성화하여 성능을 최적화할 수 있다.34
일반적으로 WAN 구간에서는 TCP와 UDP 사이의 트레이드오프를 고려해야 한다. TCP는 신뢰성이 높고 방화벽 통과가 용이하지만 UDP에 비해 지연 시간이 길고 오버헤드가 크다. 반면 UDP는 지연 시간이 짧아 실시간성에 유리하지만, WAN 환경에서는 패킷 손실 가능성이 높다.12 대부분의 라우터는 WAN 구간에 TCP를 사용하는 것을 기본으로 하거나 권장한다.
라우터 설정 및 운영 시 발생할 수 있는 일반적인 문제와 해결 방안은 다음과 같다.
RTI Admin Console과 같은 도구를 사용해 확인해야 한다.8더 복잡한 문제에 직면했을 경우, eProsima DDS-Router의 GitHub 이슈 페이지 48나 RTI의 커뮤니티 포털 및 공식 문서의 알려진 이슈(Known Issues) 목록 47은 매우 유용한 문제 해결 리소스가 된다.
본 보고서는 DDS(Data Distribution Service)의 기본 원리부터 시작하여, 분산 시스템이 확장됨에 따라 발생하는 연결성 문제를 해결하기 위한 DDS 라우터의 필요성과 아키텍처, 그리고 실제 구현 방법을 심도 있게 고찰했다. 마지막으로 시스템 아키텍트를 위한 핵심적인 결론을 종합하고, DDS 연결성의 미래를 조망한다.
이 보고서의 핵심 논제는 다음과 같이 요약할 수 있다: 표준 DDS는 단일 LAN 환경에서의 강력하고 안정적인 실시간 통신에 매우 뛰어나지만, 복잡한 네트워크 경계를 넘나드는 확장 가능하고, 관리 용이하며, 안전한 분산 시스템을 구축하기 위해서는 DDS 라우터가 필수적인 아키텍처 구성 요소이다.
라우터는 단순히 네트워크를 연결하는 도구를 넘어, 시스템 전체의 아키텍처를 향상시키는 역할을 수행한다. 라우터를 통해 트래픽을 제어하고, 발견 메커니즘의 범위를 제한하며, 보안을 강화하고, 서로 다른 시스템을 통합할 수 있다.
아키텍트가 어떤 라우터를 선택할지에 대한 결정은 프로젝트의 특성에 따라 명확해진다.
궁극적으로 라우터의 도입은 ‘계층적 데이터버스(Layered Databus)’와 같은 우수한 아키텍처 패턴을 구현할 수 있게 하는 전략적 선택이다.
DDS 기술과 이를 둘러싼 컴퓨팅 환경은 계속해서 발전하고 있다. 클라우드 네이티브 아키텍처, 엣지 컴퓨팅, 그리고 로보틱스와 자율주행차 같은 자율 시스템의 폭발적인 증가는 DDS 연결성에 새로운 과제와 기회를 제공한다.14
이러한 미래 환경에서 DDS 라우터의 역할은 더욱 중요해질 것이다. 라우터는 더 이상 단순한 네트워크 브리지가 아니다.
으로 진화하고 있다. 시스템이 더욱 분산되고 상호 연결됨에 따라, 지능적인 DDS 라우터는 미래의 복잡한 실시간 분산 시스템을 구축하는 데 있어 그 어떤 때보다 핵심적인 역할을 수행하게 될 것이다.
| Routing Service Problem | Data Distribution Service (DDS) Community RTI Connext Users, accessed July 6, 2025, https://community.rti.com/forum-topic/routing-service-problem |