맨위로가기

오브젝트 스토리지

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

오브젝트 스토리지는 데이터를 객체 단위로 저장하는 데이터 스토리지 아키텍처이다. 짐 스타키가 처음 용어를 만들었으며, 스토리지 추상화, 풍부한 메타데이터, 프로그래밍 방식의 데이터 관리가 특징이다. 1990년대 후반부터 발전하여, 클라우드 스토리지, 객체 기반 파일 시스템, 객체 스토리지 시스템 등 다양한 형태로 구현된다. 아마존 S3, 구글 클라우드 스토리지, 마이크로소프트 Azure Blob 스토리지 등이 대표적이며, Ceph, OpenStack Swift와 같은 오픈 소스 소프트웨어도 존재한다.

더 읽어볼만한 페이지

  • 데이터 관리 소프트웨어 - 데이터 유출 방지
    데이터 유출 방지(DLP)는 기업 및 조직의 중요 정보가 무단 유출되는 것을 막기 위한 기술 및 전략으로, 머신 러닝 등 다양한 보안 조치를 활용해 데이터 유출을 예방하고, 포티넷, 맥아피, 지니언스 등의 업체가 관련 솔루션을 제공한다.
  • 데이터 관리 소프트웨어 - 오픈리파인
    오픈리파인은 데이터 정제 및 변환을 위한 오픈 소스 도구로, 데이터 정리, 변환, 웹사이트 데이터 파싱, 웹 서비스 연동, 위키데이터 정렬 등의 기능을 제공하여 데이터 분석을 용이하게 하고 데이터 과학, 인문학, 저널리즘 등 다양한 분야에서 활용된다.
  • 기억 장치 - EPROM
    EPROM은 자외선을 사용하여 내용을 지울 수 있는 읽기 전용 메모리이며, MOSFET의 부유 게이트를 사용하여 데이터를 저장하고, 펌웨어 업데이트가 용이하여 소량 생산에 사용되었으나 EEPROM과 플래시 메모리에 의해 대체되었다.
  • 기억 장치 - 정적 램
    정적 램(SRAM)은 전원이 공급되는 동안 데이터를 저장하며, 갱신 회로가 필요 없고 빠른 접근 속도를 가지는 휘발성 메모리 유형이다.
  • 파일 시스템 - 부트 섹터
    부트 섹터는 시스템 부팅 코드를 담은 저장 매체의 특정 영역으로, 볼륨 부트 레코드(VBR)와 마스터 부트 레코드(MBR)로 나뉘며, BIOS는 이를 실행하고 UEFI는 부트로더를 직접 로드하지만 바이러스 공격에 취약하다.
  • 파일 시스템 - ZFS
    ZFS는 Jeff Bonwick 등이 설계하고 구현한 파일 시스템으로, 데이터 무결성, 스냅샷, RAID-Z 등의 기능을 제공하며, 썬 마이크로시스템즈에서 개발되어 OpenZFS 프로젝트를 통해 다양한 운영체제에서 사용된다.
오브젝트 스토리지
개요
유형데이터 스토리지 아키텍처
특징데이터를 객체로 관리
주요 특징
설명객체 스토리지는 데이터를 개별적인 단위인 객체로 저장하고 관리한다.
각 객체는 고유한 식별자를 가지며, 메타데이터와 함께 저장된다.
객체 스토리지는 확장성이 뛰어나고, 대용량 데이터를 효율적으로 관리할 수 있다.
주로 비정형 데이터(이미지, 동영상, 문서 등) 저장에 사용된다.
작동 방식
객체 주소 지정파일 시스템의 계층적 구조 대신 플랫 주소 공간을 사용한다.
각 객체는 고유한 식별자(ID)를 통해 접근한다.
메타데이터 관리각 객체는 데이터 외에 메타데이터(생성일, 크기, 유형 등)를 포함한다.
접근 방식HTTP 프로토콜을 통해 객체에 접근한다.
RESTful API를 사용하여 객체를 생성, 읽기, 수정, 삭제할 수 있다.
장점
확장성수평적 확장이 용이하여 대규모 데이터 저장에 적합하다.
비용 효율성사용한 만큼만 비용을 지불하는 종량제 방식으로 운영 비용을 절감할 수 있다.
메타데이터풍부한 메타데이터를 활용하여 데이터 관리 및 검색 효율성을 높일 수 있다.
접근성HTTP 프로토콜을 통해 어디서든 데이터에 접근할 수 있다.
단점
성능블록 스토리지에 비해 낮은 성능을 보일 수 있다.
일관성데이터 일관성 유지에 추가적인 노력이 필요할 수 있다.
사용 사례
클라우드 스토리지아마존 S3, 마이크로소프트 애저 Blob 스토리지, 구글 클라우드 스토리지 등 클라우드 기반 객체 스토리지가 널리 사용된다.
백업 및 아카이브대용량 데이터 백업 및 장기 보관에 적합하다.
콘텐츠 전송 네트워크 (CDN)이미지, 동영상 등 정적 콘텐츠를 효율적으로 전송할 수 있다.
빅데이터대규모 데이터 분석을 위한 데이터 레이크 구축에 활용된다.
비교
블록 스토리지운영체제가 직접 접근하는 물리적 디스크 공간을 제공하며, 높은 성능을 요구하는 데이터베이스, 가상 머신 등에 적합하다.
파일 스토리지계층적 파일 시스템 구조를 제공하며, 네트워크 공유 폴더, NAS 등에 사용된다.
추가 정보
적합한 데이터쓰기가 한 번 일어나고 읽기가 여러 번 일어나는 비정형 데이터에 적합하다 (예: 정적 온라인 콘텐츠, 데이터 백업, 이미지 아카이브, 비디오, 사진, 음악 파일).

2. 역사

1995년, 가스 깁슨이 주도한 네트워크 부착 보안 디스크 연구에서는 네임스페이스 조작과 같이 자주 쓰이지 않는 작업을 읽기 및 쓰기와 같은 일반적인 작업에서 분리하여 성능과 규모를 최적화하는 개념을 처음 제시했다.[6] 같은 해 벨기에 회사인 FilePool이 아카이브 기능 구축을 위해 설립되었다. 1996년에는 깁슨의 카네기 멜론 대학교 연구소에서 오브젝트 스토리지를 연구 프로젝트로 제안했다.[7] 데이터를 유연한 데이터 컨테이너(오브젝트)로 쓰고 읽는 것을 추상화하는 개념도 제시되었다. 오브젝트 스토리지 아키텍처를 통한 세분화된 접근 제어[8]는 NASD 팀의 일원이었으며, 이후 구글 파일 시스템의 발명가 중 한 명이 된 하워드 고비오프가 추가로 설명했다.[9]

1987년에 시작되어 Lustre 파일 시스템을 낳은 Coda 파일 시스템 프로젝트(카네기 멜론 대학교)[10], 1999년에 시작된 캘리포니아 대학교 버클리의 OceanStore 프로젝트[11], 1998년에 시작된 테네시 대학교 녹스빌의 로지스틱 네트워킹 프로젝트[13] 등도 관련된 작업이다. 1999년, 깁슨은 NASD 팀이 개발한 개념을 상업화하기 위해 파나사스를 설립했다.

시게이트 테크놀로지는 오브젝트 스토리지 개발에 핵심적인 역할을 수행했다. 스토리지 네트워킹 산업 협회(SNIA)에 따르면, "오브젝트 스토리지는 1990년대 후반에 시작되었다. 1999년 시게이트 사양은 최초의 몇몇 명령어를 도입했으며, 운영 체제가 스토리지 소비로부터 효과적으로 제거되는 방법을 제시했다."[14]

