# 멀티머신 통신 시 필수 고려사항

#### 네트워크 구성 확인

ROS2 멀티머신 환경을 구성할 때 가장 먼저 고려해야 할 요소는 네트워크의 물리적, 논리적 구성이다. 기본적으로는 서로 다른 물리적 장비(PC, 임베디드 보드 등)가 같은 서브넷(Subnet) 안에 있어야 하며, 통신할 IP 대역이 일관성 있게 설정되어야 한다.

* **IP 주소 및 서브넷 마스크**: 멀티머신 환경에서 각 장비가 서로 다른 IP 주소를 사용하도록 하고, 서브넷 마스크가 서로 호환되는지 반드시 확인한다.
* **브로드캐스트/멀티캐스트 트래픽**: ROS2는 DDS의 Discovery 메커니즘을 활용해 노드를 자동 검색한다. 이때 브로드캐스트나 멀티캐스트 패킷 사용이 불가능한 네트워크 구성(예: 방화벽, VLAN, VPN 설정 등)에서는 노드를 찾지 못하거나 Discovery가 지연될 수 있다.
* **게이트웨이 및 라우팅**: 서로 다른 라우터나 게이트웨이를 거치는 경우, UDP 멀티캐스트 트래픽이 차단될 가능성이 높다. 따라서 이런 환경에서는 Discovery Server, Peer-to-Peer Manual Discovery, 혹은 RTPS Relaying 등의 대안을 모색한다.

#### ROS\_DOMAIN\_ID 설정

ROS2 멀티머신 통신에서 충돌을 막고 논리적으로 독립된 네트워크를 구성하기 위해 자주 사용하는 방법이 `ROS_DOMAIN_ID` 설정이다.

* **기본 원리**: `ROS_DOMAIN_ID` 값이 같은 노드들끼리는 DDS Discovery를 통해 서로를 인식할 수 있고, 값이 다르면 서로를 인식하지 못한다.
* **활용 사례**: 하나의 물리적 네트워크에서 다수의 ROS2 시스템을 독립적으로 운영해야 할 때, `ROS_DOMAIN_ID`를 다르게 부여한다.
* **환경 변수 설정**: 셸에서 다음과 같이 설정할 수 있다.

```bash
export ROS_DOMAIN_ID=10
```

#### DDS QoS 정책

ROS2 통신은 DDS(데이터 분산 서비스) 프로토콜을 기반으로 한다. DDS QoS(Quality of Service)를 적절히 설정해야 원활한 멀티머신 통신이 이루어진다.

* **Reliability(신뢰성)**: Reliability QoS는 ‘Reliable’ 혹은 ‘Best Effort’로 구성할 수 있다. 중요한 제어 신호라면 ‘Reliable’을 사용하지만, 대역폭이 높은 카메라 이미지 스트림 같은 경우는 ‘Best Effort’가 오히려 지연을 낮출 수 있다.
* **Durability(내구성)**: Durability QoS는 메시지를 한쪽에서 늦게 구독을 시작해도 이전 데이터를 받을 수 있도록 해주지만, 네트워크 트래픽이 증가할 수 있다. 환경에 따라 적정 수준을 설정해야 한다.
* **Deadline**: Deadline QoS는 특정 주기 내에 반드시 메시지를 전송해야 하는 경우 사용하는 정책이다. 로봇 시스템에서는 제어 주기 안에 데이터를 수신하지 못하면 안전 문제가 생길 수 있으므로, Deadline 설정이 중요한 경우가 많다.

#### Discovery 지연 및 트래픽 평가

DDS Discovery가 제대로 이루어지지 않거나 오래 걸린다면, 노드 간 통신 자체가 끊기거나 초기화가 불완전해질 수 있다. 네트워크 지연(latency)에 대한 기본적 분석을 할 때 노드 $i$와 노드 $j$ 사이의 네트워크 지연을 $d\_{ij}$라 할 때, 이를 추산하는 단순 모델은 다음처럼 표현할 수 있다.

$$
d\_{ij} = \alpha \cdot \Delta\_{ij} + \beta
$$

