Azure Blob에서 사내 서버로 파일 전달하기

시작하기

기본 개념

Azure Blob의 파일을 사내 서버 작업 폴더로 직접 전송하기

Azure 환경에서 생성되거나 저장된 파일을 사내 시스템에서 활용해야 하는 경우가 있습니다.

예를 들어 클라우드에서 생성된 처리 결과를 내부 업무 서버로 가져오거나, Azure Blob에 저장된 백업 파일을 사내 보관 서버에 전달할 수 있습니다.

기존에는 다음과 같이 담당자나 중간 환경을 통해 파일을 이동할 수 있습니다.

Azure Blob Storage
        │
        │ Download
        ▼
   Local PC / Server
        │
        │ Copy
        ▼
 On-Premises Server

직접 전송을 구성하면 Azure Blob과 온프레미스 서버를 하나의 파일 전송 흐름으로 연결할 수 있습니다.

┌─────────────────────┐
│  Azure Blob Storage │
│                     │
│   Source Container  │
└──────────┬──────────┘
           │
           │ File Transfer
           ▼
┌─────────────────────┐
│ On-Premises Server  │
│                     │
│  Windows / Linux    │
└─────────────────────┘

이렇게 하면 Azure Blob 파일 확인 → 전송 대상 선택 → 사내 서버 저장 → 결과 확인까지 하나의 작업으로 이어갈 수 있습니다.

대상 폴더

Azure의 파일 경로와 서버의 실제 작업 폴더 연결하기

Azure Blob의 하나의 Container에는 여러 업무와 서비스에서 사용하는 파일이 함께 저장될 수 있습니다.

따라서 Container 전체를 서버로 내려받기보다, 실제 온프레미스 환경에서 필요한 파일 경로만 선택해 전달할 수 있습니다.

예를 들어 Azure Blob에 다음과 같은 파일 구조가 있다고 가정합니다.

processing-container
│
├── completed/
│   ├── report/
│   │   ├── report-01.csv
│   │   └── report-02.csv
│   │
│   └── media/
│
├── backup/
│
└── temporary/

이 중 완료된 보고서 파일만 사내 서버의 업무 폴더로 전달할 수 있습니다.

Azure Blob Storage                    On-Premises Server

processing-container                  D:\data\incoming\
│                                     │
├── completed/                        ├── report-01.csv
│   └── report/       ───────────▶    └── report-02.csv
│       Selected
│
├── backup/        Not Included
└── temporary/     Not Included

Linux 서버를 사용하는 경우에는 /data/incoming/과 같은 지정 경로를 Target으로 구성할 수도 있습니다.

전송 경로는 서버의 실제 업무 구조에 맞춰 구성할 수 있습니다.

이를 통해 Azure에 저장된 파일과 실제 사내 업무가 진행되는 서버 폴더를 직접 연결할 수 있습니다.

전달 시점

필요할 때 실행하거나 파일 생성과 일정에 맞춰 자동 전달하기

Azure Blob의 파일을 사내 서버로 전달하는 작업은 일회성 다운로드로만 구성할 필요가 없습니다.

파일이 Azure에 생성된 이후 자동으로 전달하거나, 사내 업무가 시작되기 전에 정해진 시간에 필요한 파일을 서버로 가져오도록 구성할 수 있습니다.

예를 들어 다음과 같은 방식으로 활용할 수 있습니다.

예를 들어 Azure에서 야간 처리된 결과 파일을 매일 오전 사내 서버로 전달하는 경우 다음과 같이 구성할 수 있습니다.

Azure 처리 완료
        │
        ▼
결과 파일 확인
        │
        ▼
전송 조건 확인
        │
        ▼
사내 서버 전달
        │
        ▼
작업 폴더 반영

이후 서버에 파일이 저장되면 해당 파일을 사용하는 배치 작업이나 분석 프로그램을 자동으로 실행하도록 연결할 수도 있습니다.

IT 엔지니어

환경 연결

Azure Blob Storage와 사내 서버를 각각 전송 환경에 등록하기

먼저 파일을 가져올 Azure Blob Storage와 파일을 저장할 온프레미스 서버를 각각 연결합니다.

Source와 Target은 서로 다른 환경이므로 파일 접근과 저장 범위를 분리해 관리할 수 있습니다.

Azure Blob에서는 전송할 Container와 파일을 읽을 수 있어야 하며, 사내 서버에서는 지정된 폴더에 파일을 저장할 수 있어야 합니다.

Transfer Environment

Azure Blob Storage
└── Source Container
    └── Read Files

        │
        ▼

Transfer Flow

        │
        ▼

Windows / Linux Server
└── Target Folder
    └── Write Files

전송을 구성하기 전에 다음 항목을 확인합니다.

각 환경을 독립적으로 연결하면 Azure의 Storage 접근 범위와 사내 서버의 파일 저장 범위를 분리하면서 하나의 전송 작업으로 연결할 수 있습니다.

