# 실제 사례: 로컬 네트워크와 클라우드 통신

ROS2 Humble 기반의 멀티머신 환경을 구성할 때, 로컬 네트워크(사내망 등)와 외부 클라우드(공공 클라우드 서비스 등)를 함께 연결해야 하는 사례가 종종 발생한다. 예를 들어, 로컬 로봇 환경에서는 고속의 센서 데이터 처리가 필요하고, 클라우드 서버에서는 장기 저장 및 머신러닝 분석을 담당한다면, 두 환경 간 데이터를 실시간 혹은 준실시간으로 주고받아야 한다. 이때 고려해야 할 사항은 다음과 같다:

1. **네트워크 주소 체계**: 로컬 IP 대역과 공인 IP 대역, 또는 내부 사설망과 VPN/터널링 등.
2. **방화벽 설정**: 외부 포트를 어떻게 열어둘지, 프로토콜과 포트 번호를 어떻게 할당할지.
3. **ROS2 DDS 설정**: RTPS(Real-Time Publish-Subscribe)가 사용하는 포트 범위 제어와 QoS.
4. **보안**: 암호화 통신, 접근 제어, 인증/인가 방식.
5. **데이터 전송 지연**: 로컬과 클라우드 간의 네트워크 특성을 고려한 QoS 옵션 선택.

#### 네트워크 구조 설계

로컬 네트워크와 클라우드가 연결되는 멀티머신 환경의 핵심은 **복수의 서브넷(subnet)을 하나의 ROS2 네트워크로 연결**하는 것이다. 로컬과 클라우드를 연결할 때는 다음과 같은 구조적 이슈가 있다.

1. 로컬 네트워크(예: 192.168.x.x 대역) 내부에서의 멀티머신 통신
2. 인터넷을 경유하는 트래픽(공인 IP 할당 또는 NAT 변환)
3. 클라우드 서비스(VPC, VPN, 프라이빗 서브넷 등) 내부의 ROS2 멀티머신 구성

일반적으로 로컬 머신과 클라우드 머신 각각의 서브넷에서 ROS2 멀티캐스트를 사용할 경우, 멀티캐스트가 라우터를 통해 외부로 전송되지 않도록 기본적으로 차단되어 있는지 확인해야 한다. 따라서 ROS2 DDS의 discovery(노드 간 탐색) 과정을 다중 서브넷 환경에서 어떻게 활성화할 수 있는지가 중요하다.

#### DDS Discovery Relay 혹은 Shared Memory + 브리지 서버

ROS2에서 다중 서브넷 혹은 분산 환경에서 노드를 서로 인식시키기 위해선 여러 가지 기법이 있다. 대표적으로 다음과 같은 방식이 고려된다.

1. **Discovery Server 기능 활용**: 일부 DDS 구현에서 제공하는 Discovery Server(Discovery Relay라고도 함)를 사용해 중간 서버가 노드 목록을 중앙에서 관리하고 분배한다.
2. ROS2 브리지 서버 사용

   : 로컬 네트워크 내 ROS2와, 외부 클라우드 네트워크 내 ROS2 시스템을

   bridge 노드

   를 통해 연결한다.

   * 예: 로컬 ROS2 메시지를 브리지 노드가 수신 → 브리지 노드가 외부 클라우드의 토픽으로 재게시(republish) → 역방향 경로도 동일한 방식으로 진행.

#### NAT와 포트 포워딩

클라우드 환경의 서버가 공인 IP를 보유한다 하더라도, 보안 그룹(Security Group)이나 방화벽 규칙에 의해 특정 포트가 제한되기 마련이다. 로컬 네트워크 쪽도 게이트웨이(공유기)나 방화벽이 NAT로 IP를 매핑해줄 때, ROS2 통신에 필요한 포트를 열어줘야 한다. ROS2 DDS가 사용하는 포트는 기본적으로 UDP 7400\~7600 대역(또는 DDS 구현마다 다름)을 포함해 동적으로 열리는 포트가 많으므로, 다음과 같은 조정이 필요할 수 있다.

