파일 전송
서로 다른 Cloud와 On-Prem Object Storage를 하나의 Transfer Layer로 연결하는 INNORIX 솔루션을 소개합니다.
CROSS-STORAGE TRANSFER LAYER
Object Storage는 이제 Backup을 위한 저장소만이 아니라 Data Lake, AI Dataset, Media Asset, Research Data와 Machine Data가 모이는 핵심 Data Infrastructure입니다.
하지만 Storage가 여러 Cloud, Region, Account, Private Cloud와 On-Prem으로 확장되면 데이터 이동 방식도 함께 늘어납니다. INNORIX 객체 스토리지 간 전송은 특정 Storage 제품의 내부 복사 기능이 아니라, 서로 다른 Object Storage 사이의 Data Movement를 하나의 Transfer Layer로 연결합니다.
여러 Storage → INNORIX
INNORIX → 전달 대상
SOURCE & TARGET
하나의 Cloud 안에서 Bucket을 복제하는 것과 서로 다른 Storage Infrastructure를 연결하는 것은 다른 문제입니다.
Object Storage가 다양해질수록 Endpoint, Authentication, Region, Namespace와 API Compatibility까지 실제 Source와 Target 조합에서 확인해야 할 조건이 늘어납니다.
INNORIX는 Storage의 소유자가 아니라 데이터가 현재 어디에 있고 어디로 가야 하는가를 Transfer의 기준으로 사용합니다.
S3 API & REAL COMBINATIONS
S3 API는 Object Storage 생태계의 중요한 Interface가 되었고 다양한 Storage가 S3-Compatible Interface를 제공합니다.
하지만 'S3-Compatible'이라는 하나의 표현이 모든 구현과 동작이 완전히 같다는 의미는 아닙니다. 실제 연결에서는 여러 조건이 함께 작동합니다.
따라서 Object Storage Transfer에서는 단순히 "S3 API를 지원하는가?"보다 실제 운영하려는 Source × Target 조합과 방향성이 중요합니다.
확인이 필요한 실제 연결 조건
지원 범위는 Storage Logo의 수보다 어떤 Source에서 어떤 Target으로 실제 Data Movement를 구성할 수 있는가를 기준으로 확인합니다.
NATIVE VS. CROSS-STORAGE
하나의 Storage Ecosystem 안에서 제공되는 Replication과 Migration 기능은 해당 환경을 운영하는 데 중요한 역할을 합니다.
INNORIX는 이러한 Native Storage 기능을 대체하기보다 Storage의 경계를 넘어가는 Data Movement를 담당합니다.
Native 기능이 Storage 내부를 연결한다면, INNORIX는 서로 다른 Storage 사이의 Transfer 관계를 연결합니다.
OBJECT-TO-OBJECT DATA PATH
서로 다른 Object Storage 사이에서 데이터를 이동할 때 Local System이나 Temporary Storage를 이용한 Download와 Re-upload 방식이 사용될 수 있습니다.
Download / Re-upload
INNORIX Platform — Control Plane
INNORIX는 가능한 Transfer Path에서 Source와 Target 사이의 Data Movement를 구성합니다.
Control과 Monitoring은 Platform에서 관리하고, Data는 필요한 Source와 Target 사이에서 이동하도록 구성합니다.
Direct Data Movement, Transfer Recovery와 Result Management를 하나의 구조에서 운영합니다.
MULTI-CLOUD
Cloud가 하나일 때는 해당 Cloud의 Native Tool만으로 충분할 수 있습니다. Infrastructure가 확장되면 필요한 관계가 달라집니다.
Cloud A →
Cloud B에서도 Cloud A / Private / On-Prem으로 동일하게 확장됩니다. 각 조합마다 별도의 Copy Tool과 운영 방식을 추가하는 대신 Source, Target, Transfer, Run이라는 동일한 Model로 구성할 수 있습니다.
새로운 Cloud나 Storage가 추가되면 새로운 Transfer System을 구축하는 것보다 새로운 Endpoint를 기존 Data Movement에 연결하는 구조로 확장합니다.
TRANSFER DIRECTION
Object Storage 제품이나 Transfer Service의 "지원" 여부를 확인할 때는 Source와 Target을 구분하는 것이 중요합니다.
외부 S3-Compatible Storage를 Source로 사용할 수 있다고 해서 같은 Storage가 Target으로도 동일하게 동작한다는 의미는 아닐 수 있습니다.
따라서 INNORIX에서는 Storage 지원을 단순한 Logo 목록보다 실제 Transfer Direction으로 다룹니다.
실제 제품 페이지에는 검증된 Storage와 Direction만 표시합니다.
STORAGE RELATIONSHIPS
Object Storage Transfer는 하나의 Bucket에서 다른 Bucket으로 Copy하는 기능에서 시작할 수 있지만 실제 Enterprise 환경에서는 더 다양한 관계가 필요합니다.
동일한 Transfer Model을 사용하면서 Source와 Target만 업무에 맞게 구성할 수 있습니다.
MIGRATION TO CONTINUOUS
Object Storage 사이의 이동은 일회성 Migration으로 시작될 수도 있고 지속적인 Data Pipeline이 될 수도 있습니다.
예를 들어 처음에는 On-Prem Object Storage의 Dataset을 Cloud로 Migration하고, 이후 같은 관계를 매일 생성되는 데이터의 Delivery Path로 사용할 수 있습니다.
Migration을 위해 만든 Transfer를 지속적인 Data Movement로 확장할 수 있습니다.
LARGE OBJECTS
Object Storage에는 수 GB에서 TB급까지 커지는 Dataset, Media File, Archive와 Model Artifact가 저장될 수 있습니다.
파일이 커질수록 Transfer 중단 이후 전체 Object를 다시 처리하는 비용도 커집니다.
Source
Target
INNORIX의 Large File Transfer 기능을 Object Storage 사이의 Data Movement에 적용해 Parallel Transfer, Resume, Recovery와 Transfer Result를 함께 운영합니다.
MANY OBJECTS, ONE TRANSFER
AI Dataset, Image Archive, Research Data와 Machine Data는 하나의 큰 Object보다 수백만 개의 작은 Object로 구성되는 경우도 많습니다.
이때 실제 작업은 Data Transfer만이 아닙니다.
Object 수가 증가할수록 Listing, Filtering, Queue, Concurrent Transfer와 File-Level Result가 전체 처리 시간과 운영 복잡도에 영향을 줍니다.
INNORIX는 High-Volume Transfer 기능을 적용해 대량 Object의 탐색부터 Transfer와 결과까지 하나의 실행 단위로 관리합니다.
TRANSFER CAPACITY
처리량을 높이기 위해 무조건 많은 Transfer를 동시에 실행하는 것이 항상 최적의 결과를 만드는 것은 아닙니다.
Source Storage의 API 처리 능력, Target Storage, Network와 다른 Workload를 함께 고려해야 합니다.
Transfer Infrastructure 자체를 계속 확장하는 것보다 현재 Source와 Target에서 사용할 수 있는 Capacity를 효율적으로 활용하는 방향으로 운영합니다.
OBJECT INTEGRITY
S3-Compatible API를 사용한다는 사실과 실제 데이터의 무결성 확인은 별개의 문제입니다.
특히 Multipart Upload와 Storage별 구현 차이 때문에 Object의 ETag를 모든 환경에서 단순한 파일 MD5로 해석할 수는 없습니다.
운영자는 단순히 API Request가 성공했는지가 아니라 어떤 Object가 전달되었고, 어떤 Object에 추가 처리가 필요한지를 확인할 수 있습니다.
RECOVERY BY SCOPE
수백만 개의 Object 중 일부에서 문제가 발생했을 때 전체 Transfer를 다시 실행하는 것보다 실제 실패 범위를 식별하는 것이 중요합니다.
Transfer State와 Object별 Result를 유지하고 필요한 범위만 다시 처리함으로써 대용량·대량 Storage Transfer의 Recovery 비용을 줄입니다.
DATA PLANE / CONTROL PLANE
Object Storage가 여러 Cloud와 Data Center에 분산되어 있어도 Transfer Operation은 하나의 Platform에서 관리할 수 있습니다.
INNORIX Platform — Control / Flow / Monitoring
Data Movement
Data Plane은 필요한 Storage 사이에서 움직이고, Control Plane에서는 Transfer Configuration, Automation, Run과 Result를 통합해 관리합니다.
Storage가 추가되어도 같은 운영 모델을 적용할 수 있습니다.
STORAGE & FLOW
업무의 목적은 Storage 제품보다 오래 유지되는 경우가 많습니다.
예를 들어 매일 생성된 Dataset을 Processing Environment로 전달하는 업무가 있을 때 실제 Storage는 Infrastructure 변화에 따라 달라질 수 있습니다.
Business Flow
Infrastructure
Flow와 실제 Storage Endpoint를 분리하면 Storage를 변경하거나 새로운 Target을 추가할 때 업무 전체의 Transfer Logic을 다시 만드는 범위를 줄일 수 있습니다.
EXPANDING SCALE
Object Storage 환경은 하나의 Cloud에서 Multi-Cloud, Private Cloud, On-Prem과 Sovereign Environment로 확장될 수 있습니다.
INNORIX에서는 새로운 Storage를 별개의 Transfer System으로 운영하기보다 Source 또는 Target Endpoint로 기존 Transfer Layer에 연결합니다.
Infrastructure가 확장되어도 Transfer Configuration, Monitoring과 Result를 같은 방식으로 유지할 수 있습니다.
AFTER MIGRATION
Object Storage Migration은 새로운 Storage로 데이터를 한 번 옮기는 것으로 끝날 수도 있지만, 실제 업무에서는 Migration 이후에도 Data Movement가 계속 발생합니다.
Migration에서 사용한 Transfer Layer를 이후의 Distribution, Processing, Archive와 AI Data Delivery에도 계속 사용할 수 있습니다.
STORAGE TO COMPUTE
Object Storage에 저장되는 데이터는 최종 목적지가 Storage인 경우만 있는 것은 아닙니다.
AI Dataset은 GPU Compute로, Media Asset은 Processing Server로, Machine Data는 Analytics Environment로 전달되어야 합니다.
Object Storage
Object Storage Transfer는 단순한 Storage-to-Storage Copy에서 Storage-to-Compute Data Delivery로 확장됩니다.
Object Storage에 데이터가 쌓이는 것과 실제 Workload가 그 데이터를 사용할 수 있게 만드는 과정을 같은 Transfer Layer에서 연결합니다.
AI DATA DELIVERY
Object Storage는 AI Infrastructure의 주요 Dataset Repository 중 하나입니다.
AI Data Delivery에서는 Object Storage에 있는 Dataset과 Model을 필요한 AI Compute로 전달하고, Compute에서 생성된 Checkpoint와 Result를 다시 Storage로 회수할 수 있습니다.
Object Storage Transfer가 Storage 사이의 Data Movement를 담당한다면 AI Data Delivery는 같은 Transfer Layer를 Storage와 Compute 사이로 확장합니다.
SCOPE
Object Storage Transfer의 경쟁력은 단순히 지원하는 Storage Logo의 숫자에서 결정되지 않습니다.
실제 Enterprise 환경에서는 어떤 Storage를 Source와 Target으로 사용할 수 있는지, 어떤 방향으로 이동할 수 있는지, 대용량·대량 Object를 어떻게 처리하는지, 실패 이후 어떻게 복구하는지, 새로운 Storage가 추가되어도 같은 운영 방식을 사용할 수 있는지가 중요합니다.
하나의 Bucket Copy에서 시작해 Multi-Cloud와 AI Infrastructure까지 같은 Data Movement Layer로 확장합니다.
GET STARTED
Public Cloud, Private Cloud, On-Prem과 S3-Compatible Object Storage 사이의 Transfer를 Source와 Target 중심으로 구성하고, Large Object와 수많은 Object의 이동, Recovery, Automation과 Result를 같은 방식으로 운영합니다.
필요한 경우 같은 Data Path를 Storage-to-Compute와 AI Data Delivery까지 확장할 수 있습니다.
사용 중인 Object Storage와 Data Path에 맞는 전송 구성을 함께 검토해드립니다.