Spanner Omni 배포 업그레이드

이 문서에서는 Spanner Omni 배포를 이전 버전에서 이후 버전으로 업그레이드하는 방법을 설명합니다.

Spanner Omni는 비동기식 단계적 출시 상태 머신을 사용하여 서비스 중단 없이 안전하게 업그레이드할 수 있습니다. 단계별로 업그레이드하면 다음을 수행할 수 있습니다.

• 데이터베이스 스키마 업데이트를 적용합니다.
• 순차적 다시 시작 중에 바이너리 호환성을 확인합니다.
• 완료 전에 오류가 감지되면 이전 버전으로 롤백합니다.

지원되는 업그레이드 경로

• LTS 버전은 다음 LTS 버전으로만 업데이트할 수 있습니다. 최신 LTS 버전으로 업데이트할 때는 버전을 건너뛸 수 없습니다.

• 출시일 사이에 LTS 출시가 없는 경우 한 단기 지원 (STS) 버전에서 다른 STS 버전으로 업그레이드할 때 버전을 건너뛸 수 있습니다.

자세한 내용은 버전 지원 정책을 참조하세요.

워크플로 업그레이드

Spanner Omni 업그레이드 프로세스는 여러 순차적 단계로 구성됩니다.

1. 스키마 단계: 대상 바이너리 버전을 사용하여 내부 데이터베이스 스키마 마이그레이션을 실행하여 배포를 준비합니다. 스키마 마이그레이션은 롤백할 수 없지만 이전 바이너리 버전과 하위 호환됩니다.
2. 바이너리 단계: 순차적 다시 시작을 사용하여 배포의 모든 서버에서 서버 바이너리 또는 컨테이너 이미지를 업데이트합니다. 오류가 감지되면 완료가 시작되기 전에 언제든지 바이너리 또는 컨테이너 이미지를 이전 버전으로 롤백할 수 있습니다.
3. 기능 사용 설정 단계: 버전 호환 기능을 사용 설정하고 모든 서버에서 바이너리를 업그레이드한 후 시작됩니다. 업그레이드에 버전 호환 기능이 포함되지 않은 경우 이 단계가 적용되지 않을 수 있으며, 기능이 상호 의존적인 경우 여러 단계가 필요할 수 있습니다. 롤백을 지원하는 선택적 단계의 경우 Spanner Omni CLI를 사용하여 롤백을 시작할 수 있습니다.
4. 완료 단계: 출시를 완료하고 대상 버전을 확정합니다. 완료 단계가 시작된 후에는 롤백할 수 없습니다.

시작하기 전에

Spanner Omni 배포를 업그레이드하기 전에 다음 기본 요건을 충족하는지 확인하세요.

• 실행 중인 Spanner Omni 배포가 있습니다. 자세한 내용은 Kubernetes에서 배포 만들기 또는 VM에서 배포 만들기를 참조하세요.
• Spanner Omni CLI를 다운로드하고 설치했습니다.
• CLI 명령어를 실행하는 머신에서 모든 Spanner Omni 내부 포트(TCP 15000~15027)에 대한 네트워크 액세스 권한 또는 배포 엔드포인트에 대한 네트워크 액세스 권한이 있습니다.
• 배포에서 전송 계층 보안 (TLS) 또는 상호 TLS (mTLS) 암호화를 사용하는 경우 BASE_DIR/tls 아래의 기본 디렉터리에서 유효한 인증서를 사용할 수 있거나 클러스터에 마운트되어 있는지 확인합니다.
• 타겟 출시 버전을 식별했습니다.
  • VM 배포: 대상 출시 패키지 spanner-omni-server-TARGET_VERSION.tar.gz를 다운로드합니다.
  • Helm 및 Kubernetes 배포의 경우 Artifact Registry에서 대상 컨테이너 이미지(예: us-docker.pkg.dev/spanner-omni/images/spanner-omni:TARGET_VERSION)를 식별합니다.
• Spanner Omni 배포 관리자는 업그레이드를 위한 유지보수 기간을 예약해야 합니다. 조직은 업그레이드 유지보수 기간 동안 배포를 피해야 합니다.

1단계: 스키마 업그레이드 준비

업그레이드를 시작하려면 대상 버전의 출시를 준비합니다. 이 단계에서 Spanner Omni는 기존 서버가 트래픽을 계속 처리하는 동안 내부 데이터베이스 스키마 마이그레이션을 실행합니다.

