목차
본문으로 바로가기

[StorageAccouts] Blob 설계 및 접근방법

category Cloud/Azure 2025. 7. 22. 12:12

1. Blob Sotrage 구조 설계

  • Azure Blob Storage는 파일 시스템처럼 보이지만, 디렉터리 개념이 아닌 “prefix(접두어)” 기반의 논리적 구조를 사용합니다.
  • 디렉터리 구조처럼 보이지만, Blob Storage에서는 단지 a/file/라는 접두어(prefix)를 가진 하나의 Blob으로 간주됩니다
  • 이를 기반으로 사용자별 논리적 폴더 구조를 만들고, prefix 단위로 접근을 제한하는 방식이 흔히 사용됩니다
container/
├── userA/file1.txt   (prefix: userA/)
├── userB/file2.txt   (prefix: userB/)
└── userC/file3.txt   (prefix: userC/)

2. prefix 격리

  • Blob Storage는 Container 단위로 권한을 부여하는 것이 기본입니다. 그러나 사용자가 동일 컨테이너 안에서 각자 자신의 prefix(userA/, userB/)만 접근하도록 하려면 아래와 같은 격리 기법을 활용해야 합니다.

2.1. SAS(Shared Access Signature)를 이용한 Prefix 격리

  • 구성 방법

    • 1개의 컨테이너(data)에 사용자별 prefix 생성: data/userA/, data/userB/
    • 중앙 시스템에서 각 사용자의 prefix에 대한 Blob SAS URL 발급
    • SAS URL을 통해 해당 경로만 접근 가능하도록 로직적으로 제한
  • 격리 원리

    • SAS는 컨테이너나 개별 Blob 단위의 접근 토큰을 생성합니다.
    • 그러나 prefix 기반의 전체 디렉터리에 대한 직접적인 권한 제한은 불가하므로, 접두어 검증 및 SAS 발급 로직으로 제한하는 방식입니다.

2.2. Managed Identity를 이용한 Prefix 격리

  • 구성 방법

    • Storage 계정에 Hierarchical Namespace(HNS) 활성화
    • 사용자별 prefix(userA/)를 디렉터리처럼 생성
    • 해당 prefix에 POSIX ACL 방식으로 Azure AD 사용자나 Managed Identity에게 권한 부여
  • "Azure Portal" -> "VM/APP Service" -> "identity" -> "System Assigned" -> "ON 설정"

  • Storage Account 에 권한 부여 : Azure Storage Account 접근 할 수 있도록 Managed Identity에 RBAC 부여

  • 격리 원리
    • Azure Data Lake Storage Gen2 (계층적 이름공간 활성화) 전제 조건
    • Azure AD 기반 인증 (Managed Identity 포함)
    • 디렉터리 수준의 rwx 권한을 prefix에 부여
    • 접근 요청 시 Azure는 디렉터리 ACL을 확인하여 접근 여부 결정
    • Key Vault 처럼 민간한 리소스에 접근 할 때 비밀번호나 키를 코드에 저장하지 않아도 되는 장점 있음

3. SAS vs Managed Identity 비교

항목 SAS 기반 격리 Managed Identity 기반 격리
인증 방식 SAS Token (공유키 기반) Azure AD 기반 (RBAC + ACL)
보안 수준 중간 (Token 노출 가능) 높음 (정식 인증/권한 모델)
prefix 제어 코드 또는 로직으로 강제 실제 디렉터리 수준 ACL
외부 사용자 사용 적합 부적합
내부 앱 사용 가능 매우 적합
ACL 기반 제어 X O
만료 설정 가능 (자동) 수동 회수 필요

4. 접근방법

4.1 API 기반 접근 및 관리

  • Azure SDK 또는 REST API를 통해 Blob Storage의 prefix 구조를 조회, 파일 업로드/삭제 가능
  • Azure SDK for Python, NET, JavaScript 등 지원.

4.2 VM Blob Storage 마운트

  • Blobfuse 또는 Blobfuse2 를 사용 하여 Linux에 마운트 하여 사용 할 수 있음

  • 설치 방법

yaml 옵션 설명 (접기/펼치기)
version: 2
# blobfuse2 구성 파일 버전 (반드시 2로 설정해야 blobfuse2에서 인식 가능)

logging:
  type: syslog
  level: LOG_WARNING
  # logging type: syslog, stderr, or file
  # logging level: LOG_DEBUG, LOG_INFO, LOG_WARNING, LOG_ERR 등

components:
  - libfuse
  - azstorage
  # 사용할 blobfuse2 구성 컴포넌트 목록
  # libfuse: FUSE 기반 파일 시스템
  # azstorage: Azure Blob Storage 백엔드 드라이버

libfuse:
  attribute-expiration-sec: 120
  entry-expiration-sec: 120
  negative-entry-expiration-sec: 60
  # FUSE 캐시 TTL 설정 (초 단위)
  # attribute-expiration-sec: 파일 메타데이터 캐시 유효 시간
  # entry-expiration-sec: 디렉터리 엔트리 캐시 유효 시간
  # negative-entry-expiration-sec: 존재하지 않는 항목에 대한 캐시 시간

