웹사이트 제공

이 문서에서는 Google Cloud Platform(GCP)에 웹사이트를 호스팅하는 방법에 대해 설명합니다. GCP는 웹사이트 제공을 위한 강력하고 유연하며 안정성과 확장성이 높은 플랫폼을 제공합니다. Google이 GCP를 구축하는 데 사용하는 인프라는 Google.com, YouTube, Gmail 등의 사이트에서 Google이 콘텐츠를 제공하는 데 사용하는 인프라와 동일합니다. 내 요구사항에 가장 잘 맞는 인프라 유형과 설계를 사용하여 웹사이트의 콘텐츠를 제공할 수 있습니다.

이 문서의 내용은 다음과 같은 경우에 유용합니다.

  • 웹사이트 제작 방법을 잘 알고 있으며 이전에 웹 제공 인프라를 배포하고 운영한 경험이 있음
  • 사이트를 GCP로 이전할지 여부를 판단 중

간단한 웹사이트를 빌드하려면 구조화된 위키 및 웹페이지 작성 도구인 Google 사이트 도구를 사용해 보세요. 자세한 내용은 사이트 도움말을 참조하세요.

옵션 선택

GCP를 처음으로 사용하는 경우라면 우선 이미 친숙한 기술과 비교해 보면 이해가 빠를 수 있습니다. 예를 들어 현재 다른 클라우드 제공업체 또는 자체 하드웨어를 통해 하드웨어 서버나 가상 머신(VM)을 사용하여 사이트를 호스팅하는 경우, Compute Engine이 제공하는 패러다임도 크게 다르지 않습니다. 이미 Heroku, Engine Yard 등의 Platform as a Service(PaaS) 제품을 사용하고 있다면 App Engine부터 시작하면 좋습니다.

GCP에 어느 정도 익숙해졌다면 GCP가 제공하는 다양한 제품과 서비스를 알아볼 수 있습니다. 예를 들어 우선 Compute Engine부터 시작했다면 Google Kubernetes Engine(GKE)을 사용하여 사이트 기능을 보강하거나 일부 또는 전체 기능을 App Engine으로 이전할 수 있습니다.

다음은 GCP의 호스팅 옵션을 요약한 표입니다.

옵션 제품 데이터 스토리지 부하 분산 확장성 로깅
정적 웹사이트

Cloud Storage

Firebase 호스팅

Cloud Storage 버킷 해당 사항 없음 자동 해당 사항 없음
가상 머신 Compute Engine

Cloud SQL API, Cloud Storage API, Cloud Datastore API, Cloud Bigtable API를 사용하거나 다른 외부 스토리지 제공업체를 이용할 수 있습니다.

하드 디스크 기반 영구 디스크(표준 영구 디스크) 및 SSD 영구 디스크

HTTP(S)

TCP 프록시

SSL 프록시

IPv6 종료

네트워크

지역 간

내부

자동(관리형 인스턴스 그룹)

Stackdriver Logging

Stackdriver Monitoring

Monitoring Console

컨테이너 GKE Compute Engine과 비슷하지만 영구 디스크와 상호작용하는 방식이 다릅니다. 네트워크
HTTP(S)
클러스터 자동 확장 처리

Stackdriver Logging

Stackdriver Monitoring

Monitoring Console

관리형 플랫폼 App Engine Google이 자동으로 처리 Google이 자동으로 처리 Google이 자동으로 처리 Google이 자동으로 처리

이 문서를 읽어보면 GCP에서 웹 제공에 사용할 수 있는 주요 기술을 이해하고 이러한 기술의 원리를 들여다볼 수 있습니다. 이 문서는 기초를 익힌 후 심화 학습에 도움이 되는 전체 문서, 가이드, 솔루션 문서로 연결되는 링크를 제공합니다.

비용 이해

