CDC 커넥터의 런타임 크기 조정 및 패킹

CDC 커넥터의 런타임 크기 조정 및 패킹

기능 — 일반 공급(Generally Available)

Snowflake 커넥터는 Snowflake Openflow를 사용할 수 있는 모든 리전에서 지원돼요.

Openflow Snowflake 배포는 AWS, Azure, GCP 상용 리전의 모든 계정에서 사용할 수 있어요.

BYOC 배포의 Snowflake Openflow는 AWS 상용 리전(상용 리전)의 모든 계정에서만 사용할 수 있어요.

참고

이 커넥터는 Snowflake 커넥터 약관의 적용을 받아요.

이 항목에서는 변경 데이터 캡처(CDC) 커넥터를 위해 Openflow 런타임의 크기를 조정하는 방법, 하나의 런타임에서 실행할 수 있는 커넥터 수, 그리고 커넥터가 이미 설치된 후 다른 크기가 필요할 때 해야 할 일을 설명해요.

이 지침은 크기 조정 임계값이 특정 소스 데이터베이스가 아니라 복제 처리량으로 표현되므로 모든 Openflow CDC 커넥터에 적용돼요.

런타임 크기 조정

각 런타임에는 각 노드의 CPU와 힙 메모리를 결정하는 노드 유형(node type) (Small, Medium, Large)과 노드 유형 티어(node type tier) 가 있어요. 런타임을 만들 때 둘 다 선택해요. 생성 후에는 UI 또는 ALTER OPENFLOW RUNTIME을 사용해 동일한 노드 유형 안에서 티어를 변경할 수 있어요. 노드 유형 자체는 변경할 수 없어요.

티어 노드 유형 노드당 CPU 노드당 힙
S1 Small 1 4 GB
S2 Small 2 8 GB
S3 Small 3 12 GB
M4 Medium 4 16 GB
M6 Medium 6 24 GB
L8 Large 8 33 GB

런타임에서 실행되는 모든 커넥터에 걸쳐 처리해야 하는 지속 워크로드를 기준으로 런타임 크기를 조정하세요. 지속(sustained)이란 일반적인 정상 상태 처리량을 의미하며, 피크가 아니다. 피크 부하는 일시적으로 커넥터 큐와 종단 간 복제 지연 시간을 늘릴 수 있으며, 부하가 정상 상태 수준으로 떨어지면 워크로드가 따라잡아요.

다음 범위는 내부 벤치마크와 프로덕션 고객 데이터를 기반으로 한 시작점이에요. 서비스 보장은 아니에요. 실제 적합성은 행 크기, 이벤트 분포, 스키마 폭, 소스 버스트성에 따라 달라져요. 하한에서 시작해 프로덕션에서 런타임 CPU, 메모리, 큐 깊이, 종단 간 복제 지연 시간을 측정한 다음 그로부터 늘려나가세요.

  • 가벼운 워크로드(집계 지속 처리량이 대략 초당 1,000 이벤트 미만, 활발히 변경되는 테이블 수가 대략 100개 미만): Small 런타임은 S1에서 저용량 커넥터 1개, S2에서 약 2개, S3에서 약 3~4개를 호스팅할 수 있어요. 각 소스가 정말 가볍다는 확인이 있을 때만 Small에 추가 커넥터를 패킹하세요.
  • 중간 워크로드(대략 초당 1,0005,000 이벤트, 수백 개의 활발히 변경되는 테이블): Medium 런타임은 보통 M4에서 약 58개, M6에서 약 7~10개의 커넥터를 호스팅할 수 있어요.
  • 무거운 워크로드(대략 초당 5,00015,000 이벤트, 수백낮은 수천 개의 활발히 변경되는 테이블): Large 런타임(L8)은 보통 15개 이상의 커넥터를 호스팅할 수 있어요. 더 나은 리소스 격리를 원하면 대신 부하를 여러 개의 더 작은 런타임으로 분산하세요. 그러면 문제가 있는 커넥터 하나가 다른 커넥터에 영향을 주는 것을 방지할 수 있어요.

선택한 크기로 런타임을 만드는 단계는 Openflow - Snowflake 배포 설정: 런타임 생성을 참조하세요.

하나의 런타임에서 여러 커넥터 실행

단일 런타임에서 여러 CDC 커넥터 인스턴스를 실행할 수 있어요. 이는 많은 소규모 데이터베이스를 복제할 때 유용한데, 예를 들어 테넌트별 데이터베이스가 하나씩 있는 멀티 테넌트 SaaS, 또는 비즈니스 단위나 리전별 운영 데이터베이스 군이 그 예시예요.

중요

