サービスディスカバリーにより、サービスはIPアドレスをハードコーディングする代わりに、インスタンスがスケーリングまたは再起動に応じて変わるネットワークロケーションを動的に発見できます。
なぜ重要なのか
クラウドでは、オートスケーリングとフェイルオーバーによってインスタンスは常に現れたり消えたりするため、アドレスは安定していません。サービスレジストリは健全なインスタンスを追跡します。
text
1. Service registers itself ──▶ [ Registry: orders → 10.0.1.7, 10.0.1.9 ]
2. Caller asks registry "where is orders?"
3. Registry returns healthy instances
4. Caller picks one (load-balanced)
クライアント側とサーバー側
| クライアント側 | サーバー側 | |
|---|---|---|
| インスタンス選択 | クライアント | ロードバランサー |
| 例 | Netflix Eureka + Ribbon | AWS ELB、Kubernetes Service |
| クライアント複雑性 | 高い | 低い |
text
Client-side: Caller ─▶ Registry ─▶ pick ─▶ Instance
Server-side: Caller ─▶ Load Balancer ─▶ Instance (LB does the lookup)
落とし穴
レジストリエントリが古いと、トラフィックが停止しているインスタンスにルーティングされます。ヘルスチェックとTTLは、これらを削除するために必須です。
なぜ重要なのか
サービスディスカバリーは、インスタンスが設定を編集することなく現れたり消えたりできるようにする、エラスティックスケーリングを可能にするものです。
KubernetesではDNSとServicesを介して組み込まれているため、ディスカバリーは無料で取得できることが多いです。ただし、ルーティング問題をデバッグするためにはモデルを理解することが重要です。