비용에 대해서는 수많은 변수가 존재하고 구현마다 상황이 다르므로 이 문서에서는 비용에 대한 구체적인 조언을 드리지 않습니다. GCP의 가격 체계에 대한 Google의 원칙은 가격 책정 페이지를 참조하세요. 개별 서비스의 가격은 제품 가격 책정 섹션을 참조하세요. 몇 가지 도구를 사용하여 GCP 사용 비용을 평가할 수도 있습니다.

  • GCP 사용이 어떻게 되는지 추정하려면 가격 계산기를 사용합니다. 사용하려는 서비스의 세부정보를 입력하면 추정 가격을 확인할 수 있습니다.
  • GCP에서 컴퓨팅 부하를 실행하는 데 필요한 상대적 비용을 평가하려면 총 소유 비용(TCO) 도구를 사용합니다. 비용 모델링을 위해 이 도구에서 제공하는 몇 가지 입력을 조정한 다음 GCP와 Amazon Web Services(AWS)의 예상 비용을 비교할 수 있습니다. 이 도구가 일반적인 앱의 스토리지, 네트워크와 같은 모든 구성요소를 모델링하지는 않습니다.

도메인 이름 서비스 설정

내 사이트에 맞는 적절한 도메인 이름을 등록하는 것이 일반적입니다. 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 권장사항을 참조하세요.

자세한 내용은 다음 페이지를 참조하세요.

Firebase 호스팅으로 정적 웹사이트 호스팅

Firebase 호스팅은 빠르고 안전한 정적 웹 앱 호스팅을 제공합니다. Firebase 호스팅을 사용하면 한 번의 명령으로 웹 앱과 정적 콘텐츠를 글로벌 콘텐츠 전송 네트워크(CDN)에 배포할 수 있습니다.

Firebase 호스팅을 사용하면 다음과 같은 장점이 있습니다.

  • Firebase 호스팅은 별도의 구성 없이 SSL을 기본적으로 제공합니다. 커스텀 도메인에 SSL 인증서를 무료로 프로비저닝합니다.
  • 모든 콘텐츠가 HTTPS를 통해 제공됩니다.
  • 콘텐츠가 전 세계 CDN 에지를 통해 사용자에게 전송됩니다.
  • Firebase CLI가 불과 몇 초 만에 앱을 궤도에 올려 드립니다. 명령줄 도구로 빌드 프로세스에 배포 대상을 추가할 수 있습니다.
  • 새로운 애셋의 원자적 배포, 완벽한 버전 관리, 클릭 한 번으로 롤백 같은 릴리스 관리 기능이 제공됩니다.
  • 앱과 유사한 사이트 및 단일 페이지 앱에 유용한 구성이 제공됩니다.
  • 다른 Firebase 기능과 원활하게 연동합니다.

자세한 내용은 다음 페이지를 참조하세요.

Compute Engine으로 가상 머신 사용

Infrastructure as a Service(IaaS) 사용 사례를 위해 GCP는 Compute Engine을 제공합니다. Compute Engine은 강력한 컴퓨팅 인프라를 제공하지만, 사용할 플랫폼 구성요소를 잘 선택하여 구성해야 합니다. Compute Engine에서 시스템을 구성, 관리, 모니터링할 책임은 개발자에게 있습니다. 리소스의 가용성, 안정성, 준비성은 Google에서 관할하지만 리소스의 프로비저닝과 관리는 개발자가 담당합니다. 이로 인한 장점은 개발자가 시스템을 완벽하게 제어하면서 무제한의 유연성을 발휘할 수 있다는 것입니다.

상상할 수 있는 거의 모든 웹사이트 제공 시스템을 Compute Engine으로 설계 및 배포할 수 있습니다. 고유한 하드웨어 인프라가 있을 때와 마찬가지로, 인스턴스라고 부르는 VM을 사용하여 앱을 빌드합니다. Compute Engine이 제공하는 다양한 머신 유형을 통해 요구사항 및 예산에 따라 구성을 맞춤화할 수 있습니다. 운영체제, 개발 스택, 언어, 프레임워크, 서비스, 기타 소프트웨어 기술을 자유롭게 선택할 수 있습니다.

GCP Marketplace로 자동 설정

완벽한 웹 제공 스택을 배포하는 가장 쉬운 방법은 GCP Marketplace를 사용하는 것입니다. 단지 몇 번의 클릭만으로 Google Click to Deploy 또는 Bitnami를 통해 100가지 이상의 완벽한 실용 솔루션을 배포할 수 있습니다.

