次の方法で共有

サイドカー パターン

アプリケーション コンポーネントをメイン アプリケーションとは別のプロセスまたはコンテナーにデプロイして、分離とカプセル化を提供します。 このパターンを使用すると、さまざまなコンポーネントとテクノロジからアプリケーションを構築できます。

オートバイのサイドカーと同様に、これらのコンポーネントは親アプリケーションにアタッチしてそのライフサイクルを共有するため、それらを一緒に作成して廃止します。 このパターンは サイドキック パターン とも呼ばれ、アプリケーションの分解をサポートします。

コンテキストと問題

多くの場合、アプリケーションとサービスには、監視、ログ記録、構成、ネットワーク サービスなどの関連機能が必要です。 これらの周辺タスクは、個別のコンポーネントまたはサービスとして実装できます。

緊密に統合されたコンポーネントは同じプロセスで実行され、共有リソースを効率的に使用しますが、分離性がありません。 1 つのコンポーネントで停止すると、アプリケーション全体に影響する可能性があります。 また、親アプリケーションの言語での実装も必要です。これによって相互依存関係が作成されます。

アプリケーションをサービスに分解する場合は、異なる言語とテクノロジを使用して各サービスを構築できます。 この方法により、柔軟性が向上します。 ただし、各コンポーネントには独自の依存関係があり、プラットフォームと共有リソースにアクセスするには言語固有のライブラリが必要です。 これらの機能を個別のサービスとしてデプロイすると、待機時間が追加されます。 言語固有のコードと依存関係により、ホスティングとデプロイの複雑さが増します。

解決策

個別のプロセスまたはコンテナーで、プライマリ アプリケーションと共にまとまりのある一連のタスクをデプロイします。 このアプローチでは、複数の言語にわたるプラットフォーム サービスに一貫したインターフェイスが提供されます。

サイドカー パターンを示す図。

サイドカー サービスは、その一部にならずにアプリケーションに接続し、それに沿ってデプロイします。 各アプリケーション インスタンスは、そのライフ サイクルを共有する独自のサイドカー インスタンスを取得します。

サイドカー パターンには、次の利点があります。

  • 言語の独立: サイドカーは、プライマリ アプリケーションのランタイム環境とプログラミング言語とは別に実行されます。 異なる言語で記述されたアプリケーション間で 1 つのサイドカー実装を使用できます。

  • 共有リソース アクセス: サイドカーは、プライマリ アプリケーションと同じリソースにアクセスできます。 たとえば、サイドカーは、両方のコンポーネントが使用するシステム リソースを監視できます。

  • 低待機時間: サイドカーがプライマリ アプリケーションに近接することで、通信の待ち時間が最小限に抑えられます。

  • 拡張機能拡張: サイドカーを別のプロセスとして同じホストまたはサブコンテナーにアタッチすることで、ネイティブ拡張メカニズムがないアプリケーションを拡張できます。

このパターンの最も一般的な実装では、 サイドカー コンテナー または サイドキック コンテナーとも呼ばれるコンテナーが使用されます。

問題と考慮事項

このパターンを実装するときは、次の点を考慮してください。

  • サービス、プロセス、またはコンテナーをデプロイするための展開とパッケージ化の形式を検討します。 コンテナーはサイドカー パターンに適しています。

  • サイドカー サービスを設計するときは、プロセス間通信メカニズムを慎重に選択します。 パフォーマンス要件によってそのアプローチが実用的でない場合を除き、言語に依存しないテクノロジまたはフレームワークに依存しないテクノロジを使用します。

  • サイドカーに機能性を追加する前に、別のサービスとして動作する方が良いか、または従来のデーモンとしての方が良いかを評価してみてください。

  • 機能をライブラリとして実装するか、従来の拡張メカニズムを使用するかを検討します。 言語固有のライブラリを使用すると、統合が深くなり、ネットワークのオーバーヘッドが少なくなります。

このパターンを使用する場合

このパターンは次の状況で使用します。

  • プライマリ アプリケーションでは、さまざまな言語とフレームワークが使用されます。 サイドカーは、言語やフレームワークに関係なく、さまざまなアプリケーションで使用できる一貫したインターフェイスを提供します。

  • 別のチームまたは外部パートナーがコンポーネントを所有しています。

  • アプリケーションと同じホストにコンポーネントまたは機能をデプロイする必要があります。

  • メイン アプリケーションの全体的なライフ サイクルを共有するが、個別に更新できるサービスが必要です。

  • 特定のリソースまたはコンポーネントのリソース制限をきめ細かく制御する必要があります。 たとえば、コンポーネントをサイドカーとしてデプロイして、メイン アプリケーションとは別にメモリ使用量を制限および管理できます。

