VM 워크로드 배포 개요

이 가이드에서는 VM 런타임을 사용하여 가상 머신 (VM) 기반 워크로드를 베어메탈의 Google Distributed Cloud (GDC) 에어 갭 클러스터에 배포하는 데 필요한 개념적 컨텍스트를 다룹니다. 이 가이드의 워크로드는 온프레미스 하드웨어에서 사용할 수 있는 샘플 ServiceNow 플랫폼입니다.

아키텍처

리소스 계층 구조

GDC에서는 운영팀을 위해 전용 테넌트 조직에 ServiceNow를 구성하는 구성요소를 배포합니다. 이는 모든 고객 조직과 동일합니다. 조직은 함께 관리되는 클러스터, 인프라 리소스, 애플리케이션 워크로드의 모음입니다. GDC 인스턴스의 각 조직은 전용 서버 세트를 사용하여 테넌트 간에 강력한 격리를 제공합니다. 인프라에 관한 자세한 내용은 액세스 경계 설계를 참고하세요.

GDC(에어 갭 적용형) 리소스 계층 구조

또한 소프트웨어 정책 및 시행을 사용하여 조직 내에서 논리적 격리를 제공하는 프로젝트에서 ServiceNow 리소스를 함께 배포하고 관리합니다. 프로젝트의 리소스는 수명 주기가 동일해야 하는 구성요소를 결합하기 위한 것입니다.

ServiceNow는 부하 분산기를 사용하여 영구 데이터를 저장하는 데이터베이스 서버에 연결된 애플리케이션 서버 간에 트래픽을 전달하는 3계층 아키텍처를 따릅니다.

이 아키텍처를 사용하면 각 계층을 독립적으로 개발하고 유지관리할 수 있으므로 확장성과 유지관리성이 향상됩니다. 또한 우려사항을 명확하게 분리하여 디버깅과 문제 해결을 간소화합니다. GDC 프로젝트 내에 이러한 계층을 캡슐화하면 애플리케이션 및 데이터베이스 서버와 같은 구성요소를 함께 배포하고 관리할 수 있습니다.

네트워킹

프로덕션 환경에서 ServiceNow를 실행하려면 노드 장애 발생 시 고가용성을 달성하기 위해 애플리케이션 서버를 2개 이상 배포해야 합니다. 부하 분산기와 결합된 이 토폴로지를 사용하면 여러 머신에 부하를 분산하여 애플리케이션을 수평으로 확장할 수도 있습니다. GDC의 Kubernetes 네이티브 플랫폼은 Cloud Service Mesh를 활용하여 ServiceNow를 구성하는 애플리케이션 서버로 트래픽을 안전하게 라우팅합니다.

Cloud Service Mesh는 서비스를 관리, 관찰, 보호하는 오픈소스 Istio 프로젝트를 기반으로 하는 Google의 구현입니다. 다음 Cloud Service Mesh 기능은 GDC에서 ServiceNow를 호스팅하는 데 활용됩니다.

부하 분산: Cloud Service Mesh는 인프라 확장과 트래픽 흐름을 분리하여 동적 요청 라우팅을 비롯한 다양한 트래픽 관리 기능을 제공합니다. ServiceNow에는 지속적인 클라이언트 연결이 필요하므로 DestinationRules를 사용하여 트래픽 라우팅 동작을 구성하여 고정 세션을 사용 설정합니다.

TLS 종료: Cloud Service Mesh는 TLS 인증서를 사용하여 인그레스 게이트웨이를 노출하고 애플리케이션 코드를 변경하지 않고도 mTLS (상호 전송 계층 보안)를 통해 클러스터 내에서 전송 인증을 제공합니다.
오류 복구: Cloud Service Mesh는 시간 초과, 회로 차단기, 활성 상태 점검, 제한된 재시도 등 여러 중요한 오류 복구 기능을 제공합니다.

