はじめに

この記事では、Google Cloud Platform（GCP）とAmazon Web Services（AWS）が提供するサービスを比較します。

VPCとサブネット

AWS

AWSでは、リージョン内の複数のアベイラビリティゾーン（AZ）を含む、IPアドレス範囲（CIDR）を定義して仮想プライベートクラウド（VPC）を作成します。サブネットはVPCのCIDR範囲内に作成され、特定のAZに割り当てられます。

AWSでは、固有のIPアドレス範囲（CIDRブロック）を指定してVPCを作成し、そのVPC内に複数のサブネットを指定します。各サブネットは特定のAZに関連付けられ、VPCのIPアドレス範囲の一部となるIPアドレス範囲を持ちます。

このセットアップにより、ネットワーク構成の細かな制御が可能となり、ネットワークリソースのセキュリティと分離が保証されます。ただし、IPアドレス範囲とVPC、サブネット、AZの関連性の注意深い管理が必要となります。

GCP

GCPでは、複数のリージョンにまたがるVPCを作成することができ、CIDRの概念は存在しません。代わりに、各リージョンごとに指定されたCIDRを持つサブネットが作成されます。

GCPでは、総合的なCIDRブロックを指定せずに複数のリージョンにまたがるグローバルVPCを作成することができます。GCPのサブネットはCIDRブロックと関連付けられ、特定のリージョンに紐づけられます。これらのリージョナルサブネットは、合わせてグローバルVPCを構成します。

このアプローチにより、リージョン間のシームレスなピアリングが可能となり、世界中からのアクセスを受けるシステムに向いています。VPCの総合的なCIDRブロックの管理を不要にし、よりシンプルなネットワーク管理と拡張性の向上が実現されます。

ファイアウォール

AWS: セキュリティグループ

AWSでは、セキュリティグループ（SG）を使用して、ロードバランサ（LB）やEC2インスタンスなどのリソースへの入出力トラフィックを制御します。

セキュリティグループは、インスタンスに対する入力トラフィックを制御する仮想ファイアウォールとして機能します。セキュリティグループを作成する際には、インスタンスへの入力トラフィックを制御するルールセットと、別のセットの出力トラフィックを制御するルールセットを追加します。

AWSでは、セキュリティグループ内の一対の入力および出力ルールセットを作成します。作成後、セキュリティグループはVPC内の複数のリソースに関連付けることができ、指定されたルールが各リソースに適用されます。

GCP: ファイアウォールルールとタグ

一方、Google Cloudでは、ファイアウォールルールとタグのシステムを使用して入出力トラフィックを管理および制御します。

GCPでは、入出力トラフィック用のファイアウォールルールが作成され、各ルールセットには関連付けられたタグがあります。これらのルールは、対応するタグが付けられたGCEインスタンスなどのインスタンスに適用することができます。

タグベースのルール適用に加えて、GCPのファイアウォールでは各ルールセットの優先度の設定も可能です。複数のルールが適用される場合、優先度がルール適用の順序を決定します。この機能により、ネットワークトラフィックの管理に対する高度な制御が可能となり、重要なルールが最初に適用されることが保証されます。

負荷分散（LB）

AWS: VPC内での負荷分散

AWSでは、負荷分散はVPC内で行われ、そのVPC内のリソースに対してトラフィックを均等に分散します。

一般的なセットアップでは、ロードバランサはインターネット向けのサービスのためにパブリックサブネットに配置されます。ロードバランサは、VPC内のリソース間でトラフィックを均等に分散します。

AWSのインターネット向けロードバランサはパブリックDNS名が割り当てられます。この機能により、ロードバランサはVPC内の適切なリソースに対して、着信トラフィックを適切に管理し、負荷を分散します。

GCP: リージョン間の負荷分散

対照的に、Google Cloudは複数のリージョンにまたがるリソース間で負荷分散を行う機能を提供します。

GCPでは、負荷分散器を設定して複数のリージョンにまたがるリソース間でトラフィックを分散することができます。この高度な機能により、GCPは世界中に散在するリソースを効率的にトラフィック分散することができます。

