はじめに
この連載ではコンテナとコンテナオーケストレーションを使用した分散システムの設計パターンについてまとめていきます。
今回はサイドカーについて学びます。 (分散じゃないです)
連載記事一覧
サイドカーパターンとは
サイドカーパターンは前回学習したシングルノードパターンに分類されます。
1台のマシン上で動く2つのコンテナから構成され、
- 1つめはアプリケーションコンテナ
- ２つ目はサイドカーコンテナ
があります。
サイドカーの役割はアプリケーションコンテナを拡張したり改善したりすることです。 そのままだと拡張するのが難しいコンテナに機能を追加するために使われます
サイドカーコンテナはKuberbatesにおけるPodのように、コンテナグループを通じて同じアプリケーションコンテナと同じマシン上に割り当てられ、ファイルシステムの一部・ホスト名・ネットワークなど多くのリソースを共有します。
サイドカーの例 : レガシーサービスのHTTPS対応
レガシーサービスのアプリケーションがその古さ故にHTTPS化が難しい場合、サイドカーコンテナを使用してサービスの HTTPS化に対応することが可能です。
まず、レガシーサービスをローカルホストのみにサービスを提供するように設定、つまり外部から誰もアクセスできないようにします。
次にnginxのサイドカーコンテナをアプリケーションと同じネットワークネームスペースに配置し、ローカルホスト上で動くアプリケーションにアクセスできるようにします。
nginxが外部IPアドレスからの HTTPSトラフィックを終端できるようにし、「nginx - レガシアプリ」通信は引き続きHTTPで通信します。
このように、サイドカーパターンを使用して、レガシーアプリケーションを作り直すことなく HTTPS をサポートするようモダンにサービス対応することができるようになりました。
サイドカーによる動的な設定
トラフィックのプロキシ以外で、サイドカーパターンのよくある活用方法として設定の同期に使う例があります。
設定の読み出しに関して、従来はローカルマシンからXMLやJSONやYAMLを読み出すのが一般的でしたが、最近のクラウドネイティブな環境では設定の更新にAPIを使用するのが便利です。
API経由にすることによって設定の変更を簡単に行えるようになることに加え、安全にロールバックを行うことも可能です。
が、レガシーアプリが最新のクラウドAPIやSaasと動的に疎通を行うように改修するのは、ライブラリの対応バージョンなどの要因で難しくなっているというのが実情です。
そこでアプリケーションコンテナとは別に設定マネージャーコンテナを配置し、お互いがディレクトリを共有できる共通のコンテナグループにグループ化させます。
この共有ディレクトリが設定ファイルを保持する場所です。
設定マネージャーが起動すると設定APIを確認して、APIで得られる設定とローカルファイルシステム上の設定の差分を探します。
差分があった場合、設定マネージャーはファイルシステムに設定を更新し、新しい設定ファイルで再設定を行うよう、レガシーアプリケーションに通知を送ります。
このケースもサイドカーパターンが既存レガシーアプリケーションをよりクラウドネイティブな環境に適応させられる良い例になっています。
モジュール化されたアプリケーションコンテナ
以上にあげた例はどれもレガシーアプリケーションに変更を加えないことを主旨としたケースでした。
サイドカーパターンのその他の利点としてサイドカーコンポーネントのモジュール化と再利用性があります。
例えば調査やデバッグ目的で、topコマンドのような、アプリケーションを実行しているホストのプロセスや各種メトリクスを提供する機能をAPIとして用意したいケースがあります。
このような場合、各アプリケーションにHTTPのhttp://xxxxxx.com/topのようなAPIないしインターフェースを用意し、ここでリソースの状況を出力することが考えられます。
しかし、多様な言語で構築されうる各種サービスに独自に/topインターフェースを実行するのは効率的ではありませんし、実装ごとに言語や使用フレームワークの違いに起因する機能差異が生まれる可能性もあります。
このような場合/topインターフェースで適用する機能をtopコンテナとして別途モジュール化すれば、一貫したインターフェースや機能を提供することができます。
