LASSIC Media らしくメディア
サイドカーパターンとは｜共通機能の分離
システム開発の現場では、ログの収集や通信の暗号化、認証といった、どのアプリケーションにも共通して必要になる処理があります。これらを各アプリの内部に一つずつ作り込んでいくと、言語やフレームワークが変わるたびに同じ処理を書き直すことになり、保守の負担も膨らみがちです。複数のチームが別々の言語でサービスを開発している現場ほど、この重複は目立ってきます。複数のプロダクトでログ基盤や認証基盤をそろえたい場合、この重複がそのまま保守工数へ跳ね返ってくるでしょう。
この負担を抑える設計の一つが、サイドカーパターンです。Kubernetesを中心に、ログ収集エージェントやサービスメッシュのプロキシなど、共通機能を担う仕組みとして採用が進んでいます。この記事では、発注担当者やプロジェクトマネージャーに向けて、サイドカーパターンの考え方と、レビューで押さえておきたい観点を整理します。なお、サービスメッシュ製品（Istioなど）の導入詳細については別記事に譲ることとし、本稿ではサイドカーパターンの代表的な応用例としての紹介にとどめる方針です。
この記事のポイント
- サイドカーパターンは、アプリ本体を変えずに通信制御やログ収集などの機能を隣接コンテナへ切り出す設計です。
- ログ管理や認証などの横断的な機能を各アプリへ作り込まず、共通部品として扱えるようになります。
- コンテナ数が増え通信が一段挟まる分、小規模なシステムでは過剰な構成になりやすい点に注意が必要です。
サイドカーパターンとは — 本体に手を入れない機能分離
サイドカーパターンとは、アプリケーション本体には手を入れずに、通信の制御やログ収集などの付随機能を、隣に寄り添う別のコンテナ（サイドカー）へ切り出して任せる設計パターンです。
名前の由来は、オートバイの側面に取り付けるサイドカーにあります*1。本体のオートバイを変えずに、荷物や人を運ぶ機能を横に加えられる関係が、アプリ本体と付随機能の関係になぞらえられているのです。サイドカーはアプリ本体と生成・廃棄のタイミングをそろえて動き、同じホスト上に配置される点が特徴です*1。
このパターンは「サイドキックパターン」とも呼ばれます*1。個々の機能を独立したサービスへ切り出すマイクロサービス化とは異なり、サイドカーはアプリ本体とライフサイクルを共有したまま動く点に違いがあります。機能を単独でスケーリングしたい場合は、サイドカーではなく別サービスとして切り出す方が向いているでしょう*1。
共通機能を切り出す方法は、サイドカーだけではありません。言語ごとのライブラリとして組み込むやり方や、ホスト側に常駐させるプロセス（デーモン）として動かすやり方も選択肢に挙がります*1。統合を深くしてネットワークの負荷を抑えたい場面では、ライブラリとして組み込む方が適することもあり、サイドカーが常に適した選択肢とは限りません*1。この見極めについては、発注・レビューの章で改めて取り上げます。
サイドカーは、一つの塊として作られたアプリケーションを分解していく際の受け皿としても働きます*1。モノリシックなアプリから周辺タスクだけを段階的に切り離していく進め方とも相性がよいでしょう。
なぜアプリ本体と機能を切り分けるのか
ログ記録や監視、通信の制御、設定管理、認証といった処理は、業務ロジックの内容にかかわらず、アプリケーション全般で共通して必要になります*1。これらの周辺タスクを、個別のコンポーネントとして実装できる余地がある点が出発点です*1。
これらをアプリ本体に直接組み込み、同じプロセスで動かすと、共有リソースを効率よく使える一方で、切り分けができません*1。一つのコンポーネントで不具合が起きると、アプリ全体に影響が及びかねない上、実装はアプリ本体の言語に縛られ、相互依存が生まれます*1。
では、機能ごとに別サービスへ切り分ければよいかというと、そう単純でもありません。サービスに分けると、言語やテクノロジを自由に選べます。半面、各コンポーネントが個別の依存関係を抱え、プラットフォームや共有リソースへアクセスするための言語別ライブラリが必要になります*1。別プロセスとして呼び出すたびに待機時間が加わり、ホスティングや配備の複雑さも増していくのです*1。
サイドカーパターンは、この間を取る解決策です。アプリ本体と一体になった一連の周辺タスクを、別のプロセスやコンテナへまとめてデプロイし、複数の言語にまたがる共通インターフェースを提供します*1。認証を例にとると、各アプリが個別に認証ライブラリを抱える代わりに、サイドカーがトークンの検証を代行すれば、アプリ側は検証後の処理だけを書けばよくなります。
この構成が選ばれる理由は、次の4点に整理できます*1。
- 言語の独立：サイドカーはアプリ本体とは別の言語・実行環境で動かせ、異なる言語で書かれた複数のアプリの間でも、同じ実装をそのまま共有できます。
- 共有リソースアクセス：サイドカーはアプリ本体と同じリソースにアクセスでき、両者が使うシステム資源の状態を横断的に見守れます。
- 低い通信の遅れ：アプリ本体のすぐそばに置かれるため、機能を呼び出す際の通信の待ち時間を小さく抑えられます。
- 拡張機構の補完：拡張の仕組みを持たない既存のアプリでも、サイドカーを添えることで機能を補えます。
この4点は、アプリ本体を書き換えずに済むという冒頭の定義と表裏一体の関係にあります。発注担当者としては、委託先が提案する構成がこの4点のどれを主な狙いとしているのかを確認すると、提案の意図をつかみやすくなるでしょう。
| 観点 | 本体に作り込む | サイドカーに分離する |
|---|---|---|
| 保守 | アプリ本体を更新するたびに、周辺処理も併せて見直しが要ります。 変更のたびに動作確認の範囲が広がり、リリースの手間も増えます。 |
サイドカー単体で更新・入れ替えができ、本体への影響を抑えられます。 周辺機能だけを差し替え、アプリ本体は再ビルドせずに済む場合もあります。 |
| 言語依存 | アプリの言語ごとに専用のライブラリを用意する必要があります。 言語やフレームワークを切り替えると、実装を一から見直す負担が生じます。 |
アプリの言語によらず、同じ実装を複数のアプリで使い回せます。 開発チームごとに言語が違っても、共通のサイドカーをそのまま配置できます。 |
| 再利用 | 別アプリで使うには、実装をコピーして移植する手間が生じます。 コピー後は元の実装とずれが生まれ、保守の対象が二重になりがちです。 |
同じサイドカーを、そのまま複数のアプリの横へ配置できます。 設定を変えるだけで、異なるアプリにも展開しやすくなります。 |
表からも分かるとおり、保守・言語依存・再利用のいずれの観点でも、分離した方が変更の影響範囲を狭く保てます。次章では、この分離が実際にどのような場所で採用されているのかを見ていきましょう。
Kubernetesのポッドとサービスメッシュでの使われ方
代表的な採用例の一つが、Kubernetesのポッドです。ポッドはKubernetes（コンテナの実行を自動でまとめて管理するオーケストレーション基盤）における最小の実行単位です。複数のコンテナを一つの単位としてまとめられます*2。Kubernetes v1.29以降では、初期化コンテナに「restartPolicy: Always」を設定できます。この設定によって、サイドカーとして正式に扱われるようになりました*2。
この設定を持つコンテナは、通常の初期化コンテナと違い、ポッドが動いている間は実行され続け、アプリ本体のコンテナと並行して動きます*2。ネットワークやストレージ用のボリュームはアプリ本体のコンテナと共有され、ヘルスチェック（liveness・readinessの各プローブ）にも対応しています*2。同じポッドに収めるだけで、両者が一体として動く関係が作れるわけです。複数の初期化コンテナを並べる場合でも起動の順序は保たれるため、サイドカーを先に準備してからアプリ本体を立ち上げる、といった組み方も可能です*2。
もう一つの代表例が、サービスメッシュのデータプレーンです。サービスメッシュ（マイクロサービス間の通信をまとめて制御する仕組み）では、各サービスの横にプロキシをサイドカーとして配置します。通信経路の制御や再試行、通信の暗号化、通信状況の可視化を担わせる役割です*3。Istioでは、この役割をEnvoyというプロキシが担い、アプリ側のコードを書き換えることなく機能を追加できる点が特徴です*3。プロキシは制御プレーン（Istiod）から設定を受け取り、通信の振る舞いを動的に調整します*3。
このほかにも、サイドカーは複数の役割で応用されています。呼び出し先へのルーティングや接続の異常時の遮断を担う「アンバサダー」としての配置が一例です。異なる通信規格・データ形式を変換する「プロトコルアダプター」としての利用も挙げられます*1。外部の監視基盤へ送る前に、メトリクスやログを整えて送り出す前処理役として配置される例もあります*1。OpenTelemetry Collectorのように、テレメトリの整形・転送だけを担うコンポーネントをサイドカーとして動かす構成が、その代表例です*1。分散アプリケーションランタイムのDaprでは、daprdと呼ばれる独立したプロセスがサイドカーとして動きます。アプリは、ローカルのHTTPまたはgRPCの窓口を通じてこのサイドカーを呼び出します*4。ただし、アプリの起動処理の最中はDaprの機能へアクセスできない制約がある点は押さえておく必要があります*4。
設計の観点では、サイドカーはセキュリティ・運用・性能という3つの柱とも関わってきます*1。関わり方を整理すると、次のようになります。
| 設計の柱 | サイドカーパターンとの関わり |
|---|---|
| セキュリティ | 周辺タスクを別プロセスへ切り出すと、攻撃を受けうる範囲が必要なコードだけに絞られます。 拡張機構を持たないコンポーネントにも、横断的な制御を後から足せます。 |
| 運用 | 可観測性のツールを、アプリのコードに依存関係を足さずに組み込めます。 サイドカー側だけを個別に更新・保守できる点も利点です。 |
| 性能 | 複数のアプリインスタンスにまたがってスケールするサイドカーに、共通処理をまとめられます。 インスタンスごとに機能を重複させずに済みます。 |
利点と注意点
前節ではサイドカーが使われる場所を、本節では実際に採用したときに生じる利点と負担を整理します。
利点は、アプリ本体のコードを汚さずに機能を追加・更新できることです*1。ログ収集や通信制御の仕組みを変えたいときも、アプリを再ビルドせずサイドカーだけを差し替えられます。拡張機構を持たない既存のアプリケーションでも、サイドカーを添えることで機能を補えるのです*1。
一方で、コンテナの数が増えることは避けられません。アプリのインスタンスごとにサイドカーを配置するため、必要なメモリやCPUの総量が増えます。小規模なシステムでは、この資源コストが分離によって得られる利点を上回ってしまう場合があります*1。通信がサイドカー経由で一段挟まる分、応答までの時間が延びる可能性がある点にも注意が要ります*1。サービスメッシュのプロキシも例外ではなく、通信のたびに一段の処理が加わる構成である点は変わりません*3。
加えて、機能をアプリ本体とは別の速さでスケーリングしたい場合は、サイドカーよりも独立したサービスとして切り出す方が適しています*1。基盤側にすでに同等の機能が備わっている場合も、サイドカーを足すことでかえって複雑さが増えるおそれがあります*1。
サイドカーを使うかどうかは、デプロイやパッケージ化の形式を検討する段階で判断しておきたい事項です*1。設計の初期段階でこの判断を先送りにすると、後からサイドカーを組み込む際に通信経路やパッケージ化の形式を選び直す手戻りが生じやすくなります。早い段階で採否を決めておくことが、後工程での手戻りを避ける近道になるでしょう。利点と負担のどちらが上回るかは、システムの規模やチーム構成によって変わるため、次章で挙げる観点に沿って個別に見極める進め方が現実的です。
サイドカーを一から作り込むか、Istioやdaprのような既存の実装を使うかによっても、必要な工数は変わります。既存の実装であれば、通信の暗号化や再試行といった機能をゼロから書かずに済みますが、自社要件に合わせた個別の作り込みには、その分の設計工数が上乗せされるでしょう。通信の遅れが気になる場合は、軽量なプロキシ実装を選ぶ、想定する負荷で事前に計測しておくといった対応で影響を抑えられます。
発注・レビューで押さえる点
分離の要否を規模で判断する
言語やチームが複数にまたがる大きめのシステムほど、共通機能を切り出す効果は実感しやすくなります。逆に、単一のアプリで完結する小規模な構成であれば、サイドカーを足す前にアプリ内での実装や共有ライブラリで十分かを検討する余地が残るでしょう。
企画・要件定義の段階で、対象システムの規模とチーム構成を確認しておくと、後工程での構成見直しを避けやすくなるでしょう。関わる言語の種類やサービスの数を洗い出す作業が、この判断の土台になります。たとえば、一つのアプリを複数言語のチームが分担して開発している場合は、共通機能をサイドカーへ寄せる効果が出やすい場面といえるでしょう。逆に、単一言語・単一チームで完結する社内向けの小さなツールであれば、優先度を下げても差し支えありません。
運用体制の負担を確かめる
サイドカーをコンテナ基盤で動かすには、コンテナイメージの管理やマニフェストの整備、監視対象の増加への対応が伴います。内製でこれらを担うのであれば、次のような知識・体制がそろっているかを確認しておく必要があります。
- Kubernetesのマニフエスト管理・バージョン更新に関する知識
- コンテナイメージのビルド・脆弱性対応を回す運用フロー
- サイドカー追加後の監視項目とログ基盤を統合する設計
担当者が一人しかいない体制では、サイドカーを含む構成変更のたびに作業が特定の個人へ集中し、更新作業が滞る要因になりかねません。
プロセス間通信の方式を確認する
アプリ本体とサイドカーの間でやり取りする通信の仕組みも、レビューで押さえておきたい観点です。パフォーマンス要件が特に厳しい場面を除き、特定の言語やフレームワークに縛られない技術を選ぶことが基本とされています*1。委託先に設計を任せる場合も、この通信方式の選定理由を説明してもらうとよいでしょう。通信の暗号化や認証情報の受け渡しをどう扱うかも、あわせて確認しておきたい点です。サービスメッシュの実装をそのまま使うのか、個別に組み込むのかによって、確認すべき設計書の範囲も変わってきます。
コンテナ基盤の前提を握る（Kubernetes等）
サイドカーパターンは、複数のコンテナを一つの単位でまとめられる基盤があってはじめて成立します。Kubernetesなどのコンテナオーケストレーション基盤を導入していない場合は、サイドカーの検討より前に、基盤そのものの選定・構築が工程として先に必要です。
基盤の選定から自社で進めると、比較検討や検証に相応の期間を要します。コンテナ基盤の導入・運用実績を持つ外部パートナーに相談すると、構成の妥当性を早い段階で確かめながら進められる違いがあります。委託先の実績次第では、要件に見合うサイドカーの規模感を早期に見立ててもらえる場合もあるでしょう。
まとめ
本稿では、サイドカーパターンの定義から使われる場面、利点と注意点、発注・レビューでの着眼点までを整理しました。要点を3つに集約すると、次のとおりです。第一に、サイドカーはアプリ本体を変えずに共通機能を切り出す設計であること。第二に、Kubernetesやサービスメッシュなど、コンテナ基盤を前提にした場面で力を発揮すること。第三に、コンテナ数の増加という負担と見合うかどうかを、規模に応じて判断する必要があることです。発注担当者やプロジェクトマネージャーにとっては、この3点を委託先との会話の共通の物差しとして使えるでしょう。
- サイドカーパターンは、アプリ本体を変えずに通信制御やログ収集などの付随機能を隣接コンテナへ切り出す設計である。
- 共通機能をアプリの言語から独立させられ、複数のアプリで同じ実装を使い回しやすくなる。
- Kubernetesのポッドやサービスメッシュのプロキシ、ログ収集エージェントなどで広く採用されている。
- コンテナ数の増加と通信の一段挟みが伴うため、小規模なシステムでは過剰な構成になりやすい。
- 発注・レビューでは、分離の規模的な必要性と、コンテナ基盤・運用体制の前提を確かめることが要となる。
よくある質問
ここでは、発注担当者やプロジェクトマネージャーからよく寄せられる疑問をまとめます。個別の設計判断に迷う場合は、下記のご相談窓口もあわせてご利用ください。
サイドカーパターンとマイクロサービス化は同じ考え方ですか。
同じ考え方ではありません。マイクロサービス化は機能ごとに独立したサービスへ分割し、個別にスケーリングする設計です。サイドカーパターンは、アプリ本体とライフサイクルを共有したまま、同じホスト上に付随機能を並走させる設計になります。機能を単独でスケーリングしたい場合は、サイドカーではなく別サービスとして切り出す方が向いているでしょう。発注の場面では、提案されている構成がどちらの考え方に基づくのかを確認しておくと、後の認識違いを防げます。
サービスメッシュを導入すれば、自動でサイドカーパターンになりますか。
サービスメッシュの実装の多くは、サイドカーパターンを使って通信制御を実現しています。各サービスの横にプロキシをサイドカーとして配置し、通信経路の制御や暗号化、再試行などを担わせる仕組みです。ただし、サービスメッシュの導入自体には別途の設計・検証が伴うため、本稿ではサイドカーの代表的な応用例として触れるにとどめています。導入を検討する際は、サイドカーの仕組みとサービスメッシュ製品固有の設定を切り分けて理解しておくと、レビューの見通しがよくなります。
小規模なシステムでも導入したほうがよいですか。
小規模な構成では、導入を急ぐ必要はないでしょう。サイドカーを足すとコンテナの数が増え、必要な資源も増えます。単一のアプリで完結する規模であれば、アプリ内で共通処理を実装しても保守の負担はさほど大きくなりません。チームや言語が複数にまたがる規模になった段階で、改めて検討する進め方が現実的です。
サイドカーどうしの通信は暗号化されますか。
暗号化の有無は、採用する実装によって変わります。Istioが代表するサービスメッシュのプロキシでは、サービス間の通信を相互TLS（mTLS）で暗号化する機能が提供されています*3。個別に組んだサイドカーで同等の機能を持たせるかどうかは、設計時に別途確認しておく必要があるでしょう。
サイドカーを使うにはコンテナ基盤が必須ですか。
Kubernetesなど、複数のコンテナを一つの単位でまとめられる基盤が前提になります。基盤を導入していない場合は、サイドカーの検討よりも先に、コンテナオーケストレーション基盤そのものの選定・構築が工程として必要です。基盤の有無を確認したうえで、導入の順番を組み立てるとよいでしょう。基盤の構築とサイドカーの設計を同時並行で進めると、手戻りが起きやすくなります。
サイドカーの導入にかかる費用感を教えてください。
必要な費用は、コンテナ基盤の有無や既存実装（Istio・dapr等）を使うかどうかによって大きく変わるため、一概には示せません。すでにKubernetes基盤があり既存実装を組み合わせる場合と、基盤の構築から個別に作り込む場合とでは、必要な工数の幅も異なります。まずは対象システムの構成を整理したうえで、個別に見積もりを取る進め方が現実的です。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
出典
- *1 出典：Microsoft Learn「サイドカー パターン」（Azure Architecture Center）
- *2 出典：Kubernetes公式ドキュメント「Sidecar Containers」
- *3 出典：Istio公式ドキュメント「Istio Architecture」
- *4 出典：Dapr公式ドキュメント「The Dapr sidecar」
