この記事では、Google Cloud でウェブサイトをホストする方法について説明します。Google Cloud は、ウェブサイトを提供するための堅牢性、柔軟性、信頼性が高くスケーラブルなプラットフォームを提供します。Google は、Google.com、YouTube、Gmail などのサイトからのコンテンツの提供で使用しているものと同じインフラストラクチャを使用して、Google Cloud を構築しました。ニーズに最適なインフラストラクチャの種類と設計を使用して、ウェブサイトのコンテンツを提供できます。
この記事は、次のような方を対象にしています。
- ウェブサイトの作成方法に関する知識が豊富で、ウェブ ホスティング インフラストラクチャをデプロイ、実行した経験がある方。
- サイトを Google Cloud に移行するかどうか、またその方法を検討中の方。
シンプルなウェブサイトを構築する場合は、Google サイト（構造化された Wiki やウェブページの作成ツール）の使用を検討してください。詳しくは、サイトのヘルプをご覧ください。
オプションの選択
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 でのホスティング オプションをまとめたものです。
| オプション | サービス | データ ストレージ | ロード バランシング | スケーラビリティ | ロギングとモニタリング |
|---|---|---|---|---|---|
| 静的ウェブサイト | Cloud Storage Firebase Hosting |
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 の使用コストを概算できます。使用するサービスについて詳細を入力すると、料金の見積もりを見ることができます。
ドメインネーム サービスの設定
通常は、サイトのドメイン名を登録します。パブリック ドメイン名登録事業者を使用して、サイトの一意の名前を登録できます。独自のドメインネーム システム（DNS）を完全に制御する場合は、DNS プロバイダとして Cloud DNS を利用できます。Cloud DNS のドキュメントには、利用する際に役立つクイックスタートが含まれています。
既存の DNS プロバイダを使用する場合は、そのプロバイダ用のレコードを作成する必要があります。example.com などのドメイン名の場合は、DNS プロバイダを使用して A レコードを作成します。www.example.com サブドメインの場合、www の CNAME レコードを作成して example.com ドメインを指定します。A レコードは、ホスト名を IP アドレスにマッピングします。CNAME レコードは、A レコードのエイリアスを作成します。
ドメイン名登録事業者が DNS プロバイダでもある場合は、通常はこの操作で十分です。登録と DNS に別々のプロバイダを使用する場合は、ドメインに関連付けられた正しいネームサーバーがドメイン名登録事業者にあることを確認してください。
ゾーンの有効期間（TTL）値によっては、DNS を変更してから、レコードの更新が反映されるまでしばらく時間がかかることがあります。新しいホスト名である場合は、短期間に変更が有効になります。これは、DNS リゾルバで以前の値がキャッシュに保存されておらず、DNS プロバイダに問い合わせてリクエストのルーティングに必要な情報を取得することがあるためです。
静的ウェブサイトのホスティング
HTTP(S) でウェブサイト コンテンツを提供する最も単純な方法は、静的ウェブページをホストすることです。静的ウェブページは、通常は HTML で記述されたままの状態で変更されずに提供されます。静的ウェブサイトは、ブログの投稿や小規模ビジネスのウェブサイトの一部など、公開後にほとんどページが変更されない場合に適しています。静的ウェブページでもかなりのことが可能ですが、サーバー側コードを使ってサイトでユーザーと安定したやりとりを行う必要がある場合は、この記事で説明されている他のオプションを検討してください。
Cloud Storage を使用した静的ウェブサイトのホスティング
Cloud Storage で静的サイトをホストするには、Cloud Storage バケットを作成し、コンテンツをアップロードして、新しいサイトをテストする必要があります。storage.googleapis.com から直接データを提供することも、ドメインを所有していることを確認してドメイン名を使用することもできます。
静的ウェブページはどのような方法を選択しても作成できます。たとえば、HTML と CSS を使用してページを手入力で作成できます。静的サイト生成ツール（Jekyll、Ghost、Hugo など）を使用してコンテンツを作成できます。静的サイト生成ツールを使用すると、Markdown で記述が可能な上、テンプレートやツールも利用できるため、静的ウェブサイトを簡単に作成できます。サイト ジェネレータは通常、コンテンツのプレビューに使用できるローカルのウェブサーバーを提供します。
静的サイトが稼働した後、任意のプロセスを使用して静的ページを更新できます。更新したページをバケットに手動でコピーするという単純なプロセスでも可能です。GitHub にコンテンツを格納してから、バケットを更新するスクリプトを webhook を使用して実行するなど、より自動化されたアプローチを使用することもできます。さらに高度なシステムでは、Jenkins などの継続的インテグレーション / 継続的デリバリー（CI / CD）ツールでバケットのコンテンツを更新することも考えられます。Jenkins には、ビルド アーティファクトを Cloud Storage に公開するための Google Cloud Storage Uploader ポストビルド手順を提供する Cloud Storage プラグインがあります。
静的コンテンツまたはユーザーがアップロードした静的メディアを提供する必要があるウェブアプリでは、Cloud Storage を使用するとコスト効率の高い効果的な方法でコンテンツをホストおよび提供でき、ウェブアプリへの動的リクエストの量も削減できます。
また、Cloud Storage ではユーザーが送信したコンテンツを直接受け入れることができます。この機能により、ユーザーはサーバー経由でプロキシを使用することなく、大容量のメディア ファイルを安全に直接アップロードできます。
静的ウェブサイトからパフォーマンスを最大限に引き出すには、Cloud Storage のベスト プラクティスをご覧ください。
詳しくは次のページをご覧ください。
Firebase Hosting による静的ウェブサイトのホスティング
Firebase Hosting は、ウェブアプリに高速で安全な静的ホスティングを提供します。Firebase Hosting を使用すると、1 つのコマンドでウェブアプリと静的コンテンツをグローバルのコンテンツ配信ネットワーク（CDN）にデプロイできます。
Firebase Hosting を使用して得られるメリットは次のとおりです。
- 構成不要な SSL が Firebase Hosting に組み込まれています。カスタム ドメインの SSL 証明書を無料でプロビジョニングします。
- すべてのコンテンツが HTTPS 経由で送信されます。
- コンテンツは、世界中の CDN エッジからユーザーに配信されます。
- Firebase CLI を使用して、アプリを迅速に稼働させることができます。コマンドライン ツールを使用して、デプロイのターゲットをビルドプロセスに追加します。
- 新しいアセットのアトミック デプロイ、完全なバージョニング、ワンクリック ロールバックなどのリリース管理機能を利用できます。
- Hosting により単一ページのアプリに役立つ構成が提供されます。これは、他のアプリライクなサイトでも有用です。
- Hosting は他の 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 クリック デプロイまたは Bitnami を使用すれば、数回のクリックだけで、100 を超える完全に確立されたソリューションをどれでもデプロイできます。
たとえば、Cloud Marketplace を使用して、LAMP スタックまたは WordPress を設定できます。システムでは、単一インスタンスに短時間で完璧な作業用ソフトウェア スタックをデプロイできます。デプロイする前に、Cloud Marketplace には、サイトの実行にかかる費用の見積もりと、インストールするソフトウェア コンポーネントのバージョンに関するわかりやすい情報が表示されます。また、コンポーネント インスタンス名の変更、マシンタイプの選択、ディスクサイズの選択を行い、構成をカスタマイズできます。デプロイした後、Compute Engine インスタンス、その構成、ソフトウェアを完全に制御できます。
手動設定
Compute Engine にインフラストラクチャを手動で作成することもできます。手動の場合は、構成をゼロから作成することも、Google Cloud Marketplace デプロイで作成することもできます。たとえば、Cloud Marketplace で提供されていないソフトウェア コンポーネントのバージョンを使用できます。また、すべて独自にインストールして構成することも可能です。
ウェブサイトの設定に関する完全なフレームワークとベスト プラクティスについては、この記事で扱いません。ただし、Compute Engine でのウェブ ホスティング インフラストラクチャの技術的な設定として必要な項目の概要を以下に示します。
- 要件を理解する。新しいウェブサイトを構築する場合は、インスタンス、ストレージのニーズ、ネットワーキング インフラストラクチャなど、必要なコンポーネントを理解していることを確認します。既存のソリューションからアプリを移行する場合は、すでにこれらの要件を理解しているかもしれませんが、既存の設定が Google Cloud サービスにどのようにマッピングされるかを十分に考える必要があります。
- 設計を計画する。アーキテクチャを十分に検討し、設計を書き留めます。設計をできる限り明確化してください。
- コンポーネントを作成する。コンピュータやネットワーク スイッチなど、通常物理アセットと考えられているコンポーネントは、Compute Engine のサービスを介して提供されます。たとえば、コンピュータが必要な場合は、Compute Engine インスタンスを作成する必要があります。永続ハードディスク ドライブが必要な場合は、それも作成します。Terraform などの Infrastructure as Code ツールを使用すると、このプロセスが簡単で繰り返し可能になります。
- 構成とカスタマイズを行う。必要なコンポーネントが揃ったらそれらを構成し、ソフトウェアをインストールおよび構成して、必要なカスタマイズ コードを作成およびデプロイする必要があります。シェル スクリプトを実行して構成を複製することもできます。これは、将来のデプロイを迅速に実行するうえで役立ちます。ここでも Terraform を使用すると、リソースの自動デプロイで宣言型の柔軟な構成テンプレートを利用できます。Puppet や Chef などの IT 自動化ツールも利用できます。
- アセットをデプロイする。ウェブページや画像は用意してあるものとします。
- テストする。すべてが予想どおりに機能するか確認します。
- 本番環境にデプロイする。サイトを公開し、使用できるようにします。
Compute Engine へのデータの格納
ほとんどのウェブサイトにはなんらかの種類のストレージが必要です。ユーザーがアップロードするファイルを保存するため、また、サイトで使用するアセットを保存するためなど、さまざまな理由でストレージが必要になる場合があります。
Google Cloud には、次のようなさまざまなマネージド ストレージ サービスが用意されています。
- Cloud SQL の SQL データベース。MySQL、PostgreSQL、SQL Server 用のフルマネージド リレーショナル データベース サービスです。
- NoSQL データ ストレージの 2 つのオプション（Firestore と Bigtable）。
- Memorystore。Redis および Memcached 対応のフルマネージド インメモリ データストア サービスです。
- Cloud Storage。整合性がありスケーラブルな大容量オブジェクト ストレージです。Cloud Storage には、いくつかのクラスがあります。
- Standard は最大の可用性を提供します。
- Nearline は、月に 1 回未満しかアクセスされないデータに最適な低コストの選択肢です。
- Coldline は、四半期に 1 回未満しかアクセスされないデータに最適な低コストの選択肢です。
- Archive は、アーカイブ、バックアップ、障害復旧のための最低コストの選択肢です。
- インスタンス用のメイン ストレージとして使用する、Compute Engine 上の永続ディスク。Compute Engine では、標準永続ディスクと呼ばれるハードディスク ベースの永続ディスクと、ソリッド ステート ディスク（SSD）の両方が提供されています。また、永続ディスクを使用して Compute Engine 上でお好みのストレージ テクノロジーを設定できます。たとえば、SQL データベースとして PostgreSQL を設定することも、NoSQL ストレージとして MongoDB を設定することもできます。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 Internet Information Services（IIS）サーバーに分散する方法を説明します。
- 内部ロード バランシングの設定。インターネットに公開されていないプライベート ネットワークに、ネットワーク トラフィックを分散するロードバランサを設定できます。内部ロード バランシングは、すべてのトラフィックがプライベート ネットワークに留まっているイントラネット アプリだけでなく、フロントエンドがプライベート ネットワーク経由でバックエンド サーバーにリクエストを送信する複雑なウェブアプリでも役立ちます。
ロード バランシングは柔軟にデプロイできます。たとえば、既存のソリューションで Compute Engine を使用できます。たとえば、Nginx を使用した HTTP(S) ロード バランシングは、Compute Engine ロードバランサの代わりに使用できるソリューションの一つです。
Compute Engine によるコンテンツの配信
どのウェブサイトでもレスポンス時間は基本的な指標となります。特に、グローバル ウェブ トラフィックを処理するサイトでは、CDN を使用してレイテンシを短くし、パフォーマンスを向上させることが重要になります。
Cloud CDN は、世界各地にある Google の接続拠点を使用して、ユーザーに最も近いキャッシュからコンテンツを配信します。Cloud CDN は HTTP(S) ロード バランシングに対応しています。Compute Engine または Cloud Storage（もしくはその両方）のコンテンツを単一の IP アドレスから配信するには、HTTP(S) ロードバランサ用に Cloud CDN を有効にします。
Compute Engine による自動スケーリング
需要の変化に応じて、サーバーを追加および削除するようにアーキテクチャを設定できます。このアプローチでは、サイトはピーク時の負荷でもパフォーマンスを維持する一方で、一般的な需要の時期もコストをコントロール下に置き続けることができます。Compute Engine は、この目的に使用できるオートスケーラーを提供します。
自動スケーリングはマネージド インスタンス グループの機能です。マネージド インスタンス グループは、共通のインスタンス テンプレートから作成された同種の仮想マシン インスタンスのプールです。オートスケーラーは、マネージド インスタンス グループでインスタンスを追加または削除します。Compute Engine にはマネージド インスタンス グループと非マネージド インスタンス グループがありますが、オートスケーラーで使用できるのはマネージド インスタンス グループだけです。詳細については、Compute Engine での自動スケーリングをご覧ください。
スケーラブルで復元力のあるウェブアプリ ソリューションの構築方法の詳細については、スケーラブルで復元力のあるアプリの構築をご覧ください。
Compute Engine によるロギングとモニタリング
Google Cloud には、ウェブサイトで何が起きているかをモニタリングするために使用できる機能があります。
Cloud Logging は、Google Cloud 上のアプリとサービスからログを収集して保存します。ログを表示またはエクスポートし、ログ エージェントを使用してサードパーティのログを統合できます。
Cloud Monitoring には、サイト向けのダッシュボードとアラートが用意されています。Monitoring は Google Cloud コンソールを使用して構成します。クラウド サービス、仮想マシン、一般的なオープンソース サーバー（MongoDB、Apache、Nginx、Elasticsearch など）のパフォーマンス指標を確認できます。Cloud Monitoring API を使用すると、モニタリング データを取得してカスタム指標を作成できます。
また、Cloud Monitoring では稼働時間チェックを行い、リクエストをウェブサイトに送信して応答するかどうかを確認できます。稼働時間チェックが失敗した場合にインシデントを生成するアラート ポリシーをデプロイすると、ウェブサイトの可用性をモニタリングできます。
Compute Engine による DevOps の管理
Compute Engine で DevOps を管理する方法については、Kubernetes を使用した分散負荷テストをご覧ください。
GKE でのコンテナの使用
場合によっては、Docker コンテナなどのコンテナをすでにご使用かもしれません。ウェブ ホスティングに対して、コンテナには次のようないくつかのメリットがあります。
- コンポーネント化。コンテナを使用して、ウェブアプリのさまざまなコンポーネントを分離できます。たとえば、サイトでウェブサーバーとデータベースを実行しているとします。これらのコンポーネントを別個のコンテナで実行すれば、他のコンテナに影響を与えずに、1 つのコンポーネントを変更および更新できます。アプリの設計が複雑になればなるほど、マイクロサービスなどのサービス指向アーキテクチャに適したコンテナが有用になります。この種の設計は、さまざまな目標の中で特にスケーラビリティをサポートします。
- ポータビリティ。コンテナには実行する必要のあるものがすべて揃っています。たとえば、アプリとその従属関係が一緒にバンドルされています。コンテナは、基になるシステムの詳細を気にすることなく、さまざまなプラットフォームで実行できます。
- 迅速なデプロイ。デプロイ時には、システムは一連の定義とイメージから構築されるため、迅速かつ信頼できる方法で各部分を自動的にデプロイできます。一般的にコンテナは小さいので、仮想マシンなどと比べてかなり高速にデプロイされます。
Google Cloud のコンテナ コンピューティングには、次のようなウェブ ホスティングのさらなるメリットがあります。
- オーケストレーション。GKE は、Google が導入したオープンソースのコンテナ オーケストレーション システムである Kubernetes をベースに構築されたマネージド サービスです。GKE を使用して、Compute Engine インスタンスで構成されるクラスタの一部であるコンテナでコードを実行できます。個々のコンテナの管理や、各コンテナの手動での作成とシャットダウンの代わりに、定義した構成を使用する GKE でクラスタを自動管理できます。
- イメージ登録。Artifact Registry は、Google Cloud の Docker イメージ用のプライベート ストレージを提供します。このレジストリには HTTPS エンドポイントを介してアクセスできるため、Compute Engine インスタンスや独自のハードウェアなど、あらゆるマシンからイメージを pull できます。このレジストリ サービスは、Google Cloud プロジェクトの Cloud Storage 内でカスタム イメージをホストします。このアプローチにより、デフォルトでは、プロジェクトへのアクセス権を持つプリンシパルのみがカスタム イメージにアクセスできるようになります。
- モビリティ。ワークロードを他のクラウド プロバイダで移動および結合したり、クラウド コンピューティングのワークロードをオンプレミスの実装と混在させてハイブリッド ソリューションを作成したりできる柔軟性があります。
GKE でのデータの保存
GKE は Google Cloud 上で実行され、Compute Engine インスタンスをノードとして使用するため、ストレージ オプションには Compute Engine のストレージと多くの共通点があります。API を使用して Cloud SQL、Cloud Storage、Firestore、Bigtable にアクセスできます。また選択すれば、他の外部ストレージ プロバイダを使用することもできます。ただし、GKE は、通常の Compute Engine インスタンスとは異なる方法で Compute Engine 永続ディスクとやりとりします。
Compute Engine インスタンスにはアタッチされたディスクが含まれます。Compute Engine を使用する場合は、インスタンスが存続する限り、ディスク ボリュームはインスタンスとともに残ります。ディスクとの接続を解除して、別のインスタンスで使用することもできます。ただし、コンテナ内では、オンディスク ファイルは一時的なファイルです。クラッシュ後などにコンテナが再起動すると、オンディスク ファイルは失われます。Kubernetes は、ボリュームとストレージ クラスの抽象化を使用してこの問題を解決します。ストレージ クラスの一種として GCE PD があります。つまり、コンテナで Compute Engine 永続ディスクを使用すると、GKE の使用時にデータファイルを削除されないようにすることが可能です。
ボリュームの機能とメリットを理解するには、まず Pod について理解する必要があります。Pod は、1 つ以上のコンテナに対するアプリ固有の論理ホストと考えることができます。Pod はノード インスタンスで実行されます。コンテナがポッドのメンバーである場合、コンテナは、共有ストレージ ボリュームのセットなど、複数のリソースを共有できます。これらのボリュームを使用すると、データはコンテナが再起動しても存続し、ボリュームをポッド内のコンテナ間で共有できます。もちろんポッドで単一のコンテナやボリュームも使用できますが、これらのリソースを相互に論理的に接続するための抽象化として必要なのがポッドです。
例については、WordPress と MySQL での永続ディスクの使用チュートリアルをご覧ください。
GKE によるロード バランシング
多くの大規模なウェブ ホスティング アーキテクチャでは、トラフィックの需要を共有できる複数のサーバーを実行する必要があります。GKE を使用すると、複数のコンテナ、ノード、Pod を作成および管理できるため、ロード バランシング ウェブ ホスティング システムに適しています。
ネットワーク ロード バランシングの使用
Compute Engine のネットワーク負荷分散を使用すると、GKE でロードバランサを簡単に作成できます。ネットワーク ロード バランシングでは、アドレス、ポート、プロトコル タイプなどの受信インターネット プロトコル データに基づいてシステムの負荷を分散できます。ネットワーク ロード バランシングでは転送ルールを使用します。転送ルールは、ロード バランシングに使用できるインスタンスをリストしたターゲット プールを指定します。
ネットワーク ロード バランシングを使用すると、SMTP トラフィックなどの追加の TCP/UDP ベース プロトコルをロードバランスでき、アプリはパケットを直接検査できます。
type: LoadBalancer フィールドをサービス構成ファイルに追加するだけで、ネットワーク ロード バランシングをデプロイできます。
HTTP(S) ロード バランシングの使用
HTTPS ロード バランシング、コンテンツ ベースのロード バランシング、クロスリージョン ロード バランシングなど、より高度なロード バランシング機能が必要な場合は、GKE サービスを Compute Engine の HTTP / HTTPS ロード バランシング機能と統合できます。Kubernetes は、外部トラフィックを Kubernetes のエンドポイントにルーティングするためのルールの集合をカプセル化する Ingress リソースを提供します。GKE で、Ingress リソースは、Compute Engine の HTTP / HTTPS ロードバランサのプロビジョニングと構成を処理します。
GKE で HTTP / HTTPS ロード バランシングを使用する方法の詳細については、Ingress での HTTP ロード バランシングの設定をご覧ください。
GKE によるスケーリング
クラスタのサイズを自動的に変更するには、クラスタ オートスケーラーを使用します。この機能は、空きリソースのあるノードを待っているが、スケジュールされていないポッドがあるかどうか定期的にチェックします。こうしたポッドが存在し、待機中のポッドをスケジュールできる場合、クラスタ オートスケーラーはノードプールのサイズを変更します。
また、クラスタ オートスケーラーはすべてのノードの使用状況をモニタリングします。ノードが長時間にわたって必要とされず、そのポッドをすべて他のノードにスケジュール設定できる場合、そのノードは削除されます。
クラスタ オートスケーラーの概要、制限事項およびベスト プラクティスについては、クラスタ オートスケーラーのドキュメントをご覧ください。
GKE によるロギングとモニタリング
Compute Engine の場合と同様に、Logging がロギング サービスを提供し、Monitoring がモニタリング サービスを提供します。Logging は、アプリとサービスからログを収集し、保存します。ログを表示またはエクスポートし、Logging エージェントを使用してサードパーティのログを統合できます。
Monitoring には、サイト向けのダッシュボードとアラートが用意されています。Monitoring は Google Cloud コンソールを使用して構成します。クラウド サービス、仮想マシン、一般的なオープンソース サーバー（MongoDB、Apache、Nginx、Elasticsearch など）のパフォーマンス指標を確認できます。Monitoring API を使用して、モニタリング データを取得し、カスタム指標を作成できます。
GKE による DevOps の管理
GKE を使用すれば、DevOps のメリットと考えられている点の多くが GKE にもあることがわかります。これは特に、パッケージング、デプロイ、管理の容易さという点において該当します。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 によって管理されます。これにより、カスタムのランタイムを含む追加のランタイムを使用でき、さらに多くのプログラミング言語の中から選択できます。また、さまざまな CPU およびメモリ オプションから選択できるなど、Compute Engine の柔軟性を活用することもできます。
プログラミング言語
App Engine スタンダード環境では、デフォルトのランタイムが提供されます。サポートされているプログラミング言語の特定のバージョンでソースコードを記述します。
フレキシブル環境では、サポートされているプログラミング言語のいずれかのバージョンでソースコードを記述します。これらのランタイムをカスタマイズすることも、カスタム Docker イメージまたは Dockerfile で独自のランタイムを提供することもできます。
使用しているプログラミング言語が主要な懸念事項である場合は、App Engine スタンダード環境が提供するランタイムが要件を満たしているか判別する必要があります。要件を満たしていない場合は、フレキシブル環境の使用を検討してください。
アプリに最適な環境を判断するには、App Engine 環境の選択をご覧ください。
言語別の入門チュートリアル
以下のチュートリアルは、App Engine スタンダード環境の使用を開始する際に役立ちます。
- Python の Hello World
- Java の Hello World
- PHP の Hello World
- Ruby の Hello World
- Go の Hello World
- Node.js の Hello World
以下のチュートリアルは、フレキシブル環境の使用を開始する際に役立ちます。
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 のストレージ、データベース、ML などを利用してフルスタック サーバーレス アプリケーションを構築できます。
コンテナ化されたウェブサイトの場合は、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 ゲートウェイなどのミドルウェアを使用してサービスを強化することもできます。
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 Observability の料金が適用されます。つまり、フルマネージド バージョンの Cloud Run では指標に料金はかかりません。また、Cloud Monitoring のカスタム指標も使用できます。
Cloud Run は Cloud Monitoring と統合されています。設定や構成を行う必要はありません。Cloud Run サービスの指標は、実行中に自動的に取得されます。
コンテンツ管理システムの構築
ウェブサイトの処理とは、ウェブサイト アセットをホスティングすることを意味します。Cloud Storage には、これらのアセット用のグローバル リポジトリが用意されています。1 つの共通アーキテクチャは、静的コンテンツを Cloud Storage にデプロイした後、Compute Engine と同期して動的ページをレンダリングします。Cloud Storage は、WordPress、Drupal、Joomla など、多くのサードパーティのコンテンツ管理システムと連携します。Cloud Storage は Amazon S3 互換 API も提供するため、Amazon S3 と連携するどのシステムも Cloud Storage と連携できます。
下の図は、コンテンツ マネジメント システムのサンプル アーキテクチャです。
次のステップ
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センターをご覧ください。