GCPサービスで構築したインフラをAWSと比較してみる

こんにちは、GMOアドマーケティング インフラ開発部のhakumaiです。

前回の記事「AWSエンジニアから見たGCPサービス(コンピューティング編)」を読んでいただいた方々、ありがとうございます。

今回は「GCPサービスで構築されたインフラをAWSサービスで構築したらどうなるか」をテーマにGCPとAWSを比較し、感じた点についてお話しいたします。

テーマの背景

このテーマを思いついた背景としては、前職でのAWSの経験に加え日々GCPサービスでインフラ構築をしていく中で、それぞれの魅力を実際に比較してみたいと思ったからです。
また、ひとつの要件に対してAWSとGCPでそれぞれサービス選定・設計をしてみることで、現状の設計に対する改善点が明確になるかもしれないという期待もありました。
そのため、実用的な粒度での比較ではなくあくまで自己学習レベルからの視点ではありますが、本テーマについて検討してみようと思いました。

比較題材について

比較題材としては、弊社のプロダクトである GMOSSP の広告配信機能の構成の一部を題材にしました。
GMOSSPの広告配信機能ではGCPのマネージドサービスであるCloud Runを使用しており、アクセスログを収集し集計するために一定期間保存する必要がありました。
この広告配信機能のアクセスログの収集・保存処理部分について、GCP移行時に自身が設計と構築を担当した部分でもあったため、今回の題材にしました。

GCP移行時の要件について

広告配信機能のGCP移行時の主な要件については以下になります。

• 膨大なアクセスに耐えうるためのインフラ構成にすること
• スパイクアクセス時にも問題なく対応できるようなインフラ構成にすること
• 収益に直結するアクセスログは損失させない転送・保存フローを検討すること
• 移行後は開発チームにインフラ部分を含め運用をお任せすること

このほかにも、アプリケーション部分はレガシーなPHPアプリケーション構成だったので、コンテナ化の検討という点も含まれていました。

GCP移行後の構成

上記要件を踏まえて、広告配信機能のアクセスログ収集・保存処理部分についての構成は、以下のようにしました。

Cloud Runを選定した理由としては、インフラをあまり意識することなく最低限の学習コストで運用できるというマネージドサービスの恩恵を活用したかったからです。ログの収集方法としては、Cloud Run上のコンテナでアプリケーションログが標準出力になるよう設定しCloud Loggingへログが流れるようにすることで、意図しないコンテナの停止時にもログの欠損が最小限になるように構築しました。
そしてログの保存処理部分としては、Cloud LoggingのLogsinkという機能を使うことで条件に合致したログをCloud Logging上に保存せずそれぞれのGCSバケットに保存されるよう設定しました。

その他主要なコンポーネントの概要構成については、以下に記載がありますのでご参照ください。

AWSを用いた構成に変換

この構成をAWSを使い構築すると、どうなるのかを検討しました。

サービス選定の指標

AWSでのサービス選定の指標として、今回はGCPで構築した場合と比較するため以下3つの指標と、感覚的にはなってしまいますが評価基準を決めて選定を行いました。

• 指標
  • 性能
  • 運用のしやすさ
  • コスト
• 評価基準
  • ◎：(Cloud Runと比較して)AWSのサービスの方が良さそう
  • ◯：(Cloud Runと比較して)あまり変わらない
  • △：(Cloud Runと比較して)あまり良くなさそう

そして、Cloud Runは基準として以下のように評価を設定しています。

• 性能：◯
• 運用のしやすさ：◯
• コスト：◯

サービス選定と比較結果

実際に検討したAWSサービスとその評価は以下になります。
※コストについては、実際に使用しているCloud Runのスペックと同程度のスペックを用いたと想定してコストを試算し比較しています。

	サービス概要/特徴など	性能	運用のしやすさ	コスト
ECS	AWS独自のコンテナオーケストレーションサービス ELBなど他AWSサービスとの親和性が高い	◎ ※EC2の場合 高ネットワーク帯域幅を提供するインスタンスも使用可	◯ Kubernetesよりは学習コストが低い	◎ Cloud Runより約0.6倍の料金
		△ ※Fargateの場合 ENIのアタッチやイメージのPullなどで起動がやや遅い懸念あり	◯ Kubernetesよりは学習コストが低い	◎ Cloud Runより約0.6倍の料金
