스테이지, 파이프 및 로드 기록 복제

이 항목에서는 스테이지, 저장소 통합, 파이프, 로드 기록을 포함하여 데이터 파이프라인 오브젝트와 관련 메타데이터의 복제 지원에 대한 정보를 제공합니다. 이러한 오브젝트를 복제하여 리전클라우드 플랫폼 전반에 걸쳐 수집 및 ETL 파이프라인에 대한 장애 조치를 구성할 수 있습니다.

시작하기 전에 복제 및 장애 조치/장애 복구에 대한 Snowflake 지원을 숙지하는 것이 좋습니다. 자세한 내용은 여러 계정에 걸쳐 복제 및 장애 조치 도입 섹션을 참조하십시오.

요구 사항

중요

사용하려는 대상 계정의 데이터베이스에 스테이지와 파이프가 이미 포함되어 있는 경우 복제를 활성화하기 전에 지원팀에 문의하는 것이 좋습니다. 원본 계정의 복제 또는 장애 조치 그룹에 해당 데이터베이스가 포함된 경우 기존 스테이지와 파이프가 데이터베이스에서 삭제됩니다.

데이터 파이프라인 오브젝트를 복제하려면 먼저 ETL 복제를 활성화해야 합니다. ETL 복제 지원은 2024_02 BCR 번들 의 일부입니다. 다음 문을 실행하여 2024_02 BCR 번들을 활성화 할 수 있습니다.

SELECT SYSTEM$ENABLE_BEHAVIOR_CHANGE_BUNDLE('2024_02');
Copy

참고

ETL 복제는 2024_01 번들의 일부였지만 2024_02 번들로 이동되었습니다.

저장소 통합을 사용하는 외부 스테이지를 복제하려면 STORAGE INTEGRATIONS 를 복제하도록 복제 그룹 또는 장애 조치 그룹도 구성해야 합니다. 그렇지 않으면 연결된 저장소 통합 없이 외부 스테이지가 복제됩니다.

ALTER REPLICATION GROUP 또는 ALTER FAILOVER GROUP 문을 사용하여 기존 그룹에 대해 이러한 속성을 수정할 수 있습니다.

ALTER 문의 OBJECT_TYPES 목록에 INTEGRATIONS 를 추가하는 경우 대상 계정에서 이러한 오브젝트가 삭제되지 않도록 목록에 다른 기존 오브젝트를 모두 포함하십시오. ALLOWED_INTEGRATION_TYPES 목록에 STORAGE INTEGRATIONS 를 추가하는 경우에도 같은 사항이 적용됩니다.

예:

ALTER FAILOVER GROUP my_failover_group SET
  OBJECT_TYPES = ROLES, INTEGRATIONS
  ALLOWED_INTEGRATION_TYPES = API INTEGRATIONS, STORAGE INTEGRATIONS;
Copy

참고

클라우드 저장소 공급자는 상업 클라우드 리전과 정부 클라우드 리전 간의 데이터 파이프라인 오브젝트 복제를 제한할 수 있습니다. 정부 클라우드 데이터 복제 제한 사항을 방지하려면 정부 클라우드 리전에 액세스할 수 있는 모든 리전에서 장애 조치 리소스를 구성하십시오. 정부 클라우드 제한 사항에 대한 자세한 내용은 클라우드 저장소 공급자의 설명서를 검토하십시오.

복제 및 스테이지

이 섹션에서는 다양한 스테이지 유형에 대해 Snowflake가 지원하는 복제 기능의 현재 수준에 대해 설명합니다.

내부 스테이지 복제

다음 표에서는 내부 스테이지의 각 유형에 대한 복제의 작동 방식을 설명합니다.

타입

복제 지원 설명

테이블 스테이지

복제된 데이터베이스의 테이블에 대해 빈 테이블 스테이지가 생성됩니다. 테이블 스테이지의 파일은 복제되지 않습니다.

사용자 스테이지

사용자 및 사용자 스테이지 복제에는 Business Critical Edition 이상이 필요합니다.

복제된 사용자에 대해 빈 사용자 스테이지가 생성됩니다. 사용자 스테이지의 파일은 복제되지 않습니다.

명명된 스테이지

데이터베이스를 복제하면 명명된 내부 스테이지가 복제됩니다.

스테이지의 파일을 복제하려면 스테이지에 디렉터리 테이블이 활성화되어 있어야 합니다.

외부 스테이지 복제

참고