1999년 10월 25일, 시게이트의 데이브 앤더슨은 "OBJECT BASED STORAGE DEVICES Command Set Proposal"의 예비 버전을 편집하여 제출했다. 이 문서는 국가 스토리지 산업 컨소시엄(NSIC)의 작업 결과였으며, 카네기 멜론 대학교, 시게이트, IBM, 퀀텀 및 스토리지텍의 기여를 포함했다.[15] 이 문서는 국제 정보 기술 표준 위원회(INCITS T-10)에 SCSI 인터페이스 프로토콜 기반 위원회 구성 및 사양 설계를 제안했다. 여기에는 고유 식별자와 메타데이터를 가진 추상화된 데이터로서의 객체, 객체와 파일 시스템의 관련 방식 등 여러 혁신적인 개념이 정의되었다. 앤더슨은 1999년 10월 SNIA 컨퍼런스에서 이러한 아이디어를 발표했다. 이 발표에서는 1997년 2월에 체결된 오브젝트 스토리지, 확장 가능한 컴퓨팅, 플랫폼 독립성 및 스토리지 관리의 이점을 다룬 IP 계약도 공개되었다.[16]

2. 1. 기원

짐 스타키는 디지털 이큅먼트 코퍼레이션에서 일하면서 불투명한 데이터 엔티티를 지칭하기 위해 '''blob'''이라는 용어를 만들었다. 이 용어는 Rdb/VMS에 채택되었다. "Blob"은 종종 "binary large object"의 약자라고 유머러스하게 설명된다. 스타키에 따르면, 이 역두문자어는 아폴로 컴퓨터의 마케팅 부서에서 일하던 테리 맥키버가 이 용어가 약자여야 한다고 느껴서 생겨났다. 맥키버는 "Basic Large Object"라는 확장 용어를 사용하기 시작했다. 이것은 나중에 블롭을 "Binary Large Objects"로 소급 설명하면서 대체되었다. 스타키에 따르면, "블롭은 아무것도 의미하지 않는다." 그는 약어를 거부하며, 용어를 만든 동기를 설명하면서 "블롭은 신시내티, 클리블랜드를 먹어치운 바로 그것입니다."라고 말했다. 1958년 공상 과학 영화 ''블롭''을 언급한 것이다.

1995년, 가스 깁슨이 주도한 네트워크 부착 보안 디스크에 대한 연구는 네임스페이스 조작과 같은 덜 일반적인 작업을 읽기 및 쓰기와 같은 일반적인 작업에서 분리하여 둘 모두의 성능과 규모를 최적화한다는 개념을 처음으로 제시했다.[6] 같은 해, 벨기에 회사인 FilePool이 아카이브 기능의 기반을 구축하기 위해 설립되었다. 오브젝트 스토리지는 깁슨의 카네기 멜론 대학교 연구소에서 1996년에 연구 프로젝트로 제안되었다.[7] 또 다른 핵심 개념은 데이터를 보다 유연한 데이터 컨테이너(오브젝트)로 쓰고 읽는 것을 추상화하는 것이었다. 오브젝트 스토리지 아키텍처를 통한 세분화된 접근 제어[8]는 NASD 팀의 일원이었으며 나중에 구글 파일 시스템의 발명가 중 한 명인 하워드 고비오프에 의해 추가로 설명되었다.[9]

기타 관련 작업으로는 1987년에 시작되어 Lustre 파일 시스템을 낳은 Coda 파일 시스템 프로젝트(카네기 멜론 대학교)가 있다.[10] 또한 1999년에 시작된 캘리포니아 대학교 버클리의 OceanStore 프로젝트[11]와 1998년에 시작된 테네시 대학교 녹스빌의 로지스틱 네트워킹 프로젝트가 있다.[13] 1999년, 깁슨은 NASD 팀이 개발한 개념을 상업화하기 위해 파나사스를 설립했다.

2. 2. 발전

시게이트 테크놀로지는 오브젝트 스토리지 개발에 핵심적인 역할을 했다. 스토리지 네트워킹 산업 협회(SNIA)에 따르면 "오브젝트 스토리지는 1990년대 후반에 시작되었다: 1999년 시게이트 사양은 최초의 몇몇 명령어를 도입했으며 운영 체제가 스토리지 소비로부터 효과적으로 제거되는 방법을 제시했다."[14]

1999년 10월 25일자 "OBJECT BASED STORAGE DEVICES Command Set Proposal"의 예비 버전은 시게이트의 데이브 앤더슨이 편집하여 시게이트에서 제출되었으며, 카네기 멜론 대학교, 시게이트, IBM, 퀀텀 및 스토리지텍의 기여를 포함하여 국가 스토리지 산업 컨소시엄(NSIC)의 작업 결과였다.[15] 이 논문은 SCSI 인터페이스 프로토콜을 기반으로 위원회를 구성하고 사양을 설계하기 위해 국제 정보 기술 표준 위원회(INCITS T-10)에 제안되었다. 이는 고유 식별자와 메타데이터를 가진 추상화된 데이터로서의 객체, 객체가 파일 시스템과 관련된 방식, 그리고 많은 다른 혁신적인 개념들을 정의했다. 앤더슨은 1999년 10월 SNIA 컨퍼런스에서 이러한 아이디어의 많은 부분을 발표했다. 발표는 원래 협력자(시게이트는 앤더슨과 크리스 말라카팔리가 대표) 간에 1997년 2월에 서명된 IP 계약을 공개했으며, 이는 오브젝트 스토리지, 확장 가능한 컴퓨팅, 플랫폼 독립성 및 스토리지 관리의 이점을 다루었다.[16]

3. 아키텍처



오브젝트 스토리지의 장점은 용량 확장성(스케일러빌리티)이다. 페이스북처럼 대량의 사진을 저장하거나[42], 아마존 심플 스토리지 서비스에서 대량의 고객 데이터를 보존하는 데 사용된다. 용량 확장은 스토리지 서버(노드)를 추가하여 무중단으로 할 수 있으며[43], 페타바이트(PB)급으로도 확장이 가능하다. 미국 로스앨러모스 국립 연구소는 500PB의 스토리지로 오브젝트 스토리지를 채택했다[44] .

데이터와 메타데이터를 결합하여 '''오브젝트'''로 취급한다는 점은 오브젝트 스토리지의 특징 중 하나이지만,[47], 리눅스의 파일 시스템인 XFS에도 확장 속성이 있어 속성과 데이터를 하나로 저장하므로[45], 이것만으로는 오브젝트 스토리지라고 할 수 없다. 오브젝트 스토리지는 접근 방법, 데이터 분산 등 아키텍처 전체를 포괄하는 개념이다.

PB급 분산 스토리지 구조로는 Hadoop 분산 파일 시스템 (HDFS)이나 구글 파일 시스템이 있다. 이들은 빅 데이터 처리에 최적화되어 큰 파일 크기(예: 100MB 정도)에 적합한 설계를 가진 반면, 오브젝트 스토리지는 다양한 크기의 파일에 적합하다.[46]

3. 1. 스토리지 추상화

오브젝트 스토리지의 설계 원칙 중 하나는 관리자와 애플리케이션에서 스토리지의 하위 계층 일부를 추상화하는 것이다. 따라서 데이터는 블록 또는 파일 대신 객체로 노출되고 관리된다. 객체에는 더 나은 인덱싱 또는 관리에 사용할 수 있는 추가 설명 속성이 포함된다. 관리자는 디스크 용량을 활용하거나 디스크 오류를 처리하기 위해 RAID 수준을 설정하기 위해 논리 볼륨을 구성하고 관리하는 것과 같은 하위 수준의 스토리지 기능을 수행할 필요가 없다.

오브젝트 스토리지는 또한 파일 이름과 파일 경로 외에 개별 객체를 주소 지정하고 식별할 수 있게 한다. 오브젝트 스토리지는 훨씬 더 큰 네임스페이스를 지원하고 이름 충돌을 제거하기 위해 버킷 내 또는 전체 시스템에서 고유한 식별자를 추가한다.

