ウェブサイトの処理

この記事では、Google Cloud Platform(GCP)でウェブサイトをホストする方法について説明します。GCP は、ウェブサイトを処理するための堅牢性、柔軟性、信頼性、スケーラビリティに優れたプラットフォームを提供します。Google は、Google.com、YouTube、Gmail などのサイトのコンテンツの処理に使用しているものと同じインフラストラクチャを使用して GCP を構築しています。ニーズに最適なインフラストラクチャのタイプと設計を使用して、ウェブサイトのコンテンツを処理できます。

この記事は、次のような方を対象にしています。

  • ウェブサイトの作成方法に関する知識があり、ウェブサービス インフラストラクチャをデプロイ、実行した経験がある方。
  • サイトを GCP に移行するかどうか、またその方法を検討中の方。

シンプルなウェブサイトを構築したい場合は、Google サイト(構造化された Wiki やウェブページの作成ツール)の使用を検討してください。詳しくは、サイトのヘルプをご覧ください。

オプションの選択

GCP を初めて使用する場合は、すでに習熟しているテクノロジーを使用して始めるのが妥当です。たとえば、現在ハードウェア サーバーまたは仮想マシン(VM)を使用して、別のクラウド プロバイダや独自のハードウェアでサイトをホストしている場合、Compute Engine が提供する使い慣れたパラダイムを利用できます。Heroku や Engine Yard などの PaaS(Platform as a Service)製品をすでに使用している場合は、App Engine から始めるとよいでしょう。

GCP を十分に理解してから、GCP が提供するプロダクトとサービスの優れた点を確認できます。たとえば、Compute Engine を使用した場合は、Google Kubernetes Engine(GKE)を使用してサイトの機能を拡張したり、機能の一部または全部を App Engine に移行したりできます。

次の表で、GCP のホスティング オプションの概要を説明します。

オプション サービス データ ストレージ 負荷分散 スケーラビリティ ログ
静的ウェブサイト

Cloud Storage

Firebase Hosting

Cloud Storage バケット なし 自動 なし
仮想マシン Compute Engine

Cloud SQL Admin 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 の使用状況を見積もることができます。使用したいサービスについて詳細を入力すると、料金の見積もりを見ることができます。
  • 総所有コスト(TCO)ツールを使用すると、GCP で計算負荷を実行するための相対的なコストを評価できます。このツールには、コスト モデリングのための入力項目がいくつか用意されており、それを調整しながら GCP と Amazon Web Services(AWS)の見積もりコストを比較できます。このツールは、一般的なアプリのすべてのコンポーネント(ストレージやネットワーキングなど)をモデル化しているわけではありません。

ドメインネーム サービスの設定

通常は、サイトのドメイン名を登録します。Google Domains などのパブリック ドメイン名登録事業者を使用して、サイトの一意の名前を登録できます。独自のドメインネーム システム(DNS)を完全に制御したい場合は、DNS プロバイダとして Cloud DNS を利用できます。Cloud DNS のドキュメントには、利用する際に役立つクイックスタートが含まれています。

既存の DNS プロバイダを使用する場合は、そのプロバイダ用のレコードを作成する必要があります。example.com などのドメイン名の場合は、DNS プロバイダ用に A レコードを作成します。www.example.com サブドメインの場合、wwwCNAME レコードを作成して 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 を使用してページを手動で作成できます。JekyllGhostHugo などの静的サイト ジェネレータを使用してコンテンツを作成することもできます。静的サイト ジェネレータを使用すると、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)のユースケースとして、GCP には Compute Engine があります。Compute Engine は堅牢なコンピューティング インフラストラクチャを提供しますが、使用するプラットフォーム コンポーネントを選択して構成する必要があります。Compute Engine を使う場合、システムを構成、管理、モニタリングするのはデベロッパーの責任です。Google は、リソースを、確実に利用可能で信頼性があり、デベロッパーがすぐ使えるようにしますが、それらを使えるように設定し管理するのはデベロッパーの責任です。システムを完全に制御でき、柔軟性が制限されないことが、この利点です。

Compute Engine を使用して、必要なほぼすべてのウェブサイト サービス システムを設計およびデプロイできます。インスタンスと呼ばれる VM を使用して、独自のハードウェア インフラストラクチャを使用しているかのように、アプリを構築します。Compute Engine にはさまざまなマシンタイプがあり、ニーズと予算に合わせて構成をカスタマイズできます。任意のオペレーティング システムや、開発スタック、言語、フレームワーク、サービス、その他のソフトウェア技術を選択できます。

