웹사이트 제공 | 클라우드 아키텍처 센터 | 구글 클라우드

이 문서에서는 Google Cloud에서 웹사이트를 호스팅하는 방법을 설명합니다. Google Cloud는 강력하고 유연하며 안정적이고 확장 가능한 웹사이트 플랫폼을 제공합니다. Google은 Google이 Google.com, YouTube, Gmail과 같은 사이트에서 콘텐츠를 제공하는 데 사용하는 것과 동일한 인프라를 사용하여 Google Cloud를 구축했습니다. 요구 사항에 가장 적합한 인프라 유형 및 디자인을 사용하여 웹 사이트 콘텐츠를 제공할 수 있습니다.

다음과 같은 경우 이 문서가 유용할 수 있습니다.
- 웹 사이트 제작 방법에 대한 지식이 있고 이전에 일부 웹 서비스 인프라를 배포 및 실행했습니다.

- 사이트를 Google Cloud로 이전할지 여부와 방법 평가

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

## 옵션 선택
Google Cloud를 처음 사용하는 경우 이미 익숙한 기술을 사용하여 시작하는 것이 합리적인 접근 방식입니다. 예를 들어 현재 하드웨어 서버나 가상 머신(VM)을 사용하여 다른 클라우드 제공업체나 자체 하드웨어에서 사이트를 호스팅하는 경우 Compute Engine은 친숙한 패러다임을 제공합니다. 이미 Heroku 또는 Engine Yard와 같은 PaaS(Platform-as-a-Service) 제품을 사용하고 있다면 App Engine이 가장 좋은 출발점일 수 있습니다. 서버리스 컴퓨팅을 선호한다면 Cloud Run이 좋은 옵션일 것입니다.

Google Cloud에 익숙해지면 Google Cloud에서 제공하는 다양한 제품과 서비스를 탐색할 수 있습니다. 예를 들어 Compute Engine을 사용하여 시작한 경우 Google Kubernetes Engine(GKE)을 사용하여 사이트의 기능을 강화하거나 일부 또는 모든 기능을 App Engine 및 Cloud Run으로 마이그레이션할 수 있습니다.

다음 표에는 Google Cloud의 호스팅 옵션이 요약되어 있습니다.
|옵션||제품||데이터 스토리지||로드 밸런싱||확장성||로깅 및 모니터링|
|정적 웹사이트||
|
클라우드 스토리지
Firebase 호스팅
|클라우드 스토리지 버킷||
|
HTTP(S) 옵션
|자동|
|가상 머신||Compute Engine||
|
Cloud SQL Admin API, Cloud Storage API, Datastore API, Cloud Bigtable API 또는 다른 외부 저장소 공급자를 사용할 수 있습니다.

라고 하는 하드 디스크 기반 영구 디스크
|
|
HTTPS)
TCP 프록시
SSL 프록시
IPv6 종료
회로망
지역 간
내부
|관리형 인스턴스 그룹으로 자동으로|
|컨테이너||GKE||Compute Engine과 유사하지만 영구 디스크와 다르게 상호작용||네트워크
|
HTTPS)
|클러스터 오토스케일러|
|관리 플랫폼||
|
앱 엔진
|Cloud SQL, Firestore, Cloud Storage 및 액세스 가능한 타사 데이터베이스와 같은 Google Cloud 서비스||
|
HTTPS)
Google에서 관리
|Google에서 관리|
|서버리스||
|
클라우드 런
|Cloud SQL, Firestore, Cloud Storage 및 액세스 가능한 타사 데이터베이스와 같은 Google Cloud 서비스||
|
HTTPS)
Google에서 관리
|Google에서 관리|
이 문서는 Google Cloud에서 웹 제공에 사용할 수 있는 주요 기술을 이해하고 기술 작동 방식을 엿볼 수 있도록 도와줍니다. 이 문서는 준비가 되었을 때 더 깊이 이해하는 데 도움이 되는 전체 문서, 자습서 및 솔루션 문서에 대한 링크를 제공합니다.

