Azure Blob Storage

애플리케이션을 운영하다 보면 사용자가 올린 이미지, 서버가 남긴 로그, 백업 파일처럼 데이터베이스 테이블에 넣기 어려운 데이터가 빠르게 쌓입니다. 로컬 디스크에 쌓으면 서버를 교체하거나 스케일 아웃할 때 파일이 따라오지 않고, 용량이 부족해지면 디스크를 늘리는 작업이 서비스 중단으로 이어지기도 합니다. 여러 서버가 같은 파일에 접근해야 하면 공유 파일 시스템을 직접 구성해야 하는데, 동기화와 잠금 관리가 복잡해지면서 운영 부담이 커집니다. 거기에 접근 빈도가 천차만별인 것도 문제입니다. 어제 올린 프로필 사진은 매일 수천 번 읽히지만, 3년 전 감사 로그는 검사 때만 꺼내봅니다. 이 둘을 같은 비용 구조로 저장하면 낭비가 되고, 따로 관리하자니 아카이빙 파이프라인을 직접 만들어야 합니다.

초기에는 서버에 로컬 디스크를 달아 파일을 저장하는 것이 당연했습니다. 서비스 규모가 작을 때는 문제가 없었지만, 사용자와 데이터가 늘면서 디스크 용량 한계, 서버 간 파일 공유, 장애 시 데이터 유실이 반복적으로 터지기 시작했습니다. NAS나 SAN 같은 공유 스토리지를 도입하면 일부 문제는 해결됐지만, 하드웨어 비용이 높고 용량을 미리 산정해야 했으며 인터넷을 통한 직접 배포에는 적합하지 않았습니다. 클라우드 환경이 확산되면서 서버는 언제든 생기고 사라질 수 있는 것이 되었고, 파일 저장소도 특정 서버에 묶이지 않는 독립된 서비스여야 한다는 요구가 강해졌습니다. 동시에 저장해야 할 데이터 종류가 정형 데이터에서 이미지, 동영상, 로그, IoT 센서 데이터까지 넓어지면서, 테이블 구조에 억지로 넣는 것보다 원본 그대로 저장하고 필요할 때 꺼내 쓰는 방식이 더 현실적이 되었습니다. Blob Storage는 이런 압력에 대한 응답으로, 용량 걱정 없이 비정형 데이터를 올리고, 접근 빈도에 따라 비용을 자동 조절하며, HTTP로 어디서든 가져갈 수 있는 독립 스토리지 계층으로 등장했습니다.

Blob Storage는 Storage Account → Container → Blob이라는 세 단계 계층으로 동작합니다. Storage Account는 고유한 도메인 이름을 갖는 최상위 단위로, 접근 키와 네트워크 규칙이 여기에 걸립니다. Container는 파일 시스템의 폴더와 비슷하게 Blob을 논리적으로 묶어주고, 컨테이너 단위로 공개/비공개 접근 정책을 설정할 수 있습니다. Blob 자체는 용도에 따라 세 가지 유형으로 나뉩니다. Block Blob은 이미지, 동영상, 문서처럼 통째로 쓰고 읽는 범용 객체입니다. Append Blob은 로그처럼 끝에만 데이터를 이어 붙이는 패턴에 최적화되어 있어, 여러 소스가 동시에 로그를 쓸 때 효율적입니다. Page Blob은 512바이트 페이지 단위로 랜덤 읽기와 쓰기를 지원해서 VM의 가상 디스크(VHD) 용도로 쓰입니다. 접근 빈도에 따른 비용 문제는 티어 시스템으로 해결합니다. Hot은 자주 읽히는 데이터에, Cool은 30일 이상 보관하되 가끔 읽는 데이터에, Cold는 90일 이상 장기 보관에, Archive는 거의 꺼내지 않는 규제 보관용에 맞춰져 있습니다. 저장 비용은 Hot에서 Archive로 갈수록 낮아지지만, 꺼내는 비용은 반대로 높아집니다. 수명 주기 정책을 설정하면 일정 기간 뒤 자동으로 티어를 내려주거나 삭제할 수 있어, 수동 아카이빙 작업을 없앨 수 있습니다.

Blob Storage와 Azure Files는 둘 다 파일을 저장한다는 점에서 비슷해 보입니다. 하지만 Blob Storage는 HTTP REST API와 SDK로 접근하는 객체 스토리지이고, Azure Files는 SMB/NFS 프로토콜로 마운트하는 네트워크 파일 공유입니다. 기존 애플리케이션이 파일 시스템 경로로 읽고 쓰는 구조라면 Azure Files가 코드 변경 없이 붙일 수 있고, 새로 설계하는 웹 앱이나 데이터 파이프라인처럼 API 기반 접근이 자연스러운 경우에는 Blob Storage가 비용과 확장성 면에서 유리합니다. Blob Storage와 Azure Data Lake Storage Gen2도 혼동되기 쉽습니다. 실제로 Data Lake Storage Gen2는 Blob Storage 위에 계층적 네임스페이스(폴더 구조)를 추가한 것입니다. 파일을 단순히 저장하고 서빙하는 것이 목적이면 일반 Blob Storage로 충분하고, 대규모 분석 워크로드에서 디렉터리 단위 권한 관리나 빠른 메타데이터 연산이 필요하면 계층적 네임스페이스를 켜는 쪽이 맞습니다.

웹 서비스를 운영하면서 사용자 프로필 사진, 첨부 파일, 미디어 콘텐츠를 저장해야 할 때 Blob Storage는 가장 먼저 검토되는 선택지입니다. 앱 서버는 파일을 Blob에 올리고 URL만 데이터베이스에 기록하면 되므로, 서버 디스크를 걱정하지 않고 수평 확장할 수 있습니다. CDN과 결합하면 전 세계 사용자에게 낮은 지연으로 정적 콘텐츠를 배포할 수 있고, SAS 토큰(임시 접근 URL)을 발급하면 인증된 사용자만 제한된 시간 동안 파일에 접근하게 할 수 있습니다. 로그 수집과 데이터 분석에서도 Blob Storage는 자주 등장합니다. 서버 로그, 이벤트 스트림, IoT 센서 데이터를 Append Blob이나 Block Blob으로 쌓아두고, 이후 분석 도구가 필요할 때 읽어가는 데이터 레이크 패턴이 대표적입니다. 수명 주기 정책으로 오래된 데이터를 자동으로 Archive 티어로 내리면 보관 비용을 크게 줄일 수 있습니다. 다만 Blob Storage는 파일 시스템이 아니므로 폴더 안에서 파일을 이동하거나 이름을 바꾸는 작업이 실제로는 복사 후 삭제로 처리됩니다. 디렉터리 단위의 빈번한 조작이 필요하거나, POSIX 파일 시스템 시맨틱이 필요한 워크로드에는 맞지 않습니다. 또한 Archive 티어에서 데이터를 꺼내려면 수 시간의 리하이드레이션이 필요하므로, 즉시 접근이 필요한 데이터를 Archive에 넣으면 운영에 문제가 생깁니다.

다음에 볼 개념

함께 보면 좋은 개념