はじめに

クラウドコンピューティングサービスを使用するにあたり、AWS を使ったことのある方は多いとおもいますが、マルチクラウド環境を構築する必要があったり、所属する組織のルールなどでAWS以外のクラウドを使用する必要に迫られることもあるかとおもいます。

本記事では、私が実務においてGoogle Cloud でインフラ構築をする際に感じたAWSとの違いや、構築時のポイントについて、リソースごとに3回に分けて取り上げたいとおもいます。

今回は第2回目の記事となります。前回の記事はこちらです。是非併せてご覧ください。

対象リソース・記載範囲

本記事では以下リソースの概要と、設計・構築におけるポイントを取り上げます。リソースの詳細については触れていない部分があること、使用料金、運用保守関連については記載対象外としておりますのでご承知おきください。

  • Compute Engine
  • Cloud Run
  • サーバーレスVPCアクセス
  • Cloud Load Balancing
  • Cloud Armor

Compute Engine

概要

Compute Engine は、Google Cloud 上で稼働する仮想マシン（以下 VM と称します）を作成できるインフラストラクチャーとしてのサービス（IaaS）の一部です。Google が提供する Linux または Windows Server の公開イメージが使用できるほか、オンプレミスで稼働するサーバーからインポートしたカスタムイメージも使用が可能です。カスタムイメージを利用することで、オンプレミス環境からの移行に対応することができます。
AWS でいう Amazon EC2 にあたるサービスです。

主な特徴

  • 拡張性
    必要に応じてリソースを追加または削減することができ、大規模なデータ処理や計算タスクにも対応が可能です。
  • カスタマイズ性
    仮想マシンのタイプやサイズ、ストレージ、ネットワーク構成など、多くのカスタマイズオプションが利用できます。
  • 高パフォーマンス、可用性
    Googleの高速なネットワークとデータセンターを利用して高パフォーマンスが実現できるほか、ライブマイグレーション機能によりダウンタイムを抑えることが可能です。

設計・構築のポイント

インスタンスタイプの選択

システム要件から、必要なリソース（CPU, RAM, GPUなど）を正確に評価しコストとパフォーマンスのバランスを考えて最適なインスタンスタイプを選択します。マシンファミリーの詳細は、マシンファミリー 公式ドキュメントを参照ください。

例として、計算依存型ワークロードなどのコンピューティング負荷の高いワークロードには、コンピューティング最適化マシン ファミリーを選択する、インメモリデータベースなどのメモリを多く消費するワークロードにはメモリ最適化マシン ファミリーを選択するなど、ワークロードタイプに適したものを選択するようにします。

ストレージの選択

Compute Engine では以下のストレージオプションが選択可能です。
ワークロードの性質などから、最適なストレージを選択します。

  • ゾーン永続ディスク
  • リージョン永続ディスク
  • ローカル SSD
  • Hyperdisk

永続ディスクは不揮発性であり、VM の停止時にもデータが失われることはありません。永続ディスクはさらにゾーン永続ディスクとリージョン永続ディスクに分かれます。高可用性が求められるワークロードには、リージョン永続ディスクの使用を検討します。

永続ディスクは以下のディスクタイプから選択が可能です。ワークロードの特性によって最適なものを選択します。詳細については 永続ディスクタイプ 公式ドキュメントを参照ください。

  • 標準永続ディスク
  • バランス永続ディスク
  • パフォーマンス（SSD）永続ディスク
  • エクストリーム永続ディスク

ローカルSSDは揮発性であり、停止時には保存内容が失われます。ただし永続ディスクと比べて高い IOPS とレイテンシを実現できる特徴があります。ステートレスアプリにおける一時ファイルの保存用途などがユースケースになります。

Hyperdisk は、2023年6月にGAされたもので、IOPS やスループットなどのパフォーマンスを動的に調整できるブロックストレージです。ミッションクリティカルなワークロード向けに設計されています。詳細は Hyperdisks ドキュメント をご参照ください。

ネットワーク

VM は、VPC上に作成します。通信要件に基づいて、外部（インターネット）との通信を行う（Cloud NAT を用いるかなど）を考慮します。適宜 VPC ピアリング使用の必要性なども検討します。

