Conceptly
← 전체 목록
🪣

Google Cloud Storage

스토리지객체 저장소

Google Cloud Storage는 애플리케이션이 만든 파일과 큰 객체를 서버 디스크와 분리해 보관하는 객체 저장소입니다. 여러 서비스가 같은 파일을 읽고 쓰거나, 오래 보관한 뒤 다시 꺼내야 할 때 중심 저장소 역할을 합니다. 실무에서는 '파일의 단일 진실 소스'를 두는 계층으로 이해하면 가장 쉽습니다.

아키텍처 다이어그램

🔗 관계 다이어그램

점선 애니메이션은 데이터 또는 요청의 흐름 방향을 나타냅니다

왜 필요한가요?

앱이 만든 파일을 서버 디스크에 붙여 두면 용량이 먼저 막히고, 서버를 바꾸는 순간 파일이 따라가지 않습니다. 여러 인스턴스가 같은 파일을 봐야 하면 문제는 더 빨리 꼬입니다. 이미지·영상처럼 파일 크기가 큰 서비스일수록 이 병목이 곧바로 비용과 장애로 이어집니다.

왜 이런 방식이 등장했나요?

서버 로컬 디스크나 공유 파일서버에 의존하던 방식은 서버 증설과 장애 복구가 같이 따라오면서 운영이 무거워졌습니다. 파일이 커지고 복제 대상이 늘어나자, 애플리케이션과 분리된 객체 저장소가 필요해졌습니다. 객체 저장소는 저장 계층을 애플리케이션 컴퓨팅 계층과 분리해 확장 전략을 단순화했습니다.

내부적으로 어떻게 동작하나요?

버킷을 하나의 컨테이너로 두고, 파일을 객체로 올립니다. 객체는 이름과 메타데이터를 함께 가지며, API로 읽고 씁니다. 수명 주기 규칙을 두면 오래된 객체를 자동으로 다른 보관 등급으로 옮기거나 지울 수 있습니다. 버전 관리와 접근 권한 정책을 함께 쓰면 실수 삭제 복구와 데이터 거버넌스를 동시에 챙길 수 있습니다.

경계와 구분

Cloud Storage와 Cloud SQL은 둘 다 데이터를 보관하지만, Cloud Storage는 파일과 큰 객체를 다루는 저장소이고 Cloud SQL은 행과 관계를 다루는 데이터베이스입니다. 파일 자체를 통째로 보관하고 여러 서비스가 읽어야 하면 Cloud Storage가 맞고, 조건 검색과 트랜잭션이 필요하면 Cloud SQL이 맞습니다. 분석 대상으로 쌓아 두는 원본 데이터의 1차 보관소는 보통 Cloud Storage가 담당합니다.

언제 쓰나요?

정적 자산, 업로드 파일, 로그, 백업처럼 생성 이후에는 파일 단위로 읽는 데이터에 적합합니다. 여러 서비스가 같은 파일을 보거나, 오래 보관했다가 필요할 때 내려받는 흐름에 잘 맞습니다. CDN, 데이터 파이프라인, 백업 자동화의 공통 기반 스토리지로도 자주 사용됩니다.

정적 웹사이트 호스팅데이터 레이크백업 및 아카이브미디어 저장