Kubernetes 클러스터 내에서 표준 Service 객체를 사용하여 애플리케이션 및 데이터베이스 서버를 네트워크에 노출하는 추상적인 방법을 사용합니다. 서비스는 선택기를 사용하여 인스턴스를 타겟팅하는 편리한 방법을 제공하고 클러스터 인식 DNS 서버를 사용하여 클러스터 내에서 이름 확인을 제공합니다.

apiVersion: v1
kind: Service
metadata:
  name: http-ingress
spec:
  selector:
    app.kubernetes.io/component: application-server
  ports:
  - name: http
    port: 80
---
apiVersion: v1
kind: Service
metadata:
  name: database-ingress
spec:
  selector:
    app.kubernetes.io/component: database-server
  ports:
  - name: mysql
    port: 3306

컴퓨팅

ServiceNow는 베어메탈 또는 가상 머신을 사용하여 온프레미스 설치를 호스팅할 것을 권장하며, Google은 GDC 가상 머신 (VM) 관리를 활용하여 애플리케이션 및 데이터베이스 서버를 VM 워크로드로 배포했습니다. Kubernetes 리소스를 정의하면 다양한 유형의 서버에 대한 요구사항을 충족하도록 리소스를 맞춤설정하기 위해 VirtualMachine와 VirtualMachineDisk를 모두 지정할 수 있었습니다. VirtualMachineExternalAccess를 사용하면 VM의 데이터 전송 인 및 데이터 전송 아웃을 구성할 수 있습니다.

apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineDisk
metadata:
  name: vm1-boot-disk
spec:
  size: 100G
  source:
    image:
      name: ts-service-now-system-app-server-2023-08-18-203258
      namespace: vm-system
---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachine
metadata:
  labels:
    app.kubernetes.io/component: application-server
  name: vm1
  namespace: support
spec:
  compute:
    vcpus: 8
    memory: 12G
  disks:
  - boot: true
    virtualMachineDiskRef:
      name: vm1-boot-disk

---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineExternalAccess
metadata:
  name: vm1
  namespace: support
spec:
  enabled: true
  ports:
   - name: ssh
     protocol: TCP
     port: 22

게스트 OS 이미지의 경우 규정 준수 및 보안 요구사항을 충족하기 위해 Red Hat Enterprise Linux를 기반으로 맞춤 이미지를 만들었습니다. VirtualMachineAccessRequest를 사용하여 실행 중인 VM 인스턴스에 SSH를 통해 연결할 수 있습니다. 이를 통해 Kubernetes RBAC를 통해 VM에 연결하는 기능을 제한하고 맞춤 이미지에서 로컬 사용자 계정을 만들 필요가 없습니다. 액세스 요청은 시간 기반 액세스 요청이 자동으로 만료되는 VM을 관리할 수 있도록 수명 (TTL)도 정의합니다.

자동화

이 프로젝트의 주요 결과물로, 광범위한 자동화를 지원하고 배포 간 구성 드리프트를 줄일 수 있는 반복 가능한 방식으로 ServiceNow 인스턴스를 설치하는 접근 방식을 설계했습니다.

Helm 패키징

Helm은 애플리케이션을 구성하는 모든 구성요소의 설치 및 업그레이드를 비롯하여 애플리케이션의 수명 주기를 관리하는 Kubernetes용 패키지 관리자입니다. Helm은 관측 가능성 및 규정 준수와 같은 다른 시스템과 통합하는 데 필요한 맞춤 리소스와 같은 종속 항목을 관리하는 방법도 제공합니다. Helm 차트를 만들면 이러한 리소스를 캡슐화하여 ServiceNow 설치 및 관리 프로세스를 간소화할 수 있습니다.

출시 파이프라인

애플리케이션 및 데이터베이스 서버 이미지 맞춤설정은 기본 운영체제 이미지에서 시작하여 각 서버 이미지에 필요한 종속 항목을 설치하기 위해 필요에 따라 기본 이미지를 수정합니다. 온프레미스 설치에서 ServiceNow를 호스팅하는 데 널리 사용되는 Red Hat Enterprise Linux(RHEL)를 기본 OS 이미지로 선택했습니다. 또한 Red Hat Enterprise Linux는 NIST-800-53 컨트롤을 충족하는 규정 준수 이미지를 제공하는 데 필요한 보안 기술 구현 가이드(STIG)를 충족하는 데 필요한 보안 강화 기능을 제공합니다.

