Service Directory は、環境に関係なく、一貫した信頼性の高い方法でサービスを公開、検出、接続できる単一の場所です。Service Directory は、 Google Cloud、マルチクラウド、オンプレミス環境のサービスに対応しており、1 つのプロジェクトで最大数千のサービスとエンドポイントにスケールアップできます。
シンプルな API を構築していて、そのコードがほかのアプリケーションを呼び出す必要があるとします。エンドポイントの情報が固定されていれば、これらの場所をコードにハードコードしたり、小さな構成ファイルに保存したりしても問題はありません。ただし、マイクロサービスやマルチクラウドでは、インスタンス、サービス、環境がすべて変わる可能性があるため、こういった問題を解決するのは非常に困難です。
さまざまな変更サービス(クリックして拡大)
Service Directory を使用すると、すべてのサービスを 1 か所に登録し、HTTP、gRPC、DNS を使用して解決できます。
前の図をもう一度見てみましょう。今回は Service Directory を追加します。次の図では、各サービス インスタンスが Service Directory に登録されています。これらの登録は DNS に即座に反映され、実装や環境にかかわらず、HTTP/gRPC を使ってクエリできます。
ロードバランサを使用した Service Directory(クリックして拡大)
App Engine や GKE などのプロダクト間で機能するユニバーサル サービス名を作成できます。 Google Cloudこれらのサービスを DNS 経由で利用できるようにできます。サービス アカウントのネットワーク、プロジェクト、IAM ロールに基づいて、サービスにアクセス制御を適用できます。
Service Directory を使うと、以下のような問題を解決できます。
相互運用性: Service Directory は、 Google Cloud、マルチクラウド、オンプレミスで動作するユニバーサルなネーミング サービスです。サービスの登録とエンドポイントの解決に使用するサービス名を維持しつつ、これらの環境間でサービスを移行することができます。
サービス管理: Service Directory はマネージド サービスです。高可用性、冗長性、スケーリング、および独自のサービス レジストリのメンテナンスの心配をする必要はありません。
アクセス制御: Service Directory では、IAM を使用して、誰がサービスを登録でき、名前解決できるかを制御できます。Service Directory のロールをチーム、サービス アカウント、組織に割り当てます。
純粋な DNS の限界: DNS リゾルバは、TTL やキャッシュの観点から信頼性が低く、大きなレコードサイズに対応できず、ユーザーにメタデータを提供する簡単な方法も提供しません。Service Directory は DNS サポートに加え、サービスをクエリし解決するための API を HTTP と gRPC で提供しています。
Service Directory で Cloud DNS を使用する
Cloud DNS は、Google のインフラストラクチャ上で動作する、高速でスケーラブルかつ信頼性の高いドメイン ネーム システム(DNS)サービスです。
一般公開 DNS ゾーンに加え、Cloud DNS はGoogle Cloud上の限定公開ネットワーク向けのマネージド内部 DNS ソリューションも提供しています。限定公開 DNS ゾーンを使用すると、仮想マシン(VM)インスタンス、ロードバランサ、その他のリソースに内部で名前を付けることができます。この限定公開 DNS ゾーンに対する DNS クエリは、プライベート ネットワークからのみ行えます。
次の図は、Service Directory ゾーンを使用して DNS ルックアップでサービス名を取得する方法を示しています。
Service Directory での Cloud DNS の使用(クリックして拡大)
個々のコンポーネントの概要:
エンドポイントは、Service Directory API を使用して Service Directory に直接登録されます。Service Directory には、Google Cloud サービスとGoogle Cloud 以外のサービスの両方を登録できます。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-09-10 UTC。"],[],[],null,["# Service Directory overview\n\nService Directory is a service covered by Google's obligations set forth\nin the [Cloud Data Processing Addendum](/terms/data-processing-addendum).\n\nService Directory is a single place to publish, discover, and connect to\nservices in a consistent and reliable way, regardless of their environment.\nService Directory supports services in Google Cloud, multi-cloud,\nand on-premises environments and can scale up to thousands of services and\nendpoints for a single project.\n\nService Directory has the following features:\n\n- A **Registration and Lookup API** for creating and resolving [namespaces](/service-directory/docs/key-terms#namespace), [services](/service-directory/docs/key-terms#service), and [endpoints](/service-directory/docs/key-terms#endpoint)\n- Integration with [Cloud DNS](/dns/docs). Service Directory zones allow services to be made available on Virtual Private Cloud (VPC).\n- **[IAM integration](/iam)** to assign and control service visibility and permissions\n- Built-in **[Google Cloud CLI](/sdk/gcloud/reference/service-directory)** and **[Google Cloud console](https://console.cloud.google.com/net-services/service-directory/namespaces/list)** support for interacting with Service Directory\n- **Cloud Monitoring and Cloud Logging integration** for monitoring, auditing, and debugging Service Directory operations\n\nWhy Service Directory\n---------------------\n\nAs applications adopt services, being able to resolve the location of a service\nbecomes more difficult as the endpoints of those services change. Services\ndeployed across hybrid environments present additional obstacles as neither may\nshare the same naming system, making resolving and connecting services\nchallenging. To illustrate the problem, consider the following.\n\nImagine that you are building a simple API and that your code needs to call some\nother application. When endpoint information remains static, you can hard-code\nthese locations into your code or store them in a small configuration file.\nHowever, with microservices and multi-cloud, this problem becomes much harder to\nsolve as instances, services, and environments can all change.\n[](/static/service-directory/images/service-directory-01.svg) Different changing services (click to enlarge)\n\nWith Service Directory, you can register all of your services in a single\nplace and resolve them by using HTTP, gRPC, and DNS.\n\nLet us revisit the previous diagram, but this time adding Service Directory.\nIn the following diagram, each service instance is registered with Service Directory.\nThese registrations are immediately reflected in DNS and can be queried by using\nHTTP/gRPC regardless of their implementation and environment.\n[](/static/service-directory/images/service-directory-02.svg) Service Directory with a load balancer (click to enlarge)\n\nYou can create a universal service name that works across Google Cloud\nproducts, like App Engine and GKE. You can make these services\navailable over DNS. You can apply access controls\nto services based on network, project, and IAM roles of\nservice accounts.\n\nService Directory solves the following problems:\n\n1. **Interoperability**: Service Directory is a universal naming service that works across Google Cloud, multi-cloud, and on-premises. You can migrate services between these environments and still use the same service name to register and resolve endpoints.\n2. **Service management**: Service Directory is a managed service. Your organization does not have to worry about the high availability, redundancy, scaling, or maintenance concerns of maintaining your own service registry.\n3. **Access Control**: With Service Directory, you can control who can register and resolve your services using IAM. Assign Service Directory roles to teams, service accounts, and organizations.\n4. **Limitations of pure DNS**: DNS resolvers can be unreliable in terms of respecting TTLs and caching, cannot handle larger record sizes, and do not offer an easy way to serve metadata to users. In addition to DNS support, Service Directory offers HTTP and gRPC APIs to query and resolve services.\n\nUse Cloud DNS with Service Directory\n------------------------------------\n\nCloud DNS is a fast, scalable, and reliable\n[Domain Name System](https://wikipedia.org/wiki/Domain_Name_System)\n(DNS) service running on Google's infrastructure.\n\nIn addition to public DNS zones,\n[Cloud DNS](/dns)\nalso provides a managed internal DNS solution for private networks on\nGoogle Cloud.\n[Private DNS zones](/dns/docs/overview#concepts)\nenable you to internally name your virtual machine (VM) instances, load\nbalancers, or other resources. DNS queries for those private DNS zones are\nrestricted to your private networks.\n\nThe following diagram illustrates how you can use Service Directory zones\nto make service names available using DNS lookups.\n[](/static/service-directory/images/service-directory-05.svg) Using Cloud DNS with Service Directory (click to enlarge)\n\nOverview of the individual components:\n\n1. The endpoints are registered directly with Service Directory by using the Service Directory API. You can register both Google Cloud and non-Google Cloud services with Service Directory.\n2. Both external and internal clients can look up those services at: https://servicedirectory.googleapis.com\n3. To enable DNS requests, [create a Service Directory zone in\n Cloud DNS](/service-directory/docs/configuring-service-directory-zone) that is associated with a Service Directory namespace.\n4. Internal clients can resolve this service by using DNS, HTTP, and gRPC. External clients (clients not on the private network) must use HTTP or gRPC to resolve service names.\n\nExample configuration\n---------------------\n\n### How to expose a service over DNS\n\nThe following diagram illustrates how a microservice architecture is modeled in\nService Directory and made available using DNS. Notice that Service Directory\nmaintains the services and endpoints entirely,\nbut the private zone is in Cloud DNS.\n[](/static/service-directory/images/service-directory-06.svg) Exposing a service over DNS (click to enlarge)\n\nIn this diagram (left side), the **payments** service is registered to a\nnamespace with the name `backend-namespace`, the region `us-east1`, and the\nproject `gcp-project`. The namespace is linked to the private zone\n`example.com`.\n\nTo do a DNS lookup, the client requests the\n[SRV record](https://wikipedia.org/wiki/SRV_record)\nfor the domain name `_payments._tcp.payments.example.com`, which\nresolves to the port numbers and address records for the payment service's\nendpoints.\n\nWhat's next\n-----------\n\n- To learn how to set up a Service Directory namespace, create a service in the namespace, and assign endpoints to a service, see [Configure\n Service Directory](/service-directory/docs/configuring-service-directory).\n- To learn how to create a Service Directory zone that leverages an an existing namespace, see [Configure a Service Directory DNS\n zone](/service-directory/docs/configuring-service-directory-zone).\n- To learn how to make a query to an existing Service Directory zone using DNS, see [Query using DNS](/service-directory/docs/query-dns).\n- To find solutions for common issues that you might encounter when using Service Directory, see [Troubleshooting](/service-directory/docs/troubleshooting)."]]