GCP Marketplace を使用した自動設定

ウェブサービス スタック全体をデプロイする最も簡単な方法は、GCP Marketplace を使用することです。Google クリック デプロイまたは 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 を使用すると、リソースの自動デプロイで宣言型の柔軟な構成テンプレートを利用できます。PuppetChef などの IT 自動化ツールも利用できます。
  • アセットをデプロイする。ウェブページや画像は用意してあるものとします。
  • テストする。すべてが予想どおりに機能するか確認します。
  • 本番環境にデプロイする。サイトを公開し、使用できるようにします。

Compute Engine インスタンスの手動設定を開始する場合や、理解が必要な場合は、次のチュートリアルをご覧ください。

Compute Engine へのデータの格納

ほとんどのウェブサイトにはなんらかの種類のストレージが必要です。ユーザーがアップロードするファイルを保存するため、また、サイトで使用するアセットを保存するためなど、さまざまな理由でストレージが必要になる場合があります。

GOP は、次のようなさまざまなマネージド ストレージ サービスを提供しています。

  • MySQL をベースとする、Cloud SQL 内の SQL データベース。
  • NoSQL データ ストレージの 2 つのオプション(Cloud DatastoreCloud Bigtable)。
  • Cloud Storage 内の、整合性がありスケーラブルな大容量オブジェクト ストレージ。Cloud Storage にはいくつかのクラスがあります。
    • Multi-Regional は、最大の可用性と地域的な冗長性を提供します。
    • Regional は、最大の可用性とローカライズされたストレージ ロケーションを提供します。
    • Nearline は、月に 1 回未満しかアクセスしないデータに最適な低コストの選択肢です。
    • Coldline は、アーカイブ、バックアップ、障害復旧に適した最低コストの選択肢です。
  • インスタンス用のプライマリ ストレージとして使用する、Compute Engine 上の永続ディスク。Compute Engine では、標準永続ディスクと呼ばれるハードディスク ベースの永続ディスクと、ソリッド ステート ディスク(SSD)の両方が提供されています。また、永続ディスクを使用して Compute Engine 上でお好みのストレージ テクノロジーを設定できます。たとえば、SQL データベースとして PostgreSQL を設定することも、NoSQL ストレージとして MongoDB を設定することもできます。GCP で使用できる各種ストレージ サービスとその利点については、ストレージ オプションの選択をご覧ください。

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 を使用できます。HAProxy 負荷分散階層とバックエンド サーバー層の両方で自動スケーリングを行う方法については、HAProxy と Consul を使用した内部負荷分散の自動スケーリングをご覧ください。Compute Engine のロードバランサの代わりに使用できるソリューションについては、NGINX を使用した HTTP(S) 負荷分散をご覧ください。

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 によるロギングとモニタリング

GCP には、ウェブサイトで生じたことをモニタリングするために使用できる機能があります。

Stackdriver Logging は、GCP 上のアプリやサービスからログを収集して保存します。ログを表示またはエクスポートし、ログ エージェントを使用してサードパーティのログを統合できます。

Logging

Stackdriver Monitoring には、サイト向けのダッシュボードとアラートが用意されています。これは Monitoring Console を使用して構成します。クラウド サービス、仮想マシン、一般的なオープンソース サーバー(MongoDB、Apache、Nginx、Elasticsearch など)のパフォーマンス指標を確認できます。Stackdriver Monitoring API を使用すると、モニタリング データを取得してカスタム指標を作成できます。

モニタリング ダッシュボード

Compute Engine による DevOps の管理

Compute Engine による DevOps の管理については、以下の記事をご覧ください。

GKE でのコンテナの使用

Docker コンテナなどのコンテナをすでに使用している場合があります。ウェブサービスに対して、コンテナには次のようないくつかのメリットがあります。

  • コンポーネント化。コンテナを使用して、ウェブアプリのさまざまなコンポーネントを分離できます。たとえば、サイトでウェブサーバーとデータベースを実行しているとします。これらのコンポーネントを別個のコンテナで実行すれば、他のコンテナに影響を与えずに、1 つのコンポーネントを変更および更新できます。アプリの設計が複雑になればなるほど、マイクロサービスなどのサービス指向アーキテクチャに適したコンテナが有用になります。この種の設計は、さまざまな目標の中で特にスケーラビリティをサポートします。
  • ポータビリティ。コンテナには実行する必要のあるものがすべて揃っています。たとえば、アプリとその従属関係が一緒にバンドルされています。コンテナは、基になるシステムの詳細を気にすることなく、さまざまなプラットフォームで実行できます。
  • 迅速なデプロイ。デプロイ時には、システムは一連の定義とイメージから構築されるため、迅速かつ信頼できる方法で各部分を自動的にデプロイできます。一般的にコンテナは小さいので、仮想マシンなどと比べてかなり高速にデプロイされます。