GCP Marketplace

예를 들어 GCP Marketplace에서 LAMP 스택 또는 WordPress를 설정할 수 있습니다. 시스템에서 완벽하게 작동하는 소프트웨어 스택을 단일 인스턴스에 몇 분 만에 배포해 줍니다. 배포하기 전에 GCP Marketplace에서 예상되는 사이트 운영 비용과 함께 자동으로 설치되는 소프트웨어 구성요소의 버전을 명확히 표시하며, 이때 구성요소 인스턴스 이름을 변경하고 머신 유형 및 디스크 크기 등을 선택하여 구성을 맞춤화할 수 있습니다. 배포 후에는 Compute Engine 인스턴스, 구성, 소프트웨어를 완벽하게 제어할 수 있습니다.

수동 설정

Compute Engine에 인프라를 직접 만들 수도 있습니다. 구성을 처음부터 작성하거나 GCP Marketplace 배포를 기반으로 작성하는 방법이 가능합니다. 예를 들어 소프트웨어 구성요소 중 GCP Marketplace에서 제공하지 않는 특정 버전이 필요할 수도 있고, 취향에 따라 모든 요소를 직접 설치하고 구성할 수도 있습니다.

웹사이트 설정의 전체 프레임워크 및 권장사항을 제시하는 것은 이 문서의 범위에 포함되지 않습니다. 그러나 개략적인 관점에서 볼 때, Compute Engine에 웹 제공 인프라를 설정하려면 기술적으로 다음과 같은 과정을 거쳐야 합니다.

  • 요구사항 이해. 새 웹사이트를 개발하는 경우 인스턴스, 저장용량 소요, 네트워크 인프라 등 필요한 구성요소를 잘 이해해야 합니다. 기존 솔루션의 앱을 이전하는 경우라면 이러한 요구사항을 이미 파악했을 것이지만, 기존 설정이 GCP 서비스에 어떻게 대응되는지를 고민해 볼 필요가 있습니다.
  • 설계 기획. 아키텍처를 고려하여 설계를 작성합니다. 최대한 명시적으로 작성하시기 바랍니다.
  • 구성요소 만들기. 컴퓨터, 네트워크 스위치 등 일반적으로는 물리적 애셋으로 고려되는 구성요소들이 Compute Engine에서는 서비스를 통해 제공됩니다. 예를 들어 컴퓨터가 필요하다면 Compute Engine 인스턴스를 만들어야 합니다. 영구 하드 디스크 드라이브가 필요하다면 그것도 만들어야 합니다. Cloud Deployment Manager로 이 과정을 손쉽게 반복적으로 진행할 수 있습니다.
  • 구성 및 맞춤화. 원하는 구성요소가 만들어졌으면 각 요소를 구성하고 소프트웨어를 설치 및 구성하며 필요한 맞춤화 코드를 작성 및 배포합니다. 셸 스크립트를 실행하여 구성을 복제하면 이후에 빠르게 배포하는 데 도움이 됩니다. 이 과정에서도 리소스 자동 배포를 위한 유연한 선언적 구성 템플릿을 제공하는 Deployment Manager가 도움이 됩니다. Puppet, Chef 등의 IT 자동화 도구를 활용할 수도 있습니다.
  • 애셋 배포. 웹페이지와 이미지를 배포합니다.
  • 테스트. 모든 요소가 정상적으로 작동하는지 확인합니다.
  • 프로덕션 배포. 사이트를 널리 방문하고 사용하도록 일반에 공개합니다.

Compute Engine 인스턴스를 수동으로 설정하는 방법을 이해하고 작업을 시작하려면 다음과 같은 가이드를 이용해 보시기 바랍니다.

Compute Engine으로 데이터 저장

대부분의 웹사이트에는 특정한 저장소가 필요합니다. 저장소가 필요한 이유는 사이트에서 사용하는 애셋 및 사용자가 업로드하는 파일을 저장하는 등 다양합니다.

