AWSエンジニアから見たGCPサービス(コンピューティング編)

IaaS

Compute Engine

AWSではEC2に相当するサービス。
各種インスタンスタイプや提供OSイメージ、インスタンス向けのストレージ機能、オートスケール機能など、インスタンスのアーキテクチャはほぼ同様。

両者の差分は主に以下。

EC2	Macインスタンスタイプ	macOSのAMIを使って、EC2上でmacOS環境を起動することが可能。iOSアプリの開発などmacOS環境でなければ実施できないことがEC2上で簡単に実現でき、これによりチーム内での開発環境の統一化が容易にできる。
	F1インスタンス	FPGAの回路構成の書き換えに必要なハードウェアアクセラレーションコードの開発、シミュレーション、デバッグ、コンパイルに必要な機能がそろったインスタンス。FPGAとはプログラムで書き換え可能な大規模集積回路(LSI)で、外部メモリに回路構成データ格納され電源を入れるとロードし動作する。他のタイプの集積回路はCPUの回路構成がもともと決まっていて変更できないが、FPGAであれば容易に回路構成を変更することができる。
	Amazon Linux	EC2上で使用するためのAWSによって提供/保守/サポートされるAMI。 AWS CLIなどAWS との統合に必要なツールが事前にインストールされており、AWSの基盤上で最大限のパフォーマンスが出るよう開発された。
GCE	ライブマイグレーション	GCPでは、物理ホストのメンテナンス時は表面上のダウンタイムなく新しいホストに自動で切り替えをしてくれる機能。
	カスタムマシンタイプ	GCEでは、CPU/Memoryの数を自由に選択し起動できるカスタムマシンタイプが提供されている。EC2にはカスタムタイプはないが、幅広い種類のインスタンスタイプが提供されており柔軟性は十分にあると個人的には感じている
	継続利用割引	GCEインスタンスの実行時間が一定の割合を超えた場合、割引が自動的に適用される割引サービス。

PaaS

App Engine

AWSではElastic Beanstalkに相当するサービスで、どちらもアプリのコードのみをアップロードするだけでキャパシティのプロビジョニング含め実行環境が用意され、簡単にアプリのデプロイができるサービスだが、概念には若干違いがある。

Elastic Beanstalkはウェブサーバ環境とワーカー環境があり、アプリケーションの用途に応じた環境を選択し起動することができる。どちらの環境もEC2が基盤となっており、インスタンスに直接SSH接続することが可能。ワーカー環境については、AppEngineのcronジョブ機能に当たる定期実行可能な非同期処理をさせるための環境であり、内部でSQSデーモンが動作し指定したキューへのメッセージをポーリングすることでワーカーを実行させている。

App Engineはスタンダード環境とフレキシブル環境があり、環境のカスタム度合いで選択する必要がある。スタンダード環境はGAEが用意したサンドボックス環境上で起動するが、フレキシブル環境はGCEを基盤としていてインスタンスへのSSH接続が可能だったりDockerコンテナがサポートされていたりなど、自由度が高い環境となっている。

サポートされている言語については、PythoneやGo, Javaなどのプログラミング言語はそれぞれ特定バージョンだが、どちらもほぼ同様の言語をサポートしている。Elastic Beanstalkについては、その他にもアプリケーションサーバであるTomcat・Passenger・Pumaというプラットフォームもサポートされている。また、DockerについてもElastic Beanstalkは対応しており、App Engineはフレキシブル環境のみの対応となっている。

コンテナ

Cloud Run

AWSでは基盤がECS FargateとなっているApp Runnerに相当するサービスで、どちらもサーバレスなコンテナホスティングのフルマネージドサービスである。

Cloud Runはコンテナインスタンスの未使用時にはインスタンス数をゼロへスケールインすることが可能だが、App Runnerではコールドスタートをなくして一貫した低レイテンシーを保証するという設計思想に基づき開発されているため、ゼロまでのスケールインが不可能となっている。

選択できるスペックについては、Cloud RunではCPU最大 8vCPU・メモリ最大32GBまで選択可能だが、App RunnerではCPU最大2vCPU・メモリ最大4GBまでの選択となっており、App Runnerのほうがよりミニマムなアプリケーションのデプロイに最適となっている。

GKE

AWSではECS, EKSに相当するサービスで、どちらもフルマネージドなコンテナのオーケストレーションサービスである。

GKEには標準とAutopilotという2つの運用モードがあり、標準モードではワーカーノードの設計や管理はユーザ自身の管理になるが、Autopilotモードではワーカーノードのプロビジョニング・管理もGKEにお任せすることができる。これに対し、ECS・EKSにもFargateというユーザでのインフラストラクチャの管理が不要なデータプレーンを選択することができる。

ECS・EKSでは、データプレーンとしてEC2も選択することができる。データプレーンのEC2はもちろん、Fargateではスポットインスタンスを併用することができ、費用を削減することもできる。
これに対しGKEでは、データプレーンとしてGCEを使用しており、ノードにプリエンプティブインスタンスの使用もできるため、ECS・EKSと同様に費用を削減することができる。

ちなみに、ECSとEKSのユースケースの違いとしては、ALBやAWS Secrets Managerなど他AWSのマネージドサービスと連携しつつそこで大規模なコンテナの管理を容易にしたい場合には、学習コストが低くKubernetesに存在する機能がAWSの他のサービスで賄うことができるECSが最適である。Kubernetesの思想に則ってコンテナの管理をしたい場合は、EKSが最適だとされている。

FaaS

Cloud Functions

AWSではLambdaに相当するサービスで、サーバレスなイベンド駆動型のコード実行環境を提供するサービスである。

Cloud FunctionsにはHTTPリクエストをトリガーに実行するHTTP関数と、その他GCPサービスからのイベントをトリガーに実行するイベントドリブン関数の2種類がある。
サポートされる言語としては、Cloud Functionsは特定バージョンのNode.js, Python, Go, Java, .NET, Ruby, PHPに対し、Lambdaはその他にもカスタムランタイムやコンテナイメージも対応しているため、どの言語でも実質実行させることができる。

各関数の実行環境については、Cloud Functionsは各関数に最大16GiB(第1世代は8GiB)のメモリを割り当てられることに対し、Lambdaは最大10,240MBのメモリを各関数へ割り当てることができる。またディスクについて、Cloud Functionsはメモリと共用のtmpfsボリュームにアクセスできるのに対し、Lambdaはメモリとは別に最大10GBのエフェメラルストレージ領域を持つことができる。さらに、LambdaはVPC内にも作成することができ、EFSをマウントすることも可能である。


また、LambdaにはCloud Frontと連携し、クライアントからCloud Frontへリクエストがあったとき(ビューワーのリクエストがあったとき、リクエストがオリジンに転送されたときやオリジンから戻ってきたとき、エンドユーザーに返される直前など) に、世界中のAWS ロケーション(リクエストを受け取ったエッジ)でコードを実行することができるLambda@Edgeという関数も作成することができる。Lambda@Edgeを使用することで、リクエストの加工をそれぞれのエッジで実行することができるようになる。

おわりに

簡単ではありますが、今回はコンピューティング系サービスについてAWSとGCPのサービスを比較し紹介しました。

私自身、GCP Cloud Functionsや AWS Elastic Beanstalk・App Runnerは業務経験がなくサービスについての知見はありませんでしたが、この記事の執筆を通してそれぞれのサービスの特徴を知ることができました。

次回以降は、その他のサービス比較についても執筆しようと思います。