659.45 캐시 기간에 따른 메모리 사용량 분석

1. 개요

TF2 라이브러리에서 캐시 기간(Cache Duration)은 tf2::Buffer가 과거 좌표 변환 데이터를 보관하는 시간적 범위를 결정하는 핵심 파라미터이다. 캐시 기간의 설정값은 시스템의 메모리 사용량에 직접적인 영향을 미치며, 로봇 시스템의 성능 최적화를 위해 캐시 기간과 메모리 소비 간의 상관관계를 정량적으로 분석하는 것이 필수적이다. 본 절에서는 TF2 캐시의 내부 메모리 구조, 캐시 기간에 따른 메모리 증가 양상, 그리고 실제 로봇 시스템에서의 메모리 사용량 추정 방법을 체계적으로 다룬다.

2. TF2 캐시의 내부 메모리 구조

2.1 변환 데이터의 저장 단위

TF2의 tf2::Buffer는 내부적으로 tf2::BufferCore를 통해 좌표 변환 데이터를 관리한다. BufferCore는 각 프레임 쌍(parent-child pair)에 대해 독립적인 시간 정렬 리스트(time-ordered list)를 유지하며, 각 리스트의 항목은 단일 변환 스냅샷(transform snapshot)에 해당한다.

하나의 변환 스냅샷이 차지하는 메모리는 다음과 같은 필드로 구성된다:

따라서 하나의 변환 스냅샷은 메타데이터를 포함하여 대략 72~128 바이트를 소비한다. 프레임 식별 문자열의 길이와 내부 메모리 정렬(alignment) 패딩에 따라 실제 소비량은 다소 변동될 수 있다.

2.2 프레임별 캐시 자료 구조

BufferCore는 각 프레임에 대해 TimeCacheInterface를 구현한 캐시 객체를 유지한다. 동적 변환(dynamic transform)에는 TimeCache 클래스가 사용되고, 정적 변환(static transform)에는 StaticCache 클래스가 사용된다.

• TimeCache: 시간 순서로 정렬된 std::deque<TransformStorage> 자료 구조를 내부적으로 관리한다. 새로운 변환이 삽입되면 캐시 기간을 초과하는 오래된 항목이 자동으로 제거된다.
• StaticCache: 단일 변환만 저장하므로 캐시 기간에 무관하게 일정한 메모리를 소비한다. 정적 변환은 최초 수신된 이후 갱신되지 않는 한 동일한 메모리를 점유한다.

따라서 메모리 사용량 분석의 대상은 주로 **동적 변환의 TimeCache**에 국한된다.

3. 캐시 기간과 메모리 사용량의 관계

3.1 메모리 사용량 추정 공식

특정 프레임 쌍에 대한 동적 변환의 메모리 사용량은 다음 공식으로 추정할 수 있다:

M_{\text{frame}} = f \times D \times S

여기서 각 변수의 의미는 다음과 같다:

• M_{\text{frame}}: 해당 프레임 쌍의 메모리 사용량 (바이트)
• f: 변환 발행 주파수 (Hz)
• D: 캐시 기간 (초)
• S: 단일 변환 스냅샷의 메모리 크기 (바이트, 약 72~128)

시스템 전체의 TF2 캐시 메모리 사용량은 모든 동적 프레임 쌍의 합산으로 계산한다:

M_{\text{total}} = \sum_{i=1}^{N} f_i \times D \times S + N_{\text{static}} \times S

여기서 N은 동적 프레임 쌍의 수, N_{\text{static}}은 정적 프레임 쌍의 수이다. 정적 프레임은 캐시 기간에 무관하게 각각 하나의 스냅샷만 저장하므로 N_{\text{static}} \times S의 고정 메모리를 소비한다.

3.2 구체적 수치 예시

다음은 전형적인 이동 로봇 시스템에서의 메모리 사용량을 추정한 것이다. 단일 스냅샷 크기를 S = 100 바이트로 가정한다.

시스템 설정:

• 동적 프레임 쌍 수: 15개
• 각 프레임의 평균 발행 주파수: 50 Hz
• 정적 프레임 쌍 수: 20개

