데이터 파이프라인을 위한 다중 위치 복원력¶

요구 사항¶

• 에디션: Snowflake Business Critical Edition 이상.

• 지원되는 수집 방법: 이 기능은 Snowpipe(자동 수집) 및 COPY INTO <table>을 통한 파일 기반 데이터 로딩만 지원합니다. Openflow 또는 Snowpipe Streaming은 지원하지 않습니다.

• 동일한 경로 구조: 장애 조치 후 파이프라인이 새 파일을 찾을 수 있도록 하려면 기본 위치와 정확히 동일한 계층 구조, 폴더 구조, 상대 경로를 사용하여 보조 저장소 위치에 파일을 작성해야 합니다.

고려 사항¶

• 청구: 이 기능을 사용하면 표준 복제 요금(데이터 전송 및 컴퓨팅 리소스)이 발생하며 대상 계정으로 청구됩니다.

• 스테이지 수정 다운타임: 기존 스테이지의 RELATIVE_URL 속성을 변경하면 종속 오브젝트가 무효화되고 수집이 중지됩니다. 다운타임을 방지하려면 설정 중에 새 스테이지를 생성하는 것이 좋습니다.

• 다중 큐 알림 통합(MQNI): 소스 계정과 대상 계정 모두에서 동일한 활성 큐 사용은 지원되지 않습니다. 동일한 활성 큐를 사용하는 경우 알림이 손실될 수 있습니다. Snowflake는 여러 계정에서 동일한 큐가 사용 중인지 여부를 확인하지 않습니다.

• 디렉터리 테이블: MLSI를 사용하여 스테이지에 디렉터리 테이블 생성은 현재 지원되지 않습니다.

복제 동작¶

• 비동기 복제: Snowflake는 정확히 동일한 스냅샷에서 테이블과 파이프라인의 로드 기록을 함께 복제합니다. 이는 동기화되므로 중단이 발생해도 데이터가 중복되지 않습니다. 보조 데이터베이스가 4시간 뒤처진 경우 테이블 데이터도 4시간 뒤처지며, 4시간 동안 큐에 대기 중인 알림을 처리하면 테이블이 최신 상태로 업데이트됩니다.

• 이중 쓰기 데이터 손실 방지: 복구 시점 목표(RPO)는 복제 새로 고침 간격에 따라 결정됩니다. 장애 조치 중 데이터 손실을 방지하려면 보조 클라우드 메시지 큐의 메시지 보존 기간이 복제 간격보다 길어야 합니다. 예약된 복제가 이를 따라잡기 전에 큐에서 메시지를 삭제하면 장애 조치 시 해당 파일이 수집되지 않습니다.

• 단일 쓰기 데이터 손실 위험: 단일 쓰기 라우팅을 사용하는 경우 마지막으로 복제에 성공한 후 기본 위치에서 처리된 모든 파일은 보조 위치에서 전혀 인식되지 않습니다. 장애 조치 시 이 데이터는 대상 계정에서 일시적으로 누락됩니다.

1. 이중 쓰기 - 권장¶

생산자 애플리케이션은 기본 및 보조 클라우드 저장소 버킷에 동시에 파일을 작성합니다. 보조 메시지 큐는 알림을 누적하지만, 보조 데이터베이스는 읽기 전용이므로 Snowflake는 알림을 처리하지 않습니다.

• 장애 조치 시 발생하는 결과: 보조 데이터베이스가 쓰기 가능 상태가 됩니다. Snowpipe는 보조 큐를 읽고 복제된 로드 기록을 사용하여 파일 중복을 제거합니다. 중단으로 인해 파일이 기본 위치에서 완료되지 못한 경우 보조 파이프라인은 보조 큐에서 알림을 읽으며 로드 기록에서 누락된 파일을 확인하고 수집합니다.

• 장애 복구 시의 결과: 기본 위치가 복구되고 장애 조치 그룹을 새로 고친 다음, 장애 복구하면 장애 복구 준비 중에 보조 계정에서 로드 기록이 동기화되었으므로 Snowpipe가 자동으로 새 파일 수집을 시작합니다.

• 결과: 누락된 데이터나 중복이 없습니다. Snowflake는 양방향에서 자동으로 조정을 처리합니다.

• 필요한 조치: 표준 장애 복구 전 복제 동기화(ALTER FAILOVER GROUP … REFRESH)를 사용하여 기본 계정에 최신 로드 기록이 있는지 확인하는 작업 외에는 없습니다.

