ウェブサイトの処理

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

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

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

オプションの選択

GCP を初めて使用する場合は、すでに習熟しているテクノロジーを使用して始めるのが妥当です。たとえば、現在ハードウェア サーバーまたは仮想マシン(VM)を使用して、別のクラウド プロバイダまたは独自のハードウェアなどでサイトをホストしている場合は、Google Compute Engine の使いやすいパラダイムを利用できます。Heroku や Engine Yard などプラットフォームとしてのサービス(PaaS)をすでに使用している場合は、Google App Engine を使用して始めるのが最適です。

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

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

オプション プロダクト 概要
静的ウェブサイト Google Cloud Storage
Firebase Hosting
Cloud Storage バケットから静的ウェブサイトとアセットを配信します。これは GCP の最もシンプルなオプションであり、追加の操作なしで自動的にスケーリングされます。
Cloud Storage を使用する Firebase Hosting は、追加の機能を提供します。
仮想マシン

(Linux と Windows)

Google Compute Engine ユーザーのウェブ ホスティング スタックをインストール、設定、維持します。すべてのコンポーネントを制御できますが、コンポーネントのすべての稼働を維持するのもユーザーの責任となります。幅広いオプションから、負荷分散とスケーラビリティをどのように提供するか決定する必要もあります。

Windows で .NET ベースのウェブサイトを実行する場合は、このオプションを選択します。

コンテナ Google Container Engine コンテナ テクノロジーを使用してコードに内在している依存関係をパッケージ化し、デプロイを容易にします。その後、Container Engine を使用してコンテナのクラスタを管理します。
マネージド プラットフォーム Google App Engine コーディングに集中し、App Engine にデプロイして、Google にシステムの管理を任せます。使用可能な言語とランタイムが規定されるスタンダード環境と、追加のオプションが提供されるものの、自己管理が必要なフレキシブル環境のどちらかを選択できます。

この記事にすべて目を通すと、GCP でのウェブサービスに使用できる主要なテクノロジーと、それらのテクノロジーの仕組みの概要も理解できるようになります。この記事には、準備ができた段階でより詳しい知識を得ることができる完全なドキュメント、チュートリアル、およびソリューションの記事へのリンクも記載されています。

コストについて

コストについては、多くの変数が存在し、また実装ごとに大きく異なる可能性があるため、この記事では、コストに関する特定のアドバイスは行いません。GCP での料金設定について Google の原則を理解するには、料金設定ページをご覧ください。個々のサービスの料金設定を理解するには、プロダクト価格のセクションをご覧ください。また、GCP を使用するコストを評価するのに役立ついくつかのツールを活用することができます。

  • 料金計算ツールを使うと、予想される GCP 使用容量をすばやく簡単に見積もることができます。使用したいサービスについて詳細を入力すると、料金の見積もりを見ることができます。
  • 所有権(TCO)の総コストツールは、クラウド上で計算負荷を実行するための相対的なコストを評価し、コストの見積もりを提供します。このツールは、コスト モデリングのためにユーザーが調整できるいくつかの入力を提供し、その後、Cloud Platform と Amazon Web Services での推定コストを比較します。このツールは、ストレージやネットワークのような一般的なアプリケーションのすべてのコンポーネントをモデルとしません。

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

通常は、サイトのドメイン名を登録します。Google Domains などのパブリック ドメイン名登録事業者を使用して、サイトの一意の名前を登録できます。独自のドメイン ネーム システム(DNS)を完全に制御したい場合は、Google Cloud DNS を 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 を使用してページを手動で作成できます。JekyllGhost、あるいは Hugo などの静的サイト ジェネレータを使用してコンテンツを作成することもできます。静的サイト ジェネレータでは、Markdown で記述することができ、テンプレートとツールを利用できるため、静的ウェブサイトを簡単に作成できます。サイト ジェネレータは通常、コンテンツのプレビューに使用できるローカルのウェブサーバーを提供します。

静的サイトが稼働した後、任意のプロセスを使用して静的ページを更新できます。このプロセスは、更新されたページをバケットに手動でコピーするのと同じように簡単です。GitHub にコンテンツを格納してから、webhook を使用してバケットを更新するスクリプトを実行するなど、より自動化されたアプローチを使用することもできます。さらに高度なシステムでは、Jenkins などの継続的インテグレーション / 継続的デリバリー(CI/CD)ツールを使用してバケットのコンテンツを更新することもあります。Jenkins には、ビルド アーティファクトを Cloud Storage に公開するための Google Cloud Storage Uploader ポストビルド ステップを提供する Cloud Storage プラグインがあります。