여기서 $\Delta\_{ij}$는 물리 거리 혹은 링크 상태에 따른 기본 지연 요소, $\alpha$와 $\beta$는 네트워크 환경(라우팅, QoS 설정 등)에 따라 달라지는 상수다. 이 지연이 커지면 Discovery가 제때 이루어지지 않을 수도 있으므로, DDS 설정(HeartBeat, Lease Duration 등)을 적절히 조정해야 한다.

#### 시간 동기화(Time Synchronization)

ROS2 멀티머신 환경에서 시간 동기화는 필수다. 노드 간의 메시지 타임스탬프가 일치하지 않으면, 센서 데이터나 제어 명령이 뒤죽박죽 정렬되어 의미 있는 로봇 제어를 어렵게 만든다.

* **NTP 사용**: 가장 일반적인 방법은 NTP(Network Time Protocol) 서버를 두고 모든 머신이 동기화하도록 설정하는 것이다.
* **Chrony 등 대안 사용**: 로컬 네트워크 환경에서 짧은 지연과 높은 정확도가 필요하다면 Chrony, PTP(Precision Time Protocol) 등을 고려할 수 있다.
* **ROS2 내장 Clock 사용 시 주의**: ROS2 노드가 시스템 시간을 그대로 쓰는 경우가 많으므로, 시스템 시간이 불규칙하다면 토픽 메시지의 타임스탬프가 잘못 표기될 수 있다.

#### 보안 및 방화벽 설정

멀티머신 환경에서 네트워크 보안을 유지하려면 방화벽이나 VPN을 사용하는 경우가 많다. 하지만 ROS2의 Discovery 메커니즘이 이러한 설정에 막히는 경우 통신이 끊길 수 있다.

* **UDP 포트 열기**: 기본적으로 ROS2 DDS 통신은 UDP를 사용하므로, 필요한 포트를 방화벽에서 허용해야 한다. 각 DDS 구현마다(예: Fast DDS, Cyclone DDS, RTI Connext) 포트 범위가 다를 수 있으니 문서를 확인한다.
* **VPN 구간**: VPN 구간에서는 멀티캐스트 트래픽이 차단되기도 한다. 이때 Discovery Server 또는 수동 Discovery 설정을 사용하는 편이 안전하다.
* **Security Plugin**: RTI Connext나 Fast DDS 보안 플러그인을 사용하면 DDS 통신을 암호화하거나 인증할 수 있다. 시스템 요구사항에 맞게 구성한다.

#### Discovery Server, Peer-to-Peer 설정

멀티머신 네트워크가 복잡해지거나, 브로드캐스트/멀티캐스트가 차단된 환경이라면 Discovery Server 같은 외부 서비스를 통해 노드 정보를 공유할 수 있다.

* **Discovery Server**: 중앙 집중형 서버를 통해 노드 정보를 교환하므로, 동적 IP나 제한된 네트워크에서도 Discovery가 가능하다.
* **Peer-to-Peer Manual Discovery**: 노드들이 서로의 IP를 직접 알고 있는 경우, `ROS_MASTER_URI`를 세팅하던 ROS1 방식과 유사하게 각 노드의 주소를 수동으로 등록해 바로 연결할 수 있다.
* **RTPS Relay**: RTPS(Packet) 레벨에서 중계(리레이)해주는 소프트웨어 솔루션도 존재한다. 네트워크 트래픽을 중앙에서 제어하거나, 방화벽을 우회하고자 할 때 사용하는 방법이다.

#### 자원 사용량 고려

멀티머신 환경에서 카메라, LiDAR 등 대용량 데이터를 송수신하면 CPU나 메모리, 네트워크 대역폭을 많이 소모한다.

* **CPU 부하 측정**: 주기적으로 ‘top’, ‘htop’, 혹은 ROS2 내장 통계 도구 등을 통해 각 노드 CPU 사용량을 확인한다.
* **메모리 사용량 관리**: 실시간으로 이미지, 포인트 클라우드 같은 대규모 데이터를 송수신하면 메시지 버퍼가 커질 수 있으므로, QoS 설정에서 히스토리(History)나 큐 사이즈를 조절한다.
* **네트워크 대역폭**: 여러 로봇이 동시에 대규모 데이터를 퍼블리시할 때는 스위치나 라우터의 대역폭이 포화되지 않는지 확인해야 한다. 필요하다면 VLAN 분리나 네트워크 증설을 검토한다.