2. 단일 쓰기 라우팅¶

생산자는 기본 클라우드 저장소에만 파일을 작성합니다. 중단이 발생하면 생산자를 다시 라우팅하여 보조 클라우드 저장소에 새 파일을 쓰기 시작합니다.

• 장애 조치 시 발생하는 결과: 보조 계정은 보조 버킷으로 라우팅된 새 파일을 즉시 처리하기 시작합니다. 그러나 영향을 받는 기본 위치에 갇힌 모든 진행 중인 파일은 일시적으로 남겨집니다.

• 장애 복구 시의 결과: 기본 위치가 복구되고 기본 Snowflake 계정으로 장애 복구되면 Snowpipe는 중단 전에 큐에 성공적으로 도달한 모든 파일 알림을 자동으로 처리합니다.

• 결과: 중복이 없습니다. 그러나 중단으로 인해 클라우드 알림이 완전히 생성되지 않은 파일(또는 중단이 큐의 메시지 보존 정책보다 오래 지속된 파일)에는 수동 개입이 필요합니다.

• 필요한 조치: 장애 복구 후 기본 저장소 버킷을 Snowflake의 COPY_HISTORY 뷰와 비교하여 누락된 파일을 식별합니다. ALTER PIPE … REFRESH 또는 수동 COPY INTO 명령을 실행하여 갇힌 특정 파일을 로드합니다.

1단계: 다중 위치 저장소 통합(MLSI) 생성¶

다중 위치 저장소 통합을 구성하려면 이 섹션에 언급된 몇 가지 차이점과 함께 저장소 통합을 구성하는 표준 단계를 따릅니다.

소스 계정에서 STORAGE_LOCATIONS 목록의 각 위치에 대한 값을 제공하여 MLSI를 생성합니다. 클라우드 간 설정을 위해 클라우드 공급자를 혼합하고 일치시킬 수 있습니다.

CREATE STORAGE INTEGRATION my_mlsi
  TYPE = EXTERNAL_STAGE
  STORAGE_LOCATIONS =
  (
    (
      NAME = 'my-s3-us-west-1'
      STORAGE_PROVIDER = 'S3'
      STORAGE_BASE_URL = 's3://myBucketWest'
      STORAGE_AWS_ROLE_ARN = 'arn:aws:iam::12345:role/myrole'
      STORAGE_AWS_EXTERNAL_ID = 'mlsi-external-id'
      ENCRYPTION = ( TYPE = 'AWS_SSE_S3' )
    ),
    (
      NAME = 'my-s3-us-east-1'
      STORAGE_PROVIDER = 'S3'
      STORAGE_BASE_URL = 's3://myBucketEast'
      STORAGE_AWS_ROLE_ARN = 'arn:aws:iam::67890:role/myrole'
      STORAGE_AWS_EXTERNAL_ID = 'mlsi-external-id'
      ENCRYPTION = ( TYPE = 'AWS_SSE_S3' )
    )
  )
  ENABLED = TRUE
  STORAGE_ALLOWED_LOCATIONS = ('*')
  ACTIVE = 'my-s3-us-west-1';

여기서

• STORAGE_LOCATIONS: 저장소 통합을 위해 하나 이상의 저장소 위치 목록을 지정합니다(S3 버킷, GCS 버킷 또는 Azure 컨테이너). 각 클라우드 공급자의 매개 변수를 보려면 CREATE STORAGE INTEGRATION 참조 페이지의 :ref:`클라우드 공급자 매개 변수(cloudProviderParams) <label-create_integration_storage_cloudProviderParams>`를 참조하세요.

• NAME: 저장소 위치의 식별자(이름)를 지정하는 문자열입니다.

• ENCRYPTION: 저장소 위치에 대한 암호화를 지정합니다. 스테이지 수준이 아닌 저장소 통합 수준에서 저장소 위치에 대한 암호화를 지정해야 합니다. 암호화된 파일에서 로딩하는 경우에만 필요하며, 저장소 위치와 파일이 암호화되지 않은 경우에는 필요하지 않습니다. 각 클라우드 공급자의 암호화 옵션을 보려면 CREATE STAGE 참조 페이지의 ENCRYPTION 섹션을 참조하세요.