배포 환경에 해당하는 탭을 선택합니다.

VM

VM 배포에서 대상 출시 버전 패키지를 다운로드하고 압축을 푼 다음 압축을 푼 Spanner Omni CLI를 사용하여 출시 준비를 시작합니다.

중요: 대상 Spanner Omni 출시 패키지에는 spanner CLI와 spanner_server 바이너리 (일반적으로 bin/ 아래)가 모두 포함되어 있습니다. 준비 단계를 실행하기 전에 호스트에서 대상 출시 패키지를 다운로드하고 추출합니다.

1. 모든 Spanner Omni 내부 포트 (TCP 15000~15027)에 대한 네트워크 액세스 권한이 있는 배포의 서버에 로그인합니다.

2. 대상 출시 버전 패키지를 다운로드하고 압축을 풉니다.

   tar -xzf spanner-omni-server-TARGET_VERSION.tar.gz -C EXTRACT_DIR
   

   다음을 바꿉니다.

   • TARGET_VERSION: 업그레이드할 대상 버전입니다(예: 2026.r5).
   • EXTRACT_DIR: 출시 패키지를 추출하는 디렉터리입니다(예: /tmp/target_spanner/).

3. 추출된 CLI에서 rollouts prepare 명령어를 실행하여 출시 준비를 시작합니다.

   EXTRACT_DIR/bin/spanner deployment rollouts prepare \
     --target-server-binary=EXTRACT_DIR/bin/spanner_server \
     --root-server=ROOT_SERVERS \
     --base-dir=BASE_DIR
   

   다음을 바꿉니다.

   • EXTRACT_DIR: 대상 bin/spanner CLI 및 bin/spanner_server 바이너리가 포함된 추출 디렉터리입니다.
   • ROOT_SERVERS: 루트 서버 엔드포인트 하나 또는 여러 루트 서버의 쉼표로 구분된 목록(예: localhost:15000 또는 server1:15000,server2:15000,server3:15000)
   • BASE_DIR: Spanner Omni의 기본 디렉터리입니다(예: /spanner).
   • 배포에서 TLS 또는 mTLS 암호화를 사용하는 경우 유효한 인증서를 가리키는 --ca-certificate-file=CA_CERT_FILE 및 --client-certificate-directory=CERT_DIR를 추가합니다.

Helm

Helm 배포에서 스키마 준비는 멀티 서버 배포를 실행하는지 또는 단일 서버 배포를 실행하는지에 따라 달라집니다.

• 멀티 서버 배포 (고가용성/프로덕션): Helm은 스키마 준비를 자동으로 처리합니다. 3단계: 바이너리 또는 컨테이너 이미지 업데이트에서 helm upgrade를 실행하면 Helm 차트가 spanner-prepare-for-upgrade 업그레이드 전 후크 작업을 트리거하여 StatefulSet를 업데이트하기 전에 스키마 마이그레이션을 실행합니다. 2단계: 활성 출시 상태 확인으로 바로 진행합니다.

• 단일 서버 배포 (deployment.singleServer=true): 단일 서버 모드는 내부 서비스를 루프백 인터페이스 (127.0.0.1)에 엄격하게 바인딩하므로 네트워크 작업이 도달할 수 없습니다. 대상 컨테이너 이미지와 함께 임시 디버그 컨테이너를 사용하여 실행 중인 포드 내에서 로컬로 스키마 마이그레이션을 실행합니다.

  kubectl debug pod/POD_NAME -n NAMESPACE \
    --image=us-docker.pkg.dev/spanner-omni/images/spanner-omni:TARGET_VERSION \
    --container=upgrade-prepare -i \
    -- /google/spanner/bin/spanner_server prepare_for_upgrade --root_server=127.0.0.1
  

  다음을 바꿉니다.

  • POD_NAME: 서버 포드의 이름입니다(예: spanner-a-0).
  • NAMESPACE: 배포의 Kubernetes 네임스페이스입니다(예: spanner-ns).
  • TARGET_VERSION: 업그레이드할 대상 버전입니다(예: 2026.r5).

독립형 Kubernetes

Helm 없이 Kubernetes에 Spanner Omni를 배포하는 경우 독립형 Kubernetes 일괄 작업을 실행하여 대상 이미지를 사용하여 활성 루트 서버에 대해 스키마 마이그레이션을 실행합니다.

