스테이지, 파이프, 로드 이력 복제

스테이지, 파이프, 로드 이력 복제 (Stage, pipe, and load history replication)

이 토픽은 데이터 파이프라인 객체와 관련 메타데이터(스테이지, 스토리지 통합, 파이프, 로드 이력 포함)에 대한 복제 지원 정보를 제공해요. 이러한 객체를 복제해 리전(region) 간 및 클라우드 플랫폼(cloud platform) 간으로 수집(ingest) 및 ETL 파이프라인의 장애 조치를 구성할 수 있어요.

출처: Snowflake 문서 - Stage, pipe, and load history replication

본문

Standard 및 Business Critical 기능

• 데이터베이스와 공유 복제는 모든 계정에서 사용할 수 있어요.
• 그 외 계정 객체의 복제와 장애 조치/복구(failover/failback)에는 Business Critical Edition 이상이 필요해요.
• 업그레이드 문의는 Snowflake Support에 연락해요.

시작하기 전에 Snowflake의 복제 및 장애 조치/복구 지원에 익숙할 것을 권장해요. 자세한 내용은 여러 계정 간 복제와 장애 조치 소개 를 참고해요.

요구 사항

중요

사용하려는 타깃 계정의 데이터베이스에 이미 스테이지와 파이프가 포함되어 있다면 복제를 활성화하기 전에 지원팀에 연락할 것을 권장해요. 소스 계정의 복제/장애 조치 그룹이 해당 데이터베이스를 포함하면 데이터베이스의 기존 스테이지와 파이프가 삭제돼요.

스토리지 통합을 사용하는 외부 스테이지를 복제하려면 복제/장애 조치 그룹이 STORAGE INTEGRATIONS 를 복제하도록 구성해야 해요. 그렇지 않으면 외부 스테이지가 연결된 스토리지 통합 없이 복제돼요.

ALTER REPLICATION GROUP 또는 ALTER FAILOVER GROUP 문을 사용해 기존 그룹의 이러한 속성을 수정할 수 있어요.

ALTER 문에서 INTEGRATIONS 를 OBJECT_TYPES 목록에 추가하면 타깃 계정에서 해당 객체가 삭제되는 것을 방지하기 위해 기존 객체를 목록에 포함해요. STORAGE INTEGRATIONS 를 ALLOWED_INTEGRATION_TYPES 목록에 추가하는 경우에도 동일하게 적용돼요.

예:

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

참고: 클라우드 스토리지 프로바이더가 상용 및 정부 클라우드 리전 사이의 데이터 파이프라인 객체 복제를 제한할 수 있어요. 정부 클라우드 데이터 복제 제한을 피하려면 정부 클라우드 리전에서 접근할 수 있는 모든 리전에 장애 조치 리소스를 구성해요. 정부 클라우드 제한에 대한 자세한 내용은 클라우드 스토리지 프로바이더의 문서를 검토해요.

복제와 스테이지

이 섹션은 Snowflake가 다른 유형의 스테이지에 대해 현재 지원하는 복제 기능 수준을 설명해요.

내부 스테이지의 복제

다음 표는 각 내부 스테이지 유형에 대해 복제가 어떻게 작동하는지 설명해요.

유형	복제 지원 설명
테이블 스테이지	복제된 데이터베이스의 테이블에 대해 빈 테이블 스테이지가 생성돼요. 테이블 스테이지의 파일은 복제되지 않아요.
사용자 스테이지	사용자 및 사용자 스테이지 복제에는 Business Critical Edition(이상)이 필요해요. 복제된 사용자에 대해 빈 사용자 스테이지가 생성돼요. 사용자 스테이지의 파일은 복제되지 않아요.
명명된 스테이지	데이터베이스를 복제하면 명명된 내부 스테이지가 복제돼요. 스테이지의 파일을 복제하려면 스테이지에 디렉터리 테이블이 활성화되어 있어야 해요.

외부 스테이지의 복제

참고: Snowflake는 외부 스테이지의 파일을 복제하지 않아요. 클라우드 스토리지 URL은 기본 및 보조 데이터베이스의 외부 스테이지에 대해 같은 위치를 가리켜요.

다음 표는 각 외부 스테이지 유형에 대해 복제가 어떻게 작동하는지 설명해요.

