오브젝트

오브젝트는 저장소에 파일을 맡기고 꺼낼 때 오가는 한 덩어리입니다. 이 덩어리에는 파일 내용과 그 설명이 함께 담깁니다. 맡길 때 붙인 이름 하나만 대면 저장소가 덩어리 전체를 돌려줍니다. 프로그래밍의 객체나 쿠버네티스의 설정 기록도 영어로는 같은 단어로 부릅니다. 이 항목은 오브젝트 스토리지에 담기는 오브젝트를 다룹니다.

상세

이삿짐을 창고에 맡긴다고 해 봅니다. 상자마다 이름표를 붙이고 겉면에 무엇이 들었는지 적어 둡니다. 찾을 때는 이름표에 적힌 이름을 대고 상자째로 받아 옵니다. 안에 든 물건 하나를 바꾸고 싶으면 상자를 새로 싸서 다시 맡깁니다.

오브젝트 스토리지는 파일을 한 덩어리씩 맡기고 꺼내는 저장 방식입니다. 오브젝트는 이 저장소가 한 번에 넣고 꺼내는 데이터 단위입니다. 사진 한 장, 백업 파일 하나, 동영상 하나가 각각 오브젝트 하나입니다.

파일을 한 덩어리로만 다루기로 하면 저장소가 챙길 일이 줄어듭니다. 폴더를 겹겹이 관리하거나 파일 중간을 고쳐 쓰는 일을 받지 않아도 됩니다. 폴더 나무를 맞춰 둘 일이 없으니 오브젝트를 서버 여러 대에 흩어 둘 수 있습니다. 서버를 더하는 만큼 담을 수 있는 파일도 늘어납니다.

오브젝트를 이루는 세 가지

오브젝트 하나는 세 가지로 이루어집니다. 내용을 담은 데이터, 그 내용을 설명하는 메타데이터, 그리고 오브젝트를 가리키는 이름인 키입니다. 강아지 사진을 올린 경우로 보면 아래와 같습니다.

데이터는 저장소가 들여다보지 않는 바이트 덩어리입니다. 사진이든 로그든 저장소에게는 똑같이 바이트의 나열입니다. 어떤 형식의 파일이든 오브젝트로 맡길 수 있는 까닭입니다.

메타데이터는 데이터에 대한 데이터입니다. 저장소가 내용을 열어 보지 않으니 내용이 무엇인지는 따로 적어 둬야 합니다. 올리는 사람이 자기만의 「이름 = 값」 짝을 더 붙일 수도 있습니다.

Content-Type 은 내용의 종류를 적는 이름입니다. 받는 쪽은 이 값을 보고 사진으로 띄울지 파일로 내려받을지 정합니다.

오브젝트 키는 오브젝트를 찾을 때 대는 이름입니다. 올리는 사람이 정합니다. 같은 키로 다시 올리면 앞의 오브젝트를 새 오브젝트가 덮어씁니다.

버킷과 키로 찾는 평평한 구조

오브젝트는 반드시 버킷 하나 안에 들어갑니다. 버킷은 오브젝트를 담는 가장 바깥 통입니다. 누가 꺼내 가도 되는지 같은 설정을 버킷에 걸어 두면 그 안의 오브젝트가 모두 그 설정을 따릅니다.

키는 한 버킷 안에서 겹치지 않습니다. 그래서 버킷 이름과 키 두 개만 있으면 오브젝트 하나가 정해집니다. 저장소 안의 모든 오브젝트는 이 두 이름으로 찾습니다.

버킷 안에는 폴더가 없습니다. 파일 시스템은 폴더 안에 폴더를 두는 나무 모양입니다. 오브젝트 스토리지는 버킷 아래에 키가 한 줄로 늘어선 평평한 모양입니다.

flowchart TD
    subgraph FS["파일 시스템"]
        R["/ (맨 위 폴더)"] --> P["photos 폴더"]
        P --> F1["puppy.jpg"]
        P --> F2["cat.jpg"]
    end
    subgraph OS["오브젝트 스토리지"]
        B["버킷"] --> K1["키 · photos/puppy.jpg"]
        B --> K2["키 · photos/cat.jpg"]
    end

위쪽은 폴더를 한 단계 거쳐 파일에 닿습니다. 아래쪽은 버킷에서 키로 바로 닿습니다. photos/puppy.jpg 의 슬래시(/)는 폴더 경계가 아니라 긴 이름 한 줄에 섞인 글자일 뿐입니다.