1. 다음 작업 매니페스트를 사용하여 spanner-prepare-upgrade.yaml이라는 파일을 만듭니다.

   apiVersion: batch/v1
   kind: Job
   metadata:
     namespace: NAMESPACE
     name: spanner-prepare-for-upgrade
   spec:
     # Fail fast on the first error to stop the rollout immediately.
     backoffLimit: 0
     template:
       metadata:
         namespace: NAMESPACE
       spec:
         restartPolicy: Never
         containers:
           - name: spanner-upgrade
             image: us-docker.pkg.dev/spanner-omni/images/spanner-omni:TARGET_VERSION
             command: ["/google/spanner/bin/spanner_server"]
             args:
               - "prepare_for_upgrade"
               - "--root_server=ROOT_SERVER_ENDPOINT"
             volumeMounts:
               - name: tls-certs
                 mountPath: "/spanner/tls"
                 readOnly: true
               - name: spanner-data
                 mountPath: /spanner
         volumes:
           - name: tls-certs
             secret:
               secretName: tls-certs
               optional: true
               defaultMode: 256
           - name: spanner-data
             emptyDir: {}
   

   다음을 바꿉니다.

   • NAMESPACE: 배포의 Kubernetes 네임스페이스입니다(예: spanner-ns).
   • TARGET_VERSION: 업그레이드할 대상 버전입니다(예: 2026.r5).
   • ROOT_SERVER_ENDPOINT: 활성 루트 서버 포드의 엔드포인트입니다(예: spanner-a-0.pod.spanner-ns).

2. 매니페스트를 적용하여 준비 작업을 실행합니다.

   kubectl apply -f spanner-prepare-upgrade.yaml
   

2단계: 활성 출시 상태 확인

준비 단계가 완료되면 출시가 생성되었는지 확인하고 단계 상태를 검사합니다.

참고: 멀티 서버 Helm 배포에서 Helm은 3단계의 helm upgrade 중에 출시를 만듭니다. 이 단계를 실행하는 동안 또는 실행한 후에 출시 상태를 확인할 수 있습니다.

1. 활성 출시를 나열하여 출시 ID를 가져옵니다.

   spanner deployment rollouts list \
     --deployment-endpoint=DEPLOYMENT_ENDPOINT
   

   DEPLOYMENT_ENDPOINT을 배포에 있는 서버의 엔드포인트(예: localhost:15000 또는 spanner-a-0.pod.spanner-ns:15000)로 바꿉니다.

   출력은 다음과 비슷합니다.

   NAME                         STATE          TARGET_VERSION    START_TIME                     END_TIME
   rollouts/1788942172101727    IN_PROGRESS    2026.r3-beta      2026-09-09T08:22:52.101727Z    -
   

2. 자세한 출시 단계 상태를 검사합니다.

   spanner deployment rollouts describe ROLLOUT_ID \
     --deployment-endpoint=DEPLOYMENT_ENDPOINT
   

   다음을 바꿉니다.

   • ROLLOUT_ID: 숫자 출시 ID입니다(예: 1788942172101727).
   • DEPLOYMENT_ENDPOINT: 배포에 있는 서버의 엔드포인트입니다.

   출력은 다음과 비슷합니다.

   name: rollouts/1788942172101727
   phases:
       - name: rollouts/1788942172101727/phases/schema
         startTime: "2026-09-09T08:22:52.101727Z"
         state: SUCCEEDED
       - name: rollouts/1788942172101727/phases/binary
         startTime: "2026-09-09T08:23:29.585375Z"
         state: IN_PROGRESS
       - name: rollouts/1788942172101727/phases/finalize
         state: PENDING
   sourceVersion: 2026.r2-beta.3
   startTime: "2026-09-09T08:22:52.101727Z"
   state: IN_PROGRESS
   targetVersion: 2026.r3-beta
   

   계속하기 전에 다음 단계 상태를 확인하세요.

   • schema: 내부 데이터베이스 스키마 마이그레이션이 완료되었음을 나타내는 SUCCEEDED를 표시합니다.
   • binary: 출시 엔진이 바이너리 업데이트를 수행할 준비가 되었음을 나타내는 IN_PROGRESS를 표시합니다.
   • finalize: PENDING를 표시하고 바이너리 단계가 완료되기를 기다립니다.

