サービスメッシュとは（全体像）
最近のアプリは、ひとつの大きなプログラムにせず、役割ごとに小さなサービスに分けて作ることが多い（これをマイクロサービスという）。会員管理・注文・決済……と、それぞれ別々の小さなプログラムにする作り方だ。
すると、サービスの数だけ「サービスどうしの通信」が増える。相手が本物か確かめ、通信を暗号化し、つながらないときに再挑戦し、記録を残す——これを各サービスが自前で全部やるのは大変になる。
そこで登場するのがサービスメッシュ。通信の世話だけを引き受ける専用の層を別に用意して、アプリ本体は「やりたいこと」に集中できるようにする。
詳しく：サイドカーと役割を押さえる
ここが心臓部。サービスメッシュは、サイドカープロキシという方式で動く。
サービスメッシュの仕組みと役割
| 項目 | 内容 |
|---|---|
| 方式 | サイドカープロキシ（各サービスの隣に小さな通信係を配置） |
| ルーティング | どの版へ通信を流すか調整（新版を少しずつ試す「カナリア」など） |
| mTLS（相互TLS） | 通信する両者がお互いに身分を確かめ合い、暗号化する |
| 可観測性 | 通信の様子（速さ・エラー・経路）を見える化する |
| 障害対策 | 再挑戦（リトライ）・時間切れ（タイムアウト）・故障時の遮断（サーキットブレーカ） |
| 代表 | Istio（高機能）／Linkerd（軽量）／AWS App Mesh など |
言葉を噛み砕いておく。
- サイドカープロキシ … バイクの横につける補助席（サイドカー）のように、サービス本体の隣にくっつく通信係。本体の代わりに通信を受け渡す。
- mTLS（相互TLS） … ふつうのTLSは片方（サーバ）だけ身分証を見せるが、mTLSは両者がお互いに見せ合う。なりすましを防げる。
- サーキットブレーカ … 家のブレーカーと同じで、相手が故障していると分かったら通信をいったん遮断して被害が広がるのを止める。
- カナリア … 新しい版を少人数にだけ先に試すこと（昔、炭鉱で異変を知らせたカナリアが由来）。
代表格はIstio（イスティオ）で、Googleなどが作った高機能なもの。Envoyという通信係（プロキシ）を土台にし、それらをまとめて操る司令塔（コントロールプレーン）を持つのが特徴。軽くてシンプルなものならLinkerd（リンカーディー）がある。
わかりやすく言い換えると
つまり、役割ごとに分かれた専門店が集まった商店街をイメージするとラク。
各店（サービス）が、配達・本人確認・記録を自分でやると手が回らない。そこで各店の隣に専属の通信係（サイドカー）を置き、店どうしのやり取りは全部その係に任せる。
商店街全体に張りめぐらされた、この係どうしのネットワークがサービスメッシュ。店主（アプリ本体）は商品づくりに集中でき、安全・記録・障害対策は係がまとめて面倒を見てくれる。
試験のツボ
🔴 一番出る：サイドカープロキシ方式
①各サービスの隣に通信係を置く
②通信機能をアプリ本体から切り離す
🔴 次に出る：おもな役割
①mTLS（相互に身分確認＋暗号化）
②ルーティング・可観測性・障害対策（リトライ・タイムアウト・サーキットブレーカ）
🟡 押さえると安定：代表はIstio（高機能・Envoy基盤）とLinkerd（軽量）
よくある間違い
①「サービスメッシュとKubernetesは同じもの」→ ✗ 別の層。Kubernetesはコンテナを動かす土台で、サービスメッシュはその上で通信を世話するツール。
②「IstioとEnvoyは同じもの」→ ✗ Istioは、通信係のEnvoyに、それらを操る司令塔（コントロールプレーン）を組み合わせた全体のこと。
③「サイドカーを使うとアプリ本体を書き換える必要がある」→ ✗ 本体はいじらず、隣に通信係を足すのが利点。
試験での出題パターン
実際の問題でたしかめてみよう。
オリジナル問題1（サービスメッシュの仕組み）
サービスメッシュに関する次の記述のうち、正しいものはどれか。
- サービスメッシュはアプリ本体に通信処理を直接書き込む方式で、サービスの数が増えるほど本体が複雑になるとされる
- サービスメッシュはデータベースの保存容量を増やすしくみで、サービス間の通信とは関係のない技術である
- サービスメッシュは各サービスの隣に置いた通信係（サイドカー）が、暗号化や記録などの通信の世話を肩代わりする
- サービスメッシュは1台のサーバを複数に見せる仮想化技術で、通信の暗号化や障害対策は対象外とされている
解答は 3 である。
サービスメッシュの肝は、各サービスの隣に置くサイドカープロキシだ。通信の暗号化・記録・障害対策を、この通信係がアプリ本体の代わりに引き受ける。
選択肢1は逆で、本体に直接書き込まずに通信を切り離すのがサービスメッシュの利点。選択肢2の保存容量、選択肢4の仮想化は、どちらも別の技術の説明だ。
| 選択肢 | 判定 | 理由 |
|---|---|---|
| 1 | ✗ | 本体に書かず通信を切り離すのが利点 |
| 2 | ✗ | 保存容量の話で通信とは別 |
| 3 | ✓ | サイドカーが通信の世話を肩代わりする |
| 4 | ✗ | 仮想化の説明で、暗号化も障害対策も担う |
オリジナル問題2（サービスメッシュの役割）
サービスメッシュが担うおもな役割として、正しいものはどれか。
- サービス間の相互認証（mTLS）や暗号化、再挑戦・時間切れ・遮断などの障害対策をまとめて引き受ける
- プログラムの文法ミスを自動で書き直し、ソースコードのバグをすべて取り除く役目を専門に担う
- 紙の書類を電子化して保存し、社員の勤務時間を自動で集計する事務作業を専門に担うしくみである
- パソコンの画面を大きく表示し、文字を読みやすく拡大するためだけにもっぱら使われる表示の補助技術である
解答は 1 だ。
サービスメッシュは、mTLSによる相互認証と暗号化、そしてリトライ・タイムアウト・サーキットブレーカといった障害対策を、通信係がまとめて引き受ける。
選択肢2のバグ取り、選択肢3の事務作業、選択肢4の画面拡大は、いずれもサービスメッシュの役割とは関係がない。
| 選択肢 | 判定 | 理由 |
|---|---|---|
| 1 | ✓ | mTLS・暗号化・障害対策が役割 |
| 2 | ✗ | コードのバグ取りとは別 |
| 3 | ✗ | 事務作業とは無関係 |
| 4 | ✗ | 画面表示の話で別もの |
オリジナル問題3（IstioとKubernetesの関係）
代表的なサービスメッシュに関する次の記述のうち、正しいものはどれか。
- Istioは通信係のEnvoyとまったく同じもので、司令塔（コントロールプレーン）は持たないとされている
- サービスメッシュとKubernetesは完全に同じ技術で、どちらか一方があればもう一方は不要になるとされる
- サービスメッシュを使うには、必ずアプリ本体のプログラムを大きく書き換える必要があるとされている
- Istioは高機能でEnvoyを土台に司令塔を組み合わせたもので、軽量なものとしてLinkerdが知られる
解答は 4 だ。
Istioは、通信係のEnvoyを土台にし、それらを操る司令塔（コントロールプレーン）を組み合わせた高機能なサービスメッシュ。軽量でシンプルなものとしてはLinkerdが知られている。
選択肢1は「Istio＝Envoyで司令塔なし」が誤り。選択肢2のKubernetesは別の層（コンテナを動かす土台）で同じ技術ではない。選択肢3も誤りで、本体を書き換えずにすむのが利点だ。
| 選択肢 | 判定 | 理由 |
|---|---|---|
| 1 | ✗ | Istioは司令塔を持ち、Envoyと同一ではない |
| 2 | ✗ | Kubernetesとは別の層 |
| 3 | ✗ | 本体を書き換えずにすむのが利点 |
| 4 | ✓ | Envoy＋司令塔のIstioと軽量なLinkerdで正しい |
まとめ
押さえどころ
- 🔴 サービスメッシュ ＝ 小さなサービスどうしの通信を世話する裏方の層。本体はいじらない。
- 🔴 サイドカープロキシ ＝ 各サービスの隣に置く通信係。mTLS・ルーティング・可観測性・障害対策を肩代わり。
- 🟡 代表はIstio（高機能・Envoy＋司令塔）とLinkerd（軽量）。Kubernetesとは別の層。
次に学ぶ
- コンテナ・Kubernetes（K8s） ── サービスメッシュが動く土台。コンテナとその管理のしくみを押さえると関係が見える。
- 負荷分散（L4/L7・DSR） ── サービスメッシュのルーティングと並ぶ、通信の振り分けの基本。
- Git・GitHub・CI/CD ── カナリアなどの段階的な公開を支える、開発と配備の自動化のしくみ。
執筆: SikakuQuest編集部