서비스 네트워킹

Snowpark Container Services 서비스를 사용할 때 고려해야 할 세 가지 유형의 네트워킹이 있습니다.

  • 수신 네트워킹: 외부에서 서비스로 연결하는 방법입니다.

  • 송신: 서비스가 인터넷 또는 비공개 링크를 통해 다른 서비스에 연결하는 방법입니다.

  • Snowpark Container Services의 서비스 간 커뮤니케이션

다음 섹션에서는 각 종류의 네트워킹을 구성하는 방법을 설명합니다.

네트워크 수신 구성하기

무엇이든 인터넷에서 서비스와 상호 작용할 수 있도록 하려면 서비스 사양 파일에서 서비스가 수신 대기하는 네트워크 포트를 엔드포인트로 선언합니다. 이러한 엔드포인트가 수신을 제어합니다.

기본적으로 서비스 엔드포인트는 비공개입니다. 서비스 함수서비스 간 통신 만 비공개 엔드포인트에 요청할 수 있습니다. 엔드포인트를 공개로 선언하여 인터넷에서 엔드포인트에 대한 요청을 허용할 수 있습니다. 공개 엔드포인트를 만드는 것은 권한이 있는 작업이며 서비스 소유자 역할은 계정에 대해 BIND SERVICE ENDPOINT 권한이 있어야 합니다.

endpoints:
- name: <endpoint name>
  port: <port number>
  protocol : < TCP / HTTP >
  public: true
  corsSettings:                  # optional CORS configuration
    Access-Control-Allow-Origin: # required list of allowed origins
      - <origin>                 # for example, "http://example.com"
      - <origin>
        ...
    Access-Control-Allow-Methods: # optional list of HTTP methods
      - <method>
      - <method>
        ...
    Access-Control-Allow-Headers: # optional list of HTTP headers
      - <header-name>
      - <header-name>
        ...
    Access-Control-Expose-Headers: # optional list of HTTP headers
      - <header-name>
      - <header-name>
        ...
Copy

예를 보려면 자습서 1 을 참조하십시오.

수신 연결 시간 제한

수신 엔드포인트의 시간 제한은 90초입니다. 90초 동안 수신 엔드포인트에 대한 연결에서 활동이 없으면 Snowflake는 연결을 종료합니다. 애플리케이션에 더 긴 연결 필요한 경우 폴링 또는 WebSockets를 사용합니다.

수신 웹 브라우저 인증 로그아웃

서비스로 실행되는 웹 앱을 구축하는 경우 사용자가 /sfc-endpoint/logout 으로 이동하여 앱에서 로그아웃할 수 있도록 하는 옵션이 있습니다.

로그아웃 후 사용자는 서비스의 공용 엔드포인트에 액세스하기 위해 Snowflake에 재인증해야 합니다.

수신 및 웹 앱 보안

공용 엔드포인트 지원(네트워크 수신)을 사용하여 웹 호스팅용 Snowpark Container Services 서비스를 만들 수 있습니다. 보안을 강화하기 위해 Snowflake는 프록시 서비스를 사용하여 클라이언트에서 서비스로 수신되는 요청과 서비스에서 클라이언트로 발신되는 응답을 모니터링합니다. 이 섹션에서는 프록시가 수행하는 작업과 Snowpark Container Services에 배포된 서비스에 미치는 영향을 설명합니다.

참고

로컬에서 서비스를 테스트하는 경우 Snowflake 프록시를 사용하지 않으므로 Snowpark Container Services에 배포할 때와 반대로 로컬에서 서비스를 실행하는 경험 간에 차이가 있습니다. 이 섹션을 검토하고 더 나은 테스트를 위해 로컬 설정을 업데이트하십시오.

예:

  • 요청이 금지된 HTTP 메서드를 사용하는 경우 프록시는 수신되는 HTTP 요청을 전달하지 않습니다.

  • 응답의 Content-Type 헤더가 응답에 실행 파일이 포함되어 있음을 나타내는 경우 프록시는 클라이언트에 403 응답을 보냅니다.

또한 프록시는 컨테이너 및 데이터 보안을 염두에 두고 새 헤더를 삽입하고 요청과 응답에서 기존 헤더를 변경할 수도 있습니다.