Snowflake는 외부 스테이지의 파일을 복제하지 않습니다. 클라우드 저장소 URL은 기본 데이터베이스와 보조 데이터베이스의 외부 스테이지에 대해 동일한 위치를 가리킵니다.

다음 표에서는 외부 스테이지의 각 유형에 대한 복제의 작동 방식을 설명합니다.

타입

복제 지원 설명

자격 증명이 없는 명명된 스테이지(공용 저장소 위치)

데이터베이스를 복제하면 명명된 외부 스테이지가 복제됩니다. 외부 스테이지의 파일은 복제되지 않습니다.

자격 증명이 있는 명명된 스테이지(비공개 저장소 위치)

복제 스테이지에는 시크릿 키 또는 액세스 토큰과 같은 클라우드 공급자 자격 증명이 포함됩니다.

저장소 통합이 있는 명명된 스테이지(비공개 저장소 위치)

저장소 통합 복제에는 Business Critical Edition 이상이 필요합니다.

복제 그룹 또는 장애 조치 그룹의 ALLOWED_INTEGRATION_TYPES 목록에 STORAGE INTEGRATIONS 를 포함해야 합니다. 자세한 내용은 CREATE FAILOVER GROUP 섹션을 참조하십시오.

또한 대상 계정에서 클라우드 저장소의 신뢰 관계를 구성하기 위한 조치도 취해야 합니다. 자세한 내용은 보조 저장소 통합을 위한 클라우드 저장소 액세스 구성하기 섹션을 참조하십시오.

참고

보조 스테이지 또는 파이프를 기본 오브젝트와 연결된 위치와는 다른 클라우드 저장소 위치에 연결하려면 지원팀에 문의하십시오. 예를 들어 다른 리전의 위치를 선택할 수 있습니다.

고려 사항

스테이지 오브젝트에는 다음 제약 조건이 적용됩니다.

  • Snowflake는 현재 그룹 기반 복제(복제 및 장애 조치 그룹)의 일부로 스테이지 복제를 지원합니다. 데이터베이스 복제에는 스테이지 복제가 지원되지 않습니다.

  • 외부 스테이지를 복제할 수 있습니다. 단, 외부 스테이지의 파일은 복제되지 않습니다.

  • 내부 스테이지를 복제할 수 있습니다. 내부 스테이지에서 파일을 복제하려면 스테이지에서 디렉터리 테이블을 활성화해야 합니다. Snowflake는 디렉터리 테이블에서 매핑한 파일만 복제합니다.

  • 디렉터리 테이블이 있는 내부 스테이지를 복제할 경우 기본 또는 보조 스테이지에서 디렉터리 테이블을 비활성화할 수 없습니다. 디렉터리 테이블에는 복제된 파일과 COPY 문을 사용하여 로드된 파일에 대한 중요한 정보가 포함됩니다.

  • 내부 스테이지의 디렉터리 테이블에 5GB보다 큰 파일이 포함되어 있으면 새로 고침 작업이 실패합니다. 이 제한 사항을 해결하려면 5GB보다 큰 파일을 다른 스테이지로 이동하십시오.

    기본 스테이지 또는 보조 스테이지나 이전에 복제된 스테이지에서는 디렉터리 테이블을 비활성화할 수 없습니다. 스테이지가 포함된 데이터베이스를 복제 그룹이나 장애 조치 그룹에 추가하기 전에 다음 단계를 따르십시오.

    1. 기본 스테이지에서 디렉터리 테이블을 비활성화합니다.

    2. 5GB보다 큰 파일을 디렉터리 테이블이 활성화되지 않은 다른 스테이지로 이동합니다.

    3. 파일을 다른 스테이지로 이동한 후 기본 스테이지에서 디렉터리 테이블을 다시 활성화합니다.

  • 사용자 스테이지와 테이블 스테이지의 파일은 복제되지 않습니다.

  • 저장소 통합을 사용하는 명명된 외부 스테이지의 경우 장애 조치 전에 대상 계정에서 보조 저장소 통합에 대한 신뢰 관계를 구성해야 합니다. 자세한 내용은 보조 저장소 통합을 위한 클라우드 저장소 액세스 구성하기 섹션을 참조하십시오.

  • 디렉터리 테이블이 있는 외부 스테이지를 복제하고 원본 디렉터리 테이블에 대해 자동 새로 고침 을 구성한 경우 장애 조치 전에 보조 디렉터리 테이블에 대해 자동 새로 고침을 구성해야 합니다. 자세한 내용은 보조 스테이지에서 디렉터리 테이블에 대한 자동 새로 고침 구성하기 섹션을 참조하십시오.

  • 복제된 스테이지의 디렉터리 테이블이 스테이지의 복제된 파일과 일치하지 않을 경우 복사 명령이 예상보다 더 오래 걸릴 수 있습니다. 디렉터리 테이블을 일관되게 만들려면 ALTER STAGE … REFRESH 문으로 새로 고치십시오. 디렉터리 테이블의 일관성 상태를 확인하려면 SYSTEM$GET_DIRECTORY_TABLE_STATUS 함수를 사용하십시오.

