Google Cloud Storage
고친 사람 github-actions[bot]
Google Cloud Storage 는 파일을 구글에 맡겨 두고 이름 하나로 다시 내주는 저장 서비스입니다. 쓰는 쪽은 디스크를 사거나 늘리지 않고 웹 요청으로 넣고 꺼냅니다. 구글 클라우드에서 파일을 쌓아 두는 기본 저장소입니다.
쉽고 빠른 이해
GCS 는 파일을 구글 쪽에 맡겨 두는 창고입니다. photos/puppy.jpg 라는 이름으로 사진을 올려
두면 나중에 같은 이름으로 요청해 받습니다.
같은 일을 하는 저장소가 클라우드마다 있습니다. 구글 클라우드에서 서버를 굴린다면 권한도 요금도 구글 쪽으로 묶는 편이 손이 덜 갑니다. GCS 는 그 묶음 안에 든 저장소입니다.
어떻게 도는가:
- 프로젝트를 하나 고르고 그 안에 버킷을 만듭니다
- 버킷을 어느 지역에 둘지, 얼마나 넓게 퍼뜨릴지 정합니다
- 파일에 이름을 붙여 올리고 같은 이름으로 받습니다
대가가 있습니다. 버킷 이름은 전 세계에서 하나뿐이라 남이 쓰는 이름은 못 씁니다. 꺼내 간 데이터 양과 요청 수만큼 요금이 붙고, 싸게 보관하는 등급일수록 꺼낼 때 더 냅니다.
상세
이 절은 GCS 가 파일을 누구 것으로 치고 어디에 두는지를 먼저 보고, 그다음 같은 일을 하는 Amazon S3(Simple Storage Service, 단순 저장 서비스)와 갈리는 대목을 하나씩 봅니다. 사진 한 장을 올리고 다시 받는 흐름을 줄곧 예로 씁니다.
GCS 는 오브젝트 스토리지입니다. 파일 하나를 통째로 맡기고 통째로 꺼내는 저장 방식이고, 그 한 덩어리를 오브젝트라고 부릅니다. 오브젝트를 담는 통이 버킷이고, 버킷 안에서 오브젝트를 가리키는 이름이 오브젝트 키입니다.
여기까지는 S3 와 같습니다. 둘 중 어느 쪽을 쓸지는 대개 서버가 어느 클라우드에 있느냐가 정합니다. 권한과 요금과 데이터가 한 클라우드 안에 묶여야 손이 덜 가기 때문입니다. 아래부터가 갈리는 대목입니다.
버킷은 프로젝트 안에 산다
S3 에서 버킷의 주인은 AWS(Amazon Web Services, 아마존 웹 서비스) 계정입니다. GCS 에서 그 몫을 맡는 것은 프로젝트입니다. 프로젝트는 구글 클라우드가 자원과 요금을 묶는 단위이고, 버킷을 만들려면 먼저 어느 프로젝트에 만들지 정합니다.
프로젝트 위로 층이 더 있습니다. 조직과 폴더가 프로젝트를 감싸고, 권한은 위층에서 아래층으로 내려옵니다. 조직에 「저장소를 읽어도 된다」를 한 번 붙이면 그 아래 모든 프로젝트의 버킷에 걸립니다.
flowchart TD
O[조직] --> F[폴더]
F --> P["프로젝트 · 요금이 붙는 단위"]
P --> B["버킷 · photos-bucket"]
B --> K["오브젝트 · photos/puppy.jpg"]
버킷이 프로젝트 안에 있어도 이름은 전 세계에서 하나뿐입니다. 남이 이미 쓰는 이름으로는 버킷을 못 만듭니다. 한 번 정한 버킷 이름은 바꿀 수 없습니다.
권한을 다루는 서비스 이름은 IAM(Identity and Access Management, 자격과 접근 관리)으로 AWS 와 같습니다. 갈리는 것은 상속입니다. 조직·폴더·프로젝트에 붙인 권한이 버킷까지 따라 내려오므로, 버킷 하나하나에 정책을 붙이지 않고 위에서 한 번에 잡습니다.
오브젝트마다 따로 권한을 붙이는 옛 방식도 남아 있습니다. ACL(Access Control List, 접근 제어 목록)이라고 부릅니다. 두 방식이 섞이면 어느 쪽이 허락했는지 따지기 어려워집니다. 그래서 균일한 버킷 수준 액세스를 켜면 오브젝트 ACL 이 꺼지고 IAM 하나만 남습니다.
위치를 리전보다 넓게 고른다
S3 버킷은 리전 하나에 놓입니다. GCS 는 버킷을 만들 때 데이터를 얼마나 넓게 퍼뜨릴지까지 고릅니다.
| 위치 종류 | 데이터가 놓이는 범위 | 무엇을 맞바꾸나 |
|---|---|---|
| 리전 | 한 지역 | 보관 값이 가장 쌉니다. 그 지역이 멈추면 못 읽습니다 |
| 이중 리전 | 정해진 두 지역 | 한 지역이 멈춰도 읽힙니다. 두 벌을 두는 값이 듭니다 |
| 멀티 리전 | 대륙 한 곳 안의 여러 지역 | 대륙 안 어디서나 가깝게 읽힙니다. 값이 가장 비쌉니다 |
넓게 잡아도 부르는 이름은 버킷 하나뿐이라, 애플리케이션은 데이터가 몇 지역에 놓였는지 모른 채 같은 요청을 보냅니다. 위치는 버킷을 만들 때 정하고 나중에 못 바꿉니다. 옮기려면 새 버킷을 만들어 오브젝트를 복사합니다.
보관 등급을 내려도 꺼내는 시간은 그대로다
자주 안 읽는 데이터를 싸게 두는 등급을 스토리지 클래스라고 부릅니다. Standard · Nearline · Coldline · Archive 가 대표적이고, 뒤로 갈수록 보관이 싸집니다.
갈리는 대목은 꺼내는 시간입니다. S3 에서 S3 Glacier 계열에 넣은 데이터는 되살리기를 걸고 기다려야 읽힙니다. GCS 는 Archive 에 넣은 데이터도 밀리초 안에 돌려줍니다. 등급을 내려도 읽는 코드가 달라지지 않습니다.
대신 값을 최소 보관 기간으로 받습니다. Nearline 은 30일, Coldline 은 90일, Archive 는 365일을 채우기 전에 지우면 남은 기간치 요금을 그대로 냅니다. 자주 지우고 다시 쓰는 데이터를 싼 등급에 넣으면 오히려 더 냅니다.
판 번호를 걸고 덮어쓴다
S3 에서 같은 키에 쓰기 둘이 겹치면 나중에 도착한 쪽이 남습니다. GCS 도 마지막 쓰기가 남는 것은 같습니다. 다른 것은 GCS 가 오브젝트의 판 번호를 겉으로 드러낸다는 점입니다.
GCS 는 오브젝트를 새로 쓸 때마다 세대 번호를 새로 매깁니다. 같은 키라도 내용이 바뀌면 번호가 바뀝니다. 읽을 때 이 번호를 같이 받아 둘 수 있습니다.
쓰기 요청에는 「세대가 아직 이 번호일 때만 써라」는 조건을 붙입니다. 이런 조건을 프리컨디션이라고 부릅니다. 그사이 누가 먼저 썼으면 번호가 달라져 요청이 거절됩니다.
sequenceDiagram
participant A as 앱 A
participant G as GCS
participant B as 앱 B
A->>G: 읽는다
G-->>A: 내용 · 세대 17
B->>G: 읽는다
G-->>B: 내용 · 세대 17
A->>G: 세대가 17 이면 써라
G-->>A: 썼다 · 세대 18 이 되었다
B->>G: 세대가 17 이면 써라
G-->>B: 거절 · 이미 바뀌었다
거절을 받은 쪽은 다시 읽고 다시 씁니다. 잃어버린 갱신을 앱이 알아챌 수 있다는 것이 이 번호의 쓸모입니다.
객체 버전 관리를 켜면 덮인 옛 세대가 지워지지 않고 남습니다. 옛 세대는 번호로 골라 다시 읽거나 되살립니다. 대가는 저장 용량입니다.
두 갈래 API 를 연다
GCS 를 부르는 API(Application Programming Interface, 응용 프로그램 인터페이스)에는 두 갈래가 있습니다. 하나는 JSON(JavaScript Object Notation, 자바스크립트 오브젝트 표기)으로 주고받는 JSON API로, 구글 클라우드의 다른 서비스와 꼴이 같습니다. 다른 하나는 XML(Extensible Markup Language, 확장 가능 표시 언어)로 주고받는 XML API로, S3 의 요청 꼴을 그대로 받습니다.
XML API 를 둔 까닭은 옮겨 오는 값을 낮추려는 것입니다. S3 로 짠 코드가 요청 URL(Uniform Resource Locator, 자원 주소)과 인증 키만 바꾸면 GCS 에 붙습니다. 이때 쓰는 키를 HMAC 키(Hash-based Message Authentication Code, 해시 기반 메시지 인증 코드)라고 부르고, S3 의 접근 키와 꼴이 같습니다.
그래서 GCS 는 S3 호환 스토리지용 도구에도 대개 그냥 붙습니다. 터미널에서 쓰는 CLI(Command Line Interface, 명령줄 도구)는 따로 있는데, GCS 쪽 명령이 gcloud storage 입니다.
폴더가 진짜 폴더가 되기도 한다
S3 에서 photos/ 는 폴더가 아니라 키의 앞머리입니다. 폴더 이름을 바꾸려면 그 앞머리로 시작하는
키를 하나씩 옮겨야 합니다. GCS 버킷도 기본은 같습니다.
버킷을 만들 때 계층 네임스페이스를 켜면 달라집니다. 폴더가 실제 자원이 되고, 폴더 이름 바꾸기가 요청 한 번으로 끝납니다. 안에 든 파일이 몇 개든 원자적으로 바뀝니다. 이 설정도 버킷을 만들 때만 켜고, 이미 있는 버킷에는 나중에 붙이지 못합니다.
S3 용어를 GCS 말로 옮기면
같은 물건을 두 서비스가 다른 이름으로 부릅니다. S3 를 알고 GCS 문서를 읽을 때 걸리는 곳이 대개 이름입니다.
| S3 | GCS | 하는 일 |
|---|---|---|
| 계정 | 프로젝트 | 버킷의 주인이자 요금이 붙는 단위 |
| Presigned URL | 서명된 URL | 로그인 없이 파일 하나를 잠깐 내주는 주소 |
| 멀티파트 업로드 | 재개 가능 업로드 | 큰 파일을 나눠 올리고 끊기면 이어 올린다 |
| Intelligent-Tiering | Autoclass | 읽는 빈도를 보고 등급을 알아서 옮긴다 |
| Object Lock | 보존 정책 | 정해진 기간 동안 지우지 못하게 막는다 |
이름만 바꿔 읽으면 S3 로 짠 구조가 대체로 그대로 섭니다. 다시 그리는 곳은 권한과 요금을 어디에 묶느냐이고, 그 단위가 계정에서 프로젝트로 바뀝니다.
그래서 GCS 를 고르는 까닭은 대개 기술이 아닙니다. 서버와 분석 도구가 구글 클라우드에 있으면 GCS 를, AWS 에 있으면 S3 를 씁니다. 두 클라우드에 걸쳐 있으면 XML API 덕분에 코드 한 벌로 둘 다 붙습니다.
관련 항목
Google Cloud Storage 를 이루는 구성 요소
버킷 · 오브젝트 · 오브젝트 키 · 프리픽스 · 메타데이터 · 세대 번호 · 프로젝트
Google Cloud Storage 가 속하는 상위 분류
Google Cloud · 오브젝트 스토리지 · 클라우드 스토리지 · 클라우드 컴퓨팅 · 관리형 서비스
Google Cloud Storage 가 제공하는 관리 기능
객체 버전 관리 · 객체 수명 주기 · 스토리지 클래스 · Autoclass · 보존 정책 · 소프트 삭제 · 계층 네임스페이스 · 재개 가능 업로드
Google Cloud Storage 에 접근을 허락하는 수단
IAM · ACL · 균일한 버킷 수준 액세스 · 서명된 URL · HMAC 키 · 서비스 계정
Google Cloud Storage 를 호출하는 인터페이스
JSON API · XML API · REST API · gRPC · HTTP · gcloud storage
Google Cloud Storage 가 지키는 성질
강한 일관성 · 원자성 · 내구성 · 가용성 · 프리컨디션 · Last Write Wins
Google Cloud Storage 가 놓이는 지리 단위
리전 · 이중 리전 · 멀티 리전 · 가용 영역
Google Cloud Storage 를 대신할 수 있는 다른 저장소
Amazon S3 · Azure Blob Storage · MinIO · S3 호환 스토리지 · Persistent Disk · Filestore · 블록 스토리지 · 파일 시스템
Google Cloud Storage 에 데이터를 두는 시스템 구성
정적 웹사이트 · CDN · Cloud CDN · 데이터 레이크 · 백업 · 로그
Google Cloud Storage 위에서 데이터를 읽는 분석 도구
BigQuery · Dataflow · Dataproc · Apache Spark · Apache Parquet
다른 이름: GCS · Google 클라우드 스토리지 · 구글 클라우드 스토리지 · Cloud Storage