위 표에서 확인할 수 있듯이, 캐시 기간은 동적 변환의 메모리 사용량과 선형적 비례 관계를 가진다. 캐시 기간을 기본값인 10초에서 300초(5분)로 증가시키면, 동적 변환만으로도 약 21 MB의 메모리를 소비하게 된다.

3.3 복잡한 로봇 시스템에서의 메모리 증폭

실제 로봇 시스템에서는 프레임 수와 발행 주파수가 시스템 복잡도에 따라 급격히 증가할 수 있다. 다음은 다양한 로봇 시스템 유형별 메모리 사용량 추정치이다 (캐시 기간 10초, S = 100 바이트 기준):

이 추정치에는 std::deque 자료 구조의 내부 오버헤드, 메모리 정렬 패딩, BufferCore의 관리 구조체 등 부가적인 메모리 소비가 포함되지 않으므로, 실제 메모리 사용량은 추정치의 1.2~1.5배에 달할 수 있다.

4. 메모리 사용량에 영향을 미치는 요인

4.1 변환 발행 주파수

변환 발행 주파수(f)는 캐시 기간과 함께 메모리 사용량을 결정하는 가장 중요한 변수이다. 고정밀 제어가 요구되는 매니퓰레이터 시스템에서는 관절 변환을 100~500 Hz로 발행하는 경우가 있으며, 이 경우 단일 관절만으로도 10초 캐시에 1,000~5,000개의 스냅샷이 축적된다.

불필요하게 높은 발행 주파수는 메모리 낭비를 초래한다. 예를 들어 센서 데이터의 갱신 주기가 30 Hz인 시스템에서 변환을 100 Hz로 발행하면, 센서와 동기화되지 않는 여분의 변환 스냅샷이 메모리를 점유하게 된다. 따라서 변환 발행 주파수는 해당 프레임을 소비하는 노드의 최대 처리 주파수에 맞추어 설정하는 것이 바람직하다.

4.2 프레임 수 (변환 트리의 규모)

변환 트리의 프레임 수가 증가하면 총 메모리 사용량은 프레임 수에 비례하여 증가한다. 특히 다중 로봇 시스템이나 휴머노이드 로봇과 같이 프레임 수가 수십~수백 개에 달하는 시스템에서는 캐시 기간의 설정이 전체 메모리 예산에 중대한 영향을 미친다.

프레임 수를 줄이기 위한 전략으로는, 활용되지 않는 중간 프레임의 제거, 유사한 위치를 공유하는 프레임의 병합, 그리고 빈번하게 변화하지 않는 동적 프레임의 정적 프레임 전환 등이 있다.

4.3 정적 변환과 동적 변환의 비율

정적 변환은 캐시 기간에 무관하게 일정한 메모리를 소비하므로, 가능한 한 많은 변환을 정적 변환으로 분류하는 것이 메모리 절약에 유리하다. 센서 마운트 위치, 로봇 본체 내 고정 부품 간의 관계 등 시간에 따라 변화하지 않는 변환은 반드시 정적 변환으로 발행해야 한다.

정적 변환을 동적 변환으로 잘못 발행하는 경우, 캐시 기간 동안 불필요한 중복 스냅샷이 축적되어 메모리를 낭비하게 된다. 예를 들어 50 Hz로 발행되는 정적 변환을 동적으로 잘못 설정하면, 10초 캐시에서 500개의 동일한 스냅샷이 저장되어 약 50 KB의 불필요한 메모리를 소비한다.

5. 캐시 기간 조정에 따른 트레이드오프

5.1 짧은 캐시 기간의 장단점

캐시 기간을 짧게 설정하면 메모리 사용량을 절약할 수 있으나, 다음과 같은 제약이 발생한다:

• 시간 여행(time travel) 범위 축소: 과거 시점의 변환을 조회할 수 있는 범위가 줄어들어, 센서 데이터의 처리 지연이 캐시 기간을 초과하면 ExtrapolationException이 발생한다.
• 느린 노드의 변환 실패: 센서 융합(sensor fusion)이나 SLAM과 같이 처리 시간이 긴 노드에서 과거 시점의 변환을 요청할 때 실패할 확률이 높아진다.
• 디버깅 난이도 증가: 과거 데이터를 참조할 수 있는 시간이 짧아져 문제 진단이 어려워진다.