GCPの負荷分散の特徴的な点として、負荷分散器のフロントエンドには単一のIPアドレスが割り当てられることが挙げられます。この機能により、リソースの管理が簡素化され、着信トラフィックの監視と制御が容易になります。

オブジェクトストレージ

AWS: S3

AWSでは、Simple Storage Service（S3）をスケーラブルで耐久性の高いオブジェクトストレージサービスとして提供しています。

S3は、さまざまなストレージクラスオプション、高い耐久性（11桁の9）、およびライフサイクルルールによる自動データ管理など、堅牢な機能セットを提供しています。

S3はストレージクラスの概念を使用しており、それぞれが異なるアクセス速度とコストを提供し、さまざまなユースケースに適しています。このサービスは驚異的な11桁の9（99.999999999%）の耐久性を提供し、データの安全性を確保します。アクセス制御はACL（アクセス制御リスト）やバケットポリシーを使用して管理することができます。

GCP: Cloud Storage

Google Cloudでは、オブジェクトストレージサービスとしてCloud Storageを提供しています。

S3と同様に、Google Cloud Storageもさまざまなストレージクラス、高い耐久性、およびライフサイクル管理を提供しています。しかし、Cloud Storageには組み込みのキャッシュ機能があり、静的なオブジェクトを低遅延で高速に提供するため、Content Delivery Network（CDN）のような役割も果たすことができます。

Cloud Storageの組み込みキャッシュ機能は、一定期間にわたって公開オブジェクトをキャッシュし、頻繁にアクセスされるデータのキャッシュコンテンツを提供することでパフォーマンスを向上させます。

リレーショナルデータベース（RDB）

GCP: Cloud SQLとCloud Spanner

関係データベース（RDB）はほとんどのアプリケーションの基本要素であり、クラウドプラットフォームで適切なRDBサービスを選択することは重要な役割を果たします。Google Cloud Platform（GCP）では、Cloud SQLとCloud Spannerという2つの人気のあるRDBサービスが提供されています。

Cloud SQLはAWSのRelational Database Service（RDS）に相当するものです。テラバイトスケールのデータストレージをサポートし、水平および垂直スケーリングの両方が可能です。ただし、Cloud SQLはRDSと比較してサポートされるデータベースの種類が少なく、OracleやMariaDBなどをサポートしていません。

Cloud SpannerはGoogleの独自の提供です。これは高性能なグローバル分散型の関係データベースサービスであり、リージョンや大陸をまたがるトランザクションの一貫性を保証します。Cloud SpannerはNewSQLデータベースとして分類され、現時点ではAWSには同等のサービスがありません。Cloud Spannerの強みの一つは、ノードを追加するだけで制限なくスケーリングできることです。ただし、MySQLなどの従来のRDBをサポートしておらず、Cloud Spanner固有の制約もあるため、特定の状況での実装には課題が生じる可能性があります。

AWS: RDSとAurora

AWSでは、GCPのCloud SQLに相当する強力なサービスとしてAmazon RDSを提供しています。MySQL、PostgreSQL、Oracle、MariaDBなど、さまざまなデータベースをサポートしています。さらに、RDSはAmazon Auroraというデータベースエンジンをサポートしています。Amazon AuroraはMySQLよりも5倍、PostgreSQLよりも3倍高速であるとされるデータベースエンジンで、完全に管理されており、MySQLとPostgreSQLに互換性があります。これにより、多くの企業にとって魅力的なオプションとなっています。

NoSQL

GCP: Cloud BigtableとCloud Firestore

NoSQLデータベースは、特に大規模なアプリケーション開発において、高いスループットと低レイテンシーが重要な要素となります。

GoogleのCloud Bigtableは、完全に管理されたスケーラブルなNoSQLデータベースサービスであり、AWSのDynamoDBに類似しています。Cloud Bigtableの特徴的な点は、HBase APIを使用しており、Hadoopなどのビッグデータツールとの統合が容易であることです。これにより、IoTや広告技術分野でのビッグデータ分析に特に適しています。また、Google検索やGmailなどのGoogleのコアサービスで使用されているため、信頼性も高いです。

