Snowflake Data Clean Rooms 에서 클라우드 간 자동 복제 관리하기¶
클라우드 간 자동 복제 정보¶
기본 Clean Room 환경에서는 동일한 클라우드 리전에 있는 계정과만 Clean Room을 공유할 수 있습니다. 즉, 공급자와 컨슈머는 동일한 클라우드 리전에 있어야 합니다.
계정이 나와 다른 리전에 있는 공동 작업자와 공동 작업하려면 이 페이지에 표시된 대로 클린룸 환경과 클린룸에 대해 :doc:`클라우드 간 자동 복제</collaboration/provider-listings-auto-fulfillment>`를 활성화해야 합니다.
SELECT CURRENT_REGION(); 을 실행하여 자체 클라우드 리전을 확인할 수 있습니다.
클라우드 간 자동 복제 활성화하기¶
API 또는 UI를 사용하여 클라우드 간 자동 복제를 활성화할 수 있습니다. 그러나 :ref:`리전 간 협업에 대한 제한 사항<label-dcr_LAF_limitations>`을 참고하세요.
전제 조건¶
계정에 대해 클라우드 간 자동 복제를 활성화하려면 모든 공동 작업자의 조직 관리자가 먼저 :doc:`/sql-reference/functions/system_enable_global_data_sharing_for_account`를 호출하여 계정에서 이를 활성화해야 합니다.
자동 복제 및 :doc:`자동 복제 권한 관리</collaboration/provider-listings-auto-fulfillment-manage-privileges>`에 대해 자세히 알아보세요.
UI에서 클라우드 간 자동 복제 활성화하기¶
클린룸 관리자는 다음 단계에 따라 모든 신규 및 기존 클린룸에 대해 계정 수준에서 클라우드 간 자동 복제를 활성화합니다.
API에서 클라우드 간 자동 복제 활성화하기¶
UI에서 클라우드 간 자동 복제를 이미 활성화한 경우에도 다음 지침에 따라 API에 클린룸을 만들거나 설치하세요.
계정 관리자 작업¶
API를 사용하여 계정에 대해 클라우드 간 자동 복제를 활성화하려면 공급자 계정과 컨슈머 계정 모두의 관리자가 ACCOUNTADMIN 역할을 사용하여 다음 SQL 코드를 실행해야 합니다. 이 작업은 계정당 한 번만 실행해야 합니다.
USE ROLE ACCOUNTADMIN;
-- Optionally check first to see if LAF is enabled on the account.
CALL samooha_by_snowflake_local_db.library.is_laf_enabled_on_account();
-- If LAF is not enabled, enable it.
CALL samooha_by_snowflake_local_db.library.enable_laf_on_account();
공급자 및 컨슈머 작업¶
계정에 대해 클라우드 간 자동 복제가 활성화된 후 클린룸을 만들거나 설치할 때 클라우드 간 자동 복제를 활성화하는 방법은 다음과 같습니다.
**공급자**는 ``provider.create_or_update_cleanroom_listing``을 호출하여 일반적인 방식으로 클린룸을 게시합니다.
컨슈머 는 ``consumer.install_cleanroom``을 호출하여 클린룸을 설치합니다. 컨슈머가 공급자와 다른 클라우드 리전에 있는 경우, ``consumer.install_cleanroom``이 클라우드 간 자동 복제의 복제가 설치되고 있다는 메시지와 함께 실패합니다.
**컨슈머**는 성공을 반환할 때까지 ``consumer.install_cleanroom``을 계속 호출합니다. 설치에는 몇 분이 걸립니다.
이 시점에서 컨슈머는 기본적인 클린룸 기능을 갖습니다. 클라이언트 사용자 지정 템플릿 요청, 공급자 실행 분석, 공급자 활성화를 지원하려면 다음 추가 단계를 따르세요.
공급자 프로시저가 성공을 보고할 때까지 ``provider.mount_request_logs_for_all_consumers``를 호출합니다. 이는 컨슈머에서 공급자로의 통신이 활성화되었음을 의미합니다.
전체 설정 코드 예:
공급자: 공급자는 표준 방식으로 Clean Room을 생성, 공유 및 게시합니다.
USE WAREHOUSE APP_WH; USE ROLE SAMOOHA_APP_ROLE; SET cleanroom_name = 'LAF example'; SET consumer_locator = '<CONSUMER_LOCATOR>'; SET consumer_account_name = '<CONSUMER_DATA_SHARING_ACCOUNT_ID>'; CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.provider.cleanroom_init($cleanroom_name); CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.provider.set_default_release_directive( $cleanroom_name, 'V1_0', '0'); CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.provider.add_consumers( $cleanroom_name, $consumer_locator, $consumer_account_name); CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.provider.create_or_update_cleanroom_listing($cleanroom_name);
컨슈머: 컨슈머가 클린룸을 설치합니다.
USE WAREHOUSE APP_WH; USE ROLE SAMOOHA_APP_ROLE; SET cleanroom_name = 'LAF example'; SET provider_locator = '<PROVIDER_LOCATOR>'; -- Initial call starts the process and returns a cross-cloud/region replication failure. -- Continue to call this procedure until it returns a success message. CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.consumer.install_cleanroom( $cleanroom_name, $provider_locator); -- Continue with standard clean room configuration and use. -- The consumer can run analyses, but client custom templates, provider run, and provider analysis -- aren't supported until the provider takes the action shown in the next step. ...
공급자: 컨슈머가 클린룸을 설치한 후 공급자와 컨슈머 사이에서 요청 기반 작업을 활성화하려면 공급자가 요청 공유를 마운트해야 합니다. 요청 기반 작업에는 분석을 실행하라는 공급자 요청과 클린룸에 템플릿을 추가하라는 컨슈머 요청이 포함됩니다.
-- Call mount_request_logs_for_all_consumers until it reports success. provider.mount_request_logs_for_all_consumers($cleanroom_name);
이제 전체 공급자/컨슈머 기능을 사용할 수 있습니다.
리전 간 계정의 새로 고침 빈도¶
서로 다른 클라우드 리전에 있을 때 공급자와 컨슈머 간의 요청 및 데이터에는 복제 빈도 설정이 적용됩니다.
공급자가 컨슈머에게 보내는 요청 및 데이터¶
여기에는 클린룸 생성 또는 업데이트, 공급자 데이터 변경, 권한 요청(예: 공급자 실행 분석), 요청 승인(예: 컨슈머 템플릿) 등과 같이 공급자가 컨슈머에게 보내는 모든 데이터와 요청이 포함됩니다.
:ref:`dcr_provider_set_laf_dcr_refresh_schedule`을 호출하여 공급자에서 컨슈머로의 새로 고침 빈도로 변경할 수 있습니다.
데이터 |
기본 새로 고침 빈도 |
|---|---|
다음과 같은 공급자 클린룸 데이터:
|
|
컨슈머가 공급자에게 보내는 요청 및 데이터¶
다음 테이블은 컨슈머가 공급자에게 보내는 데이터 및 요청에 대한 기본 새로 고침 빈도를 보여줍니다.
각 클린룸에 대해 :doc:`컨슈머에서 공급자로의 새로 고침 빈도를 제어</collaboration/provider-listings-auto-fulfillment-update-refresh-frequency>`할 수 있습니다.
데이터 |
기본 새로 고침 빈도 |
|---|---|
다음과 같은 요청, 승인, 변경 사항:
|
|
공급자 활성화 데이터: |
|
리전 간 공동 작업과 관련된 비용¶
다른 리전에 있는 공동 작업자의 경우 추가 비용이 발생합니다. 이러한 비용이 발생하는 방식에 대한 자세한 내용은 자동 복제 비용 섹션을 참조하십시오.
리전 간 공동 작업에 대한 제한 사항¶
리전 간 협업에는 다음과 같은 제한이 있습니다.
클린룸 UI 사용 시 :ref:`동일한 UI 게이트웨이 리전<label-web_app_hosting>`에서 다른 UI 사용자와 리전 간 협업을 활성화할 수 있습니다. 예를 들어, AWS US 동부(오하이오)의 계정은 AWS US 서부(오리건)의 계정과 동일한 UI 게이트웨이 리전(AwS US 동부(북부 버지니아))에 있으므로 계정을 공유할 수 있습니다. AWS US 동부(오하이오)의 계정은 AWS 캐나다의 계정과 동일한 게이트웨이 리전을 공유하지 않으므로 계정을 공유할 수 없습니다. 그러나 API를 사용하는 경우 리전 간 협업을 위해 모든 계정을 구성할 수 있습니다.
공급자는 클린룸에서 차등 개인정보 보호를 사용할 수 없습니다.
공동 작업자는 클린룸의 외부 테이블과 Iceberg 테이블을 연결할 수 없습니다.
컨슈머는 여러 공급자에 대한 분석을 실행할 수 없습니다.
계정은 발생할 수 있는 복제 유형 충돌로 인해 클라우드 간 협업 시나리오에서 공급자와 컨슈머 역할을 모두 수행할 수는 없습니다.
리전 간 협업 활성화 시 추가 고려 사항 섹션을 참조하세요.