この記事では、Google Cloud でウェブサイトをホストする方法について説明します。 Google Cloud は、ウェブサイトを提供するための堅牢で柔軟、信頼性、スケーラブルなプラットフォームを提供します。 Google は、Google.com、YouTube、Gmail などのサイトからコンテンツを提供するために Google が使用しているのと同じインフラストラクチャを使用して、Google Cloud を構築しました。ニーズに最適なタイプと設計のインフラストラクチャを使用して、Web サイトのコンテンツを提供できます。
この記事は、次の場合に役立ちます。
- Web サイトの作成方法に関する知識があり、以前にいくつかの Web サービス インフラストラクチャをデプロイして実行したことがある
- サイトを Google Cloud に移行するかどうか、およびその方法を評価する
シンプルなウェブサイトを構築したい場合は、構造化されたウィキおよびウェブ ページ作成ツールである Google サイトの使用を検討してください。詳しくは、Google サイトのヘルプをご覧ください
## オプションの選択
Google Cloud を初めて使用する場合は、使い慣れたテクノロジーを使用して開始するのが合理的なアプローチです。たとえば、現在ハードウェア サーバーまたは仮想マシン (VM) を使用してサイトをホストしている場合、おそらく別のクラウド プロバイダまたは独自のハードウェアで、Compute Engine が使い慣れたパラダイムを提供します。 Heroku や Engine Yard などのサービスとしてのプラットフォーム (PaaS) を既に使用している場合は、App Engine が最適な出発点となる可能性があります。サーバーレス コンピューティングを好む場合は、おそらく Cloud Run が適しています
Google Cloud に慣れてきたら、Google Cloud が提供する豊富なプロダクトとサービスを探索できます。たとえば、Compute Engine を使用して開始した場合は、Google Kubernetes Engine (GKE) を使用してサイトの機能を強化したり、機能の一部またはすべてを App Engine と Cloud Run に移行したりできます。
次の表は、GCP でのホスティング オプションをまとめたものです。
|オプション||製品||データストレージ||ロードバランシング||スケーラビリティ||ロギングとモニタリング|
|静的なウェブサイト||
| |
クラウドストレージ
Firebase ホスティング
|Cloud Storage バケット||
| |
HTTP(S) オプション
|自動的に|
|仮想マシン||Compute Engine||
| |
Cloud SQL Admin API、Cloud Storage API、Datastore API、Cloud Bigtable API、または別の外部ストレージ プロバイダを使用できます
と呼ばれるハードディスクベースの永続ディスク
| |
| |
HTTP(秒)
TCP プロキシ
SSL プロキシ
IPv6 ターミネーション
通信網
クロスリージョン
内部
|マネージド インスタンス グループで自動的に|
|コンテナ||GKE||Compute Engine に似ていますが、永続ディスクとのやり取りが異なります||ネットワーク
| |
HTTP(秒)
|クラスターオートスケーラー|
|マネージド プラットフォーム||
| |
App Engine
|Cloud SQL、Firestore、Cloud Storage、アクセス可能なサードパーティ データベースなどの Google Cloud サービス||
| |
HTTP(秒)
Google が管理
|Google が管理|
|サーバーレス||
| |
クラウドラン
|Cloud SQL、Firestore、Cloud Storage、アクセス可能なサードパーティ データベースなどの Google Cloud サービス||
| |
HTTP(秒)
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) の値によっては、レコードの更新が反映されるまでに時間がかかる場合があります。これが新しいホスト名である場合、DNS リゾルバーは以前の値をキャッシュしておらず、DNS プロバイダーに接続して要求をルーティングするために必要な情報を取得できるため、変更はすぐに有効になります。
## 静的 Web サイトのホスティング
HTTP(S) 経由でウェブサイトのコンテンツを提供する最も簡単な方法は、ホストすることです
*静的 Web ページ*。静的 Web ページが提供されます
通常は HTML を使用して書かれたままです。静的 Web サイトの使用
サイトのページが変更された後、ほとんど変更されない場合に適したオプションです。
スモールビジネスの一部であるブログ投稿やページなどの公開
Webサイト。静的な Web ページでできることはたくさんありますが、サイトが必要な場合は
サーバー側のコードを介してユーザーとの堅牢なやり取りを行う必要があります。
この記事で説明した他のオプションを検討してください
Cloud Storage を使用した静的ウェブサイトのホスティング
Cloud Storage で静的サイトをホストするには、
Cloud Storage バケット、
コンテンツをアップロードし、新しいサイトをテストします。あなたはできる
から直接データを提供する
storage.googleapis.com、
またはあなたができる
ドメインを所有していることを確認する
と使用
あなたのドメイン名
静的 Web ページは自由に作成できます。たとえば、次のことができます。
HTML と CSS を使用して手動でページを作成します。あなたが使用することができます
*静的サイト ジェネレーター*,
そのような
ジキル、
おばけ、
またはヒューゴ、
コンテンツを作成する
静的サイト ジェネレーターを使用すると、次の方法で静的 Web サイトを作成できます。
でのオーサリング
マークダウン、
テンプレートとツールの提供。サイトジェネレーター全般
コンテンツのプレビューに使用できるローカル Web サーバーを提供する
静的サイトが機能したら、静的ページを更新できます。
好きなプロセス。そのプロセスは、手動でコピーするのと同じくらい簡単です。
ページをバケットに更新しました。より自動化されたアプローチを使用することもできます。
コンテンツを GitHub に保存してから、
ウェブフック
実行する
バケットを更新するスクリプト。さらに高度なシステムでは、
などの継続的インテグレーション/継続的デリバリー (CI/CD) ツール
ジェンキンス
のコンテンツを更新するには
バケツ。 Jenkins には Cloud Storage があります
プラグイン
提供する
ビルドを公開するための Google Cloud Storage Uploader ビルド後のステップ
Cloud Storage へのアーティファクト
静的コンテンツまたはユーザーがアップロードした静的メディアを提供する必要があるウェブアプリがある場合、Cloud Storage を使用すると、ウェブアプリへの動的リクエストの量を減らしながら、このコンテンツをホストして提供するための費用対効果が高く効率的な方法になります。
さらに、Cloud Storage は、ユーザーが送信したコンテンツを直接受け入れることができます。この機能により、ユーザーはサーバー経由でプロキシすることなく、大きなメディア ファイルを直接かつ安全にアップロードできます。
静的ウェブサイトから最高のパフォーマンスを得るには、Cloud Storage のベスト プラクティスをご覧ください。
詳細については、次のページを参照してください。
- 静的 Web サイトのホスティング
- J は Jenkins の場合 (ブログ投稿)
- Google Cloud のバンドエイド 30 (ブログ投稿)
- クラウド ストレージのドキュメント
Firebase Hosting を使用した静的ウェブサイトのホスティング Firebase Hosting は、ウェブアプリに高速で安全な静的ホスティングを提供します。 Firebase Hosting を使用すると、1 つのコマンドを使用してウェブアプリと静的コンテンツをグローバル コンテンツ配信ネットワーク (CDN) にデプロイできます。 Firebase Hosting を使用すると、次のような利点があります。 - 設定不要の SSL が Firebase Hosting に組み込まれています。 カスタム ドメインで 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 インスタンス、その構成、およびソフトウェアを完全に制御できます。 手動設定 Compute Engine でインフラストラクチャを手動で作成することもできます。構成をゼロから構築するか、Google Cloud Marketplace のデプロイで構築します。 たとえば、Cloud Marketplace で提供されていないバージョンのソフトウェア コンポーネントを使用したい場合や、すべてを自分でインストールして構成したい場合があります。 Web サイトをセットアップするための完全なフレームワークとベスト プラクティスを提供することは、この記事の範囲を超えています。 ただし、おおまかに見ると、Compute Engine でウェブサービス インフラストラクチャをセットアップする際の技術面では、次のことが必要になります。 要件を理解します。 新しい Web サイトを構築している場合は、インスタンス、ストレージのニーズ、ネットワーク インフラストラクチャなど、必要なコンポーネントを理解していることを確認してください。アプリを既存のソリューションから移行する場合は、これらの要件をすでに理解している可能性がありますが、既存の設定が Google Cloud サービスにどのようにマッピングされるかを考える必要があります。 設計を計画します。 アーキテクチャを熟考し、設計を書き留めます。 できるだけ明確にしてください。 コンポーネントを作成します。 コンピュータやネットワーク スイッチなど、通常は物理的な資産と考えられるコンポーネントは、Compute Engine のサービスを通じて提供されます。 たとえば、コンピュータが必要な場合は、Compute Engine インスタンスを作成する必要があります。 永続的なハード ディスク ドライブが必要な場合は、それも作成します。 Cloud Deployment Manager または Terraform を使用すると、これが簡単で繰り返し可能なプロセスになります。 構成とカスタマイズ。必要なコンポーネントを入手したら、それらを構成し、ソフトウェアをインストールして構成し、必要なカスタマイズ コードを記述して展開する必要があります。 シェル スクリプトを実行することで構成を複製できるため、将来の展開を高速化できます。 Deployment Manager は、リソースの自動デプロイ用の宣言的で柔軟な構成テンプレートを提供することで、ここでも役立ちます。 Puppet や Chef などの IT 自動化ツールを利用することもできます。 アセットをデプロイします。 おそらく、Web ページと画像があるとします。 テスト。 すべてが期待どおりに機能することを確認します。 本番環境にデプロイします。 あなたのサイトを世界中の人が見たり使ったりできるようにしましょう Compute Engine インスタンスを手動で設定する方法を理解するために、次のチュートリアルを 1 つ以上試してください。 Compute Engine を使用したデータの保存
ほとんどの Web サイトには、何らかのストレージが必要です。ユーザーがアップロードするファイルや、もちろんサイトが使用するアセットを保存するなど、さまざまな理由でストレージが必要になる場合があります。
Google Cloud は、次のようなさまざまなマネージド ストレージ サービスを提供します。
- MySQL に基づく Cloud SQL の SQL データベース
- NoSQL データ ストレージの 2 つのオプション: Firestore と Cloud Bigtable
- 一貫性のあるスケーラブルな大容量オブジェクト ストレージ
クラウドストレージ
Cloud Storage にはいくつかのクラスがあります。
- 標準は最大の可用性を提供します
- Nearline は、月に 1 回未満アクセスされるデータに最適な低コストの選択肢を提供します
- Coldline は、四半期に 1 回未満しかアクセスされないデータに最適な低コストの選択肢を提供します
- アーカイブは、アーカイブ、バックアップ、および災害復旧のための最も低コストの選択肢を提供します
- Compute Engine 上の永続ディスク
インスタンスのプライマリ ストレージとして使用します。 Compute Engine のオファー
と呼ばれる両方のハードディスクベースの永続ディスク
標準永続ディスク、およびソリッドステート永続ディスク (SSD)。永続ディスクを使用して、Compute Engine に好みのストレージ テクノロジーを設定することもできます。たとえば、PostgreSQL を SQL データベースとして設定したり、MongoDB を NoSQL ストレージとして設定したりできます。 Google Cloud のストレージ サービスの全範囲と利点を理解するには、ストレージ オプションの選択をご覧ください
Compute Engine による負荷分散
大規模な Web サイトでは、負荷分散テクノロジを使用してサーバー間でワークロードを分散することが必要になることがよくあります。 Compute Engine で負荷分散されたウェブ サーバーを設計する場合、次のようなさまざまなオプションがあります。
- HTTP(S) 負荷分散
Cloud Load Balancing の使用の基本について説明します
- コンテンツ ベースの負荷分散。着信 URL に基づいてトラフィックをさまざまなインスタンスに分散する方法を示します
- リージョン間の負荷分散。異なるリージョンで VM インスタンスを構成し、HTTP または HTTPS 負荷分散を使用してリージョン間でトラフィックを分散する方法を示します
- TCP プロキシの負荷分散。複数のリージョンに存在するサービスのグローバル TCP プロキシ負荷分散の設定を示します
- SSL プロキシの負荷分散。複数のリージョンに存在するサービスのグローバル SSL プロキシ ロード バランシングの設定を示します
- HTTP(S)、SSL プロキシ、および TCP プロキシの負荷分散のための IPv6 ターミネーション。 IPv6 ターミネーションと、IPv6 リクエストを処理するようにロード バランサーを構成するためのオプションについて説明します。
- ネットワーク負荷分散。レイヤー 3 負荷分散構成を設定して、正常なインスタンス間で HTTP トラフィックを分散する基本的なシナリオを示します
- Microsoft IIS バックエンドを使用した地域間の負荷分散。 Compute Engine ロード バランサを使用してトラフィックを Microsoft インターネット インフォメーション サービス (IIS) サーバーに分散する方法を示します。
- 内部負荷分散のセットアップ インターネットに公開されていないプライベート ネットワークにネットワーク トラフィックを分散するロード バランサーをセットアップできます。内部負荷分散は、すべてのトラフィックがプライベート ネットワーク上にあるイントラネット アプリだけでなく、フロントエンドがプライベート ネットワークを使用してバックエンド サーバーに要求する複雑な Web アプリにも役立ちます。
負荷分散のデプロイは柔軟で、既存のソリューションで Compute Engine を使用できます。たとえば、Nginx を使用した HTTP(S) 負荷分散は、Compute Engine ロードバランサの代わりに使用できるソリューションの 1 つです。
Compute Engine によるコンテンツ配信
応答時間はどの Web サイトにとっても基本的な指標であるため、CDN を使用して待ち時間を短縮し、パフォーマンスを向上させることは、多くの場合、特にグローバルな Web トラフィックを持つサイトの場合に必要です。
Cloud CDN は、Google のグローバルに分散されたエッジ ポイント オブ プレゼンスを使用して、ユーザーに最も近いキャッシュ ロケーションからコンテンツを配信します。 Cloud CDN は HTTP(S) 負荷分散で動作します。単一の IP アドレスから Compute Engine、Cloud Storage、またはその両方からコンテンツを提供するには、HTTP(S) ロードバランサの Cloud CDN を有効にします
Compute Engine による自動スケーリング
需要の変化に応じてサーバーを追加および削除するようにアーキテクチャを設定できます。このアプローチは、より典型的な需要期間中のコストを制御しながら、サイトがピーク負荷の下で適切に機能することを保証するのに役立ちます. Compute Engine は、この目的で使用できるオートスケーラーを提供します
自動スケーリングはマネージド インスタンス グループの機能です。マネージド インスタンス グループは、共通のインスタンス テンプレートから作成された同種の仮想マシン インスタンスのプールです。オートスケーラーは、マネージド インスタンス グループのインスタンスを追加または削除します。 Compute Engine にはマネージド インスタンス グループとアンマネージド インスタンス グループの両方がありますが、オートスケーラーではマネージド インスタンス グループのみを使用できます。詳細については、Compute Engine での自動スケーリングをご覧ください。
スケーラブルで回復力のある Web アプリ ソリューションを構築するために必要なことの詳細については、「スケーラブルで回復力のある Web アプリの構築」を参照してください。
Compute Engine によるロギングとモニタリング
Google Cloud には、ウェブサイトで何が起こっているかを把握するために使用できる機能が含まれています
Cloud Logging は、Google Cloud 上のアプリやサービスからログを収集して保存します。ログエージェントを使用して、ログを表示またはエクスポートし、サードパーティのログを統合できます
Cloud Monitoring は、サイトのダッシュボードとアラートを提供します。Google Cloud コンソールで Monitoring を構成します。クラウド サービス、仮想マシン、および MongoDB、Apache、Nginx、Elasticsearch などの一般的なオープン ソース サーバーのパフォーマンス メトリックを確認できます。Cloud Monitoring API を使用して、モニタリング データを取得し、カスタム指標を作成できますCloud Monitoring は稼働時間チェックも提供します。このチェックでは、ウェブサイトにリクエストを送信して、ウェブサイトが応答するかどうかを確認します。稼働時間チェックが失敗した場合にインシデントを作成するアラート ポリシーをデプロイすることで、ウェブサイトの可用性を監視できますCompute Engine で DevOps を管理するDevOps の管理について- Kubernetes を使用した分散負荷テスト- Compute Engine で Spinnaker を実行する- Spinnaker を使用して Google Cloud でデプロイを管理する# # GKE でコンテナーを使用するDocker コンテナーなどのコンテナーを既に使用している可能性があります。Web サービスの場合、コンテナーには次のようないくつかの利点があります。コンポーネント化。コンテナーを使用して、Web アプリのさまざまなコンポーネントを分離できます。たとえば、サイトで Web サーバーとデータベースを実行しているとします。これらのコンポーネントを別々のコンテナで実行し、一方のコンポーネントを変更および更新して他方に影響を与えることができません。アプリの設計がより複雑になるにつれて、コンテナはマイクロサービスを含むサービス指向のアーキテクチャに適しています。この種の設計は、他の目標の中でもスケーラビリティをサポートします。移植性。コンテナーには、アプリを実行するために必要なものがすべて含まれており、その依存関係がまとめられています。基礎となるシステムの詳細を気にすることなく、さまざまなプラットフォームでコンテナーを実行できます。迅速な展開。展開する段階になると、一連の定義とイメージからシステムが構築されるため、パーツを迅速、確実、かつ自動的に展開できます。通常、コンテナは小さく、仮想マシンなどに比べてはるかに迅速にデプロイできます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 はボリューム抽象化を使用してこの問題を解決し、ボリュームの 1 つのタイプはgcePersistentDiskつまり、Compute Engine の永続ディスクをコンテナで使用して、GKE の使用時にデータ ファイルが削除されないようにすることができますボリュームの機能と利点を理解するには、最初にポッドについて少し理解する必要があります。Pod は、1 つ以上のコンテナーのアプリ固有の論理ホストと考えることができます。ポッドはノード インスタンスで実行されます。コンテナーが Pod のメンバーである場合、コンテナーは共有ストレージ ボリュームのセットを含む複数のリソースを共有できます。これらのボリュームにより、コンテナの再起動後もデータを保持し、ポッド内のコンテナ間でデータを共有できます。もちろん、単一のコンテナーとボリュームを Pod で使用することもできますが、Pod は、これらのリソースを相互に論理的に接続するために必要な抽象化です例、チュートリアルを参照してください WordPress と MySQL での永続ディスクの使用GKE による負荷分散多くの大規模な Web サービス アーキテクチャでは、トラフィックの需要を共有できる複数のサーバーを実行する必要があります。GKE を使用して複数のコンテナ、ノード、ポッドを作成および管理できるため、負荷分散されたウェブ サービス システムに自然に適合しますネットワーク負荷分散の使用GKE でロードバランサを作成する最も簡単な方法は、Compute Engine のネットワーク負荷分散を使用することです。ネットワーク負荷分散は、アドレス、ポート、プロトコル タイプなどの受信インターネット プロトコル データに基づいてシステムの負荷を分散できます。ネットワーク負荷分散は転送ルールを使用します。これらのルールは、負荷分散に使用できるインスタンスを一覧表示するターゲット プールを指します
ネットワーク負荷分散を使用すると、SMTP トラフィックなどの追加の TCP/UDP ベースのプロトコルを負荷分散でき、アプリでパケットを直接検査できます。
を追加するだけで、ネットワーク負荷分散を展開できます。
タイプ: ロードバランサー
フィールドをサービス構成ファイルに
HTTP(S) 負荷分散の使用
HTTPS ロード バランシング、コンテンツ ベースのロード バランシング、クロスリージョン ロード バランシングなど、より高度なロード バランシング機能が必要な場合は、GKE サービスを Compute Engine の HTTP / HTTPS ロード バランシング機能と統合できます。 Kubernetes は、外部トラフィックを Kubernetes エンドポイントにルーティングするためのルールのコレクションをカプセル化する Ingress リソースを提供します。 GKE では、Ingress リソースが Compute Engine HTTP / HTTPS ロードバランサのプロビジョニングと構成を処理します。
GKE で HTTP / HTTPS 負荷分散を使用する方法の詳細については、Ingress を使用した HTTP 負荷分散の設定をご覧ください。
GKE によるスケーリング
クラスターの自動サイズ変更には、Cluster Autoscaler を使用できます。この機能は、空きリソースのあるノードを待機しているがスケジュールされていないポッドがあるかどうかを定期的にチェックします。そのようなポッドが存在する場合、サイズ変更によって待機中のポッドをスケジュールできる場合、オートスケーラーはノード プールのサイズを変更します。
Cluster Autoscaler は、すべてのノードの使用状況も監視します。ノードが長期間必要とされず、そのすべてのポッドを別の場所でスケジュールできる場合、ノードは削除されます
Cluster Autoscaler、その制限事項、およびベスト プラクティスの詳細については、Cluster Autoscaler のドキュメントを参照してください。
GKE によるロギングとモニタリング
Compute Engine と同様に、Logging と Monitoring はロギング サービスとモニタリング サービスを提供します。 Logging は、アプリやサービスからログを収集して保存します。ログエージェントを使用して、ログを表示またはエクスポートし、サードパーティのログを統合できます
Monitoring は、サイトのダッシュボードとアラートを提供します。 Monitoring は Google Cloud コンソールで構成します。クラウド サービス、仮想マシン、および MongoDB、Apache、Nginx、Elasticsearch などの一般的なオープン ソース サーバーのパフォーマンス メトリックを確認できます。 Monitoring API を使用してモニタリング データを取得し、カスタム指標を作成できます
GKE を使用した DevOps の管理
GKE を使用すると、ほとんどの人が DevOps について考えるときに考える利点の多くをすでに得ています。これは、パッケージ化、展開、および管理の容易さに関しては特に当てはまります。 CI/CD ワークフローのニーズに合わせて、Jenkins などの一般的なツールを利用できます。次の記事を参照してください。
## App Engine を使用したマネージド プラットフォームでの構築
Google Cloud では、サービスとしてのマネージド プラットフォーム（PaaS）は 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
- Java のハローワールド
- PHP のハローワールド
- Ruby の Hello World
- Go の Hello World
- Node.js の Hello World
次のチュートリアルは、フレキシブル環境の使用を開始するのに役立ちます。
- Python 入門
- Java 入門
- PHP 入門
- Go 入門
- Node.js を使い始める
- Ruby 入門
- .NET の概要
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 コンソールにログインします。 App Engine も動作します
ロギング機能を提供する標準の言語固有のライブラリと
ログエントリを Google Cloud コンソールのログに転送します。例えば、
Pythonで
標準の Python ロギング モジュールを使用して、
Javaで
logback アペンダーを統合するか、
java.util.logging
Cloud Logging を使用します。このアプローチにより、Cloud Logging の全機能が有効になります
数行の Google Cloud 固有のコードのみを必要とします
Cloud Monitoring は、App Engine アプリをモニタリングするための機能を提供します。 Google Cloud コンソールを使用して、インシデント、稼働時間チェック、その他の詳細をモニタリングできます
## 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 がコンテナ インスタンスの自動スケーリングを管理します
あなたのために。各リビジョン
処理に必要なコンテナ インスタンスの数に自動的にスケーリングされます
すべての受信リクエスト。デフォルトでは、リビジョンがトラフィックを受信しない場合
ゼロのコンテナー インスタンスにスケーリングされます。ただし、必要に応じて、
このデフォルトを変更して、アイドル状態を維持するインスタンスを指定するか、
*暖かい*使用
最小インスタンス設定
Cloud Run によるロギングとモニタリング
Cloud Run には 2 種類のログがあり、Cloud Logging に自動的に送信されます。
- リクエスト ログ: Cloud Run サービスに送信されたリクエストのログ。これらのログは自動的に作成されます
- コンテナー ログ: コンテナー インスタンス (通常は独自のコード) から出力されたログで、コンテナー ログの書き込みで説明されているように、サポートされている場所に書き込まれます。
サービスのログは、いくつかの方法で表示できます。
- Google Cloud コンソールで Cloud Run ページを使用する
- Google Cloud コンソールで Cloud Logging のログ エクスプローラを使用する
これらの表示方法はどちらも、Cloud Logging に保存されている同じログを調べますが、ログ エクスプローラはより詳細で、より多くのフィルタリング機能を提供します
Cloud Monitoring は、Cloud Run のパフォーマンス モニタリング、指標、稼働時間チェックに加えて、特定の指標のしきい値を超えたときに通知を送信するアラートを提供します。 Google Cloud のオペレーション スイートの料金が適用されます。つまり、フルマネージド バージョンの Cloud Run では指標に料金がかかりません。 Cloud Monitoring のカスタム指標も使用できることに注意してください
Cloud Run は Cloud Monitoring と統合されています
*セットアップや構成は必要ありません*。これは、あなたの指標が
Cloud Run サービスは実行中に自動的にキャプチャされます
## コンテンツ管理システムの構築
Web サイトを提供するということは、Web サイトの資産を管理することを意味します。 Cloud Storage は、これらのアセットのグローバル リポジトリを提供します。一般的なアーキテクチャの 1 つは、静的コンテンツを Cloud Storage にデプロイし、Compute Engine と同期して動的ページをレンダリングします。 Cloud Storage は、WordPress、Drupal、Joomla などの多くのサードパーティ コンテンツ管理システムと連携します。 Cloud Storage は Amazon S3 と互換性のある API も提供しているため、Amazon S3 で動作するシステムはすべて Cloud Storage と連携できます。
以下の図は、コンテンツ管理システムのサンプル アーキテクチャです。
＃＃ 次は何ですか
- Google Cloud に関するリファレンス アーキテクチャ、図、チュートリアル、ベスト プラクティスを調べます。クラウド アーキテクチャ センターをご覧ください。
グーグルクラウド
共有ウェブホスティング#69