경로 구성

Container의 파일 위치를 서버의 업무 폴더에 맞춰 매핑하기

연결 환경을 준비한 뒤에는 Azure Blob에서 파일을 가져올 위치와 사내 서버에서 파일을 저장할 위치를 설정합니다.

예를 들어 Azure Blob의 다음 경로를 Source로 지정할 수 있습니다.

processing-container/completed/report/

Windows 서버에서는 다음과 같이 Target 폴더를 지정할 수 있습니다.

D:\data\incoming\report\

Linux 서버에서는 다음과 같이 구성할 수 있습니다.

/data/incoming/report/

전체 전송 구조는 다음과 같이 구성됩니다.

Source

Azure Blob Storage
processing-container
└── completed/
    └── report/
        ├── report-01.csv
        ├── report-02.csv
        └── report-03.csv

                │
                │ Transfer
                ▼

Target

Windows / Linux Server
└── Target Folder
    ├── report-01.csv
    ├── report-02.csv
    └── report-03.csv

업무에 따라 하나의 Azure Container에서 여러 서버로 파일을 분기하거나, 여러 Azure 경로의 파일을 하나의 중앙 서버로 수집하는 방식으로 확장할 수도 있습니다.

예를 들어 파일 유형에 따라 서로 다른 내부 서버로 전달하면 다음과 같은 구성이 가능합니다.

                    ┌──▶ Windows Server
                    │     D:\report\
Azure Blob ── Flow ─┼──▶ Linux Server
                    │     /data/media/
                    │
                    └──▶ Archive Server
                          /backup/

이처럼 Azure Blob의 하나의 파일 저장 환경을 시작점으로 두고, 사내 업무 구조에 맞춰 여러 온프레미스 환경으로 파일을 전달할 수 있습니다.

파일 조건

서버에서 필요한 파일만 선택해 지정된 위치로 전달하기

Azure Blob에는 처리 중인 파일과 완료된 파일, 백업 파일 등이 함께 저장될 수 있습니다.

따라서 모든 Blob을 서버로 전달하기보다 파일 이름이나 확장자, 경로를 기준으로 실제 업무에 필요한 파일만 선택할 수 있습니다.

예를 들어 다음과 같이 구성할 수 있습니다.

이렇게 하면 Azure Blob의 전체 파일을 내려받는 대신 온프레미스 환경에서 실제로 필요한 파일만 선택적으로 전달할 수 있습니다.

후속 처리

서버 폴더에 파일이 저장된 후 다음 작업까지 자동으로 연결하기

Azure Blob의 파일이 사내 서버에 저장된 후에는 해당 파일을 사용하는 다음 작업을 연결할 수 있습니다.

예를 들어 보고서 파일이 Windows 서버에 저장되면 내부 프로그램에서 데이터를 처리하거나, Linux 서버의 작업 폴더에 미디어 파일이 도착하면 변환 작업을 시작하도록 구성할 수 있습니다.

Azure Blob
     │
     ▼
File Transfer
     │
     ▼
On-Premises Folder
     │
     ├──────────────▶ Application
     │
     ├──────────────▶ Next Flow
     │
     └──────────────▶ Completion Notice

후속 작업은 파일이 Target에 정상적으로 반영된 결과를 기준으로 실행할 수 있습니다.

이를 통해 클라우드 파일 전달 → 서버 폴더 반영 → 내부 처리 → 결과 확인까지 하나의 업무 흐름으로 연결할 수 있습니다.

실행 확인

클라우드의 원본 파일과 서버의 저장 결과를 함께 확인하기

전송 작업이 실행되면 Runs에서 전체 처리 상태와 실행 결과를 확인할 수 있습니다.

특정 Run을 선택하면 Azure Blob의 Source와 온프레미스 서버의 Target, 전송 파일 수와 전체 용량, 진행 상태를 확인할 수 있습니다.

각 Run에서는 다음 정보를 확인할 수 있습니다.

전송이 완료되면 전체 Run 상태와 함께 실제 Target 서버의 지정 폴더에 파일이 정상적으로 저장되었는지 확인할 수 있습니다.

이를 통해 어떤 Azure 파일이 어느 사내 서버로 전달되었는지와 최종 저장 결과를 하나의 실행 기록을 기준으로 관리할 수 있습니다.

문제 대응

Azure Source와 온프레미스 Target을 구분해 원인을 확인하기

전송 중 추가 확인이 필요한 상황이 발생하면 먼저 Azure Blob과 온프레미스 서버 중 어느 환경에서 문제가 발생했는지 구분합니다.