GCP는 다음과 같은 다양한 관리형 저장소 서비스를 제공합니다.

  • MySQL을 기반으로 하는 Cloud SQL의 SQL 데이터베이스
  • NoSQL 데이터 스토리지를 위한 두 가지 옵션: Cloud DatastoreCloud Bigtable
  • 일관성, 확장성을 갖춘 Cloud Storage의 대용량 객체 스토리지. Cloud Storage는 여러 옵션으로 제공됩니다.
    • Multi-Regional: 최대한의 가용성과 지역 중복성을 제공합니다.
    • Regional: 최대한의 가용성과 지역화된 저장소 위치를 제공합니다.
    • Nearline: 액세스 빈도가 월 1회 미만인 데이터에 적합한 경제적인 옵션입니다.
    • Coldline: 보관, 백업, 재해 복구에 적합한 가장 경제적인 옵션입니다.
  • 인스턴스의 기본 스토리지로 사용되는 Compute Engine의 영구 디스크. Compute Engine은 하드 디스크 기반 영구 디스크(표준 영구 디스크) 및 SSD 영구 디스크를 제공합니다. 영구 디스크를 사용하여 Compute Engine에서 원하는 스토리지 기술을 설정할 수도 있습니다. 예를 들어 PostgreSQL을 SQL 데이터베이스로 설정하거나 MongoDB를 NoSQL 스토리지로 설정할 수 있습니다. GCP에서 제공되는 스토리지 서비스의 전체 범위와 각각의 장점은 스토리지 옵션 선택을 참조하세요.

Compute Engine으로 부하 분산

대규모로 운영되는 웹사이트에서는 부하 분산 기술로 여러 서버 간에 작업 부하를 분산해야 하는 경우가 많습니다. 다음을 비롯하여 다양한 옵션으로 Compute Engine에서 부하 분산 웹 서버를 설계할 수 있습니다.

  • HTTP(S) 부하 분산. 클라우드 부하 분산기를 사용하는 기본적인 방법을 설명합니다.
    • 콘텐츠 기반 부하 분산. 수신 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을 기존 솔루션과 함께 사용할 수 있습니다. HAProxy 부하 분산 계층과 백엔드 서버 계층을 모두 자동 확장하는 방법은 HAProxy 및 Consul을 사용한 자동 확장 내부 부하 분산을 참조하세요. Compute Engine 부하 분산기 대신 사용할 수 있는 솔루션 중 하나는 NGINX를 사용한 HTTP(S) 부하 분산을 참조하세요.

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으로 로깅 및 모니터링

GCP에는 웹사이트의 상황을 파악하는 데 사용할 수 있는 기능이 포함되어 있습니다.

Stackdriver Logging은 GCP의 앱 및 서비스에서 발생하는 로그를 수집하고 저장합니다. 로깅 에이전트를 사용하여 로그를 조회하거나 내보내고 타사 로그를 통합할 수 있습니다.

로깅

Stackdriver Monitoring은 사이트에 대한 대시보드와 알림을 제공합니다. Monitoring 콘솔을 사용하여 Monitoring을 구성할 수 있으며 클라우드 서비스, 가상 머신은 물론 MongoDB, Apache, Nginx, Elasticsearch 같이 널리 사용되는 오픈소스 서버의 성능 측정항목을 검토할 수 있습니다. Stackdriver Monitoring API를 사용하여 모니터링 데이터를 검색하고 커스텀 측정항목을 만들 수 있습니다.

Monitoring 대시보드

Compute Engine으로 DevOps 관리

Compute Engine으로 DevOps를 관리하는 방법은 다음 문서를 참조하세요.

GKE로 컨테이너 사용