복제 및 파이프

이 섹션에서는 다양한 파이프 유형에 대해 지원되는 복제 기능의 현재 수준에 대해 설명합니다.

Snowflake는 다음에 대한 복제를 지원합니다.

  • 외부 스테이지에서 데이터를 로드하는 자동 수집 및 REST 엔드포인트 파이프를 포함한 파이프 오브젝트.

  • 파이프 수준 매개 변수.

  • 파이프 오브젝트에 대한 권한 부여.

참고

보조 스테이지 또는 파이프를 기본 오브젝트와 연결된 위치와는 다른 클라우드 저장소 위치에 연결하려면 지원팀에 문의하십시오. 예를 들어 다른 리전의 위치를 선택할 수 있습니다.

보조 데이터베이스의 파이프

보조 데이터베이스의 파이프는 READ_ONLY 실행 상태에 있으며 알림을 받지만 기본 데이터베이스 역할을 하도록 보조 데이터베이스를 승격할 때까지 데이터를 로드하지 않습니다. 보조 데이터베이스를 승격하면 파이프가 FAILING_OVER 실행 상태로 전환됩니다. 장애 조치가 완료되면 파이프가 RUNNING 실행 상태에 있어야 하며 마지막 새로 고침 시간(즉, 이전 기본 데이터베이스가 마지막으로 업데이트된 시간) 이후 사용 가능한 모든 데이터를 로드하기 시작해야 합니다.

자동 수집 파이프 복제

장애 조치가 발생하는 경우 복제된 자동 수집 파이프가 새로운 기본 파이프가 되며 다음을 수행할 수 있습니다.

  • 아직 로드되지 않은 데이터를 로드할 수 있습니다. 여기에는 새로 승격된 기본 데이터베이스가 마지막으로 새로 고쳐진 이후 새로 생성된 데이터가 포함됩니다.

  • 스테이지에 로드할 새 파일이 있고 해당 파일에서 데이터를 로드할 경우 계속 알림을 받을 수 있습니다.

    참고

    알림을 받으려면 장애 조치 이전에 대상 계정에 보조 자동 수집 파이프를 구성해야 합니다. 자세한 내용은 보조 자동 수집 파이프에 대한 알림 구성하기 섹션을 참조하십시오.

REST 엔드포인트 파이프 복제

Snowpipe REST API 를 사용하여 데이터를 로드하는 파이프의 경우 Snowflake는 파이프와 파이프의 로드 기록 메타데이터를 사용자가 지정하는 각 대상 계정에 복제합니다. 대상 계정에서 수행해야 할 추가 구성 단계가 없습니다. 로드 기록 메타데이터의 세부 목록은 메타데이터 로드하기 섹션을 참조하십시오.

장애 조치 시 데이터 로딩을 계속하려면 새로 승격된 원본 계정에서 REST API를 호출하십시오.

고려 사항

파이프 오브젝트에는 다음 제약 조건이 적용됩니다.

  • Snowflake는 현재 그룹 기반 복제(복제 및 장애 조치 그룹)의 일부로 파이프 복제를 지원합니다. 데이터베이스 복제에는 파이프 복제가 지원되지 않습니다.

  • Snowflake는 파이프가 대상 테이블과 동일한 복제 그룹에 속하는 경우에만 파이프의 복사 기록을 복제합니다.

  • 알림 통합 복제는 지원되지 않습니다.

  • Snowflake는 최신 테이블이 잘린 후에만 로드 기록을 복제합니다.

  • 알림을 받으려면 장애 조치 이전에 대상 계정에 보조 자동 수집 파이프를 구성해야 합니다. 자세한 내용은 보조 자동 수집 파이프에 대한 알림 구성하기 섹션을 참조하십시오.

  • 장애 조치 후 예상 실행 상태가 아닌 파이프를 해결하려면 SYSTEM$PIPE_STATUS 함수를 사용하십시오.