## 비용 이해
변수가 너무 많고 각 구현이 다르기 때문에 비용에 대한 구체적인 조언을 제공하는 것은 이 문서의 범위를 벗어납니다. Google Cloud에서 가격이 책정되는 방식에 대한 Google의 원칙을 이해하려면 가격 책정 페이지를 참조하세요. 개별 서비스의 가격을 이해하려면 제품 가격 섹션을 참조하십시오. 가격 계산기를 사용하여 Google Cloud 사용량을 예측할 수도 있습니다. 사용하려는 서비스에 대한 세부 정보를 제공한 다음 예상 가격을 볼 수 있습니다.

## 도메인 이름 서비스 설정
일반적으로 사이트의 도메인 이름을 등록하려고 합니다. Google Domains와 같은 공개 도메인 이름 등록기관을 사용하여 사이트에 고유한 이름을 등록할 수 있습니다. 자체 DNS(도메인 이름 시스템)를 완전히 제어하려면 Cloud DNS를 사용하여 DNS 공급자 역할을 할 수 있습니다. Cloud DNS 문서에는 빠른 시작이 포함되어 있습니다.

사용하려는 기존 DNS 공급자가 있는 경우 일반적으로 다음을 수행해야 합니다.
해당 공급자와 몇 가지 레코드를 만듭니다. 다음과 같은 도메인 이름의 경우
example.com에서
DNS 공급자의 레코드. 을 위해
www.example.com 하위 도메인을 만들려면
CNAME 레코드
www 포인트
그것을
example.com 도메인. 그만큼
레코드는 호스트 이름을 IP 주소에 매핑합니다.

그만큼
CNAME 레코드는
레코드

귀하의 도메인 이름 등록 기관이 DNS 제공업체이기도 한 경우, 아마도 이것이 귀하가 해야 할 전부일 것입니다. 등록 및 DNS에 별도의 공급자를 사용하는 경우 도메인 이름 등록 기관에 도메인과 연결된 올바른 이름 서버가 있는지 확인하십시오.

DNS를 변경한 후 영역의 TTL(Time-To-Live) 값에 따라 레코드 업데이트가 전파되는 데 약간의 시간이 걸릴 수 있습니다. 이것이 새 호스트 이름인 경우 DNS 확인자가 이전 값을 캐시하지 않고 DNS 공급자에게 연락하여 요청을 라우팅하는 데 필요한 정보를 얻을 수 있기 때문에 변경 사항이 빠르게 적용됩니다.

## 정적 웹사이트 호스팅
HTTP(S)를 통해 웹 사이트 콘텐츠를 제공하는 가장 간단한 방법은 호스팅하는 것입니다.
*정적 웹 페이지*. 정적 웹 페이지가 제공됩니다.
일반적으로 HTML을 사용하여 작성된 그대로 변경되지 않았습니다. 정적 웹 사이트 사용
사이트의 페이지가 변경된 후 거의 변경되지 않는 경우 좋은 옵션입니다.
소규모 비즈니스의 일부인 블로그 게시물 또는 페이지와 같은 게시
웹사이트. 정적 웹 페이지로 많은 일을 할 수 있지만 사이트에서
서버 측 코드를 통해 사용자와 강력한 상호 작용을 해야 합니다.
이 문서에서 설명하는 다른 옵션을 고려하십시오.

 Cloud Storage로 정적 웹사이트 호스팅
Cloud Storage에서 정적 사이트를 호스팅하려면
클라우드 스토리지 버킷,
콘텐츠를 업로드하고 새 사이트를 테스트합니다. 당신은 할 수 있습니다
에서 직접 데이터 제공
storage.googleapis.com,
또는 당신은 할 수 있습니다
도메인 소유권 확인
그리고 사용
귀하의 도메인 이름

원하는 대로 정적 웹 페이지를 만들 수 있습니다. 예를 들어,
HTML 및 CSS를 사용하여 페이지를 손으로 작성합니다. 당신은 사용할 수 있습니다
*정적 사이트 생성기*,
~와 같은
지킬,
귀신,
또는 휴고,
콘텐츠를 만들기 위해