EKS	Kubernetesがベースの コンテナオーケストレーションサービス	◎ ※EC2の場合 高ネットワーク帯域幅を提供するインスタンスも使用可	△ Kubernetesの学習必要あり	◎ Cloud Runより約0.6倍の料金
		△ ※Fargateの場合 ENIのアタッチやイメージのPullなどで起動がやや遅い懸念あり	△ Kubernetesの学習必要あり	◎ Cloud Runより約0.6倍の料金
AWS App Runner	コンテナ化されたアプリケーションを簡単にデプロイできるフルマネージドサービス ECS Fargateが基盤となっている	△ サポートされるスペックが要件に対して不足	◯ ECS Fargateが基盤となっておりホストOS部分が抽象化される	◎ Cloud Runより約0.6倍の料金
AWS Elastic Beanstalk	アプリケーションコードをアップロードするだけで実行環境の作成や管理などを行ってくれるマネージドサービス Elastic Beanstalk自体は無料で使用できる(生成したリソースに利用料金がかかる)	◎ 高ネットワーク帯域幅を提供するインスタンスも使用可	◎ Elastic Beanstalkの管理画面にて各種設定が一括管理可能	◎ Cloud Runより約0.6倍の料金

上記表より、このテーマについてはElastic Beanstalkを使うことが最適だと分かりました。

Cloud RunからCloud SQLやMemorystoreなどVPCへ接続しているサービスへのアクセスは、サーバレスVPCアクセスコネクタを用いてセキュアにアクセスできるように設定しています。そのため、Cloud RunとVPCへ接続しているサービス間の通信は、サーバレスVPCアクセスコネクタのスループットに準じたアクセス速度になります。それに対し、c6gnインスタンスは最大25〜100 Gbpsという拡張ネットワークをサポートしているため、EC2が基盤となっているElastic Beanstalkでc6gnインスタンスを利用することによって、より高いネットワークスループットにてアクセスできる可能性があることが分かりました。
したがって、サーバスペックについてはElastic Beanstalkで構築したほうが、Cloud Runよりもコスト削減かつ性能の向上が見込めることが分かりました。

Elastic Beanstalkの管理画面では、LBの設定やオートスケール設定などが一括で設定・管理できるようになっています。ログの設定についても管理画面よりS3への保存設定の有効化が可能です。(ローテート条件や対象ログファイルなどをカスタマイズする場合は別途ローテート設定をする必要があります)
ここについては、Cloud Runの場合はCloud Logging側で別途シンクの設定をする必要があったので、Elastic Beanstalkの管理画面上で設定を一括で管理できるということは、あまり慣れていない人でも非常にわかりやすいと思いました。

また、AWSサービスを調べていく中で以下のようなサービスも個人的に知ることができました。

AWS Copilot	AWS ECS Fargateへのデプロイを簡単にするCLI Amazon ECS CLIの後続にあたるもの
Amazon Lightsail	AWSが提供しているVPSサービス WordPressやRedmineなどがインスタンスイメージとしてインストールでき 数ステップで構築可能 オートスケール不可であり、ユースケースには合わず選外

まとめ

以上のことから、今回の題材としてはCloud RunよりもAWS Elastic Beanstalkで構築することで、よりユースケースに沿ったスペックを安く利用できる可能性があるということが分かりました。

AWSではサービスの種類が豊富で、クラウド型のコールセンターであるAWS ConnectやAWSへの移行支援サービスであるAWS Application Migration Serviceなど、幅広いユースケースで活用できるサービスを提供していることが魅力の一つだと思います。

しかしながら、GMOSSPはアドテクノロジーを駆使してより最適な人や場所に広告を配信する必要があり、そのためにはBigQueryなどデータ分析に強みのあるGCPを選択することが現状最適だと思っています。より効率の良い広告配信を行なっていくためにも、Cloud Runでよりコストパフォーマンスが発揮できるような構成を検討していく必要があることも同時に分かりました。
今後もクラウドに囚われずより最適なアーキテクチャを検討できるよう、引き続き両サービスのキャッチアップを実施していこうと思います。