サイドカー パターンSidecar pattern

アプリケーションのコンポーネントを別のプロセスまたはコンテナーにデプロイして、分離性とカプセル化を実現します。Deploy components of an application into a separate process or container to provide isolation and encapsulation. このパターンは、種類が異なるコンポーネントとテクノロジでアプリケーションを構成することも可能にします。This pattern can also enable applications to be composed of heterogeneous components and technologies.

このパターンは、オートバイに取り付けられるサイドカーに似ているため、"サイドカー" と名付けられています。This pattern is named Sidecar because it resembles a sidecar attached to a motorcycle. このパターンでは、サイドカーは親アプリケーションに接続され、アプリケーションにサポート機能を提供します。In the pattern, the sidecar is attached to a parent application and provides supporting features for the application. また、サイドカーは、親アプリケーションと同じライフ サイクルを共有し、親アプリケーションと共に作成され、終了します。The sidecar also shares the same lifecycle as the parent application, being created and retired alongside the parent. サイドカー パターンは、サイドキック パターンと呼ばれることもある分解パターンです。The sidecar pattern is sometimes referred to as the sidekick pattern and is a decomposition pattern.

コンテキストと問題Context and Problem

多くの場合、アプリケーションとサービスは、監視、ログ記録、構成、ネットワーク サービスなどの関連する機能を必要とします。Applications and services often require related functionality, such as monitoring, logging, configuration, and networking services. これらの周辺タスクを、独立したコンポーネントまたはサービスとして実装できます。These peripheral tasks can be implemented as separate components or services.

コンポーネントまたはサービスをアプリケーションに緊密に統合すると、アプリケーションと同じプロセスで実行でき、共有リソースを効率的に使用できます。If they are tightly integrated into the application, they can run in the same process as the application, making efficient use of shared resources. ただし、緊密な結合は、十分に分離されていないことも意味し、あるコンポーネントで発生した障害が他のコンポーネントやアプリケーション全体に影響する可能性があります。However, this also means they are not well isolated, and an outage in one of these components can affect other components or the entire application. さらに、通常は、親アプリケーションと同じ言語を使用して実装する必要があります。Also, they usually need to be implemented using the same language as the parent application. その結果、コンポーネントとアプリケーションは、密接に相互依存することになります。As a result, the component and the application have close interdependence on each other.

アプリケーションを複数のサービスに分解すれば、各サービスを異なる言語とテクノロジを使用して構築できます。If the application is decomposed into services, then each service can be built using different languages and technologies. これによって柔軟性は向上しますが、各コンポーネントが独自の依存関係を持つことになり、基になるプラットフォームと親アプリケーションと共有しているリソースにアクセスするには、言語固有のライブラリが必要であることを意味します。While this gives more flexibility, it means that each component has its own dependencies and requires language-specific libraries to access the underlying platform and any resources shared with the parent application. さらに、これらの機能を独立したサービスとしてデプロイすると、アプリケーションに待ち時間が追加される可能性があります。In addition, deploying these features as separate services can add latency to the application. さらに、これらの言語固有のインターフェイスのコードと依存関係の管理が非常に複雑になる可能性があります。これは特にホスト、デプロイ、および管理に当てはまります。Managing the code and dependencies for these language-specific interfaces can also add considerable complexity, especially for hosting, deployment, and management.

解決策Solution

まとまりのあるタスク セットをプライマリ アプリケーションと併置しますが、独自のプロセスまたはコンテナー内にセットを配置して、プラットフォーム サービス用の言語を越えた同種インターフェイスを実現します。Co-locate a cohesive set of tasks with the primary application, but place them inside their own process or container, providing a homogeneous interface for platform services across languages.