유형	복제 지원 설명
자격 증명이 없는 명명된 스테이지(공용 스토리지 위치)	데이터베이스를 복제하면 명명된 외부 스테이지가 복제돼요. 외부 스테이지의 파일은 복제되지 않아요.
자격 증명이 있는 명명된 스테이지(프라이빗 스토리지 위치)	복제된 스테이지에는 시크릿 키나 접근 토큰 같은 클라우드 프로바이더 자격 증명이 포함돼요.
스토리지 통합이 있는 명명된 스테이지(프라이빗 스토리지 위치)	스토리지 통합 복제에는 Business Critical Edition(이상)이 필요해요. 복제/장애 조치 그룹의 ALLOWED_INTEGRATION_TYPES 목록에 STORAGE INTEGRATIONS 가 포함되어야 해요. 자세한 내용은 CREATE FAILOVER GROUP 을 참고해요. 또한 타깃 계정에서 클라우드 스토리지에 대한 신뢰 관계를 구성하는 조치를 취해야 해요. 자세한 내용은 보조 스토리지 통합을 위한 클라우드 스토리지 접근 구성 을 참고해요.

참고: 보조 스테이지나 파이프를 기본 객체와 연결된 것과 다른 클라우드 스토리지 위치와 연결하려면 지원팀에 연락해요. 예를 들어 다른 리전의 위치를 선택할 수 있어요.

고려 사항

스테이지 객체에는 다음 제약 사항이 적용돼요.

• Snowflake는 현재 그룹 기반 복제(복제 및 장애 조치 그룹)의 일부로 스테이지 복제를 지원해요. 데이터베이스 복제에서는 스테이지 복제가 지원되지 않아요.
• 외부 스테이지를 복제할 수 있어요. 다만 외부 스테이지의 파일은 복제되지 않아요.
• 내부 스테이지를 복제할 수 있어요. 내부 스테이지의 파일을 복제하려면 스테이지에서 디렉터리 테이블을 활성화해야 해요. Snowflake는 디렉터리 테이블이 매핑한 파일만 복제해요.
• 디렉터리 테이블이 있는 내부 스테이지를 복제할 때는 기본 또는 보조 스테이지에서 디렉터리 테이블을 비활성화할 수 없어요. 디렉터리 테이블에는 복제된 파일과 COPY 문으로 로드된 파일에 대한 중요한 정보가 들어 있어요.
• 내부 스테이지의 디렉터리 테이블에 5GB보다 큰 파일이 있으면 새로고침 작업이 실패해요. 이 제한을 해결하려면 5GB보다 큰 파일을 다른 스테이지로 옮겨요. 기본 또는 보조 스테이지, 또는 이전에 복제된 적이 있는 스테이지에서는 디렉터리 테이블을 비활성화할 수 없어요. 스테이지를 포함하는 데이터베이스를 복제/장애 조치 그룹에 추가하기 전에 다음 단계를 따르세요.
  • 기본 스테이지의 디렉터리 테이블을 비활성화해요.
  • 5GB보다 큰 파일을 디렉터리 테이블이 활성화되지 않은 다른 스테이지로 옮겨요.
  • 파일을 다른 스테이지로 옮긴 후 기본 스테이지의 디렉터리 테이블을 다시 활성화해요.
• 사용자 스테이지와 테이블 스테이지의 파일은 복제되지 않아요.
• 스토리지 통합을 사용하는 명명된 외부 스테이지의 경우 장애 조치 전에 타깃 계정에서 보조 스토리지 통합에 대한 신뢰 관계를 구성해야 해요. 자세한 내용은 보조 스토리지 통합을 위한 클라우드 스토리지 접근 구성 을 참고해요.
• 디렉터리 테이블이 있는 외부 스테이지를 복제하고 소스 디렉터리 테이블에 대해 자동 새로고침 을 구성했다면 장애 조치 전에 보조 디렉터리 테이블에 대해 자동 새로고침을 구성해야 해요. 자세한 내용은 보조 스테이지의 디렉터리 테이블에 대한 자동 새로고침 구성 을 참고해요.
• 복제된 스테이지의 디렉터리 테이블이 스테이지의 복제된 파일과 일치하지 않으면 복사(COPY) 명령이 예상보다 오래 걸릴 수 있어요. 디렉터리 테이블을 일치시키려면 ALTER STAGE … REFRESH 문으로 새로고침해요. 디렉터리 테이블의 일관성 상태를 확인하려면 SYSTEM$GET_DIRECTORY_TABLE_STATUS 함수를 사용해요.

복제와 파이프

이 섹션은 다른 유형의 파이프에 대해 지원되는 현재 복제 기능 수준을 설명해요.

Snowflake는 다음에 대한 복제를 지원해요.