지속적 통합 (CI) 파이프라인은 다음 워크플로를 사용하여 애플리케이션 및 데이터베이스 서버 이미지를 맞춤설정했습니다.

지속적 통합 워크플로

개발자가 맞춤설정 스크립트나 이미지 종속 항목을 변경하면 CI 도구에서 자동화된 워크플로가 트리거되어 GDC 출시와 번들로 제공되는 새로운 이미지 세트가 생성됩니다. 이미지 빌드의 일환으로 OS 종속 항목 (yum 업데이트)도 새로고침하고 압축을 통해 이미지를 스파스화하여 이미지를 고객 환경으로 전송하는 데 필요한 이미지 크기를 줄입니다.

소프트웨어 개발 수명 주기

소프트웨어 개발 수명 주기 (SDLC)는 조직이 소프트웨어를 계획, 생성, 테스트, 배포하는 데 도움이 되는 프로세스입니다. 잘 정의된 SDLC를 따르면 조직은 일관되고 반복 가능한 방식으로 소프트웨어를 개발하고 잠재적인 문제를 조기에 식별할 수 있습니다. 지속적 통합 (CI) 파이프라인에서 이미지를 빌드하는 것 외에도 테스트 및 품질 보증을 위해 사전 출시 버전의 ServiceNow를 개발하고 스테이징할 환경을 정의했습니다.

GDC 프로젝트별로 별도의 ServiceNow 인스턴스를 배포하면 동일한 GDC 인스턴스의 기존 인스턴스에 영향을 주지 않고 변경사항을 격리된 상태로 테스트할 수 있었습니다. ResourceManager API를 사용하여 Kubernetes 리소스를 통해 선언적으로 프로젝트를 만들고 해체했습니다.

apiVersion: resourcemanager.gdc.goog/v1
kind: Project
metadata:
  name: service-now-dev
---
apiVersion: resourcemanager.gdc.goog/v1
kind: Project
metadata:
  name: service-now-qa
---
apiVersion: resourcemanager.gdc.goog/v1
kind: Project
metadata:
  name: service-now-staging

Helm 차트 패키징 및 가상 머신과 같은 인프라를 코드로 관리하는 것과 결합하여 개발자는 변경사항을 빠르게 반복하고 프로덕션 인스턴스와 함께 새로운 기능을 테스트할 수 있습니다. 선언적 API를 사용하면 자동 테스트 실행 프레임워크가 정기 회귀 테스트를 실행하고 기존 기능을 확인할 수도 있습니다.

조작성

운영성은 시스템을 운영하고 유지관리하는 용이성입니다. 이는 모든 소프트웨어 애플리케이션 설계에서 중요한 고려사항입니다. 효과적인 모니터링은 시스템에 큰 영향을 미치기 전에 문제를 식별하고 해결할 수 있으므로 작동성에 기여합니다. 모니터링을 사용하여 개선 기회를 파악하고 서비스 수준 목표 (SLO)의 기준을 설정할 수도 있습니다.

모니터링

로깅 및 측정항목을 비롯한 기존 GDC 관측 가능성 인프라와 ServiceNow를 통합했습니다. 측정항목의 경우 Prometheus가 애플리케이션 및 데이터베이스 서버에서 생성된 데이터 포인트를 스크랩할 수 있도록 각 VM에서 HTTP 엔드포인트를 노출합니다. 이러한 엔드포인트에는 Prometheus 노드 내보내기 도구를 사용하여 수집된 시스템 측정항목과 MySQL 데이터베이스 내보내기 도구를 사용하는 등 애플리케이션별 측정항목이 포함됩니다.

각 VM에 노출된 엔드포인트를 사용하여 MonitoringTarget 커스텀 리소스를 사용하여 스크래핑 간격을 정의하고 측정항목에 주석을 달아 Prometheus 폴링 동작을 구성했습니다.