다음 중 하나가 해당하면 커넥터를 다른 것과 패킹하지 말고 전용 런타임에서 실행하세요.

  • 단일 소스가 대략 초당 15,000 이벤트 이상을 지속적으로 발생시키는 경우.
  • 부하 상태에서 1분 미만의 종단 간 복제 지연 시간이 필요한 경우.
  • 런타임을 공유하는 다른 소스의 노이지 네이버(noisy-neighbor) 영향이 용납되지 않는 경우.

복제된 각 테이블은 Snowpipe Streaming 파이프 두 개를 소비할 수 있어요. 하나는 스냅샷 복제용, 하나는 증분 복제용이에요. 런타임에 테이블을 더 패킹할수록 계정의 Snowpipe Streaming 파이프 한도를 확인하고, 한도에 가까워지기 전에 올리세요.

하나의 런타임에서 여러 커넥터 인스턴스를 구성하는 방법은 세대에 따라 달라요.

  • Gen 2: 각 커넥터 인스턴스는 자체 구성을 가지므로, 하나의 런타임에서 여러 인스턴스를 실행하는 것은 각 커넥터를 같은 런타임에 설치하는 것뿐이에요. 상속하거나 재정의할 공유 구성이 없어요.
  • Gen 1: 각 커넥터 인스턴스는 Source, Destination, Ingestion 매개변수 컨텍스트를 사용해요. Ingestion 컨텍스트는 Source와 Destination 컨텍스트에서 상속하므로, Ingestion에서 재정의하지 않는 모든 값은 상위 컨텍스트에서 해석돼요. 이 절의 나머지는 권장되는 gen 1 설정을 설명해요.

공유 Source·Destination 컨텍스트를 사용하고 Ingestion에서 커넥터별 재정의

Snowflake는 여러 CDC 커넥터 인스턴스를 수동으로 실행할 때 이 설정을 권장해요. 이는 openflow 스킬이 규모에 맞게 자동으로 적용하는 것과 동일한 패턴이에요.

팁

여러 CDC 커넥터 인스턴스를 손으로 구성할 필요는 없어요. 하나의 런타임에서 많은 CDC 커넥터를 실행해야 한다면 Snowflake CoCo의 openflow 스킬이 권장 경로예요. 스킬은 커넥터 군 전체에 이 패턴을 일관되게 적용해요. 시작하려면 Snowflake CoCo CLI를 설치·연결한 다음 번들된 openflow 스킬에 레이아웃 구성을 요청하세요.

같은 유형의 CDC 커넥터 인스턴스를 하나의 런타임에 두 개 이상 가져올 때는 Source와 Destination 컨텍스트를 기본 이름으로 유지하고 모든 커넥터 인스턴스가 그로부터 상속하게 하세요. 해당 커넥터의 Ingestion 매개변수 컨텍스트에서는 공유 기본값과 다른 값만 재정의하세요: 연결 URL, 복제 슬롯 또는 서버 ID, 대상 데이터베이스, 테이블 목록. Snowflake 역할, 웨어하우스, JDBC 드라이버 같은 공유 값은 Source와 Destination 컨텍스트에 남겨 두어 모든 커넥터 인스턴스가 상속하게 하세요.

추가 커넥터 인스턴스마다 다음 프로세스를 사용하세요.

  1. 커넥터 인스턴스를 가져와요.
  2. 해당 Ingestion 컨텍스트가 새 Source·Destination 컨텍스트 집합을 만드는 대신 기존 Source·Destination 컨텍스트에서 상속하는지 확인해요.
  3. Ingestion 컨텍스트에서 공유 기본값과 달라야 하는 모든 값을 재정의해요. 최소한 소스 연결 ID(예: JDBC URL과 복제 슬롯 또는 서버 ID)와 대상 데이터베이스를 재정의하세요.
  4. 다음 커넥터 인스턴스로 넘어가기 전에 커넥터가 올바른 소스에서 올바른 대상으로 복제하는지 확인해요.

Source·Destination 컨텍스트 이름을 바꾸지 마세요

커넥터 인스턴스마다 고유하게 만들기 위해 Source 또는 Destination 매개변수 컨텍스트 이름을 바꾸지 마세요. 이 컨텍스트 이름을 바꾸면 각 커넥터 인스턴스를 시각적으로 구분하는 더 간단한 방법처럼 보일 수 있지만, 향후 커넥터 버전 업그레이드를 조용히 깨뜨려요.