예를 들어 요청을 받으면 서비스는 응답으로 HTML, JavaScript, CSS 및 웹 페이지의 기타 콘텐츠를 클라이언트 브라우저에 보낼 수 있습니다. 브라우저의 웹 페이지는 서비스의 일부이며 사용자 인터페이스 역할을 합니다. 보안상의 이유로, 서비스에 제한 사항(예: 다른 사이트에 네트워크로 연결하는 데 대한 제한)이 있는 경우 서비스의 웹 페이지에도 동일한 제한 사항을 적용할 수도 있습니다.

기본적으로 서비스는 인터넷에 액세스할 수 있는 권한이 제한되어 있습니다. 또한 브라우저는 대부분의 경우 클라이언트 앱이 인터넷에 액세스하고 데이터를 공유할 수 없도록 제한해야 합니다. 서비스가 example.com (네트워크 송신 구성하기 참조)에 액세스할 수 있도록 EAI(External Access Integration)를 설정한 경우 서비스의 웹 페이지도 브라우저를 통해 example.com 에 액세스할 수도 있어야 합니다.

Snowflake 프록시는 응답에 Content-Security-Policy (CSP) 헤더를 추가하여 서비스와 웹 페이지에 동일한 네트워크 제한을 적용합니다. 기본적으로, 프록시는 일반적인 보안 위협으로부터 보호하기 위해 응답에 기준선 CSP를 추가합니다. 브라우저 보안은 기능과 보안의 균형을 맞추기 위해 최선의 노력으로 제공되며, 이 기준이 사용 사례에 적합한지 확인하는 것은 공동의 책임입니다. 또한 서비스가 EAI를 사용하도록 구성된 경우 프록시는 웹 페이지에 대해 EAI에서 CSP까지 동일한 네트워크 규칙을 적용합니다. 이 CSP를 사용하면 브라우저의 웹 페이지에서 서비스가 액세스할 수 있는 것과 동일한 사이트에 액세스할 수 있습니다.

Snowflake는 서비스 사양에서 구성하는 CORS 지원을 제공합니다.

Snowflake 프록시는 서비스 사양에 정의된 CORS 설정을 반환합니다. 프록시는 서비스에서 반환한 CORS 헤더를 모두 제거합니다.

다음 CORS 헤더는 기본적으로 설정되어 있습니다.

  • Access-Control-Expose-Headers 헤더는 엔드포인트에 대한 서비스 사양에 구성된 헤더 외에 항상 다음 헤더 이름을 보고합니다.

    • X-Frame-Options

    • Cross-Origin-Opener-Policy

    • Cross-Origin-Resource-Policy

    • X-Content-Type-Options

    • Cross-Origin-Embedder-Policy

    • Content-Security-Policy-Report-Only

    • Content-Security-Policy

  • Access-Control-Max-Age 는 2시간으로 설정되어 있습니다.

  • Access-Control-Allow-Credentials 가 true로 설정되어 있습니다.

또한 Snowflake는 Vary 헤더를 Origin 값으로 설정하여 Origin 의 값에 따라 Access-Control-Allow-Origin 의 값이 다를 수 있음을 브라우저에 알립니다.

CORS 요청을 만들려면 Authorization 헤더가 필요합니다. 이 헤더(Authorization: "Snowflake Token=\"${patToken}\"")에 프로그래밍 방식 액세스 토큰(PAT)을 지정합니다. 프로그래밍 방식 액세스 토큰을 생성하는 방법에 대한 자세한 내용은 인증을 위해 프로그래밍 방식의 액세스 토큰 사용 섹션을 참조하세요.

다음 섹션에서는 Snowflake 프록시가 서비스에 대한 수신되는 요청을 처리하고 서비스에서 클라이언트로 발신되는 응답을 수정하는 방법을 설명합니다.

서비스로 수신되는 요청

요청이 도착하면 프록시는 요청을 서비스에 전달하기 전에 다음을 수행합니다.

  • 금지된 HTTP 메서드가 포함된 수신 요청: 수신 HTTP 요청이 다음과 같은 금지된 HTTP 메서드 중 하나를 사용하는 경우 프록시는 해당 요청을 서비스로 전달하지 않습니다.

    • TRACE

    • CONNECT

  • 수신 요청 헤더 스크러빙: Snowflake 프록시는 다음 요청 헤더가 있는 경우 제거합니다.

    • X-SF-SPCS-Authorization

    • Authorization: Snowflake 토큰이 포함된 경우에만 제거되며, 그렇지 않으면 서비스로 전달됩니다.

