DDS(Domain ID)와 네트워크 분리 개념
DDS 통신의 기본 구조
DDS(Data Distribution Service)는 분산 환경에서 데이터를 교환하기 위한 퍼블리셔/서브스크라이버(Pub/Sub) 구조를 제공한다. 이때 ROS2는 DDS를 통신 레이어로 채택하여, 노드 간 메시지 송수신을 구현한다. DDS는 같은 도메인에 속한 참여자(Participant)들만이 서로 통신할 수 있도록 설계되어 있는데, 이 “도메인”을 구분하는 것이 Domain ID 개념이다.
도메인이란 DDS 시스템에서 데이터를 교환하는 논리적 그룹을 의미하며, Domain ID는 그 그룹을 식별하기 위한 32비트 정수 값이다. 일반적으로 로컬 호스트 단위에서 DDS 라이브러리가 가지는 기본값(예: 0)으로 지정되지만, 여러 대의 머신을 연동하거나 통신의 범위를 분리하고자 할 때는 별도의 Domain ID를 설정한다.
예를 들어, 단일 PC 내에서 여러 ROS2 애플리케이션 노드가 동시에 동작하더라도, 이들이 서로 간섭하지 않게 하려면 머신마다 혹은 프로세스마다 다른 Domain ID를 할당할 수 있다. 또는 다수의 머신이 하나의 ROS2 네트워크로 묶일 경우에는 동일한 Domain ID를 사용하여 서로 통신하도록 설정한다.
Domain ID와 물리적 네트워크 구성
DDS에서 Domain ID는 논리적인 분할을 의미하지만, 물리적인 네트워크 인터페이스와 연동될 때, 이 “논리적 분할”과 “물리적 분할”의 개념을 어떻게 구상하느냐가 중요하다. Domain ID에 의한 논리적 분할과 라우팅, VLAN, 혹은 Subnet 설정 등에 의한 물리적 분할은 별개의 차원에서 고려된다. 네트워크 엔지니어링 측면에서 IP 네트워크 수준의 분리는 Machine/Node 레벨에서 트래픽을 물리적으로(또는 가상적으로) 차단하거나 허용한다. DDS 레벨에서의 분리는 애플리케이션 단에서 각 노드에게 할당된 Domain ID에 따라 트래픽이 주고받을 수 있는지를 결정한다.
Domain ID 할당의 예
멀티머신 환경에서 ROS2 네트워크를 효율적으로 구성하기 위해서는 Domain ID를 계획적으로 할당해야 한다. 다음과 같은 예시를 들어보자. 한 연구실에서 3대의 로봇이 있고, 각각 ROS2 노드를 동작시킨다. 이 로봇들이 서로의 센서 데이터를 공유하길 원한다면, 모두 같은 Domain ID를 설정한다.
만약 각 로봇 내에서 독립적인 애플리케이션(예: 디버깅 목적의 개발용 애플리케이션)이 동시에 동작해야 하되, 메인 애플리케이션과는 통신이 섞이지 않도록 구분하고 싶다면, 로봇 내부에서 두 개의 Domain ID를 할당한다. 예를 들어 로봇1에서 Main Application은 $D=10$, Debug Application은 $D=11$을 사용한다. 이 경우 메인과 디버그 통신이 로컬에서 완전히 분리된다.
네트워크 최적화와 Domain ID
네트워크 자원이 제한적이거나, IP 기반의 QoS(Quality of Service) 정책을 활용해야 할 때 Domain ID로 논리적 트래픽 경계를 설정해 두면 관리가 편리해진다. 예를 들어, 특정 도메인에서만 사용하는 주파수가 높거나 대역폭이 큰 토픽(Topic)이 있다면, 이를 별도의 Domain ID로 격리하여 통신 트래픽을 제한하는 식으로 구성할 수 있다.
동적 할당이 아닌 정적 할당도 고려해야 할 상황이 있다. 여러 대의 로봇 및 센서 노드들이 각각 Domain ID를 가질 때, $D_0, D_1, \dots, D_n$ 형태로 미리 고정해 두면, 네트워크를 확장하거나 변경할 때 복잡도가 낮아지는 장점이 있다.
Discovery 프로세스에서의 Domain ID 역할
DDS의 Discovery 과정은 각 DomainParticipant가 네트워크를 스캔하여, 동일한 Domain ID를 사용하는 다른 Participant를 탐색하는 절차로 이해할 수 있다. ROS2 노드가 실행될 때, 내부적으로 DDS Participant가 생성되고, 이 Participant는 특정 Domain ID를 사용한다. Discovery 로직은 다음과 같은 순서로 진행된다.
Participant 생성 ROS2 노드가 구동되면 DDS 레이어에서 DomainParticipant가 생성된다. 이때 Participant는 할당된 Domain ID를 기반으로 동작한다.
Discovery 프로토콜 실행 Participant는 네트워크를 브로드캐스트 혹은 멀티캐스트하여(주로 RTPS 프로토콜 사용), 동일한 Domain ID를 사용하는 다른 Participant가 있는지 검색한다.
Participant 상호 인증 서로 Domain ID가 같고, QoS(Profile 등) 구성 상 호환이 가능하면 이들이 서로 메시지 트래픽을 교환할 수 있다는 점을 등록(Announce)하고, Publisher/Subscriber를 맵핑한다.
여기서 Domain ID가 다른 Participant가 동일 네트워크 상에 있더라도, Discovery 단계에서 서로를 전혀 인지하지 못하게 된다. 즉, 로컬 네트워크 상에 여러 Domain ID가 혼재하더라도, 논리적으로는 완전히 분리된 통신 채널을 형성한다.
Domain ID를 통한 네트워크 분산처리 설계
ROS2 시스템을 멀티머신에 걸쳐 구축할 때, 어떤 노드는 빈번히 데이터를 퍼블리시하고, 어떤 노드는 주로 서브스크라이빙만을 하는 식으로 역할이 달라질 수 있다. 트래픽이 많은 노드가 서로 붙어 있으면 네트워크 병목을 일으킬 수 있으므로, 도메인 분할을 통해 적절히 분산처리를 유도할 수 있다.
고빈도 토픽 분리: 반복 주기(주파수)가 높은 센서 데이터 토픽은 별도의 Domain ID로 분리하고, 상대적으로 주기가 낮은 제어 신호 등을 다른 Domain ID에 배치한다.
계층적 분할: 로컬 도메인(예: 로봇 내부 통신)과 글로벌 도메인(예: 로봇 간 통신)을 물리적 네트워크 뿐 아니라 Domain ID 레벨에서도 분리하여, Discovery 범위를 최소화하고 트래픽 충돌을 줄인다.
지연 시간 관리: 특정 Domain ID에서만 QoS를 활용하여 저지연(실시간)에 최적화된 설정을 적용하고, 다른 Domain ID에서는 상대적으로 관대한 QoS를 적용함으로써 전체 네트워크 부하를 제어할 수 있다.
VLAN, VPN 등과 연계한 네트워크 분리
실제 운영 환경에서 물리적 네트워크를 분리하거나, VLAN(Virtual LAN)을 통해 가상적으로 네트워크 세그먼트를 나누는 방식은 DDS의 Domain ID 분할과 상호 보완적이다. VLAN이나 VPN은 IP 계층에서 패킷의 전달 경로와 접근 권한을 분할하고, DDS Domain ID는 애플리케이션 계층에서 메시지 교환 범위를 논리적으로 구분한다. 이를 혼합 구성하면 보안과 성능 양쪽 측면에서 이점을 얻을 수 있다.
예를 들어, 외부 네트워크와 내부 통신망을 물리적으로 분리하면서도, 내부망에서는 여러 도메인을 운영하여 각각의 구역(Zone)마다 업무나 애플리케이션 특성에 맞는 통신 정책을 적용할 수 있다. VLAN과 DDS Domain ID를 함께 사용할 경우, VLAN 간 라우팅 정책에 따라 서로 다른 Domain ID 그룹을 아예 물리적으로 차단할 수도 있으며, 이는 보안성 강화와 트래픽 제어 측면에서 유리하다.
멀티 도메인 브리징(Domain Bridging)
멀티머신 환경에서 네트워크를 특정 도메인 단위로 분할하여 운영하다 보면, 때로는 서로 다른 Domain ID 간의 통신이 필요해지는 경우가 있다. 예를 들어, “Domain 0”에 속한 그룹과 “Domain 1”에 속한 그룹이 물리적으로는 같은 네트워크 상에 있더라도, Domain ID가 다르면 Discovery 단계에서 서로를 인식하지 못한다. 따라서 두 도메인 간 메시지를 교환하기 위해서는 “브리지(Bridge)” 노드가 필요하다.
ROS2에서는 “Domain Bridge”라는 개념을 통해 서로 다른 도메인에 걸쳐 있는 노드들 간 토픽을 중계할 수 있다. 브리지 노드는 다음과 같은 구조로 동작한다.
두 개(또는 그 이상)의 도메인에 각각 Participant를 생성 브리지 노드는 내부적으로 Domain 0에 대한 Participant와 Domain 1에 대한 Participant를 동시에 구동한다.
중계 대상 토픽 구독(Subscribe) 브리지 노드는 Domain 0에서 특정 토픽을 구독하고, 도착한 메시지를 임시 저장한다.
다른 도메인에 동일 토픽(또는 이름이 다른 토픽)을 퍼블리시(Publish) 브리지 노드는 구독한 메시지를 Domain 1의 Participant를 통해 재전송한다.
이를 통해 도메인이 다르더라도 브리지 노드를 매개로 메시지를 교환할 수 있다. 다만 이 방식은 네트워크 오버헤드가 증가할 수 있고, 브리지 노드가 단일 장애점(Single Point of Failure)이 될 수 있으므로 적절한 구조적 설계와 모니터링이 필요하다.
다음은 서로 다른 두 개의 도메인이 존재하는 단순 예시를 그림으로 표현한 것이다.
위 그림에서 Node A, B는 Domain 0에 속하고, Node C, D는 Domain 1에 속한다. 브리지 노드는 양쪽 Domain에 접근 권한이 있다. B가 퍼블리시한 메시지를 브리지 노드가 받아서, C에게 재전송하는 식으로 통신한다.
네트워크 토폴로지와 Domain ID의 매핑
물리적인 네트워크 토폴로지가 단순하다면, 예컨대 모든 노드가 같은 스위치나 라우터에 연결되어 있다면, Domain ID 설계 또한 단순할 수 있다. 반면, 네트워크가 계층 구조이거나 VLAN이 섞여 있다면, Domain ID와 네트워크 세그먼트 간의 매핑을 정교하게 구성해야 한다.
계층형 네트워크: 상위 네트워크(백본)와 하위 네트워크(로컬 LAN)가 구분되는 환경에서, 상위 네트워크에 연결된 노드는 하나의 Domain ID를 공유하고, 하위 네트워크별로 또 다른 Domain ID들을 설정할 수 있다.
메시형 네트워크: 여러 노드가 그물망(Mesh)처럼 연결된 환경이라면, 특정 그룹(물리적으로 인접하거나 응답 시간이 중요한 그룹)에 대해 같은 Domain ID를 매핑하고, 외부 그룹과는 브리지를 통해 연결하도록 설계할 수 있다.
VLAN 연계: VLAN을 통해 물리적 세그먼트를 분할한 뒤, 각 VLAN 내에서 공통 Domain ID를 사용하고, VLAN 간 통신은 브리지를 사용하거나 라우팅 규칙에 따라 제어한다.
도메인 액티비티 모니터링
멀티 도메인을 운용하면, 어떤 도메인에는 토픽이 과다하게 몰릴 수도 있고, 어떤 도메인은 거의 트래픽이 없을 수도 있다. 네트워크 모니터링 툴(예: Wireshark)이나 DDS-Domain 분석 툴(예: Fast DDS Monitor 등)을 활용하면, 도메인별로 트래픽 양과 Discovery/Match 여부를 관찰할 수 있다.
트래픽 부하 확인: 특정 도메인에서 초당 패킷 수나 바이트 수가 과도하게 높다면, 도메인 분할이나 QoS 조정을 검토해야 한다.
매칭 실패 분석: 실제로는 통신이 되어야 하는데 브리지 설정이 잘못되었거나, Domain ID가 잘못되어 메시지가 오가지 않는 경우가 있다. 이때 Discovery 로그를 확인하여 어떤 Participant가 다른 Participant를 인식하지 못했는지 파악한다.
QoS 연동 확인: 여러 도메인을 운용하는 경우, 각 도메인에 서로 다른 QoS 프로필을 적용할 수 있다. 예컨대 실시간성이 중요한 도메인은 Reliablity=RELIABLE, History=KEEP_LAST, Depth=1처럼 설정하고, 상대적으로 중요도가 낮은 도메인은 BEST_EFFORT로 설정할 수도 있다. 이럴 때 브리지 구간에서 QoS 호환성이 유지되는지 점검해야 한다.
ROS2에서 Domain ID 설정하기
ROS2에서는 기본적으로 Domain ID를 0으로 사용한다. 만약 여러 도메인을 필요로 한다면 다음 방법 중 하나로 Domain ID를 설정할 수 있다.
환경 변수 이용: ROS2는 내부적으로 ROS_DOMAIN_ID라는 환경 변수를 참조하여 Domain ID를 결정한다. 셸에서 다음과 같이 설정할 수 있다.
이 환경 변수를 설정한 후에 새 셸에서 ROS2 노드를 실행하면, 해당 노드는 Domain ID 10으로 동작한다.
Launch 파일에서 설정: ROS2의 launch 파일(.launch.py)에서 ROS_DOMAIN_ID 환경 변수를 설정하도록 스크립트를 작성할 수도 있다.
이렇게 하면 launch 파일을 통해 노드를 구동할 때 자동으로 Domain ID 10이 적용된다.
DDS 설정 파일 활용: 각 DDS 벤더별로 제공하는 XML 또는 환경 설정 파일에서 Domain ID를 지정할 수도 있다. 예를 들어, Fast DDS의 경우 fastdds.xml 설정 파일에 다음과 같은 방식으로 Domain ID를 정의할 수 있다.
이러한 설정 파일을 ROS2가 인식하도록 환경 변수(예: FASTRTPS_DEFAULT_PROFILES_FILE) 등을 연계해두면, ROS2 구동 시에 해당 DDS 구성으로 Participant가 생성된다.
Domain ID와 ROS2 네임스페이스(Namespaces)의 차이
ROS2에서 네임스페이스(namespace)는 토픽, 서비스, 액션 이름을 논리적으로 그룹화하기 위한 개념이다. 즉, 네임스페이스를 통해 “/robot1/cmd_vel”, “/robot2/cmd_vel”처럼 토픽 이름을 구분한다. 반면 Domain ID는 DDS 레벨의 통신 범위를 분할하는 개념이므로, 서로 다른 Domain ID에 속한 노드끼리는 아예 Discovery 단계부터 배제되어 메시지를 교환하지 못한다.
네임스페이스: 같은 Domain 안에서 토픽 이름을 구분하는 방식. 예: /robot1/camera, /robot2/camera
Domain ID: 네트워크 자체를 분할. Domain 10과 Domain 11은 물리적으로 같은 LAN 상에 있더라도 서로 통신하지 않는다.
Domain ID 동적 변경 가능성
ROS2에서는 런타임에 Domain ID를 동적으로 바꿀 수 있는 표준 API를 제공하지 않는다. 따라서 노드가 이미 실행 중인 상태에서 Domain ID를 변경하려면, 노드를 재시작해야 한다. 이 점을 고려하여 시스템을 설계할 때, 도메인이 자주 바뀌지 않도록 미리 계획하는 것이 중요하다.
리부팅 이슈: 임베디드 환경(예: 로봇)에선 노드를 재시작하는 데 부하가 크지 않을 수 있으나, 서버 환경이나 대규모 분산 환경에서는 노드 재시작 시 다운타임(서비스 중단)이 발생할 수 있다.
브리지 노드 구현: 만약 특정 상황에서 도메인 간의 연결이 일시적으로 필요하다면, 전체 도메인 설정을 바꾸는 대신 브리지 노드를 동적으로 띄웠다가 종료하는 방식이 훨씬 유연하다.
DDS Security와 Domain ID
DDS 보안을 강화하기 위해 DDS Security 플러그인(예: RTI Connext DDS Secure, Fast DDS Security)을 활용할 때, Domain ID는 접근 제어(Access Control) 정책의 일부가 될 수 있다. 보안 구성을 통해 특정 도메인에 대해 인증된 Participant만 접근을 허용하고, 다른 도메인에서는 접속을 거부하도록 설정 가능하다. 이렇게 하면 단순히 Domain ID를 분리하는 것뿐 아니라, 암호화(Encryption)와 인증(Authentication) 레벨에서도 격리도를 높여 네트워크 보안을 강화할 수 있다.
엑세스 제어 정책: Domain ID 단위로 허용/거부 목록을 설정한다.
암호화 프로파일 분리: 도메인별로 서로 다른 암호화 키를 사용하여, 무단 접근이나 패킷 스니핑을 방지한다.
대규모(Scalable) 시스템에서의 Domain ID 운용
ROS2를 사용하는 프로젝트가 소형 로봇 한두 대 수준이라면 Domain ID를 단순히 0으로 맞춰두고 공유해도 문제가 없다. 하지만 시스템 규모가 점점 커지고, 서로 다른 역할을 하는 노드가 수십, 수백 개로 늘어나면 도메인 설계가 매우 중요해진다. 일반적으로는 다음 방향으로 설계 전략을 세울 수 있다.
도메인별 역할 구분: 센서 수집 전용 도메인, 데이터 처리 전용 도메인, 로봇 제어 전용 도메인 등으로 나누면, Discovery 범위가 축소되어 네트워크 부하가 줄어든다.
도메인 간 브리지 배치: 일부 노드(브리지)가 여러 도메인에 걸쳐서 중요한 토픽만 중계한다.
고정 Domain ID 할당: 개발 환경, 시뮬레이션 환경, 실제 운용 환경마다 도메인을 미리 지정해두면, 디버깅 시 도메인 충돌을 방지할 수 있다.
이러한 방안을 통해 노드가 폭발적으로 증가해도, 각 도메인 단위로 통신량이 분산되어 안정적으로 운영할 수 있다.
시뮬레이션 환경에서의 Domain ID
시뮬레이션 툴(Gazebo, Ignition, Webots 등)과 실제 로봇 시스템을 동시에 운용할 때는, 시뮬레이터 노드와 실제 로봇 노드 간 교란을 최소화하기 위해 서로 다른 Domain ID를 자주 사용한다. 예를 들어, 실제 로봇이 Domain 0을 사용 중이라면, 시뮬레이션은 Domain 1을 할당하는 식이다. 그리고 두 도메인 간 상호작용이 필요한 경우, 브리지 노드를 통해 일부 토픽만 양방향으로 연결한다.
성능 안정: 시뮬레이션에서 발생하는 대량의 센서 데이터가 실제 로봇 제어 노드로 유입되지 않도록 막아, 불필요한 트래픽을 줄인다.
테스트 격리: 실세계 환경과 시뮬레이터가 논리적으로 분리되어 있어, 시뮬레이터 충돌이나 멈춤이 실 로봇 시스템에 영향을 주지 않는다.
Domain ID와 노드 감시(Health Monitoring)
멀티머신 환경에서 노드가 여러 도메인으로 나뉘어 동작하면, 노드 상태(가동 여부, CPU/메모리 점유율 등)를 모니터링하기가 더 까다롭다. 이를 효율적으로 처리하기 위해서는 다음과 같은 방법이 있다.
Central Monitor 도메인 모든 머신에서 헬스체크(Heart-beat) 노드를 별도 도메인(예: Domain 99)에 띄워, 각 노드가 상태 정보를 퍼블리시하도록 구성한다. 모니터링 도구는 Domain 99에만 연결되어 헬스체크 토픽을 수신하면 된다.
네트워크 레벨 모니터링 DDS 레벨이 아닌 IP 기반 모니터링 툴(예: Prometheus, Nagios 등)을 활용해 CPU 사용량, 네트워크 트래픽 등을 수집한다. 도메인이 달라도 IP 계층에서는 수집 가능하므로, 물리적 혹은 VLAN 단위로만 접근 권한을 조절하면 된다.
로그 수집 통합 ROS2 로깅(ROS2 log) 메시지나 DDS 레이어 로그를 각 도메인별로 분산하여 저장하면 디버깅이 어려울 수 있다. 이를 통합 관리하기 위해 중앙 로그 서버(Elastic Stack 등)로 전송하거나, 도메인별 로그 경로를 자동으로 태깅하여 구분짓는 방식을 취할 수 있다.
Domain Routing(도메인 라우팅) 고도화
일부 DDS 벤더(예: RTI Connext DDS)는 도메인 라우터(Domain Router)라는 기능을 제공하여, 서로 다른 Domain ID 간 토픽 라우팅 규칙을 매우 세밀하게 제어할 수 있게 한다. 예를 들어, 특정 토픽은 Domain 0 → Domain 1로만 전달 가능하게 하거나, QoS 설정에 따라 전달 여부를 다르게 지정하는 식이다.
퍼블리싱 방향 제어: 도메인 간 데이터 흐름을 단방향으로만 허용해 보안이나 트래픽 사용량을 줄일 수 있다.
QoS 기반 라우팅: 높은 우선순위를 가진 토픽만 라우팅하고, 나머지는 필터링할 수 있다.
멀티홉 라우팅: 도메인이 여러 계층으로 구분되어 있어도, 라우터를 중간중간 연결하면 최종적으로 원하는 도메인까지 메시지를 전달할 수 있다.
이러한 고급 기능은 ROS2 표준 패키지에서 직접 제공되는 것은 아니지만, DDS 설정을 커스터마이징함으로써 활용할 수 있다.
성능 분석 툴과 Domain ID
고빈도 토픽이나 대용량 이미지/PointCloud 데이터가 여러 도메인에서 동시에 퍼블리시되면, 네트워크가 어느 지점에서 병목이 생기는지 파악하기 어렵다. 이를 위해서는 성능 분석 툴과 도메인 정보를 함께 사용해야 한다.
Wireshark: RTPS 패킷을 캡처하여, 각 Domain ID별 트래픽 패턴을 분석할 수 있다. 필터를 “rtps”로 설정하고, 패킷 헤더 내 Domain ID 필드를 확인한다.
Fast DDS Monitor: Domain Participant, Publisher, Subscriber를 시각적으로 보여주고, Topic간 연결 상태와 트래픽 통계를 도메인 단위로 구분해준다.
ROS2 CLI: 간단하게 노드와 토픽 상태를 확인할 때, “ros2 topic list”나 “ros2 node list” 등을 도메인마다 셸에서 실행해볼 수 있다(환경 변수 $ROS_DOMAIN_ID$를 달리 설정).
Last updated