데이터 연결의 실행 위치와 네트워크 구조

데이터 연결을 설계할 때는 연결 기능의 연산을 어디서 수행할지와 외부 시스템까지 어떤 통신 경로를 사용할지를 구분합니다. Foundry 워커(Foundry worker)는 연산을 Foundry에서 실행합니다. 직접 연결 정책과 에이전트 프록시 정책은 그 연산이 외부 시스템에 도달하는 서로 다른 경로입니다.

Foundry 워커와 직접 연결 정책

외부 시스템이 Foundry에서 들어오는 연결을 받을 수 있다면 직접 연결 정책을 사용하는 Foundry 워커가 기본 권장 구성입니다. 인터넷에서 접근할 수 있는 REST API, 클라우드 서비스와 SaaS가 대표적인 대상입니다.

연결 기능은 격리된 컴퓨팅 컨테이너에서 실행됩니다. 이 컨테이너가 인증과 암호화된 네트워크 요청을 처리하며, 외부 시스템은 Foundry에서 시작한 요청을 받아들여야 합니다.

Foundry의 외부 통신은 플랫폼 안에서 직접 연결 외부 통신 정책으로 관리합니다. 외부 시스템의 인증 정보는 서버 측 AES-256-GCM 방식으로 암호화하여 저장하고, 권한 있는 사용자가 시작한 컨테이너만 이를 복호화할 수 있습니다.

Foundry 워커와 에이전트 프록시 정책

별도의 사설 네트워크에 있는 외부 시스템에 접근하려면 Data Connection 에이전트를 사용하는 에이전트 프록시 정책이 권장됩니다. 이 방식은 agent proxy 또는 agent thin mode라고도 부릅니다.

에이전트가 조직 네트워크 안에서 Foundry로 요청을 시작하여 WebSocket 연결을 만듭니다. 에이전트는 네트워크 터널 역할만 하며 데이터 처리 연산을 수행하지 않습니다.

모든 연결 기능의 연산은 확장 가능한 자원을 가진 Foundry의 격리 컨테이너에서 실행합니다. 컨테이너는 에이전트가 제공하는 WebSocket 경로를 통해 외부 시스템과 통신합니다. 에이전트 호스트에서도 대상 시스템에 접근할 수 있도록 네트워크를 구성해야 합니다.

어떤 연결이 에이전트를 프록시로 사용할 수 있는지는 플랫폼의 에이전트 프록시 외부 통신 정책으로 세밀하게 관리합니다. 여러 에이전트를 사용하여 여러 외부 시스템에 대한 작업 부하를 분산할 수 있습니다.

인증 정보의 저장과 복호화 방식은 직접 연결과 같습니다. 서버 측 AES-256-GCM 암호화를 사용하며 권한 있는 사용자가 시작한 컨테이너에서 복호화합니다.

구성 순서는 에이전트 준비, 하나 이상의 에이전트 프록시 정책 생성, 해당 정책을 사용하는 Foundry 워커 소스 생성입니다. 에이전트 프록시 정책은 Rubix 기반 Foundry 플랫폼 인스턴스에서 사용할 수 있습니다.

기존 기능 유지 단계의 에이전트 워커

에이전트 워커(Agent worker)는 조직이 관리하는 호스트에서 연결 기능의 연산까지 실행하는 방식이며 agent thick mode라고도 부릅니다. 기존 기능 유지 단계(Legacy)에 있으므로 사내 시스템이나 사설 네트워크의 새 연결에는 Foundry 워커와 에이전트 프록시가 권장됩니다.

에이전트는 HTTPS로 보호되는 외부 방향 연결을 사용하여 Foundry에 실행할 작업이 있는지 계속 조회합니다. 작업을 받으면 에이전트 호스트에서 실행하고 같은 연결 경로로 결과를 Foundry에 보냅니다.

원천 시스템에 접근할 방화벽과 프록시 등 네트워크 구성은 에이전트 호스트에서 직접 관리합니다. 조직 네트워크 안의 원천 시스템 입장에서는 에이전트가 연결을 시작합니다.

이 방식에서는 외부 시스템의 인증 정보를 플랫폼에 AES-128-GCM으로 암호화하여 저장하고, 암호화 키는 에이전트에 둡니다. 실행 시 에이전트가 암호화된 인증 정보를 가져와 로컬에서 복호화한 뒤 쿼리에 사용합니다. 복호화한 인증 정보는 실행 후 메모리에서 자동으로 삭제합니다.

기존 방식으로 구성하려면 에이전트를 설치하고 에이전트 워커로 설정한 뒤, 에이전트 워커 소스에 해당 에이전트를 지정합니다. 기존 연결을 옮기는 절차와 두 방식의 운영 차이는 Foundry 워커와 에이전트 워커에서 설명합니다.