5.2 긴 캐시 기간의 장단점

캐시 기간을 길게 설정하면 시간적으로 넓은 범위의 변환을 조회할 수 있으나, 다음과 같은 문제가 수반된다:

• 메모리 사용량 증가: 앞서 분석한 바와 같이 캐시 기간에 비례하여 메모리 소비가 선형적으로 증가한다.
• 변환 조회 성능 저하: 캐시 항목 수가 증가하면 이진 탐색(binary search) 비용이 O(\log n)으로 증가한다. 실질적으로는 캐시 항목 수가 극단적으로 커지지 않는 한 성능 저하는 미미하다.
• 메모리 단편화(memory fragmentation): 장기간 운용되는 시스템에서 std::deque의 빈번한 삽입/삭제가 메모리 단편화를 유발할 수 있다.

5.3 최적 캐시 기간 결정 기준

최적의 캐시 기간은 다음 요인을 종합적으로 고려하여 결정해야 한다:

1. 최대 센서 처리 지연: 가장 긴 센서 파이프라인의 처리 시간보다 캐시 기간이 길어야 한다.
2. 시스템 가용 메모리: 전체 시스템 메모리에서 TF2 캐시가 차지할 수 있는 비율을 제한해야 한다.
3. 로깅 및 디버깅 요구사항: 디버깅 목적의 과거 변환 참조가 필요한 경우 캐시 기간을 충분히 확보한다.
4. 변환 보간 정확도: 캐시 기간이 너무 짧으면 보간(interpolation)에 필요한 인접 시점의 데이터가 부족하여 정확도가 저하될 수 있다.

일반적인 지침으로, 기본값인 10초는 대부분의 표준 로봇 시스템에서 충분하다. 임베디드 시스템이나 메모리가 제한된 환경에서는 3~5초로 줄이는 것을 고려하며, SLAM이나 장기 경로 계획과 같이 긴 처리 지연이 발생하는 시스템에서는 20~30초로 확장하는 것이 적합하다.

6. 메모리 사용량 측정 및 모니터링 방법

6.1 런타임 메모리 프로파일링

실제 시스템에서 TF2 캐시의 메모리 사용량을 측정하려면 운영체제 수준의 메모리 프로파일링 도구를 활용한다.

Linux proc 파일시스템을 이용한 프로세스 메모리 모니터링:

# TF2 관련 노드의 PID 확인
ros2 node list
ps aux | grep <노드명>

# RSS(Resident Set Size) 모니터링
watch -n 1 "cat /proc/<PID>/status | grep -E 'VmRSS|VmSize'"

Valgrind Massif를 이용한 힙 메모리 프로파일링:

valgrind --tool=massif --pages-as-heap=yes \
  ros2 run <패키지명> <노드명>

# 프로파일 결과 시각화
ms_print massif.out.<PID>

6.2 TF2 내부 통계 활용

tf2_monitor 도구를 이용하면 각 프레임별 변환 발행 주파수와 지연 시간을 확인할 수 있으며, 이 정보를 기반으로 메모리 사용량을 추정할 수 있다:

ros2 run tf2_ros tf2_monitor

출력에는 각 프레임의 평균 발행 주파수가 포함되므로, 이를 캐시 기간 및 스냅샷 크기와 곱하여 프레임별 메모리 추정치를 산출할 수 있다.

6.3 프로그래밍 방식의 메모리 추정

ROS2 노드 내에서 BufferCore의 상태를 프로그래밍 방식으로 조회하여 메모리 사용량을 추정하는 방법도 가능하다:

#include <tf2_ros/buffer.h>
#include <rclcpp/rclcpp.hpp>

auto node = rclcpp::Node::make_shared("tf_memory_estimator");
tf2_ros::Buffer tf_buffer(node->get_clock());

// 모든 프레임 문자열 조회
std::string all_frames = tf_buffer._allFramesAsYAML();
RCLCPP_INFO(node->get_logger(), "TF2 Frame Info:\n%s", all_frames.c_str());

_allFramesAsYAML() 메서드는 각 프레임의 데이터 수(data count), 발행 주파수 등의 정보를 YAML 형식으로 반환하며, 이를 파싱하여 메모리 추정치를 계산할 수 있다.

7. 메모리 최적화 전략

