> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-vortex-format.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 관리형 서비스

> 커넥터 실행기를 통해 ClickHouse Cloud가 사용자의 클러스터에서 운영하는 ClickHouse 서비스를 생성, 모니터링, 폐기합니다

export const Image = ({img, alt, size = "lg", background}) => {
  const normalizedSize = ["sm", "md", "lg"].includes(size) ? size : "lg";
  const backgroundColor = background === "white" ? "white" : background === "black" ? "rgb(31 31 28)" : undefined;
  return <div className={`ch-image-${normalizedSize}`}>
      <Frame>
        <img src={img} alt={alt} style={{
    backgroundColor
  }} />
      </Frame>
    </div>;
};

export const PrivatePreviewBadge = () => {
  return <div className="privatePreviewBadge">
            <div className="privatePreviewIcon">
            <svg width="16" height="16" viewBox="0 0 16 16" fill="none" xmlns="http://www.w3.org/2000/svg">
                <path d="M5.33301 6.66667V4.66667V4.66667C5.33301 3.194 6.52701 2 7.99967 2V2C9.47234 2 10.6663 3.194 10.6663 4.66667V4.66667V6.66667" stroke="currentColor" strokeLinecap="round" strokeLinejoin="round" />
                <path d="M8.00033 9.33337V11.3334" stroke="currentColor" strokeLinecap="round" strokeLinejoin="round" />
                <path fillRule="evenodd" clipRule="evenodd" d="M11.333 14H4.66634C3.92967 14 3.33301 13.4033 3.33301 12.6666V7.99996C3.33301 7.26329 3.92967 6.66663 4.66634 6.66663H11.333C12.0697 6.66663 12.6663 7.26329 12.6663 7.99996V12.6666C12.6663 13.4033 12.0697 14 11.333 14Z" stroke="currentColor" strokeLinecap="round" strokeLinejoin="round" />
            </svg>
        </div>
            {'비공개 프리뷰'}
        </div>;
};

<PrivatePreviewBadge />

관리형 모드에서는 커넥터가 세 번째 구성 요소인 실행기를 함께 실행합니다. ClickHouse Cloud는 이 실행기를 통해 사용자의 Kubernetes 클러스터에서 ClickHouse 서비스를 운영합니다. 이 페이지에서는 서비스 생성 방법, 서비스 상태 확인 방법, ClickHouse Cloud가 해당 서비스로 수행하는 작업, 그리고 서비스가 폐기(retire)되는 과정을 다룹니다.

<h2 id="what-managed-mode-does">
  관리형 모드의 동작 방식
</h2>

실행기는 스크레이퍼, troubleshooter와 동일한 `clicklink` 바이너리에 포함된 데몬입니다. 엔드포인트로 향하는 아웃바운드 WebSocket 채널을 유지하면서 ClickHouse Cloud로부터 수명 주기 명령어를 수신합니다. 실행기는 자신이 구성된 단일 Kubernetes 클러스터에 각 명령어를 적용하고, 해당 채널을 통해 결과를 보고합니다. 다른 구성 요소와 마찬가지로 아웃바운드 연결만 생성합니다. 즉, ClickHouse Cloud가 사용자 클러스터로 접속하는 일은 없으며, 실행기의 로컬 API는 루프백에 바인딩됩니다.

관리형 모드는 비공개 프리뷰 기간 동안 S3 storage를 사용하는 Amazon EKS에서 제공됩니다. 환경을 등록할 때 계정 담당 팀이 이를 활성화합니다. `init`은 EKS 클러스터를 가리키지 않는 kube context를 거부합니다.

각 서비스에는 사용자가 소유한 세 가지 cloud resources가 필요합니다. 데이터 버킷, 백업 버킷, 그리고 ClickHouse 파드가 이들에 접근하기 위해 assume하는 IAM role입니다. 이들은 서비스가 생성되기 전에 사용자의 자격 증명으로 직접 생성하고, 서비스가 제거된 후에 삭제합니다. 실행기는 사용자의 버킷이나 IAM에 대한 자격 증명을 보유하지 않으며, 데이터를 삭제하지도 않습니다. 실행기의 클라우드 호출은 Amazon ECR과 STS로만 향합니다. 플랫폼 동기화나 생성 작업이 차트를 가져올 때 registry에 로그인하며, 플랫폼 업데이트 중에는 읽기 전용 pull role로 이미지를 확인합니다. S3나 IAM 호출은 수행하지 않습니다. 각 서비스에 대해 LoadBalancer 타입의 Kubernetes `Service`를 생성하며, 이는 클러스터의 load-balancer controller에 의해 사용자 계정 내 내부 NLB로 구현됩니다.