고객에게 발신되는 응답

Snowflake 프록시는 응답을 클라이언트에 전달하기 전에 서비스에서 보낸 응답에 이러한 수정 사항을 적용합니다.

  • 헤더 스크러빙: Snowflake 프록시는 다음 응답 헤더가 있는 경우 제거합니다.

    • X-XSS-Protection

    • Server

    • X-Powered-By

    • Public-Key-Pins

  • CORS 헤더 조작: 수신 및 CORS 고려 사항 섹션을 참조하십시오.

  • Content-Type 응답 헤더: 서비스 응답에 (실행 파일을 나타내는) 다음 MIME 유형 값을 가진 Content-Type 헤더가 포함된 경우 Snowflake 프록시는 해당 응답을 클라이언트에 전달하지 않습니다. 대신 프록시는 403 Forbidden 응답을 보냅니다.

    • application/x-msdownload: Microsoft 실행 파일.

    • application/exe: 일반 실행 파일.

    • application/x-exe: 또 다른 일반 실행 파일.

    • application/dos-exe: DOS 실행 파일.

    • application/x-winexe: Windows 실행 파일.

    • application/msdos-windows: MS-DOS Windows 실행 파일.

    • application/x-msdos-program: MS-DOS 실행 파일.

    • application/x-sh: Unix 셸 스크립트.

    • application/x-bsh: Bourne 셸 스크립트.

    • application/x-csh: C 셸 스크립트.

    • application/x-tcsh: Tcsh 셸 스크립트.

    • application/batch: Windows 배치 파일.

  • X-Frame-Options 응답 헤더: 클릭재킹 공격을 방지하기 위해 Snowflake 프록시는 이 응답 헤더를 DENY 로 설정하여 다른 웹 페이지가 귀하의 서비스 웹 페이지에 iframe을 사용하지 못하게 합니다.

  • Cross-Origin-Opener-Policy(COOP) 응답 헤더: Snowflake는 교차 원본 윈도우를 참조해 서비스 탭에 액세스하지 못하게 하기 위해 COOP 응답 헤더를 same-origin 으로 설정합니다.

  • Cross-Origin-Resource-Policy(CORP) 응답 헤더: Snowflake는 외부 사이트가 수신 엔드포인트(예: iframe)에 의해 노출된 리소스를 로드하지 못하도록 CORP 헤더를 same-origin 으로 설정합니다.

  • X-Content-Type-Options 응답 헤더: Snowflake 프록시는 이 헤더를 nosniff 로 설정하여 클라이언트가 서비스의 응답에 명시된 MIME 유형을 변경하지 않도록 보장합니다.

  • Cross-Origin-Embedder-Policy(COEP) 응답 헤더: Snowflake 프록시는 COEP 응답 헤더를 credentialless 로 설정하는데, 이는 이미지나 스크립트와 같은 교차 원본 오브젝트를 로드할 때 원격 오브젝트가 Cross-Origin Resource Sharing(CORS) 프로토콜을 지원하지 않는 경우 Snowflake는 오브젝트를 로드할 때 자격 증명을 보내지 않습니다.

  • Content-Security-Policy-Report-Only 응답 헤더: Snowflake 프록시는 이 응답 헤더를 클라이언트가 Snowflake에 CSP 보고서를 보내도록 지시하는 새로운 값으로 바꿉니다.

  • Content-Security-Policy(CSP) 응답 헤더: 기본적으로 Snowflake 프록시는 일반적인 웹 공격으로부터 보호하기 위해 다음 기준선 CSP를 추가합니다.

    default-src 'self' 'unsafe-inline' 'unsafe-eval' blob: data:; object-src 'none'; connect-src 'self'; frame-ancestors 'self';
    
    Copy

    다음 두 가지 콘텐츠 보안 정책 고려 사항이 있습니다.

    • 프록시가 추가하는 기준선 콘텐츠 보안 정책 외에도 서비스 자체가 응답에 CSP를 명시적으로 추가할 수 있습니다. 서비스는 더 엄격한 CSP를 추가하여 보안을 강화하도록 선택할 수 있습니다. 예를 들어 서비스는 self 의 스크립트만 허용하도록 다음 CSP를 추가할 수 있습니다.

      script-src 'self'
      
      Copy

      클라이언트에 전송된 결과 응답에는 두 개의 CSP 헤더가 있습니다. 응답을 받으면 클라이언트 브라우저는 각 정책으로 지정된 추가 제한 사항을 포함하는 가장 엄격한 콘텐츠 보안 정책을 적용합니다.

    • 서비스가 외부 사이트(네트워크 송신 구성하기)에 액세스할 수 있도록 EAI(External Access Integration)를 구성할 경우 Snowflake 프록시는 웹 페이지가 해당 사이트에 액세스할 수 있도록 허용하는 CSP를 생성합니다. 예를 들어, EAI와 연결된 네트워크 규칙에서 example.com 에 대한 서비스 송신 액세스를 허용한다고 가정해 보겠습니다. 그런 다음 Snowflake 프록시가 이 CSP 응답 헤더를 추가합니다.

      default-src 'self' 'unsafe-inline' 'unsafe-eval' http://example.com https://example.com blob: data:; object-src 'none'; connect-src 'self' http://example.com https://example.com wss://example.com; frame-ancestors 'self';
      
      Copy

      브라우저는 응답으로 수신된 콘텐츠 액세스 정책을 준수합니다. 이 예에서 브라우저를 통해 앱이 example.com 에 액세스할 수 있지만 다른 사이트에는 액세스할 수 없습니다.