• 외부 스테이지에서 데이터를 로드하는 자동 로드 및 REST 엔드포인트 파이프를 포함한 파이프 객체.
• 파이프 수준 파라미터.
• 파이프 객체에 대한 권한 부여.

참고: 보조 스테이지나 파이프를 기본 객체와 연결된 것과 다른 클라우드 스토리지 위치와 연결하려면 지원팀에 연락해요. 예를 들어 다른 리전의 위치를 선택할 수 있어요.

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

보조 데이터베이스의 파이프는 READ_ONLY 실행 상태이며 알림을 받지만 보조 데이터베이스를 기본으로 승격할 때까지 데이터를 로드하지 않아요. 보조 데이터베이스를 승격한 후 파이프는 FAILING_OVER 실행 상태로 전환돼요. 장애 조치가 완료되면 파이프는 RUNNING 실행 상태가 되어 마지막 새로고침 이후(즉 이전 기본 데이터베이스가 마지막으로 업데이트된 이후)에 사용할 수 있는 데이터를 로드하기 시작해요.

자동 로드 파이프의 복제

장애 조치 시 복제된 자동 로드 파이프가 새 기본 파이프가 되어 다음을 수행할 수 있어요.

• 아직 로드되지 않은 데이터를 로드해요. 여기에는 새로 승격된 기본 데이터베이스가 마지막으로 새로고침된 이후 새로 추가된 데이터가 포함돼요.
• 스테이지에 새로 로드할 파일이 있을 때 알림을 계속 받고 해당 파일의 데이터를 로드해요.
  • 참고: 알림을 받으려면 장애 조치 전에 타깃 계정에서 보조 자동 로드 파이프를 구성해야 해요. 자세한 내용은 보조 자동 로드 파이프에 대한 알림 구성 을 참고해요.

REST 엔드포인트 파이프의 복제

Snowpipe REST API 를 사용해 데이터를 로드하는 파이프의 경우 Snowflake는 파이프와 해당 로드 이력 메타데이터를 지정한 각 타깃 계정으로 복제해요. 타깃 계정에서 추가로 수행할 구성 단계는 없어요. 로드 이력 메타데이터의 자세한 목록은 로드 메타데이터 를 참고해요.

장애 조치 시에도 데이터 로드를 계속하려면 새로 승격된 소스 계정에서 REST API를 호출해요.

고려 사항

파이프 객체에는 다음 제약 사항이 적용돼요.

• Snowflake는 현재 그룹 기반 복제(복제 및 장애 조치 그룹)의 일부로 파이프 복제를 지원해요. 데이터베이스 복제에서는 파이프 복제가 지원되지 않아요.
• Snowflake는 파이프가 대상 테이블과 같은 복제 그룹에 속할 때만 파이프의 복사 이력(copy history)을 복제해요.
• 알림 통합의 복제는 지원되지 않아요.
• Snowflake는 최신 테이블 truncate 이후의 로드 이력만 복제해요.
• 알림을 받으려면 장애 조치 전에 타깃 계정에서 보조 자동 로드 파이프를 구성해야 해요. 자세한 내용은 보조 자동 로드 파이프에 대한 알림 구성을 참고해요.
• 장애 조치 후 예상 실행 상태가 아닌 파이프를 해결하려면 SYSTEM$PIPE_STATUS 함수를 사용해요.
• Snowflake는 Kafka 커넥터가 있는 Snowpipe의 복제와 장애 조치를 지원하지 않지만, Kafka 커넥터가 있는 Snowpipe Streaming의 복제와 장애 조치는 지원해요. 자세한 내용은 Snowpipe Streaming과 Kafka 커넥터를 참고해요.

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

이 예제는 내부 스테이지에 대해 복제가 어떻게 작동하는지 보여줘요. 특히 복제 전후에 디렉터리 테이블이 스테이지 메타데이터의 단일 사실 원본(single source of truth)이 되는 방법을 보여줘요.

예제의 첫 부분은 소스 계정에서 다음 작업을 완료해요.

• 스테이지의 파일을 복제하기 위해 디렉터리 테이블이 활성화된 my_int_stage 라는 내부 스테이지를 만들어요. 그런 다음 my_table 이라는 테이블의 데이터를 스테이지의 파일로 복사해요.
  • 참고: 디렉터리 테이블에 대한 스테이지 정의에서 테이블 메타데이터를 최신 파일 집합과 동기화하기 위해 예제는 file1 과 file2 를 스테이지에 로드한 후 디렉터리 테이블을 새로고침해요. 그러나 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;

• 장애 조치 그룹을 만들어요.

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

예제의 두 번째 부분은 타깃 계정에서 복제 및 장애 조치 과정을 완료해요.