정적 사이트 생성기를 사용하면 정적 웹사이트를 다음과 같이 생성할 수 있습니다.
작성
가격 인하,
템플릿과 도구를 제공합니다. 일반적으로 사이트 생성기
콘텐츠를 미리 보는 데 사용할 수 있는 로컬 웹 서버 제공

정적 사이트가 작동한 후 다음을 사용하여 정적 페이지를 업데이트할 수 있습니다.
당신이 좋아하는 프로세스. 그 과정은 손으로 복사하는 것만큼 간단할 수 있습니다.
페이지를 버킷에 업데이트했습니다. 보다 자동화된 접근 방식을 사용하도록 선택할 수 있습니다.
예를 들어 GitHub에 콘텐츠를 저장한 다음
웹훅
실행
버킷을 업데이트하는 스크립트. 훨씬 더 진보된 시스템은
다음과 같은 CI/CD(지속적 통합/지속적 전달) 도구
젠킨스,
의 콘텐츠를 업데이트하려면
버킷. Jenkins에는 클라우드 스토리지가 있습니다.
플러그인
제공하는
빌드를 게시하기 위한 Google Cloud Storage 업로더 빌드 후 단계
Cloud Storage에 대한 아티팩트

정적 콘텐츠 또는 사용자가 업로드한 정적 미디어를 제공해야 하는 웹 앱이 있는 경우 Cloud Storage를 사용하면 웹 앱에 대한 동적 요청의 양을 줄이면서 이 콘텐츠를 비용 효율적이고 효율적으로 호스팅하고 제공할 수 있습니다.

또한 Cloud Storage는 사용자가 제출한 콘텐츠를 직접 수락할 수 있습니다. 이 기능을 사용하면 서버를 통해 프록시를 사용하지 않고도 대용량 미디어 파일을 직접 안전하게 업로드할 수 있습니다.

정적 웹사이트에서 최상의 성능을 얻으려면 Cloud Storage 권장사항을 참조하세요.