3단계: 바이너리 또는 컨테이너 이미지 업데이트

스키마 단계가 성공하면 배포의 모든 노드에서 실행 중인 서버 바이너리 또는 컨테이너 이미지를 대상 버전으로 업데이트합니다.

도움말: 오류 또는 성능 저하가 관찰되면 완료 전 언제든지 바이너리 또는 컨테이너 이미지를 이전 버전으로 롤백할 수 있습니다. 자세한 내용은 업그레이드 롤백을 참조하세요.

배포 환경에 해당하는 탭을 선택합니다.

VM

VM 배포에서 순차적 재시작을 사용하여 모든 VM에서 spanner_server 바이너리를 업데이트합니다.

• 한 번에 하나의 장애 도메인 또는 영역 업데이트: 멀티 영역 배포에서는 한 영역의 서버를 업데이트하고 안정성을 확인한 후 다음 영역을 업데이트합니다. 이렇게 하면 Paxos 합의 그룹이 정족수를 유지할 수 있습니다.
• 점진적으로 다시 시작: 연속 쿼리 가용성을 유지하기 위해 서버를 동시에 5% 이하로 다시 시작합니다.
• 서버 상태 확인: 다음 장애 도메인을 업데이트하기 전에 다시 시작된 모든 서버가 정상이고 클러스터에 다시 조인되었는지 확인합니다.

Helm

Helm 배포에서 --reuse-values를 전달하거나 값 파일을 제공하여 기존 구성 값을 유지하면서 helm upgrade를 실행합니다.

• 멀티 서버 배포 (프로덕션/HA):

  helm upgrade spanner-omni oci://us-docker.pkg.dev/spanner-omni/charts/spanner-omni \
    --version CHART_VERSION \
    -n NAMESPACE \
    --reuse-values \
    --set image.tag=TARGET_VERSION \
    --timeout 30m
  

  Helm은 업그레이드 전 후크를 사용하여 1단계를 자동으로 실행한 다음 StatefulSet(rollout.staggered: true)의 순차적 영역별 순차적 업데이트를 시작합니다.

• 단일 서버 배포 (deployment.singleServer=true):

  이미 로컬에서 1단계를 완료했으므로 Helm이 업그레이드 전 후크 작업을 건너뛰도록 --set skipPrepareUpgrade=true를 명시적으로 전달합니다.

  helm upgrade spanner-omni oci://us-docker.pkg.dev/spanner-omni/charts/spanner-omni \
    --version CHART_VERSION \
    -n NAMESPACE \
    --reuse-values \
    --set skipPrepareUpgrade=true \
    --set image.tag=TARGET_VERSION \
    --timeout 30m
  

다음을 바꿉니다.

• CHART_VERSION: 대상 Helm 차트 버전(예: 1.1.0)
• NAMESPACE: 배포의 Kubernetes 네임스페이스입니다(예: spanner-ns).
• TARGET_VERSION: 대상 컨테이너 이미지 태그입니다(예: 2026.r5).

독립형 Kubernetes

Helm이 없는 커스텀 Kubernetes 배포에서 StatefulSet 또는 배포 사양의 컨테이너 이미지를 TARGET_VERSION로 업데이트합니다.

장애 도메인 전반에서 순차적 업데이트를 수행하여 한 번에 하나의 영역을 업데이트하고 정족수를 유지하기 위해 포드의 5% 이하를 동시에 다시 시작합니다.

4단계: 바이너리 단계 진행 확인

모든 서버 또는 포드를 대상 버전으로 업데이트한 후 바이너리 단계가 성공적으로 완료되었는지 확인합니다.

참고: 배포의 모든 서버가 업데이트되면 Spanner Omni는 최대 15분의 관찰 기간 동안 서버 상태를 추적한 후 binary 단계를 SUCCEEDED로 표시합니다.

출시 단계 상태를 확인합니다.

spanner deployment rollouts describe ROLLOUT_ID \
  --deployment-endpoint=DEPLOYMENT_ENDPOINT

다음을 바꿉니다.

• ROLLOUT_ID: 숫자 출시 ID입니다(예: 1788942172101727).
• DEPLOYMENT_ENDPOINT: 배포에 있는 서버의 엔드포인트입니다.

출력은 다음과 비슷합니다.