수신 및 CORS 고려 사항

기본적으로 브라우저는 한 서버에서 호스팅되는 웹 앱이 다른 호스트 이름을 가진 다른 서버로 요청을 보내는 것을 차단합니다. 예를 들어, Snowpark Container Services 내에 배포된 백엔드 서비스와 상호 작용해야 하는 웹 앱을 Snowpark Container Services 외부에서 호스팅하는 경우 이 제한이 적용됩니다.

CORS (교차 출처 리소스 공유)를 사용하면 Snowpark Container Services 서비스가 브라우저에 해당 환경 외부에서 호스팅되는 웹 앱의 요청을 허용하도록 지시할 수 있습니다. 각 공용 엔드포인트가 CORS 사전 비행 요청과 표준 요청에 모두 응답하는 방식을 지정하도록 구성할 수 있습니다.

Snowflake 프록시는 항상 다음 응답 헤더를 재정의합니다.

  • Access-Control-Allow-Origin

  • Access-Control-Allow-Methods

  • Access-Control-Allow-Headers

  • Access-Control-Expose-Headers

  • Access-Control-Max-Age

  • Access-Control-Allow-Credentials

다음 중 하나에 해당하는 경우 Snowflake 프록시는 응답에 이러한 CORS 헤더를 포함하지 않습니다.

  • CORS 가서비스 엔드포인트에 대해 구성되어 있지 않음. 즉, 서비스 사양에 corsSettings 가 없음.

  • CORS 가 서비스 엔드포인트에 대해 구성되어 있지만 요청의 Origin 헤더가 서비스 사양에 지정된 Access-Control-Allow-Origin 필드와 일치하지 않음.

서비스 사양에서 각 공개 엔드포인트에 대해 CORS 설정을 구성할 수 있습니다. 요청의 origin 헤더가 사양의 엔드포인트에 지정된 Access-Control-Allow-Origin 필드와 일치하는 경우 프록시는 사양에 정의된 CORS 헤더를 응답에 포함하며 다음과 같이 조정합니다.

  • Access-Control-Allow-Origin: 요청에서 Origin 헤더를 반환합니다.

  • Access-Control-Expose-Headers: 구성한 허용 헤더 목록을 항상 노출되는 X-Frame-Options, Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy, X-Content-Type-Options, Cross-Origin-Embedder-Policy, Content-Security-Policy-Report-Only, Content-Security-Policy 헤더와 병합합니다.

  • Access-Control-Max-Age: 2시간으로 설정됩니다.

  • Access-Control-Allow-Credentials: True로 설정됩니다.

수신 및 SSO 고려 사항

