<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>プロセス分離 on Physical AI Hub</title>
    <link>https://physicalaihub.net/tags/%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9%E5%88%86%E9%9B%A2/</link>
    <description>Recent content in プロセス分離 on Physical AI Hub</description>
    <generator>Hugo</generator>
    <language>ja-jp</language>
    <lastBuildDate>Wed, 20 May 2026 08:53:24 +0900</lastBuildDate>
    <atom:link href="https://physicalaihub.net/tags/%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9%E5%88%86%E9%9B%A2/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>ROS 2のノード合成を使い分ける：コンポーネント、ゼロコピー、障害分離の設計</title>
      <link>https://physicalaihub.net/posts/ros2-node-composition-zero-copy-isolation/</link>
      <pubDate>Wed, 20 May 2026 08:53:24 +0900</pubDate>
      <guid>https://physicalaihub.net/posts/ros2-node-composition-zero-copy-isolation/</guid>
      <description>&lt;p&gt;ROS 2の「ゼロコピー」は、配置やミドルウェアの条件を分けて考える必要がある点が気になります。&lt;/p&gt;&#xA;&lt;h2 id=&#34;結論高速化と障害分離は処理チェーンごとに境界を決める&#34;&gt;結論：高速化と障害分離は、処理チェーンごとに境界を決める&lt;/h2&gt;&#xA;&lt;p&gt;ROS 2 Jazzyを前提にすると、カメラ画像やLiDAR点群のような大容量データを連続処理する場合、関連するComposable Nodeを同一プロセスのコンポーネントコンテナへ配置し、Intra-process Communicationを使う構成が有力です。通常のプロセス間DDS通信で必要になるシリアライズや外部トランスポート経由の処理を避けられるため、コピー回数、CPU負荷、通信経路上の待ち時間を減らす方向に働きます。&lt;/p&gt;&#xA;&lt;p&gt;一方、同一プロセス化は障害分離を弱めます。さらに、ゼロコピーは一律に保証されず、メッセージ型、QoS、RMW実装、基盤ミドルウェア、APIの対応状況に左右されます。したがって、通信量の大きい安定した処理チェーンは合成し、実験的なアルゴリズム、頻繁な再起動が必要なノード、障害時にも残したい機能は別プロセスまたは別コンテナへ分ける、という判断が現実的です。&lt;/p&gt;&#xA;&lt;h2 id=&#34;なぜノードの配置が重要なのか&#34;&gt;なぜノードの配置が重要なのか&lt;/h2&gt;&#xA;&lt;p&gt;画像や点群の処理では、センサー取得、前処理、認識、記録など複数のノードがデータを受け渡します。このとき、通信方式や実装に応じた経路・保持領域が関係し、処理段数や購読者数は遅延、CPU負荷、メモリ使用量に影響します。&lt;/p&gt;&#xA;&lt;p&gt;別プロセスに配置したノード間では、通常、ROS 2のDDS/RMW通信経路を通ります。プロセス境界を越えるためのシリアライズやバッファリングが発生しますが、プロセス単位で影響範囲を分けやすい利点があります。逆に、低遅延だけを優先して多数のノードを一つのプロセスへ集約すると、あるノードのクラッシュで同じプロセス内の複数ノードが停止し得ます。&lt;/p&gt;&#xA;&lt;h2 id=&#34;前提となる用語&#34;&gt;前提となる用語&lt;/h2&gt;&#xA;&lt;p&gt;&lt;strong&gt;Composable Node&lt;/strong&gt; は、ノードを共有ライブラリとしてビルドし、コンポーネントコンテナへ動的にロードする仕組みです。複数のノードを同一プロセスで動かせます。&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;Intra-process Communication&lt;/strong&gt; は、同一プロセス内のPublisherとSubscription間で使える通信経路です。通常のプロセス間通信とは異なり、同一プロセス内でメッセージを受け渡し、シリアライズを避けられる場合があります。ただし、別プロセスの購読者へ配信する場合は、DDS経路が必要です。&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;loaned message&lt;/strong&gt; は、PublisherがRMWや基盤ミドルウェアからメモリを借りてメッセージを生成する方式です。同一プロセス内でメッセージの所有権を移動する方式とは異なります。&lt;/p&gt;&#xA;&lt;h2 id=&#34;内部の仕組みとデータ経路&#34;&gt;内部の仕組みとデータ経路&lt;/h2&gt;&#xA;&lt;p&gt;同一コンテナ内のPublisherとSubscriptionでIntra-process Communicationを有効にすると、メッセージは通常のプロセス間DDS経路を通らずに処理されます。その結果、プロセス間転送用のシリアライズ、デシリアライズ、外部トランスポート経由の処理を避けられます。これは遅延とCPU負荷を下げる方向に働きますが、ROS 2全体で共通する削減値が決まっているわけではありません。&lt;/p&gt;&#xA;&lt;p&gt;また、同一プロセス内でもコピーや保持領域が完全になくなるとは限りません。Intra-process Managerの保持領域、QoSの履歴深度、キュー長、購読者数、メッセージの所有権方式によって、メッセージの保持やコピーの挙動が変わります。プロセス間転送用の中間コピーを削減できても、同一プロセス化が常にRSSを減らすとは限りません。&lt;/p&gt;&#xA;&lt;p&gt;「ゼロコピー」を判断する際は、次の経路を区別します。第一は、同一プロセス内でメッセージの所有権を移動する経路です。第二は、RMWや基盤ミドルウェアからメモリを借りるloaned messageです。第三は、共有メモリトランスポートを利用するプロセス間通信です。これらは実装上の条件が異なり、一般に同じ意味でゼロコピーと呼べるわけではありません。第四の通常のシリアライズによるプロセス間通信は、ゼロコピー方式ではなく比較対象です。&lt;/p&gt;&#xA;&lt;p&gt;loaned messageは、RMW実装、基盤ミドルウェア、メッセージ型、Publisher APIが対応している場合に利用できます。条件を満たさなければ、通常のメッセージ確保やコピーへフォールバックします。共有メモリ転送も、実装・設定依存であり、ROS 2アプリケーション全体で自動的に有効になるものではありません。&lt;/p&gt;&#xA;&lt;figure class=&#34;mermaid-figure&#34;&gt;&#xA;    &lt;pre class=&#34;mermaid&#34; role=&#34;img&#34; aria-label=&#34;同一プロセス化ではプロセス間転送を減らせる一方、クラッシュ時の影響範囲が広がり得ます。別プロセス化ではDDS/RMW経路が必要になりますが、障害境界を分けやすくなります。外部プロセスへの配信には、合成構成でもDDS経路が発生します。&#34;&gt;flowchart LR&#xA;  subgraph COMPOSED[&#34;同一プロセスのComposable Container&#34;]&#xA;    C[&#34;カメラ&#34;] --&gt;|&#34;Intra-process経路&#34;| P[&#34;画像前処理&#34;]&#xA;    P --&gt;|&#34;Intra-process経路&#34;| R[&#34;認識&#34;]&#xA;    P -.-&gt;|&#34;外部購読者へはDDS経路&#34;| E[&#34;記録・監視ノード&#34;]&#xA;    C:::inside&#xA;    P:::inside&#xA;    R:::inside&#xA;  end&#xA;&#xA;  subgraph SEPARATED[&#34;別プロセス構成&#34;]&#xA;    C2[&#34;カメラプロセス&#34;] --&gt;|&#34;DDS/RMW&#34;| P2[&#34;前処理プロセス&#34;]&#xA;    P2 --&gt;|&#34;DDS/RMW&#34;| R2[&#34;認識プロセス&#34;]&#xA;    R2 --&gt;|&#34;DDS/RMW&#34;| E2[&#34;記録・監視プロセス&#34;]&#xA;    C2:::process&#xA;    P2:::process&#xA;    R2:::process&#xA;    E2:::process&#xA;  end&#xA;&#xA;  X[&#34;プロセス障害&#34;] -.-&gt;|&#34;同一アドレス空間のノードへ波及し得る&#34;| COMPOSED&#xA;  Y[&#34;プロセス障害&#34;] -.-&gt;|&#34;プロセス単位で影響範囲を分けやすい&#34;| SEPARATED&#xA;&#xA;  classDef inside fill:#e8f3ff,stroke:#3777b8,stroke-width:1px&#xA;  classDef process fill:#f5f5f5,stroke:#666,stroke-width:1px&#xA;  style COMPOSED fill:#f2f8ff,stroke:#3777b8,stroke-width:2px&#xA;  style SEPARATED fill:#fafafa,stroke:#666,stroke-width:2px&lt;/pre&gt;&lt;figcaption&gt;同一プロセス化ではプロセス間転送を減らせる一方、クラッシュ時の影響範囲が広がり得ます。別プロセス化ではDDS/RMW経路が必要になりますが、障害境界を分けやすくなります。外部プロセスへの配信には、合成構成でもDDS経路が発生します。&lt;/figcaption&gt;&lt;/figure&gt;&lt;figure class=&#34;mermaid-figure&#34;&gt;&#xA;    &lt;pre class=&#34;mermaid&#34; role=&#34;img&#34; aria-label=&#34;技術構成図&#34;&gt;graph LR&#xA;  subgraph COMPOSED[同一プロセス：Composable Container]&#xA;    C[カメラ] --&gt; P[前処理]&#xA;    P --&gt; R[認識]&#xA;  end&#xA;  E[記録・監視ノード\n外部プロセス]&#xA;  R --&gt;|DDS/RMW\nプロセス間経路| E&#xA;  P -.-&gt;|Intra-process| R&lt;/pre&gt;&lt;/figure&gt;&lt;p&gt;図では、カメラ、前処理、認識を同一プロセスへ合成し、外部の記録・監視ノードEをプロセス境界の外に置いています。PからEへ出る経路は、同一プロセス内の受け渡しではなく、DDS/RMWなどを経由するプロセス間通信です。&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