Docker 컨테이너와 같은 컨테이너를 이미 사용 중일 수 있습니다. 웹 제공에서 컨테이너는 다음과 같은 장점을 발휘합니다.

  • 구성요소화. 웹 앱의 다양한 구성요소를 컨테이너로 분리할 수 있습니다. 예를 들어 사이트에서 웹 서버와 데이터베이스를 실행한다고 가정해 보겠습니다. 이러한 구성요소를 서로 다른 컨테이너에서 실행하면 서로에게 영향을 주지 않으면서 구성요소 하나를 수정하고 업데이트할 수 있습니다. 앱의 설계가 복잡할수록 컨테이너는 마이크로서비스를 포함한 서비스 지향 아키텍처에 적합합니다. 이러한 설계 유형은 무엇보다도 확장성을 지원합니다.
  • 이식성. 컨테이너는 앱과 종속 항목이 하나의 번들을 이루므로 실행에 필요한 모든 것을 갖고 있습니다. 따라서 상세한 내부 시스템에 신경 쓰지 않고 다양한 플랫폼에서 컨테이너를 실행할 수 있습니다.
  • 신속한 배포. 몇 가지 정의와 이미지만으로 시스템 배포를 준비할 수 있으므로 각 부분을 빠르고 안정적으로 자동 배포할 수 있습니다. 컨테이너는 일반적으로 크기가 작으며 가상 머신 등의 다른 솔루션보다 훨씬 빠르게 배포됩니다.

웹 제공에서 GCP의 컨테이너 컴퓨팅은 이외에도 다음과 같은 장점을 발휘합니다.

  • 조정. GKE는 Google이 도입한 오픈소스 컨테이너 조정 시스템인 Kubernetes를 기반으로 하는 관리형 서비스입니다. GKE에서는 여러 Compute Engine 인스턴스로 구성된 클러스터에 속하는 컨테이너에서 코드가 실행됩니다. 개별 컨테이너를 관리하거나 각 컨테이너를 직접 생성하고 종료하는 대신 GKE를 통해 클러스터를 자동으로 관리할 수 있습니다. GKE는 개발자가 정의하는 구성을 사용합니다.
  • 이미지 등록. Container Registry는 GCP의 Docker 이미지에 대한 비공개 스토리지를 제공합니다. HTTPS 엔드포인트를 통해 Container Registry에 액세스할 수 있으므로 Compute Engine 인스턴스, 자체 하드웨어 등의 모든 머신에서 이미지를 가져올 수 있습니다. 레지스트리 서비스는 Cloud Storage에서 GCP 프로젝트 아래에 커스텀 이미지를 호스팅합니다. 따라서 기본적으로 프로젝트의 구성원만 커스텀 이미지에 액세스할 수 있습니다.
  • 이동성. 다른 클라우드 제공업체로 자유롭게 이동하고 작업 부하를 결합하거나, 클라우드 컴퓨팅 작업 부하와 온프레미스 구현을 조합하여 하이브리드 솔루션을 만들 수 있습니다.

GKE로 데이터 저장

GKE는 GCP에서 실행되며 Compute Engine 인스턴스를 노드로 사용하므로 스토리지 옵션은 Compute Engine의 스토리지와 상당 부분 겹칩니다. Cloud SQL, Cloud Storage, Cloud Datastore, Cloud Bigtable에 해당 API를 통해 액세스할 수도 있고, 필요하다면 다른 외부 스토리지 제공업체를 이용할 수도 있습니다. 그러나 GKE는 일반적인 Compute Engine 인스턴스와 다른 방식으로 Compute Engine 영구 디스크와 상호작용합니다.

Compute Engine 인스턴스는 연결된 디스크를 포함합니다. Compute Engine을 사용할 때는 인스턴스가 존속하는 동안 디스크 볼륨이 인스턴스와 함께 유지됩니다. 디스크를 분리하고 다른 인스턴스에 사용할 수도 있습니다. 그러나 컨테이너의 경우 디스크 상의 파일은 일시적입니다. 비정상 종료 등의 이유로 컨테이너가 다시 시작되면 디스크 상의 파일이 사라집니다. Kubernetes는 볼륨 추상화를 사용하여 이 문제를 해결하며, 볼륨 유형 중 하나는 gcePersistentDisk입니다. 이 경우 GKE를 사용할 때 Compute Engine 영구 디스크와 컨테이너를 함께 사용하여 데이터 파일 삭제를 방지할 수 있습니다.

