ROS 2のノード合成を使い分ける：コンポーネント、ゼロコピー、障害分離の設計

ROS 2の「ゼロコピー」は、配置やミドルウェアの条件を分けて考える必要がある点が気になります。

結論：高速化と障害分離は、処理チェーンごとに境界を決める

ROS 2 Jazzyを前提にすると、カメラ画像やLiDAR点群のような大容量データを連続処理する場合、関連するComposable Nodeを同一プロセスのコンポーネントコンテナへ配置し、Intra-process Communicationを使う構成が有力です。通常のプロセス間DDS通信で必要になるシリアライズや外部トランスポート経由の処理を避けられるため、コピー回数、CPU負荷、通信経路上の待ち時間を減らす方向に働きます。

一方、同一プロセス化は障害分離を弱めます。さらに、ゼロコピーは一律に保証されず、メッセージ型、QoS、RMW実装、基盤ミドルウェア、APIの対応状況に左右されます。したがって、通信量の大きい安定した処理チェーンは合成し、実験的なアルゴリズム、頻繁な再起動が必要なノード、障害時にも残したい機能は別プロセスまたは別コンテナへ分ける、という判断が現実的です。

なぜノードの配置が重要なのか

画像や点群の処理では、センサー取得、前処理、認識、記録など複数のノードがデータを受け渡します。このとき、通信方式や実装に応じた経路・保持領域が関係し、処理段数や購読者数は遅延、CPU負荷、メモリ使用量に影響します。

別プロセスに配置したノード間では、通常、ROS 2のDDS/RMW通信経路を通ります。プロセス境界を越えるためのシリアライズやバッファリングが発生しますが、プロセス単位で影響範囲を分けやすい利点があります。逆に、低遅延だけを優先して多数のノードを一つのプロセスへ集約すると、あるノードのクラッシュで同じプロセス内の複数ノードが停止し得ます。

前提となる用語

Composable Node は、ノードを共有ライブラリとしてビルドし、コンポーネントコンテナへ動的にロードする仕組みです。複数のノードを同一プロセスで動かせます。

Intra-process Communication は、同一プロセス内のPublisherとSubscription間で使える通信経路です。通常のプロセス間通信とは異なり、同一プロセス内でメッセージを受け渡し、シリアライズを避けられる場合があります。ただし、別プロセスの購読者へ配信する場合は、DDS経路が必要です。

loaned message は、PublisherがRMWや基盤ミドルウェアからメモリを借りてメッセージを生成する方式です。同一プロセス内でメッセージの所有権を移動する方式とは異なります。

内部の仕組みとデータ経路

同一コンテナ内のPublisherとSubscriptionでIntra-process Communicationを有効にすると、メッセージは通常のプロセス間DDS経路を通らずに処理されます。その結果、プロセス間転送用のシリアライズ、デシリアライズ、外部トランスポート経由の処理を避けられます。これは遅延とCPU負荷を下げる方向に働きますが、ROS 2全体で共通する削減値が決まっているわけではありません。

また、同一プロセス内でもコピーや保持領域が完全になくなるとは限りません。Intra-process Managerの保持領域、QoSの履歴深度、キュー長、購読者数、メッセージの所有権方式によって、メッセージの保持やコピーの挙動が変わります。プロセス間転送用の中間コピーを削減できても、同一プロセス化が常にRSSを減らすとは限りません。

「ゼロコピー」を判断する際は、次の経路を区別します。第一は、同一プロセス内でメッセージの所有権を移動する経路です。第二は、RMWや基盤ミドルウェアからメモリを借りるloaned messageです。第三は、共有メモリトランスポートを利用するプロセス間通信です。これらは実装上の条件が異なり、一般に同じ意味でゼロコピーと呼べるわけではありません。第四の通常のシリアライズによるプロセス間通信は、ゼロコピー方式ではなく比較対象です。

loaned messageは、RMW実装、基盤ミドルウェア、メッセージ型、Publisher APIが対応している場合に利用できます。条件を満たさなければ、通常のメッセージ確保やコピーへフォールバックします。共有メモリ転送も、実装・設定依存であり、ROS 2アプリケーション全体で自動的に有効になるものではありません。

