Real-time ROS2 환경에서의 QoS 설정 기본
실시간 시스템에서 QoS의 중요성
ROS2에서 노드 간 통신은 다양한 상황에 대응할 수 있도록 여러 가지 QoS(Quality of Service) 설정을 지원한다. 특히 실시간(real-time) 요구 사항이 존재하는 환경에서는 QoS 전략이 시스템의 안정성과 신뢰도를 결정짓는 핵심 요소이다. 일반적인 ROS2 애플리케이션에서는 QoS 설정이 크게 주목받지 않을 수 있지만, 산업용 로봇, 자율 주행, 의료 기기와 같은 하드 실시간 또는 소프트 실시간 특성을 요구하는 응용 분야에서는 QoS 설정이 반드시 필요하다.
이때 ROS2의 QoS 프로파일을 잘 이해하면, 통신 지연(latency), 메시지 유실율(loss rate), 통신 버퍼링 방식 등에 대해 정밀하게 튜닝(tuning)할 수 있다. 적절한 QoS 설정은 노드 간 메시지의 신뢰도와 실시간성을 보장하는 핵심 수단이며, 동시에 시스템 자원을 효율적으로 활용하게 해 준다.
QoS 설정과 Real-time ROS2의 상관관계
실시간성을 달성하기 위해서는 노드 간 메시지 처리, 스케줄링, 네트워크 지연 등에 대한 가시성과 제어가 필수적이다. ROS2의 QoS는 DDS(Data Distribution Service)에서 제공되는 설정 옵션을 기반으로 하며, 크게 다음과 같은 특성이 실시간 요구사항과 연관이 깊다.
Reliable vs Best Effort
Reliable: 모든 메시지를 확실히 전달하려고 시도한다. 재전송(ack, nack) 과정을 거치므로 일반적으로 지연 시간이 늘어나지만, 데이터 무결성을 더 보장한다.
Best Effort: 가능한 한 빠르게 전달하고, 메시지 유실에 대해서는 재전송을 고려하지 않는다. 지연 시간을 최소화하기 유리하지만, 메시지 유실 가능성이 있다.
Deadline
메시지가 정해진 시간 안에 전달되지 않을 경우 이를 감지하고, 구독자 측에서 처리 로직을 구성할 수 있는 기능이다. 이를 통해 미달(deadline miss) 상황을 감지하고 장애 처리를 수행하거나 다른 로직을 트리거(trigger)할 수 있다.
Latency Budget
메시지가 전달되는 데 허용되는 최대 지연 시간을 설정한다. 이는 DDS 수준에서 네트워크 패킷 관리, 버퍼링 시점 등을 결정하는 기준값으로 쓰일 수 있다.
Liveliness
퍼블리셔가 정상적으로 동작하고 있는지를 구독자가 모니터링할 수 있도록 제공하는 QoS 설정이다. 즉, 일정 주기 내에 퍼블리셔의 생존 신호가 감지되지 않으면, 구독자는 해당 퍼블리셔가 다운되었거나 이상 상태에 빠졌다고 판단할 수 있다.
실시간을 위한 QoS 전략의 기본 구도
ROS2 실시간 환경에서 QoS를 구성할 때, 아래와 같은 포인트를 우선적으로 고려한다.
통신 신뢰성 vs 지연 시간
실시간성의 정의는 애플리케이션마다 다르다. ‘절대적으로 메시지가 빠른 시간 내에 도착해야 하는가?’ 혹은 ‘메시지를 절대 유실해서는 안 되는가?’ 같은 질문에 따라 달라진다.
예를 들어 하드 실시간 환경에서 로봇 조작에 필수적인 센서 데이터는 가능한 유실 없이 보장(Reliable)되어야 한다. 하지만 영상 처리나 보조 데이터 같은 경우에는 Best Effort 옵션을 택해 지연 시간을 줄일 수 있다.
Deadline과 타이밍 모니터링
실시간 시스템에서는 특정 주기의 메시지가 시간 안에 도착하지 않으면 의미가 없는 경우가 많다.
Deadline QoS를 통해 노드 간 통신 지연이나 누락을 감지할 수 있고, 이를 기반으로 장애 대응 로직을 수행할 수 있다.
시스템 자원과 우선순위
QoS 설정이 너무 보수적으로 잡혀 있으면(예: 높은 신뢰성, 매우 짧은 Deadline), 통신 재전송이 과도해지거나 CPU 자원 소모가 늘어나 시스템 전체의 실시간 성능을 오히려 저하시킬 수 있다.
따라서 각 노드의 메시지 중요도와 주기, 네트워크 트래픽 상황 등을 고려해 균형 잡힌 QoS 전략을 세우는 것이 중요하다.
실시간 요구 사항 정의 시 고려해야 할 지표
ROS2 노드 간 통신의 실시간성을 확보하기 위해서는 아래 지표들을 정량적으로 정의하고, QoS 설정과 연동해야 한다.
메시지 전송 주기(Period): 퍼블리셔가 메시지를 보내는 주기. 하드 실시간에서는 일정 주기를 유지해야 하므로, 오차 범위를 설정하고 모니터링 체계를 갖추어야 한다.
지연 시간(Latency):
퍼블리셔가 메시지를 발행한 시점부터 구독자가 해당 메시지를 완전히 수신하고 처리하기까지 걸리는 시간. 네트워크 지연, OS 스케줄링, DDS 내부 버퍼링 등이 모두 포함된다.
만약 지연 시간을 $T_{lat}$라 할 때, 아래와 같이 단순 모델링할 수 있다.
여기서 $T_\text{net}$은 물리 네트워크 지연, $T_\text{sched}$은 OS나 RTOS의 스레드 스케줄링 지연, $T_\text{buf}$는 DDS 레이어에서의 버퍼링, $T_\text{proc}$는 구독 측에서 메시지를 실제로 수신하고 처리하는 데 걸리는 시간을 의미한다.
메시지 유실(Message Loss)
Reliable QoS를 사용하더라도 간헐적인 네트워크 오류나 extreme case에서는 메시지 유실이 발생할 수 있다. 이러한 경우 QoS 재전송 전략과 Deadline을 통한 모니터링이 필수적이다.
우선순위 스케줄링(Priority Scheduling)
운영체제나 RTOS 수준에서 고우선순위 노드가 메시지를 발행하거나 구독할 때, CPU와 네트워크 대역폭을 먼저 쓸 수 있도록 환경을 구성하는 것도 실시간성 확보에 중요하다.
QoS 프로파일별 실시간 활용 방안
ROS2에서 제공하는 QoS 프로파일은 크게 몇 가지 유형(Default, Sensor Data, System Default 등)으로 구분된다. 하지만 실시간 요구사항을 충족하기 위해서는 표준 프로파일을 그대로 사용하는 것보다, 각 항목을 세부적으로 커스터마이징하는 경우가 많다. 일반적으로 다음과 같은 조합을 활용한다.
Reliable + Keep Last
메시지 전달 보장을 최우선으로 하고, 버퍼의 마지막 몇 개만 관리하는 형태.
하드 실시간 인 경우, 큐 사이즈를 너무 크게 잡으면 지연 시간이 가중되므로, 큐 사이즈를 1 또는 소수로 제한하는 방식이 유리하다.
Best Effort + Keep All
메시지 전달 보장을 크게 고려하지 않고 빠른 처리를 원하는 경우에 사용된다.
Keep All 옵션으로 모든 메시지를 보관하다 보면 메모리 사용량이 급격히 늘어날 수 있으므로 주의가 필요하다.
Transient Local
퍼블리셔가 죽거나 일시적으로 통신이 끊겼을 때도, 새로운 구독자가 다시 연결하면 과거 메시지를 받을 수 있도록 해 주는 설정이다.
실시간 관점에서는 메시지 유실을 방지하지만, 실시간성보다는 신뢰성 보강 측면이 크므로 주기적인 데이터를 다루는 하드 실시간에는 신중하게 적용해야 한다.
DDS 레벨에서의 RT QoS 특징
ROS2 QoS는 DDS를 기반으로 하기 때문에, DDS에서 정의한 다음 요소들도 실시간 통신에 영향을 미친다.
주기적 샘플 전송 주기(Periodicity)
DDS는 샘플 전송을 주기적으로 진행할 수 있는 메커니즘을 제공한다. 이를 통해 노드 간 메시지 교환이 예측 가능하게 이루어진다.
장애 전파(Deadline Miss Listener)
DDS 레벨에서 Deadline이 어긋날 경우 이벤트를 발생시켜 별도의 핸들러(listener)에서 처리할 수 있다. 이는 ROS2에서 QoS 이벤트 콜백으로 연결되어, 개발자가 원하는 로직을 구현하도록 한다.
RTPS(Real-Time Publish-Subscribe) 프로토콜 스택
ROS2의 통신 계층은 기본적으로 RTPS(Real-Time Publish-Subscribe)를 이용한다. 이름은 ‘Real-Time’이라 불리지만, 실제로는 하드 실시간을 완벽하게 보장하지는 않는다. QoS 설정을 통해 RTPS가 제공하는 재전송, 버퍼 관리 등의 정책을 세부 제어함으로써 실시간성을 최대한 끌어올릴 수 있다.
RMW 구현체별 QoS 차이점
ROS2는 여러 가지 RMW(Robot Middleware) 구현체를 지원한다. 대표적인 예로 Cyclone DDS, Fast DDS, RTI Connext 등이 있다. 각 RMW는 DDS 스펙을 따르지만, 구현 디테일과 성능 최적화 전략이 다르기 때문에 실시간 ROS2 환경에서 QoS 설정 시 다음과 같은 점을 유의해야 한다.
Default QoS 프로파일의 차이
RMW마다 Default QoS 초기값이 미묘하게 다를 수 있다. 예를 들어, Fast DDS에서는 기본적으로 Reliable 모드지만, Cyclone DDS에서는 다른 값을 사용하는 식이다.
실시간 환경에서는 Default QoS 프로파일을 그대로 사용하기보다는, 프로젝트 요구 사항에 맞춰 명시적으로 설정하는 편이 낫다.
노드 스레드 모델 구현 차이
RMW마다 메시지 핸들링 스레드 개수, 스레드 간 스케줄링 방식, Lock-Free 구조 적용 여부가 상이하다.
동일한 QoS 설정을 사용하더라도, 어떤 RMW를 사용하느냐에 따라 메시지 지연 시간이 달라질 수 있다.
네트워크 드라이버 및 버퍼링 정책
Cyclone DDS는 패킷을 하나의 OS 소켓으로만 처리하거나, Fast DDS는 멀티 소켓 방식을 쓰는 등, 내부 정책이 다르다.
메시지 유실이나 지연이 발생할 때 재전송(ack, nack)이 어떻게 일어나는지, 버퍼가 가득 찼을 때의 동작 방식을 확인해야 한다.
노드 내부 실시간 스케줄링
QoS 설정이 통신 지연을 최소화하고 신뢰성을 유지하는 데 중요한 역할을 하지만, 노드 내부적으로도 실시간성을 보장하기 위한 프로세스 스케줄링과 메모리 할당 전략이 필요하다. 일반적으로 리눅스 환경에서 다음과 같은 방식을 적용한다.
실시간 스레드 우선순위 설정:
SCHED_FIFO또는SCHED_RR와 같은 리눅스 RT 스케줄링 정책을 사용해 중요 노드의 스레드 우선순위를 높인다.이를 위해서는 다음과 같은 명령으로 프로세스를 RT 모드로 실행하거나, 런칭 스크립트 내에서 설정할 수 있다.
여기서 -f는 FIFO 정책을 의미하고, 90은 우선순위 값을 뜻한다.
메모리 Lock과 Zero-Copy:
실시간 애플리케이션에서는 런타임 메모리 할당으로 발생하는 페이지 폴트나 스와핑을 최소화하기 위해
mlock함수를 이용해 중요한 메모리를 Lock하는 기법을 사용하기도 한다.Zero-Copy 기법을 사용할 수 있는 RMW가 있다면, 이를 활성화하여 메시지 복사를 줄여 지연을 개선할 수 있다. 다만 Zero-Copy를 지원하지 않는 노드 또는 상위 레벨의 API와 호환성 문제가 있을 수 있으므로, 테스트가 필수다.
Garbage Collection 제어:
C++로 개발되는 ROS2 노드라면 큰 문제가 되지 않지만, Python 노드에서는 Garbage Collector(GC)가 예기치 않은 시점에 동작하여, 스레드 중단(lag)을 유발할 수 있다.
실시간이 중요한 노드라면 C++ 노드로 구현하는 것이 일반적이며, Python을 사용할 경우에는 GC 동작을 주기적으로 수동 호출하거나, 비실시간 부하가 낮은 구간에 제한적으로 동작하도록 하는 기법을 고려할 수 있다.
QoS 구성 시 주의 사항
실시간 ROS2 환경에서 QoS를 튜닝할 때, 아래 요소들을 종합적으로 고려해야 시스템 전체 성능 저하 없이 안정적인 실시간 요구 사항을 만족시킬 수 있다.
상충되는 QoS 옵션
Reliable + Keep All + 짧은 Deadline 조합은 재전송과 높은 메모리 사용량이 뒤섞여 오히려 지연을 유발할 수 있다.
Best Effort + 긴 Deadline 조합은 실시간성을 높일 수 있지만, 메시지 유실 확률이 높아질 수 있다.
네트워크 품질
DDS는 로컬 네트워크나 무선 환경 등 다양한 상황에서 동작한다. 특히 무선 네트워크는 지연 변동(latency jitter)이 크고 패킷 손실률이 높기 때문에, QoS 설정 시 재전송 전략이 더욱 중요하다.
산업용 이더넷(예: TSN, EtherCAT)과 같이 실시간 특성을 보장하는 네트워크를 활용하면 QoS 설정 부담이 줄어든다.
메시지 크기와 주기
초당 수백 MB에 달하는 큰 이미지 데이터를 실시간으로 전송하려고 하면, 아무리 QoS를 잘 설정해도 버퍼링 지연이 발생할 가능성이 크다.
프로파일링을 통해 노드 간 트래픽과 처리량을 측정하고, 실제로 원하는 실시간 성능을 달성할 수 있는지 검증해야 한다.
확장성(Scalability)
QoS 설정으로 소규모 시스템에서 충분한 실시간 성능을 얻었더라도, 노드가 늘어나거나 네트워크 환경이 복잡해지면 결과가 달라질 수 있다.
대규모 분산 시스템이라면 노드 간 통신 구조, 토폴로지, QoS 설정을 전반적으로 재설계해야 할 수도 있다.
시간 동기화(Timestamp Synchronization)
실시간 ROS2 환경에서는 노드 간 메시지를 정확한 시간 축에서 분석하고 처리하기 위해 타임스탬프를 일관성 있게 유지하는 것이 매우 중요하다. 센서 측정값과 제어 명령 등이 서로 다른 노드 혹은 장비에서 생성되므로, 이를 공통된 시간 축으로 맞추지 않으면 데이터 해석에 오류가 생길 수 있다. 또한, QoS 설정을 통해 메시지 전달이 신뢰적으로 이루어지더라도, 타임스탬프가 잘못 기록되어 있으면 실시간 판단 로직이 오작동할 수 있다.
NTP와 PTP를 통한 외부 클록 동기화:
일반적으로 NTP(Network Time Protocol)를 통해 인터넷 상의 시간 서버와 동기화를 진행한다. 하지만 NTP는 정확도가 수 ms 수준으로, 하드 실시간이 필요한 로봇 시스템에는 부족할 수 있다.
PTP(Precision Time Protocol)는 하드웨어 타임스탬프를 지원하고, 네트워크 장비(스위치, 네트워크 카드 등)가 PTP 하드웨어 스탬프를 처리해 주면, 마이크로초(µs) 수준의 동기화를 달성할 수 있다.
산업용 로봇이나 자율주행 차량처럼 아주 낮은 지연과 높은 정확도가 필요한 환경에서는 PTP에 대응하는 네트워크 인프라를 구성하는 것을 고려한다.
ROS2 클록과 시스템 클록:
ROS2에서는 여러 종류의 클록을 지원한다. 기본적으로는 시스템 클록(벽시계 시간)을 사용하지만, 실시간 테스트나 시뮬레이션 환경에서는 ROS2의 스테디 클록(steady clock) 또는 시뮬레이션 클록(sim time)을 사용할 수 있다.
실제 물리 시스템에서 하드 실시간 처리를 해야 한다면, 모든 노드가 동일한 물리 클록(예: PTP로 동기화된 시스템 시간)을 기준으로 타임스탬프를 생성하고, 메시지에도 이를 기록하는 방식을 권장한다.
노드 간 타임스탬프 관리:
센서 노드에서 메시지를 발행할 때, 센서에서 측정된 순간의 시각을 정확히 기록해야 한다. 이 시점이 OS 스케줄링이나 통신 지연에 의해 지연될 경우, “측정 시간”과 “발행 시간”이 달라질 수 있다.
퍼블리셔 노드에서 타임스탬프를 부여할 때, 센서의 하드웨어 시각 정보를 읽어와 최대한 오차를 줄이거나, 실시간으로 센서에서 제공하는 클록에 접근(드라이버 레벨)하도록 한다.
분산 노드에서의 타임스탬프 보정:
여러 대의 임베디드 장치가 서로 다른 실시간 OS 환경에서 동작하며, 각각 센서를 연결하고 있을 수 있다. 각 장치에서 PTP를 통해 시간 동기화를 했다 하더라도, 센서 드라이버가 제공하는 타임스탬프에 미세한 오프셋이 존재할 수 있다.
이를 보완하기 위해, 후처리 단계에서 센서 데이터를 재정렬하거나, 중앙 노드에서 타임스탬프 보정을 수행한다. 예를 들어, 다음과 같이 오프셋 $\Delta t$를 측정해 보정할 수 있다.
여기서 $t_\text{sensor}$는 센서 드라이버가 부여한 시간, $\Delta t$는 센서마다 고유하게 발생하는 지연이나 동기화 오차이다.
QoS와 타임스탬프 관계:
메시지 전달 자체를 Reliable로 설정했다고 해서 센서 측정 시간이 정확히 맞춰지는 것은 아니다.
Best Effort로 통신하면 지연은 줄어들 수 있지만, 메시지가 손실될 때 시간 축 정보가 불연속적으로 끊길 수 있으므로, 보정 로직에서 예외 상황을 처리해야 한다.
Deadline QoS를 통해 특정 시간 간격 내에 메시지를 수신하지 못하면 이벤트를 발생시킴으로써, 타임스탬프 이상 여부를 감지할 수도 있다.
ROS2 QoS와 RTOS 통합
하드 실시간성을 확보하기 위해는 ROS2가 동작하는 운영체제 자체도 RTOS(Real-Time Operating System) 또는 리눅스 실시간 패치 커널을 사용하는 경우가 많다. 이때 QoS 설정은 RTOS의 스케줄링 정책과 상호작용하게 된다.
ROS 2 + Xenomai / RT Preempt 패치:
표준 리눅스 커널 대신 Xenomai나 RT Preempt 패치가 적용된 커널을 사용하면, 커널 공간에서의 스케줄링 지연과 우선순위 역전 현상을 크게 줄일 수 있다.
DDS 레이어에서 Reliable 전송을 하기 위해 내부적으로 스레드를 운영하는데, 이러한 스레드도 RT 스케줄링 적용이 가능하도록 커널 및 RMW 설정을 조정해야 한다.
Interrupt Latency 제어:
RTOS 환경에서 중요한 인터럽트를 처리하는 ISR(Interrupt Service Routine) 우선순위가 DDS 통신 스레드보다도 높게 설정되면, 통신 재전송이나 버퍼링에 지연이 생길 수 있다.
QoS에서 짧은 Deadline을 요구한다면, DDS 통신 관련 스레드가 우선적으로 처리될 수 있도록 RTOS에서 인터럽트와 스레드 스케줄링 우선순위를 조정할 필요가 있다.
Shared Memory / Zero-Copy:
같은 물리 머신 내부에서 노드 간 통신이 이루어지는 경우, RMW에 따라 Shared Memory 전송 방식을 지원하기도 한다. 이때는 TCP/UDP 소켓이 아닌 메모리 맵 기반으로 데이터를 교환하므로, 지연이 크게 줄어든다.
Zero-Copy를 지원하는 RMW라면, 메시지 전송 과정에서 복사(copy)가 발생하지 않아 CPU 사용량과 지연 시간을 최소화할 수 있다.
Watchdog과 Fail-safe 매커니즘:
RTOS 및 ROS2 QoS 조합에서 메시지 교환이 일정 기간 이상 중단되면, 워치독 프로세스나 시스템 Fail-safe 로직을 동작시켜야 할 때가 있다.
Liveliness QoS나 Deadline QoS에서 타임아웃이 감지되면 즉시 시스템 레벨 워치독을 활성화해 안전 모드로 전환하는 등의 메커니즘이 가능하다.
QoS 디버깅 및 모니터링
실시간 ROS2 시스템에서 QoS 설정을 제대로 했는지, 혹은 통신 지연이나 메시지 유실이 어느 정도로 발생하는지 모니터링하고 디버깅하는 것은 매우 중요하다. 아래와 같은 기법을 활용하면 QoS 설정이 제대로 동작하는지 검증할 수 있다.
ROS2 CLI와 QoS 프로파일 확인:
ROS2 Command Line Interface(CLI)를 통해 퍼블리셔 및 서브스크라이버의 현재 QoS 프로파일을 조회할 수 있다. 예를 들어 다음 명령을 사용하면 특정 토픽의 퍼블리셔들이 어떤 QoS 설정을 갖는지 확인할 수 있다.
이를 통해 Reliability(신뢰성), Durability(지속성), Deadline 등 주요 QoS 정보가 올바른지 확인한다.
rqt_graph 및 rqt_topic:
rqt_graph를 사용하면 노드 간 연결 상태를 시각적으로 볼 수 있고, rqt_topic 플러그인을 이용하면 토픽 데이터를 실시간으로 모니터링할 수 있다.
QoS 설정으로 인한 메시지 유실 또는 지연을 직관적으로 확인하기는 어렵지만, 토픽에서 메시지가 수신되는 빈도나 시점을 대략적으로 파악하는 데 도움이 된다.
DDS 네이티브 툴:
Cyclone DDS, Fast DDS, RTI Connext 등 각 DDS 구현체마다 네트워크 트래픽 모니터링 툴, 로깅(logging) 옵션, 관리자(admin) 콘솔 등을 제공한다.
예를 들어 Fast DDS의 경우 “Fast DDS Monitor”라는 GUI 툴을 통해 데이터 라우팅 정보를 시각적으로 확인하고, 노드 간 통신 상태(Throughput, Latency, 패킷 드롭)을 모니터링할 수 있다.
Wireshark나 tcpdump를 통한 패킷 캡처:
DDS 통신은 주로 UDP 기반의 RTPS 프로토콜을 사용하므로, Wireshark를 통해 패킷을 캡처하면 실제 전송되는 메시지들을 분석할 수 있다.
Best Effort 모드에서 패킷 유실이 발생하는지, Reliable 모드에서 재전송(ACK, NACK) 트래픽이 빈번히 발생하는지 등을 확인할 수 있다.
Latency 측정 스크립트:
실제 퍼블리셔와 서브스크라이버 노드 쌍을 구성해, 메시지 발행 시각과 수신 시각의 차이를 계산하는 스크립트를 작성한다.
ROS2 노드 내부에서
rclcpp::Clock을 사용하거나, 메시지 헤더에 타임스탬프를 기록해서 다음과 같은 계산을 수행한다.
평균 지연 시간뿐만 아니라, 최대/최소 지연 시간, 지연 분산 등을 측정하고, 이를 바탕으로 QoS 설정을 튜닝한다.
Deadline Miss 이벤트 감시:
Deadline QoS를 사용하고 있다면, 퍼블리셔나 서브스크라이버에서 Deadline Miss 콜백 함수를 등록할 수 있다.
콜백에서 로그를 기록하거나, 토픽으로 재발행하는 방식을 통해 언제, 얼마나 자주 Deadline Miss가 일어나는지 파악한다.
예시 코드: QoS 프로파일 커스텀
ROS2에서 특정 노드에 커스텀 QoS 설정을 적용하는 예시 코드는 아래와 같다(C++ 예시).
custom_qos.reliability(RMW_QOS_POLICY_RELIABILITY_RELIABLE);를 통해 신뢰성 높은 전달을 보장한다.deadline(rclcpp::Duration(0, 500000000));로 0.5초 이내에 메시지를 수신하지 못하면 Deadline Miss 이벤트를 발생시킨다.liveliness_lease_duration(rclcpp::Duration(2, 0));는 2초 동안 퍼블리셔가 메시지를 발행하지 않으면 구독자가 Liveliness Lost 상태를 감지한다.
QoS 테스트 시나리오
실시간 요건을 갖춘 시스템에서 QoS 설정을 제대로 검증하기 위해서는 여러 가지 상황을 가정하고 테스트를 진행해야 한다.
정상 시나리오
네트워크 부하가 낮고, OS 리소스도 충분한 상태에서 메시지 지연, 유실, Deadline Miss가 거의 없이 정상적으로 동작하는지 확인한다.
네트워크 부하 증가
일정 주기로 큰 메시지(예: 이미지 스트림)를 추가로 전송하거나, 인위적으로 패킷 손실을 유발한다.
이때 Reliable QoS가 과도한 재전송 트래픽을 발생시키는지, 지연이 크게 증가하지 않는지 확인한다.
CPU 부하 증가
타 스레드에서 높은 우선순위로 CPU를 많이 사용하는 태스크를 돌려, ROS2 통신 스레드가 스케줄링에서 밀려나 지연이 발생하는지 모니터링한다.
RTOS라면 우선순위 역전 상황이 없는지, 리소스 락(lock) 충돌로 인한 지연이 없는지 체크한다.
노드 재시작/충돌
퍼블리셔 또는 구독자 노드가 일시적으로 다운되었다가 재시작될 때, QoS 재협상(Discovery) 단계가 제대로 수행되는지 확인한다.
Transient Local 또는 Durable QoS를 사용하는 토픽이라면, 재시작 후에 과거 메시지를 올바르게 수신하는지 점검한다.
Deadline Miss/ Liveliness Lost 시나리오
의도적으로 퍼블리셔가 메시지를 보내지 않거나, 메시지 전송을 지연시켜서 Deadline Miss 이벤트가 발생하는지를 테스트한다.
Liveliness QoS가 동작하는지 확인하기 위해, 퍼블리셔를 장시간 정지시켜 본다.
QoS 실무 적용 체크리스트
다음 체크리스트를 바탕으로 실시간 ROS2에서 QoS 정책을 설정하고 검증할 수 있다.
실시간 요구사항 정의
하드 실시간인가, 소프트 실시간인가?
메시지 유실 허용 범위, 최대 지연 시간, Deadline 등 명확히 수치화했는가?
네트워크 환경
유선 LAN, Wi-Fi, 5G 등 어떤 네트워크인가?
DDS 멀티캐스트 혹은 유니캐스트 설정이 맞는지 확인했는가?
네트워크 QoS(DSCP, VLAN, TSN 등)를 적용해 우선순위를 부여할 수 있는가?
노드 스케줄링
중요한 노드는 RT 스케줄링 정책(SCHED_FIFO 또는 SCHED_RR)을 부여했는가?
우선순위 할당이 적절한가(우선순위 역전 문제는 없는가)?
QoS 정책 조합
Reliable vs Best Effort, Deadline, Liveliness, Durability 설정이 충돌 없이 구성되었는가?
QoS 파라미터(큐 사이즈, lease_duration 등)가 과도하거나 부족하진 않은가?
디버깅 및 모니터링 체계
메시지 지연 측정 로직, Deadline Miss 콜백, Liveliness 모니터링 등이 구현되었는가?
실제 동작 환경에서 패킷 캡처나 DDS 모니터링 툴로 검사했는가?
성능 평가
노드 수를 늘리고, 네트워크 부하를 높여가며 확장성 테스트를 진행했는가?
Latency, Jitter, Throughput, CPU 사용량 등을 정량적으로 측정했는가?
Last updated