인터넷에서 공용 엔드포인트에 액세스할 때 사용자 이름/비밀번호 인증은 작동하지만 SSO 페이지가 빈 페이지로 표시되거나 “OAuth client integration with the given client ID is not found.” 오류가 발생할 수 있습니다.

이는 페더레이션 인증을 사용하도록 Snowflake 구성하기 에 설명된 대로 최신 보안 통합 버전 대신 이전 스타일의 연합 인증(SSO)을 사용하는 경우 발생합니다. 확인하려면 다음을 수행합니다.

  1. 다음 쿼리를 실행합니다.

    SHOW PARAMETERS LIKE 'SAML_IDENTITY_PROVIDER' IN ACCOUNT;
    
    Copy

    이 매개 변수가 설정되어 있다면 어느 시점에서 이전 스타일의 연합 인증을 사용 중이었다는 뜻입니다.

  2. 앞의 매개 변수가 설정된 경우 다음 쿼리를 실행하여 SAML 보안 통합이 있는지 확인합니다.

    SHOW INTEGRATIONS
      ->> SELECT * FROM $1 WHERE "type" = 'SAML2';
    
    Copy

    SAML2 유형의 통합 인증이 없는 경우 이전 스타일의 연합 인증을 사용하고 있는 것입니다.

이 경우 해결 방법은 기존 방식의 연합 인증에서 새로운 통합 방식의 연합 인증으로 마이그레이션하는 것입니다. 자세한 내용은 SAML2 보안 통합으로 마이그레이션하기 섹션을 참조하십시오.

네트워크 송신 구성하기

애플리케이션 코드에는 인터넷 액세스 권한이 필요할 수 있습니다. 기본적으로 애플리케이션 컨테이너에는 인터넷에 액세스할 권한이 없습니다. EAI(External Access Integration) 를 사용하여 인터넷 액세스를 활성화해야 합니다.

일반적으로, 서비스(작업 서비스 포함)에서 허용되는 외부 액세스를 관리하려면 계정 관리자가 EAIs를 생성해야 합니다. 그러면 계정 관리자는 개발자가 서비스를 실행하는 데 사용하는 특정 역할에 EAI 사용 권한을 부여할 수 있습니다.

다음 예에서는 네트워크 규칙을 사용하여 지정된 특정 대상으로의 송신 트래픽을 허용하는 EAI를 생성하는 단계를 간략하게 설명합니다. 그런 다음 서비스를 생성할 때 EAI를 참조하여 특정 인터넷 대상에 대한 요청을 허용합니다.

애플리케이션 코드가 다음 대상으로 요청을 보내도록 하는 경우를 가정해 보겠습니다.

  • translation.googleapis.com에 대한 HTTPS 요청

  • google.com에 대한 HTTP 및 HTTPS 요청

