サービスメッシュ

Linkerd りんかーど

サービスメッシュKubernetesマイクロサービスプロキシmTLS可観測性

Linkerdについて教えて

簡単に言うとこんな感じ！

Linkerd（リンカード）は、たくさんの小さなサービスが連携するシステムで「サービス同士の通信を裏でこっそり管理してくれるインフラ」だよ！セキュリティ・監視・信頼性をアプリのコードをいじらずに後付けできちゃうすごいやつなんだ！

Linkerdとは

Linkerd（リンカード） は、Kubernetes上で動くマイクロサービス（小さなサービスを組み合わせて作るシステム設計）環境向けのオープンソースのサービスメッシュです。サービスメッシュとは、マイクロサービス同士の通信を一元的に管理・監視・セキュリティ保護する仕組みのことを指します。2016年にBuoyant社が開発し、CNCFのGraduatedプロジェクト（クラウドネイティブ技術の成熟した標準として認定された最高ランク）として広く使われています。

Linkerdの最大の特徴は「超軽量」であること。Rustで書かれた独自のマイクロプロキシ「Linkerd2-proxy」を採用しており、同種のツールと比べてCPU・メモリ消費が非常に少ない点が評価されています。アプリケーションのサイドカー（各サービスに横付けされる小さなプロキシコンテナ）として動作するため、アプリ本体のコードをまったく変えずに通信の暗号化・ロードバランシング・メトリクス収集などを実現できます。

システム発注や選定をする立場から見ると、「Linkerdを導入すれば開発チームへの追加実装依頼なしに、サービス間通信の安全性と可視性を確保できる」という点が重要です。特にゼロトラストセキュリティ（すべての通信を信頼しない前提で認証・暗号化する考え方）の実現を低コストで目指す組織に向いています。

Linkerdの仕組みと構成要素

Linkerdは大きく3つのコンポーネントで構成されています。

コンポーネント	役割	動作場所
コントロールプレーン	設定管理・証明書発行・ポリシー制御	専用Namespaceで動作
データプレーン（サイドカープロキシ）	実際の通信を横取りして処理	各サービスPodに注入
Linkerd CLI / ダッシュボード	管理・可視化ツール	運用者が操作

具体的な機能一覧：

mTLS（相互TLS認証）の自動化 — サービス間の通信を証明書で双方向に認証・暗号化。コード変更不要
ゴールデンメトリクスの自動収集 — 成功率・レイテンシ・スループットをデフォルトで可視化
HTTPロードバランシング（EWMA） — 応答速度に応じてリクエストを賢く振り分ける
リトライ・タイムアウト制御 — 失敗した通信を自動的にリトライする設定が可能
トラフィックシフト — カナリアデプロイ（新バージョンへの段階的なトラフィック移行）をサポート

覚え方：「リンカード＝つなぐカード」

Link（つなぐ）＋ -erd（ツール的な語尾）で、「サービス同士をつなぐカード（切り札）」と覚えると◎。カードを差し込むだけで通信が安全に管理される、そんなイメージです。

Linkerd1 と Linkerd2 の違い

項目	Linkerd1（旧世代）	Linkerd2（現行）
実装言語	Scala / JVM	Rust（プロキシ）+ Go（コントロール）
対応環境	汎用（DC/OS等）	Kubernetes専用
リソース消費	重い	軽量
現状	非推奨（EOL）	現役・活発開発中

歴史と背景

2016年 — Buoyant社がScala/JVMベースのLinkerd1をリリース。TwitterのFinagleを源流とする。CNCFの最初のプロジェクトの1つとして寄贈される
2018年 — Kubernetes専化・超軽量設計を目指したLinkerd2（旧称Conduit） をBuoyantが発表
2019年 — Linkerd2が正式リリース。Rustベースのサイドカープロキシを採用し軽量化を実現
2021年 — CNCFのGraduatedプロジェクトに昇格。Envoyベースの競合（Istio等）との差別化として「シンプルさ・軽量さ」を強調
2022年〜 — eBPFを活用したサイドカーレス実験（ambient modeのトレンドに対応）を開始
現在 — ライセンス変更（BSL）をめぐるコミュニティ騒動もあったが、OSSとして引き続き開発継続中

マイクロサービスが複雑化するにつれ「サービス間通信の管理が手に負えない」という課題が顕在化。その解決策としてサービスメッシュの概念が生まれ、Linkerdはその先駆けとなりました。

Linkerd vs 主要サービスメッシュ比較

サービスメッシュには複数の選択肢があります。どれを選ぶかは「シンプルさ優先か、機能フルセット優先か」で変わります。

Linkerdが向いているケース

チーム規模が小さく、運用負荷を下げたい
Kubernetesに乗り出したばかりでシンプルに始めたい
リソース（CPU・メモリ）が限られた環境（エッジ・小規模クラスタ）
ゼロトラスト的なサービス間mTLSをすぐに実現したい

規格・RFC番号	内容
RFC 8446	TLS 1.3 — Linkerdのmtls基盤となるトランスポート暗号化プロトコル
RFC 7540	HTTP/2 — Linkerdのプロキシが内部通信で活用するプロトコル
RFC 7235	HTTP認証フレームワーク — サービス間認証の基礎概念