Azure Blob에서 파일을 읽을 수 없는 경우에는 Storage 연결 상태와 Container, 파일 경로를 확인합니다. 반대로 서버에 파일을 저장할 수 없는 경우에는 Target 장비 연결과 대상 폴더, 저장 권한을 확인합니다.

                 Transfer Failed
                        │
           ┌────────────┴────────────┐
           │                         │
           ▼                         ▼
      Azure 확인                 Server 확인
           │                         │
    Container 연결               장비 연결 상태
    Source 파일 경로             Target 폴더
    파일 읽기 권한               파일 저장 권한
           │                         │
           └────────────┬────────────┘
                        ▼
                    환경 조정
                        │
                        ▼
                      Retry
                        │
                        ▼
                 서버 저장 결과 확인

문제를 확인한 뒤 필요한 연결이나 경로, 접근 범위를 조정하고 작업을 다시 실행할 수 있습니다.

재실행 후에는 새로운 Run을 통해 Azure Blob의 파일이 사내 Windows 또는 Linux 서버의 지정된 작업 폴더에 정상적으로 반영되었는지 확인합니다.

이 레시피를 적용하면 Azure Blob 연결 → Source 파일과 경로 선택 → Windows 또는 Linux 서버 Target 구성 → 파일 조건과 실행 시점 설정 → 클라우드에서 온프레미스로 직접 전송 → 서버 반영 후 후속 작업 연결 → Run 결과 확인 → 저장 결과 검증까지 하나의 흐름으로 구성할 수 있습니다.

이를 통해 클라우드에 저장된 파일을 중간 PC를 거치지 않고 사내 업무 환경으로 직접 전달하고, 서버의 실제 작업 폴더에서 파일 활용과 후속 처리까지 이어지는 하이브리드 파일 전송 환경을 구성할 수 있습니다.

개발자

Azure Blob 파일을 온프레미스 서버로 전송하고 결과를 확인하기

소스(Azure Blob)와 대상(서버)을 각각 장비로 등록한 뒤, 프리픽스와 서버 경로를 지정해 전송을 만들고 종료 상태를 확인합니다. 시작 전에 다음 항목을 준비합니다.

Python·Node.js는 REST를 직접 호출하는 최소 api() 헬퍼와 상태 상수(STATUS_COMPLETE·TERMINAL)를 API 호출 레시피의 것을 재사용합니다. Java·C#은 번들 소스의 InnorixClient(상수 포함)와 Json(C#은 J) 헬퍼를 사용합니다. 장비 식별자(azure-src·onprem-01)와 경로는 실제 값으로 바꿔 넣습니다.

Azure Blob → 서버 전송 생성

Azure Blob의 프리픽스를 폴더 루트로 넣고(sourcePaths + sendAllFolder), 서버의 절대 경로를 targetPath로 지정합니다. 전송 생성 후 monitorId로 종료 상태를 확인합니다.

import time


def transfer_to_server(source, target, prefixes, target_path, action="overwrite"):
    transfer = api("POST", "/api/transfers/manual", {
        "sourceDevice": source,
        "targetDevice": target,
        "targetPath": target_path,
        "sourcePaths": prefixes,
        "sendAllFolder": True,
        "transferOptions": {"target-action": action},
    })
    return transfer["monitorId"]


def wait_transfer(monitor_id, timeout=14400, interval=5):
    deadline = time.time() + timeout
    while time.time() < deadline:
        detail = api("GET", f"/api/transfers/{monitor_id}") or {}
        if detail.get("status") in TERMINAL:
            return detail
        time.sleep(interval)
    raise TimeoutError(monitor_id)


monitor_id = transfer_to_server("azure-src", "onprem-01", ["export/2026/09"], "/data/incoming")
detail = wait_transfer(monitor_id)
print("completed:", detail.get("status") == STATUS_COMPLETE)

서버 경로는 절대 경로 targetPath는 대상 서버의 절대 경로로 지정합니다(Windows는 C:/share/incoming, Linux는 /data/incoming). 대상 폴더가 없으면 전송이 실패할 수 있으므로 미리 준비합니다.

정기 반입 같은 프리픽스를 주기적으로 반입해야 하면 예약 자동화(S3→Linux 자동 다운로드 레시피 참고)로 전환해 정해진 시각마다 실행할 수 있습니다.

실패 파일이 남으면 중단 후 재개 레시피의 retry_failed로 실패분만 다시 전송합니다.

구현 결과

이 레시피를 적용하면 다음 흐름으로 Azure Blob 파일을 온프레미스 서버로 전달할 수 있습니다.

Azure Blob (azure-src) — 프리픽스 지정
   ↓  

전송 생성 → 종료 상태까지 대기
   ↓  

온프레미스 서버 (onprem-01) — 지정 폴더에 파일 저장
   ↓  

실패 파일만 재시도

클라우드 자격 증명을 코드에서 다루지 않고 device ID와 경로만으로 Azure Blob → 서버 전송을 실행하며, 남은 실패 파일만 선택해 다시 보낼 수 있습니다.