Cloud Firestoreは、GCPのNoSQLデータベースサービスであり、完全に管理された高速なドキュメントデータベースです。AWSのDocumentDBに類似しています。Firestoreのオフラインサポートは特徴的な機能です。クライアント側のネットワークの中断が発生した場合、Firestoreは更新をローカルにキャッシュし、接続が再開された際にFirestoreに反映します。これにより、開発者はそのようなシナリオを処理する必要がなくなり、時間とリソースを節約できます。

AWS: DynamoDBとDocumentDB

DynamoDBは、任意のスケールでシングルデジットミリ秒のパフォーマンスを提供するキーバリュー型およびドキュメントデータベースです。インターネットスケールのアプリケーションに対して、完全に管理された、マルチリージョン、マルチマスター、耐久性の高いデータベースであり、組み込みのセキュリティ、バックアップとリストア、およびインメモリキャッシュの機能を備えています。

DocumentDB（MongoDB互換）は、MongoDBワークロードをサポートする高速でスケーラブルな完全に管理されたドキュメントデータベースサービスです。開発者は同じMongoDBのアプリケーションコード、ドライバ、ツールを使用して、Amazon DocumentDB上でワークロードを実行、管理、スケーリングすることができ、パフォーマンス、スケーラビリティ、可用性の向上を享受することができます。また、基礎となるインフラストラクチャの管理については心配する必要がありません。

コンテナ

GCP: Cloud Run

コンテナの領域では、Google Cloud Platform（GCP）はCloud Runという完全に管理されたサービスを提供しています。Cloud Runは、コンテナ化されたアプリケーションを自動的にスケーリングするサービスです。Cloud Runはサーバーレスに設計されており、全てのインフラストラクチャ管理を引き受けるため、もっとも重要なことに集中できます。

Cloud Runの特徴の一つは、インスタンスが使用されていない場合にゼロまでスケールダウンできる能力です。これにより、断続的なワークロードに対して費用効果の高いソリューションが提供されます。さらに、開発者はコンテナに最大8vCPUと32GBのメモリを選択できるため、高パフォーマンスのニーズに対応できるスケーラブルなソリューションとなっています。

AWS: App Runner

Cloud Runに対するAWSの同等サービスはApp Runnerであり、Elastic Container Service（ECS）Fargateを基盤に構築されています。Cloud Runと同様に、App Runnerはコンテナ化されたアプリケーションを迅速かつ安全にデプロイするための完全に管理されたサービスです。

ただし、App Runnerは異なる哲学で設計されています。ゼロまでスケールダウンするのではなく、一貫した低レイテンシーを確保するためにコールドスタートを排除することを目指しており、ゼロまでスケールダウンは許可されません。コンテナの仕様に関しては、App Runnerでは最大2vCPUと4GBのメモリが許容されますが、Cloud Runよりは少ないですが、幅広いアプリケーションには十分なスペックとなります。

FaaS

GCP: Cloud Functions

Function as a Service（FaaS）は、開発者が基礎となるインフラストラクチャを気にせずにコードを実行および管理できるクラウドサービスモデルです。GoogleのCloud Functionsは、HTTPおよびイベント駆動の関数を提供するFaaSサービスです。

Cloud Functionsは、Node.js、Python、Go、Java、.NET、Ruby、PHPなど、いくつかの言語をサポートしています。各関数は16GiB（第1世代では8GiB）までのメモリを持つことができ、ディスクアクセスはtmpfsボリュームと共有されます。

AWS: Lambda

AWS Lambdaは、GCPのCloud Functionsに対応するものです。これはAmazon Web Servicesの一部として提供されるイベント駆動型のサーバーレスコンピューティングプラットフォームです。Lambdaは、いくつかの標準言語だけでなく、カスタムランタイムやコンテナイメージもサポートしており、事実上、どの言語でも使用することができます。

各Lambda関数は10,240MBまでのメモリを持つことができ、メモリに加えて10GBの一時ストレージも利用できます。Cloud Functionsとは異なり、LambdaはVPC内で作成することもでき、Elastic File System（EFS）をマウントすることもできます。

LambdaにはLambda@Edgeという機能もあり、CloudFrontと組み合わせてAWSのさまざまなロケーションでコードを実行できます。これにより、各エッジロケーションでリクエストを変更することができ、より低レイテンシーで個別のユーザーエクスペリエンスを提供することができます。