볼륨의 기능과 장점을 이해하려면 우선 pod에 대해 알아야 합니다. 포드는 하나 이상의 컨테이너에 대한 논리적 앱별 호스트로 생각할 수 있습니다. 포드는 노드 인스턴스에서 실행됩니다. 포드에 속하는 여러 컨테이너는 공유 저장소 볼륨 세트를 포함하여 몇 가지 리소스를 공유할 수 있습니다. 이러한 볼륨을 통해 컨테이너가 다시 시작될 때 데이터를 유지하고 포드 내에서 컨테이너 간에 데이터를 공유할 수 있습니다. 물론 pod 안의 컨테이너와 볼륨을 하나만 사용할 수도 있지만, pod는 이러한 리소스를 서로 논리적으로 연결하는 필수적인 추상화 요소입니다.

자세한 내용은 WordPress 및 MySQL로 영구 디스크 사용 가이드를 참조하세요.

GKE로 부하 분산

대규모 웹 제공 아키텍처에서는 트래픽 수요를 공유할 수 있는 여러 서버를 실행해야 하는 경우가 많습니다. GKE로 여러 컨테이너, 노드, pod를 만들고 관리할 수 있으므로 부하 분산 웹 제공 시스템에 적합합니다.

네트워크 부하 분산 사용

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과 마찬가지로 LoggingMonitoring에서 로깅 및 모니터링 서비스를 제공합니다. Logging은 앱과 서비스에서 발생하는 로그를 수집하고 저장합니다. 로깅 에이전트를 사용하여 로그를 조회하거나 내보내고 타사 로그를 통합할 수 있습니다.

Monitoring은 사이트에 대한 대시보드와 알림을 제공합니다. Monitoring 콘솔을 사용하여 Monitoring을 구성할 수 있으며 클라우드 서비스, 가상 머신은 물론 MongoDB, Apache, Nginx, Elasticsearch 같이 널리 사용되는 오픈소스 서버의 성능 측정항목을 검토할 수 있습니다. Monitoring API를 사용하여 모니터링 데이터를 검색하고 커스텀 측정항목을 만들 수 있습니다.

GKE로 DevOps 관리

GKE를 사용하면 일반적으로 알려진 DevOps에 따르는 장점을 상당 부분 누릴 수 있습니다. 특히 패키징, 배포, 관리가 쉬워집니다. CI/CD 워크플로 요구사항에 대해서는 Jenkins와 같이 널리 사용되는 도구를 활용할 수 있습니다. 다음과 같은 도움말을 참조하세요.

App Engine으로 관리형 플랫폼에서 개발

GCP의 관리형 Platform as a Service(PaaS)를 App Engine이라고 합니다. App Engine에 웹사이트를 구축할 때는 Google에서 지원 인프라를 관리해 주므로 기능을 코딩하는 데만 집중하면 됩니다. App Engine이 제공하는 광범위한 기능을 통해 모든 것을 직접 구축하고 관리할 때보다 훨씬 쉽게 확장성, 부하 분산, 로깅, 모니터링, 보안을 구현할 수 있습니다. App Engine에서 다양한 프로그래밍 언어로 코딩하면서 여러 가지 기타 GCP 서비스를 활용할 수 있습니다.

App Engine은 안전한 샌드박스 환경에서 앱을 실행할 수 있는 표준 환경을 제공합니다. App Engine 표준 환경은 여러 서버 간에 요청을 분산하고 트래픽 수요에 맞춰 서버를 확장합니다. 서버의 하드웨어, 운영체제, 실제 위치에 영향을 받지 않는 안전하고 안정적인 자체 환경에서 앱이 실행됩니다.

App Engine 및 기타 구성요소를 사용하는 웹 앱

App Engine은 선택의 폭을 넓히기 위해 가변형 환경을 제공합니다. 가변형 환경을 사용하면 구성 가능한 Compute Engine 인스턴스에서 앱이 실행되지만, 호스팅 환경은 App Engine에서 자동으로 관리합니다. 따라서 커스텀 런타임을 포함한 추가 런타임을 사용하여 프로그래밍 언어를 더욱 폭넓게 선택할 수 있습니다. 또한 Compute Engine이 제공하는 유연성을 활용하여 다양한 CPU 및 메모리 옵션 등을 선택할 수 있습니다.