GCP でのコンテナ コンピューティングは、以下の点を含め、ウェブサービスではさらにメリットがあります。

  • オーケストレーションGKE は、Google 独自のオープンソース コンテナ オーケストレーション システムである Kubernetes をベースに構築されたマネージド サービスです。GKE を使用して、Compute Engine インスタンスで構成されるクラスタの一部であるコンテナでコードを実行できます。個々のコンテナを管理したり、各コンテナを手動で作成したりシャットダウンしたりする代わりに、定義した構成を使用する GKE でクラスタを自動管理できます。
  • イメージ登録Container Registry は、GCP の Docker イメージ用のプライベート ストレージを提供します。Container Registry には HTTPS エンドポイントを通じてアクセスできるため、Compute Engine インスタンスや独自のハードウェアなどのあらゆるマシンからイメージを pull できます。レジストリ サービスは、GCP プロジェクトで Cloud Storage 内のカスタム イメージをホストします。このアプローチにより、デフォルトで、プロジェクトのメンバーのみがカスタム イメージにアクセスできるようになります。
  • モビリティ。ワークロードを他のクラウド プロバイダで移動および結合したり、クラウド コンピューティングのワークロードをオンプレミスの実装と混在させてハイブリッド ソリューションを作成したりできる柔軟性があります。

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 ではボリュームの抽象化によりこの問題を解決します。ボリュームのタイプの 1 つが gcePersistentDisk です。つまり、コンテナで Compute Engine 永続ディスクを使用して、GKE の使用時にデータファイルを削除されないようにすることができます。

ボリュームの機能とメリットを理解するには、まずポッドについて理解する必要があります。ポッドは、1 つ以上のコンテナに対するアプリ固有の論理ホストと考えることができます。ポッドはノード インスタンスで実行されます。コンテナがポッドのメンバーである場合、コンテナは、共有ストレージ ボリュームのセットなど、複数のリソースを共有できます。これらのボリュームを使用すると、データはコンテナが再起動しても存続し、ボリュームをポッド内のコンテナ間で共有できます。もちろんポッドで単一のコンテナやボリュームも使用できますが、これらのリソースを相互に論理的に接続するための抽象化として必要なのがポッドです。

例については、WordPress と MySQL での永続ディスクの使用をご覧ください。

GKE による負荷分散

多くの大規模なウェブサービス アーキテクチャでは、トラフィックの需要を共有できる複数のサーバーを実行する必要があります。GKE を使用すると、複数のコンテナ、ノード、ポッドを作成および管理できるため、負荷分散ウェブサービス システムに適しています。

ネットワーク負荷分散の使用

Compute Engine のネットワーク負荷分散を使用すると、GKE でロードバランサを簡単に作成できます。ネットワーク負荷分散では、アドレス、ポート、プロトコル タイプなどの受信インターネット プロトコル データに基づいてシステムの負荷を分散できます。ネットワーク負荷分散では転送ルールを使用します。転送ルールは、負荷分散に使用できるインスタンスをリストしたターゲット プールを指し示します。

ネットワーク負荷分散を使用すると、SMTP トラフィックなどの追加の TCP/UDP ベース プロトコルを負荷分散でき、アプリはパケットを直接検査できます。

type: LoadBalancer フィールドをサービス構成ファイルに追加するだけで、ネットワーク負荷分散をデプロイできます。

HTTP(S) 負荷分散の使用

HTTPS 負荷分散、コンテンツ ベースの負荷分散、クロスリージョン負荷分散など、より高度な負荷分散機能が必要な場合は、GKE サービスを Compute Engine の HTTP / HTTPS 負荷分散と統合できます。Kubernetes は、外部トラフィックを Kubernetes のエンドポイントにルーティングするためのルールの集合をカプセル化する上りリソースを提供します。GKE で、上りリソースは、Compute Engine の HTTP / HTTPS ロードバランサのプロビジョニングと構成を処理します。