3. 2. 풍부한 사용자 정의 메타데이터 포함

객체 스토리지는 파일 메타데이터를 데이터와 분리하여 다음과 같은 기능을 제공한다.

  • 애플리케이션 또는 사용자별 정보를 캡처하여 색인 생성을 개선한다.
  • 데이터 관리 정책(예: 객체를 한 스토리지 계층에서 다른 계층으로 이동)을 지원한다.
  • 여러 노드 및 클러스터에서 스토리지 관리를 중앙 집중화한다.
  • 데이터 스토리지(예: 비정형 바이너리 스토리지)와 독립적으로 메타데이터 스토리지(예: 캡슐화된 데이터베이스 또는 키-값 스토리지) 및 캐싱/색인 생성을 최적화한다.


데이터와 메타데이터를 함께 '''오브젝트'''로 취급하며[47], 사용자는 메타데이터를 자유롭게 등록할 수 있다[54]。 예를 들어, 이미지의 메타데이터로 피사체나 장소를 등록하여 검색이나 추출에 이용할 수 있다[55]。

3. 3. 프로그래밍 방식의 데이터 관리

오브젝트 스토리지는 애플리케이션이 데이터를 조작할 수 있도록 프로그래밍 방식의 인터페이스를 제공한다. 기본적으로 여기에는 기본적인 읽기, 쓰기 및 삭제 작업을 위한 생성, 읽기, 업데이트 및 삭제(CRUD) 기능이 포함된다. 일부 오브젝트 스토리지 구현은 더 나아가 객체/파일 버전 관리, 객체 복제, 수명 주기 관리, 그리고 서로 다른 계층 및 유형의 스토리지 간 객체 이동과 같은 추가 기능을 지원한다. 대부분의 API 구현은 REST 기반으로, 많은 표준 HTTP 호출을 사용할 수 있다.[42]

데이터는 고유한 ID(URI)를 가지며, 데이터에 대한 접근은 일반적으로 RESTful API를 통해 이루어진다.[47][48] 오브젝트 스토리지는 웹 브라우저 등의 애플리케이션이 서버에 API 요청을 발행함으로써 접근한다. 명령에는 읽기를 수행하는 '''GET''', 쓰기를 수행하는 '''PUT''' 등이 있다.[49] API와 데이터 ID를 지정함으로써 접근하기 때문에, 파일 서버나 네트워크 연결 스토리지 (NAS)처럼 윈도우의 탐색기 또는 MacOS의 Finder로 접근하기 위해서는 FUSE 어댑터 등을 사용할 필요가 있다.

데이터를 직접 갱신하거나 덮어쓰는 것은 불가능하며,[50] 데이터를 갱신할 때는 새로운 데이터 쓰기와 오래된 데이터 삭제를 조합하여 수행하게 된다.

API는 아마존 웹 서비스 S3 API가 사실상의 표준이라는 의견도 있으며,[51] S3 호환을 표방하는 제품도 있다.

4. 구현

객체 스토리지의 구현은 다양한 방식으로 이루어졌다.
클라우드 스토리지클라우드 스토리지의 대부분은 객체 스토리지 아키텍처를 활용한다. 대표적인 예로는 아마존 웹 서비스 S3(2006년 3월 출시), 마이크로소프트 애저 블롭 스토리지, 랙스페이스 클라우드 파일즈(2010년 코드가 Openstack 프로젝트에 기증되어 OpenStack Swift로 출시됨), 구글 클라우드 스토리지(2010년 5월 출시) 등이 있다.
객체 기반 파일 시스템일부 분산 파일 시스템은 객체 기반 아키텍처를 사용한다. 파일 메타데이터는 메타데이터 서버에 저장되고, 파일 데이터는 오브젝트 스토리지 서버에 저장된다. 파일 시스템 클라이언트 소프트웨어는 개별 서버와 상호 작용하며, 이를 추상화하여 사용자 및 애플리케이션에 완전한 파일 시스템을 제공한다.
객체 스토리지 시스템EMC Centera와 히타치 HCP(이전 HCAP)는 보존을 위해 흔히 언급되는 객체 스토리지 제품이다. 퀀텀 ActiveScale 객체 스토리지 플랫폼도 그 예이다. 2008년부터는 보다 일반적인 용도의 객체 스토리지 시스템이 출시되었다. 웹 애플리케이션 내 "전용" 스토리지 시스템의 성장과 클라우드 스토리지의 초기 성공에 힘입어, 객체 스토리지 시스템은 기업 내 또는 클라우드 스토리지 서비스 제공업체에서 시스템을 배포할 수 있는 기능을 갖춘 클라우드 스토리지의 확장성과 기능을 약속했다.
객체 스토리지의 특징


  • 확장성: 스토리지 서버(노드)를 추가하여 무중단으로 용량 확장이 가능하며[43], 페타바이트(PB)급으로도 확장이 가능하다. 페이스북처럼 대량의 사진을 저장하거나[42], 아마존 심플 스토리지 서비스에서 대량의 고객 데이터를 보존하는 데 사용된다. 미국 로스앨러모스 국립 연구소는 500PB의 스토리지를 채택했다.[44]
  • 데이터와 메타데이터의 결합: 데이터와 메타데이터를 결합하여 '오브젝트'로 취급한다.[47] 사용자는 메타데이터를 자유롭게 등록하여 검색이나 추출에 활용할 수 있다.[54][55]
  • 아키텍처: 리눅스의 파일 시스템인 XFS에도 '확장 속성'이 있어 속성과 데이터를 하나로 저장하지만[45], 이것만으로는 오브젝트 스토리지라고 부르지 않는다. 접근 방법이나 데이터 분산 등 아키텍처 전체를 포함하여 이해해야 한다.
  • 파일 크기: Hadoop 분산 파일 시스템 (HDFS)나 구글 파일 시스템과 같은 PB급 분산 스토리지 구조는 빅 데이터 처리에 적합한 큰 파일 크기에 최적화된 설계인 반면, 오브젝트 스토리지는 어떤 크기에도 적합한 설계로 여겨진다.[46]
  • 접근 방식: 데이터는 고유한 ID(URI)를 가지며[47], 일반적으로 RESTful API를 통해 접근한다.[47][48] 웹 브라우저 등의 애플리케이션은 서버에 API 요청을 발행하여 오브젝트 스토리지에 접근하며, 'GET'(읽기), 'PUT'(쓰기) 등의 명령을 사용한다.[49] 파일 서버나 네트워크 연결 스토리지(NAS)처럼 윈도우 탐색기나 MacOS Finder로 접근하려면 FUSE 어댑터 등을 사용해야 한다.
  • 데이터 갱신: 데이터를 직접 갱신하거나 덮어쓰는 것은 불가능하며[50], 데이터를 갱신할 때는 새로운 데이터를 쓰고 오래된 데이터를 삭제하는 방식으로 처리한다.
  • 표준 API: 아마존 웹 서비스 S3 API가 사실상의 표준으로 여겨지며[51], S3 호환을 표방하는 제품도 있다.
  • 데이터 저장: 오브젝트 스토리지는 디렉터리가 없고[47] 플랫한 공간에 데이터를 저장하며, 이 공간을 '버킷' 또는 '컨테이너'라고 부른다.[52][48]
  • 고가용성: 같은 데이터를 여러 스토리지에 분산하여 기록(레플리케이션)하므로[53], RAID 등의 고가용성 기술을 별도로 준비할 필요가 없다. 용량 효율을 높인 이레이저 코딩이 구현된 오브젝트 스토리지도 있다.[53]

