멀티머신 디버깅 및 모니터링 툴
개요
멀티머신 환경에서 ROS2 노드를 디버깅하고 모니터링하는 일은 단일 머신에서의 디버깅보다 훨씬 복잡하다. 네트워크 지연, 메시지 손실, 서로 다른 머신에서 발생하는 로깅 정보의 시점 차이 등을 고려해야 하기 때문이다. 또한 머신 간 상호 작용이 예측과 다르게 동작할 때, 그 원인을 찾기 위해서는 다양한 수준(ROS2 내부 구조, 네트워크 계층, CPU 및 메모리 사용량 등)에서 관찰이 필요하다.
따라서 ROS2 멀티머신 디버깅에는 여러 가지 툴을 활용하여 시스템을 다각도로 모니터링하고 문제를 진단할 수 있어야 한다. 이 장에서는 대표적으로 많이 활용되는 툴들을 심층적으로 다루고, 각 툴의 쓰임새 및 장단점을 살펴본다.
rqt 툴 모음
ROS1 시대부터 친숙하게 사용되었던 rqt는 ROS2에서도 여전히 유용하다. rqt에는 여러 가지 플러그인이 존재하며, 멀티머신 환경에서도 동일한 방식으로 노드, 토픽, 서비스, 파라미터를 모니터링할 수 있다. 다만, DDS 통신 환경에서 QoS 설정 등에 따라 rqt가 멀티머신의 특정 노드나 토픽을 제대로 인식하지 못할 수도 있으므로, QoS 설정을 사전에 통일하거나 의도적으로 차이를 두었을 때에는 플러그인별로 동작을 점검해야 한다.
ros2 CLI(명령줄 인터페이스)
멀티머신 환경에서 가장 먼저 확인해야 할 사항 중 하나는 “원격 노드가 보이는가?”이다. 예컨대, 로컬 머신에서 아래와 같은 명령어를 통해 노드 목록을 확인할 수 있다.
ros2 node list만약 원격 머신에서 실행되고 있는 노드가 전혀 보이지 않는다면, 네트워크 문제 혹은 DDS 설정 문제를 의심해봐야 한다. 반대로 특정 노드는 보이지만 토픽이 안 보이거나, 서비스가 호출되지 않는다면 QoS 관련 문제가 있을 수 있다. 아래는 서비스 목록을 확인하는 예시이다.
ros2 service list이러한 CLI 도구들은 불필요한 GUI 로딩 없이 빠르게 상태를 파악할 수 있다는 점에서 장점이 있다. 또한 SSH를 통해 원격 머신에 접속해서 실행할 수도 있어, 멀티머신 환경에서 매우 유용하다.
ros2 topic/echo
멀티머신의 토픽 통신 상태를 확인하기 위해서는 주로 다음과 같은 명령어를 사용한다.
ros2 topic list
ros2 topic echo /some_topicros2 topic echo /some_topic은 해당 토픽의 메시지를 실시간으로 출력해주므로, 멀티머신 간 통신이 정상적으로 이루어지고 있는지, 메시지 타입이 올바른지, 또는 데이터의 형식이 의도대로 전송되고 있는지를 빠르게 체크할 수 있다. 다만 메시지 양이 방대할 경우에는, echo 작업 자체가 실시간 통신에 부담을 줄 수 있으므로 주의해야 한다.
ros2 param
각 노드에서 파라미터를 활용하고 있다면, 다음과 같은 명령어를 통해 노드의 파라미터 상태를 확인할 수 있다.
멀티머신 환경에서 파라미터가 일관되게 설정되지 않았다면, 동일 노드라 하더라도 머신에 따라 동작이 다르게 나타날 수 있다. 예컨대, 센서 주기가 10Hz로 설정된 노드와 20Hz로 설정된 노드가 동시에 존재한다면 서로 다른 타이밍으로 메시지를 발행/수신하게 되어, 의도치 않은 간헐적 지연이 발생할 수도 있다. 따라서 파라미터 상태를 주기적으로 확인하고 일관성을 유지하는 것이 중요하다.
ros2 lifecycle
ROS2의 라이프사이클 노드(lifecycle node) 기능을 사용할 경우, 특정 노드의 상태(UNCONFIGURED, INACTIVE, ACTIVE, FINALIZED 등)를 모니터링하고 제어할 필요가 있다. 이를 위해 아래와 같은 명령어를 사용할 수 있다.
멀티머신 환경에서 여러 라이프사이클 노드가 있을 때, 이들이 어떻게 상태 전이를 하는지 모니터링함으로써, 어떤 노드에서 문제가 생겼는지 빠르게 파악할 수 있다. 특히 한 노드가 ACTIVE 상태에 진입하지 못해 전체 시스템이 지연되는 경우가 많으므로, 상태 전이를 제대로 따라가는지 꼼꼼히 점검해야 한다.
메시지 기록 및 재생 (ros2 bag)
멀티머신 통신에서 가장 대표적인 모니터링 기법 중 하나는 메시지를 기록하고(recode) 재생하여(replay) 문제 상황을 재현하는 것이다. 로컬 머신에서만 ros2 bag을 실행할 수 있는 것이 아니라, 원격 머신에서도 동일하게 가능하다. 예를 들어, 서로 다른 머신에서 동시에 ros2 bag을 수행한다면 시간차가 있는 서로 다른 로그를 얻을 수 있으며, 이를 종합해서 문제를 추적할 수도 있다.
특히 멀티머신 환경에서는 데이터가 정상적으로 흘러갔는지, 메시지 손실이 있었는지 등을 확인하기 위해 두 머신에서 기록된 ros2 bag 파일을 비교 분석하기도 한다. 이때 시계열 정보를 기준으로 로그를 정렬하고, 특정 시점에 어떤 메시지가 누락되었는지 상세하게 살피면 유용하다.
네트워크 모니터링 툴
멀티머신 환경에서 가장 빈번하게 발생하는 문제 중 하나는 네트워크 지연, 패킷 손실, 혹은 QoS mismatch 등으로 인해 의도한 메시지가 제때 전달되지 않는 현상이다. 이러한 문제를 빠르게 파악하기 위해서는 네트워크 상태를 모니터링하거나 특정 시점의 패킷 흐름을 캡처하여 분석하는 과정이 필요하다.
ping: 간단하면서도 가장 빠르게 네트워크 연결성을 확인할 수 있는 유틸리티다. 다음과 같은 명령어로 특정 IP나 호스트명에 대해 연결 상태 및 지연 시간을 확인할 수 있다.
만약 패킷 손실이 발생하거나 지연 시간이 급격히 증가한다면, 네트워크 트래픽이 과도하거나 QoS 설정에 따라 UDP 통신이 제대로 되지 않을 가능성을 고려해야 한다.
netstat, ss: 로컬 시스템에서 열려 있는 소켓 상태나 연결 상태, 포트 등을 확인할 수 있다. 예를 들어 ROS2 노드가 특정 포트를 통해 통신 중인지, 또는 예상치 못한 포트에 의해 충돌이 발생하고 있는지 등을 살펴볼 수 있다. Linux 환경에서는 아래와 같이 사용한다.
이 명령을 통해 TCP/UDP 연결 목록과 바인딩된 프로세스 정보를 확인할 수 있다.
iperf: 네트워크 대역폭과 전송 속도를 계량하고, TCP/UDP 성능 테스트를 할 때 유용한 툴이다. 머신 간 대역폭이 ROS2 통신을 수행하기에 충분한지, 혹은 DDS 통신에 영향을 미칠 만큼 포화 상태는 아닌지 등을 확인하는 용도로 사용한다. 기본적으로 한쪽 머신을 서버 모드로, 다른 쪽 머신을 클라이언트 모드로 실행한다.
이렇게 하면 두 머신 간 최대 전송속도, 지연 시간, 패킷 재전송 여부 등의 정보를 얻을 수 있다.
Wireshark: 네트워크 패킷을 캡처하고 분석할 수 있는 강력한 도구다. DDS 통신을 비롯한 UDP/TCP 트래픽의 내용을 패킷 단위로 확인할 수 있어, 특정 시점에 어떤 메시지가 전송 혹은 수신되었는지 살펴볼 수 있다.
ROS2에서는 DDS의 다양한 구현체에 따라 포트와 트래픽 형식이 달라질 수 있으므로, 패킷 필터나 디코더 설정을 적절히 해주어야 한다. 예를 들어, FastDDS나 RTI Connext 같은 특정 DDS 구현체에서는 전용 Wireshark 디섹터(plugin)를 제공하기도 한다.
DDS 전용 모니터링 툴
ROS2에서의 통신 계층은 DDS(Datat Distribution Service)이다. DDS 벤더별로 전용 모니터링 및 관리 툴을 제공하며, 이를 통해 실제 노드와 토픽 목록, QoS 설정, RTPS(Reliable Transport Protocol for sensor) 세부 사항 등을 자세히 확인할 수 있다.
RTI Admin Console (RTI Connext): RTI Connext DDS를 사용하는 경우, RTI Admin Console을 통해 DDS 도메인, 파티션, 토픽, QoS 설정 등을 그래픽 인터페이스로 한눈에 볼 수 있다. 단, 라이선스에 따라 설치가 제한될 수 있으므로 상황에 맞게 사용 여부를 결정해야 한다.
Fast DDS Monitor (eProsima Fast DDS): eProsima Fast DDS를 사용하는 환경이라면, Fast DDS Monitor를 이용하여 토픽과 파티션, 노드 상태 등을 실시간 모니터링할 수 있다. 관리자 권한으로 실행해야 하는 경우도 있으므로, 설치 및 설정 단계에서 유의한다.
Cyclone DDS 툴: Eclipse Cyclone DDS를 사용할 때에는, 명령줄 기반 툴이나 Eclipse Foundation 측에서 제공하는 일부 시각화 툴을 활용할 수 있다. 다만 다른 상용 DDS만큼 UI가 정교하지 않을 수 있으니, Wireshark와 병행하여 사용하는 경우가 많다.
시스템 리소스 모니터링
ROS2 멀티머신 환경에서 CPU나 메모리가 과도하게 사용되는 경우, 노드가 느려지거나 패킷 전송이 지연되는 문제가 발생할 수 있다. 이를 방지하기 위해서는 각 머신에서의 시스템 리소스 사용 상태를 모니터링할 필요가 있다.
top, htop: CPU 및 메모리 사용량, 스레드, 프로세스 정보를 실시간으로 확인할 수 있는 툴이다. 멀티코어 환경에서 특정 코어만 과부하되는 경우, ROS2 노드가 예상치 못한 스케줄링 지연을 겪을 수 있다. 또한 메모리 부족이 발생해 스왑(swap)이 잦아지면, 통신에 필요한 버퍼 할당이 늦어져 QoS 보장에 문제가 생길 수도 있다.
free, vmstat: 메모리와 스왑 사용량 등을 좀 더 세밀하게 파악할 때 사용한다. 한 머신에서 ROS2 노드가 메모리 누수를 일으킨다면, 다른 머신과의 통신이 정상이라 해도 결국 해당 노드의 성능이 떨어져 전체 시스템 동작에 영향을 줄 수 있다.
nvidia-smi: GPU 리소스를 사용하는 노드가 있을 경우(예: SLAM, 딥러닝 노드), nvidia-smi 명령어를 통해 GPU 메모리 사용량, GPU 사용률 등을 확인할 수 있다. GPU가 과부하되면 이미지 프로세싱 주기가 늘어나거나, 메시지 발행이 지연될 가능성이 높다.
분산 로깅(Logging) 및 집계(Aggregation) 툴
멀티머신 환경에서는 여러 머신에서 생성되는 로그를 한곳에서 종합해 분석할 수 있어야 한다. 각 머신에 접속해 로그 파일을 개별적으로 살펴보는 방법은 노드가 많을수록 비효율적이며, 실시간 문제 파악이 어려워진다. 따라서 중앙 집중형 로깅 시스템이나 로그 집계 툴을 통해 모든 머신의 로그를 한눈에 모니터링하는 방식을 많이 사용한다.
rsyslog, syslog-ng: 전통적으로 Linux 환경에서 자주 사용되는 시스템 로그 데몬이다. 여러 머신에서 발생하는 로그를 중앙 서버로 전송하고, 시간 순서에 따라 저장하거나 필터링하여 저장하는 기능을 제공한다. ROS2 노드 로그 역시 텍스트 형식으로 파일에 남긴다면 이와 같은 syslog 시스템으로 통합 가능하다.
Fluentd, Logstash, Beats(Filebeat, Metricbeat 등): 다양한 소스(파일, TCP/UDP 소켓, 애플리케이션 로그 등)에서 로그를 수집하고, 원하는 형식으로 가공한 뒤 중앙 저장소(Elasticsearch, MongoDB 등)로 전송할 수 있는 툴이다. ROS2 환경에서도 텍스트 로그, JSON 형태 로그 등을 모두 수집할 수 있다. 예를 들어, 멀티머신에서 로그를 Fluentd 에이전트가 수집하여 Elasticsearch로 전송하고, Kibana로 시각화하는 파이프라인을 구성하면, 대시보드 하나에서 모든 로그를 확인할 수 있다.
Graylog: 로그 저장, 검색, 시각화까지 제공하는 통합 로깅 플랫폼이다. 머신 간 로깅 정보를 대조하며 문제 발생 시점을 빠르게 파악하기에 좋다.
분산 트레이싱(Tracing) 툴
최근에는 마이크로서비스 아키텍처나 분산 시스템에서 널리 쓰이는 트레이싱 기법(Distributed Tracing)을 ROS2 멀티머신 환경에도 적용하는 시도가 있다. 각 노드가 메시지를 주고받는 시점을 추적하여 “어떤 노드가 언제 호출되었고, 얼마나 시간이 소요되었는지”를 가시화하면, 병목 지점을 찾기 용이하다.
Jaeger, Zipkin: OpenTracing 혹은 OpenTelemetry 기반의 분산 트레이싱 툴이다. ROS2 노드에서 특정 시점에 스팬(span)을 생성하고, 메시지 수신 후 처리가 끝날 때까지의 기간을 추적할 수 있다. 다만 기존 ROS2 노드를 수정해서 트레이싱 코드를 넣어야 하므로, 적용 난이도가 다소 높을 수 있다.
eBPF 기반 트레이싱: Linux 커널 단에서 eBPF(extended Berkeley Packet Filter)를 활용해 네트워크 소켓 레벨에서의 패킷 흐름, 프로세스 간 컨텍스트 전환, 시스템 콜 등의 정보를 관찰하는 방법이다. ROS2 DDS 통신이 실제로 어떤 IP/포트 조합을 통해 데이터를 송수신하는지, 각 노드가 CPU를 얼마나 소비하는지 등을 미세하게 추적할 수 있다.
성능 분석(Profiling) 및 디버깅 툴
멀티머신 환경에서 특정 노드가 비정상적으로 느려지는 경우, 네트워크 문제뿐 아니라 노드 자체의 연산 비용이 과도하거나 메모리/스레드 자원 할당이 비효율적일 수 있다. 이러한 문제를 찾으려면 코드 수준의 디버깅과 시스템 성능 분석이 필요하다.
Perf: Linux 커널에서 제공하는 성능 분석 툴이다. 함수 단위 프로파일링, CPU 캐시 미스, 하드웨어 이벤트 측정 등이 가능하다. ROS2 노드를 perf record로 실행한 뒤, perf report로 성능 병목 지점을 분석할 수 있다.
스택 트레이스(-g 옵션)까지 기록하면, 어떤 함수에서 CPU 시간을 많이 쓰는지 파악하기 용이하다.
GDB: 대표적인 디버거로, 노드가 크래시가 날 때 코어 덤프를 분석하거나, 특정 라인에서 브레이크포인트를 걸어 동작을 단계별로 살펴볼 수 있다. 멀티머신 환경이라고 해도 원격 디버깅(gdbserver + GDB)을 사용하면, 원격 머신에서 실행 중인 프로세스를 로컬 환경에서 디버깅할 수 있다.
Valgrind: 메모리 누수, 잘못된 메모리 접근 등을 분석하는 데 특화된 툴이다. 멀티머신에서 동일 ROS2 노드가 실행될 때만 문제가 발생한다면, 메모리 접근 경합(race condition)이나 시점 차이에 의한 버그가 있을 수 있다. Valgrind의 Memcheck 모드를 활용하면, 소켓 통신 과정에서의 메모리 오류도 잡아낼 수 있다.
노드 그래프 시각화 및 동적 분석
ROS2 멀티머신 환경에서 노드 간 데이터 흐름을 한눈에 파악하려면, 노드 그래프를 시각화하는 방법이 매우 유용하다. rqt_graph, ros2 CLI 그래프 명령어 등 기본 도구 외에도 전문 시각화 툴을 사용하는 경우가 있다.
rqt_graph: 전통적인 노드-토픽 그래프를 확인할 수 있는 툴이다. 멀티머신 환경에서도 모든 노드가 하나의 그래프에 표시되지만, QoS나 도메인 파티션, 네트워크가 분리되어 있으면 일부 노드가 표시되지 않을 수 있다.
ROS2 Graph APIs: 로우 레벨의 DDS 정보를 얻기 위해서는 ROS2 Graph API나 DDS 수준의 트레이스 API를 사용할 수 있다. 예컨대, 특정 시점에 어떤 Publisher-Subscriber 페어가 연결되었는지, QoS는 무엇인지 등의 정보를 코드 레벨에서 파악할 수 있다.
동적 시스템 분석(DSA) 툴: IBM DSA 또는 Intel VTune 등, 동적 환경에서 스레드 및 CPU 사용을 추적하고, 이벤트를 시간 축에 매핑하여 볼 수 있는 툴이다. ROS2가 멀티스레드로 동작하는 부분을 세밀하게 분석할 때 도움이 된다.
Last updated