#### RMW 구현체 선택

ROS2 멀티머신 환경에서는 동일한 RMW(Robot Middleware) 구현체를 사용하는 것이 유리하다. RMW가 다르면 DDS Discovery와 QoS 적용이 완전히 호환되지 않을 수 있다.

* **예시**: Fast DDS, Cyclone DDS, RTI Connext 등.
* **성능 차이**: 메시지 전송 지연, 브로드캐스트 범위, 보안 플러그인 지원 여부 등이 구현체마다 다르므로, 멀티머신 통신 특성에 적합한 구현체를 선택하는 것이 중요하다.
* **호환성 문제**: 서로 다른 RMW를 사용하는 노드 간에도 통신이 가능한 경우가 있지만, QoS 정책이나 보안 설정에 따라 제약이 생길 수 있다.

#### ROS2 Launch 파일 구성

멀티머신 환경에서 여러 노드를 동시에 실행하려면 Launch 파일을 신중히 구성해야 한다.

* **멀티 노드 실행**: 로컬 머신에서 여러 노드를 실행하는 것 외에도, 원격 머신의 노드를 SSH 명령어로 제어할 수 있다. Launch 파일에서 별도의 로직을 넣어 분산 실행을 지원하도록 스크립팅할 수 있다.
* **환경 변수 전달**: Launch 파일 내에서 `ROS_DOMAIN_ID`나 DDS 관련 설정을 적용하려면, ‘environments’ 섹션에 환경 변수 설정을 추가하거나, 별도 스크립트를 호출하여 실행한다.

#### 모니터링 및 디버깅

네트워크 지연이나 DDS Discovery 실패 같은 문제가 자주 발생할 수 있으므로, 모니터링과 디버깅 툴을 익숙하게 다루어야 한다.

ROS2 CLI:

```bash
ros2 node list
ros2 topic list
ros2 topic echo /some_topic
```

등을 활용해 해당 노드 혹은 토픽이 정상적으로 보이는지 확인한다.

**DDS 레벨 로깅**: DDS 구현체마다 제공하는 로깅 옵션을 활성화하면 Discovery, QoS 협상 과정에서 발생하는 메시지를 확인할 수 있다.

**Wireshark 분석**: 마지막으로는 `Wireshark` 등의 패킷 스니퍼 도구를 통해 멀티캐스트 패킷이 실제 네트워크를 타고 다니는지, 특정 포트가 막히는지 직접 확인할 수 있다.

#### Docker/가상환경에서의 멀티머신 통신

Docker 컨테이너나 가상머신으로 ROS2 노드를 실행할 때 네트워크 설정이 달라질 수 있다.

**Bridge 네트워크**: Docker 컨테이너 기본 설정이 NAT 기반이므로, 멀티캐스트 패킷이 제대로 전달되지 않는 경우가 있다. ‘host’ 네트워크 모드를 사용하거나, 별도 브리지 네트워크를 구성해 다리를 만들어야 한다.

**가상머신(VM)**: VM 환경에서는 호스트와 VM 간 브리지 설정이 필요하다. 가상 네트워크 어댑터가 멀티캐스트를 지원하는지, 방화벽 설정이 있는지 확인한다.

#### 실시간성(Real-Time) 고려

물리 로봇 시스템에서 분산 제어를 하는 경우에는 실시간 처리 요구사항이 중요하다.

**RT 커널 사용**: 리눅스 RT(Real-Time) 커널을 사용하면 스케줄링 지연을 낮출 수 있다.

**RTDDS, Micro-ROS**: 초저지연을 위한 실시간 DDS 구현체 혹은 Micro-ROS로 임베디드 장치와 통신할 때, 실시간성 보장을 위한 추가 설정이 필요하다.

**QoS 설정 재점검**: Reliability, Deadline, Liveliness QoS가 엄격하게 요구될 경우, 네트워크 지연이 매우 작은 환경(예: 단일 스위치)으로 제한하거나, 별도의 시간 동기화 및 로우 레벨 최적화가 필요하다.