통합 파일 및 객체 스토리지일부 오브젝트 스토리지 시스템은 통합 파일 및 오브젝트 스토리지를 지원하여, 클라이언트가 스토리지 시스템에 객체를 저장하는 동시에 다른 클라이언트가 동일한 스토리지 시스템에 파일을 저장할 수 있도록 한다.[17] 하이브리드 클라우드 스토리지 분야의 다른 공급업체들은 클라우드 스토리지 게이트웨이를 사용하여 오브젝트 스토리지에 파일 접근 계층을 제공하고, SMB 및 NFS와 같은 파일 접근 프로토콜을 구현하고 있다.
"Captive" 객체 스토리지일부 대형 인터넷 기업들은 객체 스토리지 제품이 상용화되지 않았거나 사용 사례가 매우 구체적일 때 자체 소프트웨어를 개발했다. 페이스북은 자사의 대규모 사진 관리 요구 사항을 효율적으로 해결하기 위해 자체 객체 스토리지 소프트웨어인 "Haystack"을 개발한 것으로 유명하다.[18]
객체 기반 스토리지 장치가스 깁슨이 주도한 네트워크 부착 보안 디스크에 대한 1995년 연구는 네임스페이스 조작과 같은 덜 일반적인 작업을 읽기 및 쓰기와 같은 일반적인 작업에서 분리하여 둘 모두의 성능과 규모를 최적화한다는 개념을 처음으로 제시했다.[6] 1996년에는 깁슨의 카네기 멜론 대학교 연구소에서 오브젝트 스토리지를 연구 프로젝트로 제안했다.[7] 데이터를 보다 유연한 데이터 컨테이너(오브젝트)로 쓰고 읽는 것을 추상화하는 것도 핵심 개념이었다. 오브젝트 스토리지 아키텍처를 통한 세분화된 접근 제어[8]는 NASD 팀의 일원이었으며 나중에 구글 파일 시스템의 발명가 중 한 명인 하워드 고비오프에 의해 추가로 설명되었다.[9]

시게이트 테크놀로지(Seagate Technology)는 오브젝트 스토리지 개발에 핵심적인 역할을 했다. 스토리지 네트워킹 산업 협회(SNIA)에 따르면 "오브젝트 스토리지는 1990년대 후반에 시작되었다: 1999년 시게이트 사양은 최초의 몇몇 명령어를 도입했으며 운영 체제가 스토리지 소비로부터 효과적으로 제거되는 방법을 제시했다."[14]

1999년 10월 25일, 시게이트의 데이브 앤더슨은 "OBJECT BASED STORAGE DEVICES Command Set Proposal"의 예비 버전을 편집하여 국가 스토리지 산업 컨소시엄(NSIC)의 작업 결과를 국제 정보 기술 표준 위원회(INCITS T-10)에 제안했다. 이 제안에는 카네기 멜론 대학교, 시게이트, IBM, 퀀텀 및 스토리지텍의 기여가 포함되었다.[15] 이 문서는 고유 식별자와 메타데이터를 가진 추상화된 데이터로서의 객체, 객체가 파일 시스템과 관련된 방식, 그리고 많은 다른 혁신적인 개념들을 정의했다. 앤더슨은 1999년 10월 SNIA 컨퍼런스에서 이러한 아이디어의 많은 부분을 발표했다.[16]

오브젝트 스토리지 장치를 위한 SCSI 명령 집합은 국제 정보 기술 표준 위원회(INCITS)의 T10 위원회를 위해 SNIA의 워킹 그룹에 의해 개발되었다.[22] T10은 모든 SCSI 표준을 담당한다.

컴퓨터 네트워크에서 스토리지를 구성하는 기술에는 스토리지 영역 네트워크(SAN)도 있다. 오브젝트 스토리지는 SAN에서 사용되는 고가의 파이버 채널을 이용하지 않는다. 스토리지 장치도 저속이지만 대용량・저가격의 SATA HDD를 활용하는 등[57], '''상용 하드웨어의 활용'''이 설계 사상이다. 실제로 스토리지 노드 간은 TCP/IP로 통신하며, SCSI 프로토콜은 사용되지 않는다. 이러한 이유로 스토리지는 HDD, 네트워크는 이더넷이다. 파이버 채널이나 테이프 장치는 주류라고 할 수 없다.

4. 1. 클라우드 스토리지

시장에서 사용 가능한 클라우드 스토리지의 대부분은 객체 스토리지 아키텍처를 활용한다. 주목할 만한 예로는 2006년 3월에 출시된 아마존 웹 서비스 S3(AWS S3), 마이크로소프트 애저 블롭 스토리지, 랙스페이스 클라우드 파일즈(2010년에 코드가 Openstack 프로젝트에 기증되어 OpenStack Swift로 출시됨), 2010년 5월에 출시된 구글 클라우드 스토리지가 있다.

4. 2. 객체 기반 파일 시스템

일부 분산 파일 시스템은 객체 기반 아키텍처를 사용하며, 파일 메타데이터는 메타데이터 서버에 저장되고 파일 데이터는 오브젝트 스토리지 서버에 저장된다. 파일 시스템 클라이언트 소프트웨어는 개별 서버와 상호 작용하고, 이를 추상화하여 사용자 및 애플리케이션에 완전한 파일 시스템을 제공한다.

4. 3. 객체 스토리지 시스템

EMC Centera와 히타치 HCP(이전 HCAP)는 보존을 위해 흔히 언급되는 객체 스토리지 제품이다. 퀀텀 ActiveScale 객체 스토리지 플랫폼도 그 예이다.

2008년부터는 보다 일반적인 용도의 객체 스토리지 시스템이 출시되었다. 웹 애플리케이션 내 "전용" 스토리지 시스템의 성장과 클라우드 스토리지의 초기 성공에 힘입어, 객체 스토리지 시스템은 기업 내 또는 클라우드 스토리지 서비스 제공업체에서 시스템을 배포할 수 있는 기능을 갖춘 클라우드 스토리지의 확장성과 기능을 약속했다. 용량 확장성(스케일러빌리티)이 장점으로, 페이스북처럼 대량의 사진을 저장하거나[42], 아마존 심플 스토리지 서비스에서 대량의 고객 데이터를 보존한다. 스토리지 서버(노드)를 추가하여 무중단으로 용량 확장이 가능하며[43], 페타바이트(PB)급으로도 확장이 가능하다. 미국 로스앨러모스 국립 연구소는 500PB의 스토리지를 채택했다.[44]

오브젝트 스토리지는 데이터와 메타데이터를 결합하여 '''오브젝트'''로 취급한다[47]는 특징이 있다. 그러나 리눅스의 파일 시스템인 XFS에도 '''확장 속성'''이 있어 속성과 데이터를 하나로 저장하지만[45], 이것만으로는 오브젝트 스토리지라고 부르지 않는다. 접근 방법이나 데이터 분산 등 아키텍처 전체를 포함하여 이해해야 한다.

PB급 분산 스토리지 구조에는 Hadoop 분산 파일 시스템 (HDFS)나 구글 파일 시스템이 있다. 이들은 빅 데이터 처리에 적합한 큰 파일 크기에 최적화된 설계인 반면, 오브젝트 스토리지는 어떤 크기에도 적합한 설계로 여겨진다[46] .

데이터는 고유한 ID(URI)를 가지며[47], 일반적으로 RESTful API를 통해 접근한다[47][48]。웹 브라우저 등의 애플리케이션은 서버에 API 요청을 발행하여 오브젝트 스토리지에 접근하며, '''GET'''(읽기), '''PUT'''(쓰기) 등의 명령을 사용한다[49]。API와 데이터 ID를 지정하여 접근하므로, 파일 서버나 네트워크 연결 스토리지(NAS)처럼 윈도우 탐색기나 MacOS Finder로 접근하려면 FUSE 어댑터 등을 사용해야 한다.