静的コンテンツまたはユーザーがアップロードした静的メディアを処理する必要があるウェブ アプリケーションがある場合は、Cloud Storage を使用するとコスト効率の高い効果的な方法でコンテンツをホストおよび処理することができ、ウェブ アプリケーションへの動的リクエストの量も削減できます。

また、Cloud Storage ではユーザーが送信したコンテンツを直接受け入れることができます。この機能により、ユーザーはサーバー経由でプロキシすることなく、大容量のメディア ファイルを安全な方法で直接アップロードできます。

静的ウェブサイトで最高のパフォーマンスを実現するには、Google Cloud Storage のベスト プラクティスをご覧ください。

詳しくは次のページをご覧ください。

Firebase Hosting による静的ウェブサイトのホスティング

Firebase Hosting は、ウェブアプリの高速で安全な静的ホスティングを提供します。Firebase Hosting を使用すると、1 つのコマンドから、ウェブアプリや静的コンテンツをグローバル コンテンツ デリバリ ネットワーク(CDN)にすばやく簡単にデプロイできます。

Firebase Hosting を使用して得られるメリットは次のとおりです。

  • 設定不要な SSL が Firebase Hosting に組み込まれているため、コンテンツは常に安全に配信されます。カスタム ドメインの SSL 証明書を無料でプロビジョニングします。
  • すべてのコンテンツは HTTPS 経由で処理されます。
  • コンテンツは、世界中の CDN エッジからユーザーに迅速に配信されます。
  • Firebase CLI を使用すると、アプリを迅速に立ち上げることができます。コマンドライン ツールを使用すると、デプロイ先をビルドプロセスに容易に追加できます。
  • 新しいアセットのアトミック デプロイメント、完全なバージョニング、ワンクリック ロールバックなどリリース管理機能を利用できます。
  • Hosting が提供する設定は 1 ページのアプリやその他のアプリに似たサイトでも活用できます。
  • Hosting は他の Firebase 機能とシームレスに使用できるよう構築されています。

詳しくは次のページをご覧ください。

Compute Engine での仮想マシンの使用

Infrastructure as a Service(IaaS)の利用方法では、GCP は Google Compute Engine を提供します。Compute Engine は堅牢なコンピューティング インフラストラクチャを提供しますが、使用するプラットフォーム コンポーネントを選択して設定する必要があります。Compute Engine を使う場合、システムを設定、管理、モニタリングするのはデベロッパーの責任です。Google は、リソースを確実に利用可能で信頼性があり、デベロッパーがすぐ使えるようにしますが、それらを使えるように設定し管理するのはデベロッパーの責任です。システムを完全に制御でき、柔軟性が制限されないことが、この利点です。

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

Cloud Launcher を使用した自動設定

完全なウェブサービス スタックをデプロイする最も簡単な方法は、Google Cloud Launcher を使用することです。数回のクリックだけで、純正の Google Click-to-Deploy または Bitnami で完全に動作する、100 を超えるソリューションをどれでもデプロイできます。

Google Cloud Launcher

たとえば、Cloud Launcher を使用して、LAMP スタックまたは WordPress を簡単に設定できます。システムでは、単一インスタンスに短時間で完璧な作業用ソフトウェア スタックをデプロイできます。デプロイする前に、Cloud Launcher には、サイトの実行に関するコストの見積もりと、インストールされるソフトウェアのバージョンに関する明確な情報が示されます。また、コンポーネント インスタンス名を変更したり、マシンタイプを選択したり、ディスクサイズを変更するなど、設定をカスタマイズできます。デプロイした後、Compute Engine インスタンス、その設定、ソフトウェアを完全に制御できます。

手動設定

Compute Engine で、設定を新規に作成するか、Cloud Launcher デプロイメントで設定を作成してインフラストラクチャを手動で作成することもできます。たとえば、Cloud Launcher で提供されないソフトウェア コンポーネントの特定のバージョンを使用する場合や、すべてを独自にインストールおよび設定したい場合に手動設定できます。