GKE で HTTP / HTTPS 負荷分散を使用する方法の詳細については、Ingress での HTTP 負荷分散の設定をご覧ください。

GKE によるスケーリング

クラスタのサイズを自動的に変更するには、クラスタ オートスケーラーを使用します。この機能は、空きリソースのあるノードを待っているが、スケジュールされていないポッドがあるかどうか定期的にチェックします。こうしたポッドが存在し、待機中のポッドをスケジュールできる場合、クラスタ オートスケーラーはノードプールのサイズを変更します。

また、クラスタ オートスケーラーはすべてのノードの使用状況をモニタリングします。ノードが長時間にわたって必要とされず、そのポッドをすべて他のノードにスケジュール設定できる場合、そのノードは削除されます。

クラスタ オートスケーラーの概要、制限事項およびベスト プラクティスについては、クラスタ オートスケーラーのドキュメントをご覧ください。

GKE によるロギングとモニタリング

Compute Engine の場合と同様に、Logging がロギング サービスを提供し、Monitoring がモニタリング サービスを提供します。Logging は、アプリとサービスからログを収集し、保存します。ログを表示またはエクスポートし、ログ エージェントを使用してサードパーティのログを統合できます。

Monitoring には、サイト向けのダッシュボードとアラートが用意されています。これは Monitoring Console を使用して構成します。クラウド サービス、仮想マシン、一般的なオープンソース サーバー(MongoDB、Apache、Nginx、Elasticsearch など)のパフォーマンス指標を確認できます。Monitoring API を使用して、モニタリング データを取得し、カスタム指標を作成できます。

GKE による DevOps の管理

GKE を使用すれば、DevOps のメリットと考えられている点の多くが GKE にもあることがわかります。これは特に、パッケージング、デプロイ、管理の容易さという点において該当します。CI / CD ワークフローのニーズがある場合は、Jenkins などの一般的なツールを利用できます。以下の記事をご覧ください。

App Engine によるマネージド プラットフォームでのビルド

GCP では、マネージドの Platform as a Service(PaaS)を Google App Engine と呼びます。App Engine でウェブサイトを構築すると、ユーザーは機能のコーディングに集中し、それを支えるインフラストラクチャの管理は Google に任せることができます。App Engine には、スケーラビリティ、負荷分散、ロギング、モニタリング、セキュリティを自分で構築したり管理したりするよりも大幅に簡素化できる、幅広い機能が用意されています。App Engine では、さまざまなプログラミング言語でコードを作成できます。また、他のさまざまな GCP サービスを使用することもできます。

App Engine は、アプリを安全なサンドボックス環境で実行できる、スタンダード環境を提供します。App Engine のスタンダード環境では、複数のサーバーにリクエストが分散され、トラフィック需要に合わせてサーバーがスケーリングされます。アプリは、ハードウェア、オペレーティング システムまたはサーバーの物理的な場所に依存しない、独自の安全かつ信頼できる環境内で実行されます。

App Engine とその他のコンポーネントを使用するウェブアプリ

App Engine には、さらに多くのオプションを利用できるフレキシブル環境が用意されています。このフレキシブル環境を使用すると、アプリは構成可能な Compute Engine インスタンスで実行されますが、ホスティング環境の管理は App Engine で自動的に実行されます。これにより、カスタムのランタイムを含む追加のランタイムを使用でき、さらに多くのプログラミング言語の中から選択できます。また、さまざまな CPU およびメモリ オプションから選択できるなど、Compute Engine の柔軟性を活用することもできます。

プログラミング言語

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 では、java.util.logging.Logger API を使用できます。

Monitoring には、App Engine アプリをモニタリングする機能があります。GCP Console では、インシデント、稼働時間チェック、その他の詳細をモニタリングできます。

コンテンツ管理システムの構築

ウェブサイトの処理とは、ウェブサイト アセットを管理することを意味します。Cloud Storage には、これらのアセット用のグローバル リポジトリが用意されています。1 つの共通アーキテクチャは、静的コンテンツを Cloud Storage にデプロイした後、Compute Engine と同期して動的ページをレンダリングします。Cloud Storage は、WordPressDrupalJoomla など、多くのサードパーティのコンテンツ管理システムと連携します。Cloud Storage は Amazon S3 互換 API も提供するため、Amazon S3 と連携するどのシステムでも Cloud Storage で使用できます。

コンテンツ管理システムのアーキテクチャ例については、コンテンツ管理をご覧ください。

GCP でのコンテンツ管理システム

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...