이 페이지에서는 버킷을 사용하여 정적 웹사이트를 호스팅하는 예와 팁을 보여줍니다.
특수 페이지
색인 페이지
색인 페이지(webserver 디렉터리 색인이라고도 함)는 연결된 파일이 없는 URL 요청 시 방문자에게 제공되는 파일입니다. MainPageSuffix
속성을 할당하면 Cloud Storage는 방문자가 요청한 URL과 프리픽스가 일치하는 이름의 파일을 찾습니다.
예를 들어 정적 웹사이트의 MainPageSuffix
를 index.html
로 설정한다고 가정해 보겠습니다. 그리고 버킷 www.example.com
에 directory
라는 이름의 파일이 없다고 가정합니다. 이 상황에서 사용자가 URL http://www.example.com/directory
를 요청하면 Cloud Storage는 www.example.com/directory/index.html
파일을 제공하려고 시도합니다. 해당 파일이 존재하지 않으면 Cloud Storage는 오류 페이지를 반환합니다.
또한 사용자가 최상위 사이트를 요청하면 MainPageSuffix
가 제공되는 파일을 제어합니다. 위의 예를 계속해 보면, 사용자가 http://www.example.com
을 요청하면 Cloud Storage가 파일 www.example.com/index.html
을 제공하려고 시도합니다.
http://www.example.com/dir/
와 같이 뒤에 슬래시가 오는 URL에 액세스하려는 경우 문제해결을 참조하세요.
오류 페이지
오류 페이지는 기존 파일과 일치하지 않는 URL을 요청한 정적 사이트 방문자에게 반환되는 파일입니다. MainPageSuffix
를 할당한 경우, Cloud Storage는 요청된 이름의 파일이 없거나 해당 색인 페이지가 없는 경우에만 오류 페이지를 반환합니다.
오류 페이지가 반환되는 경우의 http 응답 코드는 404
입니다. 오류 페이지로 작동하는 파일을 제어하는 속성은 NotFoundPage
입니다. NotFoundPage
를 설정하지 않으면 사용자에게 일반 오류 페이지가 표시됩니다.
웹사이트 구성 예
객체가 3개 있는 버킷
www.example.com
이라는 버킷이 다음 설정과 파일을 사용하는 웹사이트로 구성되었다고 가정합니다.
MainPageSuffix
= 'index.html'NotFoundPage
= '404.html'- 버킷에는 'index.html', '404.html', 'dir/index.html'이라는 공개적으로 공유되는 객체가 세 개 있습니다.
다음 표에서는 선택한 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 |
객체가 2개 있는 버킷
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
의 콘텐츠를 제공하려 한다고 가정합니다. 방법은 다음과 같습니다.
추가 콘텐츠를 제공할 새 버킷을 만듭니다.
정적 웹사이트 호스팅의 가이드에 따라 HTTPS를 통해 콘텐츠를 제공하는 경우 Google Cloud Console에서 다음과 같이 부하 분산기를 수정합니다.
- 백엔드 구성의 경우 새로 만든 버킷을 선택하여 새 백엔드 버킷
test-bucket
을 만듭니다. - 호스트 및 경로 규칙에서 다음과 같이 새 규칙을 추가합니다.
Hosts Paths Backends test.example.com /* test-bucket
프런트엔드 구성에서 다음을 제외하고 첫 번째 구성과 동일한 값을 가진 새 프런트엔드 IP 및 포트를 추가합니다.
- IP 주소에서 새 IP 주소를 만들고 예약합니다.
- 인증서에서
test.example.com
의 새 SSL 인증서를 만듭니다.
- 백엔드 구성의 경우 새로 만든 버킷을 선택하여 새 백엔드 버킷
부하 분산기를 업데이트한 후 새 프런트엔드 구성의 IP 주소를 사용하여 도메인 등록 서비스에 새
A
레코드를 추가합니다.NAME TYPE DATA test A IP_ADDRESS
API 동작
MainPageSuffix
및 NotFoundPage
웹사이트 구성은 CNAME
또는 A
리디렉션을 통해 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.html
과 index.html
이 포함됩니다.
동적 웹사이트의 정적 애셋 호스팅
Cloud Storage를 사용하여 Google App Engine 또는 Google Compute Engine에서 호스팅되는 동적 웹사이트의 정적 애셋을 호스팅할 수 있습니다. 버킷에서 이미지 또는 자바스크립트 파일과 같은 정적 애셋을 호스팅하면 다음과 같은 이점이 있습니다.
공개적으로 읽을 수 있는 객체는 기본적으로 Cloud Storage 네트워크에 캐싱되므로 Cloud Storage는 콘텐츠 전송 네트워크(CDN)처럼 작동합니다.
일반적으로 콘텐츠 액세스를 위한 대역폭 비용이 Cloud Storage 사용 비용보다 적습니다.
Cloud Storage에서 정적 콘텐츠를 제공하면 웹 서버의 부하가 줄어듭니다.
동적 웹사이트의 정적 애셋을 호스팅할 때는 정적 웹사이트처럼 DNS 레코드를 만들고 버킷 또는 부하 분산기를 가리킬 필요가 없습니다. 예를 들어 적절한 애셋을 공개적으로 공유하도록 구성되어 있는 www_example_com_assets
라는 버킷이 있고 Cloud Storage 도메인을 사용하여 이러한 애셋에 액세스할 수 있습니다.
예를 들어 공개적으로 공유되는 www_example_com_assets
버킷에 자바스크립트 파일 library.js
가 있으면 이 파일에 http://storage.googleapis.com/www_example_com_assets/library.js
로 액세스할 수 있습니다.
캐시 매개변수 설정
Cache-Control
메타데이터를 구성하여 웹사이트 애셋의 캐시 여부나 방식을 제어할 수 있습니다. 일반적으로 모든 익명 사용자가 액세스할 수 있는 객체에만 캐시 제어 메타데이터를 설정합니다. 이는 정적 웹사이트의 일부로 Cloud Storage 버킷에서 제공되는 모든 객체의 요구 사항입니다.
Cloud Storage에서는 사용자가 명시적 캐시 제어 설정을 지정하지 않은 경우 모든 익명 사용자가 액세스할 수 있는 객체에 3600초의 캐시 제어 설정이 적용됩니다. Cache-Control
과 같은 객체 메타데이터를 설정하는 방법은 메타데이터 보기 및 수정을 참조하세요.
또한 Cloud CDN을 사용하여 사용자와 가까운 외부 HTTP(S) 부하 분산 콘텐츠를 캐시할 수 있으므로 제공 비용을 절감하는 경우가 많습니다. 자세한 내용은 캐싱을 참조하세요.
요금 모니터링
정적 웹사이트로 구성된 버킷에서 애셋을 제공하거나 Cloud Storage 외부에서 호스팅되는 동적 웹사이트의 버킷에서 정적 애셋을 제공하는 경우 버킷이 포함된 프로젝트의 요금을 모니터링해야 합니다. 콘텐츠를 제공하면 콘텐츠 저장, 네트워크 사용, 검색 작업 수행을 위한 Cloud Storage 비용이 발생합니다. 자세한 내용은 Cloud Storage 가격 책정 페이지를 참조하세요.
외부 애플리케이션 부하 분산기를 사용하여 HTTPS를 설정하는 경우 네트워킹 요금이 발생할 수도 있습니다. 자세한 내용은 네트워크 가격 책정을 참조하세요.
가격 책정 예시 페이지의 간단한 가격 책정 예시를 사용하여 트래픽이 적은 정적 웹사이트의 사용 사례에 대한 가격을 추정할 수 있습니다. 하지만 이 예시에는 정적 웹사이트 호스팅 비용에서 가장 큰 비중을 차지할 수 있는 외부 애플리케이션 부하 분산기 관련된 요금이 반영되지 않습니다. 가격 계산기를 사용하여 예상 사용량을 기준으로 예상 비용을 산출할 수 있습니다.
현재 Google Cloud 사용자는 결제 페이지에서 프로젝트 비용을 세부 항목별로 확인할 수 있습니다.
문제해결
정적 웹사이트 콘텐츠를 제공하도록 구성된 버킷을 사용할 때 발생할 수 있는 일반적인 문제는 문제해결을 참조하세요.
다음 단계
직접 사용해 보기
Google Cloud를 처음 사용하는 경우 계정을 만들어 실제 시나리오에서 Cloud Storage의 성능을 평가할 수 있습니다. 신규 고객에게는 워크로드를 실행, 테스트, 배포하는 데 사용할 수 있는 $300의 무료 크레딧이 제공됩니다.
Cloud Storage 무료로 사용해 보기