자세한 내용은 다음 페이지를 참조하십시오.
- 정적 웹사이트 호스팅
- J는 Jenkins(블로그 게시물)
- Google Cloud의 Band Aid 30(블로그 게시물)
- 클라우드 저장소 설명서
 Firebase 호스팅으로 정적 웹사이트 호스팅Firebase 호스팅은 웹 앱을 위한 빠르고 안전한 정적 호스팅을 제공합니다.Firebase 호스팅을 사용하면 단일 명령을 사용하여 웹 앱과 정적 콘텐츠를 글로벌 콘텐츠 전송 네트워크(CDN)에 배포할 수 있습니다.Firebase 호스팅 사용:- 구성이 필요 없는 SSL이 Firebase 호스팅에 내장되어 있습니다.맞춤형 도메인에 SSL 인증서를 무료로 프로비저닝- 모든 콘텐츠는 HTTPS를 통해 제공됩니다- 콘텐츠는 사용자에게 전달됩니다 전 세계 CDN 에지에서- Firebase CLI를 사용하여 몇 초 만에 앱을 시작하고 실행할 수 있습니다.명령줄 도구를 사용하여 배포 대상을 빌드 프로세스에 추가- 새 자산의 원자적 배포, 전체 버전 관리 및 원클릭과 같은 릴리스 관리 기능을 사용할 수 있습니다. 롤백- 호스팅은 단일 페이지 앱 및 앱과 유사한 기타 사이트에 유용한 구성을 제공합니다.- 호스팅은 기타 Firebase 기능자세한 내용은 다음 페이지를 참조하세요.## Compute Engine과 함께 가상 머신 사용IaaS(Infrastructure as a Service) 사용 사례 , Google Cloud는 Compute Engine을 제공합니다.Compute Engine은 강력한 컴퓨팅 인프라를 제공하지만 사용하려는 플랫폼 구성요소를 선택하고 구성해야 합니다.Compute Engine에서 시스템을 구성, 관리, 모니터링하는 것은 귀하의 책임입니다.Google은 리소스를 사용할 수 있고 안정적이며 사용할 준비가 되었는지 확인하지만 리소스를 프로비저닝하고 관리하는 것은 사용자의 몫입니다.여기에서 장점은 시스템을 완벽하게 제어하고 무제한의 유연성을 가질 수 있다는 것입니다.Compute Engine을 사용하여 원하는 거의 모든 웹사이트 제공 시스템을 설계하고 배포할 수 있습니다.자체 하드웨어 인프라가 있는 경우와 마찬가지로 인스턴스라고 하는 VM을 사용하여 앱을 빌드할 수 있습니다.Compute Engine은 요구사항과 예산에 맞게 구성을 맞춤설정할 수 있는 다양한 머신 유형을 제공합니다.선호하는 운영 체제, 개발 스택, 언어, 프레임워크, 서비스 및 기타 소프트웨어 기술을 선택할 수 있습니다.Google Cloud Marketplace로 자동 설정The 완전한 웹 제공 스택을 배포하는 가장 쉬운 방법은 Google Cloud Marketplace를 사용하는 것입니다.단 몇 번의 클릭만으로 Google Click to Deploy 또는 Bitnami를 사용하여 100개가 넘는 완전히 구현된 솔루션을 배포할 수 있습니다.예를 들어 LAMP 스택 또는 WordPress를 설정할 수 있습니다. Cloud Marketplace와 함께.시스템은 단일 인스턴스에서 단 몇 분 만에 작동하는 완전한 소프트웨어 스택을 배포합니다.배포하기 전에 Cloud Marketplace는 사이트 실행에 대한 예상 비용을 표시하고 설치하는 소프트웨어 구성 요소의 버전에 대한 명확한 정보를 제공하며 구성 요소 인스턴스 이름을 변경하고 머신 유형 및 디스크 크기 선택.배포한 후에는 Compute Engine 인스턴스, 해당 구성 및 소프트웨어를 완전히 제어할 수 있습니다.수동 설정다음에서 인프라를 만들 수도 있습니다. 처음부터 구성을 빌드하거나 Google Cloud Marketplace 배포를 기반으로 빌드하는 Compute Engine 수동.예를 들어 Cloud Marketplace에서 제공하지 않는 소프트웨어 구성 요소 버전을 사용하거나 직접 모든 것을 설치하고 구성하는 것을 선호할 수 있습니다.웹 사이트 설정을 위한 프레임워크 및 모범 사례는 이 문서의 범위를 벗어납니다.하지만 높은 수준에서 볼 때 Compute Engine에서 웹 제공 인프라를 설정하는 기술적인 측면에서 다음이 필요합니다.요구 사항을 이해합니다.새 웹 사이트를 구축하는 경우 인스턴스, 스토리지 요구 사항 및 네트워킹 인프라와 같은 필요한 구성 요소를 이해해야 합니다.기존 솔루션에서 앱을 마이그레이션하는 경우 이러한 요구사항을 이미 이해하고 있을 수 있지만 기존 설정이 Google Cloud 서비스에 매핑되는 방식을 고려해야 합니다.디자인을 계획합니다.아키텍처를 생각하고 디자인을 적어보세요.최대한 명시적으로 작성하세요.구성 요소를 만듭니다.컴퓨터 및 네트워크 스위치와 같이 일반적으로 물리적 자산이라고 생각할 수 있는 구성요소는 Compute Engine의 서비스를 통해 제공됩니다.예를 들어 컴퓨터를 원하면 Compute Engine 인스턴스를 만들어야 합니다.영구 하드 디스크 드라이브를 원하면 그것도 만드십시오.Cloud Deployment Manager 또는 Terraform은 이를 쉽고 반복 가능한 프로세스로 만듭니다.구성 및 사용자 정의. 원하는 구성 요소를 확보한 후에는 이를 구성하고, 소프트웨어를 설치 및 구성하고, 필요한 사용자 정의 코드를 작성 및 배포해야 합니다.향후 배포 속도를 높이는 데 도움이 되는 셸 스크립트를 실행하여 구성을 복제할 수 있습니다.Deployment Manager는 리소스 자동 배포를 위한 선언적이고 유연한 구성 템플릿을 제공하여 여기에서도 도움이 됩니다.Puppet 및 Chef와 같은 IT 자동화 도구를 활용할 수도 있습니다.자산을 배포합니다.아마도 웹 페이지와 이미지가 있을 것입니다.테스트.모든 것이 예상대로 작동하는지 확인하십시오.프로덕션에 배포합니다.전 세계가 보고 사용할 수 있도록 사이트를 공개하세요.Compute Engine 인스턴스를 수동으로 설정하는 것이 어떤지 이해하고 시작하는 데 도움이 되도록 다음 중 하나 이상을 시도해 보세요. 다음 가이드:Compute Engine으로 데이터 저장
