このドキュメントでは、ServiceNow クラウド検出を使用して Google Cloud、他のクラウド プラットフォームやオンプレミスでアセットに関する情報を検出して収集するためのアーキテクチャ パターンについて説明します。このドキュメントは、IT 運用管理（ITOM）、IT インフラストラクチャ ライブラリ（ITIL）、Google Cloud サービス（Compute Engine、Google Kubernetes Engine（GKE）や Cloud Asset Inventory など）、ServiceNow Cloud Discovery に精通したアーキテクチャ チームまたはクラウド運用チームを対象としています。
概要
大企業の多くは、Google Cloud、他のクラウド プラットフォーム、オンプレミス インフラストラクチャを組み合わせたハイブリッドな IT インフラストラクチャ デプロイを使用しています。このようなハイブリッド デプロイは通常、クラウド移行戦略の最初のイテレーションです。これらの企業の IT 部門は、テクニカル エコシステム内のすべてのアセットを検出、追跡することが求められています。場合によっては、数百万のアセットが発生する可能性があります。IT 部門は、アセットが提供する技術サービスとこれらのアセットを結び付ける構成管理システムを構築する必要があります。また、このシステムは、IT 運用管理（ITOM）と IT サービス管理（ITSM）のベスト プラクティスをサポートする方法でアセットとサービスをモニタリングする必要があります。
Google Cloud のお客様は、ServiceNow クラウド リソース検出を使用して、Google Cloud、他のクラウド プラットフォーム、オンプレミスにあるアセットに関する情報を見つけて収集します。ServiceNow には、複数のクラウド プロバイダにまたがるリソース管理 IT ワークフローを自動化するための幅広いツールが用意されています。Cloud Operations Workspace などのツールを使用することで、IT 部門はマルチクラウド リソース ダッシュボードを作成し、統合インターフェース（「一括表示」と呼ばれることもあります）を介して複雑な構成を管理できます。このドキュメントでは、このシナリオの一連のアーキテクチャ パターン、その構成要素のおおまかな概要、設計上の一般的な考慮事項について説明します。
このアーキテクチャの ServiceNow コンポーネント
これらのアーキテクチャ パターンの ServiceNow プラットフォーム コンポーネントには次のものが含まれます。
- 構成項目（CI）の構成管理データベース（CMDB）を含む ServiceNow インスタンス。各 CI は、デジタル サービスの提供に関連する運用環境のコンポーネントを表します。CI には、コンポーネントに関する特定のメタデータと、他の CI との関係を含む複数の属性があります。
- Google Cloud プロジェクトで実行されている 1 つ以上の ServiceNow 管理、計測、検出（MID）サーバー。MID サーバーは CI のメタデータを収集し、CMDB に保存します。
これらのアーキテクチャ パターンでは、Google Cloud Asset Inventory のデータを ServiceNow の Google Cloud Platform アセット インベントリ検出にインポートする一般的なプラクティスを定義します。
Google Cloud インテグレーションのアーキテクチャ パターン
このドキュメントでは、Google Cloud を ServiceNow に統合するための次のアーキテクチャ パターンについて説明します。
これらのアーキテクチャ パターンの例は、Google Cloud と ServiceNow クラウドの一部にインフラストラクチャが含まれるハイブリッド デプロイ向けに設計されています。これらは、Google 管理インフラストラクチャと顧客管理インフラストラクチャ間の Google Cloud で、ServiceNow がどのように動作するかについて説明します。ServiceNow MID サーバーは、Google Cloud APIs を呼び出して、Google が管理するすべてのインフラストラクチャにクエリを実行します。呼び出される API の詳細については、ITOM アプリケーションで使用される Google Cloud Platform API をご覧ください。
以下のパターンでは、アーキテクチャ コンポーネントが Google Cloud Platform アセット インベントリ検出プロセスで連携し、ServiceNow Discovery アプリケーションと関連ツールが必要とするクラウド アセット インベントリ情報が収集されます。
Google Cloud 検出パターン
基本的な ServiceNow クラウド検出のアーキテクチャ パターンでは、ServiceNow MID サーバーを使用して Google Cloud Asset Inventory と他の Google Cloud APIs を呼び出し、次のようなリソースに関するデータを収集します。
- VM インスタンス
- タグ（キー / 値）
- ストレージ ボリュームとストレージ マッピング
- データセンターのリソース（ハードウェアの種類を含む）
- クラウド ネットワーク、サブネット、ゲートウェイ
- イメージ
- Cloud ロードバランサとアベイラビリティ ゾーン
- クラウド データベースとデータベース クラスタ
- コンテナ（GKE）
- リソースラベルに基づくサービス マッピング
このパターンでは、MID サーバーは VM にログインしてデータを収集しないため、認証情報は必要ありません。これにより、検出プロセスで追加情報を収集する機能が制限されます。ただし、MID サーバーの認証情報を管理、ローテーションする必要がないため、運用コストは低くなります。
次の図は、このアーキテクチャ パターンを表しています。
このパターンの Google Cloud 部分は、以下で構成されます。
- 1 つの Google Cloud プロジェクト（図のサービス プロジェクト A）。これは、2 つの Google Cloud ロードバランサ、1 つ以上の VM インスタンス、GKE インスタンス、1 つ以上の ServiceNow MID サーバーで構成されます。各 MID サーバーはそれぞれの VM で実行されます。
- 独自の VM で実行される MID サーバーで構成される、第 2 の Google Cloud プロジェクト（図のサービス プロジェクト B）。
- Partner Interconnect で構成される第 3 の Google Cloud プロジェクト（図のホスト プロジェクト C）。
- その他のマネージド サービス（Cloud APIs、BigQuery、Cloud Storage など）。
- MID サーバーから Google Cloud APIs へのネットワーク ルート。
ServiceNow 部分は ServiceNow インスタンスで構成され、これは MID サーバーからメタデータをキャプチャして CMDB に保存します。
Google Cloud エージェントレス IP ベースの検出パターン
このアーキテクチャ パターンでは、バッチジョブと Google Cloud サービス アカウントを使用して VM へのログインと詳細の収集を行い、IP ベースの検出を基本的なクラウド検出パターンに追加します。このパターンでは、MID サーバーの認証情報の管理とローテーションを行う必要があるため、基本パターンよりも MID サーバーの管理に多くの負担がかかります。ただし、検出プロセスが Cloud Asset Inventory によって提供されるデータ以外にも拡張され、次のような追加のデータが含まれるようになります。
- OS 認証情報管理とセキュリティ
- 高度な検出（ファイルベースの検出やライセンスの検出など）
- OS の詳細
- 実行中のプロセス
- TCP 接続
- インストールされているソフトウェア
このアーキテクチャ パターンでは、1 つ以上の ServiceNow MID サーバーが Google Cloud に配置され、ServiceNow インスタンスは ServiceNow クラウド プラットフォームにホストされます。MID サーバーは、MID サーバー External Communication Channel（ECC）キュー（図には示されていません）を介して ServiceNow インスタンスに接続されています。次の図に、このアーキテクチャを示します。
このパターンの Google Cloud 部分は、以下で構成されます。
- サービス プロジェクト A。これは、2 つの Google Cloud ロードバランサ、1 つ以上の VM、GKE インスタンス、1 つ以上の ServiceNow MID サーバーで構成されています。各 MID サーバーはそれぞれの VM で実行されます。
- サービス プロジェクト B。これは、独自の VM で実行される MID サーバーで構成されます。
- Partner Interconnect で構成されるホスト プロジェクト C。
- その他のマネージド サービス（Cloud APIs、BigQuery、Cloud Storage など）。
- GKE インフラストラクチャにデプロイされた ServiceNow Kubernetes Discovery。
- MID サーバーから Google Cloud APIs へのネットワーク ルート。
- MID サーバーがサーバーレス IP アドレス検出を必要とする Google Cloud VM にログインできるようにするサービス アカウント。
- MID サーバーからサーバーレス IP アドレス検出を必要とする Google Cloud VM への設定されたネットワーク ルート。
ServiceNow 部分は ServiceNow インスタンスで構成され、これは MID サーバーからメタデータをキャプチャして CMDB に保存します。
Agent Client Collector パターンを使用した Google Cloud 検出
このアーキテクチャ パターンには次のものが含まれます。
- 初期のクラウド検出。
- 1 つ以上の MID Server。
追加の ServiceNow エージェント（Agent Client Collector）。これは、VM にインストールします。これらのエージェントは MID サーバーに直接接続し、次の追加情報を ServiceNow にリレーします。
- ニア リアルタイムの push ベースの検出
- ソフトウェア メータリング
- ライブ CI ビュー
- サーバーへのワークフローの自動化
次の図は、このアーキテクチャ パターンを表しています。
このパターンの Google Cloud 部分は、以下で構成されます。
- サービス プロジェクト A。2 つの Google Cloud ロードバランサ、1 つ以上の VM インスタンス、GKE インスタンス、1 つ以上の ServiceNow MID サーバーで構成されています。各 MID サーバーはそれぞれの VM で実行されます。
- サービス プロジェクト B。独自の VM で実行されている MID サーバーで構成されます。
- Partner Interconnect で構成されるホスト プロジェクト C。
- GKE インフラストラクチャにデプロイされた ServiceNow Kubernetes Discovery。
- その他のマネージド サービス（Cloud APIs、BigQuery、Cloud Storage など）。
- MID サーバーから Google Cloud APIs へのネットワーク ルート。
- MID サーバーから ServiceNow Discovery Agent がインストールされている Google Cloud VM に設定されたネットワーク ルート。
ServiceNow の部分は、次のものから構成されます。
- ServiceNow インスタンス。MID Servers からメタデータをキャプチャして、CMDB に保存します。
- 顧客管理の Google Cloud VM にインストールされている ServiceNow ディスカバリ エージェント。
クラウド アセット検出のワークフロー
以下のセクションでは、Google Cloud アセット検出のワークフローについて説明します。このワークフローは、このドキュメントで説明する 3 つのアーキテクチャ パターンすべてに適用されます。
ServiceNow コンポーネントをインストールして構成する
- Cloud Asset Inventory API を有効にします。
- VM に Agent Client Collector をインストールします。詳細については、Agent Client Collector のインストールをご覧ください。
- MID サーバーをホストするコンピュータにリソースを割り当てます。
- VM インスタンスと MID サーバーをホストするコンピュータ間のポート 443 での接続を許可するように、ファイアウォール ルールを構成します。
- MID サーバーのネットワーク接続を構成します。
- MID サーバーをインストールします。
- 関連する Google Cloud APIs を呼び出すように MID サーバーを構成します。MID サーバーに Google Cloud APIs を呼び出すための有効なネットワーク ルートがあることを確認します。
ワークフロー
- Cloud Asset Inventory は、Google Cloud 環境でサポートされているすべてのアセットタイプのデータベースをコンパイルします。ServiceNow は CMDB を更新するための追加情報を取得ソースとして Cloud Asset Inventory を使用します。
- ServiceNow の MID サーバーは、Google Cloud 環境内のすべてのアセットに関する情報について、Cloud Asset Inventory データベースに対するクエリを実行します。
- MID サーバーはクラウド アセット情報を Cloud Storage バケットに保存します。
- すべての必要な情報を Cloud Asset Inventory データベースから取得できるわけではありません。エージェントレス パターンでは、現在の OS パッチ バージョンは VM 情報には含まれません。この詳細に関して、MID サーバーは次の方法で高度な検出を実行します。
- MID サーバーでは、高度な検出を必要とする VM の IP アドレスに基づいてバッチジョブを作成します。
- このバッチジョブで、MID サーバーは各 VM にログインして、パッチのバージョニングやその他の情報を OS に問い合わせます。
- Agent Client Collector がインストールされている場合、キャプチャしたデータは Cloud Asset Inventory データベースではなく MID サーバーに直接送信されます。詳細については、ネットワークの準備と MID サーバーの構成をご覧ください。
- アセット検出データを収集した後、MID サーバーは次のように CMDB に保存します。
- MID サーバーは、各アセットによって提供される運用機能を表す CI を CMDB に作成します。
- MID サーバーによって Google Cloud からラベルが自動的に検出され、CMDB に保存されます。これらのラベルは CI に自動的にマッピングされ、サービスマップの作成に役立ちます。
このワークフロー プロセスは、必要に応じて定期的に繰り返す必要があります。デプロイのスケールと構成に応じて、イベント単位またはスケジュール単位の検出を選択できます。詳細については、CMDB 設計ガイダンスの「CI ライフサイクルの管理」をご覧ください。
設計上の考慮事項
以降のセクションでは、このドキュメントで説明するアーキテクチャ パターンを実装するための設計ガイダンスを示します。
ServiceNow インスタンスのロケーション
ほとんどのユースケースでは、Google Cloud に MID サーバーをデプロイすることをおすすめします。これにより、インスタンスは、詳細な検出を行うクラウド アセットの近くに配置されます。
このドキュメントのアーキテクチャ パターンでは、CMDB が Google Cloud アセットだけでなく、すべてのクラウド リソースとすべてのオンプレミス リソースの検出データを格納していることを前提としています。CMDB は、ServiceNow クラウド、Google Cloud、またはオンプレミスに配置できます。環境内における CMDB の場所は、最終的には特定の要件によって異なります。
MID サーバー エージェントの使用を決定する
また、設計の際には、MID サーバー エージェントとサービス アカウントを使用するかどうかも考慮する必要があります。検出プロセスで Cloud Asset Inventory が提供しているメタデータ以外の情報を収集する必要がある場合は、サービス アカウントを使用して MID サーバー インフラストラクチャを使用するか、または、MID サーバーをエージェント クライアント コレクタと一緒に使用する必要があります。どちらの方法でも、運用サポート費用に影響する可能性があるため、設計で考慮する必要があります。使用するべきアプローチは、キャプチャする必要があるデータと、データの使用方法によって異なります。データをキャプチャする運用コストが、データが提供する価値を上回る場合があります。
MID サーバーに対するマルチリージョン サポート
会社が MID サーバー インフラストラクチャのマルチリージョン サポートを必要とする場合は、各 MID サーバーを少なくとも 2 つのアベイラビリティ ゾーンにデプロイし、それを別のリージョンに複製することを計画する必要があります。
費用への影響
Google Cloud アセット検出用の ServiceNow コンポーネントをデプロイする場所を選択する場合は、下り（外向き）コストとコンピューティング コストを考慮する必要があります。
下り（外向き）費用
データが Google Cloud の外に移動するたびに下り（外向き）料金が発生します。そのため、ユースケースの下り（外向き）費用を分析して、ServiceNow コンポーネントを見つける最適なオプションを判断する必要があります。通常、ディープ ディスカバリを実行する MP Server は、Google Cloud で実行している場合、別のクラウドやオンプレミスで実行している場合よりも下り（外向き）の費用が少なくなります。
コンピューティングの費用
Google Cloud で実行される ServiceNow コンポーネントには、コンピューティング費用が発生します。この費用は、会社にとって最適な値を判断するために分析する必要があります。
たとえば、Google Cloud Compute Engine インスタンスにデプロイする MID サーバーの数を検討する必要があります。より多くの MID サーバーをデプロイすると、アセット ディスカバリ プロセスが高速化されます。ただし、各 MID サーバーが独自の VM インスタンスにデプロイされるため、コンピューティング費用が増加します。デプロイする MIG Server を 1 台にするか、複数にするかについては、1 つのシステムに複数の MID サーバーをインストールするをご覧ください。
運用サポートに関する考慮事項
多くの場合、デプロイには、ファイアウォール、侵入防止システム、侵入検知システム、パケット ミラーリング インフラストラクチャなどのネットワーク セキュリティ制御が含まれます。Google Cloud と MID サーバーがデプロイされている環境の間に広範なネットワーク セキュリティ コントロールが適用されている場合、これらのコントロールにより運用サポートの問題が発生する可能性があります。これらの問題を回避するには、MID サーバーを Google Cloud で、または詳細な検出をクエリする Google Cloud インフラストラクチャに可能な限り近い場所で、ホストすることをおすすめします。
MID サーバーの保護
MID サーバー インスタンスには、次のセキュリティ対策をおすすめします。
- MID サーバーが分離され、信頼できる管理者のみが接続できるようにすることを確認します。
- MID サーバーが削除されないように保護されていることを確認します。
- IAM ロールが適用され、変更の容量が、ITIL プロセスまたは CI / CD パイプラインを介して承認された変更のみに制限されるようにします。
サービス アカウントの保護
サービス アカウントの管理には、次のセキュリティ対策をおすすめします。
- MID サーバーが、アセットの検出に絶対に必要な IAM ロールと権限のみを持つサービス アカウントを使用していることを確認してください。詳しくは、サービス アカウントの操作のベスト プラクティスをご覧ください。
- ServiceNow 認証を行うには、サービス アカウント キーの内容を ServiceNow ユーザー インターフェースにコピーする必要があります。サービス アカウント キーが正しく管理されていない場合は、セキュリティ リスクが発生します。秘密鍵のセキュリティと、サービス アカウント キーを管理するためのベスト プラクティスで説明されているその他の操作は、お客様の責任で実施してください。サービス アカウント キーを作成できない場合は、組織でサービス アカウント キーの作成が無効になっている可能性があります。詳細については、デフォルトで安全な組織リソースの管理をご覧ください。
フォルダとプロジェクトの構造
フォルダとプロジェクトは、Google Cloud リソース階層のノードです。アセット検出をサポートするには、フォルダとプロジェクトの構造に、アプリケーションの構造とアプリケーションがデプロイされる環境を反映する必要があります。このようにリソースを構造化することで、ServiceNow でアセットをテクニカル サービスにマッピングすることもできます。
ServiceNow 検出をサポートすることを念頭に置きながら、フォルダとプロジェクトの構造に変更を加えます。フォルダとプロジェクト構造の主な役割は、課金と IAM アクセスをサポートすることです。したがって、ServiceNow をサポートするための変更は、組織の Google Cloud 請求構造をサポートし、適応するものである必要があります。Google Cloud の組織、フォルダ、プロジェクト階層の構造に関するベスト プラクティスについては、リソース階層と組織の作成と管理をご覧ください。
次の図は、Google Cloud リソース階層の例を示しています。この例では、フォルダ構造でアプリが定義され、各プロジェクトで環境が定義されています。
ラベル付け
ラベルは、クラウド リソースに割り当てることができる Key-Value ペアです（ServiceNow、AWS、Azure ではラベルを「タグ」と呼びます）。
ServiceNow は、Google Cloud アセットに割り当てたラベルを使用してアセットを識別し、必要に応じてサービスにマッピングします。適切なラベル付けスキームを選択することで、インフラストラクチャが正確なレポートと ITOM/ITSM のコンプライアンスを実現できるよう ServiceNow でモニタリングできます。
フォルダとプロジェクトの構造で許可されているものよりも限定された一意の ID を必要とするリソースには、ラベルを使用することをおすすめします。たとえば、次のようなケースでラベルを使用すると便利です。
- アプリケーションのコンプライアンス要件が厳しい場合は、すべてのアプリケーション リソースにラベルを付けることで、組織内で対象となるすべてのインフラストラクチャを簡単に識別できます。
- マルチクラウド環境では、ラベルを使用してすべてのリソースのクラウド プロバイダとリージョンを識別できます。
- Google Cloud Billing レポートまたは BigQuery への Cloud Billing のエクスポートでデフォルトよりも細かい可視化が必要な場合は、データをラベルでフィルタできます。
VPC 内で実行される Google 管理のアセットには、自動的にラベルが割り当てられます。Google によって割り当てられるラベルには、接頭辞 goog- が付きます。MID サーバーで、これらのアセットの詳細な検査を試行しないでください。Google マネージド リソースのラベルについて詳しくは、タグベースのマッピングと Cloud Asset Inventory のリアルタイム通知に基づいて、リソースに自動的にラベルを付けるをご覧ください。
次の表に、Google Cloud サービスが、それらのサービスによって管理されるリソースに対して割り当てるラベルを示します。
| Google Cloud サービス | ラベルまたはラベル接頭辞 |
|---|---|
| Google Kubernetes Engine |
goog-gke-
|
| Compute Engine |
|
| Dataproc |
|
| Vertex AI Workbench |
|
リソース管理を効果的にサポートするには、組織のデプロイ プロセスでプロジェクト構造とフォルダ構造を作成し、組織全体で一貫してアセットラベルを割り当てる必要があります。インフラストラクチャとラベル付けに不整合がある場合、サポートされない可能性が高く長期的なスケーリングが難しい手動プロセスなしでは、適切な CMDB を維持することが困難になる可能性があります。
次のリストは、デプロイ プロセスに一貫性を持たせ、再現可能なものにするためのベスト プラクティスを示しています。
- Infrastructure as Code（IaC）または自動プロビジョニング システム（Terraform、ServiceNow ITOM、Google Cloud Deployment Manager を使用したクラウドのプロビジョニングとガバナンスなど）を使用する。
- ラベルのための適切なガバナンス プロセスが設定されている。ラベル付けガバナンスの概要については、ServiceNow ドキュメントでタグガバナンスをご覧ください。
次のステップ
- Cloud Billing のリソースを構成するための追加のベスト プラクティスについては、Cloud Billing リソースの組織化とアクセス管理のガイドと Google Cloud の Cloud Insights の設定ガイドをご覧ください。
- 組織の IAM 権限を構造化するためのベスト プラクティスについては、アカウントと組織の計画に関するベスト プラクティスと、クラウドのプロビジョニングとガバナンスをご覧ください。
- 組織全体の VPC ファイアウォール ポリシーを構築するためのベスト プラクティスについては、階層型ファイアウォール ポリシーをご覧ください。
- ラベルを使用して ServiceNow のタグベースの検出をサポートする方法を学習する。
- Google Cloud プロジェクトで実行するして出力データを MID サーバー経由で ServiceNow インスタンスに送信し、関連するデータベースにイベントと指標を保存する push メカニズムである ServiceNow エージェント クライアント コレクタについて学習する。
- リファレンス アーキテクチャ、図、ベスト プラクティスについては、Cloud アーキテクチャ センターをご確認ください。