이 문서에서는 ServiceNow 클라우드 검색을 사용하여 Google Cloud, 다른 클라우드 플랫폼, 온프레미스에서 애셋 정보를 찾고 수집하는 방법에 대한 아키텍처 패턴을 설명합니다. 이 문서는 Compute Engine, Google Kubernetes Engine(GKE), Cloud 애셋 인벤토리, ServiceNow 클라우드 검색과 같은 IT 운영 관리(ITOM), 정보 기술 인프라 라이브러리(ITIL), Google Cloud 서비스에 익숙한 아키텍처 팀 또는 Cloud 운영 팀을 대상으로 작성되었습니다.
개요
많은 대기업은 Google Cloud, 다른 클라우드 플랫폼, 온프레미스 인프라를 결합한 하이브리드 IT 인프라 배포를 사용합니다. 이러한 하이브리드 배포는 일반적으로 클라우드 이전 전략의 초기 반복입니다. 이러한 기업의 IT 부서는 기술 생태계의 모든 애셋을 검색하고 추적해야 하며, 이란 애셋은 잠재적으로 수백만 개에 달할 수 있습니다. IT 부서는 이러한 애셋을 애셋이 제공하는 기술 서비스와 연결하는 구성 관리 시스템을 구축해야 합니다. 또한 이 시스템은 IT 운영 관리(ITOM) 및 IT 서비스 관리(ITSM) 권장사항을 지원하는 방식으로 애셋 및 서비스를 모니터링해야 합니다.
Google Cloud 고객의 경우 일반적인 아키텍처는 ServiceNow 클라우드 리소스 검색을 사용하여 Google Cloud, 다른 클라우드 플랫폼, 온프레미스의 애셋에 대한 정보를 찾고 수집합니다. ServiceNow는 여러 클라우드 제공업체에서 리소스 관리 IT 워크플로를 자동화하기 위한 광범위한 도구를 제공합니다. Cloud 운영 작업공간과 같은 도구를 사용하면 IT 부서는 멀티 클라우드 리소스 대시보드를 만들고 통합 인터페이스(일반적으로단일 제어 창이라고 함)를 통해 복잡한 구성을 관리할 수 있습니다. 이 문서에서는 이 시나리오에 대한 아키텍처 패턴 세트, 상위 수준의 구성요소 개요 및 일반적인 설계 고려사항을 설명합니다.
이 아키텍처를 위한 ServiceNow 구성요소
이러한 아키텍처 패턴의 ServiceNow 플랫폼 구성요소에는 다음이 포함됩니다.
- 구성 항목(CI)의 구성 관리 데이터베이스(CMDB)가 포함된 ServiceNow 인스턴스. 각 CI는 디지털 서비스 제공과 관련된 운영 환경의 구성요소를 나타냅니다. CI에는 구성요소 및 구성요소의 다른 CI와의 관계에 관한 특정 메타데이터가 포함된 여러 속성이 있습니다.
- Google Cloud 프로젝트에서 실행되는 하나 이상의 ServiceNow 관리, 계측, 검색(MID) 서버. MID 서버는 CI의 메타데이터를 수집하여 CMDB에 저장합니다.
이러한 아키텍처 패턴은 Google Cloud 애셋 인벤토리 데이터를 ServiceNow의 Google Cloud Platform 애셋 인벤토리 검색으로 가져오기 위한 몇 가지 일반적인 권장사항을 정의합니다.
Google Cloud 통합을 위한 아키텍처 패턴
이 문서에서는 Google Cloud를 ServiceNow에 통합하기 위한 다음과 같은 아키텍처 패턴을 설명합니다.
이러한 아키텍처 패턴 예시는 Google Cloud에 일부 인프라가 있고 ServiceNow 클라우드에 일부 인프라가 있는 하이브리드 배포를 위해 설계되었습니다. 이 문서는 Google에서 관리하는 인프라와 고객 관리 인프라 사이에서 ServiceNow가 Google Cloud에서 작동하는 방식을 보여줍니다. ServiceNow MID 서버는 Google Cloud API를 호출하여 모든 Google 관리 인프라를 쿼리합니다. 호출되는 API에 관한 자세한 내용은 ITOM 애플리케이션에서 사용하는 Google Cloud Platform API를 참고하세요.
다음 각 패턴에서 아키텍처 구성요소는 Google Cloud Platform 애셋 인벤토리 검색 프로세스에서 함께 작동하여 ServiceNow Discovery 애플리케이션 및 관련 도구에 필요한 Cloud 애셋 인벤토리 정보를 수집합니다.
Google Cloud 검색 패턴
기본 ServiceNow 클라우드 검색 아키텍처 패턴은 ServiceNow MID 서버를 사용하여 Google Cloud 애셋 인벤토리 및 기타 Google Cloud API를 호출하여 다음과 같은 리소스에 관한 데이터를 수집합니다.
- VM 인스턴스
- 태그(키/값)
- 스토리지 볼륨 및 스토리지 매핑
- 하드웨어 유형을 포함한 데이터 센터 리소스
- 클라우드 네트워크, 서브넷, 게이트웨이
- 이미지
- Cloud Load Balancing 및 가용성 영역
- 클라우드 데이터베이스 및 데이터베이스 클러스터
- 컨테이너(GKE)
- 리소스 라벨을 기반으로 한 서비스 매핑
이 패턴에서 MID 서버는 데이터를 수집하기 위해 VM에 로그인하지 않으므로 사용자 인증 정보가 필요하지 않습니다. 이렇게 하면 검색 프로세스가 추가 정보를 수집하는 기능이 제한됩니다. 하지만 MID 서버 사용자 인증 정보를 관리하고 회전할 필요가 없으므로 운영 비용이 더 적게 듭니다.
이 아키텍처 패턴을 다이어그램으로 나타내면 다음과 같습니다.
이 패턴의 Google Cloud 부분은 다음으로 구성됩니다.
- 두 개의 Google Cloud 부하 분산기, 하나 이상의 VM 인스턴스, GKE 인스턴스 및 하나 이상의 ServiceNow MID 서버로 구성된 하나의 Google Cloud 프로젝트(다이어그램의 서비스 프로젝트 A). 각 MID 서버는 자체 VM에서 실행됩니다.
- 자체 VM에서 실행되는 MID 서버로 구성된 두 번째 Google Cloud 프로젝트(다이어그램의 서비스 프로젝트 B)
- Partner Interconnect로 구성된 세 번째 Google Cloud 프로젝트(다이어그램의 호스트 프로젝트 C)
- Cloud APIs, BigQuery, Cloud Storage와 같은 추가 관리형 서비스
- MID 서버에서 Google Cloud API로 설정되는 네트워크 경로
ServiceNow 부분은 MID 서버에서 메타데이터를 캡처하여 CMDB에 저장하는 ServiceNow 인스턴스로 구성됩니다.
Google Cloud 에이전트리스 IP 검색 패턴
이 아키텍처 패턴은 일괄 작업 및 Google Cloud 서비스 계정을 사용하여 VM에 로그인하고 추가 세부 정보를 수집하여 기본 클라우드 검색 패턴에 IP 기반 검색을 추가합니다. 이 패턴에서는 MID 서버 사용자 인증 정보를 관리하고 순환해야 하므로 기본 패턴보다 MID 서버를 관리하는 데 더 많은 운영 부담이 발생합니다. 하지만 다음과 같이 추가 데이터를 포함하도록 Cloud 애셋 인벤토리에서 제공하는 데이터 이상으로 검색 프로세스를 확장합니다.
- OS 사용자 인증 정보 관리 및 보안
- 파일 기반 검색 및 라이선스 검색과 같은 향상된 검색
- OS 세부정보
- 실행 중인 프로세스
- TCP 연결
- 설치된 소프트웨어
이 아키텍처 패턴에서 하나 이상의 ServiceNow MID 서버는 Google Cloud에 있고 ServiceNow 인스턴스는 ServiceNow 클라우드 플랫폼에 호스팅됩니다. MID 서버는 MID 서버 외부 통신 채널(ECC) 큐(표시되지 않음)를 통해 ServiceNow 인스턴스에 연결됩니다. 이 아키텍처는 다음 다이어그램에 나와 있습니다.
이 패턴의 Google Cloud 부분은 다음으로 구성됩니다.
- 서비스 프로젝트 A: 2개의 Google Cloud 부하 분산기, 하나 이상의 VM, GKE 인스턴스, 하나 이상의 ServiceNow MID 서버로 구성. 각 MID 서버는 자체 VM에서 실행됩니다.
- 서비스 프로젝트 B: 자체 VM에서 실행되는 MID 서버로 구성
- 호스트 프로젝트 C: Partner interconnect로 구성
- Cloud APIs, BigQuery, Cloud Storage와 같은 추가 관리형 서비스
- GKE 인프라에 배포된 ServiceNow Kubernetes 검색
- MID 서버에서 Google Cloud API로 설정되는 네트워크 경로
- MID 서버가 서버리스 IP 주소 검색이 필요한 모든 Google Cloud VM에 로그인할 수 있도록 지원하는 서비스 계정
- MID 서버에서 서버리스 IP 주소 검색이 필요한 모든 Google Cloud VM에 설정되는 네트워크 경로
ServiceNow 부분은 MID 서버에서 메타데이터를 캡처하여 CMDB에 저장하는 ServiceNow 인스턴스로 구성됩니다.
Agent Client Collector 패턴을 사용한 Google Cloud 검색
이 아키텍처 패턴에는 다음이 포함됩니다.
- 초기 클라우드 검색.
- 하나 이상의 MID 서버.
VM에 설치하는 추가 ServiceNow 에이전트인 에이전트 클라이언트 수집기입니다. 이러한 에이전트는 MID 서버에 직접 연결되어 다음과 같은 추가 정보를 ServiceNow에 전달합니다.
- 거의 실시간 푸시 기반 탐색
- 소프트웨어 측정
- 실시간 CI 보기
- 서버에 대한 워크플로 자동화
이 아키텍처 패턴을 다이어그램으로 나타내면 다음과 같습니다.
이 패턴의 Google Cloud 부분은 다음으로 구성됩니다.
- 서비스 프로젝트 A: 2개의 Google Cloud 부하 분산기, 하나 이상의 VM 인스턴스, GKE 인스턴스, 하나 이상의 ServiceNow MID 서버로 구성 각 MID 서버는 자체 VM에서 실행됩니다.
- 서비스 프로젝트 B: 자체 VM에서 실행되는 MID 서버로 구성
- 호스트 프로젝트 C: Partner interconnect로 구성
- GKE 인프라에 배포된 ServiceNow Kubernetes 검색
- Cloud APIs, BigQuery, Cloud Storage와 같은 추가 관리형 서비스
- MID 서버에서 Google Cloud API로 설정되는 네트워크 경로
- MID 서버에서 ServiceNow 검색 에이전트가 설치된 Google Cloud VM으로 설정된 네트워크 경로.
ServiceNow 부분은 다음으로 구성됩니다.
- MID 서버에서 메타데이터를 캡처하여 CMDB에 저장하는 ServiceNow 인스턴스
- 고객 관리 Google Cloud VM에 설치된 ServiceNow 검색 에이전트
Cloud 애셋 검색 워크플로
다음 섹션에서는 Google Cloud 애셋 검색의 워크플로를 설명합니다. 이 워크플로는 이 문서에 설명된 세 가지 아키텍처 패턴 모두에 적용됩니다.
ServiceNow 구성요소 설치 및 구성
- Cloud Asset Inventory API를 사용 설정합니다.
- VM에 에이전트 클라이언트 수집기를 설치합니다. 자세한 내용은 에이전트 클라이언트 수집기 설치를 참고하세요.
- MID 서버를 호스팅하는 컴퓨터에 리소스를 할당합니다.
- VM 인스턴스와 MID 서버를 호스팅하는 컴퓨터 간에 포트 443에서 연결을 허용하도록 방화벽 규칙을 구성합니다.
- MID 서버 네트워크 연결을 구성합니다.
- MID 서버를 설치합니다.
- 관련 Google Cloud API를 호출하도록 MID 서버를 구성합니다. MID 서버에 Google Cloud API를 호출할 수 있는 유효한 네트워크 경로가 있는지 확인합니다.
워크플로
- Cloud 애셋 인벤토리는 Google Cloud 환경의 모든 지원되는 애셋 유형의 데이터베이스를 컴파일합니다. ServiceNow는 Cloud 애셋 인벤토리를 소스로 사용하여 CMDB를 업데이트하기 위한 추가 정보를 검색합니다.
- ServiceNow MID 서버는 Google Cloud 환경의 모든 애셋에 대한 정보에 대한 Cloud 애셋 인벤토리 데이터베이스를 쿼리합니다.
- MID 서버는 Cloud Storage 버킷에 Cloud 애셋 정보를 저장합니다.
- Cloud 애셋 인벤토리 데이터베이스에서 필요한 모든 정보를 가져올 수 있는 것은 아닙니다. 에이전트리스 패턴에서는 VM 정보에 현재 OS 패치 버전이 포함되지 않습니다. 이러한 수준의 세부정보에 대해 MID 서버는 다음을 수행하여 심층 검색을 수행합니다.
- MID 서버는 심층 검색이 필요한 VM의 IP 주소를 기반으로 일괄 작업을 만듭니다.
- 배치 작업에서 MID 서버는 각 VM에 로그인하고 OS에 패치 버전 관리 및 기타 정보를 쿼리합니다.
- Agent Client Collector가 설치된 경우 캡처한 데이터는 Cloud 애셋 인벤토리 데이터베이스에 저장되지 않고 MID 서버로 직접 전송됩니다. 자세한 내용은 네트워킹 준비 및 MID 서버 구성을 참고하세요.
- MID 서버는 애셋 검색 데이터를 수집한 후 다음과 같이 CMDB에 저장합니다.
- MID 서버는 CMDB에서 각 애셋에서 제공하는 운영 기능을 나타내는 CI를 만듭니다.
- MID 서버는 자동으로 Google Cloud에서 라벨을 검색하고 CMDB에 저장합니다. 이러한 라벨은 CI에 자동으로 매핑되며 서비스 맵을 만드는 데 유용합니다.
워크플로 프로세스는 필요에 따라 주기적으로 반복해야 합니다. 배포의 규모와 구성에 따라 이벤트 기반 또는 일정 기반 탐색을 선택할 수 있습니다. 자세한 내용은 CMDB 설계 가이드의 'CI 수명 주기 관리'를 참고하세요.
설계 고려사항
다음 섹션에서는 이 문서에 설명된 아키텍처 패턴을 구현하기 위한 설계 가이드를 제공합니다.
ServiceNow 인스턴스의 위치
대부분의 사용 사례에서는 Google Cloud에 MID 서버를 배포하는 것이 좋습니다. 이렇게 하면 인스턴스가 심층 검색을 수행하는 클라우드 애셋과 가까워집니다.
이 문서의 아키텍처 패턴에서는 CMDB가 Google Cloud 애셋뿐만 아니라 모든 클라우드 리소스 및 모든 온프레미스 리소스의 검색 데이터를 저장한다고 가정합니다. CMDB는 ServiceNow Cloud, Google Cloud 또는 온프레미스에 위치할 수 있습니다. 환경에서 CMDB를 찾을 위치에 대한 최종 결정은 사용자의 특정 요구사항에 따라 달라집니다.
MID 서버 에이전트 사용 결정
또 다른 설계 고려사항은 MID 서버 에이전트 및 서비스 계정을 사용할지 여부입니다. 검색 프로세스에서 Cloud 애셋 인벤토리가 제공하는 메타데이터 이외의 정보를 수집해야 하는 경우 서비스 계정이 있는 MID 서버 인프라를 사용하거나 에이전트 클라이언트 수집기가 있는 MID 서버를 사용해야 합니다. 두 가지 접근 방식 모두 운영 지원 비용에 영향을 미칠 수 있으므로 설계 시 이를 고려해야 합니다. 사용해야 하는 접근 방식은 캡처해야 하는 데이터와 데이터를 사용하는 방법에 따라 다릅니다. 데이터를 캡처하는 데 드는 운영 비용은 데이터가 제공하는 가치보다 클 수 있습니다.
MID 서버에 대한 멀티 리전 지원
회사에서 MID 서버 인프라에 대한 멀티 리전 지원이 필요한 경우, 2개 이상의 가용성 영역에 각 MID 서버를 배포하고 이를 다른 리전에 복제해야 합니다.
비용 영향
Google Cloud 애셋 검색을 위해 ServiceNow 구성요소를 배포할 위치를 선택할 때 이그레스 비용 및 컴퓨팅 비용을 고려해야 합니다.
이그레스 비용
데이터가 Google Cloud 외부로 이동할 때마다 이그레스 요금이 발생합니다. 따라서 사용 사례에 대한 이그레스 비용을 분석하여 ServiceNow 구성요소를 찾는 최적의 옵션을 결정해야 합니다. 일반적으로 심층 검색을 수행하는 MID 서버는 다른 클라우드 또는 온프레미스에서 실행되는 경우보다 Google Cloud에서 실행되는 경우 이그레스 비용이 더 적게 듭니다.
컴퓨팅 비용
Google Cloud에서 실행되는 ServiceNow 구성요소에는 컴퓨팅 비용이 발생하며, 이를 분석하여 회사에 가장 적합한 가치를 결정해야 합니다.
예를 들어 Google Cloud Compute Engine 인스턴스에 배포하는 MID 서버의 수를 고려해야 합니다. MID 서버를 더 많이 배포하면 저작물 검색 프로세스가 더 빨라집니다. 하지만 이렇게 하면 각 MID 서버가 자체 VM 인스턴스에 배포되므로 컴퓨팅 비용이 증가합니다. 하나 또는 여러 개의 MID 서버를 배포할지에 대한 자세한 내용은 단일 시스템에 여러 MID 서버 설치를 참조하세요.
운영 지원성 고려사항
배포에는 방화벽, 침입 방지 시스템, 침입 감지 시스템, 패킷 미러링 인프라와 같은 네트워크 보안 제어가 포함될 수 있습니다. Google Cloud와 MID 서버가 배포된 환경 사이에 광범위한 네트워크 보안 제어가 마련되어 있는 경우 이러한 제어로 인해 운영 지원 문제가 발생할 수 있습니다. 이러한 문제를 방지하려면 Google Cloud에서 MID 서버를 호스팅하거나 심층 탐색이 쿼리할 Google Cloud 인프라에 최대한 가깝게 호스팅하는 것이 좋습니다.
MID 서버 보안
MID 서버 인스턴스에 대해 다음과 같은 보안 관행을 따르는 것이 좋습니다.
- MID 서버가 신뢰할 수 있는 관리자만 연결할 수 있도록 격리되어 있는지 확인합니다.
- MID 서버가 삭제로부터 보호되는지 확인합니다.
- IAM 역할이 적용되어 변경 기능이 ITIL 프로세스 또는 CI/CD 파이프라인을 통해 승인된 변경사항으로만 제한되는지 확인합니다.
서비스 계정 보호
서비스 계정 관리에 다음과 같은 보안 관행을 따르는 것이 좋습니다.
- MID 서버가 애셋 검색에 절대적으로 필요한 IAM 역할 및 권한만 가진 서비스 계정을 사용하는지 확인합니다. 자세한 내용은 서비스 계정 작업 권장사항을 참조하세요.
- ServiceNow 인증을 사용하려면 서비스 계정 키의 콘텐츠를 ServiceNow 사용자 인터페이스에 복사해야 합니다. 서비스 계정 키를 올바르게 관리하지 않으면 보안 위험을 초래할 수 있습니다. 비공개 키의 보안 및 서비스 계정 키 관리 권장사항에 설명된 다른 작업의 책임은 사용자에게 있습니다. 서비스 계정 키를 만들 수 없는 경우 조직 수준에서 서비스 계정 키 생성이 사용 중지된 것일 수 있습니다. 자세한 내용은 기본 보안별 조직 리소스 관리를 참조하세요.
폴더 및 프로젝트 구조
폴더 및 프로젝트는 Google Cloud 리소스 계층 구조의 노드입니다. 애셋 검색을 지원하려면 폴더 및 프로젝트 구조에 애플리케이션 구조와 해당 애플리케이션이 배포된 환경의 구조를 반영해야 합니다. 이러한 방식으로 리소스를 구성하면 ServiceNow에서 해당 애셋을 제공된 기술 서비스에 매핑할 수도 있습니다.
ServiceNow 검색을 지원하기 위해 폴더 및 프로젝트 구조를 변경할 때는 주의해야 합니다. 폴더 및 프로젝트 구조의 기본 역할은 결제 및 IAM 액세스를 지원하는 것입니다. 따라서 ServiceNow를 지원하기 위해 수행하는 모든 변경사항은 조직의 Google Cloud Billing 구조를 지원하고 이에 연계되어야 합니다. Google Cloud 조직, 폴더 및 프로젝트 계층 구조를 구조화하기 위한 권장사항은 리소스 계층 구조 및 조직 만들기 및 관리를 참조하세요.
다음 다이어그램은 완벽한 형태의 Google Cloud 리소스 계층 구조의 대표적인 예시입니다. 이 예시에서 폴더 구조는 애플리케이션을 정의하고 각 프로젝트는 환경을 정의합니다.
라벨 지정
라벨은 클라우드 리소스에 할당할 수 있는 키-값 쌍입니다. (ServiceNow, AWS, Azure는 라벨을 태그로 나타냅니다.)
ServiceNow는 Google Cloud 자산에 할당한 라벨을 사용하여 애셋을 식별하고 선택적으로 서비스에 매핑합니다. 적절한 라벨 스키마를 선택하면 ServiceNow가 정확한 보고와 ITOM/ITSM 규정 준수를 위해 인프라를 모니터링하는 데 도움이 됩니다.
폴더 및 프로젝트 구조에서 허용하는 것보다 더 구체적인 고유 식별이 필요한 모든 리소스에 라벨을 사용하는 것이 좋습니다. 예를 들어 다음과 같은 경우에 라벨을 사용할 수 있습니다.
- 애플리케이션에 엄격한 규정 준수 요구사항이 있는 경우 모든 애플리케이션 리소스에 라벨을 지정하여 조직에서 범위 내의 모든 인프라를 쉽게 식별할 수 있습니다.
- 멀티클라우드 환경에서 라벨을 사용하여 모든 리소스의 클라우드 제공업체와 리전을 식별할 수 있습니다.
- Google Cloud Billing 보고서 또는 BigQuery로 Cloud Billing 내보내기에서 기본적으로 제공하는 것보다 더 세분화된 가시성이 필요한 경우 데이터를 라벨로 필터링할 수 있습니다.
Google은 VPC에서 실행되는 Google 관리 애셋에 라벨을 자동으로 할당합니다. Google에서 할당한 라벨에는 goog-이라는 프리픽스가 붙습니다. MID 서버는 이러한 애셋에 대한 심층 검사를 시도해서는 안 됩니다. Google 관리 리소스의 라벨에 대한 자세한 내용은 태그 기반 매핑 및 Cloud 애셋 인벤토리 실시간 알림을 기반으로 리소스에 자동으로 라벨 지정을 참조하세요.
다음 표에는 Google Cloud 서비스가 해당 서비스를 관리하는 리소스에 할당하는 라벨이 나열되어 있습니다.
| Google Cloud 서비스 | 라벨 또는 라벨 접두사 |
|---|---|
| Google Kubernetes Engine |
goog-gke-
|
| Compute Engine |
|
| Dataproc |
|
| Vertex AI Workbench |
|
리소스 관리를 효과적으로 지원하려면 조직의 배포 프로세스가 프로젝트 및 폴더 구조를 만들고 전체 조직에 일관되게 애셋 라벨을 할당해야 합니다. 인프라와 라벨 지정의 불일치로 인해 지원되지 않을 가능성이 높고 장기적으로 확장 문제가 발생할 수 있는 수동 프로세스가 없는 경우 올바른 CMDB를 유지하기 어려울 수 있습니다.
다음 목록은 배포 프로세스를 일관되고 반복 가능하게 만드는 권장사항을 보여줍니다.
- Google Cloud Deployment Manager를 사용하여 인프라를 코드(IaC)나 Terraform, ServiceNow ITOM 또는 클라우드 프로비저닝 및 거버넌스와 같은 자동화된 프로비저닝 시스템으로 사용합니다.
- 라벨에 대한 적절한 거버넌스 프로세스를 마련합니다. 라벨 지정 거버넌스에 관한 개요는 ServiceNow 문서의 태그 거버넌스를 참고하세요.
다음 단계
- Cloud Billing에 대한 리소스 구조화를 위한 추가 권장사항은 Cloud Billing 리소스 조직 및 액세스 관리 가이드 및 Google Cloud에 대한 Cloud Insights 설정 가이드를 참조하세요.
- 조직의 IAM 권한 구조화에 대한 권장사항은 계정 및 조직 계획을 위한 권장사항 및 클라우드 프로비저닝 및 거버넌스를 참조하세요.
- 조직 전체에서 VPC 방화벽 정책을 구조화하기 위한 권장사항은 계층식 방화벽 정책을 참고하세요.
- 라벨을 사용하여 ServiceNow 태그 기반 검색을 지원하는 방법을 알아보세요.
- Google Cloud 프로젝트에서 실행되고 MID 서버를 통해 출력 데이터를 ServiceNow 인스턴스로 전송하여 관련 데이터베이스에 이벤트 및 메트릭을 저장하는 푸시 메커니즘인 ServiceNow Agent Client Collector에 대해 알아보세요.
- 그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 알아보려면 Cloud 아키텍처 센터를 확인하세요.