< Best Practices for Using Cloud Storage (Part 2) >
Uniformly control access to Cloud Storage resources
Cloud Storage 리소스에 대한 액세스를 균일하게 제어
- Cloud Storage는 버킷과 객체에 대한 액세스 권한을 부여하기 위해
IAM(Identity and Access Management)과 ACL(액세스 제어 목록)이라는 두 가지 시스템을 제공 - 이러한 시스템은 Cloud Storage 리소스에 액세스하기 위해 병렬로 작동하며 시스템 중 하나만 권한을 부여하면 됨
- IAM은 GCP 전체에서 사용되며 버킷 및 프로젝트 수준에서 다양한 권한을 부여할 수 있음
- ACL은 Cloud Storage에서만 사용되며 권한 옵션이 제한되어 있지만 객체별로 권한을 부여할 수 있음
- 균일한 권한 부여 시스템을 지원하기 위해 Cloud Storage에는 균일한 버킷 수준 액세스 권한이 있음
- Cloud Storage 리소스에 대한 액세스 권한이 IAM을 통해서만 버킷과 버킷의 객체에 대한 액세스 권한 부여
- 균일한 버킷 수준 액세스를 활성화한 후 90일 이내에 결정을 취소할 수 있음
- Cloud Storage 리소스에 대한 액세스 권한을 부여하는 방법을 통합하고 단순화하기 때문에
일반적으로 균일한 버킷 수준 액세스를 사용하는 것이 좋음
- 균일한 버킷 수준 액세스를 사용하면 도메인 제한 공유 및 IAM 조건과 같은 다른 GCP 보안 기능도 사용할 수 있음
- 그러나 균일한 버킷 수준 액세스를 사용하지 않고 대신 세분화된 ACL을 유지할 수 있음
- 예를 들어 레거시 ACL을 통해 버킷의 특정 객체에 대한 액세스를 제어하려는 경우
또는 객체의 업로더가 해당 객체에 대한 전체 제어 권한을 가지지만 버킷의 다른 객체에 대한 액세스 권한은 제한하려는 경우
Consider these best practices for uploading data
데이터 업로드에 대한 다음 모범 사례를 고려
- XMLHttpRequest 또는 XHR 콜백을 사용하여
진행률 업데이트를 가져오고 진행률이 중단된 시점을 감지하는 경우 연결을 닫았다가 다시 열지 말아야 함
- 그렇게 하면 네트워크 정체 시간 동안 나쁜 긍정적인 피드백 루프가 생성됨
- 네트워크가 혼잡할 때 XHR 콜백은 업로드 스트림의 승인 활동 뒤에 백로그될 수 있으며,
연결을 닫았다가 다시 열면 가장 감당할 수 있는 정확한 시간에 더 많은 네트워크 용량이 사용됨
- 업로드 트래픽의 경우 상당히 긴 시간 제한을 설정
- 좋은 최종 사용자 경험을 위해 애플리케이션이 오랫동안 XHR 콜백을 받지 못했을 때
메시지로 클라이언트 상태 창을 업데이트하는 클라이언트 측 타이머를 설정하며 이 경우 연결을 닫고 다시 시도하지 말아야 함 - 재개 가능한 업로드를 시작하기 위해 Cloud Storage에 POST하는 프로세스와 함께 Google Compute Engine 인스턴스를
사용하는 경우 Cloud Storage 버킷과 동일한 위치에서 Compute Engine 인스턴스를 사용해야 함
- 그런 다음 지역 IP 서비스를 사용하여 고객 요청을 라우팅할 Compute Engine 지역을 선택할 수 있음
- 이렇게 하면 트래픽을 지역으로 현지화하는 데 도움이 됨
- 재개 가능한 업로드의 경우 재개 가능한 세션이 생성된 지역에 있어야 함
- 이렇게 하면 세션 상태를 읽고 쓸 때 발생하는 교차 리전 트래픽이 줄어들어 재개 가능한 업로드 성능이 향상 - 가능하면 전송을 더 작은 청크로 나누는 것을 피하고 대신 전체 콘텐츠를 단일 청크로 업로드
- 청킹을 피하면 고정 대기 시간 비용이 제거되고, 처리량을 개선하고 Cloud Storage에 대한 QPS를 줄임 - 파일을 gzip 형식으로 저장하고 관련 메타데이터를 Content-Encoding gzip으로 설정하여 압축 해제 트랜스코딩 사용 가능
- 그러나 gzip의 콘텐츠 인코딩과 압축된 콘텐츠 유형이 모두 포함된 콘텐츠는 업로드하지 않아야 함
- 압축된 데이터에 콘텐츠 인코딩 gzip을 사용하면 사실상 아무런 이점이 없음
Consider the following when using gsutil for Cloud Storage
Cloud Storage용 gsutil을 사용할 때 다음 사항을 고려
- gsutil -D를 실행하여 디버깅 출력을 생성하면 출력에 OAuth2 새로고침 및 액세스 토큰이 포함
- 문제 해결 또는 기술 지원 상호 작용 중에 이 디버그 출력을 다른 사람에게 보내기 전에 이 정보를 수정해야 함 - gsutil --trace-token을 실행하여 Google에 직접 추적을 보내면
OAuth2 토큰과 같은 민감한 정보와 추적 중에 액세스한 모든 파일의 콘텐츠가 추적 콘텐츠에 포함될 수 있음 - .boto 구성의 고객 제공 암호화 키 정보는 보안에 민감
- .boto 구성의 프록시 구성 정보는 특히 프록시 설정에 사용자 및 암호 정보가가 필요한 경우 보안에 민감
- 프록시 설정에 사용자 및 비밀번호 정보가 필요하지 않더라도
프록시의 호스트 및 포트 번호는 종종 보안에 민감한 것으로 간주되어야 함
- .boto 구성 파일에 대한 액세스를 보호 - 프로덕션 환경에서 gsutil을 사용하는 경우 개별 사용자 계정 사용자 인증 정보 대신 서비스 계정 사용자 인증 정보를 사용
- 서비스 계정은 이러한 용도로 설계되었으며 직원이 퇴사할 때 액세스 권한을 잃지 않도록 보호
Validate your data
데이터 검증
- 데이터는 노이즈가 많은 네트워크 링크, 클라이언트 또는 서버 컴퓨터의 메모리 오류, 경로를 따라
라우터의 메모리 오류, 소프트웨어 버그로 인해 클라우드에 업로드되거나 클라우드에서 다운로드되는 동안 손상될 수 있음 - CRC32c 또는 MD5 체크섬을 사용하여 버킷과 주고받는 데이터의 유효성을 검사
- Cloud Storage는 업로드에 대한 서버 측 검증을 지원하지만 클라이언트 측 검증도 일반적인 접근 방식
- 업로드를 시작하기 전에 애플리케이션이 이미 객체의 MD5 또는 CRC32c를 계산한 경우 업로드 요청과 함께
이를 제공할 수 있으며 Cloud Storage는 제공한 해시가 Google에서 계산한 값과 일치하는 경우에만 객체를 생성
- 또는 사용자는 새 개체의 메타데이터에 대한 요청을 실행하고 보고된 해시 값을 비교하고 일치하지 않는 경우
개체를 삭제하여 클라이언트 측 유효성 검사를 수행
- 모든 Cloud Storage 객체에는 CRC32c 해시가 있음
- CRC32c 컴퓨팅을 위한 라이브러리에는 C++용 Boost, Python용 crcmod, Ruby용 digest-crc가 있음
- Java 사용자는 GoogleCloudPlatform crc32 Java 프로젝트에서 알고리즘 구현을 찾을 수 있음
- Gsutil은 모든 업로드 및 다운로드에서 무결성 검사를 자동으로 수행
- 또한 "gsutil 해시" 명령을 사용하여 모든 로컬 파일의 CRC를 계산할 수 있음
- MD5 해시는 비복합 개체에 대해 지원
- MD5 해시는 전체 개체에만 적용되므로 범위 GET 수행으로 인한 부분 다운로드의 무결성 검사에 사용할 수 없음
You can host static websites
정적 웹사이트를 호스팅할 수 있음
- 교차 출처 리소스 공유 또는 CORS 주제에서는 다른 웹사이트에서 호스팅되는 스크립트가
Cloud Storage 버킷에 저장된 정적 리소스에 액세스하도록 허용하는 방법을 설명
- Cloud Storage에서 호스팅되는 스크립트가
Cloud Storage 외부 웹사이트에서 호스팅되는 정적 리소스에 액세스하도록 허용할 수도 있음
- 웹사이트는 storage.googleapis.com의 콘텐츠에 액세스할 수 있도록 CORS 헤더를 제공해야 함
- 이러한 유형의 데이터 액세스 전용으로 특정 버킷을 사용하는 것이 좋음
(online) 05_Performing Operations on Cloud Storage.pdf
2.06MB
