파일 전송
Object Storage Transfer
서로 다른 Cloud와 On-Prem Object Storage를 하나의 Transfer Layer로 연결하는 INNORIX 솔루션을 소개합니다.
File Transfer
서로 다른 Object 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으로 확장되면 데이터를 이동해야 하는 Source와 Target의 조합도 함께 늘어납니다.
INNORIX 객체 스토리지 간 전송은 특정 Storage 제품의 내부 복사 기능을 대체하는 것이 아니라, Public Cloud, Private Object Storage, On-Prem과 S3-Compatible Storage 사이의 Data Movement를 Source와 Target 중심의 하나의 Transfer Layer로 연결합니다. Large Object와 수많은 Object의 Transfer, Recovery, Automation과 Result까지 같은 운영 모델에서 관리하고 필요하면 Storage-to-Compute로 Data Path를 확장합니다.
- Public Cloud Storage
- Private Object Storage
- On-Prem Storage
- S3-Compatible Storage
- INNORIX
- Object Storage
- AI / Compute
- Data Center
File Transfer
Storage의 종류보다 실제 Source와 Target의 조합을 중심으로 구성합니다.
하나의 Cloud 안에서 Bucket을 복제하는 것과 서로 다른 Storage Infrastructure를 연결하는 것은 다른 문제입니다. Object Storage가 다양해질수록 Endpoint, Authentication, Region, Namespace와 API Compatibility처럼 실제 Source와 Target 조합에서 확인해야 할 조건이 늘어나고, 같은 Storage라도 Source와 Target 방향에 따라 지원 범위가 달라질 수 있습니다.
S3 API는 Object Storage 생태계의 중요한 Interface이지만 S3-Compatible이라는 표현만으로 모든 구현과 동작이 동일하다고 볼 수는 없습니다. Endpoint 구성, Authentication, Region Signing, Path Style과 Virtual-Hosted Style, Listing 방식과 Object Metadata 등이 함께 작동하므로 INNORIX는 Storage Logo의 수보다 어떤 Source에서 어떤 Target으로 실제 Data Movement를 구성할 수 있는가와 그 방향성을 기준으로 Transfer를 구성합니다.
확인 항목, 의미
File Transfer
Native Storage 기능은 유지하면서 Storage의 경계를 넘어가는 Transfer를 연결합니다.
하나의 Storage Ecosystem 안에서 제공되는 Replication과 Migration 기능은 해당 환경 내부의 Resource와 Region을 운영하는 데 중요한 역할을 합니다. 하나의 Cloud와 Storage만 사용하는 환경이라면 이러한 Native Tool만으로 필요한 Data Movement를 충분히 처리할 수도 있습니다.
INNORIX는 이러한 기능을 대체하기보다 서로 다른 Cloud, Private Storage와 On-Prem 사이처럼 Storage의 경계를 넘어가는 Data Movement를 담당합니다. Infrastructure가 확장될 때 각 조합마다 별도의 Copy Tool과 운영 방식을 추가하는 대신 Source, Target, Transfer와 Run이라는 동일한 Model에서 Cross-Storage 관계를 구성합니다.
Native Storage 기능, INNORIX
- Cloud A
- Cloud A
- Cloud B
- Private Storage
- On-Prem
- Cloud B
- Cloud A
- Private Storage
- On-Prem
File Transfer
Object에서 Object까지 실제 Data Path를 하나의 구조로 운영합니다.
Local / Temporary Storage
Object Storage B
Download / Re-upload
- Object Storage A
- Local / Temporary Storage
- Object Storage B
INNORIX
- INNORIX Platform — Control Plane
- Object Storage A
- Object Storage B — Data Path
File Transfer
Bucket에서 Multi-Cloud까지 같은 Transfer Model을 확장합니다.
Object Storage Transfer는 하나의 Bucket에서 다른 Bucket으로 Copy하는 관계에서 시작할 수 있지만 실제 Enterprise 환경에서는 Account, Region, Production, Archive, Primary, Secondary와 서로 다른 Cloud 사이까지 다양한 관계가 필요합니다. Storage가 추가될 때마다 새로운 Transfer System을 구축하기보다 새로운 Source 또는 Target Endpoint를 기존 Data Movement에 연결하는 구조가 장기적으로 더 일관된 운영 모델을 만듭니다.
INNORIX는 Bucket → Bucket, Account → Account, Region → Region과 Cloud ↔ On-Prem을 같은 Source, Target 관계로 구성합니다. Infrastructure가 하나의 Storage에서 Multiple Account와 Region, Multi-Cloud, Private와 Sovereign Environment로 확대되어도 Transfer Configuration, Monitoring과 Result를 같은 방식으로 유지할 수 있습니다.
Transfer 관계, 대표적인 목적
- 1 Storage
- Multiple Buckets
- Multiple Accounts / Regions
- Multi-Cloud
- Private + On-Prem
- Distributed Data Infrastructure
File Transfer
Large Object와 수많은 Object를 데이터 특성에 맞게 처리합니다.
Object Storage의 데이터는 하나의 형태로만 존재하지 않습니다. 수 GB에서 TB급까지 커지는 Dataset, Media File, Archive와 Model Artifact가 있는 반면 AI Dataset, Image Archive, Research Data와 Machine Data는 수백만 개의 작은 Object로 구성될 수 있습니다. Mixed Dataset에서는 두 특성이 동시에 나타날 수도 있습니다.
INNORIX는 Large File Transfer와 High-Volume Transfer Capability를 Object Storage Data Path에 적용합니다. Large Object에서는 Parallel Transfer, Progress, Resume와 Recovery가 중요하고, Object 수가 많아지면 Listing, Filtering, Queue, Concurrent Transfer와 Object-Level Result가 전체 처리 시간과 운영 복잡도에 영향을 줍니다. Object의 크기와 개수가 달라져도 하나의 Transfer 실행과 결과 체계에서 관리합니다.
Data Profile, Transfer에서 중요해지는 것
Large Object
- Source
- Parallel Transfer
- Progress
- Resume
- Recovery
- Target
High-Volume Objects
- List
- Compare / Filter
- Queue
- Concurrent Transfer
- Object Result
File Transfer
Source와 Target의 Capacity 안에서 Transfer를 확장하고 장애 범위만 복구합니다.
Object가 크거나 개수가 많다고 해서 무조건 많은 Transfer를 동시에 실행하는 것이 항상 최적의 결과를 만드는 것은 아닙니다. Source Storage의 API 처리 능력, Target Storage의 처리량, Network와 다른 Workload를 함께 고려하면서 Parallel Transfer와 Concurrency를 조정하고 대기 작업을 Queue로 관리해야 합니다.
Transfer 도중 문제가 발생했을 때도 같은 원칙이 적용됩니다. 수백만 개의 Object 가운데 일부만 실패했거나 Large Object가 대부분 전달된 상태라면 전체 작업을 처음부터 반복하는 대신 Transfer State와 Object별 Result를 유지하고 Interrupted, Failed, Partial 범위를 기준으로 Resume 또는 Retry하는 것이 중요합니다. INNORIX는 현재 Source와 Target에서 사용할 수 있는 Capacity를 활용하면서 실패 범위만 다시 처리하는 방식으로 Transfer를 운영합니다.
Transfer 요소, 역할
- Source Storage
- Parallel / Concurrency
- Parallel / Concurrency
- Completed
- Completed
- Failed
- Retry
- Interrupted
- Resume
- Completed
- Target Storage
File Transfer
Object의 완료와 Integrity를 Transfer Result로 확인합니다.
S3-Compatible API를 사용한다는 사실과 실제 데이터의 무결성 확인은 별개의 문제입니다. 특히 Multipart Upload와 Storage별 구현 차이 때문에 Object의 ETag를 모든 환경에서 단순한 파일 MD5와 동일하게 해석할 수 없으므로, API Request의 성공 여부만으로 전체 Data Movement의 결과를 판단하기보다 실제 Transfer의 완료 상태와 Object별 결과를 함께 확인해야 합니다.
INNORIX는 어떤 Object가 전달되었는지, 어느 Object에 추가 처리가 필요한지와 최종 Transfer Result를 운영 단위에서 확인할 수 있도록 합니다. Transfer가 중단되거나 일부 Object가 실패하면 필요한 범위만 복구하고, 완료 이후에는 Object Result와 Receipt를 통해 대규모, 대량 Storage Transfer의 최종 상태를 하나의 결과 체계에서 확인합니다.
- Object Transfer
- Transfer Complete
- Object Result
- Object Result
- Completed
- Retry / Recovery
- Verify
- Receipt
File Transfer
Migration에서 반복되는 Data Movement까지 같은 Data Path를 사용합니다.
Object Storage 사이의 이동은 새로운 Storage로 데이터를 한 번 옮기는 Migration으로 시작될 수도 있지만, 실제 업무에서는 Migration 이후에도 새로운 Dataset 전달, Processing, Archive, Regional Operation과 Hybrid Data Movement가 계속 발생할 수 있습니다. Migration을 위해 만든 Transfer를 일회성 도구로 남겨두면 이후 업무마다 새로운 Copy 방식이 다시 추가될 수 있습니다.
INNORIX는 One-Time, Scheduled, Incremental, Event-Driven과 Flow 기반 Transfer를 같은 Source, Target 관계에 적용합니다. 예를 들어 On-Prem Object Storage의 Dataset을 Cloud로 처음 Migration한 뒤 같은 Data Path를 매일 생성되는 데이터의 Delivery에 사용하고, 이후 Processing이나 Archive로 이어갈 수 있습니다. Migration에서 검증한 Transfer Layer를 지속적인 Data Movement로 확장하는 구조입니다.
Transfer Mode, 적용
- Initial Migration
- Object Storage A
- Object Storage B
- Scheduled Delivery
- Processing / Archive
File Transfer
Storage와 업무 Flow를 분리해 Infrastructure 변화에 대응합니다.
업무의 목적은 특정 Storage 제품보다 오래 유지되는 경우가 많습니다. 매일 생성된 Dataset을 Processing Environment로 전달한 뒤 Archive하는 업무가 있다면 실제 Storage Endpoint는 Cloud 변경, Region 이동이나 Infrastructure 확장에 따라 달라질 수 있지만 Daily Dataset → Processing → Archive라는 Business Flow는 계속 유지될 수 있습니다.
INNORIX는 Endpoint와 Flow의 역할을 분리해 실제 Storage가 변경되거나 새로운 Target이 추가될 때 업무 전체의 Transfer Logic을 다시 만드는 범위를 줄입니다. Data Plane은 필요한 Storage 사이에서 움직이고 Control Plane에서는 Transfer Configuration, Automation, Run과 Result를 관리하므로 Infrastructure가 달라져도 업무의 Data Movement 관계와 운영 방식은 유지할 수 있습니다.
Business Flow
- Daily Dataset
- Processing
- Archive
Control / Data Plane
- INNORIX Platform, Control Plane
- Storage A
- Storage B
- Storage C
File Transfer
Object Storage에서 Compute까지 같은 Data Path를 확장합니다.
Object Storage에 저장되는 데이터의 최종 목적지가 항상 다른 Storage인 것은 아닙니다. AI Dataset은 GPU Compute로, Media Asset은 Processing Server로, Machine Data는 Analytics Environment로 전달되어야 하며, Workload에서 생성된 Checkpoint와 Result는 다시 Object Storage로 돌아올 수 있습니다.
이 경우 Object Storage Transfer는 Storage-to-Storage Copy에서 Storage-to-Compute Data Delivery로 자연스럽게 확장됩니다. Object Storage Transfer가 Storage 사이의 Data Movement를 중심으로 한다면 AI Data Delivery는 같은 Transfer Capability를 Storage ↔ Compute 사이의 Dataset, Model, Checkpoint와 Result 이동에 적용합니다.
Object Storage Transfer, AI Data Delivery
- Object Storage
- INNORIX
- Another Storage
- GPU / AI Compute
- Processing Server
- Data Center
- Analytics Environment
- Result / Checkpoint
- Object Storage
File Transfer
Storage 조합이 늘어나도 하나의 Data Movement 운영 모델을 유지합니다.
Object Storage Transfer의 범위는 단순히 지원하는 Storage Logo의 숫자로 설명하기 어렵습니다. 실제 Enterprise 환경에서는 어떤 Storage를 Source와 Target으로 사용할 수 있는지, 어떤 방향으로 이동할 수 있는지, Large Object와 수많은 Object를 어떻게 처리하는지, 실패 이후 어떤 범위를 복구하는지와 새로운 Storage가 추가되어도 같은 운영 방식을 사용할 수 있는지가 함께 중요합니다.
INNORIX는 Data Plane을 필요한 Storage 사이의 Transfer에 사용하고 Control Plane에서 Configuration, Flow, Run, Monitoring과 Result를 관리합니다. 하나의 Bucket Copy에서 시작해 Multi-Cloud, Private, On-Prem과 AI Infrastructure까지 확장되어도 Connectivity, Transfer와 Operation을 같은 Data Movement Layer에서 연결합니다.
- INNORIX Platform, Control, Flow, Monitoring
- Storage A
- Storage B
- Storage C
- Data Movement
File Transfer
Storage 사이의 Data Movement를 하나의 Transfer Layer로 연결하세요.
Public Cloud, Private Cloud, On-Prem과 S3-Compatible Object Storage 사이의 Transfer를 Source와 Target 중심으로 구성하고, Large Object와 수많은 Object의 이동, Recovery, Automation과 Result를 같은 방식으로 운영합니다.
Migration에서 시작한 Data Path를 반복되는 Storage Transfer로 이어가고, 필요한 경우 Storage-to-Compute와 AI Data Delivery까지 같은 Transfer Layer에서 확장합니다.
객체 스토리지 간 전송을 검토하고 계신가요?
사용 중인 Object Storage와 Data Path에 맞는 전송 구성을 함께 검토해드립니다.
- Object Storage 조합 및 환경 검토
- Cloud, Region 간 Data Path 구성
- Migration, 반복 전송 적용 안내