セキュリティ

通信要件に基づき、VPCファイアウォール ルールを定義して、通信の許可や拒否を設定します。

VM への接続(SSH)については、大きく以下に分かれます。セキュリティ要件によって最適なものを選択します。個人的に Identity-Aware Proxy を使用した方法が、踏み台サーバの用意も不要となるのでオススメです。

  • コンソール
  • SSH ターミナルソフト
  • Identity-Aware Proxy 経由（コンソール、ターミナルソフト使用可能）

※ Identity-Aware Proxy イメージ（公式ドキュメントから引用）

データの暗号化については、デフォルトで Compute Engine の全ての保存データは暗号化されます。暗号化処理や管理は自動で行われます。ユーザー側で管理を行いたい場合、 CSEK（顧客指定の独自作成された暗号鍵）や、CMEK（Cloud KMS によって生成される顧客で管理する暗号鍵）の使用を検討します。

スケーラビリティと可用性

VM の用途が Webサーバーなどのスケールアウトが可能なものについては、マネージドインスタンスグループ(MIG)の使用を検討します。可用性要件から、複数のゾーンやリージョンを使用します。 MIG は、AWS でいう AutoScalingGroup にあたるサービスです。また、後述する Cloud Load Balancing の使用についても併せて検討します。

Cloud Run

概要

Cloud Run は、Google のインフラ上で直接コンテナを実行できる、フルマネージド型のサーバーレスコンピューティングプラットフォームです。コンテナイメージをビルドできる任意の言語やフレームワークを使用することが可能です。

サーバーレスのコンテナ実行環境サービスということで、AWS でいう ECS(Fargate) にあたるサービスという印象を持たれる方もいるかもしれませんが、大きく違うところがあります。Cloud Run は VPC上のリソースではないということです。この点については後ほど触れます。

主な特徴

  • サーバーレス
    サーバーのプロビジョニング、管理、スケーリングを気にすることなく、コードを実行することができます。
  • コンテナベース
    アプリケーションをコンテナ化することで、ローカル環境でのテストと本番環境での実行が容易になります。
  • 自動スケーリング
    トラフィックの増減に応じて、インスタンス数を自動的にスケーリングすることが出来ます。トラフィックがない場合はインスタンス数を0にすることも可能です。
  • HTTPベース
    Cloud Run は HTTP リクエストをトリガーとして動作します。これにより、WebアプリケーションやAPIなどを容易にホストすることができます。
  • フルマネージド
    サーバーやインフラの管理は Google が行うため、開発者はアプリケーションの開発に集中できます。
  • 統合
    Cloud Run は他の Google Cloud サービスとの統合が容易で、例えば Pub/Sub, Cloud Storage などのサービスを簡単に利用できます。

設計・構築のポイント

スケーラビリティと可用性

トラフィックの増減に応じて自動スケーリングをするよう設定が可能です。コンテナインスタンス数を最小0に設定することが可能ですが、トラフィックが生じた際の初期化に時間がかかる場合があるため、最小インスタンス数を1以上にしてウォームスタンバイとするか検討します。

コンテナインスタンスあたりの最大同時リクエスト数はデフォルトで80に設定されています。コンテナのリクエスト処理能力によって、値を調節します。（処理能力が高い場合は同時実行数を増やすなど）

可用性について、Cloud Run のサービスはリージョン内の複数ゾーンに自動複製されるようになっています。

セキュリティ

利用者を制限したい場合は、 IAM にて利用するユーザーの制限が可能なため、そちらを検討します。
また、後述する Cloud Armor を使用して 不正なアクセスや攻撃に対してフィルタリングをかけることも検討が必要だとおもいます。Cloud Armor は Cloud Load Balancing の背後にある Web アプリケーションを保護しますので、Cloud Load Balancing についての考慮も併せて必要になってきます。

APIキーやパスワードなどの機密情報を使用する場合は、Secret Manager で作成したシークレットに保存し、コンテナでシークレットを使用する方法が勧められていますので、その方法を採用するか検討します。Secret Manager についての詳細は割愛させていただきます。詳細は公式ドキュメントをご参照ください。

ネットワーク

