정적 웹사이트 예시 및 팁

이 페이지에서는 버킷을 사용하여 정적 웹사이트를 호스팅하는 예시와 팁을 보여줍니다.

웹사이트 구성 예

다음 시나리오에서는 다양한 URL로 객체 액세스를 시도할 때 제공되는 객체를 보여줍니다.

객체가 3개 있는 버킷

www.example.com이라는 버킷이 다음 설정과 파일을 사용하는 웹사이트로 구성되었다고 가정합니다.

  • MainPageSuffix = 'index.html'
  • NotFoundPage = '404.html'
  • 버킷에는 'index.html', '404.html', 'dir/index.html'이라는 공개적으로 공유되는 객체가 3개 있습니다.

다음 표에서는 선택한 URL에 제공되는 콘텐츠를 보여줍니다.

요청된 URL 제공되는 콘텐츠 HTTP 응답 코드
http://www.example.com
http://www.example.com/ http://www.example.com/index.html
객체 'index.html'. 200
http://www.example.com/hello 객체 '404.html'. 404
http://www.example.com/dir/index.html 객체 'dir/index.html'. 200
http://www.example.com/dir 객체 'dir/index.html'. 301
http://www.example.com/dir/ 객체 'dir/index.html'(/dir/에 대해 0바이트 객체가 없다고 가정) 200
0바이트의 빈 객체(/dir/에 대해 있는 경우) 이 0바이트 객체 삭제는 문제해결 주제를 참조하세요. 301

객체가 두 개 있는 버킷

www.example.com이라는 버킷이 다음 설정과 파일을 사용하는 웹사이트로 구성되었다고 가정합니다.

  • MainPageSuffix = 'main.html'
  • NotFoundPage = '404.html'
  • 버킷에는 'main.html'과 '404.html'이라는 공개적으로 공유되는 객체 2개가 있습니다.

다음 표에서는 선택한 URL에 제공되는 콘텐츠를 보여줍니다.

요청된 URL 제공되는 콘텐츠 HTTP 응답 코드
http://www.example.com
http://www.example.com/
객체 'main.html'. 200
http://www.example.com/index.html 객체 '404.html'. 404

객체가 공개적으로 공유되는 경우 이 객체를 URL로 볼 수도 있습니다.

http://storage.googleapis.com/[BUCKET_NAME]/[OBJECT_NAME]

예를 들어 index.html 객체의 URL은 다음과 같습니다.

http://storage.googleapis.com/www.example.com/index.html

공개적으로 액세스 가능한 데이터 작업에 대한 자세한 내용은 공개 데이터에 액세스를 참조하세요.

웹사이트로 구성된 버킷 작업 팁

다음은 버킷을 사용하여 정적 웹사이트를 호스팅할 때 참고해야 할 몇 가지 팁입니다.

하위 도메인 추가

또한 www.example.com의 콘텐츠를 제공하는 버킷과 다른 버킷에서 test.example.com의 콘텐츠를 제공하려 한다고 가정합니다. 다음 안내를 따르세요.

  1. 새 버킷 test.example.com을 만듭니다. example.com 도메인을 이미 확인했으므로 추가 확인 없이 하위 도메인을 지원하는 버킷을 만들 수 있습니다.

  2. 하위 도메인의 CNAME 레코드를 추가합니다.

    NAME                  TYPE     DATA
    test                  CNAME    c.storage.googleapis.com.
    

캐시 매개변수 설정

Cache-Control 메타데이터를 구성하여 웹사이트 애셋의 캐시 여부나 방식을 제어할 수 있습니다. 일반적으로 모든 익명 사용자가 액세스할 수 있는 객체에만 캐시 제어 메타데이터를 설정합니다. 이는 정적 웹사이트의 일부로 Cloud Storage 버킷에서 제공되는 모든 객체의 요구 사항입니다.

개발자가 명시적 캐시 제어 설정을 지정하지 않은 경우 Cloud Storage는 모든 익명 사용자가 액세스할 수 있는 객체에 3600초 캐시 제어 설정을 적용합니다. Cache-Control과 같은 객체 메타데이터를 설정하는 방법은 메타데이터 보기 및 수정을 참조하세요.