* DDS 구현별로 포트 범위를 고정하거나 축소
* 방화벽 규칙에 따라 Inbound/Outbound 포트 허용
* NAT 포트 포워딩 규칙 적용

#### 예시: Fast DDS 포트 설정

가령 Fast DDS(에Prosima Fast DDS) 사용 시, 기본 포트 할당 방식을 변경하기 위해서는 XML 설정 파일 혹은 C++ API로 파라미터를 조정할 수 있다. XML 예시를 일부 살펴보면 아래와 유사한 설정을 할 수 있다. (이는 단순 예시일 뿐, 실제로 적용할 때는 Fast DDS 공식 문서를 참고해야 한다.)

```xml
<transport_descriptors>
  <transport_descriptor>
    <kind>UDPv4</kind>
    <sendBufferSize>65507</sendBufferSize>
    <receiveBufferSize>65507</receiveBufferSize>
    <interfaceWhiteList>
      <address>192.168.1.10</address>
    </interfaceWhiteList>
    <!-- 포트 범위 등 추가 설정 -->
  </transport_descriptor>
</transport_descriptors>
```

이렇게 포트를 고정하거나 특정 범위로 제한해야 방화벽이나 NAT에서 예측 가능한 구성을 할 수 있다.

#### SSH 터널링을 활용한 방법

만약 클라우드 서버와 로컬 시스템 간 직접 포트 오픈이 어렵다면, SSH 터널링을 통해 ROS2 통신을 우회하는 방법도 시도할 수 있다. 예를 들어, 로컬 네트워크 내 특정 머신에서 클라우드 서버로 SSH 접속을 열고, 포트 포워딩을 이용해 DDS 소켓에 대한 트래픽을 터널링한다. 일반적인 SSH 포트 포워딩 예시는 다음과 같다:

```bash
# 로컬 포트 8888을 클라우드 서버의 7400에 바인딩
ssh -L 8888:localhost:7400 user@cloud-host
```

이러한 방식을 확장해 ROS2가 사용하는 여러 포트를 SSH 터널로 연결하면, 별도의 복잡한 NAT나 방화벽 규칙 없이도 테스트 가능할 수 있다. 다만, 대규모 트래픽 전송 시 SSH 터널링 부하가 커질 수 있으므로 주의가 필요하다.

#### QoS 설정 및 지연시간 분석

로컬 네트워크와 클라우드 간 물리적 거리 및 네트워크 품질에 따라 지연(latency), 패킷 손실, 대역폭 등이 달라진다. ROS2 QoS(특히 Reliability, Durability, Deadline, Liveliness 등)를 적절히 설정해야 데이터 손실이나 불필요한 재전송을 막고 안정적으로 통신할 수 있다.

* **Reliability**: Reliable vs Best Effort 클라우드 환경에서 패킷 손실률이 높은 경우 Best Effort로 두면 높은 처리량을 기대할 수 있으나, 데이터 무결성은 희생될 수 있다.
* **History**: Keep Last vs Keep All 통신 지연이 길어지는 경우, 메시지 버퍼 사용량이 중요해진다.
* **Deadline**: 노드 간 신호가 일정 시간 내에 도달해야 하는 경우 지정한다.

실제 지연시간 측정을 위해서는 $\mathbf{T}*{\text{latency}} = t\*{\text{cloud}} - t*{\text{local}}$ 과 같이 측정 시점을 기록한 후, 통계적으로 평균 지연, 분산, 최대 지연 등을 분석한다.

#### 예시 네트워크 구조도

로컬 네트워크와 클라우드 환경에서 ROS2 노드들이 어떻게 연결될 수 있는지, 단순화된 구조 예시를 아래 다이어그램으로 보여줄 수 있다.