name: rollouts/1788942172101727
phases:
    - name: rollouts/1788942172101727/phases/schema
      startTime: "2026-09-09T08:22:52.101727Z"
      state: SUCCEEDED
    - name: rollouts/1788942172101727/phases/binary
      startTime: "2026-09-09T08:23:29.585375Z"
      state: SUCCEEDED
    - name: rollouts/1788942172101727/phases/finalize
      state: PENDING
sourceVersion: 2026.r2-beta.3
startTime: "2026-09-09T08:22:52.101727Z"
state: IN_PROGRESS
targetVersion: 2026.r3-beta

binary 단계 상태가 SUCCEEDED로 변경되는지 확인합니다. 전체 출시 상태는 나머지 단계가 모두 완료될 때까지 IN_PROGRESS로 유지됩니다. phases/binary가 SUCCEEDED로 전환되면 배포가 나머지 단계를 진행할 준비가 된 것입니다.

5단계: 나머지 단계 예약 및 실행

바이너리 단계가 성공하고 배포가 안정적인지 확인하면 finalize 단계까지 출시의 나머지 단계를 예약합니다. finalize 단계 (출시의 마지막 단계)는 배포 전반에서 새 버전을 봉인합니다. --deployment-endpoint를 지정하여 Spanner Omni 서비스에 대한 네트워크 액세스 권한이 있는 모든 머신에서 이 명령어를 실행할 수 있습니다.

주의: 완료가 시작된 후에는 롤백할 수 없습니다. 충분한 시간 동안 배포를 관찰하고 일반적인 워크로드에서 정상적이고 안정적인지 확인한 후에만 출시를 완료합니다. 자세한 내용은 업그레이드 롤백을 참조하세요.

PENDING 상태의 각 나머지 단계(예: enable_features(있는 경우), finalize)에 대해 다음 단계를 완료합니다.

1. 단계를 예약합니다.

   spanner deployment rollouts phases schedule PHASE_NAME \
     --rollout=ROLLOUT_ID \
     --deployment-endpoint=DEPLOYMENT_ENDPOINT
   

   다음을 바꿉니다.

   • PHASE_NAME: 예약할 단계의 이름입니다(예: finalize 또는 enable_features).
   • ROLLOUT_ID: 숫자 출시 ID입니다(예: 1788942172101727).
   • DEPLOYMENT_ENDPOINT: 배포에 있는 서버의 엔드포인트입니다.

   출력에 예약된 단계가 IN_PROGRESS로 표시됩니다.

   name: rollouts/1788942172101727
   phases:
       - name: rollouts/1788942172101727/phases/schema
         startTime: "2026-09-09T08:22:52.101727Z"
         state: SUCCEEDED
       - name: rollouts/1788942172101727/phases/binary
         startTime: "2026-09-09T08:23:29.585375Z"
         state: SUCCEEDED
       - name: rollouts/1788942172101727/phases/finalize
         state: IN_PROGRESS
   sourceVersion: 2026.r2-beta.3
   startTime: "2026-09-09T08:22:52.101727Z"
   state: IN_PROGRESS
   targetVersion: 2026.r3-beta
   

2. 단계가 성공할 때까지 기다린 후 상태를 확인합니다.

   spanner deployment rollouts describe ROLLOUT_ID \
     --deployment-endpoint=DEPLOYMENT_ENDPOINT
   

   finalize까지의 모든 단계가 완료될 때까지 나머지 각 단계에 대해 이 단계를 반복합니다.

   마지막 단계 (finalize)가 완료되면 모든 단계와 전체 출시 상태가 SUCCEEDED로 전환됩니다.

   endTime: "2026-09-09T08:45:43.949702Z"
   name: rollouts/1788942172101727
   phases:
       - name: rollouts/1788942172101727/phases/schema
         startTime: "2026-09-09T08:22:52.101727Z"
         state: SUCCEEDED
       - name: rollouts/1788942172101727/phases/binary
         startTime: "2026-09-09T08:23:29.585375Z"
         state: SUCCEEDED
       - name: rollouts/1788942172101727/phases/finalize
         startTime: "2026-09-09T08:45:43.898111Z"
         state: SUCCEEDED
   sourceVersion: 2026.r2-beta.3
   startTime: "2026-09-09T08:22:52.101727Z"
   state: SUCCEEDED
   targetVersion: 2026.r3-beta
   