このパターンは、次の場合に適さない場合があります。

  • プロセス間通信を最適化する必要があります。 サイドカーはオーバーヘッド (特に待機時間) を増やします。これにより、コンポーネント間の通信が頻繁に行われるアプリケーションには適さなくなります。

  • アプリケーションが小さい。 各インスタンスのサイドカーをデプロイするリソース コストが、分離の利点を上回る可能性があります。

  • コンポーネントを個別にスケーリングする必要があります。 コンポーネントをメイン アプリケーションとは異なる方法でスケーリングする必要がある場合は、代わりに別のサービスとしてデプロイします。

  • お使いのプラットフォームには同等の機能があります。 アプリケーション プラットフォームで必要な機能が既にネイティブに提供されている場合、サイドカーは不要な複雑さを増します。

ワークロード設計

ワークロードの設計でサイドカー パターンを使用して、 Azure Well-Architected Framework の柱で説明されている目標と原則に対処する方法を評価します。 次の表は、このパターンが各柱の目標をサポートする方法に関するガイダンスを示しています。

支柱 このパターンが柱の目標をサポートする方法
セキュリティ 設計の決定により、ワークロードのデータとシステムの 機密性、 整合性、 および 可用性 が確保されます。 これらのタスクをカプセル化して別々のプロセスにデプロイすると、攻撃対象領域が必要なコードのみに減ります。 サイドカーを使用して、これらの機能のネイティブ サポートがないアプリケーション コンポーネントにクロスカット セキュリティ コントロールを追加することもできます。

- SE:04 セグメンテーション
- SE:07 暗号化
オペレーショナル エクセレンスは、標準化されたプロセスとチームの凝集によってワークロードの品質を提供するのに役立ちます。 このパターンにより、アプリケーション コードに依存関係を追加することなく、可観測性ツールを柔軟に統合できます。 サイドカーは、アプリケーションとは別に更新および保守できます。

- OE:04 ツールとプロセス
- OE:07 監視システム
パフォーマンス効率 は、スケーリング、データ、およびコードの最適化を通じて、ワークロード の需要を効率的に満たすのに役立ちます。 このパターンを使用すると、複数のアプリケーション インスタンスにまたがってスケールするサイドカーで、共通のタスクを一元化できます。 アプリケーション インスタンスごとに重複する機能をデプロイする必要はありません。

- PE:07 コードとインフラストラクチャ

このパターンによって柱内にトレードオフが生じる場合は、他の柱の目標に照らして検討してください。

例

サイドカー パターンは、多くのシナリオに適用できます。 次の例を考えてみましょう。

  • 依存関係の抽象化: 各アプリケーションと共にカスタム サービスをデプロイし、一貫性のある API を介して共有依存関係機能にアクセスできるようにする。 この方法では、言語固有のクライアント ライブラリが、ログ記録、構成、サービス検出、状態管理、正常性チェックなどの問題を処理するサイドカーに置き換えられます。

    分散アプリケーション ランタイム (Dapr) サイドカーは、このユース ケースを例示しています。

  • サービス メッシュ データ プレーン: 各サービス インスタンスと共にサイドカー プロキシをデプロイして、トラフィック ルーティング、再試行、相互トランスポート層セキュリティ (mTLS)、ポリシーの適用、テレメトリなどのクロスカット ネットワークの問題を処理します。

    Istio などのサービス メッシュでは、サイドカー プロキシを使用して、アプリケーション コードを変更することなくこれらの機能を実装します。

  • アンバサダー サイドカー:アンバサダー サービスをサイドカーとしてデプロイします。 アプリケーションは、要求のログ記録、ルーティング、回線切断、およびその他の接続機能を処理するアンバサダーを介して呼び出しをルーティングします。

  • プロトコル アダプター: 互換性のないプロトコルまたはデータ形式間で変換したり、 メッセージング システムをブリッジしたりするために、サイドカーをデプロイします。 この方法により、アプリケーションでは、より単純なインターフェイスまたはレガシ インターフェイスを使用できます。

  • テレメトリ エンリッチメント: 外部監視システムにデータを転送する前に、メトリック、ログ、トレースなどのテレメトリ データを前処理またはエンリッチするサイドカーをデプロイします。 OpenTelemetry Collector などのコンポーネントは、アプリケーションとは別にテレメトリを正規化、強化、またはルーティングするためのサイドカーとして実行できます。

次のステップ

  • Last updated on