Service Directory

解決する課題

サービスがどこで動いているか（IP・ポート・メタデータ）を、環境を横断して一元的に把握し、名前で見つけられるようにするのが核心です。

• VM・コンテナ・サーバーレス・オンプレミスと、サービスの実体が分散し、所在の管理が煩雑になっている
• アプリのコードや設定に IP・ポートを直書きしてしまい、変更のたびに各所を直す必要がある
• サービスの所在を DNS でも API でも 同じ情報源から引きたい
• マイクロサービス間の名前解決（サービスディスカバリ）を、自前のレジストリを運用せずに済ませたい

ロードバランサや DNS が「どこへ流すか」を担うのに対し、Service Directory は「どんなサービスが、どこに、どんな属性で存在するか」という**レジストリ（登録簿）**を担うのが位置づけです。

主要概念と用語

• ネームスペース: サービスをまとめる入れ物。リージョン単位のリソースで、配下にサービスを格納する
• サービス: 論理的なサービス名。配下に複数のエンドポイントと、サービス単位のメタデータ（アノテーション）を持つ
• エンドポイント: サービスの実体の所在。IP アドレスとポート、および任意のメタデータ（アノテーション）を持つ。1 つのサービスに複数登録できる
• アノテーション: サービスやエンドポイントに付けるキーと値のメタデータ。バージョン・環境・プロトコルなどの属性を持たせ、検索やフィルタに使う
• Service Directory の DNS ゾーン: ネームスペースを 限定公開（プライベート）DNS ゾーンに紐づけ、登録したサービスを VPC 内から DNS 名で解決できるようにする統合機能
• 解決の経路: 登録した情報は API（resolve）／DNS／gRPC のリゾルバのいずれからも引ける。同じレジストリを複数の方法で参照する

仕様・制限・クォータ

• リージョン単位のリソース。ネームスペース・サービス・エンドポイントはいずれもリージョンに属する
• 階層は ネームスペース → サービス → エンドポイントの 3 段。エンドポイントは IP とポート、任意のアノテーションを持つ
• 1 サービスあたりのエンドポイント数、1 ネームスペースあたりのサービス数、アノテーションの数やサイズなどに上限がある。大規模構成では事前に上限を確認し、必要なら引き上げを申請する
• DNS 統合では、ネームスペースを限定公開 DNS ゾーンに対応づけ、紐づけた VPC からサービスを名前解決できる
• 課金は API 呼び出し回数と登録リソース数を中心とした従量。具体的な単価・上限値は変動するため公式の料金・クォータページで最新値を確認する

内部の仕組み

Service Directory は、サービスの所在情報を保持するマネージドなレジストリとして動き、登録された情報を複数の経路から一貫して提供します。

• アプリやインフラ自動化が、サービスとエンドポイントを API でレジストリへ登録する。登録内容は IP・ポートとアノテーション
• 利用側は API の resolve でサービスを引き、条件に合うエンドポイント群とメタデータを受け取る
• ネームスペースを 限定公開 DNS ゾーンに紐づけると、同じ情報が **DNS（A/AAAA/SRV など）**として VPC 内から解決できる。アプリ側を変えずに名前解決へ載せられる
• gRPC のネームリゾルバ統合により、gRPC クライアントが Service Directory を直接参照してエンドポイントを取得できる
• レジストリ自体は Google が冗長構成で運用するため、利用者は可用性やスケールを意識せずに済む

設計パターン / ベストプラクティス

• IP・ポートをアプリへ直書きせず、Service Directory へ登録して名前で参照することで、所在変更をレジストリ更新に閉じ込める
• VM・コンテナ・外部サービスを同一のネームスペース体系へ登録し、環境を横断したサービスディスカバリの基盤にする
• 環境・バージョン・プロトコルなどをアノテーションで表現し、利用側がメタデータで対象を絞り込めるようにする
• 既存アプリを改修せずに導入したい場合は、DNS 統合を使い、アプリからは通常の DNS 名前解決として扱わせる
• gRPC マイクロサービス間では gRPC リゾルバ統合を使い、クライアントから直接エンドポイントを取得させる

運用・監視

• Cloud Monitoring で API 呼び出し量や解決状況のメトリクスを監視し、想定外の急増や解決失敗を検知する
• Cloud Audit Logs でネームスペース・サービス・エンドポイントの作成・変更・削除を追跡し、誰がレジストリを変えたかを把握する
• エンドポイント登録を**自動化（IaC やデプロイパイプライン）**し、手作業による登録漏れ・削除漏れを防ぐ
• 解決できない場合は、ネームスペース・サービスの存在、エンドポイントの登録内容、DNS 統合ゾーンと VPC の紐づけ、IAM 権限を順に確認する

コスト

課金の中心は API 呼び出し回数と、登録しているリソースの規模です。

具体的な単価は変動するため、料金は公式の料金ページで最新値を確認してください。

セキュリティ

• IAM でネームスペース・サービス・エンドポイントへの参照・編集権限を分離し、登録（書き込み）と解決（読み取り）の権限を最小化する
• DNS 統合は限定公開（プライベート）DNS ゾーンを用いるため、登録したサービス名を外部へ露出させず VPC 内に閉じられる
• Cloud Audit Logs でレジストリ変更を記録し、不正・誤操作による所在情報の改ざんを追跡できるようにする
• アノテーションに機密情報を入れない。メタデータは検索・属性付けの目的に限り、認証情報などは Secret Manager 等で別管理する

関連サービス・比較

名前を IP へ解く配送そのものは Cloud DNS、トラフィックの分散は Cloud Load Balancing が担い、Service Directory はその上位で「どんなサービスがどこにあるか」を保持します。マイクロサービス間の通信制御まで踏み込む場合は Cloud Service Mesh が比較対象になり、Service Directory は所在の登録・検索に焦点を絞ったレジストリとして位置づけられます。

ハンズオン / CLI例

# ネームスペースを作成
gcloud service-directory namespaces create my-namespace \
  --location=asia-northeast1

# ネームスペース配下にサービスを作成（アノテーション付き）
gcloud service-directory services create my-service \
  --namespace=my-namespace \
  --location=asia-northeast1 \
  --annotations=env=prod,protocol=grpc

# サービスにエンドポイント（IP とポート）を登録
gcloud service-directory endpoints create ep-1 \
  --service=my-service \
  --namespace=my-namespace \
  --location=asia-northeast1 \
  --address=10.10.0.10 \
  --port=8080

# サービスを解決し、登録済みエンドポイントを取得
gcloud service-directory services resolve my-service \
  --namespace=my-namespace \
  --location=asia-northeast1