예 1: 명명된 내부 스테이지 복제하기

이 예에서는 내부 스테이지에 대한 복제의 작동 방식을 보여줍니다. 특히 이 예에서는 디렉터리 테이블이 복제 전후의 스테이지 메타데이터에 대한 단일 정보 소스가 되는 방식을 보여줍니다.

이 예의 첫 번째 부분에서는 원본 계정에서 다음 작업을 완료합니다.

  1. 스테이지의 파일을 복제하기 위해 활성화된 디렉터리 테이블로 my_int_stage 라는 내부 스테이지를 생성합니다. 그런 다음 my_table 이라는 테이블의 데이터를 스테이지의 파일에 복사합니다.

    참고

    이 예에서는 file1file2 를 스테이지에 로드한 후 디렉터리 테이블을 새로 고쳐 테이블 메타데이터를 디렉터리 테이블의 스테이지 정의에 있는 최신 파일 세트와 동기화합니다. 하지만 file3 을 로드한 후에는 새로 고침 작업이 발생하지 않습니다.

    CREATE OR REPLACE STAGE my_stage
      DIRECTORY = (ENABLE = TRUE);
    
    COPY INTO @my_stage/folder1/file1 from my_table;
    COPY INTO @my_stage/folder2/file2 from my_table;
    ALTER STAGE my_stage REFRESH;
    
    COPY INTO @my_stage/folder3/file3 from my_table;
    
    Copy
  2. 장애 조치 그룹 만들기:

    CREATE FAILOVER GROUP my_stage_failover_group
      OBJECT_TYPES = DATABASES
      ALLOWED_DATABASES = my_database_1
      ALLOWED_ACCOUNTS = myorg.my_account_2;
    
    Copy

이 예의 두 번째 부분에서는 대상 계정에서 복제 및 장애 조치 프로세스를 완료합니다.

  1. 장애 조치 그룹을 원본 계정에 있는 장애 조치 그룹의 복제본으로 만들고, 새 장애 조치 그룹의 오브젝트를 새로 고치고, 원본 계정 역할을 하도록 대상 계정을 승격합니다.

    CREATE FAILOVER GROUP my_stage_failover_group
      AS REPLICA OF myorg.my_account_1.my_stage_failover_group;
    
    ALTER FAILOVER GROUP my_stage_failover_group REFRESH;
    
    ALTER FAILOVER GROUP my_stage_failover_group PRIMARY;
    
    Copy
  2. 다음으로, 복제된 스테이지에서 디렉터리 테이블을 새로 고치고 my_stage 의 디렉터리 테이블에서 추적하는 모든 파일을 my_table 이라는 테이블에 복사합니다.

    참고

    COPY INTO 문은 file1file2 를 테이블에 로드하지만 file3 은 로드하지 않습니다. 이는 원본 계정에 file3 을 추가한 후 디렉터리 테이블이 새로 고쳐지지 않았기 때문입니다.

    ALTER STAGE my_stage REFRESH;
    
    COPY INTO my_table FROM @my_stage;
    
    Copy

예 2: 외부 스테이지 및 저장소 통합 복제

이 예에서는 외부 스테이지 및 저장소 통합을 대상 계정에 복제하는 샘플 워크플로를 제공합니다.

이 예에서는 Amazon S3 버킷에 대한 보안 액세스 구성하기 를 이미 완료했다고 가정합니다.

이 예의 첫 번째 부분에서는 원본 계정에서 다음 작업을 완료합니다.

  1. 데이터베이스 my_database_2 의 Amazon S3 버킷에 대한 저장소 통합을 생성합니다.

    CREATE STORAGE INTEGRATION my_storage_int
      TYPE = external_stage
      STORAGE_PROVIDER = 's3'
      STORAGE_ALLOWED_LOCATIONS = ('s3://mybucket/path')
      STORAGE_BLOCKED_LOCATIONS = ('s3://mybucket/blockedpath')
      ENABLED = true;
    
    Copy
  2. 저장소 통합 my_storage_int 를 사용하여 데이터베이스 my_database_2 에 외부 스테이지를 생성합니다.

    CREATE STAGE my_ext_stage
      URL = 's3://mybucket/path'
      STORAGE_INTEGRATION = my_storage_int
    
    Copy
  3. 장애 조치 그룹을 생성하고 데이터베이스 my_database_2 및 저장소 통합 오브젝트를 포함합니다.

    CREATE FAILOVER GROUP my_external_stage_fg
      OBJECT_TYPES = databases, integrations
      ALLOWED_INTEGRATION_TYPES = storage integrations
      ALLOWED_DATABASES = my_database_2
      ALLOWED_ACCOUNTS = myorg.my_account_2;
    
    Copy