• 소스 계정의 장애 조치 그룹의 복제본으로 장애 조치 그룹을 만들고, 새 장애 조치 그룹의 객체를 새로고침하며, 타깃 계정을 소스 계정으로 승격해요.

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;

• 다음으로, 복제된 스테이지의 디렉터리 테이블을 새로고침하고 my_stage 에서 디렉터리 테이블이 추적하는 모든 파일을 my_table 이라는 테이블로 복사해요.
  • 참고: COPY INTO 문은 file1 과 file2 를 테이블에 로드하지만 file3 은 로드하지 않아요. 소스 계정에서 file3 을 추가한 후 디렉터리 테이블이 새로고침되지 않았기 때문이에요.

ALTER STAGE my_stage REFRESH;

COPY INTO my_table FROM @my_stage;

예제 2: 외부 스테이지 및 스토리지 통합 복제

이 예제는 외부 스테이지와 스토리지 통합을 타깃 계정으로 복제하는 샘플 워크플로우를 제공해요.

예제는 이미 다음을 완료했다고 가정해요: Amazon S3 버킷에 대한 보안 접근 구성.

예제의 첫 부분은 소스 계정에서 다음 작업을 완료해요.

• 데이터베이스 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;

• 스토리지 통합 my_storage_int 를 사용해 데이터베이스 my_database_2 에 외부 스테이지를 만들어요.

CREATE STAGE my_ext_stage
  URL = 's3://mybucket/path'
  STORAGE_INTEGRATION = my_storage_int

• 장애 조치 그룹을 만들고 데이터베이스 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;

예제의 두 번째 부분은 타깃 계정에서 복제 및 장애 조치 과정을 완료해요.

• 소스 계정의 장애 조치 그룹의 복제본으로 장애 조치 그룹을 만들고 새로고침해요.

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;

• 스토리지 통합을 타깃 계정으로 복제한 후 클라우드 프로바이더 권한을 업데이트해 복제 통합에 클라우드 스토리지에 대한 접근 권한을 부여하는 추가 단계를 수행해야 해요. 자세한 내용은 보조 스토리지 통합을 위한 클라우드 스토리지 접근 구성 을 참고해요.

예제 3: 자동 로드 파이프 복제

이 예제는 Snowpipe를 자동화하기 위해 Amazon Simple Queue Service(SQS)와 함께 Amazon Simple Notification Service(SNS) 토픽 을 사용하는 파이프를 복제하는 샘플 워크플로우를 제공해요.

예제는 이미 다음 작업을 완료했다고 가정해요.

• Amazon S3용 스토리지 통합을 생성하고 구성함. 예제에서는 my_s3_storage_int라는 스토리지 통합을 사용해요.
• Amazon SNS 토픽과 구독을 만들고 Snowflake SQS 큐를 SNS 토픽에 구독함.
• 스토리지 통합을 참조하는 외부 스테이지를 만듦. 예제에서는 my_s3_stage라는 스테이지를 사용해요. 지침은 CREATE STAGE를 참고해요.

소스 계정에서 다음 작업으로 시작해요.

• 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');

• ALTER PIPE 문으로 파이프를 새로고침해 지난 7일 동안의 스테이지에서 데이터를 로드해요.

ALTER PIPE mypipe REFRESH;

• 마지막으로 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;

예제의 두 번째 부분은 타깃 계정에서 복제 및 장애 조치 과정을 완료해요.

• 소스 계정의 장애 조치 그룹의 복제본으로 장애 조치 그룹을 만들어요.

CREATE FAILOVER GROUP my_pipe_failover_group
  AS REPLICA OF myorg.my_account_1.my_pipe_failover_group;

• DESCRIBE INTEGRATION 문을 실행해 보조 배포에서 Snowflake 계정의 AWS IAM 사용자에 대한 ARN을 검색해요. ARN을 사용해 IAM 사용자에게 S3 버킷에 접근할 권한을 부여해요. 5단계: IAM 사용자에게 버킷 객체 접근 권한 부여 를 참고해요.

DESC INTEGRATION my_s3_storage_int;

• SYSTEM$GET_AWS_SNS_IAM_POLICY 시스템 함수를 호출해 새 SQS 큐가 SNS 토픽에 구독할 수 있는 권한을 부여하는 IAM 정책을 생성해요. Snowflake는 소스 계정에서 장애 조치 그룹을 복제할 때 타깃 계정에 새 SQS 큐를 만들었어요.

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