apiVersion: monitoring.gdc.goog/v1
kind: MonitoringTarget
metadata:
  name: database-monitor
spec:
  podMetricsEndpoints:
    path:
      value: /metrics
    port:
      annotation: application.io/dbMetrics
    scrapeInterval: 60s

로깅을 위해 각 VM에 FluentBit을 설치하고 구성하여 관련 로그를 추적하고 로그 데이터를 Loki로 전송했습니다. Loki에서는 Grafana를 통해 데이터가 색인화되고 쿼리됩니다. 감사 로그는 규정 준수를 위해 보관 기간이 연장된 특수 엔드포인트로 전달됩니다. 컨테이너 기반 애플리케이션은 LoggingTarget 및 AuditLoggingTarget 커스텀 리소스를 사용하여 로깅 파이프라인이 프로젝트의 특정 서비스에서 로그를 수집하도록 지시할 수 있습니다.

Prometheus와 Loki에서 제공되는 데이터를 기반으로 MonitoringRule 커스텀 리소스를 사용하여 알림을 만들었습니다. 이를 통해 Helm 차트에서 이 구성을 코드로 관리할 수 있습니다. 선언적 API를 사용하여 알림과 대시보드를 정의하면 Git 저장소에 이 구성을 저장하고 다른 코드 변경사항에 사용하는 것과 동일한 코드 검토 및 지속적 통합 프로세스를 따를 수 있습니다.

오류 모드

초기 테스트에서 여러 리소스 관련 실패 모드가 발견되었으며, 이를 통해 어떤 측정항목과 알림을 먼저 추가할지 우선순위를 정할 수 있었습니다. 데이터베이스 잘못된 구성으로 인해 버퍼 테이블이 사용 가능한 모든 메모리를 소비하고 과도한 로깅으로 연결된 영구 볼륨 디스크가 채워졌기 때문에 높은 메모리 및 디스크 사용량을 모니터링하는 것부터 시작했습니다. InnoDB 버퍼 크기를 조정하고 로그 순환 전략을 구현한 후 VM이 높은 메모리 또는 디스크 사용량에 접근하는 경우 실행되는 알림을 도입했습니다. 또한 운영자가 알림이 발생할 경우 문제를 진단하고 완화하는 방법을 설명하는 문서를 빠르게 검토할 수 있도록 런북을 작성하고 오류 코드를 할당했습니다.

apiVersion: monitoring.gdc.goog/v1
kind: MonitoringRule
metadata:
  name: monitoring-rule
spec:
  interval: 60s
  limit: 0
  alertRules:
  - alert: vm1_disk_usage
    expr:
      (node_filesystem_size_bytes{container_name="compute"} -
      node_filesystem_avail_bytes{container_name="compute"}) * 100 /
      node_filesystem_size_bytes{container_name="compute"} > 90
    labels:
      severity: error
      code: <a href="/distributed-cloud/hosted/docs/latest/gdch/gdch-io/service-manual/ts/runbooks/ts-r0001">TS-R0001</a>
      resource: vm1
    annotations:
      message: "vm1 disk usage above 90% utilization"

시스템 안정성을 확인한 후 ServiceNow 내의 애플리케이션 실패 모드로 초점을 전환했습니다. 애플리케이션 내 문제를 디버깅하려면 각 애플리케이션 서버 VM에 보안 셸 (SSH)을 사용하여 ServiceNow 시스템 로그를 확인해야 하는 경우가 많았으므로 FluentBit를 구성하여 이러한 로그를 Loki로 전달하여 GDC 관측 가능성 스택을 빌드하고 Grafana에서 모든 ServiceNow 운영 로그를 쿼리했습니다.

중앙 집중식 로깅을 통해 여러 VM의 로그를 동시에 쿼리하여 시스템의 각 구성요소에 대한 뷰를 통합할 수도 있었습니다. 그런 다음 로그 검색 쿼리를 런북에 통합하여 운영자가 오류 조건을 알려진 해결 방법 및 솔루션과 일치시킬 수 있도록 했습니다.

