[Infra] GCS 적용 (1) - GCS(Google Cloud Storage)란?

팀 프로젝트를 진행하면서 비동기 처리를 하다가 기능 추가로 인해 파일 업로드 기능을 구현해야 해서 GCS 적용 글로 급하게 넘어오게 되었다^^..(실제 코드로 비동기 적용 글은 파일 업로드 기능이 끝나고 다시 올릴 거 같다!)

 

이미 서버는 EC2로 배포가 되어있는 상태라서 처음에는 AWS S3를 활용해서 파일 업로드를 구현하려 했지만 AWS 계정을 전에 다니던 아카데미의 공유 계정을 사용하고 있었기 때문에 제약 사항으로 걸린 부분이 너무 많아서 S3로는 진행할 수 없게 되었다. 여러 가지 방법을 찾아보던 도중 GCS라는 것을 알게 되었고 다양한 방법 중 현재 프로젝트에 적용하기에는 가장 좋은 방법이라 생각이 들어서 GCS(Google Cloud Storage)를 사용하기로 했다. 

 

이번 글에서는 S3 적용 불가 이유,  찾아봤던 다양한 파일 업로드 방법들과 그중 GCS를 선택하게 된 이유에 대해 적어보려 한다!

---

 

S3 사용 불가 이유는?

• 현재 프로젝트에서는 위에서 적은 것처럼 아카데미 서버 반의 AWS 계정을 사용 중이다. 
• 아카데미 서버 반의 AWS 계정은 여러 명이 사용 중이기 때문에 보안적으로 사용할 수 있는 기능이 한정적이다. 
• 그중 IAM 계정을 생성할 수 없게 보안이 걸려있다. 
• - S3 사용을 위해 AccessKey를 발급 시도.
  - IAM에서 사용자 추가를 하지 않고 AccessKey 발급을 시도했지만 권한 정책에서 루트 사용자를 지정할 수 없으므로 권한을 제한할 수 없다는 경고문 확인..
• 개인 계정에  S3를 생성하여 연결을 시도했지만 나의 작은 지식과 찾아본 정보로는 EC2 생성 계정과 S3 생성 계정에 iam 사용자를 만들어서 권한으로 설정해서 연결해야 했기 때문에 실패했다.

대체 방안

1. AWS 계정 통일
   • EC2와 S3를 한 계정(개인 계정)에 모두 몰아버리는 것.
   • EC2와 S3 연결과 관리가 쉽다는 장점 존재.
   • 가장 큰 단점인 비용 문제 존재.
2. 외부 스토리지 서비스 사용
   • AWS S3가 아닌 다른 외부 클라우드 스토리지 서비스를 사용하는 방법.
   • Google Cloud Storage, Microsoft Azure Blob Storage, Dropbox 등 존재.
   • 해당 서비스들의 API를 통해 파일 업로드 및 관리 기능을 구현할 수 있다. 
   • EC2 인스턴스에서 외부 서비스로의 접근 권한이 필요하다.
     • EC2에 연결할 때 IAM 관련 작업이 필요하지만 JSON 키 파일만으로 접근 권한을 부여하는 방식이 있다.
     • 대신 보안 위험이 존재.
3. 서버 간 파일 전송 프로토콜(FTP/SFTP)
   • FTP(File Transfer Protocol), SFTP(SSH File Transfer Protocol)
   • 인터넷을 통해 파일을 전송하기 위한 표준 네트워크 프로토콜.
   • FTP는 사용자 ID, PW를 통해 인증 후 파일 서버에 접근하여 파일 업로드, 다운로드 등의 작업이 가능.
   • SFTP는 SSH를 기반으로 하여 FTP의 기능을 제공하면서 데이터 전송과 인증 정보를 암호화하여 보안을 강화.
   • 서버의 설정, 사용자 권한 설정 등을 직접 제어할 수 있다는 장점 존재.
   • 서버의 구축, 운영, 보안 유지 등에 지속적인 관리가 필요하다는 단점 존재.
   • FTP, SFTP 서버를 처음 구축하는 과정이 복잡하고 어렵다. 