대부분의 웹사이트에는 일종의 저장소가 필요합니다. 사용자가 업로드하는 파일 저장, 사이트에서 사용하는 자산 등 다양한 이유로 스토리지가 필요할 수 있습니다.

Google Cloud는 다음과 같은 다양한 관리형 스토리지 서비스를 제공합니다.
- MySQL을 기반으로 하는 Cloud SQL의 SQL 데이터베이스

- NoSQL 데이터 스토리지를 위한 두 가지 옵션: Firestore 및 Cloud Bigtable

- 일관되고 확장 가능한 대용량 객체 스토리지
클라우드 스토리지

Cloud Storage는 여러 등급으로 제공됩니다.
- 표준은 최대 가용성을 제공합니다.

- Nearline은 한 달에 한 번 미만으로 액세스하는 데이터에 적합한 저비용 선택을 제공합니다.

- Coldline은 분기당 1회 미만으로 액세스하는 데이터에 적합한 저비용 선택을 제공합니다.

- 아카이브는 아카이빙, 백업 및 재해 복구를 위한 최저 비용 선택을 제공합니다.

- 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 트래픽을 분산하기 위해 계층 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의 앱과 서비스에서 로그를 수집하고 저장합니다. 로깅 에이전트를 사용하여 로그를 보거나 내보내고 타사 로그를 통합할 수 있습니다.
Cloud Monitoring은 사이트에 대시보드와 알림을 제공합니다.Google Cloud Console로 모니터링을 구성합니다.클라우드 서비스, 가상 머신 및 MongoDB, Apache, Nginx 및 Elasticsearch와 같은 일반적인 오픈 소스 서버에 대한 성능 지표를 검토할 수 있습니다.Cloud Monitoring API를 사용하여 모니터링 데이터를 검색하고 맞춤 측정항목을 만들 수 있습니다.또한 Cloud Monitoring은 웹사이트에 요청을 보내 응답하는지 확인하는 업타임 체크를 제공합니다.가동시간 확인에 실패하면 사건을 생성하는 알림 정책을 배포하여 웹사이트의 가용성을 모니터링할 수 있습니다.Compute Engine으로 DevOps 관리DevOps 관리에 대한 정보 다음 문서를 참조하세요.- Kubernetes를 사용한 분산 부하 테스트- Compute Engine에서 Spinnaker 실행- Spinnaker를 사용하여 Google Cloud에서 배포 관리# # GKE와 함께 컨테이너 사용Docker 컨테이너와 같은 컨테이너를 이미 사용 중일 수 있습니다.웹 서비스의 경우 컨테이너는 다음과 같은 몇 가지 이점을 제공합니다.구성 요소화.컨테이너를 사용하여 웹 앱의 다양한 구성 요소를 분리할 수 있습니다.예를 들어 사이트에서 웹 서버와 데이터베이스를 실행한다고 가정합니다.이러한 구성 요소를 별도의 컨테이너에서 실행하여 다른 구성 요소에 영향을 주지 않고 한 구성 요소를 수정 및 업데이트할 수 있습니다.앱의 디자인이 더 복잡해짐에 따라 컨테이너는 마이크로서비스를 포함한 서비스 지향 아키텍처에 적합합니다.이러한 종류의 디자인은 무엇보다도 확장성을 지원합니다.휴대성.컨테이너에는 앱을 실행하는 데 필요한 모든 것이 있습니다. 앱과 해당 종속성이 함께 번들로 제공됩니다.기본 시스템 세부 정보에 대해 걱정하지 않고 다양한 플랫폼에서 컨테이너를 실행할 수 있습니다.빠른 배포.배포할 시간이 되면 정의 및 이미지 집합으로 시스템이 구축되므로 부품을 빠르고 안정적이며 자동으로 배포할 수 있습니다.컨테이너는 일반적으로 작고 예를 들어 가상 머신에 비해 훨씬 빠르게 배포됩니다.Google Cloud의 컨테이너 컴퓨팅은 다음을 포함하여 웹 서비스에 훨씬 더 많은 이점을 제공합니다.오케스트레이션.GKE는 Google에서 도입한 오픈소스 컨테이너 오케스트레이션 시스템인 Kubernetes를 기반으로 구축된 관리형 서비스입니다.GKE를 사용하면 Compute Engine 인스턴스로 구성된 클러스터의 일부인 컨테이너에서 코드가 실행됩니다.개별 컨테이너를 관리하거나 각 컨테이너를 수동으로 만들고 종료하는 대신 정의한 구성을 사용하는 GKE를 통해 클러스터를 자동으로 관리할 수 있습니다.이미지 등록.Container Registry 또는 Artifact Registry는 Google Cloud에서 Docker 이미지용 비공개 스토리지를 제공합니다.HTTPS 엔드포인트를 통해 레지스트리에 액세스할 수 있으므로 Compute Engine 인스턴스든 자체 하드웨어든 모든 머신에서 이미지를 가져올 수 있습니다.레지스트리 서비스는 Google Cloud 프로젝트의 Cloud Storage에서 커스텀 이미지를 호스팅합니다.이 접근 방식은 기본적으로 프로젝트에 대한 액세스 권한이 있는 주체만 사용자 지정 이미지에 액세스할 수 있도록 합니다.이동성.즉, 워크로드를 이동하고 다른 클라우드 공급자와 결합하거나 클라우드 컴퓨팅 워크로드를 온프레미스 구현과 혼합하여 하이브리드 솔루션을 생성할 수 있는 유연성이 있음을 의미합니다.GKEGKE는 Google Cloud에서 실행되고 Compute Engine 인스턴스를 노드로 사용하므로 스토리지 옵션은 Compute Engine의 스토리지와 공통점이 많습니다.API를 통해 Cloud SQL, Cloud Storage, Datastore, Bigtable에 액세스하거나 원하는 경우 다른 외부 저장소 공급자를 사용할 수 있습니다.그러나 GKE는 일반 Compute Engine 인스턴스와 다른 방식으로 Compute Engine 영구 디스크와 상호작용합니다.Compute Engine 인스턴스에는 연결된 디스크가 포함됩니다.Compute Engine을 사용하는 경우 인스턴스가 존재하는 한 디스크 볼륨은 인스턴스와 함께 유지됩니다.디스크를 분리하여 다른인스턴스에서 사용할 수도 있습니다.그러나 컨테이너에서 온디스크 파일은 일시적입니다.컨테이너충돌 후와 같이 다시 시작하면 디스크에 있는 파일이 손실됩니다.Kubernetes는볼륨 추상화를 사용하여이 문제를 해결합니다.볼륨 유형 중 하나는gcePersistentDisk이것은 컨테이너와 함께 Compute Engine 영구 디스크를 사용하여GKE를 사용할 때 데이터 파일이 삭제되지 않도록 유지할 수 있음을 의미합니다.볼륨의 기능과 이점을 이해하려면 , 먼저 팟(Pod)에 대해 약간 이해해야 합니다.포드를 하나 이상의 컨테이너에 대한 앱별 논리 호스트로 생각할 수 있습니다.포드는 노드 인스턴스에서 실행됩니다.컨테이너가 팟(Pod)의 구성원인 경우 공유 스토리지 볼륨 세트를 포함하여 여러 리소스를 공유할 수 있습니다.이러한 볼륨을 사용하면 데이터가 컨테이너 재시작 후에도 유지되고 팟(Pod) 내의 컨테이너 간에 공유될 수 있습니다.물론 팟에서 하나의 컨테이너와 볼륨을 사용할 수도 있지만 팟은 이러한 리소스를 서로 논리적으로 연결하는 데 필요한 추상화입니다.예를 들어 , WordPress 및 MySQL에서 영구 디스크 사용 가이드 참조GKE로 부하 분산많은 대규모 웹 제공 아키텍처에는 트래픽 수요를 공유할 수 있는 여러 서버가 실행되어야 합니다.GKE로 여러 컨테이너, 노드, 팟(Pod)을 만들고 관리할 수 있기 때문에 부하 분산된 웹 제공 시스템에 적합합니다.네트워크 부하 분산 사용GKE에서 부하 분산기를 만드는 가장 쉬운 방법은 Compute Engine의 네트워크 부하 분산을 사용하는 것입니다.네트워크 부하 분산은 주소, 포트 및 프로토콜 유형과 같은 들어오는 인터넷 프로토콜 데이터를 기반으로 시스템의 부하를 분산할 수 있습니다.네트워크 부하 분산은 전달 규칙을 사용합니다.이러한 규칙은 부하 분산에 사용할 수 있는 인스턴스를 나열하는 대상 풀을 가리킵니다.
네트워크 로드 밸런싱을 사용하면 SMTP 트래픽과 같은 추가 TCP/UDP 기반 프로토콜을 로드 밸런싱할 수 있으며 앱에서 패킷을 직접 검사할 수 있습니다.