topic_arn 은 소스 계정에서 원래 파이프용으로 만든 SNS 토픽의 Amazon Resource Name(ARN)이에요. 그런 다음 새 Amazon SQS 큐를 SNS 토픽에 구독 해요.

• 새 장애 조치 그룹의 객체를 새로고침해요.

ALTER FAILOVER GROUP my_pipe_failover_group REFRESH;

• 마지막으로 ALTER FAILOVER GROUP 명령으로 타깃 계정을 소스 계정으로 승격해요.

ALTER FAILOVER GROUP my_pipe_failover_group PRIMARY;

mypipe 파이프는 소스 계정에서 장애 조치 그룹이 마지막으로 새로고침된 이후로 사용할 수 있게 된 데이터를 로드하기 시작할 거예요. 복제된 파이프가 작동하는지 확인하려면 파이프의 COPY 문에서 테이블을 쿼리해요.

SELECT * FROM mytable;

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

이 섹션은 다음 시나리오에 대해 Amazon S3 이벤트 알림을 Amazon Simple Queue Service(SQS) 큐로 직접 보내는 대신 Amazon Simple Notification Service(SNS) 토픽을 사용하도록 마이그레이션하는 방법을 다뤄요.

• Amazon S3용 디렉터리 테이블 자동 새로고침
• Amazon S3용 Snowpipe 자동화

디렉터리 테이블이나 파이프를 복제하면 Snowflake가 타깃 계정에 자동화를 처리할 새 SQS 큐를 만들어요. 단일 SNS 토픽을 구성해 S3 버킷의 이벤트 알림을 여러 계정의 모든 SQS 큐에 전달할 수 있어요. S3 이벤트 알림을 모든 SQS 큐에 브로드캐스트하면 장애 조치 후 알림과 데이터가 손실될 위험을 줄일 수 있어요.

참고: 이미 SNS를 사용한다면 마이그레이션이 필요하지 않아요. 대신 장애 조치 전에 보조 디렉터리 테이블이나 자동 로드 파이프에 대해 SNS로 자동화를 구성하는 일반적인 단계를 따르세요.

• 보조 스테이지의 디렉터리 테이블에 대한 자동 새로고침 구성
• 보조 자동 로드 파이프에 대한 알림 구성

사전 요구 사항

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

• S3 버킷에 대해 이벤트 알림을 하나 이상 이미 설정함. 지침은 사용 사례에 대한 토픽을 참고해요.
  • Amazon S3용 디렉터리 테이블 자동 새로고침: 새 S3 이벤트 알림 만들기
  • Snowpipe 자동화를 위한 새 S3 이벤트 알림 만들기
• 디렉터리 테이블이 있는 스테이지나 파이프를 포함하는 복제/장애 조치 그룹을 타깃 계정에 이미 만들었음.

SNS 토픽으로 마이그레이션

• AWS 계정에 SNS 토픽을 만들어요. 지침은 AWS SNS 문서의 Amazon SNS 토픽 만들기 를 참고해요.
• S3 이벤트 알림에 대한 타깃 대상(예: 다른 SQS 큐나 AWS Lambda 워크로드)을 SNS 토픽에 구독해요. SNS는 버킷에 대한 이벤트 알림을 토픽의 모든 구독자에게 게시해요. 지침은 AWS SNS 문서 를 참고해요.
• 토픽의 접근 정책을 다음 권한으로 업데이트해요.
  • Snowflake IAM 사용자가 타깃 계정의 SQS 큐를 토픽에 구독할 수 있도록 허용.
  • Amazon S3가 버킷의 이벤트 알림을 SNS 토픽에 게시할 수 있도록 허용. 지침은 1단계: Snowflake SQS 큐를 SNS 토픽에 구독 을 참고해요.
• 타깃 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')

• S3 이벤트 알림을 업데이트해 SNS 토픽을 대상으로 사용해요. 지침은 Amazon S3 사용자 가이드 를 참고해요.

이 단계를 완료한 후 SQS 큐는 자동으로 S3 이벤트 알림에서 분리돼요. 지정된 S3 버킷을 사용하는 모든 디렉터리 테이블과 파이프는 SNS를 알림 소스로 사용하기 시작할 거예요.

더 알아보기 (Learn more)

• 여러 계정 간 복제와 장애 조치 소개 — 복제 개념과 복제된 객체
• 복제 고려 사항 — 복제된 객체의 동작과 제약
• 여러 계정 간 데이터베이스 및 계정 객체 복제 — 복제 구성 워크플로우
• 여러 계정 간 보안 통합 및 네트워크 정책 복제 — 보안 통합 및 네트워크 정책 복제