백업

백업은 장애 발생 시 시스템을 복원할 수 있으므로 소프트웨어 시스템의 작동 가능성에 중요합니다. GDC는 Kubernetes 리소스를 통해 VM 백업 및 복원을 제공합니다. VirtualMachineBackupPlanTemplate 커스텀 리소스로 VirtualMachineBackupRequest 커스텀 리소스를 만들면 각 VM에 연결된 영구 볼륨을 객체 스토리지에 백업할 수 있습니다. 여기서 백업은 버킷을 통해 설정된 보관 정책에 따라 보관할 수 있습니다.

apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineBackupPlanTemplate
metadata:
  name: vm-backup-plan
spec:
  backupRepository: "backup-repository"
---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineBackupRequest
metadata:
  name: "db-vm-backup"
spec:
  virtualMachineBackupPlanTemplate: vm-backup-plan
  virtualMachine: db1
  virtualMachineBackupName: db-vm-backup

마찬가지로 백업에서 VM 상태를 복원하려면 VirtualMachineRestoreRequest 커스텀 리소스를 만들어 두 서비스의 코드나 구성을 수정하지 않고 애플리케이션과 데이터베이스 서버를 모두 복원해야 합니다.

apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineRestoreRequest
metadata:
  name: vm-restore-1
spec:
  virtualMachineBackup: db-vm-backup
  restoreName: restore1
  restoredResourceName: db1

업그레이드

ServiceNow 및 종속 항목의 소프트웨어 수명 주기를 지원하기 위해 Google에서는 세 가지 유형의 소프트웨어 업그레이드를 식별했으며, 각 업그레이드는 다운타임과 서비스 중단을 최소화하기 위해 약간 다르게 처리됩니다.

OS 업그레이드
패치 및 주 버전과 같은 플랫폼 업그레이드
구성 업데이트

OS 업그레이드의 경우 각 GDC 출시와 함께 배포되는 애플리케이션 및 데이터베이스 서버용 새 VM 이미지를 지속적으로 빌드하고 출시합니다. 이러한 이미지에는 보안 취약점 수정사항과 기본 Red Hat 운영체제 업데이트가 포함되어 있습니다. 새 이미지를 배포하기 위해 운영자는 새 VM을 업로드하고 실행하고, 구성을 확인하고, 이전 인스턴스를 폐기하는 데 필요한 단계를 자세히 설명하는 런북을 따릅니다.

ServiceNow 플랫폼 업그레이드에는 기존 VM 이미지에 업데이트를 적용해야 하므로 패치 및 주요 출시 버전 업데이트를 실행하기 위해 불변 인프라를 사용할 수 없습니다. 플랫폼 업그레이드의 경우 GDC 출시와 함께 독립형 업그레이드 패키지를 출시하기 전에 개발 및 스테이징 환경에서 패치 또는 주요 출시 버전을 테스트하고 확인합니다. 패치와 주요 버전 업그레이드를 적용하기 위해 운영자는 런북에 따라 기존 VM 인스턴스에 연결하고 업그레이드 패키지를 업로드하며 실행 중인 각 VM에서 업그레이드를 시작합니다.

마지막으로 구성 업데이트는 업데이트 세트 및 기타 사용자 데이터를 위한 ServiceNow API를 사용하여 다운타임 없이 적용됩니다. Google은 GDC 출시 프로세스 중에 여러 업데이트 세트를 함께 패키징하기 전에 개발 및 스테이징 환경에서 구성 업데이트를 개발하고 테스트합니다. 그런 다음 운영자는 런북에 따라 업데이트 세트를 업로드하고 적용하기 위해 적절한 ServiceNow API를 호출하는 Google에서 개발한 명령줄 도구를 호출합니다.

통합

ID 공급업체

