VM 워크로드 배포 개요

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

아키텍처

리소스 계층 구조

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

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

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

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

네트워킹

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

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

• 부하 분산: Cloud Service Mesh는 인프라 확장과 트래픽 흐름을 분리하여 동적 요청 라우팅을 비롯한 다양한 트래픽 관리 기능을 제공합니다. 티켓팅 시스템에는 지속적인 클라이언트 연결이 필요하므로 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

컴퓨팅

티켓팅 시스템에서는 베어메탈 또는 가상 머신을 사용하여 온프레미스 설치를 호스팅하는 것이 좋다고 권장하며, Google Cloud는 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-ticketing-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 이미지의 경우 규정 준수 및 보안 요구사항을 충족하기 위해 맞춤 이미지를 만들었습니다. 실행 중인 VM 인스턴스는 VirtualMachineAccessRequest를 사용하여 SSH를 통해 연결할 수 있으므로 Kubernetes RBAC를 통해 VM에 연결하는 기능을 제한하고 맞춤 이미지에서 로컬 사용자 계정을 만들 필요가 없습니다. 액세스 요청은 시간 기반 액세스 요청이 자동으로 만료되는 VM을 관리할 수 있도록 수명 (TTL)도 정의합니다.

자동화

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

출시 파이프라인

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

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

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

소프트웨어 개발 수명 주기

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

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

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

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

조작성

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

모니터링

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

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

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

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

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

오류 모드

초기 테스트에서 여러 리소스 관련 실패 모드가 발견되었으며, 이를 통해 어떤 측정항목과 알림을 먼저 추가할지 우선순위를 정할 수 있었습니다. 데이터베이스 잘못된 구성으로 인해 버퍼 테이블이 사용 가능한 모든 메모리를 소비하고 과도한 로깅으로 연결된 영구 볼륨 디스크가 채워졌기 때문에 높은 메모리 및 디스크 사용량을 모니터링하는 것부터 시작했습니다. 스토리지 버퍼 크기를 조정하고 로그 순환 전략을 구현한 후 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"

시스템 안정성을 확인한 후 티켓팅 시스템 내 애플리케이션 실패 모드로 초점을 옮겼습니다. 애플리케이션 내 문제를 디버깅하려면 각 애플리케이션 서버 VM에 보안 셸 (SSH)을 사용하여 티켓팅 시스템 로그를 확인해야 하는 경우가 많았으므로 GDC 관측 가능성 스택을 기반으로 하고 모니터링 인스턴스에서 모든 티켓팅 시스템 운영 로그를 쿼리할 수 있도록 이러한 로그를 로깅 도구로 전달하는 애플리케이션을 구성했습니다.

중앙 집중식 로깅을 통해 여러 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

업그레이드

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

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

OS 업그레이드의 경우 각 GDC 출시와 함께 배포되는 애플리케이션 및 데이터베이스 서버용 새 VM 이미지를 지속적으로 빌드하고 출시합니다. 이러한 이미지에는 보안 취약점 수정사항과 기본 운영체제 업데이트가 포함되어 있습니다.

티켓팅 시스템 플랫폼 업그레이드에는 기존 VM 이미지에 업데이트를 적용해야 하므로 불변 인프라를 사용하여 패치 및 주요 출시 버전 업데이트를 실행할 수 없습니다. 플랫폼 업그레이드의 경우 GDC 출시와 함께 독립형 업그레이드 패키지를 출시하기 전에 개발 및 스테이징 환경에서 패치 또는 주요 출시 버전을 테스트하고 확인합니다.

마지막으로 구성 업데이트는 업데이트 세트 및 기타 사용자 데이터를 위한 티켓팅 시스템 API를 통해 다운타임 없이 적용됩니다. Google에서는 GDC 출시 프로세스 중에 여러 업데이트 세트를 함께 패키징하기 전에 개발 및 스테이징 환경에서 구성 업데이트를 개발하고 테스트합니다.

통합

ID 공급업체

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

티켓팅 시스템은 애플리케이션 서버 VM 이미지에서 사전 사용 설정된 다중 ID 공급업체 모듈을 통해 SAML 2.0 및 OIDC 공급업체를 모두 지원합니다. 고객은 조직 ID 제공업체를 통해 인증하며, 이 경우 티켓팅 시스템 내에서 사용자가 자동으로 생성되고 역할이 할당됩니다.

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

알림 수집

사용자가 로그인하여 지원 케이스를 수동으로 만드는 것 외에도 시스템 알림에 따라 티켓팅 시스템 인시던트가 생성됩니다.

이 통합을 위해 애플리케이션에서 알림을 수신하고 Cloud Service Mesh를 통해 노출된 티켓팅 시스템 API 엔드포인트를 사용하여 인시던트의 수명 주기를 관리하도록 오픈소스 Kubernetes 웹훅을 맞춤설정했습니다.

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

이메일

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

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

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

규정 준수

감사 로깅

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

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

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

액세스 제어

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

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

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

재해 복구

데이터베이스 복제

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

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

바이너리 로그 보관 기간보다 오래 실행된 기존 인스턴스의 복제를 사용 설정하려면 데이터베이스 백업을 사용하여 복제본 데이터베이스를 복원하여 기본 데이터베이스에서 복제를 시작하면 됩니다.

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

1. 바이너리 로그를 사용 설정합니다.

2. 서버 ID를 설정합니다.

3. 복제 사용자 계정을 만듭니다.

4. 백업 만들기

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

1. 서버 ID를 설정합니다.

2. 복제 사용자 인증 정보와 호스트, 포트와 같은 기본 연결 세부정보를 구성합니다.

3. 백업에서 복원된 바이너리 로그 위치를 재개합니다.

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