Wikipedia

サービスディスカバリ

サービスディスカバリ（Service Discovery、サービス検出[1]）はサービスのインスタンスがもつネットワーク上の位置を決定することである[2]。

概要 編集

プログラムからサービスを利用する際、ドメイン名などのサービス識別子からIPアドレスなどの実サーバ接続情報を明示的/暗示的に得る必要がある。このサービス識別子-サービス実体間参照解決をサービスディスカバリという。固有の（変化しない）サービス識別子を用いて（変化しやすい）サービス実体を参照することで、安定したサービスへのアクセス・容易なサービス実体の変更が可能になる。Domain Name Systemはサービスドメイン名-サーバーIPアドレスの解決による古典的なサービスディスカバリ手法である。

サービスを提供するサーバーが安定したIPアドレスを持つ場合、サービス利用者はサーバーIPアドレスをハードコードするだけで安定したサービスディスカバリが可能である[3]。しかしクラウドコンピューティング・Dockerコンテナ等の登場により、サーバーが頻繁に生成破棄されまた単一のサーバーではなくサーバークラスタがスケーリングしながらサービス提供するケースが増えてきた。結果としてサービスのIPアドレスは動的に割り当てられ頻繁に変更されやすく、かつ一意のIPアドレスにはならなくなっている[4]。そのためハードコードされたネットワーク位置ではなく利用時に実体参照を解決するサービスディスカバリの必要性がでてきた。

要件 編集

サービスディスカバリに求められる特性の例を以下に挙げる。

  • サービス死活監視: 機能していないサービスへはルーティングしない
  • ネットワーク位置集約: 複数インスタンス候補からの選別
  • 可用性: 単一障害点になりうるゆえの高い安定性

手法 編集

以下はサービスディスカバリに用いられる手法である。

Service Registry 編集

サービスレジストリはサービス・サービスインスタンス・サービス位置の保管庫であり[5]、サービスディスカバリに利用されるパターンの一種である。サービス解決に必要な情報をレジストリを集約しアクセスすることでサービスディスカバリを可能にする。レジストリの異常動作はサービスディスカバリ自体の異常動作を招く（単一障害点である）ので、etcdをはじめとした分散ストアなど、非常に高い可用性をもったレジストリ実装が求められる[6]。

要素技術 編集

以下はサービスディスカバリを実現するために利用される要素技術の例である。

実装例 編集

コンテナ 編集

コンテナの集合でアプリケーションを構成する場合、不安定なコンテナIPアドレスに対処するためにコンテナサービスディスカバリが必要になる。コンテナエンジンやコンテナオーケストレーターはサービスディスカバリ機能を提供している。

表: コンテナサービスディスカバリ
プラットフォーム 識別子 識別子例 負荷分散 方式
Dockerエンジン コンテナ名, Alias containerA ✔ コンテナIP-コンテナ名 DNS (with ラウンドロビン)
Docker-Compose Service名 serviceB ✔ コンテナIP-Service名 DNS (with ラウンドロビン)
Kubernetes Service名 serviceB.namespaceX ✔ ServiceプロキシIP-Service名 DNS + Serviceプロキシ-コンテナ負荷分散
AWS ECS Service名 serviceB.namespaceX ✔ コンテナIP-Service名 DNS (with ラウンドロビン)

Dockerエンジンはコンテナに対するDNSでサービスディスカバリを実現している。BridgeネットワークドライバがDNSを内蔵しており、コンテナ名およびエイリアス名をドメイン名とするDNSでルーティングしている（c.f. Docker#技術的な特徴 - ネットワーク）。Docker-ComposeではService名を生成コンテナ名相当としてBridgeネットワークによるDNSでルーティングをおこなっている。

Kubernetesではコンテナセットプロキシに対するDNSでサービスディスカバリを実現している[7]。k8sではコンテナ群に対応しロードバランシングをおこなうプロキシとしてServiceを定義している。Serviceは論理的な存在であり仮想IPアドレスは安定しているため、サーバー死活とDNSに関わる問題を避けられる[8]。この背景に基づいてk8sではServiceに対するサービスディスカバリを提供している。

AWSのマネージドコンテナオーケストレーションである Amazon Elastic Container Service (ECS) ではコンテナに対するDNSでサービスディスカバリを実現している。ECSではコンテナ群に対応するServiceを定義している[9]。Amazon ECS service discovery はServiceに所属するコンテナのプライベートIPアドレスと死活を管理してRoute53 DNSへService名をドメイン名として自動登録する。これによりアプリケーション内部におけるサービスディスカバリを提供している[10]。

脚注 編集

  1. ^ AWS ECS Docs/service-discovery
  2. ^ When using client‑side discovery, the client is responsible for determining the network locations of available service instances enginx
  3. ^ 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
  4. ^ Service instances have dynamically assigned network locations. Moreover, the set of service instances changes dynamically because of autoscaling, failures, and upgrades. enginx
  5. ^ Implement a service registry, which is a database of services, their instances and their locations. Microservice Architecture
  6. ^ 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
  7. ^ ユーザーはアドオンを使ってKubernetesクラスターにDNS Serviceをセットアップできます(常にセットアップすべきです)。 kubernetes docs - Service
  8. ^ kubernetes docs - Service - なぜ、DNSラウンドロビンを使わないのでしょうか。
  9. ^ 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
  10. ^ 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

関連項目 編集

外部リンク 編集

「https://ja.wikipedia.org/w/index.php?title=サービスディスカバリ&oldid=82528519」から取得