サービスディスカバリ（Service Discovery、サービス検出AWS ECS Docs/service-discovery）はサービスのインスタンスがもつネットワーク上の位置を決定することであるWhen using client‑side discovery, the client is responsible for determining the network locations of available service instances enginx。
概要 プログラムからサービスを利用する際、ドメイン名などのサービス識別子からIPアドレスなどの実サーバ接続情報を明示的/暗示的に得る必要がある。このサービス識別子-サービス実体間参照解決をサービスディスカバリという。固有の（変化しない）サービス識別子を用いて（変化しやすい）サービス実体を参照することで、安定したサービスへのアクセス・容易なサービス実体の変更が可能になる。Domain Name Systemはサービスドメイン名-サーバーIPアドレスの解決による古典的なサービスディスカバリ手法である。
サービスを提供するサーバーが安定したIPアドレスを持つ場合、サービス利用者はサーバーIPアドレスをハードコードするだけで安定したサービスディスカバリが可能であるIn a traditional application running on physical hardware, the network locations of service instances are relatively static. For example, your code can read the network locations from a configuration file that is occasionally updated. enginx。しかしクラウドコンピューティング・Dockerコンテナ等の登場により、サーバーが頻繁に生成破棄されまた単一のサーバーではなくサーバークラスタがスケーリングしながらサービス提供するケースが増えてきた。結果としてサービスのIPアドレスは動的に割り当てられ頻繁に変更されやすく、かつ一意のIPアドレスにはならなくなっているService instances have dynamically assigned network locations. Moreover, the set of service instances changes dynamically because of autoscaling, failures, and upgrades. enginx。そのためハードコードされたネットワーク位置ではなく利用時に実体参照を解決するサービスディスカバリの必要性がでてきた。
要件 サービスディスカバリに求められる特性の例を以下に挙げる。
サービス死活監視: 機能していないサービスへはルーティングしない ネットワーク位置集約: 複数インスタンス候補からの選別 可用性: 単一障害点になりうるゆえの高い安定性
手法 以下はサービスディスカバリに用いられる手法である。
DNSラウンドロビン: ドメイン名 - サーバークラスタ中のIPアドレス
Service Registry サービスレジストリはサービス・サービスインスタンス・サービス位置の保管庫でありImplement a service registry, which is a database of services, their instances and their locations. Microservice Architecture、サービスディスカバリに利用されるパターンの一種である。サービス解決に必要な情報をレジストリを集約しアクセスすることでサービスディスカバリを可能にする。レジストリの異常動作はサービスディスカバリ自体の異常動作を招く（単一障害点である）ので、etcdをはじめとした分散ストアなど、非常に高い可用性をもったレジストリ実装が求められるOther examples of service registries (or technologies that are commonly used as service registries) include: Apache Zookeeper Consul Etcd ... (中略) ... the service registry must be highly available. Microservice Architecture。
要素技術 以下はサービスディスカバリを実現するために利用される要素技術の例である。
Domain Name System: ドメイン名 - IPアドレス ロードバランサ: バランサIPアドレス - サーバークラスタ中のIPアドレス プロキシ
実装例 コンテナ コンテナの集合でアプリケーションを構成する場合、不安定なコンテナIPアドレスに対処するためにコンテナサービスディスカバリが必要になる。コンテナエンジンやコンテナオーケストレーターはサービスディスカバリ機能を提供している。 +表: コンテナサービスディスカバリプラットフォーム識別子識別子例負荷分散方式Dockerエンジンコンテナ名, AliascontainerA✔コンテナIP-コンテナ名 DNS (with ラウンドロビン)Docker-ComposeService名serviceB✔コンテナIP-Service名 DNS (with ラウンドロビン)KubernetesService名serviceB.namespaceX✔ServiceプロキシIP-Service名 DNS + Serviceプロキシ-コンテナ負荷分散AWS ECSService名serviceB.namespaceX✔コンテナIP-Service名 DNS (with ラウンドロビン) Dockerエンジンはコンテナに対するDNSでサービスディスカバリを実現している。BridgeネットワークドライバがDNSを内蔵しており、コンテナ名およびエイリアス名をドメイン名とするDNSでルーティングしている（c.f. Docker#技術的な特徴 - ネットワーク）。Docker-ComposeではService名を生成コンテナ名相当としてBridgeネットワークによるDNSでルーティングをおこなっている。
Kubernetesではコンテナセットプロキシに対するDNSでサービスディスカバリを実現しているユーザーはアドオンを使ってKubernetesクラスターにDNS Serviceをセットアップできます(常にセットアップすべきです)。 kubernetes docs - Service。k8sではコンテナ群に対応しロードバランシングをおこなうプロキシとしてServiceを定義している。Serviceは論理的な存在であり仮想IPアドレスは安定しているため、サーバー死活とDNSに関わる問題を避けられるkubernetes docs - Service - なぜ、DNSラウンドロビンを使わないのでしょうか。。この背景に基づいてk8sではServiceに対するサービスディスカバリを提供している。
AWSのマネージドコンテナオーケストレーションである Amazon Elastic Container Service (ECS) ではコンテナに対するDNSでサービスディスカバリを実現している。ECSではコンテナ群に対応するServiceを定義しているAmazon ECS allows you to run and maintain a specified number of instances of a task definition simultaneously in an Amazon ECS cluster. This is called a service. AWS ECS docs - Services。Amazon ECS service discovery はServiceに所属するコンテナのプライベートIPアドレスと死活を管理してRoute53 DNSへService名をドメイン名として自動登録する。これによりアプリケーション内部におけるサービスディスカバリを提供しているService discovery uses Amazon Route 53 auto naming APIs to manage DNS entries for your service's tasks, making them discoverable within your VPC. AWS ECS docs - Services。
脚注
関連項目 セマンティックウェブ DNSラウンドロビン
外部リンク Service Discovery S-Cube Knowledge Model Dong, H., Hussain, F.K., Chang, E.: Semantic Web Service matchmakers: State of the art and challenges[Online]. Concurrency and Computation: Practice and Experience 25(7) (May 2013) pp. 961-988. Accessed on June 16, 2015. Sun, L., Dong, H., Hussain, F.K., Hussain, O.K., Chang, E.: Cloud service selection: State-of-the-art and future research directions. Journal of Network and Computer Applications[Online] 45 (October 2014) pp. 134-150. Date accessed: 16 June 2015.