Linkerdとは

サービスメッシュとは

サービスメッシュは、オペレーティングシステム内で情報がどのように移動するかを管理するために使われます。この通信を管理するほかの仕組みとは異なり、サービスメッシュはインフラの明確なレイヤーとしてシェアウェアに組み込まれており、アプリや通信の最適化を助けるために各要素が円滑に連携しているかを認識できます。これにより、フリーウェアが拡張される際のダウンタイムを避けやすくなります。

‍

Linkerdとは

Kubernetes向けに特化した軽量なSidecarで、オープンソースとして公開されています。多くの企業が本番環境で活用しており、PayPalやExpediaなどもその一例です。クラウドネイティブソフトウェアの可用性・安全性・透明性を高め、マイクロサービスのソースコードを変更せずにクラスタ全体の観測性を実現します。

利用者は、システムの応答時間やリクエスト数、成功率などを確認できます。さらに、問題診断のための即時トラフィック解析を提供します。最大の特徴は設定が不要で、すぐに機能し始めることです。Kubernetesとシームレスに連携し、毎秒数千のリクエストを処理できます。

‍

Linkerdのアーキテクチャ

ほかのサービスメッシュと同様に、コントロールプレーン（インジケータープレーン）とデータプレーンを備えています。インジケータープレーンにはメインコントローラ、ユーザー向けの操作画面となるWebコンポーネント、カスタムのPrometheusとGrafanaで構成されるメトリクスコンポーネントが含まれます。これらがサービスメッシュの代理設定を制御し、集めた情報を分析します。データプレーンは、各システムコンテナにSidecarとして配置されるプロキシ群で構成され、システム間の通信を担います。

Linkerdはどのように動くか

Linkerdは単独で動作し、特定の言語やAPIに依存しないため、コンテナやマイクロサービスのアーキテクチャとして利用可能です。一般的にはホスト単位、またはSidecarとして導入されます。

ホスト単位でのデプロイでは、物理サーバーや仮想サーバー1台にLinkerdのインスタンスを1つ導入できます。これにより、そのホストで動作するすべてのフリーウェアシステムへの流入はLinkerdインスタンスへ転送されます。

Sidecarとして導入する場合は、アプリシステムごとにLinkerdインスタンスを配置できます。これはコンテナベースのアプリに便利です。たとえば、DockerコンテナやKubernetesのPodを使うマイクロサービス基盤で利用できます。

1. Linkerdデータプレーン

Linkerdのデータプレーンとなるプロキシコンポーネントは、通常コマンドラインで注入されるため、システムへの追加が容易です。システムを起動してSidecarとしてプロキシコンポーネントを組み込むだけで、サービスはサービスメッシュに参加できます。Linkerdのプロキシコンポーネントは次の機能をサポートします。

• HTTP、HTTP/2、TCP、WebSocketトラフィックの透過的なプロキシ機能
• HTTPおよびTCPの流入に関する統計情報の収集
• HTTPトラフィックに対するレイテンシを考慮したレイヤ7のロードバランシングと、非HTTPトラフィック向けのレイヤ4ロードバランシング
• TLS暗号化による通信を常時守る
• “tap”機能による障害診断

2. Linkerdコントロールプレーン

コントロールプレーンはLinkerdダッシュボード上でプロキシ設定を管理し、データプレーンのメトリクスを収集・集約してAPIやWebポータルを通じて提供します。

興味深いのは、Linkerdのコントロールプレーンを構成するコンテナにも標準でLinkerdのプロキシが含まれており、メッシュ上の他のシステムと同様に管理できる点です。ただし、これはすべてのサービスメッシュで共通しているわけではありません。

‍

オブザーバビリティとLinkerd 

分散システムがもたらす複雑さに対処するには、サービスメッシュを導入すると比較的容易になります。暗号化や“スマート”なルーティング、そして実行時のオブザーバビリティなどの機能によって、これらのアプリを管理しやすくなるからです。

サービスメッシュ自体はオブザーバビリティの三本柱には含まれませんが、保存した情報を活用しやすくする手段として利用できます。Linkerdは小型のオープンソースプログラムで、特定のメッシュを通るすべての呼び出しを追跡・報告できます。その結果、目的の場所へスムーズに到達しやすくなります。