概要で触れたように、Cloud Run は VPC上のリソースではないため、Compute Engine や Cloud SQL といった VPCリソースを使用するためには、後述のサーバーレスVPCアクセスを使う必要があります。

※ サーバーレスVPCアクセス構成図（公式ドキュメントより引用）

また、外部サービス(APIなど)との連携が必要なワークロードにおいて、Cloud Run 側の IPを固定したい場合は、サーバレスVPCアクセスを使用して Cloud NAT 経由で通信を行うことで実現が可能です。通信要件によりこういった経路を検討します。

サーバーレスVPCアクセス

概要

サーバーレスVPCアクセスは、Google Cloud のサーバーレス プラットフォームから仮想プライベート クラウド（VPC）リソースへの接続を可能にする機能です。使用することで、Cloud Functions、App Engine、Cloud Run などのサーバーレス サービスから、VPC 内のリソース（例: Compute Engine インスタンス、Cloud SQL、VPC ネットワーク ピアリング など）に接続することができます。

コンピュート系というよりはネットワーク系のリソースになりますが、本記事にて触れるCloud Run と関連が深いため、ここで取り上げます。

主な特徴

  • プライベート接続
    サーバーレスプロダクト(Cloud Runなど)のインスタンスとVPCネットワークのリソース間の通信はGoogleの内部ネットワークを経由します。これにより、公開されていないVPCリソースへのアクセスが安全に保たれます。
  • スケーラビリティ
    サーバーレス VPC アクセスは、高いトラフィックの要求を処理するために自動的にスケールします。
  • VPCピアリングとの統合
    サーバーレスVPCアクセスを使用すると、VPCネットワークピアリングを介して他のGoogle Cloudプロジェクトやオンプレミスネットワークのリソースにも接続することができます。

設計・構築のポイント

コネクタ作成

サーバーレスVPCアクセスの使用にあたって、VPC内にコネクタを作成します。コネクタは、/28 CIDR のVPC内専用サブネットとコネクタインスタンスから成ります。

コネクタインスタンスのスループットとスケーリング

インスタンスは3つのタイプから選択が可能で、スループット範囲が異なります。ワークロードのトラフィックを考慮しマシンタイプを選択します。詳細は公式ドキュメントにてご確認ください。

インスタンスはスケールアウトが可能で、最小数（デフォルト2）と最大数（デフォルト10）を設定します。スケールアウトにより追加されるインスタンスは初めに指定したタイプとなり、追加されたインスタンスはスケールインしないという仕様になっています。増加したインスタンス数を減らしたい場合はコネクタを再作成する必要があるので注意が必要です。

Cloud Load Balancing

概要

Cloud Load Balancing は、Google Cloud 上で稼働するアプリケーションのトラフィックを、複数のインスタンスやリージョンに自動的に分散させるためのソフトウェアで定義された完全分散型のマネージド サービスです。これにより、アプリケーションは高い可用性と低遅延を実現し、大量のトラフィックでも安定したパフォーマンスを提供することができます。

AWS でいう ELB にあたるサービスと言えます。

主な特徴

  • 様々な種類のロードバランス機能
    Cloud Load Balancingは、HTTP/HTTPS、TCP/UDP、SSL Proxy & TCP Proxy、Internal TCP/UDP など様々な種類のロードバランスに対応しています。
  • 高可用性
    事前のプロビジョニングや予測を必要とせず、ピークトラフィックの負荷を自動的に処理します。
  • セキュリティ
    HTTPSを使用してのトラフィックのロードバランシング、SSL/TLSの終了、Google Front End (GFE) の利用によるDDoS攻撃の軽減などのセキュリティ機能が備わっています。
  • CDN 機能との連携
    Google Cloud の提供する CDNサービスである Cloud CDN は、Cloud Load Balancing(外部HTTPS負荷分散) と連携してコンテンツ配信を行います。一般的な CDN は、ロードランサーの前段にてリクエストを受けますが、Cloud CDNは、外部HTTP(S)負荷分散が利用するキャッシュとして実装がなされています。

設計・構築のポイント

ロードバランスタイプの選択