azstorage:
  type: block
  # blob 유형 지정: block, append, page
  # 일반적인 파일 업로드/다운로드는 block

  account-name: mystorageaccount
  container: mycontainer
  # Azure Storage 계정 및 컨테이너 이름

  endpoint: https://mystorageaccount.blob.core.windows.net
  # endpoint 생략 시 기본 Azure 상용 환경 URL 사용
  # 중국/독일/정부 클라우드 환경에서는 별도 지정 필요

  sas: "?sv=...&ss=...&srt=...&sp=...&se=...&st=...&spr=...&sig=..."
  # SAS 토큰 (또는 아래의 managed identity 방식도 가능)

  # (대신 아래를 사용해도 됨)
  # msi-resource-id: <Azure managed identity 리소스 ID>
  # use-http: true   # HTTP로 통신 (기본 false)

  file-cache-timeout-in-seconds: 120
  # 파일 캐시 유효 시간. 설정된 시간 이내에는 재다운로드 안 함

  download-pool-size: 16
  upload-pool-size: 16
  # 병렬 다운로드/업로드 개수 설정

  allow-other: true
  # 다른 사용자도 마운트된 디렉터리에 접근 가능하게 설정 (멀티유저 시스템)

  tmp-path: /mnt/blobfuse
  # 임시 파일 저장 경로 (로컬 캐시로 활용됨)

  mode: 0777
  # 마운트된 파일 시스템의 기본 권한
[연동방법] account-key (접기/펼치기)
  • 스토리지계정(Storage Account) : test11

  • 컨테이너 : test

    • 위치 : 생성한 스토리지 계정 -> 데이터 스토리지 -> 컨테이너
  • account-key : 키 생성 값

    • 위치 : 생성한 스토리지 계정 -> "보안 + 네트워킹" -> 액세스 키
# Refer ./setup/baseConfig.yaml for full set of config parameters

logging:
  type: syslog
  level: log_debug

components:
  - libfuse
  - file_cache
  - attr_cache
  - azstorage

libfuse:
  attribute-expiration-sec: 120
  entry-expiration-sec: 120
  negative-entry-expiration-sec: 240

file_cache:
  path: /<PATH>/<TO>/<CACHE_DIR>
  timeout-sec: 120
  max-size-mb: 4096

attr_cache:
  timeout-sec: 7200

azstorage:
  type: block
  account-name: blobjarunan216121
  account-key: 0YIBktENKRkvDXR4X4GrLKyIqScO99lVZ12345BEBD/K8rxm4N8ED6G957yG0tgs==
  mode: key
  container: content
[연동방법] SAS 방식 (접기/펼치기)
  • 스토리지계정(Storage Account) : test11

  • 컨테이너 : test

    • 위치 : 생성한 스토리지 계정 -> 데이터 스토리지 -> 컨테이너
  • sas : 키 생성 값

    • 위치 : 생성한 스토리지 계정 -> "보안 + 네트워킹" -> 공유 액세스 서명
# Refer ./setup/baseConfig.yaml for full set of config parameters

logging:
  type: syslog
  level: log_debug

components:
  - libfuse
  - file_cache
  - attr_cache
  - azstorage

libfuse:
  attribute-expiration-sec: 120
  entry-expiration-sec: 120
  negative-entry-expiration-sec: 240

file_cache:
  path: /<PATH>/<TO>/<CACHE_DIR>
  timeout-sec: 120
  max-size-mb: 4096

attr_cache:
  timeout-sec: 7200

azstorage:
  type: block 
  account-name: test11
  sas: sv=2024-11-04&ss=b&srt=c&sp=rwdlacyx&se=2025-07-24T10:07:03Z&st=2025-07-24T01:52:03Z&spr=https&sig=%%2FQ%3D 
  container: test
  • 마운트
# 구성파일 작성 ( fuse_connection.cfg 에 Storage Account key, Container 정보 입력 )
# 마운트 명령어
$ blobfuse2 /mnt/blob --temp-path=/mnt/blobfusetemp --config-file=/home/fuse_connection.cfg

# /mnt/blob                                        // Azure Blob Storage 컨테이너를 마운트할 로컬 디렉터리 경로입니다. 이 디렉터리는 미리 생성 필요
# --temp-path=/mnt/blobfusetemp                    //임시 캐시 디렉터리 경로입니다. Blobfuse는 성능을 위해 이 디렉터리에 메타데이터 및 임시 데이터를 저장합니다. 미리 생성 필요 
# --config-file=/home/fuse_connection.cfg          //Azure Storage 계정 연결 정보가 들어 있는 설정 파일 경로입니다. 계정 이름, 키 또는 SAS 토큰, 컨테이너 이름 등이 포함
  • 재기동 시 자동 기동 설정