다음을 추가하기만 하면 네트워크 로드 밸런싱을 배포할 수 있습니다.
유형: 로드밸런서
서비스 구성 파일에 대한 필드

 HTTP(S) 부하 분산 사용
HTTPS 부하 분산, 콘텐츠 기반 부하 분산, 지역 간 부하 분산과 같은 고급 부하 분산 기능이 필요한 경우 GKE 서비스를 Compute Engine의 HTTP/HTTPS 부하 분산 기능과 통합할 수 있습니다. Kubernetes는 외부 트래픽을 Kubernetes 엔드포인트로 라우팅하기 위한 규칙 모음을 캡슐화하는 Ingress 리소스를 제공합니다. GKE에서 인그레스 리소스는 Compute Engine HTTP/HTTPS 부하 분산기 프로비저닝 및 구성을 처리합니다.

GKE에서 HTTP/HTTPS 부하 분산 사용에 대한 자세한 내용은 인그레스로 HTTP 부하 분산 설정을 참조하세요.

 GKE로 확장
클러스터 크기를 자동으로 조정하려면 Cluster Autoscaler를 사용할 수 있습니다. 이 기능은 사용 가능한 리소스가 있는 노드를 기다리고 있지만 예약되지 않은 포드가 있는지 주기적으로 확인합니다. 이러한 포드가 있는 경우 크기 조정을 통해 대기 중인 포드를 예약할 수 있는 경우 자동 확장 처리가 노드 풀의 크기를 조정합니다.