• ACTIVE: 현재 계정에서 저장소 통합의 활성 위치로 설정할 저장소 위치의 이름을 지정합니다.

  소스 계정의 활성 저장소 위치에 대해 액세스 제어를 설정하고 저장소에 액세스할 수 있는 권한을 Snowflake에 부여해야 합니다. 다음 항목의 지침을 따릅니다.

  • Configuring a Snowflake storage integration to access Amazon S3

  • Google Cloud Storage용 통합 구성

  • 데이터를 로드하기 위해 Azure 컨테이너 구성

2단계: 외부 스테이지와 MLSI 연결¶

기존 스테이지를 변경하는 대신 새 스테이지를 생성하는 것이 좋습니다.

CREATE STAGE 명령을 사용하여 생성한 다중 위치 저장소 통합을 하나 이상의 외부 스테이지와 연결합니다.

CREATE STAGE my_ext_stage
  RELATIVE_URL = '/my_folder/my_sub_folder/'
  STORAGE_INTEGRATION = 'my_mlsi';

여기서

• RELATIVE_URL: 저장소 통합에 정의된 저장소 위치에서 외부 스테이지 위치로의 상대 경로입니다. 장애 조치 후 파이프라인이 새 파일을 찾을 수 있도록 하려면 기본 위치와 동일한 계층 구조, 폴더 구조, 상대 경로를 사용하여 보조 저장소 위치에 파일을 작성해야 합니다.

• STORAGE_INTEGRATION: 다중 위치 저장소 통합의 이름입니다.

예:

ALTER STAGE my_ext_stage SET
  RELATIVE_URL = '/my_folder/my_sub_folder/'
  STORAGE_INTEGRATION = 'my_mlsi';

3단계: 다중 큐 알림 통합(MQNI) 구성¶

클라우드 메시징을 통해 자동화된 데이터 로딩을 사용하고 외부 스테이지에 대해 다중 위치 저장소 통합을 구성한 경우, Snowpipe 파이프라인의 원활한 장애 조치를 위해 다중 큐 알림 통합도 사용해야 합니다.

알림 통합을 위해 정의하는 각 큐에 대해 다음 항목의 단계를 사용하여 메시징 서비스를 준비해야 합니다.

• SQS 알림을 사용하여 Snowpipe 자동화를 위한 Amazon SNS 구성하기. MLSI에 저장소 위치가 있는 각 AWS 리전에 대한 SNS 항목을 생성합니다.

• GCS Pub 및 Sub를 사용하여 자동화 구성하기

• Azure Event Grid를 사용하여 자동화 구성하기

CREATE NOTIFICATION INTEGRATION my_mqni
  ENABLED = TRUE
  TYPE = MULTI_QUEUE
  DIRECTION = INBOUND
  QUEUES = (
    (
      NAME = 'my-us-west-1'
      NOTIFICATION_PROVIDER = AWS_SNS
      AWS_SNS_TOPIC_ARN = 'arn:aws:sns:us-west-1:12345:my-snowpipe-mlsi-west'
    ),
    (
      NAME = 'my-us-east-1'
      NOTIFICATION_PROVIDER = AWS_SNS
      AWS_SNS_TOPIC_ARN = 'arn:aws:sns:us-west-1:12345:my-snowpipe-mlsi-east'
    )
  )
  ACTIVE = 'my-us-west-1';

CREATE PIPE my_pipe
  AUTO_INGEST = TRUE
  INTEGRATION = my_mqni
  AS COPY INTO my_table FROM @my_ext_stage/my_pipe/;

SYSTEM$CONVERT_PIPES_TO_MULTI_QUEUE(
  '<new_mqni_name>',
  '<original_sns_topic_arn_or_int_name>',
  '<new_sns_topic_arn_or_int_name>'
)

SELECT SYSTEM$CONVERT_PIPES_TO_MULTI_QUEUE(
  'my_mqni',
  'arn:aws:sns:us-west-1:12345:my-snowpipe-mlsi-west',
  'arn:aws:sns:us-east-1:67890:my-snowpipe-mlsi-east'
);

SELECT SYSTEM$CONVERT_PIPES_TO_MULTI_QUEUE(
  'my_azure_mqni',
  'my_azure_ni_1',
  'my_azure_ni_2'
);

4단계: MLSI 및 MQNI를 대상 계정에 복제¶