{% @mermaid/diagram content="graph LR
subgraph Local Network
A\[ROS2 Node A]
B\[ROS2 Node B]
end
subgraph Bridge Server
M\[Bridge Node/Server]
end
subgraph Cloud
C\[ROS2 Node C]
D\[DB/ML Service]
end

```
A -- DDS/RTPS --> B
B -- TCP/UDP --> M
M -- TCP/UDP --> C
C -- DDS/RTPS --> D" %}
```

* **Local Network**: 로봇이나 센서 등 실제 장비가 존재하는 내부망. Node A, Node B가 서로 실시간 센서 데이터를 송수신한다.
* **Bridge Server**: 로컬 네트워크와 클라우드 네트워크 간 통신을 담당하는 브리지. VPN 혹은 SSH 터널링, DDS Discovery Server 등을 활용해 양쪽 세계를 이어준다.
* **Cloud**: 공인 IP나 사설망(VPC) 등을 통해 서비스되는 클라우드 리소스. Node C, DB/ML 서비스 등이 포함되어, 대규모 데이터 분석이나 장기 보관이 이루어진다.

이 예시는 단순화된 형태이며, 실제 환경에서는 방화벽이나 로드 밸런서, NAT 게이트웨이 등이 추가로 고려된다.

#### VPN 구성과 ROS2

로컬 네트워크와 클라우드를 안전하게 연결하기 위해서는 VPN(Virtual Private Network)을 구성하는 방법이 가장 전형적이다. 예를 들어 AWS VPC Peering, Azure VPN Gateway, OpenVPN, WireGuard 등 다양한 방식으로 원격지 네트워크를 단일 서브넷처럼 묶을 수 있다. 이때 VPN이 구성되면, ROS2 DDS는 멀티캐스트나 유니캐스트를 모두 VPN 터널을 통해 전달할 수 있으며, 추가적인 방화벽 규칙은 VPN 내부 통신에 대해 좀 더 자유롭게 적용 가능해진다.

* **OpenVPN 예시**: 로컬 머신 혹은 로컬 게이트웨이에서 OpenVPN 클라이언트를 실행하고, 클라우드 쪽에 OpenVPN 서버를 둔다.
* **WireGuard 예시**: 로컬과 클라우드 서버 각각 WireGuard 인터페이스를 설정하고, 암호화된 터널을 통해 ROS2 노드가 상호 통신한다.

#### Discovery Server 구성

멀티머신 ROS2에서 DDS Discovery Server(또는 Discovery Relay)를 중앙 집중형으로 구성하면, 라우터를 통해 브로드캐스트나 멀티캐스트가 제한되어 있더라도 노드 간 발견이 가능해진다. Fast DDS, Cyclone DDS 등 여러 DDS 벤더들이 Discovery Server 기능을 지원한다.

* **중앙 서버**: Discovery Server가 동작하는 머신. 모든 노드가 해당 서버에 접속해 자신의 존재를 알린다.
* **노드 측 설정**: 각 노드가 DDS Discovery Server의 IP와 포트를 설정 파일이나 ROS2 파라미터로 지정해, 멀티캐스트 대신 Discovery Server를 통해 노드 목록을 수신한다.

이를 활용하면 로컬 네트워크 내부 노드와 클라우드에 있는 노드 모두 Discovery Server만 접근 가능한 상태가 되어도 서로 간 노드 정보를 전달받을 수 있다.

#### 보안/인증 및 암호화 통신

로컬과 클라우드를 연결하는 멀티머신 환경에서는 보안이 매우 중요한 요소다. 데이터 도청, 변조, 무단 침입 등을 방지하기 위해 다음과 같은 방식을 고려할 수 있다.

1. **TLS/DTLS**: DDS 자체에서 DTLS를 지원하는 벤더도 있고, TLS 터널이나 DTLS를 통해 메시지를 암호화할 수 있다.
2. **VPN**: 앞서 언급한 VPN 내에서만 ROS2 통신이 이뤄지도록 하여, 암호화된 링크 위에서 DDS가 작동한다.
3. **SROS2**: ROS2용 보안 확장(Secure ROS2, SROS2)을 통해 노드 간 통신 시, DDS Security 플러그인을 활용해 인증/인가, 암호화, 메시지 무결성을 보장한다.

**SROS2 예시**

SROS2는 DDS Security 표준을 준수하는 플러그인(예: Fast DDS Security)과 협력해, **PKI 기반 인증서**와 **액세스 제어 정책**을 구성한다. 주요 개념은 다음과 같다.

* **키(Key), 인증서(Certificate)**: 각 노드는 본인 식별을 위한 키-인증서 세트를 갖는다.
* **Governance 파일**: 어떤 Topic, Service, Action에 대해 어떤 보안 정책을 적용할지 정의한다.
* **Permissions 파일**: 각 노드가 어떤 Topic을 게시/구독할 권한이 있는지 결정한다.

이 과정을 설정해두면, 로컬 노드든 클라우드 노드든 서로 인증을 거친 뒤에만 ROS2 메시지를 교환할 수 있게 된다.

#### Docker 컨테이너 활용

로컬과 클라우드 환경이 서로 다른 운영체제를 사용하거나, 의존성 설정이 복잡할 때는 **Docker 컨테이너**로 ROS2 환경을 패키징하는 것이 유리하다. 컨테이너 내부에서 DDS 포트와 설정을 통일성 있게 관리하고, 로컬-클라우드 간 배포 시에도 일관된 이미지를 사용할 수 있다.

* **docker-compose**: 멀티 컨테이너 서비스를 구성할 때, 로컬과 클라우드에서 동일한 Docker Compose 설정 파일을 사용해 배포 전략을 재현 가능하게 만든다.
* **Kubernetes**: 클라우드 환경에서 ROS2 작업 노드를 자동으로 스케일링하거나 관리해야 한다면, Kubernetes 상에서 ROS2 클러스터를 운영할 수도 있다. 이 경우, DDS 네트워킹(포트, 멀티캐스트, 서비스 디스커버리 등)이 Kubernetes의 Pod 네트워크 정책과 잘 호환되는지 검토가 필요하다.

#### 모니터링 및 로깅

로컬과 클라우드 간 트래픽이 정상적으로 송수신되고 있는지를 알기 위해서는 **시스템 모니터링**이 필수다.

1. **ROS2 기본 로깅**: ros2 run, ros2 launch 등으로 노드를 구동할 때 콘솔 로그를 확인한다.
2. **rqt\_graph / rqt\_topic**: 노드/토픽 그래프를 시각화해 정상적으로 연결되어 있는지 확인한다.
3. **네트워크 모니터링**: netstat, iftop, iperf 등으로 네트워크 트래픽 양과 지연, 손실을 측정한다.
4. **클라우드 모니터링**: AWS, Azure, GCP에서 제공하는 CloudWatch, Azure Monitor, Stackdriver 등을 통해 VM/컨테이너 리소스 사용량과 네트워크 상태를 확인한다.

#### 대규모 분산 환경에서의 고려 사항

로컬-클라우드 멀티머신 환경에서 노드 수가 수십, 수백 개로 늘어날 경우, DDS의 브로드캐스트/멀티캐스트 탐색을 그대로 사용하기에는 부하가 매우 커질 수 있다. 또한, 보안/방화벽 규칙이 복잡해질 가능성도 높다. 따라서 다음과 같은 방안을 함께 고민해야 한다.

* **DDS Discovery Server/Relay**: 중앙 집중형 노드 탐색으로 네트워크 부하와 설정 복잡도를 줄인다.
* **교차 인증**: 서로 다른 서브넷 혹은 조직에서 운영하는 노드가 함께 통신할 경우, 보안 정책과 인증 절차(예: SROS2 PKI)가 일관되도록 설계한다.
* **Cloud Edge 서비스**: 클라우드 사업자에서 제공하는 로컬 게이트웨이나 엣지 컴퓨팅 인프라를 활용해, 지연을 줄이고 데이터 전송 비용을 절감한다.