Kubernetesパターン 第2版 ―クラウドネイティブアプリケーションのための再利用可能パターン

18章Ambassador（アンバサダ）

Ambassador（アンバサダ）パターンは、外部の複雑性を隠蔽し、Podの外側のサービスへアクセスする際の統一的なインタフェイスを提供する役割に特化したサイドカーです。この章では、Ambassadorパターンがプロキシとして動作し、外部の依存先への直接アクセスをメインコンテナから分離する仕組みを見ていきます。

18.1　問題

コンテナ化されたサービスは別々に存在するのではなく、場合によっては信頼性の高い方法で到達するのが難しい別サービスにアクセスせざるを得ないこともよくあります。他のサービスへのアクセスの難しさは、動的で変化するアドレス、クラスタ化されたサービスインスタンスへのロードバランシングの必要性、信頼性の低いプロトコル、難しいデータフォーマットなどの理由から発生します。コンテナは単一の目的を持ち、さまざまなコンテキストにおいて再利用可能であるのが理想的です。しかし何らかのビジネス機能を提供し、外部サービスを特別な方法で利用するコンテナがある場合、コンテナは1つ以上の責任を持つことになります。

外部サービスの利用には、コンテナに入れるのは避けたい特別なサービスディスカバリライブラリが必要な場合があります。あるいは、別々の種類のサービスディスカバリライブラリや手法を使うことで、サービスを切り替えたいかもしれません。外部の他サービスにアクセスするロジックを抽象化し分離する方法こそが、Ambassadorパターンの目的です。

18.2　解決策

このパターンを実際に示す例として、アプリケーションのキャッシュがあります。開発環境においてローカルキャッシュにアクセスするなら設定は単純かもしれませんが、本番環境では、キャッシュの別シャードに接続できるクライアント設定が必要な場合もあるはずです。別の例として、レジストリからサービスを見つけ、クライアントサイドのサービスディスカバリを行うことでそのサービスを利用するケースがあります。また3つめの例としては、HTTPのような信頼性の低いプロトコルを通じてサービスを利用する際、アプリケーションを保護するためサーキットブレーカロジックを使用したり、タイムアウトを設定したり、リトライを実行するなどの場合があります。 ...