7.1 프레임별 차별화된 발행 주파수 적용

모든 동적 프레임에 동일한 발행 주파수를 적용하지 말고, 각 프레임의 변화 속도와 소비 노드의 요구사항에 맞추어 차별화된 주파수를 설정한다:

• 관절 변환 (joint frames): 제어 루프 주파수에 맞추어 100~500 Hz
• 오도메트리 변환 (odom → base_link): 로봇 이동 속도에 따라 20~100 Hz
• 센서 마운트 변환: 센서 데이터 주파수에 맞추어 10~30 Hz

7.2 정적 변환의 적극적 활용

시간에 따라 변화하지 않는 모든 변환은 정적 변환으로 발행한다. 정적 변환은 /tf_static 토픽을 통해 전달되며, StaticCache에 단일 항목만 저장되므로 메모리 소비가 최소화된다. URDF에 정의된 고정 관절(fixed joint)의 변환은 robot_state_publisher에 의해 자동으로 정적 변환으로 발행된다.

7.3 노드별 캐시 기간 차별화

시스템 설계 시 모든 노드가 동일한 캐시 기간을 사용할 필요는 없다. 각 노드의 용도에 따라 적절한 캐시 기간을 설정할 수 있다:

// 실시간 제어 노드: 짧은 캐시
tf2_ros::Buffer buffer_control(
  node->get_clock(),
  tf2::durationFromSec(3.0)
);

// SLAM/내비게이션 노드: 긴 캐시
tf2_ros::Buffer buffer_nav(
  node->get_clock(),
  tf2::durationFromSec(30.0)
);

# 실시간 제어 노드: 짧은 캐시
buffer_control = tf2_ros.Buffer(cache_time=rclpy.duration.Duration(seconds=3.0))

# SLAM/내비게이션 노드: 긴 캐시
buffer_nav = tf2_ros.Buffer(cache_time=rclpy.duration.Duration(seconds=30.0))

7.4 임베디드 시스템에서의 메모리 관리

메모리가 제한된 임베디드 플랫폼(예: Raspberry Pi, NVIDIA Jetson Nano)에서는 다음 전략을 적용한다:

1. 캐시 기간을 2~3초로 축소: 임베디드 환경에서는 처리 지연이 짧고, 과거 변환 참조 필요성이 낮으므로 캐시 기간 축소가 가능하다.
2. 불필요한 프레임 제거: 시각화 전용 프레임이나 디버깅 프레임을 운영 환경에서 비활성화한다.
3. 발행 주파수 하향 조정: 처리 성능에 맞추어 발행 주파수를 낮추어 캐시 항목 수를 줄인다.
4. 메모리 모니터링 통합: 시스템 가동 중 메모리 사용량의 지속적인 모니터링을 통해 메모리 누수나 비정상적 증가를 조기에 감지한다.

8. 요약

TF2의 캐시 기간은 메모리 사용량과 직접적인 선형 비례 관계를 가지며, 변환 발행 주파수 및 프레임 수와의 곱으로 총 메모리 소비량이 결정된다. 기본값인 10초는 일반적인 로봇 시스템에서 합리적인 균형을 제공하지만, 시스템의 프레임 규모, 발행 주파수, 메모리 제약, 처리 지연 특성에 따라 적절히 조정해야 한다. 정적 변환의 적극적 활용, 프레임별 차별화된 발행 주파수 설정, 노드별 캐시 기간 차별화 등의 최적화 전략을 통해 메모리 효율성을 극대화할 수 있다.

9. 참고 문헌

• Foote, T. (2013). “tf: The Transform Library.” IEEE International Conference on Technologies for Practical Robot Applications (TePRA).
• Open Robotics. “tf2 — ROS 2 Documentation.” ROS 2 공식 문서. https://docs.ros.org/en/rolling/Concepts/Intermediate/About-Tf2.html
• Open Robotics. “tf2_ros API Reference.” ROS 2 API 문서. https://docs.ros2.org/latest/api/tf2_ros/
• REP 103 — Standard Units of Measure and Coordinate Conventions. https://www.ros.org/reps/rep-0103.html
• REP 105 — Coordinate Frames for Mobile Platforms. https://www.ros.org/reps/rep-0105.html