Sidecar構成とは
メインのアプリケーションの横に、補助的な機能を持つ別のプログラムを寄り添わせる仕組み
メリット
開発者は「アプリの機能」に集中できる。
「ログをどう送るか」といったインフラ寄りの悩みはサイドカーに任せれば良い。
GCPにおけるサイドカー構成を、技術的な仕組みと具体的な接続経路に絞って解説します。
サイドカー構成の定義
1つのリソース（Cloud RunのサービスやGKEのPod）の中に、「メインアプリ」と「補助機能」の2つのコンテナを共存させる構成です。これらはネットワーク（localhost）とリソースを共有します。
2. GCPでの具体的な接続フロー（Cloud Run + Cloud SQL）
最も一般的な「Cloud SQL Auth Proxy」をサイドカーとして利用する例です。
table:構成
コンポーネント 役割 通信先
メインコンテナ ビジネスロジックの実行 localhost:3306 (サイドカー) へ出力
サイドカーコンテナ セキュリティ・接続の管理 localhost:3306 で受信し、Cloud SQLへ転送
Cloud SQL データベース サイドカーからのセキュアな通信を受信
通信の仕組み
1. メインコンテナ：データベースの接続先を 127.0.0.1:3306 に設定してリクエストを送信。
2. サイドカーコンテナ：同一ネットワーク内の 3306 ポートでトラフィックを受信し、IAM認証を用いて Cloud SQL への安全なトンネルを確立。
3. 完了：アプリ側は複雑な認証ロジックを実装せずに、DBへの接続が可能になる。
3. 設定ファイルの構造（YAML）
Cloud Run での定義例です。containers 配下に2つのイメージを並列で記述します。
code:yaml
spec:
containers:
# 1. メインアプリケーション
- image: gcr.io/my-project/app:latest
env:
- name: DB_HOST
value: "127.0.0.1"
# 2. サイドカー（Cloud SQL Auth Proxy）
- image: gcr.io/cloud-sql-connectors/cloud-sql-proxy:latest
args:
- "--port=3306"
- "connection-name"
4. 主なユースケース一覧
プロキシ（接続中継）: Cloud SQL Auth Proxy や AlloyDB Proxy による安全なDB接続。
ログ・監視: Fluent bit 等を用いたログの収集と Cloud Logging への転送。
シークレット管理: Secret Manager から取得した機密情報をメインコンテナへ受け渡し。
サービスメッシュ: Istio (Anthos Service Mesh) によるトラフィック制御。
メリット
アプリコードにインフラ依存の処理（認証や暗号化）を含めずに済む。
同じサイドカーイメージを複数の異なるアプリ（Java, Go, Python等）で再利用できる。