3. 출시 목록에서 완료 상태를 확인합니다.

   spanner deployment rollouts list \
     --deployment-endpoint=DEPLOYMENT_ENDPOINT
   

   출력에서 출시가 완료되었음을 확인할 수 있습니다.

   NAME                         STATE        TARGET_VERSION    START_TIME                     END_TIME
   rollouts/1788942172101727    SUCCEEDED    2026.r3-beta      2026-09-09T08:22:52.101727Z    2026-09-09T08:45:43.949702Z
   

업그레이드 롤백

업그레이드 중에 문제가 발생하면 업그레이드를 롤백할 수 있는지 여부는 현재 출시 단계에 따라 달라집니다.

• 스키마 단계: 롤백할 수 없습니다. 준비 중에 적용된 내부 데이터베이스 스키마 마이그레이션은 정방향 전용이며 되돌릴 수 없습니다. 하지만 스키마 이전은 소스 버전과 하위 호환되므로 이전 서버 바이너리가 계속 정상적으로 작동할 수 있습니다.
• 바이너리 단계: 완료가 시작되기 전 언제든지 이전 버전으로 롤백할 수 있습니다. 자세한 내용은 바이너리 또는 컨테이너 이미지 롤백을 참조하세요.
• 선택적 출시 단계: 자동 롤백을 지원하는 선택적 단계 (예: 기능 사용 설정)의 경우 Spanner Omni CLI를 사용하여 롤백을 시작합니다.
• 완료 단계: 롤백할 수 없습니다. 완료가 시작되면 대상 버전이 배포 전반에서 영구적으로 봉인되고 롤백이 불가능합니다.

바이너리 또는 컨테이너 이미지 롤백

완료가 시작되기 전에 바이너리 단계를 롤백하려면 모든 서버 또는 포드에서 순차적 다시 시작을 수행하여 이전 (소스) 버전을 복원합니다.

VM

VM 배포에서 모든 VM의 spanner_server 바이너리를 롤백합니다.

1. 이전 spanner_server 바이너리 버전을 호스트에 배포합니다.
2. 장애 도메인 전반에서 서버를 점진적으로 다시 시작하여 한 번에 한 영역을 업데이트하고 Paxos 쿼럼을 유지하기 위해 서버의 5% 이하를 동시에 다시 시작합니다.
3. 다음 장애 도메인으로 진행하기 전에 다시 시작된 모든 서버가 정상이고 클러스터에 다시 조인되었는지 확인합니다.

Helm

Helm 배포에서 컨테이너 이미지 태그를 이전 버전으로 다시 업데이트합니다.

helm upgrade spanner-omni oci://us-docker.pkg.dev/spanner-omni/charts/spanner-omni \
  --version CHART_VERSION \
  -n NAMESPACE \
  --reuse-values \
  --set image.tag=SOURCE_VERSION \
  --timeout 30m

다음을 바꿉니다.

• CHART_VERSION: Helm 차트 버전(예: 1.1.0)
• NAMESPACE: 배포의 Kubernetes 네임스페이스입니다(예: spanner-ns).
• SOURCE_VERSION: 되돌릴 이전 컨테이너 이미지 태그입니다(예: 2026.r2-beta.3).

독립형 Kubernetes

Helm이 없는 커스텀 Kubernetes 배포에서 StatefulSet 또는 배포 사양의 컨테이너 이미지를 SOURCE_VERSION로 다시 업데이트합니다.

장애 도메인 전반에서 순차적 업데이트를 수행하여 한 번에 하나의 영역을 업데이트하고 정족수를 유지하기 위해 포드의 5% 이하를 동시에 다시 시작합니다.

선택적 출시 단계 롤백

롤백을 지원하는 선택적 출시 단계 (예: 기능 사용 설정 단계)의 경우 rollouts rollback 명령어를 실행하여 롤백을 시작합니다.

spanner deployment rollouts rollback ROLLOUT_ID \
  --deployment-endpoint=DEPLOYMENT_ENDPOINT

다음을 바꿉니다.

• ROLLOUT_ID: 숫자 출시 ID입니다.
• DEPLOYMENT_ENDPOINT: 배포에 있는 서버의 엔드포인트입니다.

다음 단계

• 배포 유지보수 방법 알아보기
• Kubernetes 배포 확장 또는 VM 배포 확장 방법 알아보기
• 모니터링 개요 알아보기