데이터를 직접 갱신하거나 덮어쓰는 것은 불가능하며[50], 데이터를 갱신할 때는 새로운 데이터를 쓰고 오래된 데이터를 삭제하는 방식으로 처리한다.

아마존 웹 서비스 S3 API가 사실상의 표준으로 여겨지며[51], S3 호환을 표방하는 제품도 있다. 오브젝트 스토리지는 디렉터리가 없고[47] 플랫한 공간에 데이터를 저장하며, 이 공간을 '''버킷''' 또는 '''컨테이너'''라고 부른다[52][48]。 버킷은 여러 개를 사용할 수 있다.

같은 데이터를 여러 스토리지에 분산하여 기록(레플리케이션)하므로[53], RAID 등의 고가용성 기술을 별도로 준비할 필요가 없다. 용량 효율을 높인 이레이저 코딩이 구현된 오브젝트 스토리지도 있다[53]。

데이터와 메타데이터는 함께 '''오브젝트'''가 되며, 사용자는 메타데이터를 자유롭게 등록할 수 있다[54]。 예를 들어, 이미지의 메타데이터로 피사체나 장소를 등록하여 검색이나 추출에 사용할 수 있다[55]。

4. 4. 통합 파일 및 객체 스토리지

일부 오브젝트 스토리지 시스템은 통합 파일 및 오브젝트 스토리지를 지원하여, 클라이언트가 스토리지 시스템에 객체를 저장하는 동시에 다른 클라이언트가 동일한 스토리지 시스템에 파일을 저장할 수 있도록 한다.[17] 하이브리드 클라우드 스토리지 분야의 다른 공급업체들은 클라우드 스토리지 게이트웨이를 사용하여 오브젝트 스토리지에 파일 접근 계층을 제공하고, SMB 및 NFS와 같은 파일 접근 프로토콜을 구현하고 있다.

4. 5. "Captive" 객체 스토리지

일부 대형 인터넷 기업들은 객체 스토리지 제품이 상용화되지 않았거나 사용 사례가 매우 구체적일 때 자체 소프트웨어를 개발했다. 페이스북은 자사의 대규모 사진 관리 요구 사항을 효율적으로 해결하기 위해 자체 객체 스토리지 소프트웨어인 "Haystack"을 개발한 것으로 유명하다.[18]

4. 6. 객체 기반 스토리지 장치

가스 깁슨이 주도한 네트워크 부착 보안 디스크에 대한 1995년 연구는 네임스페이스 조작과 같은 덜 일반적인 작업을 읽기 및 쓰기와 같은 일반적인 작업에서 분리하여 둘 모두의 성능과 규모를 최적화한다는 개념을 처음으로 제시했다.[6] 1996년에는 깁슨의 카네기 멜론 대학교 연구소에서 오브젝트 스토리지를 연구 프로젝트로 제안했다.[7] 데이터를 보다 유연한 데이터 컨테이너(오브젝트)로 쓰고 읽는 것을 추상화하는 것도 핵심 개념이었다. 오브젝트 스토리지 아키텍처를 통한 세분화된 접근 제어[8]는 NASD 팀의 일원이었으며 나중에 구글 파일 시스템의 발명가 중 한 명인 하워드 고비오프에 의해 추가로 설명되었다.[9]

시게이트 테크놀로지(Seagate Technology)는 오브젝트 스토리지 개발에 핵심적인 역할을 했다. 스토리지 네트워킹 산업 협회(SNIA)에 따르면 "오브젝트 스토리지는 1990년대 후반에 시작되었다: 1999년 시게이트 사양은 최초의 몇몇 명령어를 도입했으며 운영 체제가 스토리지 소비로부터 효과적으로 제거되는 방법을 제시했다."[14]

1999년 10월 25일, 시게이트의 데이브 앤더슨은 "OBJECT BASED STORAGE DEVICES Command Set Proposal"의 예비 버전을 편집하여 국가 스토리지 산업 컨소시엄(NSIC)의 작업 결과를 국제 정보 기술 표준 위원회(INCITS T-10)에 제안했다. 이 제안에는 카네기 멜론 대학교, 시게이트, IBM, 퀀텀 및 스토리지텍의 기여가 포함되었다.[15] 이 문서는 고유 식별자와 메타데이터를 가진 추상화된 데이터로서의 객체, 객체가 파일 시스템과 관련된 방식, 그리고 많은 다른 혁신적인 개념들을 정의했다. 앤더슨은 1999년 10월 SNIA 컨퍼런스에서 이러한 아이디어의 많은 부분을 발표했다.[16]

오브젝트 스토리지 장치를 위한 SCSI 명령 집합은 국제 정보 기술 표준 위원회(INCITS)의 T10 위원회를 위해 SNIA의 워킹 그룹에 의해 개발되었다.[22] T10은 모든 SCSI 표준을 담당한다.

컴퓨터 네트워크에서 스토리지를 구성하는 기술에는 스토리지 영역 네트워크(SAN)도 있다. 오브젝트 스토리지는 SAN에서 사용되는 고가의 파이버 채널을 이용하지 않는다. 스토리지 장치도 저속이지만 대용량・저가격의 SATA HDD를 활용하는 등[57], '''상용 하드웨어의 활용'''이 설계 사상이다. 실제로 스토리지 노드 간은 TCP/IP로 통신하며, SCSI 프로토콜은 사용되지 않는다. 이러한 이유로 스토리지는 HDD, 네트워크는 이더넷이다. 파이버 채널이나 테이프 장치는 주류라고 할 수 없다.

5. 시장 채택

오브젝트 스토리지는 2000년대 초반, 특히 사베인스-옥슬리법과 같은 규정 준수 법률 시행 이후 아카이브 플랫폼으로 널리 채택되었다.

5. 1. 현재 시장 현황

Lustre는 최초의 객체 스토리지 제품 중 하나로, 상위 100대 슈퍼컴퓨터의 70%와 Top 500의 약 50%에서 사용된다.[23] 2013년 6월 16일 기준으로, 상위 10개 시스템 중 7개가 여기에 포함되며, 여기에는 중국의 톈허-2(4위)와 오크리지 국립 연구소의 타이탄 슈퍼컴퓨터(7위)가 있다.[24]

객체 스토리지 시스템은 2000년대 초반, 특히 사베인스-옥슬리법과 같은 규정 준수 법률 이후 아카이브 플랫폼으로 널리 채택되었다. EMC의 Centera 제품은 시장 출시 5년 만인 2007년까지 3,500개 이상의 고객과 150PB를 출하했다고 주장했다.[25] 히타치의 HCP 제품 또한 많은 페타바이트 규모의 고객을 확보하고 있다고 한다.[26]

새로운 객체 스토리지 시스템도 인기를 얻고 있는데, 특히 이베이와 같은 대규모 사용자 지정 애플리케이션에서 EMC Atmos가 하루에 5억 개 이상의 객체를 관리하는 데 사용된다.[27] 2014년 3월 3일 기준으로 EMC는 1.5EB 이상의 Atmos 스토리지를 판매했다고 주장한다.[28] 2014년 7월 1일, 로스알라모스 국립 연구소는 Scality RING을 500PB 스토리지 환경의 기반으로 선택했는데, 이는 역대 최대 규모에 속한다.[29]

페이스북의 Haystack과 같은 "독점" 객체 스토리지 시스템은 놀라운 속도로 확장되었다. 2009년 4월, Haystack은 600억 개의 사진과 1.5PB의 스토리지를 관리하고 있었으며, 매주 2억 2천만 개의 사진과 25테라바이트를 추가했다.[18] 페이스북은 최근 하루에 3억 5천만 개의 사진을 추가하고 있으며 2,400억 개의 사진을 저장하고 있다고 밝혔다.[30] 이는 최대 357PB에 해당할 수 있다.[31]

