私のリクエストはどのように目的地にたどり着くのか？RouteとEndpointを徹底解説 🚀

私たちがインターネットで買い物をして注文ボタンを押した瞬間、数多くのデータが複雑な道をたどってサーバーまで安全に到着します。まるで宅配便の配達員が私たちの家の住所を正確に探し当てるように！📦

この過程で最も重要な二つの概念が、まさに経路(Route)とエンドポイント(Endpoint)です。多くの方がこれらを別々のものと考えがちですが、実は非常に密接な関係を結んでいます。今日はこの二つの関係をすっきりと解き明かしてみましょう！

🛣️ 経路(Route): 目的地へ向かう高速道路

経路(Route)は、文字通りデータトラフィックがどの「道」をたどるべきかについての規則またはポリシーの集合です。

• 「ユーザーが/loginページをリクエストしたら、『ログイン処理サーバー』に送れ！」
• 「モバイルアプリから来たリクエストは、『v2 APIサーバー』に送れ！」
• 「決済関連リクエストの90%は新規サーバーへ、10%は安定した旧バージョンサーバーへ送ってテストしろ！」

このようにRouteは、交通警察のように入ってくるトラフィックの特性（アドレス、ヘッダー情報など）を見て、どこへ行くべきか方向を指示する役割を果たします。

しかし、Routeはそこまでです。「ログイン処理サーバー」という目的地の「グループ」を教えるだけで、そのグループに属する数多くのサーバーのうち、正確にどのサーバーのどの扉（ポート）に入るべきかは教えてくれません。

まるで「ソウル市江南区」という大きな地域までしか教えてくれないのと同じです。

💡 ポイント: Routeはトラフィックをどこに送るかについての抽象的な「方向」と「規則」です。

🚪 エンドポイント(Endpoint): 最終目的地の玄関

エンドポイント(Endpoint)は、データトラフィックが最終的に到着する実際の目的地です。これ以上進む場所がない道の終わり、つまり通信が終了する地点です。

一般的にIPアドレスとポート(Port)番号の組み合わせで表現されます。

• 10.1.2.3:8080
• 172.16.0.10:3000

先ほどの宅配便の例をもう一度見てみましょう。Routeが「ソウル市江南区」までの経路を教えてくれたとすれば、Endpointは「テヘラン路123番地、45階6号」のような非常に具体的な最終住所です。この住所があってこそ、宅配便の配達員が正確に玄関先まで配達できますよね？

💡 ポイント: Endpointはトラフィックが到達する具体的で物理的な「最終住所」です。

🗺️ 全体像: Routeの終わりには必ずEndpointがある

さて、最も重要な質問にたどり着きました。この二つはどのような関係なのでしょうか？

結論から言えば、エンドポイントは経路の一部であり、経路の最終目的地です。Routeルールがいくら精巧でも、その終わりにトラフィックを受け取るEndpointがなければ何の意味もありません。

全体のプロセスを一度追ってみましょうか？

1. リクエスト発生 📨: ユーザーがhttp://my-service.com/apiというアドレスにリクエストを送ります。
2. ルーター/ゲートウェイ到着 🚦: リクエストはまず、Kubernetes IngressやIstio Gatewayのようなトラフィックの関門に到達します。
3. 経路(Route)ルール確認 📜: ゲートウェイは設定されたRouteルール（例: IstioのVirtualService）を確認します。
• 「ふむ、/apiに来たリクエストだな。このリクエストはapi-serviceに送るように設定されているぞ！」
1. エンドポイント(Endpoint)検索 🏠: 次にシステムはapi-serviceが実際にどこにあるかを探し始めます。Kubernetesはこのサービスに接続されたPodのリスト、つまりEndpointリストを持っています。
• api-serviceのEndpoint: 10.1.2.3:8080, 10.1.2.4:8080, 10.1.2.5:8080
1. 最終トラフィック転送 🚚: ゲートウェイは検索されたEndpointリストの中から一つ（例: 10.1.2.3:8080）を選択し、最終的にトラフィックを転送します。

ご覧の通り、Routeはトラフィックを送る「サービス」を指定する抽象的な道案内役を果たし、その道の終わりには常に具体的な住所であるEndpointが待っています。

---

🤔 よくある誤解: 「RouteとEndpointはただ別物じゃないの？」

多くの方がKubernetesでServiceやIngress（Routeルール）とEndpoints（目的地リスト）を別々のオブジェクトとして管理するため、これらを完全に分離された概念だと考えがちです。

しかし、これは事実ではありません。🙅‍♂️

機能的にこれらは強く結合しています。Routeルールを定義する行為は、結局「どのEndpointにトラフィックを送るか」を決定するための過程です。Routeは「どのように」送るかを定義し、Endpointは「どこに」送るかについての最終的な答えであると言えます。

道（Route）があるのに目的地（Endpoint）がない、あるいは目的地はあるのに道がなければ、何もできないのと同じです。

---

💻 コードで直接確認: Kubernetes & Istioの例

百聞は一見に如かず！実際のコードでどのように動作するか見てみましょう。

1. サービスとエンドポイントの作成（基本）

まず、Kubernetesにmy-apiという名前のサービスをデプロイすると、Kubernetesはこのサービスに接続されたPodのIPとポートを自動的に収集し、Endpointsオブジェクトを作成します。

# my-apiサービスに接続されているエンドポイントリストを確認
kubectl get endpoints my-api

[Raw Data 結果]

NAME     ENDPOINTS                               AGE
my-api   10.1.2.3:8080,10.1.2.4:8080,10.1.2.5:8080   2d

👆 これがまさにトラフィックが最終的に到達できる「実際の住所」リストです。

2. Istio VirtualServiceでRouteルールを定義

次に、IstioのVirtualServiceを使用して複雑なルーティングルールを作成してみましょう。「入ってくるリクエストの90%はv1バージョンへ、10%はv2バージョンへ送れ」というルールです。

# my-api-route.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-api-virtualservice
spec:
  hosts:
  - "my-api.example.com"
  http:
  - route: # 👈 ここが「経路(Route)」ルールです。
    - destination:
        host: my-api-service # 👈 どのサービスに送るか？
        subset: v1           # 👈 そのサービスの「v1」バージョン群へ！
      weight: 90
    - destination:
        host: my-api-service # 👈 どのサービスに送るか？
        subset: v2           # 👈 そのサービスの「v2」バージョン群へ！
      weight: 10

上記のYAMLでhttp.routeセクションがまさに経路です。この経路は「リクエストをmy-api-serviceに送るが、v1とv2のグループに分けて送れ」と指示しています。

そしてIstioは、このv1、v2グループに属するPodの実際のIPアドレス、つまり上で確認したEndpointsリスト（10.1.2.3:8080など）を参照して、最終的にトラフィックを転送します。

結局、VirtualServiceで定義された華やかなRouteルールも、最終的には具体的なEndpointにトラフィックを送るための精巧な案内板に過ぎないのです。

結論

エンドポイントは、トラフィックが転送される経路の核心的な最終構成要素です。

• Route (経路): トラフィックをどこに送るかについてのポリシーと規則（高速道路）
• Endpoint (エンドポイント): トラフィックが最終的に到達する実際の住所（家の玄関）

次にネットワークアーキテクチャを設計したりトラブルシューティングを行う際には、この二つの関係をぜひ覚えておいてください。抽象的な経路規則（Route）と具体的な目的地（Endpoint）を一緒に見つめることで、初めてトラフィック全体の流れを完全に理解できるようになるでしょう！😉

---