# 서비스 생성
# 예시: /etc/systemd/system/blobfuse2-mount.service
[Unit]
Description=Mount Azure Blob Storage using Blobfuse2
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/blobfuse2 mount /mnt/blobfuse --config-file=/path/to/blobfuse2.yaml
ExecStop=/bin/fusermount -u /mnt/blobfuse
RemainAfterExit=true
Restart=always

[Install]
WantedBy=multi-user.target



# 서비스 등록 
sudo systemctl daemon-reexec
sudo systemctl enable blobfuse2-mount.service
sudo systemctl start blobfuse2-mount.service

4.4 App Service Blob Storage 접근

  • BYOS ( Bring Your Own Storage ) 방식

    • App Service 의 Configuration 메뉴에서 Path Mappings 설정
    • Storage Account , Container , Access Key 입력
    • SMB 파일 공유 시 Security Profile 을 Maximum compatibility로 설정
      • 네트워크 설정이 중요, Vnet 통합 시 NSG 및 Private Endpoint 설정 필요
  • Azure Service Connector 방식

    • Azure PaaS 서비스인 Azure Storage, Azure SQL Database, Azure Cosmos DB등 과 같은 서비스 간의 연결을 지원
    • Docs

5. 디스크 성능 비교

항목 Blob Storage (Storage Account) Managed Disk Azure NetApp Files
IOPS (최대) 최대 수십만 (계층, 단일 Blob 제한 존재) P30: 5,000 IOPS / P80: 20,000 IOPS 최대 450,000 IOPS (용량 기반)
Throughput (최대) 최대 60 Gbps 이상 (계정 기준) P80 디스크 기준: 900 MBps 최대 4.5 GBps (Premium Tier 기준)
지연시간 (Latency) 5~20ms 이상 (HTTP 기반 API) <1ms (디스크 접근) <1ms
접근 방식 REST API / SDK / Blobfuse / AzCopy VM에 직접 마운트 NFSv3 / SMB
단일 Blob 제한 약 500 requests/sec / Blob (Blob 유형에 따라 다름) 없음 (디스크 단위) 없음
단일 계정 제한 Blob 요청 20,000 RPS / 계정 VM + 디스크 조합 기준 최대 100 TiB / Volume
확장성 스토리지 계정 기준으로 확장 디스크 크기 및 병렬 디스크 용량 단위로 QoS 확장
SLA 99.9% (LRS), 99.99% (ZRS) 99.90% 99.99%

6. SAS / Managed Identity 방화벽·예외 처리 검토

6.1. SAS 방식 연동 시 체크포인트

구분 주요 검토 항목 방화벽·예외 처리 포인트
Storage 접근 경로 Private Endpoint 사용 필수 🔴 NSG 및 Firewall에서 Storage Private Endpoint IP 대역 허용
DNS 설정 Private DNS Zone 등록 및 사용 🔴 내부 DNS에서 *.privatelink.blob.core.windows.net 이름 해석 가능해야 함
SAS 토큰 보안 SAS 토큰 노출 최소화 및 만료시간 관리 토큰은 Key Vault 등 안전한 저장소 사용 권장
방화벽 규칙 Storage Account 퍼블릭 IP 접근 차단 상태 확인 - Public Network Access Off 상태 유지
- Private Endpoint IP 허용
App Service 네트워킹 VNet 통합 및 서비스 엔드포인트 연동 여부 🔴 App Service가 Private Endpoint와 같은 VNet에 있거나 VNet 통합 설정 필수

6.2. Managed Identity 방식 연동 시 체크포인트

구분 주요 검토 항목 방화벽·예외 처리 포인트
Managed Identity 토큰 발급 IMDS(Instance Metadata Service) 접근 🔴 NSG/UDR에서 169.254.169.254 메타데이터 IP 접근 허용 필수
Storage 접근 권한 제어 RBAC 할당 (예: Storage Blob Data Reader) - 권한은 최소권한 원칙으로 할당
- 권한 변경 시 반영 지연 확인
Private Endpoint 연동 SAS와 동일, Private Endpoint 통한 연결 🔴 NSG/Firewall에 Private Endpoint IP 대역 허용
DNS 구성 Private DNS Zone 및 이름 해석 구성 🔴 Private DNS가 제대로 구성되어 privatelink.* 도메인 해석 가능해야 함
App Service 네트워킹 VNet 통합 및 MI 지원 여부 🔴 App Service가 Managed Identity 지원하고 Private Link 연결 가능해야 함

6.3. 모니터링 및 운영 시 체크포인트

  • Access Logs / Diagnostic Logs: Storage 및 네트워크 로그 활성화로 비정상 접근 감지
  • RBAC 권한 변경 감시: Managed Identity 권한 변경 및 토큰 사용 기록 점검
  • DNS 문제 모니터링: Private DNS 정상 작동 여부, 네트워크 격리 문제 감지
  • 네트워크 트래픽 흐름 점검: UDR, NSG, Firewall 로그로 Private Endpoint 트래픽 모니터링

7. 관련 링크