サービスディスカバリ

サービスディスカバリ（Service Discovery、サービス検出）はサービスのインスタンスがもつネットワーク上の位置を決定することである。 
概要.
プログラムからサービスを利用する際、ドメイン名などのサービス識別子からIPアドレスなどの実サーバ接続情報を明示的/暗示的に得る必要がある。このサービス識別子-サービス実体間参照解決をサービスディスカバリという。固有の（変化しない）サービス識別子を用いて（変化しやすい）サービス実体を参照することで、安定したサービスへのアクセス・容易なサービス実体の変更が可能になる。Domain Name Systemはサービスドメイン名-サーバーIPアドレスの解決による古典的なサービスディスカバリ手法である。
サービスを提供するサーバーが安定したIPアドレスを持つ場合、サービス利用者はサーバーIPアドレスをハードコードするだけで安定したサービスディスカバリが可能である。しかしクラウドコンピューティング・Dockerコンテナ等の登場により、サーバーが頻繁に生成破棄されまた単一のサーバーではなくサーバークラスタがスケーリングしながらサービス提供するケースが増えてきた。結果としてサービスのIPアドレスは動的に割り当てられ頻繁に変更されやすく、かつ一意のIPアドレスにはならなくなっている。そのためハードコードされたネットワーク位置ではなく利用時に実体参照を解決するサービスディスカバリの必要性がでてきた。
要件.
サービスディスカバリに求められる特性の例を以下に挙げる。
手法.
以下はサービスディスカバリに用いられる手法である。
Service Registry.
サービスレジストリはサービス・サービスインスタンス・サービス位置の保管庫であり、サービスディスカバリに利用されるパターンの一種である。サービス解決に必要な情報をレジストリを集約しアクセスすることでサービスディスカバリを可能にする。レジストリの異常動作はサービスディスカバリ自体の異常動作を招く（単一障害点である）ので、etcdをはじめとした分散ストアなど、非常に高い可用性をもったレジストリ実装が求められる。
要素技術.
以下はサービスディスカバリを実現するために利用される要素技術の例である。
実装例.
コンテナ.
コンテナの集合でアプリケーションを構成する場合、不安定なコンテナIPアドレスに対処するためにコンテナサービスディスカバリが必要になる。コンテナエンジンやコンテナオーケストレーターはサービスディスカバリ機能を提供している。
Dockerエンジンはコンテナに対するDNSでサービスディスカバリを実現している。BridgeネットワークドライバがDNSを内蔵しており、コンテナ名およびエイリアス名をドメイン名とするDNSでルーティングしている（c.f. Docker#技術的な特徴 - ネットワーク）。Docker-ComposeではService名を生成コンテナ名相当としてBridgeネットワークによるDNSでルーティングをおこなっている。
Kubernetesではコンテナセットプロキシに対するDNSでサービスディスカバリを実現している。k8sではコンテナ群に対応しロードバランシングをおこなうプロキシとして"Service"を定義している。"Service"は論理的な存在であり仮想IPアドレスは安定しているため、サーバー死活とDNSに関わる問題を避けられる。この背景に基づいてk8sでは"Service"に対するサービスディスカバリを提供している。
AWSのマネージドコンテナオーケストレーションである Amazon Elastic Container Service (ECS) ではコンテナに対するDNSでサービスディスカバリを実現している。ECSではコンテナ群に対応する"Service"を定義している。"Amazon ECS service discovery" はServiceに所属するコンテナのプライベートIPアドレスと死活を管理してRoute53 DNSへ"Service"名をドメイン名として自動登録する。これによりアプリケーション内部におけるサービスディスカバリを提供している。