Cluster Autoscaler는 또한 모든 노드의 사용량을 모니터링합니다. 노드가 오랜 기간 동안 필요하지 않고 모든 포드가 다른 곳에서 예약될 수 있는 경우 노드가 삭제됩니다.

Cluster Autoscaler, 제한 사항 및 모범 사례에 대한 자세한 내용은 Cluster Autoscaler 설명서를 참조하세요.

 GKE로 로깅 및 모니터링
Compute Engine에서와 마찬가지로 Logging 및 Monitoring은 로깅 및 모니터링 서비스를 제공합니다. Logging은 앱과 서비스에서 로그를 수집하고 저장합니다. 로깅 에이전트를 사용하여 로그를 보거나 내보내고 타사 로그를 통합할 수 있습니다.

모니터링은 사이트에 대한 대시보드 및 경고를 제공합니다. Google Cloud Console을 사용하여 Monitoring을 구성합니다. 클라우드 서비스, 가상 머신 및 MongoDB, Apache, Nginx 및 Elasticsearch와 같은 일반적인 오픈 소스 서버에 대한 성능 지표를 검토할 수 있습니다. Monitoring API를 사용하여 모니터링 데이터를 검색하고 커스텀 측정항목을 생성할 수 있습니다.

 GKE로 DevOps 관리