ウェブサイトの設定に関する完全なフレームワークとベスト プラクティスについては、この記事で扱いません。ただし、Compute Engine でのウェブサービス インフラストラクチャの技術的な設定として必要な項目を以下に示します。

  • 要件を理解する。新しいウェブサイトを作成する場合は、インスタンス、ストレージのニーズ、ネットワーキング インフラストラクチャなど、必要なコンポーネントを理解していることを確認します。アプリケーションを既存のソリューションから移行する場合は、すでにこれらの要件を理解しているかもしれませんが、既存の設定が GCP サービスにどのようにマッピングされるかを検討する必要があります。
  • 設計を計画する。アーキテクチャを十分に検討し、設計を書き出します。できるだけ正確に書き出します。
  • コンポーネントを作成する。コンピュータやネットワークなど通常物理アセットと考えられているコンポーネントは、Compute Engine のサービスを介して提供されます。たとえば、コンピュータが必要な場合は、Compute Engine インスタンスを作成する必要があります。永続ハードディスク ドライブが必要な場合は、それも作成します。 Google Cloud Deployment Manager を使うと、この作業を簡単で繰り返し可能なプロセスにすることができます。
  • 設定、カスタマイズする。 必要なコンポーネントが揃った後は、それらを設定し、ソフトウェアをインストールおよび設定して、必要なカスタマイズ コードを作成およびデプロイする必要があります。シェル スクリプトを実行して設定をレプリケートすることもできます。これは、将来の新たなデプロイメントを迅速に実行するのに有用です。Cloud 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 を設定できます。Cloud Platform 上でのストレージ サービスの全範囲と利点については、ストレージ オプションの選択をご覧ください。

Compute Engine による負荷分散

大規模に運用されるウェブサイトでは、負荷分散テクノロジーを使用してワークロードをサーバー間で分散することが要件になる場合がよくあります。Compute Engine では負荷分散されたウェブサーバーの構築時に、次のようなさまざまなオプションを利用できます。

  • HTTP(S)負荷分散。 Compute Engine のロードバランサを使用する際の基礎事項を説明します。
  • ネットワーク負荷分散。 このシナリオでは、正常に動作しているインスタンスの間で HTTP トラフィックを分散させるようにレイヤ 3 負荷分散を設定します。
  • コンテンツ ベースの負荷分散。 受信 URL に基づいてトラフィックをさまざまなインスタンスに分散する方法をデモンストレーションします。
  • クロスリージョン負荷分散。 複数のリージョンで Compute Engine インスタンスを設定し、HTTP と HTTPS の負荷分散を使用してトラフィックをリージョンに分散する方法をデモンストレーションします。
  • NGINX を使用した HTTP(S)負荷分散. Compute Engine のロードバランサの代わりに使用できる 1 つのソリューションについて順を追って説明します。
  • Microsoft IIS バックエンドによるクロスリージョン負荷分散。 Compute Engine のロードバランサを使用してトラフィックを Microsoft Internet Information Services(IIS)サーバーに分散する方法を説明します。
  • Internal Load Balancing の設定 インターネットに公開されていないプライベート ネットワークにネットワーク トラフィックを分散するロードバランサを設定できます。内部負荷分散は、すべてのトラフィックがプライベート ネットワーク上に留まっているイントラネット アプリケーションに対してだけでなく、フロントエンドがプライベート ネットワーク経由でバックエンド サーバーにリクエストを送信する複雑なウェブ アプリケーションに対しても有用です。
  • HAProxy と Consul を使用したオートスケール内部負荷分散。 HAProxy 負荷分散階層とバックエンド サーバーの両方で自動スケーリングをサポートするように以前の構成を拡張します。

Compute Engine によるオートスケーリング

需要の変化に応じてサーバーの追加や削除ができるようにアーキテクチャを設定できます。このアプローチでは、サイトはピーク時の負荷でもパフォーマンスを維持する一方で、一般的な需要の時期もコストをコントロール下に置き続けることができます。Compute Engine は、この目的に使用できるオートスケーラーを提供します。

オートスケーリングはマネージド インスタンス グループの機能です。マネージド インスタンス グループは、共通のインスタンス テンプレートから作成された同種の仮想マシン インスタンスのプールです。オートスケーラーは、マネージド インスタンス グループでインスタンスを追加または削除します。Compute Engine にはマネージド インスタンス グループと非マネージド インスタンス グループがありますが、オートスケーラーで使用できるのはマネージド インスタンス グループだけです。Compute Engine のドキュメントには、Compute Engine のオートスケーリングに関する完全なガイドが含まれています。