VM에서 실행기는 나머지 두 구성 요소와 함께 `clicklink-executor` systemd unit으로 실행됩니다. Kubernetes에서는 커넥터 네임스페이스 내 단일 레플리카 배포로 동작합니다. 포트 8086으로 상태 확인과 메트릭을 제공하고, `127.0.0.1:9999`로 로컬 API를 제공합니다.

<h2 id="enable-managed-mode">
  관리형 모드 활성화
</h2>

관리형 모드는 등록할 때 선택합니다. `clicklink clctl init`에 `--managed`를 전달하거나, 터미널에 표시되는 프롬프트에 응답하십시오. VM에서 `init`은 해당 호스트의 kubeconfig에서 클러스터를 가져오며(EKS cluster가 두 개 이상 있는 경우 `--cluster-name`으로 지정), 실행기에 클러스터 전역 액세스 권한을 인라인으로 부여합니다. Kubernetes에서는 커넥터 엔드포인트의 CIDR을 `--egress-cidrs`로 전달하여 차트가 기본 거부(default-deny) NetworkPolicy를 활성화된 상태로 배치하도록 하십시오.

설치 과정 자체는 달라지지 않습니다. 전체 흐름은 [온보딩](/ko/products/bring-your-own-cloud/connector/onboarding#install-and-enroll)을, 플래그는 [CLI 참고](/ko/products/bring-your-own-cloud/connector/reference/cli#init)를 확인하십시오.

<h2 id="create-a-service">
  서비스 생성
</h2>

엔드포인트를 통한 서비스 생성은 환경별로 활성화되므로, 시작하기 전에 계정 담당 팀에 문의하십시오.

서비스를 생성하려면 두 개의 명령어가 필요합니다. `prepare`는 사용자 측에 필요한 모든 것을 생성하고, `instances create`는 엔드포인트를 통해 ClickHouse Cloud에 생성 요청을 제출합니다. ClickHouse Cloud는 서비스 정의를 렌더링한 뒤 아웃바운드 채널을 통해 실행기로 생성 요청을 전달합니다. 실행기는 이를 클러스터에 적용하고 결과를 보고합니다.

AWS 자격 증명이 필요한 명령어는 `prepare`뿐이며, 이 명령어는 S3 버킷과 IAM role을 생성합니다. `instances create`는 커넥터의 구성과 자격 증명이 필요하고, `--wait`를 사용할 때만 실행기의 로컬 API에 접근합니다. VM에서는 두 명령어 모두 커넥터 호스트에서 root로 실행하십시오. Kubernetes에서는 관리형 클러스터의 kube 컨텍스트가 설정된 작업 머신에서 두 명령어를 모두 실행하십시오.

* `prepare`에는 커넥터 구성 사본(`--config`), 실행기의 로컬 API로 연결되는 `kubectl port-forward`, 그리고 쓰기 가능한 `--output-dir`가 필요합니다. 이 명령어는 실행기를 통해 서비스 이름을 확인하며, 실행기에 연결할 수 없으면 실행을 거부합니다.
* 현재 호스트에 구성에 지정된 자격 증명 파일이 없으면, `instances create`는 이를 `clicklink-hmac` 및 `clicklink-mtls` 시크릿에서 읽어오며 읽을 때마다 이를 알립니다. 커넥터 네임스페이스가 `clicklink`가 아니면 `--connector-namespace`를 추가하십시오. 이 폴백 동작은 `instances create`에만 적용됩니다.

<Image img="https://mintcdn.com/private-7c7dfe99-vortex-format/wGEkZpH7GS15Wa4H/images/cloud/reference/byoc-connector-service-lifecycle.svg?fit=max&auto=format&n=wGEkZpH7GS15Wa4H&q=85&s=14eac921a706075c4813bdc9b0cc9b45" size="lg" alt="관리형 모드에서의 ClickHouse Connector 서비스 수명 주기" width="1320" height="870" data-path="images/cloud/reference/byoc-connector-service-lifecycle.svg" />

<Steps>
  <Step title="서비스 준비" id="prepare">
    <Tabs>
      <Tab title="Kubernetes" id="prepare-kubernetes">
        ```bash theme={null}
        CONNECTOR_NAMESPACE='clicklink'   # init 단계에서 선택한 커넥터 네임스페이스
        kubectl -n "${CONNECTOR_NAMESPACE}" get configmap clicklink-connector-executor \
          -o jsonpath='{.data.config\.yaml}' > clicklink-config.yaml
        kubectl -n "${CONNECTOR_NAMESPACE}" port-forward deployment/clicklink-connector-executor 9999:9999 &
        clicklink clctl executor prepare --config clicklink-config.yaml --output-dir ./clicklink-access
        ```

        출력 디렉터리는 삭제하지 말고 그대로 두십시오. `instances create`와 모든 retry가 읽어 들이는 create body와 name 레코드가 이 디렉터리에 보관됩니다.
      </Tab>

      <Tab title="Linux VM" id="prepare-vm">
        ```bash theme={null}
        sudo clicklink clctl executor prepare --config /etc/clicklink/config.yaml
        ```
      </Tab>
    </Tabs>

    이 명령은 네 단계를 순서대로 실행하며, 첫 번째 실패 지점에서 중단됩니다.

    1. **Name.** service name을 선택하거나 `--instance <name>`으로 전달한 이름을 검사합니다. 생성된 이름은 `<output-dir>/_prepare/<eks-cluster-name>.name`에 기록되어 다음 실행에서 이어서 사용되므로, retry 시에는 첫 실행의 버킷과 역할을 재사용합니다. `--new-name`을 사용하면 다른 이름을 선택합니다. executor가 아직 보유 중인 이름이거나 해당 네임스페이스에 이미 ClickHouse 클러스터가 있는 이름은 거부됩니다.
    2. **Storage.** 데이터 및 backup 버킷과 IAM role `CH-S3-<name>-<region>-00-Role`을 생성합니다. 기본 버킷 이름은 `<cluster>-clickhouse-data-<rand>`와 `<cluster>-clickhouse-backup-<rand>`이며, `--data-bucket`과 `--backup-bucket`으로 재정의할 수 있습니다. `--role-arn`을 지정하면 사용자가 제공한 역할을 검증하며 IAM은 작성하지 않습니다.
    3. **Grant and apply.** VM에서는 service 네임스페이스(`ns-<name>`)에 대한 executor의 access bundle을 렌더링하고, 해당 RBAC를 적용한 뒤 executor의 registry에 service를 등록합니다. Kubernetes에서는 이 단계가 생략됩니다. executor가 자신의 파드 ServiceAccount로 실행되며, create 요청이 도착하면 직접 service를 등록합니다.
    4. **Summary.** `default` USER의 password를 발급하고 create body를 `<output-dir>/_prepare/<name>.create.json`에 작성합니다(mode `0600`, password의 해시만 포함). 그리고 다음에 실행할 명령을 `Next:` 줄에 출력합니다.

    <Warning>
      `prepare`는 `default` USER의 password를 stderr에 단 한 번만 출력합니다. create body에도 `--output json` 결과에도 password는 포함되지 않으며, ClickHouse Cloud는 해시만 수신합니다. 다음 단계로 넘어가기 전에 반드시 저장하십시오. 재실행 시 create body가 이미 존재하면 기록된 해시를 그대로 유지하며, 그 사실을 알려 줍니다.
    </Warning>

    kubeconfig에 여러 Context가 있다면 `--context <name>`을 전달하십시오. 이때 Context는 구성의 `executor.cluster`에 지정된 EKS cluster를 가리켜야 합니다. `--dry-run`은 아무것도 생성하거나 작성하지 않고 모든 단계를 실행합니다. 해싱 단계는 SHA-1을 사용하는데, Go는 `GODEBUG=fips140=only` 설정에서 이를 거부합니다. 따라서 해당 설정이 적용되지 않은 호스트에서 `prepare`를 실행하십시오.
  </Step>

  <Step title="생성 요청을 제출합니다" id="create">
    <Tabs>
      <Tab title="Kubernetes" id="create-kubernetes">
        ```bash theme={null}
        clicklink clctl instances create \
          --from-prepare ./clicklink-access/_prepare/<name>.create.json \
          --config clicklink-config.yaml \
          --wait
        ```

        `prepare`에서 실행한 포트 포워딩은 그대로 열어 두십시오. `--wait`가 이 연결을 통해 실행기를 폴링합니다.
      </Tab>

      <Tab title="Linux VM" id="create-vm">
        ```bash theme={null}
        sudo clicklink clctl instances create \
          --from-prepare /etc/clicklink/access/executor/_prepare/<name>.create.json \
          --config /etc/clicklink/config.yaml \
          --wait
        ```
      </Tab>
    </Tabs>

    이 명령은 커넥터 자체의 자격 증명을 사용하여 준비된 body를 커넥터 엔드포인트로 전송합니다. 실행하면 `created <spoken-name> (state provisioning)`과 `watch:` hint가 출력됩니다. `<spoken-name>`은 ClickHouse Cloud가 할당한 이름(예: `amberaws-kq-42`)이며, 준비 단계에서 지정한 service name이 아닙니다. `watch:` hint와 모든 `clctl` 명령은 사용자가 지정한 service name을 사용합니다.

    동일한 입력으로 재시도해도 안전합니다. 멱등성 key는 기본적으로 환경과 service name에서 파생되므로, 다시 제출하면 최초 생성 결과가 반환됩니다.

    `--wait`는 service가 `running` 상태가 될 때까지 10초마다 실행기의 로컬 API를 폴링하며, 최대 `--wait-timeout`(기본값 `30m`)까지 대기합니다. 실행기가 해당 이름에 대한 생성 실패를 기록하거나 service가 `terminating`, `terminated`, `stale` 상태로 전환되면 기록된 오류와 함께 즉시 실패 처리합니다.
  </Step>

  <Step title="확인" id="verify">
    ```bash theme={null}
    clicklink clctl instances get --name <name> --cluster <eks-cluster-name>
    ```

    서비스는 `status`가 `running`이 되면 사용할 준비가 된 것입니다. 해당 서비스의 `default` 사용자는 `prepare`에서 출력된 비밀번호를 사용합니다. `--cluster`는 `CLCTL_CLUSTER` 환경 변수로도 지정할 수 있습니다.
  </Step>
</Steps>

<h2 id="status">
  상태
</h2>

실행기는 로컬 API를 통해 상태 조회에 응답하며, 이 API는 `127.0.0.1:9999`에 바인딩되고 자체 인증(authentication) 기능은 제공하지 않습니다. VM에서는 해당 호스트에서 명령어를 실행하십시오. Kubernetes에서는 먼저 포트 포워딩을 설정한 뒤, 명령어가 이를 바라보도록 지정하십시오:

```bash theme={null}
kubectl -n <connector-namespace> port-forward deployment/clicklink-connector-executor 9999:9999
clicklink clctl instances list --endpoint http://127.0.0.1:9999
```

`clicklink clctl instances list`는 실행기가 알고 있는 모든 서비스를 JSON으로 출력합니다. `clicklink clctl instances get --name <name> --cluster <eks-cluster-name>`는 특정 서비스 하나를 생성 당시 사용된 저장소 정보와 함께 출력합니다. 실행기는 서비스의 `ClickHouseCluster` 리소스(준비된 서버 레플리카 수 대 예상 서버 레플리카 수)를 기준으로 상태를 판단하며, `sync_interval`(기본값 30초)마다 이를 갱신합니다:

* `provisioning`: 아직 준비된 서버 레플리카가 없거나, `ClickHouseCluster`가 아직 존재하지 않음
* `running`: 예상된 모든 서버 레플리카가 준비됨
* `degraded`: 일부 서버 레플리카만 준비되고 전부는 준비되지 않음
* `terminating`: 실행기가 서비스를 제거하는 중
* `terminated`: 서비스의 네임스페이스가 사라짐
* `stale`: 삭제 절차 없이 서비스가 실행기의 registry에서 제거됨. `--wait`와 `teardown`은 이를 `terminated`와 동일하게 취급합니다

종료된 서비스는 [teardown](#delete-a-service)이 해당 cloud resources를 제거할 때까지 저장소 정보와 함께 목록에 계속 표시됩니다.

실행기는 ClickHouse Cloud가 전송한 모든 명령어를 기록합니다. `clicklink clctl commands list`로 이를 출력할 수 있으며, `--status`(`pending`, `running`, `completed`, `failed`), `--action`(예: `create_instance`), `--cluster`로 필터링할 수 있습니다. `clicklink clctl commands get <id>`는 명령어 하나를 해당 stage 및 결과와 함께 출력합니다. 실패한 명령어의 `result`에는 오류 내용이 담겨 있어, 생성이 수렴하지 못한 이유나 어떤 [플랫폼 업데이트](/ko/products/bring-your-own-cloud/connector/platform-updates)가 승인을 기다리고 있는지를 확인할 수 있습니다.

<h2 id="service-lifecycle">
  서비스 수명 주기
</h2>

서비스가 생성되고 나면 ClickHouse Cloud는 실행기를 통해 해당 서비스를 운영합니다. ClickHouse Cloud가 전송하는 명령어는 다음과 같습니다:

* **Scale.** ClickHouse Cloud가 고정된 레플리카 수를 지정하며, 그 상한은 ClickHouse Cloud 설정으로 결정됩니다(기본 구성에서는 20). 자동 스케일링은 지원되지 않습니다.
* **Stop 및 start.** 중지하면 서버가 0으로 스케일되고 Keeper는 유지됩니다. 시작하면 레플리카 수가 복원됩니다. 이 과정 내내 데이터는 사용자의 버킷에 그대로 남아 있습니다.
* **Restart.** 전체 서비스, 해당 Keeper, 또는 단일 파드를 재시작합니다.
* **Backups.** ClickHouse Cloud가 백업을 트리거하며, 백업은 백업 버킷에 저장되고 백업을 삭제하면 제거됩니다.
* **버전 업그레이드 및 구성 변경.** ClickHouse Cloud는 새 버전이나 설정을 반영해 서비스 정의를 다시 렌더링합니다. 이는 `create_instance` 명령어로 전달되므로 `commands list --action create_instance`에서도 업그레이드를 확인할 수 있습니다. 실행기는 이를 적용한 뒤 레플리카가 다시 준비 상태가 될 때까지 대기합니다.
* **Delete.** [서비스 삭제](#delete-a-service)에서 설명합니다.

<Warning>
  버전 업그레이드와 구성 변경에는 고객 승인 단계가 없습니다. ClickHouse Cloud는 스케일이나 재시작을 적용할 때와 동일한 방식으로 관리형 서비스에 이를 적용합니다. 즉, 정의를 다시 전송하고 실행기가 클러스터를 해당 정의에 수렴시킵니다.
</Warning>

생성, 스케일, 시작 작업은 비동기적으로 완료됩니다. 실행기는 정의를 적용하는 즉시 해당 명령어를 실행 중으로 보고하고 2분마다 진행 상황을 보고합니다. 서버 레플리카가 준비되면 최종 결과를 보고합니다. 2시간 이내에 준비되지 않으면 명령어를 실패로 보고하며, 이후 레플리카가 정상적으로 기동되면 서비스를 다시 `running` 상태로 전환합니다.

`instances scale`, `instances patch`, `instances delete` 하위 명령어는 ClickHouse Cloud를 거치지 않고 실행기의 로컬 API에 직접 명령어를 전송합니다. 계정 담당 팀이 요청하는 경우에만 실행하십시오. 각 명령어의 동작은 [CLI 참고](/ko/products/bring-your-own-cloud/connector/reference/cli#instances-scale)에 설명되어 있습니다.

<h2 id="support-sessions">
  관리형 서비스의 지원 세션
</h2>

실행기는 자신이 생성하는 각 서비스에 스크레이퍼를 연결합니다. 다만 Troubleshooter는 프로비저닝하지 않으므로, 직접 프로비저닝하기 전까지는 [지원 세션](/ko/products/bring-your-own-cloud/connector/support-sessions)에서 관리형 서비스에 대한 진단을 실행할 수 없습니다. 직접 등록한 instance와 동일한 방식으로, 서비스 네임스페이스 `ns-<name>`을 지정하여 서비스마다 한 번씩 프로비저닝하십시오.

<Tabs>
  <Tab title="Kubernetes" id="troubleshooter-kubernetes">
    ```bash theme={null}
    printf '%s\n' "$CH_DEFAULT_PASSWORD" | clicklink clctl troubleshoot access provision --target helm \
      --target-namespace "${CONNECTOR_NAMESPACE}" \
      --instance <name> --instance-namespace ns-<name> \
      --server <kubernetes-api-server-url> --ch-admin-password-stdin \
      --apply-ch-grants --ch-pod <clickhouse-pod-or-label-selector> --ch-pod-namespace ns-<name>
    ```

    `$CH_DEFAULT_PASSWORD`는 `prepare`가 출력한 `default` 사용자의 password입니다. 이 command는 SQL 권한 부여를 적용하기 위해 해당 값으로 인증하며, 별도로 입력을 요청하지 않습니다. 그런 다음 [ClickHouse instance 추가](/ko/products/bring-your-own-cloud/connector/configuration#clickhouse-instances)에 설명된 대로 시크릿과 ServiceAccount 쌍을 `troubleshooter.accessBundles`에 추가하고 `helm upgrade`를 실행하십시오.
  </Tab>

  <Tab title="Linux VM" id="troubleshooter-vm">
    ```bash theme={null}
    printf '%s\n' "$CH_DEFAULT_PASSWORD" | sudo clicklink clctl troubleshoot access provision --provider local \
      --instance <name> --instance-namespace ns-<name> \
      --server <kubernetes-api-server-url> --ch-admin-password-stdin
    ```

    `$CH_DEFAULT_PASSWORD`는 `prepare`가 출력한 `default` 사용자의 password입니다.
  </Tab>
</Tabs>

ClickHouse 사용자에게는 위와 같이 SQL로 권한을 부여하십시오. `--ch-user-via cr`로 추가한 사용자는 유지되지 않습니다. 서비스 정의는 ClickHouse Cloud가 소유하며 이를 반복해서 다시 적용하기 때문입니다. 서비스가 삭제되면 실행기는 VM에서 Troubleshooter의 bundle을 제거합니다. Kubernetes에서는 [제거](/ko/products/bring-your-own-cloud/connector/operations#uninstall-kubernetes)에 나열된 대로 직접 삭제하기 전까지 bundle 시크릿과 ServiceAccount가 그대로 남아 있습니다.

<h2 id="delete-a-service">
  서비스 삭제
</h2>

커넥터 엔드포인트를 통한 고객용 삭제 명령은 제공되지 않습니다. 서비스 삭제는 계정 담당 팀에 요청하십시오. ClickHouse Cloud가 서비스를 종료하면 실행기가 해당 워크로드와 네임스페이스를 삭제합니다(`terminating`을 거쳐 `terminated`). AWS 측에는 아무런 변경도 가해지지 않습니다. 버킷, 그 안의 데이터, IAM role은 직접 제거하기 전까지 그대로 유지됩니다.

서비스 상태가 `terminated`로 보고되면 `prepare`가 생성한 리소스를 정리하십시오. `teardown`은 `prepare`를 실행했던 곳에서 동일한 AWS 자격 증명으로 실행해야 합니다. Kubernetes에서는 동일한 workstation, 동일한 구성 사본과 출력 디렉터리, 그리고 실행기로 연결된 포트 포워딩이 필요합니다.

<Tabs>
  <Tab title="Kubernetes" id="teardown-kubernetes">
    ```bash theme={null}
    kubectl -n "${CONNECTOR_NAMESPACE}" port-forward deployment/clicklink-connector-executor 9999:9999 &
    clicklink clctl executor teardown --instance <name> --config clicklink-config.yaml --output-dir ./clicklink-access
    ```
  </Tab>

  <Tab title="Linux VM" id="teardown-vm">
    ```bash theme={null}
    sudo clicklink clctl executor teardown --instance <name>
    ```
  </Tab>
</Tabs>

이 명령은 실행기가 보관 중인 서비스 기록, 즉 데이터가 어디에 있고 어떤 역할을 사용했는지를 읽습니다. 그런 다음 `prepare`가 생성한 IAM role을 삭제하고, 실행기가 해당 서비스를 잊도록 하여 이름을 해제합니다. VM에서는 서비스의 클러스터 전체 RBAC 객체, 로컬 액세스 bundle, registry entry도 함께 제거합니다.

기본적으로 서비스의 데이터와 백업은 유지됩니다. 유지되는 버킷의 태그는 `clicklink:deployed-name`에서 `clicklink:retained-from=<name>`으로 변경되므로, 동일한 이름으로 다시 생성된 서비스가 이를 상속하는 일은 없으며, 요약에 데이터 위치가 표시됩니다. 이를 삭제하려면 같은 명령에 `--delete-data --delete-backups --yes`를 추가하십시오.

<Warning>
  `--delete-data`와 `--delete-backups`는 지정된 버킷을 비우고 삭제하며, 이후에는 복구할 수 없습니다. `--yes`를 추가하기 전에 기록 단계에서 버킷 이름을 반드시 확인하십시오.
</Warning>

`--yes`가 없으면 기록 단계 이후 실행이 중단되며, 비우게 될 버킷의 이름을 알려 줍니다. `--dry-run`은 모든 정보를 읽기만 하고 아무것도 쓰지 않습니다. `--role-arn`으로 직접 지정한 역할이나 `prepare`가 생성하지 않은 버킷은 유지 대상으로 보고되며 전혀 건드리지 않습니다. 서비스의 네임스페이스에 아직 ClickHouse 클러스터가 남아 있으면 실행이 거부됩니다. 무엇이든 삭제하기 전에 모든 정보를 먼저 읽으므로, 거부된 실행은 아무것도 변경하지 않습니다.

<h2 id="when-the-connector-is-offline">
  커넥터가 오프라인일 때
</h2>

실행 중인 서비스는 실행기에 의존하지 않습니다. 클러스터의 ClickHouse Operator가 서비스를 계속 실행 상태로 유지하므로, 커넥터 연결이 끊기더라도 이미 쿼리를 처리 중인 서비스는 전혀 영향을 받지 않습니다.

실행기가 연결되어 있지 않은 동안에는 ClickHouse Cloud가 새 작업을 전달할 수 없습니다. 이미 수락된 생성, 삭제, 플랫폼 동기화 작업은 보관되었다가 재시도됩니다. 생성은 마지막 진행 상황 보고 시점부터 30분 동안, 삭제는 2시간 동안, 플랫폼 동기화는 최대 10회까지 재시도됩니다. 이 한도를 초과하면 커넥터 엔드포인트가 해당 명령어를 실패로 표시합니다. 그 외 모든 수명 주기 명령어(scale, stop, start, restart, backup, backup 삭제)는 큐에 대기되지 않고 거부됩니다. 실행기가 연결되어 있지 않은 상태에서 제출한 생성 또는 삭제 명령어도 동일하게 거부되며, 이미 수락된 명령어만 재시도됩니다.

실행기가 이미 수락한 명령어는 완료될 때까지 실행되며, 보고하지 못한 결과는 다음 연결 시 전송됩니다.

`instances create`는 명령어를 실행하는 호스트에서 커넥터 엔드포인트에 연결할 수 있어야 합니다. `--wait`, `instances list`, `instances get`, `commands list`는 실행기의 로컬 API를 사용하므로 실행기가 실행 중이어야 합니다. 플랫폼 승인 토큰은 연결 상태와 관계없이 자체 시간에 따라 만료됩니다. [승인 윈도우](/ko/products/bring-your-own-cloud/connector/platform-updates#the-approval-window)를 참조하십시오.