サイドカーパターン（共有サービス構成との使い分け）

監視の設計書に「サイドカーは使わない」と書いてあり、サイドカーとは何か、なぜ使わないのかを整理したメモ。
サイドカーは「アプリの横に補助コンテナを1つずつ付ける」構成で、補助の仕事を1か所にまとめる「共有サービス構成」と比べると使い分けが分かりやすい。

結論

• サイドカーは、本体のアプリと同じ実行単位（Amazon ECS なら「タスク」、Kubernetes なら「Pod」）の中で一緒に起動する補助用のコンテナ
• アプリのコードを変えずに、ログ転送・トレース中継・通信の暗号化などの周辺の仕事を横のコンテナに任せるために使う
• アプリと localhost で話せて障害もタスク内で閉じる代わりに、台数・更新・認証情報・リソースがアプリと一緒に増える
• 補助の仕事を独立したサービス1つにまとめる共有サービス構成なら、その逆になる。タスクの中で完結させる必要がなければ共有サービス構成を選ぶ

---

サイドカーとは

本体のアプリと同じ実行単位の中に、一緒に起動させる補助用のコンテナのこと。名前は、バイクの横に取り付ける側車（サイドカー）から来ている。

何のために使うか

アプリのコードを変えずに、周辺の仕事を横のコンテナに任せるために使う。

特徴

• 本体と同じタスクの中にいるので、localhost で通信できる
• 起動・停止・台数の増減が本体と一緒になる。本体を 10 台に増やせば、サイドカーも 10 個になる
• 本体とサイドカーは一緒に動き、一緒に止まる。障害の影響もタスクの中で閉じる

---

図で比べる：サイドカー構成と共有サービス構成

サイドカー構成

タスクごとにサイドカーが付き、それぞれが送信先へ送る。

flowchart LR
    subgraph T1["タスク1"]
        A1["アプリ"] -->|localhost| S1["サイドカー"]
    end
    subgraph T2["タスク2"]
        A2["アプリ"] -->|localhost| S2["サイドカー"]
    end
    S1 --> Dest["送信先"]
    S2 --> Dest

共有サービス構成

補助の仕事をする Collector を独立したサービスとして1つにまとめ、各タスクのアプリはそこへ送る。

flowchart LR
    subgraph T1["タスク1"]
        A1["アプリ"]
    end
    subgraph T2["タスク2"]
        A2["アプリ"]
    end
    A1 --> C["共有 Collector<br/>（独立したサービス）"]
    A2 --> C
    C --> Dest["送信先"]

---

使い分け

タスクの中で完結させる理由（タスク内でのログ収集、localhost 以外への送信禁止など）がなければ、共有サービス構成の方が更新・権限・リソースの面で扱いやすい。

---

実例：トレースの Collector をサイドカーにしなかった設計

あるサービスの監視の設計書では、トレースを送る OpenTelemetry Collector を各タスクに置かず、独立した ECS サービスとして1つにまとめる構成（上の共有サービス構成）を選んでいた。

サイドカーにしなかった理由

• Collector の更新を、アプリのデプロイと切り離せる
• 送信先の認証情報を、アプリのタスクに持たせなくて済む
• CPU・メモリを、アプリの台数分だけ複製しなくて済む
• Collector の台数を、アプリとは別に増減できる

サイドカーを検討し直す条件

設計書には、次のような要件が出てきたらサイドカーを検討し直す、とも書かれていた。

• タスクの中でログを集める必要がある
• localhost 以外への送信を禁止したい
• タスクごとにディスクへ一時保存したい
• 共有 Collector が落ちても、サービスごとに影響を切り離したい

いずれも「タスクの中で完結させたい」要件で、共有サービス構成では満たせないものになっている。

---

ハマりどころ

ECS で localhost が使えるのは awsvpc ネットワークモードのとき

同じタスクのコンテナ同士が localhost で通信できるのは、タスク定義の networkMode が awsvpc のとき。Fargate は awsvpc が必須なので、Fargate なら常に使える。
EC2 上の bridge モードでは、同じタスクのコンテナ同士をつなぐのに links（bridge モード専用の設定）を使う。

ECS の「一緒に止まる」は essential 次第

essential: true のコンテナが止まると、タスク内の他のコンテナもすべて止まる。essential: false のコンテナが止まっても、他のコンテナには影響しない。省略すると true 扱いになる。
サイドカーが落ちたときにアプリまで止めたいかどうかで、サイドカー側の essential を決める。

Kubernetes のサイドカーは initContainers に書く

Kubernetes では、restartPolicy: Always を付けた initContainers の要素がサイドカーになる（v1.28 で導入、v1.33 で Stable）。
停止するときは、本体のコンテナが完全に止まるまでサイドカーの停止を待つので、本体より先にサイドカーが止まることはない。

npm の use-sidecar は別物

npm に use-sidecar という React 向けのパッケージがあり、lockfile を検索すると引っかかることがある。名前が同じだけで、ここで説明したコンテナの構成とは関係ない。

---

参考

• Sidecar Containers | Kubernetes
• Allocate a network interface for an Amazon ECS task（awsvpc ネットワークモード）
• Amazon ECS task definition parameters for Fargate（networkMode・essential・links）
• 関連: AWS + BigQuery マルチクラウド構成