Linkerdのオブザーバビリティ機能

Linkerdのマルチクラスタが備えるオブザーバビリティ機能は主に2つあります。

1. Prometheusメトリクス

Linkerdのプロキシはポート4191で自動的にこれらのメトリクスを公開するため、監視用のサービスを作成するだけでメトリクスを取得できます。Linkerdのプロキシが生成する主なメトリクスは以下のとおりです。

• プロトコルレベルのメトリクス
• ルートメトリクス
• トランスポートレベルのメトリクス
• コントロールプレーンのメトリクス
• TLSの認証情報を報告するIdentityメトリクス

Linkerdに付属するVisualアドオンを使うと、独自のPrometheusインスタンスやGrafanaダッシュボード、Webインターフェースによる詳細な分析が可能です。

2. 分散トレース

Linkerdは、OpenTelemetryの祖先にあたるOpenCensusに対応した分散トレースをサポートしています。OpenCensusではB3がトレーシングに使われます。

貴社のインスツルメンテーションライブラリがB3プロパゲータを使用しており、監視基盤がB3トレーシングコンテキストに対応していることを確認すると、Linkerdのトレーシング機能を有効化できます。Jaeger拡張を導入すれば、バックエンドやインジェクタ、OpenTelemetryコレクタがデプロイされます。すでにJaegerとCollectorが導入済みの場合は、Helmからこれらを除去可能です。

OpenTelemetryを利用する場合、Opencensusのスパンを受け取り、トレースを生成するためにCollectorパイプラインが必要です。すべてのスパンを対応付けるにはB3のトレーシングコンテキストが不可欠です。JaegerはコレクターサービスのURLをすべてのLinkerdプロキシに注入します。

Podを再起動すると、すべてのPodにトレーシング設定が反映されます。Linkerdのトレーシングによって、各プロキシ通信のレイテンシが可視化されます。

‍

Linkerdの利点

Linkerd helm chartの利点をまとめると以下のとおりです。

• オープンソースの Linkerd GitHub
• 活発なコミュニティ
• Istioと並ぶ代表的なサービスメッシュ
• Istioと異なり、Linkerdは設定が不要
• ライブラリや言語に依存しない
• 容易にスケール可能
• HTTP/2やgRPC、その他多くのプロトコルをサポート
• TLSをグローバルに有効
• Linkerdは流入をインテリジェントに振り分ける
• 動的リクエストルーティングでトラフィックを切り替え
• Linkerdの分散トレーシングで問題の原因を特定
• マイクロサービスアーキテクチャを補完
• 堅牢性やオブザーバビリティ、ロードバランシングを提供
• PrometheusとGrafanaを同梱
• Linkerdは即時のUIを提供

‍

LinkerdとIstioの比較

IstioとLinkerdはどちらもSidecarとして動作し、Kubernetes上のアプリの信頼性・セキュリティ・オブザーバビリティを高めることを目指しています。両者ともアプリケーションインスタンスと並行して「Sidecarプロキシ」で機能を提供します。

共通点はありますが、両プロジェクトは大きく異なります。Istioは複雑で、大手ベンダーが推進するプロジェクトです。一方、Linkerdはシンプルさ、効率、ユーザー体験を重視しています。

Linkerdとは異なり、IstioはSidecarに関する多くの課題を一括で解決しようとするため、複雑になっています。

1. Istioのアーキテクチャ

Istioメッシュではデータプレーンとコントロールプレーンが分離されています。

• データプレーン側のSidecarはプロキシとして機能し、マイクロサービス間のWeb接続を管理し、メッシュのトラフィックに関するテレメトリを収集します。
• コントロールプレーンはプロキシのトラフィックルーティングを設定します。

2. ‍Istio vs. Linkerd

両方とも新機能が頻繁に追加されるため、状況は変化する可能性があります。

‍

結論

クラウドネイティブスタックの中心でSidecarが急速に台頭しており、勢いは衰える気配がありません。2017年に初のサービスメッシュとして登場したLinkerdのSidecarは、Microsoft、HP、Lenovo、Nordstromなどの大手企業にも採用され、その利用は増え続けています。Kubernetesを利用しているなら、すぐにオープンソース版を導入でき、数秒でサービスメッシュに触れられます。