Service Directory は、Cloud のデータ処理に関する追加条項に規定されている Google の義務の対象となるサービスです。
Service Directory は、環境に関係なく、一貫した信頼性の高い方法でサービスを公開、検出、接続できる単一の場所です。Service Directory は、 Google Cloud、マルチクラウド、オンプレミス環境のサービスに対応しており、1 つのプロジェクトで数千のサービスとエンドポイントまでスケールアップできます。
Service Directory には次の機能があります。
- Namespace、サービス、エンドポイントの作成と解決を行う Registration and Lookup API
- Cloud DNS との統合。Service Directory ゾーンを使用すると、Virtual Private Cloud（VPC）でサービスを利用できます。
- IAM との統合: サービスの可視性と権限を割り当て、制御する
- 組み込みの Google Cloud CLI と Google Cloud コンソールで Service Directory の操作をサポート
- Cloud Monitoring と Cloud Logging の統合: Service Directory オペレーションのモニタリング、監査、デバッグ
Service Directory を使用する理由
アプリケーションでサービスが採用されるにつれて、サービスのエンドポイントが変更されるため、サービスの場所を解決することが難しくなります。ハイブリッド環境にデプロイされたサービスは、どちらも同じ命名システムを共有していない可能性があるため、サービスの解決と接続が困難になるという追加の障害があります。問題を説明するために、次のことを考えてみましょう。
シンプルな API を構築していて、そのコードがほかのアプリケーションを呼び出す必要があるとします。エンドポイントの情報が固定されていれば、これらの場所をコードにハードコードしたり、小さな構成ファイルに保存したりしても問題はありません。ただし、マイクロサービスやマルチクラウドでは、インスタンス、サービス、環境がすべて変わる可能性があるため、こういった問題を解決するのは非常に困難です。
Service Directory を使用すると、すべてのサービスを 1 か所に登録し、HTTP、gRPC、DNS を使用して解決できます。
前の図をもう一度見てみましょう。今回は Service Directory を追加します。次の図では、各サービス インスタンスが Service Directory に登録されています。これらの登録は DNS に即座に反映され、実装や環境にかかわらず、HTTP/gRPC を使ってクエリできます。
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 API を使用して Service Directory に直接登録されます。Service Directory には、Google Cloud サービスとGoogle Cloud 以外のサービスの両方を登録できます。
- 外部クライアントと内部クライアントの両方が、https://servicedirectory.googleapis.com でこれらのサービスを検索できます。
- DNS リクエストを有効にするには、Service Directory 名前空間に関連付けられた Cloud DNS に Service Directory ゾーンを作成します。
- 内部クライアントは、DNS、HTTP、gRPC を使用してこのサービスを解決できます。外部の（プライベート ネットワーク上にない）クライアントは HTTP か gRPC を使ってサービス名を解決する必要があります。
構成の例
DNS を介してサービスを公開する方法
次の図は、マイクロサービス アーキテクチャが Service Directory でモデル化され、DNS を使用して利用可能になる仕組みを示しています。Service Directory はサービスとエンドポイントを完全に維持しますが、限定公開ゾーンは Cloud DNS にあります。
この図（左側）では、payments サービスが、backend-namespace という名前、us-east1 というリージョン、gcp-project というプロジェクトの名前空間に登録されています。Namespace は限定公開ゾーン example.com にリンクされています。
DNS ルックアップを行うために、クライアントはドメイン名 _payments._tcp.payments.example.com の SRV レコードをリクエストします。これは、支払いサービスのエンドポイントのポート番号とアドレス レコードに解決されます。
次のステップ
- Service Directory Namespace を設定し、Namespace 内にサービスを作成して、エンドポイントをサービスに割り当てる方法については、Service Directory を構成するをご覧ください。
- 既存の名前空間を利用する Service Directory ゾーンを作成する方法については、Service Directory DNS ゾーンを構成するをご覧ください。
- DNS を使用して既存の Service Directory ゾーンにクエリを実行する方法については、DNS を使用したクエリをご覧ください。
- Service Directory の使用時に発生する可能性のある一般的な問題の解決策については、トラブルシューティングをご覧ください。