GKE를 사용하면 DevOps를 생각할 때 대부분의 사람들이 생각하는 많은 이점을 이미 얻고 있습니다. 이는 패키징, 배포 및 관리의 용이성과 관련하여 특히 그렇습니다. CI/CD 워크플로 요구 사항에 대해 Jenkins와 같은 널리 사용되는 도구를 활용할 수 있습니다. 다음 문서를 참조하십시오.
## App Engine으로 관리형 플랫폼에 구축
Google Cloud에서 관리형 PaaS(Platform as a Service)를 App Engine이라고 합니다. App Engine에서 웹사이트를 구축하면 기능을 코딩하는 데 집중하고 지원 인프라 관리는 Google에 맡깁니다. App Engine은 확장성, 로드 밸런싱, 로깅, 모니터링, 보안을 직접 구축하고 관리해야 하는 경우보다 훨씬 쉽게 만들어주는 다양한 기능을 제공합니다. App Engine을 사용하면 다양한 프로그래밍 언어로 코딩할 수 있으며 다양한 기타 Google Cloud 서비스를 사용할 수 있습니다.

App Engine은 안전한 샌드박스 환경에서 앱을 실행할 수 있는 표준 환경을 제공합니다. App Engine 표준 환경은 요청을 여러 서버에 분산하고 서버를 확장하여 트래픽 수요를 충족합니다. 앱은 하드웨어, 운영 체제 또는 서버의 물리적 위치와 독립적인 자체 안전하고 안정적인 환경에서 실행됩니다.

더 많은 옵션을 제공하기 위해 App Engine은 유연한 환경을 제공합니다. 가변형 환경을 사용하면 앱이 구성 가능한 Compute Engine 인스턴스에서 실행되지만 App Engine이 대신 호스팅 환경을 관리합니다. 즉, 사용자 지정 런타임을 비롯한 추가 런타임을 사용하여 더 많은 프로그래밍 언어를 선택할 수 있습니다. 또한 다양한 CPU 및 메모리 옵션 중에서 선택하는 등 Compute Engine이 제공하는 유연성을 일부 활용할 수 있습니다.

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

유연한 환경에서는 지원되는 프로그래밍 언어 버전으로 소스 코드를 작성합니다. 이러한 런타임을 사용자 지정하거나 사용자 지정 Docker 이미지 또는 Dockerfile로 자체 런타임을 제공할 수 있습니다.

사용하는 프로그래밍 언어가 주요 관심사인 경우 App Engine 표준 환경에서 제공하는 런타임이 요구 사항을 충족하는지 여부를 결정해야 합니다. 그렇지 않은 경우 가변형 환경 사용을 고려해야 합니다.

앱의 요구사항에 가장 적합한 환경을 결정하려면 App Engine 환경 선택을 참조하세요.

 언어별 자습서 시작하기
다음 가이드는 App Engine 표준 환경 사용을 시작하는 데 도움이 될 수 있습니다.
- Python의 Hello World
- 자바의 Hello World
- PHP의 Hello World
- Hello World in Ruby
- Hello World in Go
- Node.js의 Hello World
다음 가이드는 가변형 환경 사용을 시작하는 데 도움이 될 수 있습니다.
- 파이썬 시작하기
- 자바 시작하기
- PHP 시작하기
- Go 시작하기
- Node.js 시작하기
- 루비 시작하기
- .NET 시작하기
 App Engine으로 데이터 저장
App Engine은 다음과 같은 데이터 저장 옵션을 제공합니다.
|이름||구조||일관성|
|Firestore||무계획성||강력한 일관성.|
|Cloud SQL||관계형||강력한 일관성.|
|클라우드 스토리지||파일 및 관련 메타데이터||버킷 또는 개체 목록을 가져오는 목록 작업을 수행할 때를 제외하고는 매우 일관성이 있습니다.|
표준 환경에서 여러 타사 데이터베이스를 사용할 수도 있습니다.

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 로깅 모듈을 사용할 수 있으며
자바에서
logback appender를 통합하거나
java.util.logging
Cloud 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 데이터베이스에 액세스하고 동적 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 Gateway와 같은 미들웨어를 사용하여 서비스를 향상시킬 수 있습니다.

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 운영 제품군 가격이 적용됩니다. 즉, 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에 대한 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 살펴보세요. 클라우드 아키텍처 센터를 살펴보세요.