서비스 디렉터리는 환경에 관계없이 일관되고 안정적인 방식으로 서비스를 게시, 검색, 연결할 수 있는 단일 위치입니다.
서비스 디렉터리는 Google Cloud, 멀티 클라우드, 온프레미스 환경의 서비스를 지원하며 단일 프로젝트에 최대 수천 개의 서비스와 엔드포인트를 확장할 수 있습니다.
서비스 디렉터리의 기능은 다음과 같습니다.
네임스페이스, 서비스, 엔드포인트를 만들고 확인하기 위한 Registration and Lookup API
Cloud DNS 통합 서비스 디렉터리 영역을 사용하면 Virtual Private Cloud (VPC)에서 서비스를 제공할 수 있습니다.
서비스 디렉터리 작업 모니터링, 감사, 디버깅을 위한 Cloud Monitoring 및 Cloud Logging 통합
서비스 디렉터리를 사용하는 이유
애플리케이션이 서비스를 채택함에 따라 서비스의 엔드포인트가 변경되면 서비스의 위치를 확인하기 어려워집니다. 하이브리드 환경에 배포된 서비스는 둘 다 동일한 이름 지정 시스템을 공유하지 않을 수 있으므로 추가 장애물이 발생하여 서비스를 확인하고 연결하기가 어렵습니다. 문제를 설명하기 위해 다음을 살펴보세요.
간단한 API를 빌드하고 있고 코드에서 다른 애플리케이션을 호출해야 한다고 가정해 보겠습니다. 엔드포인트 정보가 정적 상태로 유지되는 경우 이러한 위치를 코드에 하드코딩하거나 작은 구성 파일에 저장할 수 있습니다.
그러나 마이크로서비스와 멀티 클라우드를 사용하면 인스턴스, 서비스, 환경이 모두 변경될 수 있으므로 이 문제를 해결하기가 훨씬 더 어려워집니다.
다양한 변경 서비스 (확대하려면 클릭)
서비스 디렉터리를 사용하면 모든 서비스를 한곳에서 등록하고 HTTP, gRPC, DNS를 사용하여 확인할 수 있습니다.
이전 다이어그램을 다시 살펴보면서 이번에는 서비스 디렉터리를 추가해 보겠습니다.
다음 다이어그램에서 각 서비스 인스턴스는 서비스 디렉터리에 등록됩니다.
이러한 등록은 DNS에 즉시 반영되며 구현 및 환경과 관계없이 HTTP/gRPC를 사용하여 쿼리할 수 있습니다.
부하 분산기가 있는 서비스 디렉터리 (확대하려면 클릭)
App Engine 및 GKE와 같은 여러 제품에서 작동하는 범용 서비스 이름을 만들 수 있습니다. Google Cloud
DNS를 통해 이러한 서비스를 사용할 수 있습니다. 서비스 계정의 네트워크, 프로젝트, IAM 역할을 기반으로 서비스에 액세스 제어를 적용할 수 있습니다.
서비스 디렉터리는 다음 문제를 해결합니다.
상호 운용성: 서비스 디렉터리는 Google Cloud, 멀티 클라우드, 온프레미스에서 작동하는 범용 이름 지정 서비스입니다.
이러한 환경 간에 서비스를 이전하면서 동일한 서비스 이름을 사용하여 엔드포인트를 등록하고 확인할 수 있습니다.
서비스 관리: 서비스 디렉터리는 관리형 서비스입니다.
조직은 자체 서비스 레지스트리를 유지하는 데 따르는 고가용성, 중복, 확장 또는 유지보수 문제를 걱정할 필요가 없습니다.
액세스 제어: 서비스 디렉터리를 사용하면 IAM을 사용하여 서비스를 등록하고 확인할 수 있는 사용자를 제어할 수 있습니다. 팀, 서비스 계정, 조직에 서비스 디렉터리 역할을 할당합니다.
순수 DNS의 제한사항: DNS 리졸버는 TTL 및 캐싱을 준수하는 측면에서 신뢰할 수 없으며, 더 큰 레코드 크기를 처리할 수 없으며, 사용자에게 메타데이터를 제공하는 간단한 방법을 제공하지 않습니다. 서비스 디렉터리는 DNS 지원 외에도 서비스를 쿼리하고 확인하는 HTTP 및 gRPC API를 제공합니다.
서비스 디렉터리와 함께 Cloud DNS 사용
Cloud DNS는 Google의 인프라에서 실행되는 빠르고 확장 가능하며 안정적인 도메인 이름 시스템(DNS) 서비스입니다.
Cloud DNS는 공개 DNS 영역 외에도Google Cloud의 비공개 네트워크를 위한 관리형 내부 DNS 솔루션을 제공합니다.
비공개 DNS 영역을 사용하면 가상 머신 (VM) 인스턴스, 부하 분산기 또는 기타 리소스의 이름을 내부적으로 지정할 수 있습니다. 이러한 비공개 DNS 영역에 대한 DNS 쿼리는 비공개 네트워크로 제한됩니다.
다음 다이어그램은 서비스 디렉터리 영역을 사용하여 DNS 조회를 통해 서비스 이름을 사용할 수 있는 방법을 보여줍니다.
서비스 디렉터리와 함께 Cloud DNS 사용 (확대하려면 클릭)
개별 구성요소 개요:
엔드포인트는 서비스 디렉터리 API를 사용하여 서비스 디렉터리에 직접 등록됩니다. 서비스 디렉터리에Google Cloud 및 비Google Cloud 서비스를 둘 다 등록할 수 있습니다.
외부 클라이언트와 내부 클라이언트 모두 https://servicedirectory.googleapis.com에서 이러한 서비스를 조회할 수 있습니다.
[[["이해하기 쉬움","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-04(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)."]]