클라우드 스토리지는 많은 새로운 웹 및 모바일 애플리케이션이 이진 데이터를 저장하는 일반적인 방법으로 선택하면서 널리 보급되었다.[32] Smugmug 및 Dropbox와 같은 많은 인기 애플리케이션의 스토리지 백엔드인 Amazon S3는 2013년 4월에 2조 개 이상의 객체를 저장하면서 엄청난 규모로 성장했다.[33] 두 달 후, 마이크로소프트는 Azure에 8조 5천억 개로 더 많은 객체를 저장했다고 주장했다.[34] 2014년 4월까지 Azure는 20조 개 이상의 객체를 저장했다고 주장했다.[35] Windows Azure Storage는 Blob(사용자 파일), Table(구조화된 스토리지) 및 Queue(메시지 전달)를 관리하며 이들을 모두 객체로 간주한다.[36]

6. 표준

현재 표준으로 사용되는 오브젝트 스토리지 장치(OSD)에는 두 가지 주요 버전이 있다.
OSD 버전 1[38]은 64비트 파티션 ID와 64비트 객체 ID를 사용하여 객체를 식별한다. 파티션은 OSD 내에서 생성 및 삭제되며, 객체는 파티션 내에서 생성 및 삭제된다. 파티션이나 객체의 크기는 고정되어 있지 않고 장치의 물리적 용량이나 파티션에 할당된 용량에 따라 달라진다. 객체는 확장 가능한 속성 집합으로 표현된다. 일부 속성은 OSD에 의해 직접 구현되며(예: 객체 크기, 수정 시간), 보안 관련 특수 속성도 있다. 상위 수준 스토리지 시스템에서 객체 분류, 객체 간 관계 표현 등을 위해 사용하는 속성도 있다. `list` 명령은 파티션 내 객체 ID 목록을 반환하며, 속성 값으로 필터링할 수 있다. 읽기/쓰기 명령은 속성 가져오기/설정 명령과 함께 사용되어 효율성을 높일 수 있다.
OSD 버전 2[39]는 OSD 명령 세트의 2세대로, 스냅샷, 객체 모음, 향상된 오류 처리 기능을 추가로 지원한다. 스냅샷은 특정 시점의 파티션 내 모든 객체를 새로운 파티션으로 복사하는 기능이다. 쓰기 시 복사 기술을 사용하여 효율적인 공간 사용이 가능하다. 객체 모음은 다른 객체의 식별자를 포함하는 특수한 객체로, 모음에 객체를 추가/삭제하거나, 모음 내 모든 객체의 속성을 가져오거나 설정할 수 있다. 오류 보고에도 사용된다. 미디어 결함이나 소프트웨어 오류로 손상된 객체는 특수 오류 모음에 포함되어 상위 수준 스토리지 시스템에서 수정 조치를 취할 수 있다.

6. 1. 객체 기반 스토리지 장치 표준

객체 기반 스토리지 장치(OSD) 표준은 크게 두 가지 버전으로 나뉜다.
OSD 버전 1[38]

  • 객체는 64비트 파티션 ID와 64비트 객체 ID로 지정된다.
  • 파티션은 OSD 내에서 생성 및 삭제되며, 객체는 파티션 내에서 생성 및 삭제된다.
  • 파티션이나 객체의 크기는 고정되어 있지 않으며, 장치의 물리적 크기 제한이나 파티션의 논리적 할당량 제약에 따라 달라진다.
  • 객체는 확장 가능한 속성 집합으로 설명된다.
  • 일부 속성(객체의 바이트 수, 수정 시간 등)은 OSD에 의해 직접 구현된다.
  • 보안 메커니즘의 일부인 특수한 정책 태그 속성도 존재한다.
  • OSD에 의해 해석되지 않는 속성은 상위 수준 스토리지 시스템에서 객체 분류, 객체 간 관계 캡처 등에 사용된다.
  • `list` 명령은 파티션 내 객체 식별자 목록을 반환하며, 속성 값 기준으로 필터링할 수 있다.
  • 읽기/쓰기 명령은 속성 가져오기/설정 명령과 결합하여 사용할 수 있어 효율성을 높인다.

OSD 버전 2[39]

OSD 명령 세트의 2세대로, 다음과 같은 기능을 추가로 지원한다.

  • 스냅샷: 특정 시점의 파티션 내 모든 객체를 새로운 파티션으로 복사한다. 쓰기 시 복사 기술을 사용하여 효율적인 공간 사용이 가능하다.
  • 객체 모음: 다른 객체의 식별자를 포함하는 특수한 객체로, 모음에 객체를 추가/삭제하거나, 모음 내 모든 객체의 속성을 가져오거나 설정할 수 있다. 오류 보고에도 사용된다.
  • 향상된 오류 처리: 미디어 결함이나 소프트웨어 오류로 손상된 객체는 특수 오류 모음에 포함되어 상위 수준 스토리지 시스템에서 수정 조치를 취할 수 있다.

6. 1. 1. OSD 버전 1

OSD 표준의 첫 번째 버전[38]에서 객체는 64비트 파티션 ID와 64비트 객체 ID로 지정된다. 파티션은 OSD 내에서 생성 및 삭제되며, 객체는 파티션 내에서 생성 및 삭제된다. 파티션이나 객체와 관련된 고정된 크기는 없으며, 장치의 물리적 크기 제한 또는 파티션의 논리적 할당량 제약에 따라 크기가 커질 수 있다.

확장 가능한 속성 집합이 객체를 설명한다. 일부 속성은 객체의 바이트 수와 객체의 수정 시간과 같이 OSD에 의해 직접 구현된다. 보안 메커니즘의 일부인 특수한 정책 태그 속성이 있다. 다른 속성은 OSD에 의해 해석되지 않는다. 이러한 속성은 영구 스토리지를 위해 OSD를 사용하는 상위 수준의 스토리지 시스템에서 객체에 설정된다. 예를 들어, 속성은 객체를 분류하거나 다른 OSD에 저장된 서로 다른 객체 간의 관계를 캡처하는 데 사용될 수 있다.

`list` 명령은 파티션 내의 객체에 대한 식별자 목록을 반환하며, 선택적으로 속성 값에 대한 일치를 기준으로 필터링된다. `list` 명령은 나열된 객체의 선택된 속성을 반환할 수도 있다.

읽기 및 쓰기 명령은 속성을 가져오고 설정하는 명령과 결합하거나 함께 사용할 수 있다. 이 기능을 통해 상위 수준의 스토리지 시스템이 OSD에 대한 인터페이스를 넘나드는 횟수를 줄일 수 있으며, 이는 전반적인 효율성을 향상시킬 수 있다.

6. 1. 2. OSD 버전 2

"객체 기반 스토리지 장치 - 2"(OSD-2)는 OSD 명령 세트의 2세대로, 스냅샷, 객체 모음, 향상된 오류 처리 기능을 지원한다.[39]

스냅샷은 특정 시점에 파티션 내의 모든 객체를 새로운 파티션으로 복사한 것이다. OSD는 쓰기 시 복사 기술을 사용하여 효율적으로 공간을 사용하는 복사를 구현할 수 있다. 이를 통해 두 파티션은 스냅샷 사이에 변경되지 않은 객체를 공유하거나, OSD가 데이터를 새 파티션으로 물리적으로 복사할 수 있다. 이 표준은 쓰기 가능한 복제본과 읽기 전용 스냅샷을 정의한다.

모음은 다른 객체의 식별자를 포함하는 특수한 종류의 객체이다. 모음에 객체를 추가하고 삭제하는 작업이 있으며, 모음 내의 모든 객체에 대한 속성을 가져오거나 설정하는 작업도 있다. 모음은 오류 보고에도 사용된다. 객체가 미디어 결함(예: 디스크의 불량 지점)이나 OSD 구현 내의 소프트웨어 오류로 인해 손상된 경우, 해당 객체의 식별자는 특수 오류 모음에 들어간다. OSD를 사용하는 상위 수준 스토리지 시스템은 이 모음을 조회하여 필요에 따라 수정 조치를 취할 수 있다.