API 동작

MainPageSuffixNotFoundPage 웹사이트 구성은 CNAME 엔드포인트 또는 Cloud Load Balancing을 통해 Cloud Storage로 전달되는 요청에만 사용됩니다. 예를 들어 www.example.com에 대한 요청은 색인 페이지를 표시하지만 storage.googleapis.com/www.example.com에 대한 동일한 요청은 그렇지 않습니다.

따라서 storage.googleapis.com/www.example.com과 같은 Cloud Storage 도메인에 대한 요청의 API 동작이 유지됩니다. 예를 들어 다른 버킷에서처럼 www.example.com 버킷의 객체를 계속 나열할 수 있습니다. www.example.com 버킷의 경우 수신하는 객체 목록에 404.htmlindex.html이 포함됩니다.

동적 웹사이트의 정적 애셋 호스팅

Cloud Storage를 사용하여 Google App Engine 또는 Google Compute Engine에서 호스팅되는 동적 웹사이트의 정적 애셋을 호스팅할 수 있습니다. 버킷에서 이미지 또는 자바스크립트 파일과 같은 정적 애셋을 호스팅하면 다음과 같은 이점이 있습니다.

  • 공개적으로 읽을 수 있는 객체는 기본적으로 Cloud Storage 네트워크에 캐싱되므로 Cloud Storage는 기본적으로 콘텐츠 전송 네트워크(CDN)처럼 동작합니다.

  • 일반적으로 Cloud Storage를 사용하면 콘텐츠 액세스를 위한 대역폭 비용이 절감됩니다.

  • Cloud Storage에서 정적 콘텐츠를 제공하면 웹 서버의 부하가 줄어듭니다.

캐시 제어 요청 헤더를 사용하여 공개적으로 읽을 수 있는 정적 애셋에 대해 캐싱을 중지하거나 캐시 전체 기간을 설정하는 등의 방법으로 캐싱을 제어할 수도 있습니다. 자세한 내용은 캐시 매개변수 설정을 참조하세요.

동적 웹사이트의 고정 애셋을 호스팅할 때 정적 웹사이트처럼 CNAME 레코드를 만들고 동일한 이름의 버킷을 가리킬 필요가 없습니다. 예를 들어 적절한 애셋을 공개적으로 공유하도록 구성되어 있는 www_example_com_assets라는 버킷이 있고 Cloud Storage 도메인을 사용하여 이러한 애셋에 액세스할 수 있습니다. 예를 들어 공개적으로 공유되는 www_example_com_assets 버킷에 자바스크립트 파일 library.js가 있으면 이 파일에 http://storage.googleapis.com/www_example_com_assets/library.js로 액세스할 수 있습니다.

스토리지 요금 모니터링

정적 웹사이트로 구성된 버킷에서 애셋을 제공하거나 Cloud Storage 외부에서 호스팅되는 동적 웹사이트의 버킷에서 정적 애셋을 제공하는 경우 버킷이 포함된 프로젝트의 요금을 모니터링해야 합니다. 콘텐츠를 제공하면 콘텐츠 저장, 네트워크 사용, 검색 작업 수행을 위한 Cloud Storage 비용이 발생합니다. 자세한 내용은 Cloud Storage 가격 책정 페이지를 참조하세요.

가격 책정 페이지의 간단한 가격 책정 예시를 사용하여 트래픽이 적은 정적 웹사이트의 사용 사례에 대한 가격을 추정할 수 있습니다. 가격 계산기를 사용하여 예상 사용량을 기준으로 예상 비용을 산출할 수 있습니다.

새 Cloud Platform 사용자는 무료 체험판을 사용할 수 있습니다.

현재 Cloud Platform 사용자는 결제 페이지에서 프로젝트 비용의 상세 내역을 확인할 수 있습니다.

문제해결

정적 웹사이트 콘텐츠를 제공하도록 구성된 버킷을 사용할 때 발생할 수 있는 일반적인 문제는 문제해결을 참조하세요.

다음 단계

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

도움이 필요하시나요? 지원 페이지를 방문하세요.