flowchart LR
  subgraph COMPOSED["同一プロセスのComposable Container"]
    C["カメラ"] -->|"Intra-process経路"| P["画像前処理"]
    P -->|"Intra-process経路"| R["認識"]
    P -.->|"外部購読者へはDDS経路"| E["記録・監視ノード"]
    C:::inside
    P:::inside
    R:::inside
  end

  subgraph SEPARATED["別プロセス構成"]
    C2["カメラプロセス"] -->|"DDS/RMW"| P2["前処理プロセス"]
    P2 -->|"DDS/RMW"| R2["認識プロセス"]
    R2 -->|"DDS/RMW"| E2["記録・監視プロセス"]
    C2:::process
    P2:::process
    R2:::process
    E2:::process
  end

  X["プロセス障害"] -.->|"同一アドレス空間のノードへ波及し得る"| COMPOSED
  Y["プロセス障害"] -.->|"プロセス単位で影響範囲を分けやすい"| SEPARATED

  classDef inside fill:#e8f3ff,stroke:#3777b8,stroke-width:1px
  classDef process fill:#f5f5f5,stroke:#666,stroke-width:1px
  style COMPOSED fill:#f2f8ff,stroke:#3777b8,stroke-width:2px
  style SEPARATED fill:#fafafa,stroke:#666,stroke-width:2px

graph LR
  subgraph COMPOSED[同一プロセス：Composable Container]
    C[カメラ] --> P[前処理]
    P --> R[認識]
  end
  E[記録・監視ノード\n外部プロセス]
  R -->|DDS/RMW\nプロセス間経路| E
  P -.->|Intra-process| R

図では、カメラ、前処理、認識を同一プロセスへ合成し、外部の記録・監視ノードEをプロセス境界の外に置いています。PからEへ出る経路は、同一プロセス内の受け渡しではなく、DDS/RMWなどを経由するプロセス間通信です。

配置方式の比較

Executorは別の設計軸

ノード合成そのものは、スケジューリングやコールバックの実行順序を保証しません。Executor、Callback Group、スレッド数、各コールバックの処理時間が、同一プロセス内の遅延と干渉を左右します。

Single-ThreadedExecutorでは、処理時間の長いコールバックが他の処理に影響する可能性があります。Multi-ThreadedExecutorでは複数スレッドによる並行実行を設計できますが、Callback Groupや共有資源、処理時間を考慮する必要があります。単一プロセス化だけでリアルタイム性が向上すると考えるのは適切ではありません。

使いどころと分割の考え方

カメラ取得、画像前処理、認識のように、同じ高帯域データを連続して処理し、相互の通信量が大きい機能は、同一コンテナへまとめる候補です。Intra-process Communicationにより、プロセス間転送に伴う処理を避けられる可能性があります。

一方、ドライバ、実験的なアルゴリズム、頻繁な再起動が必要なノード、障害時にも動作を継続させたい機能は、別プロセスまたは別コンテナへ分ける判断が考えられます。プロセス分離は障害波及を抑えますが、DDS参加者、共有デバイス、ホスト、外部サービスの障害まで分離するものではありません。監視・再起動機構や共有リソースを含めて、実際の障害範囲を確認します。

制約と採用判断

判断では、まず高帯域データの経路上で通信量の大きい箇所を特定します。次に、Intra-process、loaned message、共有メモリのどれが対象のRMW、QoS、メッセージ型、APIで利用できるかを確認します。そのうえで、一つのプロセスが停止した際に同時停止してよいノードの範囲を決め、Executor、Callback Group、スレッド数を含めてコールバック干渉を設計します。

具体的な遅延削減率、RSS、ピークメモリ、アロケーション回数は、ROS 2ディストリビューション、RMWやDDS実装、CPU、センサーの型、QoS、Executorによって変わります。最終判断には、対象ハードウェアと構成での性能およびクラッシュ時の影響範囲の検証が必要です。

まとめ

Composable NodeとIntra-process Communicationは、大容量データのシリアライズやプロセス間転送を減らす有力な手段です。しかし、メモリ使用量が必ず減るわけではなく、ゼロコピーも一律には保証されません。

採用の基準は、全ノードを一つに集めることではありません。通信量の大きい安定した処理チェーンは合成し、独立再起動や障害分離が必要な機能はプロセス境界の外へ置きます。遅延、メモリ、障害分離、Executorの挙動を同じ設計表で評価し、対象構成で検証することが重要です。

参考情報

• Using ROS 2 components
• Intra-process communication
• About Executors
• Configure Zero Copy loaned messages
• Robot Operating System 2: Design, architecture, and uses

低遅延化の効果と障害分離の範囲は、対象構成ごとに確認したい設計論点です。

AI利用に関する注記

本サイトの記事は、複数のAIエージェントによる調査・執筆・レビューを経て公開しています。正確性と品質の向上に努めていますが、内容については必ず一次情報をご確認ください。