7. 키-값 스토어와의 차이점

키-값 스토어와 객체 스토어 사이의 경계는 모호하며, 키-값 스토어가 때때로 객체 스토어라고도 불린다.

키-값 스토어에서 데이터는 논리 블록 번호(LBN)가 아닌 키로 식별된다. 키는 "cat", "olive", "42"와 같이 임의의 바이트 시퀀스일 수 있다. 데이터(값)는 고정 크기일 필요가 없으며 임의의 길이의 바이트 시퀀스일 수도 있다. 키와 값을 데이터 스토어에 제공하여 데이터를 저장하고, 나중에 키를 제공하여 데이터를 검색할 수 있다. 이 개념은 프로그래밍 언어에서 딕셔너리(Python), 해시(Perl), 맵(Java, Rust, C++) 등으로 불린다. Memcached, Redis, CouchDB와 같은 여러 데이터 스토어도 키-값 스토어를 구현한다.

객체 스토어는 두 가지 측면에서 키-값 스토어와 유사하다. 첫째, 객체 식별자 또는 URL (키에 해당)은 임의의 문자열일 수 있다.[40] 둘째, 데이터는 임의의 크기일 수 있다.

그러나 키-값 스토어와 객체 스토어 간에는 몇 가지 주요 차이점이 있다.


  • 객체 스토어는 각 데이터 조각과 함께 제한된 속성 집합(메타데이터)을 연결할 수 있다. 키, 값, 속성 집합의 조합을 객체라고 한다.
  • 객체 스토어는 대량의 데이터(수백 메가바이트 또는 기가바이트)에 최적화되어 있지만, 키-값 스토어의 경우 값은 비교적 작을 것(킬로바이트)으로 예상된다.
  • 객체 스토어는 일반적으로 결과적 일관성과 같은 약한 일관성 보장을 제공하는 반면, 키-값 스토어는 강력한 일관성을 제공한다.

8. 장점 및 단점

오브젝트 스토리지는 장점과 단점을 모두 가지고 있다.

'''장점'''으로는 뛰어난 용량 확장성을 들 수 있다. 페이스북과 같이 대량의 사진을 저장하거나 아마존 심플 스토리지 서비스처럼 대규모 데이터를 보관하는 데 용이하다. 스토리지 서버(노드)를 추가하여 무중단으로 용량을 확장할 수 있으며, 페타바이트(PB)급 확장도 가능하다. 데이터와 메타데이터를 함께 묶어 오브젝트로 관리하고, 사용자가 메타데이터를 자유롭게 추가할 수 있어 데이터 검색 및 추출이 용이하다. 또한, 데이터를 여러 스토리지에 분산하여 저장(레플리케이션)하므로 RAID 등의 별도의 고가용성 기술이 필요하지 않다.[53]

'''단점'''으로는 기존 애플리케이션과의 호환성 문제가 있다. 오브젝트 스토리지를 사용하려면 API 지원 등 애플리케이션 변경이 필요하다. 또한, 데이터의 부분적인 읽기/쓰기가 불가능하여 잦은 업데이트가 필요한 데이터베이스나 빠른 입출력이 필요한 트랜잭션 처리에는 부적합하다.[56] 백업, 아카이브, 서버 로그 저장 등에는 문제가 없다.

8. 1. 장점

페이스북처럼 대량의 사진을 저장하거나[42], 아마존 심플 스토리지 서비스에서 대량의 고객 데이터를 보존하는 것과 같이 용량 확장성(스케일러빌리티)이 장점이다. 용량 확장은 스토리지 서버(노드)를 추가하여 무중단으로 할 수 있다[43] . 페타바이트(PB)급으로도 확장이 가능하며, 미국 로스앨러모스 국립 연구소는 500 PB의 스토리지로 채택했다[44] .

오브젝트 스토리지는 데이터와 메타데이터를 결합하여 '''오브젝트'''로 취급한다는 특징이 있다[47] . 그러나 이는 오브젝트 스토리지의 일부 특징일 뿐이며, 리눅스의 파일 시스템인 XFS의 '''확장 속성'''처럼 속성과 데이터를 하나로 저장하는 것만으로는 오브젝트 스토리지라고 부르지 않는다. 오브젝트 스토리지는 접근 방법, 데이터 분산 등의 아키텍처 전체를 포괄하는 개념이다.

PB급 분산 스토리지 구조로는 Hadoop 분산 파일 시스템 (HDFS)나 구글 파일 시스템이 있다. 이들은 빅 데이터 처리에 최적화되어 큰 파일 크기에 적합한 설계(파일이 100 MB 정도의 크기로 세분화되어 저장되는 등)를 가진 반면, 오브젝트 스토리지는 어떤 크기의 파일에도 적합한 설계로 여겨진다[46] . 오브젝트 스토리지는 디렉터리를 가지지 않고[47] 플랫한 공간에 데이터를 저장하며, 이 공간은 '''버킷''' 또는 '''컨테이너'''라고 불린다[52][48]。 버킷은 여러 개 존재할 수 있다.

같은 데이터를 여러 스토리지에 분산하여 기록(레플리케이션)하므로[53], RAID와 같은 고가용성 기술을 별도로 준비하지 않아도 된다. 용량 효율을 높인 이레이저 코딩이 구현된 오브젝트 스토리지도 존재한다[53]。

데이터와 메타데이터는 함께 '''오브젝트'''로 묶이며, 메타데이터는 사용자가 자유롭게 등록할 수 있다[54]。 예를 들어, 이미지의 메타데이터로 피사체나 장소를 등록하여 검색이나 추출에 이용할 수 있다[55]。

8. 2. 단점

오브젝트 스토리지는 기존 애플리케이션의 변경, 특히 API 지원이 필수적이다. 또한, 데이터의 부분적인 읽기 및 쓰기가 불가능하기 때문에 빈번한 부분 업데이트가 필요한 데이터베이스나 고속 I/O의 트랜잭션에는 적합하지 않다.[56] 백업, 아카이브, 서버 로그 저장 등에는 문제가 없다.

9. 구성 요소

오브젝트 스토리지는 주로 프록시 노드와 스토리지 노드로 구성된다.[57] 부하 분산을 위해 로드 밸런서를 이용하는 경우도 있다.

9. 1. 프록시 노드

서버 구성의 예


프록시 노드와 스토리지 노드는 오브젝트 스토리지 서버 구성의 주요 요소이다.[57] 로드 밸런서는 부하 분산을 위해 사용되기도 한다. 프록시 노드는 API 제공 및 요청을 관리하며,[58] 클라이언트로부터 API 요청을 받아 스토리지 노드로 명령을 전달한다. 또한 데이터가 저장된 노드의 위치를 관리하는데, OpenStack Swift에서는 "Ring"이라는 알고리즘이 사용된다.[58] 프록시 노드는 클라이언트 측의 공용 네트워크(LAN) 단자와 스토리지 노드 측의 사설 네트워크 단자를 모두 가지고 있다.

9. 2. 스토리지 노드



스토리지 노드는 실제로 데이터를 저장한다. 프록시 노드의 사설 네트워크 쪽에 연결되며, 일반적으로 가용성을 높이기 위해 여러 대의 노드로 구성된다.[57] 객체 스토리지는 API로 접근하지만, 이는 클라이언트가 스토리지 전체를 바라볼 때이고, 스토리지 노드 단위에서는 최종적으로 객체가 기존의 파일 시스템에 저장된다. 이때 XFS와 같이 데이터 속성을 유지할 수 있는 파일 시스템을 이용한다.[58]

10. 구현 예시