그래도 슬래시 덕에 폴더처럼 쓸 수는 있습니다. 여러 키가 함께 가진 앞부분을 프리픽스라고 합니다. 목록을 달라고 할 때 photos/ 로 시작하는 키만 걸러 받을 수 있습니다. 관리 화면도 이 프리픽스를 폴더 모양으로 그려 보여 줍니다.

폴더가 없으니 폴더 이름을 한 번에 바꾸는 방법도 없습니다. photos/ 를 images/ 로 바꾸려면 그 프리픽스로 시작하는 오브젝트를 하나씩 새 키로 복사하고 옛 키를 지웁니다.

한 덩어리로 쓰고 한 덩어리로 읽기

파일 시스템에서는 파일을 열어 중간 몇 바이트만 고쳐 쓸 수 있습니다. 파일 끝에 이어 쓰는 것도 됩니다. 오브젝트는 그렇게 못 합니다. 한 글자를 바꿔도 오브젝트 전체를 새로 올립니다.

오브젝트 스토리지는 대개 한 오브젝트의 복사본을 여러 서버에 나눠 둡니다. 중간 고쳐 쓰기를 받으면 복사본마다 어디까지 고쳐졌는지를 맞춰야 합니다. 한 덩어리로만 바꾸면 복사본은 옛 버전이거나 새 버전이거나 둘 중 하나입니다.

읽는 쪽도 덕을 봅니다. 새 오브젝트가 다 올라가기 전까지는 옛 오브젝트가 보입니다. 다 올라간 뒤에는 새 오브젝트가 보입니다. 반쯤 올라간 오브젝트를 읽게 되는 일은 없습니다.

아주 큰 파일은 한 번에 올리다 끊기면 처음부터 다시 올려야 합니다. 그래서 파일을 여러 조각으로 나눠 따로 올리고 저장소가 마지막에 한 오브젝트로 합치게 하는 방법이 있습니다. 이를 멀티파트 업로드라고 합니다. 끊긴 조각만 다시 올리면 됩니다.

HTTP 요청으로 다루는 오브젝트

오브젝트는 대개 HTTP(HyperText Transfer Protocol, 하이퍼텍스트 전송 프로토콜) 요청으로 다룹니다. 웹 브라우저가 웹 페이지를 받을 때 쓰는 그 요청입니다. 요청마다 무엇을 할지 적는 단어가 붙습니다. 이 단어를 메서드라고 합니다.

아래는 강아지 사진 오브젝트 하나에 보내는 요청 넷입니다. 오른쪽 주석이 요청마다 일어나는 일입니다.

PUT /photos/puppy.jpg     # 올리기·덮어쓰기
GET /photos/puppy.jpg     # 데이터 받기
HEAD /photos/puppy.jpg    # 메타데이터만
DELETE /photos/puppy.jpg  # 지우기

요청 줄의 경로에 키가 들어갑니다. 버킷 이름도 요청을 보내는 주소에 함께 들어갑니다. 위 예는 키만 보이려고 버킷을 뺐습니다. PUT 은 데이터와 메타데이터를 함께 실어 보냅니다. HEAD 는 데이터를 빼고 메타데이터만 돌려받습니다. 크기나 종류만 알고 싶을 때 큰 파일을 받지 않아도 됩니다.

버킷 이름과 키만 대면 오브젝트가 정해지니 쓰는 쪽이 편합니다. 서버 애플리케이션은 파일을 로컬 디스크에 두지 않습니다. 오브젝트 스토리지에 올리고 키만 데이터베이스에 적어 둡니다. 서버를 여러 대로 늘려도 모두 같은 오브젝트를 봅니다.

옛 버전을 남기는 버전 관리

평소에는 같은 키로 다시 올리면 옛 오브젝트가 사라집니다. 실수로 덮어쓰거나 지우면 되돌릴 수 없습니다. 이를 막으려고 버전 관리를 켤 수 있습니다.

버전 관리를 켜면 저장소가 같은 키 아래에 버전을 쌓습니다. 버전마다 번호를 붙여 옛 버전을 남겨 둡니다. 아래 그림은 사진을 세 번 올린 키 하나를 두 가지 요청으로 찾는 모습입니다.

flowchart TD
    Q1["요청 · 키만"] --> V3
    Q2["요청 · 키 + 버전 1 의 번호"] --> V1
    subgraph K["키 · photos/puppy.jpg"]
        V3["버전 3 · 가장 새 버전"]
        V2["버전 2"]
        V1["버전 1 · 처음 올린 사진"]
    end

키만 대면 가장 새 버전이 돌아옵니다. 키와 버전 번호를 함께 대면 그 버전이 돌아옵니다. 사진을 세 번 올렸어도 앞의 두 장이 남아 있는 셈입니다.