1. To replicate your multi-location storage integration and multi-queue notification integration, alter your existing replication or failover group to include STORAGE INTEGRATIONS and NOTIFICATION INTEGRATIONS in the ALLOWED_INTEGRATION_TYPES list.

예를 들어, ALTER FAILOVER GROUP 명령을 사용합니다.

ALTER FAILOVER GROUP my_fg SET
  OBJECT_TYPES = DATABASES, ROLES, INTEGRATIONS
  ALLOWED_INTEGRATION_TYPES = API INTEGRATIONS, STORAGE INTEGRATIONS,
    NOTIFICATION INTEGRATIONS;

2. 그런 다음 대상 계정에서 새로 고침 작업을 수행합니다.

ALTER FAILOVER GROUP my_fg REFRESH;

5단계: 대상 계정에서 활성 상태 구성¶

새로 고침 작업을 수행한 후 실제 중단 중에 원활한 장애 조치를 보장하려면 대상 계정에서 활성 저장소 위치와 큐(알림 통합을 사용하는 경우)를 구성합니다.

대상 계정에서:

1. 대상 계정에서 활성 위치로 설정하려는 저장소 위치에 대해 다음 항목의 지침을 사용하여 Snowflake에 저장소에 대한 액세스 권한을 부여합니다.

   • 옵션 1: Amazon S3에 액세스하기 위한 Snowflake 저장소 통합 구성

   • Google Cloud Storage용 통합 구성

   • 데이터를 로드하기 위해 Azure 컨테이너 구성

2. 보조 저장소 활성화: MLSI를 설정하여 대상 계정에서 보조 백업 저장소 위치를 사용합니다.

   CopyExpand

   ALTER STORAGE INTEGRATION my_mlsi SET ACTIVE = 'my-s3-us-east-1';
   

   Show lessSee more

   Scroll to top

3. 다중 큐 알림 통합을 사용하는 경우 대상 계정에서 활성으로 설정할 큐에 대한 메시징 서비스에 액세스할 수 있는 권한을 Snowflake에 부여합니다. 클라우드 공급자의 지침을 따릅니다.

   • AWS의 경우 :ref:`label-create_sns_topic_subscription`에서 Snowflake SQS 큐를 SNS 항목에 구독을 참조하세요.

   • Google Cloud의 경우 :ref:`label-gcp_pubsub_snowpipe`에서 Pub 및 Sub 구독에 Snowflake 액세스 권한 부여를 참조하세요.

   • Azure의 경우 :ref:`label-azure_configuring_automation`에서 저장소 큐에 Snowflake 액세스 권한 부여를 참조하세요.

4. 보조 큐 활성화(MQNI를 사용하는 경우): 활성 큐를 대상 계정의 보조 위치로 설정합니다.

   CopyExpand

   ALTER INTEGRATION my_mqni
     SET ACTIVE = 'MY_MQNI-queue2';
   

   Show lessSee more

   Scroll to top

1. 활성 통합 상태 확인¶

속성을 확인하여 통합이 올바른 저장소 및 큐를 가리키고 있는지 확인합니다. 출력의 ACTIVE 속성을 찾습니다.

-- Check the active storage location
DESCRIBE STORAGE INTEGRATION my_mlsi;

-- Check the active message queue
DESCRIBE INTEGRATION my_mqni;

2. 파이프 상태 확인(Snowpipe만 해당)¶

SYSTEM$PIPE_STATUS 함수를 사용하여 파이프가 실행 중인지 확인하고 파이프가 보조 위치의 새 파일을 적극적으로 큐에 넣고 있는지 확인합니다.

SELECT SYSTEM$PIPE_STATUS('my_pipe');

“executionState”:”RUNNING”을 찾고 “pendingFileCount”를 확인하여 보조 버킷에 삭제된 새 파일을 적극적으로 인식하고 있는지 확인합니다.

3. 성공적인 수집 검증(로드 기록)¶

데이터가 오류나 중복 없이 로드되도록 보장하려면 COPY_HISTORY 뷰를 쿼리합니다. 이는 수집된 파일, 해당 소스 경로, 로드된 시간을 정확히 보여줍니다.

SELECT file_name, status, row_count, last_load_time
FROM TABLE(information_schema.copy_history(
  table_name => 'my_table',
  start_time => DATEADD(hours, -1, CURRENT_TIMESTAMP())
));

file_name 경로가 활성 저장소 위치를 반영하고 상태가 LOADED로 표시되는지 확인합니다.