背景
KubernetesのPodには、マルチコンテナの構成で、サイドカーパターン・アンバサダーパターン・アダプターパターンというコンテナデザインパターンが存在します。ただ、それぞれ具体的にどのような構成のことを指すのか、うまく言語化できない状態だったので、調べてまとめることにしました。
コンテナデザインパターンとは
前述した通り、コンテナデザインパターンには3種類あります。それぞれについて、図を用いて解説します。
解説には、Design patterns for container-based distributed systemsを参考にしています。
サイドカーパターン
サイドカーパターンは、メインのコンテナと、補助的な機能を提供するコンテナで構成されます。
補助的な機能とは、以下の図のような、ログファイルを転送するコンテナ、Gitリポジトリの更新をローカルのストレージに反映するコンテナ、などが該当します。
サイドカーパターンのメリットはいくつかあります。
- メインコンテナには優先的にCPUを割り当て、低レイテンシで応答させることができる
- コンテナはパッケージングの単位なので、コンテナに分けることで、2つのチームに開発の責任を簡単に分担することができ、独立してテストできる
- コンテナは再利用でき、サイドカーコンテナは複数の異なるメインコンテナと組み合わせることができる
- コンテナは障害を封じ込める境界線を提供し、障害がシステム全体に波及することを防ぐことができる
- コンテナはデプロイの単位であり、各機能をアップグレードしたり、必要に応じてロールバックすることができる
これら5つのメリットは、後述する他のコンテナデザインパターンにも当てはまります。
アンバサダーパターン
アンバサダーパターンは、メインのコンテナと、外部システムとの接続を中継するコンテナで構成されます。
例えば、データベースや、S3やGCPなどのオブジェクトストレージと接続するアプリケーションがあるとします。
アンバサダーパターンを用いることなく実装した場合は、接続先の情報を環境変数に設定するなどして、アプリケーションのコンテナから直接接続することが一般的だと思いますが、これではアプリケーションと外部システムの結合度が強くなってしまいます。
しかし、アンバサダーパターンを用いると、その結合度を下げることができます。外部システムと接続するのはアンバサダーコンテナに任せ、アプリケーションのコンテナはlocalhostを指定して、アンバサダーコンテナに接続します。これにより、アプリケーションは環境による差異を考慮する必要がなくなります。
以下の図は、アンバサダーパターンの例です。
アダプターパターン
アダプターパターンは、メインのコンテナと、外部システムからの接続を中継するコンテナで構成されます。
以下の図のような、レガシーアプリケーションを含む複数のアプリケーションのPodに対して、統一されたインターフェースを提供できます。
まとめ
これらのコンテナデザインパターンは、補助的な機能を、組み込み式ではなくコンテナとして提供したり、外部システムとの結合度を下げるために考えられた設計です。アプリケーション開発者とKubernetes管理者の責任の所在が明確になりますし、それぞれがその領域に集中できるので、メリットは大きいと思います。すでにKubernetesを導入している方、または今後導入を検討している方は、開発者と管理者で連携して、これらのコンテナデザインパターンの導入も合わせて検討してみてはいかがでしょうか。