Snowflake가 Source 또는 Destination 컨텍스트에 새 매개변수를 추가하는 커넥터 버전을 제공하면, 업그레이드 프로세스는 기본 이름을 가진 컨텍스트를 찾아 그 새 매개변수를 적용해요. 컨텍스트 이름을 바꿨다면 업그레이드 프로세스가 찾지 못해, 커넥터 인스턴스가 실제로 사용하는 컨텍스트에 새 매개변수가 추가되지 않아요. 그러면 커넥터 인스턴스가 새 버전과 조용히 어긋나게 되고 Snowflake 레지스트리가 이를 자동으로 복구할 수 없어요. 이 위험은 컨텍스트를 단일 공유 대체 이름으로 바꾸든 커넥터 인스턴스마다 고유한 이름으로 바꾸든 동일하게 적용돼요.

Ingestion 컨텍스트는 이름을 바꿔도 안전한데, 레지스트리가 새로운 커넥터 인스턴스마다 새 Ingestion 컨텍스트를 만들기 때문이에요. 이름을 바꿔도 다른 커넥터 인스턴스나 향후 업그레이드에는 영향을 주지 않아요. 모든 커넥터 인스턴스를 매개변수 컨텍스트 목록에서 개별적으로 식별할 수 있게 하려면 Ingestion 컨텍스트만 바꾸세요. 예를 들어 소스 데이터베이스 이름, 테넌트 이름, 리전으로 바꾸세요.

이전 커넥터 인스턴스의 의도치 않은 상속 피하기

추가 CDC 커넥터 인스턴스를 가져올 때 가장 흔한 실수는 전용 컨텍스트를 만드는 대신 이전 인스턴스의 Ingestion 컨텍스트를 의도치 않게 재사용하는 것이에요. 이 경우 새 커넥터 인스턴스가 이전 인스턴스의 소스 데이터베이스, 대상 데이터베이스, 테이블 목록, 복제 슬롯, 서버 ID 또는 XStream 구성을 사용해 오류 없이 잘못된 데이터를 복제하게 돼요.

추가 커넥터 인스턴스를 가져온 후에는 항상 해당 Ingestion 컨텍스트가 새 것이고 그 인스턴스에 전용이며 이전 커넥터 인스턴스와 공유되지 않는지 확인하세요. 가져오기 마법사가 기존 매개변수 컨텍스트를 상속하는 옵션을 제공하면, 기존 것을 재사용하지 않고 새 Ingestion 컨텍스트를 만드는지 확인하세요.

런타임 크기 변경

Openflow는 변경해야 할 대상에 따라 두 가지 유형의 크기 변경을 지원해요.

동일한 노드 유형 안에서 크기 변경

동일한 노드 유형 안에서 티어를 변경하려면(예: S1→S2, M4→M6) Openflow UI 또는 SQL을 사용하세요. 커넥터 마이그레이션이 필요 없어요.

노드 유형 안에서 크기를 변경하는 가장 흔한 이유는 현재 티어의 CPU 또는 힙 메모리 부족으로 커넥터가 실패하거나 느리게 실행되는 경우예요. 런타임의 CPU 사용량을 측정하려면 모니터링 가이드의 높은 CPU 쿼리를 사용하세요.

Openflow UI 사용:

  1. 런타임 목록에서 크기를 변경할 런타임의 메뉴를 열어요.
  2. 런타임 편집(Edit runtime) 을 선택해요.
  3. 노드 유형 티어(Node type tier) 를 원하는 티어로 변경해요.
  4. 저장(Save) 을 선택해요.

SQL 사용:

ALTER OPENFLOW RUNTIME my_runtime SET NODE_TYPE_TIER = 'S2';

노드 유형 변경

런타임의 노드 유형은 생성 시 고정돼요. 한 노드 유형에서 다른 노드 유형으로 전환하려면(예: Small→Medium) 대상 노드 유형의 새 런타임이 필요해요. 현재 복제 진행 상황을 보존할지 여부에 따라 두 가지 옵션이 있어요.

현재 커넥터의 진행 상황을 유지할 필요가 없다면, 필요한 노드 유형의 새 런타임을 만들고 그 위에 새 커넥터 인스턴스를 설치하는 것이 가장 간단한 경로예요. 새 커넥터는 처음부터 시작해요: 구성된 모든 테이블을 스냅샷한 다음 그 시점부터 진행 중인 변경을 캡처해요. 기존 커넥터의 복제 진행 상황은 폐기돼요.

현재 커넥터의 진행 상황을 유지하려면, 예를 들어 처음에 스냅샷하는 데 오래 걸린 테이블을 다시 스냅샷하지 않으려면 커넥터를 새 런타임으로 마이그레이션하세요. 이렇게 하면 기존 대상 테이블을 재사용하고 중단된 지점부터 증분 복제를 재개해요. 소스별로 다른 마이그레이션 단계는 실행 중인 커넥터의 재설치 또는 마이그레이션 지침을 참조하세요.

출처: Snowflake CDC 커넥터의 런타임 크기 조정 및 패킹