고객에게 원활한 여정을 제공하고 조직에서 사용자를 온보딩할 수 있도록 Google은 GDC에서 사용할 수 있는 여러 ID 공급업체와 ServiceNow를 통합합니다. 일반적으로 엔터프라이즈 및 공공 부문 고객은 직원에게 권한을 부여하고 취소하기 위해 Active Directory 또는 기타 시스템과 같은 잘 관리된 자체 ID 제공업체를 보유하고 있습니다. 규정 준수 요구사항과 ID 및 액세스 관리의 용이성으로 인해 이러한 고객은 기존 ID 공급업체를 정보 소스로 사용하여 ServiceNow에 대한 직원 액세스를 관리하려고 합니다.

ServiceNow 멀티테넌시 개요

ServiceNow는 애플리케이션 서버 VM 이미지에서 사전 사용 설정한 다중 ID 공급업체 모듈을 통해 SAML 2.0 및 OIDC 공급업체를 모두 지원합니다. 인프라 운영자 (IO)와 고객은 모두 조직 ID 공급업체를 통해 인증하며, 이를 통해 ServiceNow 내에서 사용자가 자동으로 생성되고 역할이 할당됩니다.

ID 공급업체 서버로의 이그레스는 ProjectNetworkPolicy 커스텀 리소스를 통해 허용되며, 이는 GDC의 조직에서 외부 서비스에 연결할 수 있는지를 제한합니다. 이러한 정책을 사용하면 ServiceNow가 네트워크에서 액세스할 수 있는 엔드포인트를 선언적으로 제어할 수 있습니다.

알림 수집

사용자가 로그인하여 지원 케이스를 수동으로 만드는 것 외에도 시스템 알림에 대한 응답으로 ServiceNow 인시던트를 생성하기 위해 Prometheus AlertManager와 통합됩니다. 이 통합을 통해 운영자는 관측 가능성 및 티켓팅 시스템을 중앙 진입점과 연결하여 GDC 환경 내에서 소프트웨어 및 하드웨어 문제를 분류하고 해결할 수 있습니다.

이 통합을 위해 Prometheus에서 알림을 수신하고 Cloud Service Mesh를 통해 노출된 ServiceNow API 엔드포인트를 사용하여 인시던트의 수명 주기를 관리하도록 오픈소스 Kubernetes 웹훅을 맞춤설정했습니다. ServiceNow에서 인시던트가 생성되면 운영자는 인시던트 워크플로를 시작하여 인시던트가 발생할 때 이를 분류하고 우선순위를 지정할 수 있으며, 링크를 따라 Grafana에서 트리거된 알림의 실시간 상태를 확인할 수 있습니다.

API 키는 역할 기반 액세스 제어 (RBAC)를 통해 제어되는 Kubernetes 보안 비밀로 지원되는 GDC 보안 비밀 저장소를 사용하여 저장됩니다. API 엔드포인트 및 인시던트 맞춤설정 필드와 같은 기타 구성은 Kubernetes ConfigMap 키-값 스토리지를 통해 관리됩니다.

이메일

ServiceNow는 고객이 이메일 기반 지원을 받을 수 있도록 메일 서버 통합을 제공합니다. 자동화된 워크플로는 인바운드 고객 이메일을 지원 케이스로 변환하고 케이스 링크가 포함된 자동 답장을 고객에게 전송하여 지원팀이 받은편지함을 더 잘 관리하고, 이메일 요청을 체계적으로 추적 및 해결하고, 더 나은 고객 서비스를 제공할 수 있도록 지원합니다.

GDC에 노출된 SMTP 및 POP3 서비스와 통합하기 위해 네트워크 정책을 사용하여 프로젝트 간 액세스를 제어합니다. 별도의 프로젝트에서 이메일 구성요소를 호스팅하면 다른 애플리케이션에서 재사용할 수 있는 서비스로 이메일을 분리할 수 있습니다.

apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  name: allow-ingress-traffic-from-service-now
spec:
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - projects:
        matchNames:
        - service-now

이메일을 Kubernetes 서비스로 노출하면 서비스 검색 및 도메인 이름 확인도 제공되며 ServiceNow와 같은 클라이언트에서 이메일 서버 백엔드가 더욱 분리됩니다.

