分散システムデザインパターン ―コンテナを使ったスケーラブルなサービスの設計

2章サイドカー

シングルノードパターンの最初は、サイドカーです。サイドカーパターンは、1台のマシン上で動く2つのコンテナから構成されます。1つめはアプリケーションコンテナです。ここにはアプリケーションのコアロジックが含まれています。このコンテナなしには、アプリケーションは存在できません。アプリケーションコンテナに加えて、サイドカーコンテナがあります。サイドカーの役割は、アプリケーションコンテナを拡張したり改善したりすることです。その際、場合によってはサイドカーコンテナはアプリケーションコンテナに関して何も知らないケースもあります。もっと単純に言うなら、サイドカーコンテナは、そのままだと拡張するのが難しいコンテナに、機能を追加するために使われます。サイドカーコンテナは、Kubernetesにおけるpod APIオブジェクトのような、アトミックなコンテナグループを通じて、同じマシン上に割り当てられます。同じマシン上に割り当てられることに加え、アプリケーションコンテナとサイドカーコンテナは、ファイルシステムの一部、ホスト名、ネットワーク、それ以外のネームスペースなど多くのリソースを共有します。一般的なサイドカーパターンは図2-1のようになります。

図2-1　一般的なサイドカーパターン

2.1　サイドカーの例：レガシーサービスのHTTPS対応

例として、レガシーなWebサービスを考えてみましょう。そのサービスが作られた数年前は、会社にとって社内ネットワークのセキュリティの優先順位は高くなかったため、アプリケーションはHTTPSではなく暗号化されていないHTTP経由でサービスを提供していました。セキュリティインシデントが最近発生したことから、その会社はすべてのWebサイトにHTTPSの使用を義務付けました。このWebサービスをアップデートするために派遣されたチームをさらにがっかりさせたのが、アプリケーションのコードがすでに動いていない古い社内ビルドシステムで作られたものだったことでした。このHTTPアプリケーションをコンテナ化するのは簡単です。バイナリは、チームのコンテナオーケストレータ内にある新しいカーネルの上で動く古いカーネル上でも動かせるからです。それに比べて、アプリケーション自体をHTTPS対応するのはずっと難しくなります。チームは、古いビルドシステムを生き返らせるか、アプリケーションのソースコードを新しいビルドシステムに移植するか決断を迫られましたが、その時、チームメンバーの1人がサイドカーパターンを使ってこの問題をもっと簡単に解決できると提案しました。 ...