Cloud Load Balancing では9種類のロードバランサが用意されています。選択の仕方については大まかに以下となります。

  • トラフィックの種類（HTTP/HTTPS か TCP/UDP/他プロトコル）
  • 外部用か内部用か
  • グローバルかリージョナルか
  • プロキシ型かパススルー型か

※ ロードバランサーの選択方法（公式ドキュメントより引用）

よくある HTTP/HTTPS によるwebサーバーへの負荷分散に使用するユースケースの場合、Global external Application Load Balancer または、Regional external Application Load Balancer を使用します。ただし、2023年9月現在、Regional external Application Load Balancer については、Cloud Armor セキュリティポリシー の使用がプレビューとなっています。セキュリティを考慮すると Global external Application Load Balancer を使用した方が良さそうです。

本記事では、以降 Global external Application Load Balancer について解説します。

オリジンバックエンドの指定、振り分け

オリジンに指定できるバックエンドは以下5種類です。

  • インスタンスグループ（Compute Engine）
  • Cloud Storage バケット
  • サーバーレスネットワークエンドポイントグループ（Cloud Run, App Engine, Cloud Functions）
  • ゾーンネットワークエンドポイントグループ（Compute Engine, Kubernetes Engine）
  • インターネット ネットワークエンドポイントグループ

例として、Compute Engine と Cloud Storage を使用する Webアプリケーションなどの場合、URLのホストとパス名によってトラフィックを振り分けることができるため、どのように振り分けを行うかを検討します。

CDN の使用

Cloud CDN は Cloud Load Balancing と連携してコンテンツを配信します。使用有無を検討するほか、使用する場合はワークロードに合ったキャッシュのライフサイクルを検討します。

バックエンドサービスの作成時にCDNの使用有無を選択することができ、AWS CloudFront のように、様々な値を設定してリソースを作成するという必要はありません。

Cloud Armor

概要

Cloud Armorは、Google Cloud 用の分散型拒否サービス (DDoS) 防御とウェブアプリケーションファイヤウォール (WAF) ソリューションです。負荷分散器のレベルでトラフィックを保護し、不正なアクセスや攻撃からユーザーのアプリケーションやサービスを守る役割を果たします。

主な特徴

  • DDoS防御
    Googleのグローバルインフラストラクチャを利用して、DDoS攻撃を吸収・ミティゲートします。
  • IP ベースのブラックリスト/ホワイトリスト
    特定のIPアドレスや範囲からのアクセスを許可または拒否するルールを設定できます。
  • WAF機能
    一般的なウェブベースの脅威やOWASP Top 10などの攻撃を検出・ブロックするルールセットを持っています。
  • カスタムルール
    ユーザーは独自のセキュリティルールを定義して、特定のトラフィックパターンを許可または拒否することができます。
  • 適用範囲
    Cloud Armorのルールは Cloud Load Balancing に関連付けられ、これにより特定のバックエンドサービスやバックエンドバケットに対するトラフィックを保護することができます。

設計・構築のポイント

セキュリティポリシー、ルールの設定

基本モード（IPアドレス、IP範囲で指定）、詳細モード（CEL で記述する）でルールを設定します。OWASP10 を軽減する事前設定ルールも提供されていますので、どの攻撃を防ぐかを検討します。

要件により、WAFルールの細かい運用などが求められる場合は、サードパーティの自動運用サービスの使用を検討してもよいとおもいます。

DDoS対策

Managed Protection というDDoS 保護サービスが2 つのサービスティアで提供されています。デフォルトではスタンダードティアとなっており、こちらでも一定の DDoS 対策機能は備わっています。追加の機能やDDoS 対応サポートチームの支援を受けたい場合などは、プラスティアの使用を検討します。

プレビューモード

Cloud Armor にはプレビューモードという機能があり、実際に拒否や許可などを行わず、設定したセキュリティポリシーが意図した通りに動作しているか確認をすることができます。所謂ドライランです。特に本番環境などで設定を変更する際は活用を検討します。

おわりに

今回はコンピューティング関連リソースについて触れてきました。AWSと類似するところもありますが、Google Cloud 独自の概念やサービスがもありますので、理解して適切に使用することが求められます。次回はデータベース系リソースについて取り上げます。