구현 예시는 다음과 같다.

분류내용
퍼블릭 클라우드 서비스
오픈 소스 소프트웨어
클로즈드 소스 소프트웨어


10. 1. 퍼블릭 클라우드 서비스

10. 2. 오픈 소스 소프트웨어

10. 3. 클로즈드 소스 소프트웨어

참조

[1] 논문 Storage area networking - Object-based storage 2003-08
[2] 웹사이트 Object Storage versus Block Storage: Understanding the Technology Differences http://www.druva.com[...] Druva 2014-08-14
[3] 웹사이트 Block Storage vs. Object Storage vs. File Storage: What's the Difference? https://qumulo.com/b[...] Qumulo 2022
[4] 웹사이트 Critical Capabilities for Object Storage http://www.gartner.c[...] 2014-02-11
[5] 웹사이트 The true story of BLOBs https://www.ibphoeni[...] 1997-01-22
[6] 웹사이트 File Server Scaling with Network-Attached Secure Disks http://www.pdl.cmu.e[...] Proceedings of the ACM International Conference on Measurement and Modeling of Computer Systems (Sigmetrics '97)
[7] CiteSeerX Object Storage: The Future Building Block for Storage Systems
[8] 웹사이트 Security for Network Attached Storage Devices (CMU-CS-97-185) http://repository.cm[...] Parallel Data Laboratory 1997-10-01
[9] 웹사이트 The Google File System http://research.goog[...] 2003-10
[10] 웹사이트 Lustre: The intergalactic file system http://ols.fedorapro[...]
[11] 웹사이트 OceanStore http://oceanstore.cs[...]
[12] 서적 Proceedings of the ninth international conference on Architectural support for programming languages and operating systems 2000
[13] 논문 The Internet Backplane Protocol: Storage in the Network http://web.eecs.utk.[...] 1999-10
[14] 간행물 Object Storage: What, How and Why? https://www.snia.org[...] NSF (Networking Storage Forum), SNIA (Storage Networking Industry Association) 2020-02-19
[15] 웹사이트 Object based storage devices: a command set proposal https://www.t10.org/[...] 1999
[16] 간행물 Object Based Storage: A Vision https://www.t10.org/[...] Dave Anderson and Seagate Technology 1999-10-13
[17] 웹사이트 Unified file and object storage: The best of both worlds? https://www.computer[...] 2020-10-23
[18] 웹사이트 Needle in a haystack: efficient storage of billions of photos https://engineering.[...] 2009-04-30
[19] 웹사이트 Object Storage and Applications https://www.usenix.o[...] 2007-02
[20] 웹사이트 The Seagate Kinetic Open Storage Vision http://www.seagate.c[...] Seagate
[21] 뉴스 Seagate introduces a new drive interface: Ethernet https://arstechnica.[...] Ars Technica 2013-10-27
[22] 웹사이트 Linux and object storage devices https://lwn.net/Arti[...] 2008-11-04
[23] 웹사이트 Lustre Future Development http://storageconfer[...] IEEE MSST
[24] 웹사이트 Datadirect Networks to build world's fastest storage system for Titan, the world's most powerful supercomputer http://www.multivu.c[...]
[25] 웹사이트 EMC Marks Five Years of EMC Centera Innovation and Market Leadership http://www.emc.com/a[...] EMC 2007-04-18
[26] 웹사이트 Hitachi Content Platform Supports Multiple Petabytes, Billions of Objects http://www.techvalid[...] Techvalidate.com
[27] 뉴스 EMC World Continues Focus on Big Data, Cloud and Flash http://www.infostor.[...] 2011-05-11
[28] 웹사이트 In it for the Long Run: EMC's Object Storage Leadership http://www.rethinkst[...]
[29] 뉴스 Los Alamos National Laboratory likes it, puts Scality's RING on it https://www.theregis[...] The Register 2014-07-01
[30] 뉴스 Facebook Builds Exabyte Data Centers for Cold Storage http://www.datacente[...] 2013-01-13
[31] 웹사이트 How much data does x store? http://techexpectati[...] Techexpectations.org 2014-05-17
[32] 웹사이트 Object storage already dominates our days (we just didn't notice) http://blog.oxygencl[...] 2012-01-11
[33] 뉴스 Amazon S3 goes exponential, now stores 2 trillion objects http://gigaom.com/20[...] Gigaom 2013-04-18
[34] 뉴스 Microsoft: Azure powers 299M Skype users, 50M Office Web Apps users, stores 8.5T objects https://thenextweb.c[...] thenextweb.com 2013-06-27
[35] 뉴스 Microsoft Azure's 44 New Enhancements, 20 Trillion Objects http://www.tomsitpro[...] Tom's IT Pro 2014-04-04
[36] 간행물 Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency http://sigops.org/so[...] Association for Computing Machinery 2013-11-06
[37] 웹사이트 IDC MarketScape: Worldwide Object-Based Storage 2019 Vendor Assessment https://www.idc.com/[...] IDC 2020-02-16
[38] 웹사이트 INCITS 400-2004 https://store.accuri[...] InterNational Committee for Information Technology Standards 2013-11-08
[39] 웹사이트 INCITS 458-2011 https://store.accuri[...] InterNational Committee for Information Technology Standards 2013-11-08
[40] 웹사이트 Object Storage API overview https://docs.opensta[...] 2017-06-09
[41] 웹사이트 ストレージの基礎 http://itpro.nikkeib[...] 2017-12-26
[42] 웹사이트 Finding a needle in Haystack: Facebook’s photo storage https://www.usenix.n[...] 2017-12-26
[43] 웹사이트 ストレージノードのインストールと設定 https://docs.opensta[...] 2017-12-26
[44] 웹사이트 Los Alamos National Laboratory likes it, puts Scality's RING on it https://www.theregis[...] 2017-12-26
[45] 웹사이트 共通テーマ: アドバンスト・ファイルシステム・インプリメンター・ガイド 第10回 https://www.ibm.com/[...] 2017-12-26
[46] 웹사이트 What features differentiate HDFS and OpenStack Object Storage? https://www.quora.co[...] 2018-01-02
[47] 웹사이트 オブジェクトストレージとは http://www.fujitsu.c[...] 2017-12-26
[48] 웹사이트 第3回　ConoHaオブジェクトストレージを使ってみよう https://gihyo.jp/dev[...] 2017-12-26
[49] 웹사이트 Object Storage API https://developer.op[...] 2017-12-26
[50] 웹사이트 用語解説辞典 https://www.nttpc.co[...] 2017-12-26
[51] 웹사이트 日本発、S3互換クラウドストレージ構築パッケージ「Cloudian」 https://atmarkit.itm[...] 2017-12-26
[52] 웹사이트 ストレージ バケットの作成 https://cloud.google[...] 2017-12-26
[53] 웹사이트 第10回 オブジェクトストレージの宿命、容量効率を高める方法とは？ https://www.itmedia.[...] 2017-12-26
[54] 웹사이트 OpenStack: Swift 【API 編】 http://www.valinux.c[...] 2017-12-26
[55] 웹사이트 5.2 オブジェクト・ストレージのメタ検索 https://www.ibm.com/[...] 2017-12-26
[56] 웹사이트 オブジェクトストレージのおすすめ用途 https://www.idcf.jp/[...] 2017-12-26
[57] 웹사이트 5.1 オブジェクト・ストレージを利用するには？ https://www.ibm.com/[...] 2017-12-26
[58] 웹사이트 OpenStack Swiftを使ってクラウドストレージサービスを構築する https://knowledge.sa[...] 2017-12-26
[59] 논문 Storage area networking - Object-based storage https://archive.org/[...] 2003-08
[60] 웹인용 Object Storage versus Block Storage: Understanding the Technology Differences http://www.druva.com[...] Druva 2015-01-19


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com