サイドカー サービスは、必ずアプリケーションの一部であるわけではありませんが、アプリケーションに接続されます。A sidecar service is not necessarily part of the application, but is connected to it. サイドカー サービスは、常に親アプリケーションの傍に存在します。It goes wherever the parent application goes. サイドカーは、プライマリ アプリケーションと共にデプロイされるサポート プロセスまたはサービスです。Sidecars are supporting processes or services that are deployed with the primary application. オートバイのサイドカーは、1 台のバイクに取り付けられ、オートバイはそれぞれ専用のサイドカーを持つことができます。On a motorcycle, the sidecar is attached to one motorcycle, and each motorcycle can have its own sidecar. 同じように、サイドカー サービスは、その親アプリケーションと運命を共にします。In the same way, a sidecar service shares the fate of its parent application. アプリケーションの各インスタンスにサイドカー インスタンスがデプロイされ、一緒にホストされます。For each instance of the application, an instance of the sidecar is deployed and hosted alongside it.

サイドカー パターンを使用する利点は次のとおりです。Advantages of using a sidecar pattern include:

  • サイドカーは、ランタイム環境とプログラミング言語に関してプライマリ アプリケーションから独立しているため、言語ごとにサイドカーを開発する必要はありません。A sidecar is independent from its primary application in terms of runtime environment and programming language, so you don't need to develop one sidecar per language.

  • サイドカーは、プライマリ アプリケーションと同じリソースにアクセスできます。The sidecar can access the same resources as the primary application. たとえば、サイドカーは、サイドカーとプライマリ アプリケーションの両方で使用されるシステム リソースを監視できます。For example, a sidecar can monitor system resources used by both the sidecar and the primary application.

  • プライマリ アプリケーションに近接しているため、通信時に有意な待ち時間は発生しません。Because of its proximity to the primary application, there’s no significant latency when communicating between them.

  • 拡張メカニズムがないアプリケーションでも、サイドカーを 独自のプロセスとしてプライマリ アプリケーションと同じホストまたはサブコンテナーに接続することで、機能を拡張できます。Even for applications that don’t provide an extensibility mechanism, you can use a sidecar to extend functionality by attaching it as own process in the same host or sub-container as the primary application.

多くの場合、サイドカー パターンはコンテナーで使用され、サイドカー コンテナーまたはサイドキック コンテナーと呼ばれます。The sidecar pattern is often used with containers and referred to as a sidecar container or sidekick container.

問題と注意事項Issues and Considerations

  • サービス、プロセス、またはコンテナーをデプロイするために使用するデプロイとパッケージの形式を検討します。Consider the deployment and packaging format you will use to deploy services, processes, or containers. サイドカー パターンに特に適しているのはコンテナーです。Containers are particularly well suited to the sidecar pattern.
  • サイドカー サービスを設計する際は、プロセス間通信メカニズムを慎重に決定します。When designing a sidecar service, carefully decide on the interprocess communication mechanism. パフォーマンスの要件によって実現が難しい場合を除いて、言語またはフレームワークに依存しないテクノロジを使用するようにします。Try to use language- or framework-agnostic technologies unless performance requirements make that impractical.
  • 機能をサイドカーに配置する前に、独立したサービスまたは従来のデーモンのほうがうまく動作するかどうかを検討します。Before putting functionality into a sidecar, consider whether it would work better as a separate service or a more traditional daemon.
  • さらに、機能をライブラリとして実装できるか、従来の拡張メカニズムを使用して実装できるかを検討します。Also consider whether the functionality could be implemented as a library or using a traditional extension mechanism. 言語固有のライブラリのほうが、より深いレベルで統合され、ネットワークのオーバーヘッドが少ない場合があります。Language-specific libraries may have a deeper level of integration and less network overhead.

このパターンを使用する状況When to Use this Pattern