프로그래밍 언어

App Engine 표준 환경은 기본 런타임을 제공하며, 개발자는 지원되는 프로그래밍 언어의 특정 버전으로 소스 코드를 작성합니다.

가변형 환경에서는 지원되는 프로그래밍 언어 중 임의의 버전으로 소스 코드를 작성합니다. 이러한 런타임을 맞춤설정할 수도 있고, 커스텀 Docker 이미지 또는 Dockerfile을 사용하여 자체 런타임을 제공할 수도 있습니다.

주로 사용하는 프로그래밍 언어가 지원되는지 여부가 중요하다면 App Engine 표준이 제공하는 런타임이 요구사항에 맞는지 여부를 판단해야 합니다. 그렇지 않다면 가변형 환경을 고려해야 합니다.

앱의 요구사항에 가장 잘 맞는 환경을 판단하려면 App Engine 환경 선택을 참조하세요.

언어별 시작하기 가이드

다음은 App Engine 표준 환경을 처음 사용할 때 도움이 되는 가이드입니다.

다음은 가변형 환경을 처음 사용할 때 도움이 되는 가이드입니다.

App Engine으로 데이터 저장

App Engine이 제공하는 데이터 저장 옵션은 다음과 같습니다.

이름 구조 일관성
Cloud Datastore 스키마 없음 강력한 일관성(전역 쿼리 수행 시 제외)
Cloud SQL 관계형 강력한 일관성
Cloud Storage 파일 및 관련 메타데이터 강력한 일관성(버킷 또는 객체의 목록을 가져오는 목록 작업 수행 시 제외)

표준 환경에서 몇 가지 타사 데이터베이스를 사용할 수도 있습니다.

App Engine의 스토리지에 대한 자세한 내용은 스토리지 옵션 선택을 참조한 다음 원하는 프로그래밍 언어를 선택하세요.

가변형 환경을 사용할 때는 표준 환경에서 제공하는 스토리지 옵션뿐 아니라 더욱 폭넓은 타사 데이터베이스를 사용할 수 있습니다. 가변형 환경의 타사 데이터베이스에 대한 자세한 내용은 타사 데이터베이스 사용을 참조하세요.

App Engine으로 부하 분산 및 자동 확장

App Engine에서 개발할 때는 부하 분산 및 자동 확장이 자동으로 관리됩니다.

App Engine으로 로깅 및 모니터링

App Engine에서는 요청이 자동으로 로깅되며, GCP Console에서 해당 로그를 조회할 수 있습니다. 또한 App Engine은 로깅 기능을 제공하는 언어별 표준 라이브러리와 연동하여 로그 항목을 GCP Console의 로그로 전달합니다. 예를 들어 Python에서는 표준 Python 로깅 모듈을, 자바에서는 java.util.logging.Logger API를 사용할 수 있습니다.

Monitoring은 App Engine 앱을 모니터링하는 기능을 제공합니다. GCP Console을 통해 이슈, 업타임 체크, 기타 세부정보를 모니터링할 수 있습니다.

콘텐츠 관리 시스템 구축

웹사이트 제공에는 웹사이트 애셋 관리가 필수적으로 수반됩니다. Cloud Storage는 이러한 애셋을 위한 글로벌 저장소를 제공합니다. 널리 사용되는 아키텍처 중 하나는 Cloud Storage에 정적 콘텐츠를 배포하고 Compute Engine과 동기화하여 동적 페이지를 렌더링하는 것입니다. Cloud Storage는 WordPress, Drupal, Joomla 등의 다양한 타사 콘텐츠 관리 시스템과 연동합니다. 또한 Cloud Storage는 Amazon S3 호환 API를 제공하므로 Amazon S3와 연동하는 모든 시스템은 Cloud Storage와도 연동이 가능합니다.

콘텐츠 관리 시스템의 샘플 아키텍처는 콘텐츠 관리를 참조하세요.

GCP의 콘텐츠 관리 시스템

다음 단계

  • 다른 Google Cloud Platform 기능을 직접 사용해 보려면 가이드 참조
이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

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