4. 온프레미스 NFS(Network File System) 스토리지 활용
   • NFS는 컴퓨터 간에 파일이나 폴더를 공유할 수 있게 해주는 방식 → 공유 폴더
   • 온프레미스 NFS 서버에 스토리지(큰 공유 폴더)를 만든다.
   • EC2 인스턴스에서 NFS 클라이언트를 설치하고, 서버의 공유 폴더를 마운트(연결).
     
   • NFS 스토리지 유지를 위해서는 NFS 서버 컴퓨터의 전원이 항상 켜져 있어야 하고, 네트워크 연결이 안정적이어야 한다.  →  온프레미스(On-Premises) 환경에 있는 실제 물리 서버, 즉 서버실과 같은 실제 하드웨어 서버가 항상 켜져있어야 한다. 

 

🧐Google Cloud Storage를 선택한 이유는?

• 맨 처음 언급했던 것처럼 현재 적용해보려 하는 방법은 GCS이다.
• On-Premises는 실제 하드웨어 서버가 항상 켜져있어야 하기 때문에 불가능했고, FTP와 SFTP는 초반 과정이 너무 복잡해 보였다.
• 이미 Chat-GPT API 사용으로 비용이 발생하고 있었기 때문에 비용 문제를 더 늘리고 싶지 않아 프리 티어도 사용할 수 있고 접근이 쉬운 GCS를 선택했다.

 

🧐Google Cloud Storage가 정확히 뭔데?

• Cloud Storage는 Object Repositroy(객체 저장소)이며  Google Cloud에 어떤 형식의 파일이든 저장하게 해주는 서비스.
• 버킷이라는 컨테이너에 파일을 저장한다. 
• Project : 모든 데이터가 속하는 공간.
• Bucket : 데이터를 담는 개념.
  • Bucket 내부에 Bucket을 만들 수 없다.
  • Bucket의 이름은 Globally unique(전역에서 고유한) 해야 한다.
  • Bucket의 수는 작고 Object(객체)가 많을 수록 좋은 설계다.
  • Bucket 생성 시, Bucket의 이름, 지리적 위치, Repository 등급을 지정할 수 있다.
  • 라벨을 달 수 있으며 key-value 형태로 GCP의 다른 리소스와 그룹화가 가능하다.
• Object(객체) : 버킷에 저장되는 파일들. 객체는 생성 개수에 제한이 없으며 아래와 같은 2가지의 테이터로 구성된다.
  • 객체 데이터 : GCS에 저장되는 파일
  • 객체 메타(meta) 데이터 : key-value 값 형태이며 객체의 퀄리티를 설명
• Repository 등급 : 등급의 종류는 아래와 같이 4가지가 존재한다.

특징	Multi-Regional	Regional	Nearline	Coldline
데이터 접근 방법	매우 자주 접근	동일 Region 내 자주 접근	한 달에 한 번 미만 접근	1년에 한 번 미만 접근
저장 비용	높다     ↔    낮다
복구 비용	낮다     ↔    높다
Use Case	웹 사이트 콘텐츠, 비디오 스트리밍, 게임, 모바일 App 같이 자주 접근	동일 지역 내 분석, 트랜스 코딩	백업, Long tail 미디어	아카이빙, 재난 복구 용
가용성	높다     ↔    낮다

 

 

다음 글에서는 GCS 기본 설정, 프로젝트 설정 및 IAM 설정을 해볼 예정이다!

 

 

이번 글에서는 제가 잘못된 정보를 공유했을 수도 있다고 생각합니다. 혹여나 잘못된 정보가 있거나 틀린 것이 있다면 가감 없이 지적해 주시면 수정하겠습니다!! :)

 

참고

https://techblog-history-younghunjo1.tistory.com/27