규정 준수

감사 로깅

감사 로그는 소프트웨어 사용을 추적 및 모니터링하고 시스템 활동 기록을 제공하여 규정 준수 태세에 기여합니다. 감사 로그는 승인되지 않은 사용자의 액세스 시도를 기록하고, API 사용량을 추적하며, 잠재적인 보안 위험을 식별합니다. 감사 로그는 건강보험 이전 및 책임법 (HIPAA), 결제 카드 산업 데이터 보안 표준 (PCI DSS), 사베인즈 옥슬리법 (SOX)에서 부과하는 요구사항과 같은 규정 준수 요구사항을 충족합니다.

GDC는 플랫폼 내에서 관리 활동 및 액세스를 기록하고 이러한 로그를 구성 가능한 기간 동안 보관하는 시스템을 제공합니다. AuditLoggingTarget 커스텀 리소스를 배포하면 애플리케이션에서 감사 로그를 수집하도록 로깅 파이프라인이 구성됩니다.

ServiceNow의 경우 Red Hat Enterprise Linux의 auditd 데몬에서 수집된 시스템 감사 이벤트와 ServiceNow 보안 감사 로그에서 생성된 애플리케이션별 이벤트 모두에 대해 감사 로깅 타겟을 구성했습니다. 두 유형의 로그는 모두 중앙 집중식 Loki 인스턴스로 전송되며, 여기에서 쿼리를 작성하고 Grafana에서 대시보드를 볼 수 있습니다.

액세스 제어

액세스 제어는 액세스를 요청하는 사용자 또는 프로세스의 ID를 기반으로 리소스에 대한 액세스를 허용하거나 거부하는 프로세스입니다. 이렇게 하면 무단 액세스로부터 데이터를 보호하고 승인된 사용자만 시스템을 변경할 수 있습니다. GDC에서는 Kubernetes RBAC를 사용하여 정책을 선언하고 ServiceNow 애플리케이션으로 구성된 시스템 리소스에 대한 승인을 적용합니다.

GDC에서 ProjectRole를 정의하면 사전 설정된 승인 역할을 사용하여 Kubernetes 리소스에 대한 세부적인 액세스 권한을 부여할 수 있습니다. VM 관리자 (vm-admin) 역할과 같은 기존 역할과 결합하여 운영자는 문제를 디버그하고 정기 유지보수를 실행하기 위해 하나 이상의 역할에 바인드할 수 있습니다.

GDC에서 ProjectRole를 정의하면 사전 설정된 승인 역할을 사용하여 Kubernetes 리소스에 대한 세부적인 액세스 권한을 부여할 수 있습니다.

apiVersion: resourcemanager.gdc.goog/v1
kind: ProjectRole
metadata:
  name: service-now-admin
  labels:
    resourcemanager.gdc.goog/rbac-selector: system
spec:
  rules:
  - apiGroups:
    - ""
    resources:
    - configmaps
    - events
    - pods/log
    - services
    verbs:
    - get
    - list

Gitlab과 같은 코드형 인프라 (IaC) 시스템과 구성 관리와 같은 동기화 서비스를 통해 역할과 역할 바인딩을 관리하면 승인 프로세스를 통해 운영자가 역할에 대한 임시 상승된 액세스 권한을 얻을 수 있습니다. 이러한 시스템은 시스템 변경사항의 감사 로그를 유지하면서 시스템에 대한 시간 제한 액세스도 제공합니다.

런북

런북은 작업을 완료하기 위한 단계별 가이드를 제공하므로 규정을 준수하는 소프트웨어 애플리케이션을 유지하는 데 중요합니다. 이렇게 하면 모든 작업이 올바르게 완료되고 모든 관련 법률 및 규정을 준수하는 데 도움이 됩니다. 또한 런북은 모든 팀 구성원이 자신의 책임과 이를 완료하는 방법을 알 수 있도록 지원합니다. Google에서는 ServiceNow의 암호 순환, 서버 다시 시작, 기타 표준 운영 절차 (SOP)와 같은 관리 작업을 실행하기 위한 런북을 작성했습니다.