이 예의 두 번째 부분에서는 대상 계정에서 복제 및 장애 조치 프로세스를 완료합니다.

  1. 장애 조치 그룹을 원본 계정에 있는 장애 조치 그룹의 복제본으로서 생성하고 새로 고칩니다.

    CREATE FAILOVER GROUP my_external_stage_fg
      AS REPLICA OF myorg.my_account_1.my_external_stage_fg;
    
    ALTER FAILOVER GROUP my_external_stage_fg REFRESH;
    
    Copy
  2. 저장소 통합을 대상 계정에 복제한 후에는 클라우드 공급자 권한을 업데이트하여 클라우드 저장소에 대한 복제 통합 액세스 권한을 부여하는 추가 단계를 수행해야 합니다. 자세한 내용은 보조 저장소 통합을 위한 클라우드 저장소 액세스 구성하기 섹션을 참조하십시오.

예 3: 자동 수집 파이프 복제하기

이 예에서는 Amazon SQS(Simple Queue Service)와 함께 Amazon SNS(Simple Notification Service) 항목을 사용하여 Snowpipe를 자동화하는 파이프를 복제하는 샘플 워크플로를 제공합니다.

이 예에서는 다음 작업을 이미 완료했다고 가정합니다.

원본 계정에서 다음 작업부터 시작합니다.

  1. CREATE PIPE 명령을 사용하여 외부 스테이지의 데이터를 mytable 이라는 테이블에 로드하는 자동 수집이 활성화된 파이프를 만듭니다.

    CREATE PIPE snowpipe_db.public.mypipe AUTO_INGEST=TRUE
     AWS_SNS_TOPIC='<topic_arn>'
     AS
       COPY INTO snowpipe_db.public.mytable
       FROM @snowpipe_db.public.my_s3_stage
       FILE_FORMAT = (TYPE = 'JSON');
    
    Copy
  2. 지난 7일 동안의 데이터를 스테이지에서 로드하도록 ALTER PIPE 문으로 파이프를 새로 고칩니다.

    ALTER PIPE mypipe REFRESH;
    
    Copy
  3. 마지막으로, CREATE FAILOVER GROUP 을 사용하여 저장소 통합 복제를 허용하는 장애 조치 그룹을 생성합니다.

    CREATE FAILOVER GROUP my_pipe_failover_group
      OBJECT_TYPES = DATABASES, INTEGRATIONS
      ALLOWED_INTEGRATION_TYPES = STORAGE INTEGRATIONS
      ALLOWED_DATABASES = snowpipe_db
      ALLOWED_ACCOUNTS = myorg.my_account_2;
    
    Copy

이 예의 두 번째 부분에서는 대상 계정에서 복제 및 장애 조치 프로세스를 완료합니다.

  1. 장애 조치 그룹을 원본 계정에 있는 장애 조치 그룹의 복제본으로서 생성합니다.

    CREATE FAILOVER GROUP my_pipe_failover_group
      AS REPLICA OF myorg.my_account_1.my_pipe_failover_group;
    
    Copy
  2. DESCRIBE INTEGRATION 문을 실행하여 보조 배포에서 Snowflake 계정의 AWS IAM 사용자에 대한 ARN을 검색합니다.

    ARN을 사용하여 IAM 사용자에게 S3 버킷에 액세스하는 권한을 부여합니다. 5단계: IAM 사용자에게 버킷 오브젝트에 액세스하는 권한 부여를 참조하십시오.

    DESC INTEGRATION my_s3_storage_int;
    
    Copy
  3. SYSTEM$GET_AWS_SNS_IAM_POLICY 시스템 함수를 호출하여 SNS 항목을 구독할 수 있는 새로운 SQS 큐 권한을 부여하는 IAM 정책을 생성합니다. Snowflake는 원본 계정에서 장애 조치 그룹을 복제할 때 대상 계정에 새 SQS 큐를 생성했습니다.

    SELECT SYSTEM$GET_AWS_SNS_IAM_POLICY('<topic_arn>');
    
    Copy

    topic_arn 은 원본 계정의 원본 파이프에 대해 생성한 SNS 항목의 ARN(Amazon Resource Name)입니다.

    그런 다음 SNS 항목에 대해 새 Amazon SQS 큐를 구독합니다.

  4. 새 장애 조치 그룹의 오브젝트를 새로 고칩니다.

    ALTER FAILOVER GROUP my_pipe_failover_group REFRESH;
    
    Copy
  5. 마지막으로, ALTER FAILOVER GROUP 명령을 사용하여 원본 계정 역할을 하도록 대상 계정을 승격합니다.

    ALTER FAILOVER GROUP my_pipe_failover_group PRIMARY;
    
    Copy

    mypipe 파이프는 원본 계정에서 장애 조치 그룹을 마지막으로 새로 고친 이후 사용 가능한 모든 데이터를 로드하기 시작합니다.

    복제된 파이프가 작동하는지 확인하려면 파이프의 COPY 문에서 테이블을 쿼리하십시오.

    SELECT * FROM mytable;
    
    Copy