서비스가 인터넷에서 이러한 도메인에 액세스할 수 있도록 하려면 다음 단계를 따르십시오.

  1. EAI(External Access Integration) 만들기 이를 위해서는 적절한 권한이 필요합니다. 예를 들어, ACCOUNTADMIN 역할을 사용하여 EAI를 생성할 수 있습니다. 이는 다음과 같은 2단계 프로세스입니다.

    1. CREATE NETWORK RULE 명령을 사용하여 액세스를 허용하려는 외부 대상을 나열하는 하나 이상의 송신 네트워크 규칙을 만듭니다. 하나의 네트워크 규칙으로 이 예를 수행할 수 있지만, 설명을 위해 다음 두 네트워크 규칙을 만듭니다.

      1. translate_network_rule 이라는 네트워크 규칙을 만듭니다.

        CREATE OR REPLACE NETWORK RULE translate_network_rule
          MODE = EGRESS
          TYPE = HOST_PORT
          VALUE_LIST = ('translation.googleapis.com');
        
        Copy

        이 규칙을 사용해 translation.googleapis.com 대상에 대한 TCP 연결을 허용합니다. VALUE_LIST 속성의 도메인은 선택적 포트 번호를 지정하지 않으므로 기본 포트 443(HTTPS)을 허용합니다. 이를 통해 애플리케이션이 https://translation.googleapis.com/ 으로 시작하는 모든 URL에 연결할 수 있습니다.

      2. google_network_rule 이라는 네트워크 규칙을 만듭니다.

        CREATE OR REPLACE NETWORK RULE google_network_rule
          MODE = EGRESS
          TYPE = HOST_PORT
          VALUE_LIST = ('google.com:80', 'google.com:443');
        
        Copy

        이를 통해 애플리케이션이 http://google.com/ 또는 https://google.com/ 으로 시작하는 모든 URL에 연결할 수 있습니다.

      참고

      VALUE_LIST 매개 변수의 경우 전체 호스트 이름을 제공해야 합니다. 와일드카드(예: *.googleapis.com)는 지원되지 않습니다.

      Snowpark Container Services는 포트 22, 80, 443, 1024 이상을 허용하는 네트워크 규칙만 지원합니다. 참조된 네트워크 규칙이 다른 포트에 대한 액세스를 허용하는 경우 서비스 생성이 실패합니다. 추가 포트를 사용해야 하는 경우 계정 담당자에게 문의하십시오.

      참고

      서비스가 인터넷의 어떤 대상으로든 HTTP 또는 HTTPS 요청을 보내도록 허용하려면 VALUE_LIST 속성에서 “0.0.0.0”을 도메인으로 지정합니다. 다음 네트워크 규칙을 사용하면 인터넷의 어디에서나 “HTTP” 및 “HTTPS” 요청을 모두 보낼 수 있습니다. “0.0.0.0”에서는 포트 80 또는 443만 지원됩니다.

      CREATE NETWORK RULE allow_all_rule
        TYPE = 'HOST_PORT'
        MODE= 'EGRESS'
        VALUE_LIST = ('0.0.0.0:443','0.0.0.0:80');
      
      Copy
    2. 이전의 두 송신 네트워크 규칙이 허용되도록 지정하는 EAI(외부 액세스 통합)를 생성합니다.

      CREATE EXTERNAL ACCESS INTEGRATION google_apis_access_integration
        ALLOWED_NETWORK_RULES = (translate_network_rule, google_network_rule)
        ENABLED = true;
      
      Copy

      이제 계정 관리자는 개발자가 인터넷의 특정 대상에 액세스할 수 있는 서비스를 실행할 수 있도록 통합 사용 권한을 부여할 수 있습니다.

      GRANT USAGE ON INTEGRATION google_apis_access_integration TO ROLE test_role;
      
      Copy
  2. 다음 예제와 같이 EAI를 제공하여 서비스를 만듭니다. 서비스를 생성하는 소유자 역할에는 EAI에 대한 USAGE 권한과 참조된 시크릿에 대한 READ 권한이 필요합니다. ACCOUNTADMIN 역할은 서비스를 생성하기 위한 용도로 사용할 수 없습니다.

    • 다음과 같이 서비스를 만듭니다.

      USE ROLE test_role;
      
      CREATE SERVICE eai_service
        IN COMPUTE POOL MYPOOL
        EXTERNAL_ACCESS_INTEGRATIONS = (GOOGLE_APIS_ACCESS_INTEGRATION)
        FROM SPECIFICATION
        $$
        spec:
          containers:
            - name: main
              image: /db/data_schema/tutorial_repository/my_echo_service_image:tutorial
              env:
                TEST_FILE_STAGE: source_stage/test_file
              args:
                - read_secret.py
          endpoints:
            - name: read
              port: 8080
        $$;
      
      Copy

      이 예시 CREATE SERVICE 요청은 인라인 서비스 사양을 사용하고 EAI를 포함하도록 선택적 EXTERNAL_ACCESS_INTEGRATIONS 속성을 지정합니다. EAI는 서비스에서 특정 대상으로의 송신 트래픽을 허용하는 네트워크 규칙을 지정합니다.

    • 작업 서비스 실행:

      EXECUTE JOB SERVICE
        IN COMPUTE POOL tt_cp
        NAME = example_job_service
        EXTERNAL_ACCESS_INTEGRATIONS = (GOOGLE_APIS_ACCESS_INTEGRATION)
        FROM SPECIFICATION $$
        spec:
          container:
          - name: curl
            image: /tutorial_db/data_schema/tutorial_repo/alpine-curl:latest
            command:
            - "curl"
            - "http://google.com/"
        $$;
      
      Copy

      이 예시 EXECUTE JOB SERVICE 명령은 인라인 사양과 EAI를 포함하도록 선택적 EXTERNAL_ACCESS_INTEGRATIONS 속성을 지정합니다. 이렇게 하면 작업에서 EAI가 허용하는 네트워크 규칙에 지정된 대상으로의 송신 트래픽이 허용됩니다.