대가는 저장 공간입니다. 버전이 쌓이는 만큼 공간을 차지합니다. 그래서 정해진 때가 지난 버전을 지우는 규칙을 함께 걸어 둡니다. 이 규칙을 수명 주기 규칙이라고 부릅니다.

버전 번호를 부르는 이름은 저장소마다 다릅니다. Amazon S3(Simple Storage Service, 단순 저장 서비스)에서는 버전 ID라고 부릅니다. Google Cloud Storage 에서는 세대 번호라고 부릅니다.

내용이 곧 이름인 Git 의 오브젝트

버전 관리 도구 Git 도 기록을 오브젝트로 저장합니다. 파일 내용 하나, 폴더 목록 하나, 커밋 하나가 각각 오브젝트 하나입니다. 파일 내용을 담는 오브젝트는 블롭이라고 부릅니다.

Git 오브젝트의 이름은 사람이 정하지 않습니다. 내용을 해시 함수에 넣어 나온 값이 이름이 됩니다. 이렇게 내용에서 이름을 계산해 내는 방식을 내용 주소 지정이라고 합니다.

이름을 정하는 쪽이 다르니 성질도 오브젝트 스토리지와 갈립니다. 아래 표는 같은 질문에 두 저장소가 어떻게 답하는지 보입니다.

내용이 바뀌면 이름도 바뀌니 Git 오브젝트는 한 번 쓰면 고쳐지지 않습니다. 파일을 고치면 옛 오브젝트는 그대로 두고 새 이름의 오브젝트가 하나 더 생깁니다. 옛 버전을 남기는 버전 관리가 저장 방식에 처음부터 들어 있는 셈입니다.

오브젝트에 맞는 데이터와 안 맞는 데이터

한 번 써 두고 여러 번 읽는 파일이 잘 맞습니다. 사용자가 올린 사진과 동영상, 데이터베이스 백업 파일, 하루치 로그 묶음이 그렇습니다. 올린 뒤에 고칠 일이 거의 없고 통으로 받아 가면 되는 파일들입니다.

자주 조금씩 고치는 데이터는 안 맞습니다. 데이터베이스가 쓰는 파일은 한 행을 고칠 때마다 몇 바이트를 바꿉니다. 오브젝트였다면 그때마다 파일 전체를 다시 올려야 합니다. 이런 데이터는 디스크를 고정 크기 조각으로 나눠 조각 단위로 읽고 쓰는 블록 스토리지에 둡니다.

여러 파일을 한 번에 함께 바꿔야 하는 일도 안 맞습니다. 오브젝트 스토리지는 오브젝트 하나씩만 한 덩어리로 바꿔 줍니다. 파일 셋 가운데 둘만 바뀐 채로 멈추는 일을 막으려면 애플리케이션이 직접 챙겨야 합니다.

같은 단어를 쓰는 다른 분야

오브젝트라는 단어는 저장소 밖에서도 쓰입니다. 가리키는 것이 저마다 다릅니다.

관련 항목

오브젝트를 담아 두는 저장 방식

오브젝트 스토리지 · 클라우드 스토리지 · 분산 스토리지 · 복제 · 강한 일관성 · 결과적 일관성

오브젝트를 이루는 구성 요소

데이터 · 메타데이터 · 오브젝트 키 · Content-Type · 사용자 정의 메타데이터 · ETag

오브젝트를 담고 가리키는 이름 체계

버킷 · 프리픽스 · 네임스페이스 · URL · 리전

오브젝트를 다루는 요청과 명령

HTTP · 요청 메서드 · PUT · GET · HEAD · DELETE · 멀티파트 업로드 · 서명된 URL

오브젝트의 버전을 쌓고 지우는 장치

버전관리 · S3 버전 관리 · 버전 ID · 세대 번호 · 수명 주기 규칙 · 오브젝트 잠금

오브젝트 스토리지를 제공하는 제품

Amazon S3 · Google Cloud Storage · Azure Blob Storage · MinIO · Ceph · S3 Glacier

오브젝트와 겨루는 다른 저장 방식

파일 시스템 · 블록 스토리지 · 네트워크 파일 시스템 · 데이터베이스 · 디스크

내용으로 이름을 짓는 Git 오브젝트

Git · 블롭 · 트리 · 커밋 객체 · 태그 객체 · 해시 · 해시 함수 · 내용 주소 지정 · 머클 트리 · 중복 제거

오브젝트라는 단어를 함께 쓰는 다른 분야

객체 · 객체 지향 프로그래밍 · Kubernetes · 쿠버네티스 오브젝트 · 오브젝트 파일 · 공유 라이브러리