이 문서에서는 Google Cloud에서 웹사이트를 호스팅하는 방법을 설명합니다. Google Cloud는 웹사이트를 제공하기 위한 강력하고 유연하고 안정적이며 확장 가능한 플랫폼을 제공합니다. Google은 Google.com, YouTube, Gmail과 같은 사이트에서 콘텐츠를 제공하는 데 사용하는 것과 동일한 인프라를 사용하여 Google Cloud를 구축했습니다. 내 요구사항에 가장 잘 맞는 인프라 유형과 설계를 사용하여 웹사이트의 콘텐츠를 호스팅할 수 있습니다.
이 문서의 내용은 다음과 같은 경우에 유용합니다.
- 웹사이트 제작 방법을 잘 알고 있으며 이전에 웹 호스팅 인프라를 배포하고 운영한 경험이 있음
- 사이트를 Google Cloud로 마이그레이션할지 여부와 방법을 평가합니다.
간단한 웹사이트를 빌드하려면 구조화된 위키 및 웹페이지 작성 도구인 Google 사이트 도구를 사용해 보세요. 자세한 내용은 사이트 도움말을 참조하세요.
옵션 선택
Google Cloud를 처음 사용하는 경우 이미 익숙한 기술을 사용하여 시작하는 것이 합리적입니다. 예를 들어 현재 다른 클라우드 제공업체 또는 자체 하드웨어를 통해 하드웨어 서버나 가상 머신(VM)을 사용하여 사이트를 호스팅하는 경우 Compute Engine이 제공하는 패러다임도 크게 다르지 않습니다. 이미 Heroku, Engine Yard 등의 Platform as a Service(PaaS) 제품을 사용하고 있다면 App Engine부터 시작하면 좋습니다. 서버리스 컴퓨팅을 선호하는 경우 Cloud Run 옵션을 선택하는 것이 좋습니다.
Google Cloud에 어느 정도 익숙해졌다면 Google Cloud가 제공하는 다양한 제품과 서비스를 알아볼 수 있습니다. 예를 들어 Compute Engine을 사용하여 시작한 경우 Google Kubernetes Engine(GKE)을 사용하여 사이트의 기능을 보강하거나 일부 또는 전체 기능을 App Engine 및 Cloud Run으로 마이그레이션할 수 있습니다.
다음 표는 Google Cloud의 호스팅 옵션을 요약하여 보여줍니다.
| 옵션 | 제품 | 데이터 스토리지 | 부하 분산 | 확장성 | 로깅 및 모니터링 |
|---|---|---|---|---|---|
| 정적 웹사이트 | Cloud Storage Firebase 호스팅 |
Cloud Storage 버킷 | HTTP(S) 선택사항 |
자동 | |
| 가상 머신 | Compute Engine | Cloud SQL, Cloud Storage, Firestore, Bigtable 또는 다른 외부 저장소 제공업체를 사용할 수 있습니다. 하드 디스크 기반 영구 디스크(표준 영구 디스크) 및 SSD 영구 디스크 |
HTTP(S) TCP 프록시 SSL 프록시 IPv6 종료 네트워크 지역 간 내부 |
자동(관리형 인스턴스 그룹) | |
| 컨테이너 | GKE | Compute Engine과 비슷하지만 영구 디스크와 상호작용하는 방식이 다릅니다. |
네트워크 HTTP(S) |
클러스터 자동 확장 처리 | |
| 관리형 플랫폼 | App Engine |
Cloud SQL, Firestore, Cloud Storage 및 액세스 가능한 타사 데이터베이스와 같은 Google Cloud 서비스 | HTTP(S) Google에서 관리하는 설정 |
Google에서 관리하는 설정 | |
| 서버리스 | Cloud Run |
Cloud SQL, Firestore, Cloud Storage 및 액세스 가능한 타사 데이터베이스와 같은 Google Cloud 서비스 | HTTP(S) Google에서 관리하는 설정 |
Google에서 관리하는 설정 |
이 문서는 Google Cloud에서 웹을 호스팅하는 데 사용할 수 있는 주요 기술을 이해하는 데 도움이 되며 기술의 작동 방식을 간략하게 보여줍니다. 이 문서는 기초를 익힌 후 심화 학습에 도움이 되는 전체 문서, 가이드, 솔루션 문서로 연결되는 링크를 제공합니다.
비용 이해
비용에 대해서는 수많은 변수가 존재하고 구현마다 상황이 다르므로 이 문서에서는 비용에 대한 구체적인 조언을 드리지 않습니다. Google Cloud의 가격에 대한 Google의 원칙은 가격 책정 페이지를 참조하세요. 개별 서비스의 가격은 제품 가격 책정 섹션을 참조하세요. 가격 계산기를 사용하여 Google Cloud 사용량을 대략적으로 추정할 수도 있습니다. 사용하려는 서비스의 세부정보를 입력하면 추정 가격을 확인할 수 있습니다.
도메인 이름 서비스 설정
내 사이트에 맞는 적절한 도메인 이름을 등록하는 것이 일반적입니다. Google Domains와 같은 공개 도메인 이름 등록기관을 이용하여 사이트의 고유 이름을 등록할 수 있습니다. 자체 도메인 이름 시스템(DNS)을 완벽하게 제어하려는 경우 Cloud DNS를 DNS 제공업체로 사용할 수 있습니다. Cloud DNS 문서의 빠른 시작 부분을 참고하시기 바랍니다.
기존 DNS 제공업체를 그대로 이용하려는 경우 일반적으로 해당 제공업체에서 레코드를 몇 개 만들어야 합니다. example.com과 같은 도메인 이름에는 DNS 제공업체에서 A 레코드를 만듭니다. www.example.com 하위 도메인의 경우 www에 대한 CNAME 레코드를 만들어 example.com 도메인을 가리킵니다. A 레코드는 호스트 이름을 IP 주소에 매핑합니다.
CNAME 레코드는 A 레코드에 대한 별칭을 만듭니다.
도메인 이름 등록기관이 DNS 제공업체를 겸하는 경우 여기까지만 수행하면 됩니다. 등록과 DNS에 서로 다른 제공업체를 이용하는 경우 도메인 이름 등록기관에 내 도메인에 연결된 올바른 네임 서버가 있는지 확인해야 합니다.
DNS를 변경한 후 레코드 업데이트가 전파되려면 해당 영역의 TTL(수명) 값에 따라 어느 정도 시간이 걸립니다. 새 호스트 이름이라면 DNS 리졸버가 캐시된 이전 값을 갖지 않으므로 DNS 제공업체에 접촉하여 요청을 라우팅하는 데 필요한 정보를 가져오기 때문에 변경사항이 빠르게 적용됩니다.
정적 웹사이트 호스팅
HTTP(S)를 통해 웹사이트 콘텐츠를 제공하는 가장 간단한 방법은 정적 웹 페이지를 호스팅하는 것입니다. 정적 웹 페이지는 보통 HTML을 사용하여 작성된 그대로 변경 없이 제공됩니다. 사이트의 페이지가 블로그 게시물 또는 소규모 업체 웹사이트의 페이지와 같이 게시 후 변경될 일이 거의 없다면 정적 웹사이트가 좋은 옵션입니다. 정적 웹 페이지로도 많은 효과를 볼 수 있지만, 사이트에서 서버 측 코드를 통해 사용자와 긴밀하게 상호작용해야 한다면 이 문서에서 설명하는 다른 옵션을 고려해야 합니다.
Cloud Storage로 정적 웹사이트 호스팅
Cloud Storage에서 정적 사이트를 호스팅하려면 Cloud Storage 버킷을 만들고 콘텐츠를 업로드하고 새 사이트를 테스트해야 합니다. 데이터를 storage.googleapis.com에서 직접 제공할 수도 있고, 도메인 소유권을 인증한 후 내 도메인 이름을 사용할 수도 있습니다.
어떠한 방법으로든 정적 웹 페이지를 만들 수 있습니다. 예를 들어 HTML과 CSS로 페이지를 직접 작성할 수 있습니다. Jekyll, Ghost, Hugo 등의 정적 사이트 생성기를 사용하여 콘텐츠를 만들 수도 있습니다. 정적 사이트 생성기를 사용하면 마크다운을 작성하고 템플릿과 도구를 제공하여 정적 웹사이트를 제작할 수 있습니다. 사이트 생성기는 일반적으로 콘텐츠 미리보기를 표시하는 데 사용할 수 있는 로컬 웹 서버를 제공합니다.
정적 사이트를 가동한 후에는 원하는 프로세스를 사용하여 정적 페이지를 업데이트할 수 있습니다. 업데이트된 페이지를 버킷에 직접 복사하는 직관적인 프로세스를 사용할 수도 있습니다. 보다 자동화된 방식으로서, 콘텐츠를 GitHub에 저장하고 webhook을 사용하여 버킷을 업데이트하는 스크립트를 실행할 수도 있습니다. 더 진보된 시스템에서는 Jenkins와 같은 지속적 통합/지속적 배포(CI/CD) 도구를 사용하여 버킷의 콘텐츠를 업데이트할 수 있습니다. Jenkins의 Cloud Storage 플러그인은 빌드 아티팩트를 Cloud Storage에 게시하는 Google Cloud Storage Uploader 빌드 후 단계를 제공합니다.
웹 앱에서 정적 콘텐츠 또는 사용자가 업로드한 정적 미디어를 제공해야 하는 경우, Cloud Storage로 이 콘텐츠를 호스팅하고 제공하면 경제성과 효율성을 높이는 동시에 웹 앱에 대한 동적 요청 수를 줄일 수 있습니다.
또한 Cloud Storage는 사용자가 제출한 콘텐츠를 직접 수용할 수 있습니다. 사용자는 이 기능을 통해 서버 프록시를 거치지 않고도 대용량 미디어 파일을 안전하게 직접 업로드할 수 있습니다.
정적 웹사이트의 성능을 극대화하는 방법은 Cloud Storage 권장사항을 참조하세요.
자세한 내용은 다음 페이지를 참조하세요.
- 정적 웹사이트 호스팅
- Jenkins를 나타내는 J(블로그 게시물)
- Google Cloud의 Band Aid 30(블로그 게시물)
- Cloud Storage 문서
Firebase 호스팅으로 정적 웹사이트 호스팅
Firebase 호스팅은 빠르고 안전한 정적 웹 앱 호스팅을 제공합니다. Firebase 호스팅을 사용하면 한 번의 명령어로 웹 앱과 정적 콘텐츠를 글로벌 콘텐츠 전송 네트워크(CDN)에 배포할 수 있습니다.
Firebase 호스팅을 사용하면 다음과 같은 장점이 있습니다.
- Firebase 호스팅은 별도의 구성 없이 SSL을 기본적으로 제공합니다. 커스텀 도메인에 SSL 인증서를 무료로 프로비저닝합니다.
- 모든 콘텐츠가 HTTPS를 통해 제공됩니다.
- 콘텐츠가 전 세계 CDN 에지를 통해 사용자에게 전송됩니다.
- Firebase CLI가 불과 몇 초 만에 앱을 궤도에 올려 드립니다. 명령줄 도구로 빌드 프로세스에 배포 대상을 추가할 수 있습니다.
- 새로운 애셋의 원자적 배포, 완벽한 버전 관리, 클릭 한 번으로 롤백 같은 릴리스 관리 기능이 제공됩니다.
- 앱과 유사한 사이트 및 단일 페이지 앱에 유용한 구성이 제공됩니다.
- 다른 Firebase 기능과 원활하게 연동합니다.
자세한 내용은 다음 페이지를 참조하세요.
Compute Engine으로 가상 머신 사용
Infrastructure as a Service(IaaS) 사용 사례를 위해 Google Cloud는 Compute Engine을 제공합니다. Compute Engine은 강력한 컴퓨팅 인프라를 제공하지만, 사용할 플랫폼 구성요소를 잘 선택하여 구성해야 합니다. Compute Engine에서 시스템을 구성, 관리, 모니터링할 책임은 개발자에게 있습니다. 리소스의 가용성, 안정성, 준비성은 Google에서 관할하지만 리소스의 프로비저닝과 관리는 개발자가 담당합니다. 이로 인한 장점은 개발자가 시스템을 완벽하게 제어하면서 무제한의 유연성을 발휘할 수 있다는 것입니다.
상상할 수 있는 거의 모든 웹사이트 호스팅 시스템을 Compute Engine으로 설계 및 배포할 수 있습니다. 고유한 하드웨어 인프라가 있을 때와 마찬가지로, 인스턴스라고 부르는 VM을 사용하여 앱을 빌드합니다. Compute Engine이 제공하는 다양한 머신 유형을 통해 요구사항 및 예산에 따라 구성을 맞춤화할 수 있습니다. 운영체제, 개발 스택, 언어, 프레임워크, 서비스, 기타 소프트웨어 기술을 자유롭게 선택할 수 있습니다.
Google Cloud Marketplace로 자동 설정
완벽한 웹 호스팅 스택을 배포하는 가장 쉬운 방법은 Google Cloud Marketplace를 사용하는 것입니다. 단지 몇 번의 클릭만으로 Google Click to Deploy 또는 Bitnami를 통해 100가지 이상의 완벽한 실용 솔루션을 배포할 수 있습니다.
예를 들어 Cloud Marketplace에서 LAMP 스택 또는 WordPress를 설정할 수 있습니다. 시스템에서 완벽하게 작동하는 소프트웨어 스택을 단일 인스턴스에 몇 분 만에 배포해 줍니다. 배포하기 전에 Cloud Marketplace에서 예상되는 사이트 운영 비용과 함께 자동으로 설치되는 소프트웨어 구성요소의 버전을 명확히 표시하며, 이때 구성요소 인스턴스 이름을 변경하고 머신 유형 및 디스크 크기 등을 선택하여 구성을 맞춤화할 수 있습니다. 배포 후에는 Compute Engine 인스턴스, 구성, 소프트웨어를 완벽하게 제어할 수 있습니다.
수동 설정
또한 구성을 처음부터 새로 만들거나 Google Cloud Marketplace 배포를 기반으로 만들어 Compute Engine에 직접 인프라를 만들 수 있습니다. 예를 들어 Cloud Marketplace에서 제공하지 않는 특정 버전의 소프트웨어 구성요소를 사용하고 싶을 수도 있고, 모든 것을 직접 설치하고 구성하고 싶을 수도 있습니다.
웹사이트 설정의 전체 프레임워크 및 권장사항을 제시하는 것은 이 문서의 범위에 포함되지 않습니다. 그러나 개략적인 관점에서 볼 때, Compute Engine에 웹 호스팅 인프라를 설정하려면 기술적으로 다음과 같은 과정을 거쳐야 합니다.
- 요구사항 이해. 새 웹사이트를 개발하는 경우 인스턴스, 저장용량 소요, 네트워크 인프라 등 필요한 구성요소를 잘 이해해야 합니다. 기존 솔루션의 앱을 마이그레이션하는 경우라면 이러한 요구사항을 이미 파악하고 있겠지만 기존 설정이 Google Cloud 서비스에 어떻게 대응되는지를 고민해 볼 필요가 있습니다.
- 설계 기획. 아키텍처를 고려하여 설계를 작성합니다. 최대한 명시적으로 작성하시기 바랍니다.
- 구성요소 만들기. 컴퓨터, 네트워크 스위치 등 일반적으로는 물리적 애셋으로 고려되는 구성요소들이 Compute Engine에서는 서비스를 통해 제공됩니다. 예를 들어 컴퓨터가 필요하다면 Compute Engine 인스턴스를 만들어야 합니다. 영구 하드 디스크 드라이브가 필요하다면 그것도 만들어야 합니다. Terraform과 같은 코드형 인프라 도구를 사용하면 이 과정을 손쉽게 반복적으로 진행할 수 있습니다.
- 구성 및 맞춤설정. 원하는 구성요소가 만들어졌으면 각 요소를 구성하고 소프트웨어를 설치 및 구성하며 필요한 맞춤화 코드를 작성 및 배포합니다. 셸 스크립트를 실행하여 구성을 복제하면 이후에 빠르게 배포하는 데 도움이 됩니다. 이 과정에서도 리소스 자동 배포를 위한 유연한 선언적 구성 템플릿을 제공하는 Terraform이 도움이 됩니다. Puppet, Chef 등의 IT 자동화 도구를 활용할 수도 있습니다.
- 애셋 배포. 웹페이지와 이미지를 배포합니다.
- 테스트. 모든 요소가 정상적으로 작동하는지 확인합니다.
- 프로덕션 배포. 사이트를 널리 방문하고 사용하도록 일반에 공개합니다.
Compute Engine 인스턴스를 수동으로 설정하는 방법을 이해하고 작업을 시작하려면 다음과 같은 가이드를 이용해 보시기 바랍니다.
Compute Engine으로 데이터 저장
대부분의 웹사이트에는 특정한 저장소가 필요합니다. 스토리지는 사이트에서 사용하는 애셋 및 사용자가 업로드하는 파일을 저장하는 등 다양한 용도로 필요합니다.
Google Cloud는 다음을 포함한 다양한 관리형 스토리지 서비스를 제공합니다.
- Cloud SQL의 SQL 데이터베이스: MySQL, PostgreSQL, SQL Server를 위한 완전 관리형 관계형 데이터베이스 서비스입니다.
- NoSQL 데이터 스토리지를 위한 두 가지 옵션: Firestore 및 Bigtable
- Memorystore는 Redis 및 Memcached용 완전 관리형 인메모리 데이터 스토어 서비스입니다.
- 일관성, 확장성을 갖춘 Cloud Storage의 대용량 객체 스토리지.
Cloud Storage는 여러 클래스로 제공됩니다.
- 표준은 최대한의 가용성을 제공합니다.
- Nearline은 월 1회 미만으로 액세스하는 데이터에 적합한 경제적인 옵션을 제공합니다.
- Coldline은 분기당 1회 미만으로 액세스하는 데이터에 적합한 경제적인 옵션을 제공합니다.
- Archive는 보관처리, 백업, 재해 복구에 적합한 가장 경제적인 옵션입니다.
- 인스턴스의 기본 저장소로 사용되는 Compute Engine의 영구 디스크. Compute Engine은 하드 디스크 기반 영구 디스크(표준 영구 디스크) 및 SSD 영구 디스크를 제공합니다. 영구 디스크를 사용하여 Compute Engine에서 원하는 스토리지 기술을 설정할 수도 있습니다. 예를 들어 PostgreSQL을 SQL 데이터베이스로 설정하거나 MongoDB를 NoSQL 스토리지로 설정할 수 있습니다. 에Google Cloud서 제공되는 스토리지 서비스의 전체 범위와 각각의 장점은 스토리지 옵션 선택을 참조하세요.
Compute Engine으로 부하 분산
대규모로 운영되는 웹사이트에서는 부하 분산 기술로 여러 서버 간에 워크로드를 분산해야 하는 경우가 많습니다. 다음을 비롯하여 다양한 옵션으로 Compute Engine에서 부하 분산 웹 서버를 설계할 수 있습니다.
- HTTP(S) 부하 분산.
Cloud Load Balancing을 사용하는 기본적인 방법을 설명합니다.
- 콘텐츠 기반 부하 분산. 수신 URL에 따라 트래픽을 서로 다른 인스턴스로 분산하는 방법을 보여줍니다.
- 리전 간 부하 분산. 여러 리전에 VM 인스턴스를 구성하고 HTTP 또는 HTTPS 부하 분산을 통해 리전 간에 트래픽을 분산하는 방법을 보여줍니다.
- TCP 프록시 부하 분산. 여러 리전에서 운영되는 서비스에 글로벌 TCP 프록시 부하 분산을 설정하는 방법을 보여줍니다.
- SSL 프록시 부하 분산. 여러 리전에서 운영되는 서비스에 글로벌 SSL 프록시 부하 분산을 설정하는 방법을 보여줍니다.
- HTTP(S), SSL 프록시, TCP 프록시 부하 분산을 위한 IPv6 종료. IPv6 종료의 의미 및 IPv6 요청을 처리하도록 부하 분산기를 구성하는 방법을 설명합니다.
- 네트워크 부하 분산. 정상적인 인스턴스 간에 HTTP 트래픽을 분산하도록 Layer 3 부하 분산 구성을 설정하는 기본적인 시나리오를 보여줍니다.
- Microsoft IIS 백엔드를 사용한 리전 간 부하 분산. Compute Engine 부하 분산기를 사용하여 Microsoft 인터넷 정보 서비스(IIS) 서버로 트래픽을 분산하는 방법을 보여줍니다.
- 내부 부하 분산 설정 인터넷에 노출되지 않는 비공개 네트워크에 네트워크 트래픽을 분산하는 부하 분산기를 설정할 수 있습니다. 내부 부하 분산은 모든 트래픽이 비공개 네트워크에 유지되는 인트라넷 앱뿐 아니라 프런트엔드에서 비공개 네트워크를 통해 백엔드 서버로 요청을 전송하는 복잡한 웹 앱에도 유용합니다.
부하 분산 배포는 유연성이 있으므로 Compute Engine을 기존 솔루션과 함께 사용할 수 있습니다. 예를 들어 Nginx를 사용한 HTTP(S) 부하 분산은 Compute Engine 부하 분산기 대신 사용할 수 있는 솔루션 중 하나입니다.
Compute Engine으로 콘텐츠 배포
응답 시간은 모든 웹사이트에서 가장 중요한 측정항목 중 하나이며, 특히 글로벌 웹 트래픽을 처리하는 사이트에서는 CDN을 사용하여 지연 시간을 줄이고 성능을 높이는 것이 필수인 경우가 많습니다.
Cloud CDN에서는 전 세계에 분산된 Google의 에지 접속 지점을 활용하여 사용자와 가장 가까운 캐시 위치로부터 콘텐츠를 제공합니다. Cloud CDN은 HTTP(S) 부하 분산과 연동합니다. 단일 IP 주소로 Compute Engine, Cloud Storage 또는 둘 모두의 콘텐츠를 제공하려는 경우 HTTP(S) 부하 분산기에 대해 Cloud CDN을 사용 설정하기만 하면 됩니다.
Compute Engine으로 자동 확장
수요의 변화에 따라 서버를 추가 및 삭제할 수 있도록 아키텍처를 설정할 수 있습니다. 이 방식을 사용하면 최대 부하 상황에서도 사이트의 성능을 적절히 유지함과 동시에 일반적인 수요 상황에서는 비용을 억제할 수 있습니다. Compute Engine은 이러한 목적으로 사용할 수 있는 자동 확장 처리를 제공합니다.
자동 확장은 관리형 인스턴스 그룹의 기능입니다. 관리형 인스턴스 그룹은 공통의 인스턴스 템플릿에서 만든 동종의 가상 머신 인스턴스로 구성된 풀입니다. 자동 확장 처리는 관리형 인스턴스 그룹에서 인스턴스를 추가하거나 삭제합니다. Compute Engine에는 관리형 및 비관리형 인스턴스 그룹이 모두 있으며, 자동 확장 처리는 관리형 인스턴스 그룹에서만 사용할 수 있습니다. 자세한 내용은 Compute Engine의 자동 확장을 참조하세요.
확장성과 복원성을 겸비한 웹 앱 솔루션을 개발하는 데 대한 자세한 내용은 확장성과 복원성을 겸비한 웹 앱 개발을 참조하세요.
Compute Engine으로 로깅 및 모니터링
Google Cloud에는 웹사이트의 상황을 파악하는 데 사용할 수 있는 기능이 포함되어 있습니다.
Cloud Logging은 Google Cloud의 앱과 서비스에서 로그를 수집하고 저장합니다. Logging 에이전트를 사용하여 로그를 조회하거나 내보내고 타사 로그를 통합할 수 있습니다.
Cloud Monitoring은 사이트에 대한 대시보드와 알림을 제공합니다. Google Cloud Console로 Monitoring을 구성합니다. 클라우드 서비스, 가상 머신은 물론 MongoDB, Apache, Nginx, Elasticsearch 같이 널리 사용되는 오픈소스 서버의 성능 측정항목을 검토할 수 있습니다. Cloud Monitoring API를 사용하여 모니터링 데이터를 검색하고 커스텀 측정항목을 만들 수 있습니다.
또한 Cloud Monitoring은 웹사이트로 요청을 보내 응답하는지 확인하는 업타임 체크를 제공합니다. 업타임 체크가 실패하면 이슈를 만드는 알림 정책을 배포하여 웹사이트의 가용성을 모니터링할 수 있습니다.
Compute Engine으로 DevOps 관리
Compute Engine으로 DevOps를 관리하는 방법은 다음 문서를 참조하세요.
GKE로 컨테이너 사용
Docker 컨테이너와 같은 컨테이너를 이미 사용 중일 수 있습니다. 웹 호스팅에서 컨테이너는 다음과 같은 장점을 발휘합니다.
- 구성요소화. 웹 앱의 다양한 구성요소를 컨테이너로 분리할 수 있습니다. 예를 들어 사이트에서 웹 서버와 데이터베이스를 실행한다고 가정해 보겠습니다. 이러한 구성요소를 서로 다른 컨테이너에서 실행하면 서로에게 영향을 주지 않으면서 구성요소 하나를 수정하고 업데이트할 수 있습니다. 앱의 설계가 복잡할수록 컨테이너는 마이크로서비스를 포함한 서비스 지향 아키텍처에 적합합니다. 이러한 설계 유형은 무엇보다도 확장성을 지원합니다.
- 이식성. 컨테이너는 앱과 종속 항목이 하나의 번들을 이루므로 실행에 필요한 모든 것을 갖고 있습니다. 따라서 상세한 내부 시스템에 신경 쓰지 않고 다양한 플랫폼에서 컨테이너를 실행할 수 있습니다.
- 신속한 배포. 몇 가지 정의와 이미지만으로 시스템 배포를 준비할 수 있으므로 각 부분을 빠르고 안정적으로 자동 배포할 수 있습니다. 컨테이너는 일반적으로 크기가 작으며 가상 머신 등의 다른 솔루션보다 훨씬 빠르게 배포됩니다.
웹 호스팅에서 Google Cloud의 컨테이너 컴퓨팅은 이외에도 다음과 같은 장점을 발휘합니다.
- 조정. GKE는 Google이 도입한 오픈소스 컨테이너 조정 시스템인 Kubernetes를 기반으로 하는 관리형 서비스입니다. GKE에서는 여러 Compute Engine 인스턴스로 구성된 클러스터에 속하는 컨테이너에서 코드가 실행됩니다. 개별 컨테이너를 관리하거나 각 컨테이너를 직접 생성하고 종료하는 대신 GKE를 통해 클러스터를 자동으로 관리할 수 있습니다. GKE는 개발자가 정의하는 구성을 사용합니다.
- 이미지 등록. Container Registry 또는 Artifact Registry는 Google Cloud의 Docker 이미지에 대한 비공개 스토리지를 제공합니다. HTTPS 엔드포인트를 통해 레지스트리에 액세스할 수 있으므로 Compute Engine 인스턴스, 자체 하드웨어 등의 모든 머신에서 이미지를 가져올 수 있습니다. 레지스트리 서비스는 Cloud Storage에서 Google Cloud 프로젝트 아래에 커스텀 이미지를 호스팅합니다. 따라서 기본적으로 프로젝트의 액세스 권한이 있는 주 구성원만 커스텀 이미지에 액세스할 수 있습니다.
- 이동성. 다른 클라우드 제공업체로 자유롭게 이동하고 워크로드를 결합하거나, 클라우드 컴퓨팅 워크로드와 온프레미스 구현을 조합하여 하이브리드 솔루션을 만들 수 있습니다.
GKE로 데이터 저장
GKE는 Google Cloud에서 실행되며 Compute Engine 인스턴스를 노드로 사용하므로 스토리지 옵션은 Compute Engine의 스토리지와 상당 부분 겹칩니다. Cloud SQL, Cloud Storage, Firestore, Cloud Bigtable에 해당 API를 통해 액세스할 수도 있고, 필요하다면 다른 외부 저장소 제공업체를 이용할 수도 있습니다. 그러나 GKE는 일반적인 Compute Engine 인스턴스와 다른 방식으로 Compute Engine 영구 디스크와 상호작용합니다.
Compute Engine 인스턴스는 연결된 디스크를 포함합니다. Compute Engine을 사용할 때는 인스턴스가 존속하는 동안 디스크 볼륨이 인스턴스와 함께 유지됩니다. 디스크를 분리하고 다른 인스턴스에 사용할 수도 있습니다. 그러나 컨테이너의 경우 디스크 상의 파일은 일시적입니다. 비정상 종료 등의 이유로 컨테이너가 다시 시작되면 디스크 상의 파일이 사라집니다. Kubernetes는 볼륨 및 스토리지 클래스 추상화를 사용하여 이 문제를 해결합니다. 스토리지 클래스 유형 중 하나는 GCE PD입니다.
이 경우 GKE를 사용할 때 Compute Engine 영구 디스크와 컨테이너를 함께 사용하여 데이터 파일 삭제를 방지할 수 있습니다.
볼륨의 기능과 장점을 이해하려면 우선 pod에 대해 알아야 합니다. pod는 하나 이상의 컨테이너에 대한 논리적 앱별 호스트로 생각할 수 있습니다. pod는 노드 인스턴스에서 실행됩니다. pod에 속하는 여러 컨테이너는 공유 저장소 볼륨 세트를 포함하여 몇 가지 리소스를 공유할 수 있습니다. 이러한 볼륨을 통해 컨테이너가 다시 시작될 때 데이터를 유지하고 pod 내에서 컨테이너 간에 데이터를 공유할 수 있습니다. 물론 pod 안의 컨테이너와 볼륨을 하나만 사용할 수도 있지만, pod는 이러한 리소스를 서로 논리적으로 연결하는 필수적인 추상화 요소입니다.
자세한 내용은 WordPress 및 MySQL로 영구 디스크 사용 튜토리얼을 참조하세요.
GKE로 부하 분산
대규모 웹 호스팅 아키텍처에서는 트래픽 수요를 공유할 수 있는 여러 서버를 실행해야 하는 경우가 많습니다. GKE로 여러 컨테이너, 노드, 포드를 만들고 관리할 수 있으므로 부하 분산 웹 호스팅 시스템에 적합합니다.
네트워크 부하 분산 사용
GKE에서 부하 분산기를 만드는 가장 쉬운 방법은 Compute Engine의 네트워크 부하 분산을 사용하는 것입니다. 네트워크 부하 분산을 사용하면 주소, 포트, 프로토콜 유형과 같은 수신 인터넷 프로토콜 데이터를 기준으로 시스템의 부하를 분산할 수 있습니다. 네트워크 부하 분산에서는 전달 규칙을 사용합니다. 이러한 규칙은 부하 분산에 사용할 수 있는 인스턴스를 나열하는 대상 풀을 가리킵니다.
네트워크 부하 분산을 사용하면 SMTP 트래픽과 같은 추가적인 TCP/UDP 기반 프로토콜을 부하 분산하고 앱에서 패킷을 직접 조사할 수 있습니다.
서비스 구성 파일에 type: LoadBalancer 필드를 추가하기만 하면 네트워크 부하 분산을 배포할 수 있습니다.
HTTP(S) 부하 분산 사용
HTTPS 부하 분산, 콘텐츠 기반 부하 분산, 리전 간 부하 분산과 같은 진보된 부하 분산 기능이 필요하다면 GKE 서비스에 Compute Engine의 HTTP/HTTPS 부하 분산 기능을 통합할 수 있습니다. Kubernetes는 외부 트래픽을 Kubernetes 엔드포인트로 라우팅하는 규칙 모음을 캡슐화하는 인그레스 리소스를 제공합니다. GKE에서 인그레스 리소스는 Compute Engine HTTP/HTTPS 부하 분산기의 프로비저닝과 구성을 처리합니다.
GKE에서 HTTP/HTTPS 부하 분산을 사용하는 방법에 대한 자세한 내용은 인그레스로 HTTP 부하 분산 설정을 참조하세요.
GKE로 확장
클러스터 자동 확장 처리를 사용하여 클러스터 크기를 자동으로 조절할 수 있습니다. 이 기능은 여유 리소스가 있지만 예약되지 않은 노드를 기다리는 pod가 있는지 여부를 주기적으로 확인합니다. 이러한 pod가 존재하면 대기 중인 pod가 예약될 수 있도록 자동 확장 처리에서 노드 풀의 크기를 조절합니다.
또한 클러스터 자동 확장 처리는 모든 노드의 사용 현황을 모니터링합니다. 특정 노드가 불필요한 상태로 장기간 유지되고 모든 pod를 다른 위치에 예약할 수 있는 경우 해당 노드는 삭제됩니다.
클러스터 자동 확장 처리에 대한 세부정보, 제한사항, 권장사항은 클러스터 자동 확장 처리 문서를 참조하세요.
GKE로 로깅 및 모니터링
Compute Engine과 마찬가지로 Logging 및 Monitoring에서 로깅 및 모니터링 서비스를 제공합니다. Logging은 앱과 서비스에서 발생하는 로그를 수집하고 저장합니다. Logging 에이전트를 사용하여 로그를 조회하거나 내보내고 타사 로그를 통합할 수 있습니다.
Monitoring은 사이트에 대한 대시보드와 알림을 제공합니다. Google Cloud Console로 Monitoring을 구성합니다. 클라우드 서비스, 가상 머신은 물론 MongoDB, Apache, Nginx, Elasticsearch 같이 널리 사용되는 오픈소스 서버의 성능 측정항목을 검토할 수 있습니다. Monitoring API를 사용하여 모니터링 데이터를 검색하고 커스텀 측정항목을 만들 수 있습니다.
GKE로 DevOps 관리
GKE를 사용하면 일반적으로 알려진 DevOps에 따르는 장점을 상당 부분 누릴 수 있습니다. 특히 패키징, 배포, 관리가 쉬워집니다. CI/CD 워크플로 요구사항에 대해서는 Cloud Build 및 Cloud Deploy와 같이 클라우드용으로 빌드된 도구 또는 Jenkins와 같이 널리 사용되는 도구를 활용할 수 있습니다. 자세한 내용은 다음 도움말을 참조하세요.
App Engine으로 관리형 플랫폼에서 개발
Google Cloud의 관리형 Platform as a Service(PaaS)를 App Engine이라고 합니다. App Engine에 웹사이트를 구축할 때는 Google에서 지원 인프라를 관리해 주므로 기능을 코딩하는 데만 집중하면 됩니다. App Engine이 제공하는 광범위한 기능을 통해 모든 것을 직접 구축하고 관리할 때보다 훨씬 쉽게 확장성, 부하 분산, 로깅, 모니터링, 보안을 구현할 수 있습니다. App Engine에서 다양한 프로그래밍 언어로 코딩하면서 여러 가지 기타 Google Cloud 서비스를 활용할 수 있습니다.
App Engine은 안전한 샌드박스 환경에서 앱을 실행할 수 있는 표준 환경을 제공합니다. App Engine 표준 환경은 여러 서버 간에 요청을 분산하고 트래픽 수요에 맞춰 서버를 확장합니다. 서버의 하드웨어, 운영체제, 실제 위치에 영향을 받지 않는 안전하고 안정적인 자체 환경에서 앱이 실행됩니다.
App Engine은 선택의 폭을 넓히기 위해 가변형 환경을 제공합니다. 가변형 환경을 사용하면 구성 가능한 Compute Engine 인스턴스에서 앱이 실행되지만, 호스팅 환경은 App Engine에서 자동으로 관리합니다. 따라서 커스텀 런타임을 포함한 추가 런타임을 사용하여 프로그래밍 언어를 더욱 폭넓게 선택할 수 있습니다. 또한 Compute Engine이 제공하는 유연성을 활용하여 다양한 CPU 및 메모리 옵션 등을 선택할 수 있습니다.
프로그래밍 언어
App Engine 표준 환경은 기본 런타임을 제공하며, 개발자는 지원되는 프로그래밍 언어의 특정 버전으로 소스 코드를 작성합니다.
가변형 환경에서는 지원되는 프로그래밍 언어 중 임의의 버전으로 소스 코드를 작성합니다. 이러한 런타임을 맞춤설정할 수도 있고, 커스텀 Docker 이미지 또는 Dockerfile을 사용하여 자체 런타임을 제공할 수도 있습니다.
주로 사용하는 프로그래밍 언어가 지원되는지 여부가 중요하다면 App Engine 표준이 제공하는 런타임이 요구사항에 맞는지 여부를 판단해야 합니다. 그렇지 않다면 가변형 환경을 고려해야 합니다.
앱의 요구사항에 가장 잘 맞는 환경을 판단하려면 App Engine 환경 선택을 참조하세요.
언어별 시작하기 가이드
다음은 App Engine 표준 환경을 처음 사용할 때 도움이 되는 가이드입니다.
- Hello World(Python)
- Hello World(자바)
- Hello World(PHP)
- Hello World(Ruby)
- Hello World(Go)
- Hello World(Node.js)
다음은 가변형 환경을 처음 사용할 때 도움이 되는 가이드입니다.
App Engine으로 데이터 저장
App Engine이 제공하는 데이터 저장 옵션은 다음과 같습니다.
| 이름 | 구조 | 일관성 |
|---|---|---|
| Firestore | 스키마 없음 | 강력한 일관성 |
| Cloud SQL | 관계형 | 강력한 일관성 |
| Cloud Storage | 파일 및 관련 메타데이터 | 강력한 일관성(버킷 또는 객체의 목록을 가져오는 목록 작업 수행 시 제외) |
표준 환경에서 몇 가지 타사 데이터베이스를 사용할 수도 있습니다.
App Engine의 스토리지에 대한 자세한 내용은 스토리지 옵션 선택을 참조한 다음 원하는 프로그래밍 언어를 선택하세요.
가변형 환경을 사용할 때는 표준 환경에서 제공하는 스토리지 옵션뿐 아니라 더욱 폭넓은 타사 데이터베이스를 사용할 수 있습니다. 가변형 환경의 타사 데이터베이스에 대한 자세한 내용은 타사 데이터베이스 사용을 참조하세요.
App Engine으로 부하 분산 및 자동 확장
기본적으로 App Engine은 들어오는 요청을 적절한 백엔드 인스턴스로 자동 라우팅하며 부하 분산을 수행합니다. 하지만 Google Cloud의 모든 기능을 갖춘 엔터프라이즈급 HTTP(S) 부하 분산 기능을 활용하려면 서버리스 네트워크 엔드포인트 그룹을 사용하면 됩니다.
App Engine은 확장을 위해 트래픽 변동에 따라 자동으로 인스턴스를 만들고 종료하거나 트래픽 양과 관계없이 실행될 인스턴스 수를 지정할 수 있습니다.
App Engine으로 로깅 및 모니터링
App Engine에서는 요청이 자동으로 로깅되며 Google Cloud Console에서 이러한 로그를 볼 수 있습니다. 또한 App Engine은 로깅 기능을 제공하는 언어별 표준 라이브러리를 사용하여 로그 항목을 Google Cloud Console의 로그로 전달합니다. 예를 들어 Python으로 표준 Python 로깅 모듈을 사용하거나, 자바로 Logback 어펜더를 통합하거나, Cloud Logging에 java.util.logging를 통합할 수 있습니다. 이 접근 방식은 Cloud Logging의 모든 기능을 사용 설정하며 몇 줄의 Google Cloud 관련 코드만 필요로 합니다.
Cloud Monitoring은 App Engine 앱을 모니터링하는 기능을 제공합니다. Google Cloud Console을 통해 이슈, 업타임 체크, 기타 세부정보를 모니터링할 수 있습니다.
Cloud Run으로 서버리스 플랫폼에서 빌드
Google Cloud의 서버리스 플랫폼을 사용하면 기본 인프라에 대한 걱정 없이 원하는 방식에 따라 코드를 작성할 수 있습니다. Google Cloud의 스토리지, 데이터베이스, 머신러닝 등으로 전체 스택 서버리스 애플리케이션을 빌드할 수 있습니다.
컨테이너화된 웹사이트의 경우 GKE를 사용할 수 있을 뿐만 아니라 Cloud Run에 배포할 수도 있습니다. Cloud Run은 Google Cloud에서 확장성이 뛰어난 컨테이너화된 애플리케이션을 실행할 수 있게 해주는 완전 관리형 서버리스 플랫폼입니다. 코드가 실행된 시간에 대해서만 비용을 지불하면 됩니다.
컨테이너를 Cloud Run과 함께 사용하면 Nginx, Express.js, Django와 같은 안정적인 기술을 활용하여 웹사이트를 구축하고, Cloud SQL을 통해 SQL Database에 액세스하고, 동적 HTML 페이지를 렌더링할 수 있습니다.
Cloud Run 문서의 빠른 시작 부분을 참고하시기 바랍니다.
Cloud Run으로 데이터 저장
Cloud Run 컨테이너는 일시적이며, 이를 사용하려는 경우 사용 사례에 맞는 할당량 및 한도를 이해해야 합니다. 파일은 컨테이너 인스턴스에 임시로 저장하여 처리할 수 있지만 런타임 계약에 설명된 대로 이 스토리지는 서비스의 가용 메모리에서 제공됩니다.
영구 스토리지의 경우 App Engine과 마찬가지로 Cloud Storage, Firestore 또는 Cloud SQL과 같은 Google Cloud 서비스를 선택할 수 있습니다. 또는 타사 스토리지 솔루션을 사용할 수도 있습니다.
Cloud Run으로 부하 분산 및 자동 확장
기본적으로 Cloud Run을 빌드하면 수신 요청이 적절한 백엔드 컨테이너로 자동으로 라우팅되고 부하 분산이 수행됩니다. 하지만 Google Cloud의 모든 기능을 갖춘 엔터프라이즈급 HTTP(S) 부하 분산 기능을 활용하려면 서버리스 네트워크 엔드포인트 그룹을 사용하면 됩니다.
HTTP(S) 부하 분산을 사용하면 Cloud CDN을 사용 설정하거나 여러 리전에서 트래픽을 제공할 수 있습니다. 또한 API 게이트웨이와 같은 미들웨어를 사용하여 서비스를 개선할 수 있습니다.
Cloud Run의 경우 Google Cloud가 컨테이너 인스턴스 자동 확장을 자동으로 관리합니다. 각 버전은 수신되는 모든 요청을 처리하는 데 필요한 컨테이너 인스턴스 수에 맞게 자동으로 확장됩니다. 버전이 트래픽을 수신하지 않으면 기본적으로 0개의 컨테이너 인스턴스로 축소됩니다. 하지만 원하는 경우 이 기본값을 변경하여 최소 인스턴스 설정으로 이 인스턴스를 유휴 또는 준비 상태로 유지하도록 지정할 수 있습니다.
Cloud Run으로 로깅 및 모니터링
Cloud Run에는 Cloud Logging으로 자동 전송되는 두 가지 유형의 로그가 있습니다.
- 요청 로그: Cloud Run 서비스로 전송된 요청의 로그입니다. 이러한 로그는 자동으로 생성됩니다.
- 컨테이너 로그: 컨테이너 로그 작성에 설명된 대로 지원되는 위치에 작성된 컨테이너 인스턴스(일반적으로 자체 코드)에서 내보낸 로그입니다.
다음 두 가지 방법으로 서비스의 로그를 볼 수 있습니다.
- Google Cloud Console에서 Cloud Run 페이지를 사용합니다.
- Google Cloud Console에서 Cloud Logging 로그 탐색기를 사용합니다.
두 방법 모두 Cloud Logging에 저장된 동일한 로그를 검사하지만 로그 탐색기는 세부정보와 더 많은 필터링 기능을 제공합니다.
Cloud Monitoring은 특정 측정항목의 기준을 초과할 경우 알림을 전송하도록 Cloud Run 성능 모니터링, 측정항목, 업타임 체크와 함께 알림을 제공합니다. Google Cloud Observability 가격 책정이 적용됩니다. 즉, 완전 관리형 Cloud Run 버전의 측정항목에는 요금이 부과되지 않습니다. Cloud Monitoring 커스텀 측정항목을 사용할 수도 있습니다.
Cloud Run은 Cloud Monitoring과 통합되므로 설정이나 구성이 필요하지 않습니다. 즉, Cloud Run 서비스의 측정항목이 실행 중일 때 자동으로 캡처됩니다.
콘텐츠 관리 시스템 구축
웹사이트 호스팅에는 웹사이트 애셋 관리가 필수적으로 수반됩니다. Cloud Storage는 이러한 애셋을 위한 글로벌 저장소를 제공합니다. 널리 사용되는 아키텍처 중 하나는 Cloud Storage에 정적 콘텐츠를 배포하고 Compute Engine과 동기화하여 동적 페이지를 렌더링하는 것입니다. Cloud Storage는 WordPress, Drupal, Joomla 등의 다양한 타사 콘텐츠 관리 시스템과 연동합니다. 또한 Cloud Storage는 Amazon S3 호환 API를 제공하므로 Amazon S3와 연동하는 모든 시스템은 Cloud Storage와도 연동이 가능합니다.
아래 다이어그램은 콘텐츠 관리 시스템의 샘플 아키텍처입니다.
다음 단계
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기 Cloud 아키텍처 센터 살펴보기