비공개 연결을 사용한 네트워크 송신

공용 인터넷을 통해 네트워크 송신을 라우팅하는 대신 비공개 연결 엔드포인트 를 통해 서비스 송신 트래픽을 전송하도록 선택할 수 있습니다.

먼저 Snowflake 계정에서 비공개 연결 엔드포인트를 만들어야 합니다. 그런 다음 나가는 트래픽이 비공개 연결 을 사용하도록 허용하는 네트워크 규칙을 구성합니다. 외부 액세스 통합(EAI)을 설정하는 프로세스는 이전 섹션에서 설명한 것과 동일합니다.

참고

비공개 통신을 사용하려면 Snowflake와 고객의 클라우드 계정이 모두 동일한 클라우드 공급자와 동일한 리전을 사용해야 합니다.

예를 들어 비공개 연결을 통해 서비스의 아웃바운드 인터넷 액세스를 Amazon S3 버킷으로 사용 설정하려면 다음과 같이 하십시오.

  1. 자체 유지 관리되는 엔드포인트 서비스(Amazon S3)에 대해 비공개 링크 연결을 사용 설정합니다. 단계별 지침은 AWS Private Link for Amazon S3 섹션을 참조하십시오.

  2. SYSTEM$PROVISION_PRIVATELINK_ENDPOINT 시스템 함수를 호출하여 Snowflake VNet 에서 비공개 연결 엔드포인트를 프로비저닝하십시오. 이를 통해 Snowflake는 비공개 연결을 사용하여 외부 서비스(이 예에서는 Amazon S3)에 연결할 수 있습니다.

    USE ROLE ACCOUNTADMIN;
    
    SELECT SYSTEM$PROVISION_PRIVATELINK_ENDPOINT(
      'com.amazonaws.us-west-2.s3',
      '*.s3.us-west-2.amazonaws.com'
    );
    
    Copy
  3. 클라우드 공급자 계정에서 엔드포인트를 승인합니다. 이 예에서는 Amazon AWS 의 경우 AWS 설명서의 연결 요청 수락 또는 거부 섹션을 참조하십시오. 또한 Azure에서 엔드포인트를 승인하려면 Azure 설명서 를 참조하십시오.

  4. CREATE NETWORK RULE 명령을 사용하여 액세스를 허용할 외부 대상을 지정하는 송신 네트워크 규칙을 만들 수 있습니다.

    CREATE OR REPLACE NETWORK RULE private_link_network_rule
      MODE = EGRESS
      TYPE = PRIVATE_HOST_PORT
      VALUE_LIST = ('<bucket-name>.s3.us-west-2.amazonaws.com');
    
    Copy

    TYPE 매개 변수 값은 PRIVATE_HOST_PORT 로 설정됩니다. 네트워크 규칙에 따라 발신 네트워크 트래픽이 비공개 연결 을 사용할 수 있음을 나타냅니다.

  5. EAI 를 생성하고 이를 사용하여 서비스를 만드는 나머지 단계는 이전 섹션에서 설명한 것과 동일합니다(네트워크 송신 구성하기 참조).

비공개 연결 엔드포인트 작업에 대한 자세한 내용은 다음을 참조하십시오.

컨테이너 간 네트워크 통신 구성하기

다음 두 가지 고려 사항이 있습니다.

  • 서비스 인스턴스의 컨테이너 간 통신: 서비스 인스턴스가 여러 컨테이너를 실행하는 경우 이러한 컨테이너는 localhost를 통해 서로 통신할 수 있습니다(서비스 사양에서 엔드포인트를 정의할 필요가 없음).

  • 여러 서비스 또는 여러 서비스 인스턴스에 걸친 컨테이너 간 통신: 서로 다른 서비스(또는 동일한 서비스의 다른 인스턴스)에 속한 컨테이너는 사양 파일에 정의된 엔드포인트를 사용하여 통신할 수 있습니다. 자세한 내용은 서비스 간 통신 섹션을 참조하십시오.