このパターンは次の状況で使用します。Use this pattern when:

  • プライマリ アプリケーションが、異なる種類の言語とフレームワークのセットを使用している。Your primary application uses a heterogenous set of languages and frameworks. サイドカー サービスに配置されるコンポーネントは、さまざまな言語で記述され、異なるフレームワークを使用しているアプリケーションによって使用できます。A component located in a sidecar service can be consumed by applications written in different languages using different frameworks.
  • コンポーネントが、リモート チームまたは別の組織によって所有されている。A component is owned by a remote team or a different organization.
  • コンポーネントまたは機能を、アプリケーションと同じホストに併置する必要がある。A component or feature must be co-located on the same host as the application
  • メイン アプリケーションの全体的なライフ サイクルを共有するが、別々に更新できるサービスが必要である。You need a service that shares the overall lifecycle of your main application, but can be independently updated.
  • 特定のリソースまたはコンポーネントのリソース制限をきめ細かく制御する必要がある。You need fine-grained control over resource limits for a particular resource or component. たとえば、特定のコンポーネントが使用するメモリの量を制限できます。For example, you may want to restrict the amount of memory a specific component uses. コンポーネントをサイドカーとしてデプロイし、メイン アプリケーションとは別にメモリ使用量を管理できます。You can deploy the component as a sidecar and manage memory usage independently of the main application.

このパターンは次の状況では適切でない可能性があります。This pattern may not be suitable:

  • プロセス間通信を最適化する必要がある。When interprocess communication needs to be optimized. 親アプリケーションとサイドカー サービス間の通信には、オーバーヘッドが含まれています。大きいのは、呼び出し時の待ち時間です。Communication between a parent application and sidecar services includes some overhead, notably latency in the calls. 対話が多いインターフェイスでは、これは容認できるトレードオフではない可能性があります。This may not be an acceptable trade-off for chatty interfaces.
  • 各インスタンスにサイドカー サービスをデプロイするリソース コストと分離によるメリットが釣り合わない小規模なアプリケーション。For small applications where the resource cost of deploying a sidecar service for each instance is not worth the advantage of isolation.
  • サービスのスケールをメイン アプリケーションとは異なるようにするか、メイン アプリケーションと無関係にスケーリングする必要がある。When the service needs to scale differently than or independently from the main applications. この場合は、機能を別のサービスとしてデプロイするほうが適している可能性があります。If so, it may be better to deploy the feature as a separate service.

Example

サイドカー パターンは多くのシナリオに適用できます。The sidecar pattern is applicable to many scenarios. 一般的な例を次に示します。Some common examples:

  • インフラストラクチャ API。Infrastructure API. インフラストラクチャ開発チームは、インフラストラクチャにアクセスするための言語固有のクライアント ライブラリではなく、各アプリケーションと一緒にデプロイされるサービスを作成します。The infrastructure development team creates a service that's deployed alongside each application, instead of a language-specific client library to access the infrastructure. サービスはサイドカーとして読み込まれ、ログ記録、環境データ、構成ストア、検出、正常性チェック、ウォッチドッグ サービスなどのインフラストラクチャ サービス用の共通層を提供します。The service is loaded as a sidecar and provides a common layer for infrastructure services, including logging, environment data, configuration store, discovery, health checks, and watchdog services. さらに、サイドカーは、親アプリケーションのホスト環境とプロセス (またはコンテナー) を監視し、情報を一元的なサービスに記録します。The sidecar also monitors the parent application's host environment and process (or container) and logs the information to a centralized service.
  • NGINX/HAProxy を管理する。Manage NGINX/HAProxy. NGINX と環境の状態を監視するサイドカー サービスをデプロイした後、NGINX 構成ファイルを更新し、状態の変更が必要なときにプロセスをリサイクルします。Deploy NGINX with a sidecar service that monitors environment state, then updates the NGINX configuration file and recycles the process when a change in state is needed.
  • アンバサダー サイドカー。Ambassador sidecar. アンバサダー サービスをサイドカーとしてデプロイします。Deploy an ambassador service as a sidecar. アプリケーションは、要求のログ、ルーティング、回線切断、およびその他の接続関連の機能を処理するアンバサダーを介して呼び出しを行います。The application calls through the ambassador, which handles request logging, routing, circuit breaking, and other connectivity related features.
  • オフロード プロキシ。Offload proxy. node.js サービス インスタンスの前に NGINX プロキシを配置して、サービスの静的ファイルの内容を処理します。Place an NGINX proxy in front of a node.js service instance, to handle serving static file content for the service.