Dynamic Endpoint Transfer

File Transfer

목적지가 계속 바뀌어도 필요한 Endpoint로 파일을 연결합니다.

기존 파일 전송은 보통 Server A → Server B처럼 고정된 Source와 Target을 전제로 합니다. 하지만 Cloud, Kubernetes, AI Compute, Edge와 분산 Infrastructure에서는 실제 작업을 수행할 Server, VM, Pod, GPU Compute와 Device가 필요할 때 생성되고 선택되며 다시 사라질 수 있습니다.

File Transfer

Endpoint의 역할, 조건과 Group을 이용해 변화하는 Infrastructure를 구성합니다.

Dynamic Endpoint는 단순한 IP 목록이 아닙니다. 실제 Infrastructure가 관리하는 Role, Environment, Region, Workload, Project와 Status 같은 정보를 Transfer 관계에 연결하면 특정 장비 이름보다 업무에서 필요한 Endpoint의 조건을 중심으로 Data Movement를 구성할 수 있습니다.

같은 역할을 수행하는 Compute와 Device가 여러 개 존재하는 경우에는 이를 Endpoint Group으로 묶을 수 있습니다. GPU Pool, Compute Pool, Kubernetes Workloads, Edge Fleet와 Temporary Compute처럼 Infrastructure의 실제 목록이 추가되거나 변경되더라도 Transfer Logic은 Group과 Condition을 중심으로 유지됩니다. 이를 통해 Endpoint의 실제 구성과 업무의 Data Movement 관계를 분리하면서 실행 시점에는 하나의 Transfer로 연결할 수 있습니다.

File Transfer

Workload와 Endpoint Lifecycle에서 Data가 필요한 지점을 연결합니다.

Compute가 자동으로 생성되고 Workload가 배치되어도 실제 작업에 필요한 Dataset과 File은 해당 Endpoint까지 이동해야 합니다. Cloud와 AI Infrastructure에서는 Compute가 영구적인 Server가 아니라 작업을 위해 잠시 생성되는 GPU, VM 또는 Pod일 수 있으므로 Endpoint Lifecycle과 Transfer Lifecycle의 Timing을 함께 연결하는 것이 중요합니다.

기존 Infrastructure가 Endpoint를 생성하고 Ready 상태를 판단하면 INNORIX가 필요한 Data를 전달하고, 기존 Workload가 Processing이나 Training을 수행한 뒤 Result와 Checkpoint를 다시 Persistent Storage로 수집할 수 있습니다. INNORIX가 Endpoint를 생성하거나 종료하는 것이 아니라 Lifecycle에서 Data가 필요한 시점에 Transfer를 실행하고 완료 결과를 반환합니다.

File Transfer

Endpoint 수가 증가해도 Transfer Logic은 역할과 조건을 중심으로 유지합니다.

고정 Target 방식에서는 새로운 Server나 Device가 추가될 때 Source → Server A, Source → Server B와 같은 Transfer Configuration도 함께 증가할 수 있습니다. Dynamic Endpoint Model에서는 실제 Endpoint 목록과 업무의 Transfer Logic을 분리하고, Source가 어떤 역할과 조건을 가진 Endpoint로 데이터를 보내야 하는지를 중심으로 관계를 구성합니다.

따라서 Endpoint Group에 새로운 Compute나 Device가 추가되거나 기존 Endpoint가 교체되어도 같은 Transfer Logic을 재사용할 수 있습니다. 준비된 Endpoint로 Transfer를 시작하고 아직 사용할 수 없는 Endpoint는 상태에 따라 기다리며, Transfer 도중 문제가 발생하면 Resume과 Recovery를 적용해 Infrastructure 규모와 상태가 변화해도 최종 Data Delivery까지 같은 관계를 유지합니다.

File Transfer

Cloud, Kubernetes, AI와 Edge를 하나의 Endpoint Model로 연결합니다.

Dynamic Endpoint는 특정 Infrastructure 하나에만 적용되는 개념이 아닙니다. Cloud에서는 VM과 Compute Instance, Kubernetes에서는 Pod, Node, Workload Endpoint, AI에서는 GPU와 Training, Inference Compute, Edge에서는 Gateway, Factory, Branch Device가 실제 Transfer Endpoint가 될 수 있습니다.

Workload가 Region과 Environment에 따라 서로 다른 곳에서 실행되는 Multi-Region 환경에서도 Transfer Logic을 특정 Region의 Server 하나에 고정하기보다 기존 Infrastructure가 선택한 Endpoint와 Data Path를 연결할 수 있습니다. 실제 Infrastructure의 종류가 달라도 Endpoint → Condition → Transfer → Result라는 동일한 Data Movement Model을 적용합니다.

File Transfer

AI Data Delivery와 Dynamic Endpoint Transfer는 Data와 Infrastructure의 변화를 각각 담당합니다.

두 상품은 밀접하게 연결되지만 중심 질문이 다릅니다. AI Data Delivery는 Dataset, Model, Checkpoint와 Result처럼 무엇을 전달해야 하는가에 집중하고, Dynamic Endpoint Transfer는 GPU, Compute, Server와 Device처럼 현재 어디로 전달해야 하는가를 연결합니다.

예를 들어 AI Training에서는 AI Data Delivery가 Dataset과 Model Weight의 실제 File Movement를 담당하고, Dynamic Endpoint Transfer는 Scheduler가 선택한 GPU나 Temporary Compute를 현재 Transfer Target으로 연결합니다. Workload가 끝난 뒤에는 Checkpoint와 Result를 Persistent Storage로 다시 수집할 수 있어 Data Lifecycle과 Endpoint Lifecycle이 변화하더라도 두 역할을 겹치지 않고 하나의 Data Movement로 연결할 수 있습니다.

File Transfer

Infrastructure가 변할 때마다 Data Movement도 함께 따라갑니다.

GPU Compute가 매번 달라지고, Kubernetes Workload가 새로운 Endpoint에서 실행되고, Edge Device가 서로 다른 시점에 연결되어도 Transfer Logic을 특정 Server 하나에 고정할 필요가 없습니다.

기존 Infrastructure와 Orchestrator가 어디에서 작업할지 결정하면 INNORIX는 그 Endpoint까지 필요한 파일을 전달하고, Workload 이후의 Result를 다시 필요한 Storage와 System으로 연결합니다.