재해 복구

데이터베이스 복제

재해 복구 (DR) 요구사항을 충족하기 위해 여러 GDC 인스턴스에 기본-보조 구성으로 ServiceNow를 배포합니다. 이 모드에서는 ServiceNow에 대한 요청이 일반적으로 기본 사이트로 라우팅되는 반면 보조 사이트는 MariaDB 데이터베이스의 바이너리 로그를 지속적으로 복제합니다. 장애 조치 이벤트가 발생하면 보조 사이트가 새 기본 사이트로 승격되고 요청이 새 기본 사이트로 라우팅됩니다.

MariaDB 복제

MariaDB 복제 기능을 기반으로 Helm 배포 중에 설정된 매개변수에 따라 GDC 인스턴스별로 기본 및 복제 데이터베이스 서버를 모두 구성합니다.

바이너리 로그 보관 기간보다 오래 실행된 기존 인스턴스의 복제를 사용 설정하려면 Mariabackup을 사용하여 복제본 데이터베이스를 복원하면 됩니다. Mariabackup은 기본 데이터베이스에서 복제를 시작하기 위해 전역 트랜잭션 ID (GTID)도 기록합니다.

기본 모드에서 애플리케이션 서버와 데이터베이스는 현재와 동일하게 작동하지만 기본 데이터베이스는 복제를 사용 설정하도록 구성됩니다. 예를 들면 다음과 같습니다.

바이너리 로그를 사용 설정합니다.
서버 ID를 설정합니다.
복제 사용자 계정을 만듭니다.
GTID 정보를 포함하는 백업을 만듭니다.

복제본 모드에서 애플리케이션 서버는 복제본 데이터베이스에 직접 연결하지 않도록 ServiceNow 웹 서비스를 사용 중지합니다. 복제본 데이터베이스는 기본 데이터베이스에서 복제를 시작하도록 구성해야 합니다. 예를 들면 다음과 같습니다.

서버 ID를 설정합니다.
복제 사용자 인증 정보와 호스트, 포트와 같은 기본 연결 세부정보를 구성합니다.
백업에서 복원하면 GTID에서 바이너리 로그 위치가 재개됩니다.

데이터베이스 복제에는 복제본이 기본 데이터베이스에 연결하여 복제를 시작할 수 있도록 네트워크 연결이 필요합니다. 복제를 위해 기본 데이터베이스 엔드포인트를 노출하려면 Cloud Service Mesh를 사용하여 Istio 게이트웨이에서 TLS 종료를 지원하는 Istio Ingress 게이트웨이를 만들면 됩니다. 이는 ServiceNow 웹 애플리케이션에서 HTTPS 데이터 전송을 처리하는 방식과 유사합니다.

장애 조치 절차

장애 조치가 발생하면 보조 사이트가 새로운 기본 사이트로 승격되고 요청이 새로운 기본 사이트로 라우팅됩니다. 이 프로세스는 처음에는 수동 절차이지만 추가 노력을 통해 점점 더 자동화할 수 있습니다.

기본 사이트에서 다음을 실행합니다.

애플리케이션 서버에서 ServiceNow 서비스를 중지합니다.
복제본 모드로 데이터베이스 서버를 구성합니다.
애플리케이션 서버에서 사용하는 경우 리버스 프록시 서비스를 시작합니다.

보조 사이트에서 다음을 실행합니다.

데이터베이스 서버에서 복제를 중지합니다.
애플리케이션 서버에서 사용하는 경우 역방향 프록시 서비스를 중지합니다.
기본 모드의 데이터베이스 서버를 구성합니다.
애플리케이션 서버에서 ServiceNow 서비스를 시작합니다.

런북에 문서화된 장애 조치 절차를 마련하면 재해 발생 시 작업이 중단되지 않으며 재해로부터 복구하는 데 걸리는 시간이 단축됩니다.

VM 워크로드 배포 개요 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.