サイドカー

概要

サイドカーは、アプリケーション本体の隣に補助的なプロセスを「並走」させ、ログ収集・通信の代理・証明書の更新といった共通機能を後付けするデザインパターンです。名前の由来はバイクの側車（サイドカー）で、本体とは別の車体でありながら同じ道を同じ速度で走る — アプリとは別のコンテナでありながら、同じライフサイクルを共にする関係をよく表しています。

実際の姿としては、Kubernetes の Pod（複数コンテナをまとめる最小デプロイ単位）の中に、アプリ用コンテナと補助用コンテナを同居させる形が典型です。同じ Pod 内のコンテナはネットワークとストレージの一部を共有するため、サイドカーは localhost 越しにアプリと会話し、同じボリュームのログファイルを読めます。アプリからは「すぐ隣にいる小さな相棒」であり、コードを1行も変えずに機能を足せるのがこのパターンの魅力です。

なぜ生まれたか

マイクロサービスの時代になると、すべてのサービスに共通で必要な機能 — リトライ、タイムアウト、ログ転送、TLS の証明書管理、メトリクスの出力など — をどう配るかが問題になりました。素朴な答えは「共通ライブラリを作って各サービスに組み込む」ですが、サービスが Go・Java・Python・Node.js と多言語で書かれていると、同じ機能を言語ごとに再実装し、言語ごとにバグを直し、全サービスにバージョンアップを行き渡らせる必要があります。ライブラリの更新は各チームの再ビルド・再デプロイ待ちになり、「全サービスの半分だけ古い実装が残っている」状態が常態化します。

サイドカーはこの「言語ごとのライブラリ地獄」を、プロセス分離という発想で断ち切りました。共通機能を独立したプロセス（コンテナ）に切り出して隣に置けば、アプリが何語で書かれていても localhost の通信さえできれば機能を使えます。実装は1つ、更新はサイドカーのイメージ差し替えだけ。ライブラリの「組み込む」から、インフラの「添える」への転換です。

詳細

Pod 内で何を共有しているか

Kubernetes の Pod では、同居するコンテナ群が同じネットワーク名前空間を共有します。つまりサイドカーとアプリは同じ IP アドレスを持ち、互いに localhost で到達できます。さらにボリュームをマウントし合えばファイルも共有できます。一方でファイルシステム本体やプロセス空間は分かれているため、依存関係やランタイムは汚染し合いません。「近さは localhost、独立性はコンテナ」という絶妙な距離感が、このパターンの土台です。

代表的な使い道

サイドカーの代表例は大きく3つあります。1つ目はログ・メトリクス収集で、アプリが書き出したログファイルを Fluentd や Fluent Bit のようなエージェントが読み取り、集約基盤へ転送します。アプリは「ローカルに書くだけ」でよく、転送先の変更にも無関係でいられます。2つ目はネットワークプロキシで、アプリの送受信をすべてサイドカー（Envoy が代表格）が仲介し、mTLS による暗号化、リトライやサーキットブレーカー、分散トレーシング用のヘッダ付与などを肩代わりします。この形を全サービスに展開したものがサービスメッシュで、サイドカーパターンの最大の応用先です。3つ目は証明書やシークレットの取得・更新で、Vault Agent のようなサイドカーが定期的に新しい認証情報を取得し、共有ボリューム経由でアプリに渡します。

落とし穴 — リソースと起動順序

便利な一方で、代償も明確です。まずリソースのオーバーヘッド。サイドカーは Pod の数だけ増えるため、1つあたり数十〜数百 MB のメモリでも、1,000 Pod あれば無視できない総量になります。プロキシ型なら通信のたびに 1〜数ミリ秒のレイテンシも上乗せされます。

次に起動・終了の順序問題です。プロキシ型サイドカーの準備が整う前にアプリが外部と通信しようとして失敗する、逆に終了時にサイドカーが先に落ちてアプリの最後のリクエストが宙に浮く、バッチ Job ではアプリが終わってもサイドカーが生き続けて Job が完了しない — いずれも現場で頻発した古典的な悩みでした。Kubernetes 1.28 以降はネイティブサイドカー（init コンテナに restartPolicy: Always を指定する方式）が導入され、「アプリより先に起動し、アプリより後に終了する」というライフサイクルをプラットフォーム側が保証できるようになり、この種の問題は大きく改善されています。

採用判断の軸はシンプルで、「その機能は言語をまたいで共通か」「アプリと同じ頻度で更新したいか」です。単一言語の小さなチームなら普通のライブラリで十分なことも多く、サイドカーはあくまで多言語・多サービスの規模で効いてくるパターンだと覚えておくとよいでしょう。