Amazon SNS(Simple Notification Service)로 마이그레이션하기

이 섹션에서는 다음 시나리오에 대해 Amazon S3 이벤트 알림을 Amazon Simple Queue Service(SQS) 큐로 직접 보내는 것에서 Amazon Simple Notification Service(SNS) 항목을 사용하는 것으로 마이그레이션하는 방법을 다룹니다.

디렉터리 테이블이나 파이프를 복제하면 Snowflake는 자동화를 처리하기 위해 대상 계정에 새 SQS 큐를 생성합니다. S3 버킷에서 여러 계정의 모든 SQS 큐로 이벤트 알림을 전달하도록 단일 SNS 항목을 구성할 수 있습니다. S3 이벤트 알림을 모든 SQS 큐에 브로드캐스팅하면 장애 조치 후 알림과 데이터가 손실될 위험이 감소합니다.

참고

이미 SNS를 사용하고 있다면 마이그레이션이 필요하지 않습니다. 대신 장애 조치 전에 보조 디렉터리 테이블이나 자동 수집 파이프에 대해 SNS를 사용하여 자동화를 구성하는 일반적인 단계를 따르십시오.

전제 조건

마이그레이션하려면 다음 조건을 충족해야 합니다.

SNS 항목으로 마이그레이션하기

  1. AWS 계정에서 SNS 항목을 만듭니다. 지침은 AWS SNS 설명서에서 Amazon SNS 항목 만들기 를 참조하십시오.

  2. S3 이벤트 알림에 대한 대상 목적지(예: 다른 SQS 큐 또는 AWS Lambda 워크로드)를 SNS 항목에 신청합니다. SNS 항목의 모든 구독자에게 버킷에 대한 이벤트 알림을 게시합니다. 자세한 지침은 AWSSNS 설명서 를 참조하십시오.

  3. 다음 권한으로 항목에 대한 액세스 정책을 업데이트합니다.

    • Snowflake IAM 사용자가 대상 계정에 있는 SQS 큐를 항목에 신청하도록 허용합니다.

    • Amazon S3이 버킷의 이벤트 알림을 SNS 항목에 게시하도록 허용합니다.

    지침은 1단계: Snowflake SQS 큐를 SNS 항목에 신청 을 참조하십시오.

  4. 대상 Snowflake 계정에서 SYSTEM$CONVERT_PIPES_SQS_TO_SNS 함수를 호출합니다. 이 함수는 메타데이터 동기화 또는 수집 작업을 중단하지 않고 대상 계정의 SQS 큐를 SNS 항목에 신청합니다.

    S3 버킷 이름과 SNS 항목 ARN을 지정합니다.

    SELECT SYSTEM$CONVERT_PIPES_SQS_TO_SNS('s3_mybucket', 'arn:aws:sns:us-west-2:001234567890:MySNSTopic')
    
    Copy
  5. S3 이벤트 알림을 업데이트하여 SNS 항목을 목적지로 사용합니다. 지침은 Amazon S3 사용자 가이드 를 참조하십시오.

이러한 단계를 완료하면 SQS 큐가 S3 이벤트 알림에서 자동으로 바인딩 해제됩니다. 지정된 S3 버킷을 사용하는 모든 디렉터리 테이블과 파이프는 SNS를 알림 소스로 사용하기 시작합니다.