拡張性と復元力のあるウェブアプリ ソリューションの構築方法の詳細については、スケーラブルで復元力のあるアプリの構築をご覧ください。

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

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

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

Stackdriver logging

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

Stackdriver monitoring ダッシュボード

Compute Engine による DevOps の管理

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

Container Engine でのコンテナの使用

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

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

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

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

Container Engine でのデータの保存

Container Engine は GCP で実行され、Compute Engine インスタンスをノードとして使用するため、ストレージ オプションの多くは Compute Engine のストレージと共通しています。Cloud SQL、Cloud Storage、Cloud Datastore、Cloud Bigtable に API を使ってアクセスするか、選択した別の外部ストレージ プロバイダを使用することもできます。ただし、Container Engine は、通常の Compute Engine インスタンスとは異なる方法で Compute Engine 永続ディスクとやりとりします。

Compute Engine インスタンスには接続されたディスクが含まれます。Compute Engine を使用する場合は、インスタンスが存続する限り、ディスク ボリュームはインスタンスとともに残ります。ディスクとの接続を解除して、別のインスタンスで使用することもできます。ただし、コンテナ内では、オンディスク ファイルは一時的なファイルです。クラッシュ後などにコンテナが再起動すると、オンディスク ファイルは失われます。Kubernetes では、ボリュームを抽象化してこの問題を解決し、ボリュームのタイプの 1 つは gcePersistentDisk になります。これにより、コンテナで Compute Engine 永続ディスクを使用して、Container Engine の使用時にデータファイルが削除されないようにすることができます。

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

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

Container Engine による負荷分散

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

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

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

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

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

HTTP(S)負荷分散の使用

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

Container Engine での HTTP/HTTPS 負荷分散の使用の詳細については、このドキュメントを参照してください

Container Engine によるスケーリング

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

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

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

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

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

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

Container Engine による DevOps の管理

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

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

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

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

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

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

プログラミング言語

App Engine のスタンダード環境では、Python 2.7Java 7/Servlet 2.5PHP 5.5.34Go のデフォルトのランタイムが提供されます。フレキシブル環境には、Java 8/Servlet 3.1、Java 7/Jetty 9Python 2.7 と Python 3.4Node.js 4.2.3Go のネイティブ サポートが含まれます。フレキシブル環境内では、これらのランタイムをカスタマイズしたり、カスタムの Docker イメージや Dockerfile を使用する独自のランタイムが提供されます。

使用しているプログラミング言語が主要な懸念事項である場合は、App Engine 標準が提供するランタイムが要件に満たしているか判断する必要があります。要件を満たしていない場合は、フレキシブル環境の使用を検討してください。

言語別のチュートリアルの開始

以下のチュートリアルは、App Engine スタンダード環境の使用を開始する際に役立ちます。

以下のチュートリアルは、フレキシブル環境の使用を開始する際に役立ちます。

App Engine でのデータの保存

App Engine には、以下のデータ保存オプションがあります。

名前 ストラクチャ 整合性
Cloud Datastore スキーマレス グローバル クエリの実行時以外は強整合性
Cloud SQL リレーショナル 強整合性
Cloud Storage ファイルと関連付けられたメタデータ バケットやオブジェクトのリストを取得するリスト オペレーションの実行時を除いて強整合性

スタンダード環境で複数のサードパーティ データベースを使用することもできます。

App Engine でのストレージの詳細については、このドキュメントを参照してください。ドキュメントのページを開いた後に、ページの右上で言語名をクリックして希望するプログラミング言語を選択できます。

フレキシブル環境を使用する場合、スタンダード環境で使用できるストレージ オプションすべてと、より幅広いサードパーティ データベースも利用できます。フレキシブル環境でのサードパーティ データベースの詳細については、サードパーティ データベースの使用をご覧ください。

App Engine による負荷分散とオートスケーリング

App Engine で構築する場合、負荷分散とオーストケーリングは自動的に管理されます。

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

App Engine では、リクエストは自動的にログに記録され、それらのログは Cloud Platform Console で表示できます。App Engine は、ログ機能を提供する標準の言語固有のライブラリでも機能し、ログエントリをコンソールのログに送ります。たとえば、Python では標準の Python ロギング モジュールを使用し、Java では java.util.logging.Logger API を使用できます。

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

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

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

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

Google Cloud Platform のコンテンツ管理システム

次のステップ

外出先でもリソースをモニタリング

Google Cloud Console アプリを入手して、プロジェクトの管理にお役立てください。

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