5
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

セゾン情報システムズAdvent Calendar 2023

Day 22

AWSとGoogle Cloudの利用経験あるサービスを雑多に比較してみる

Last updated at Posted at 2023-12-21

この記事は セゾン情報システムズ Advent Calendar 2023 22日目シーズン2の記事です。

背景

Google Cloudメインのクラウド環境から再びAWSメインの環境に戻ってきました。Google Cloudで様々なサービスを扱う経験をさせてもらいまして、せっかくなので忘れない内に各サービスの感想をAWSと比べながら語りたいと思います。流石に全てを比較しようとすると収拾がつかなくなりそうですので、印象的なコンテナサービスを中心に数を絞って記載します。

前提

・Google Cloudは2023年7月頃までの利用時の情報を元に記載します。AWSも少々扱う機会があったもののブランクがありました。それ故正解性に不十分な面があることをご承知おき下さい。

・機能の比較を綺麗に羅列されてる記事は多数ありますので、この記事では主観的に書くことを目的にしています。私の利用状況で偏りが出てしまう部分もあるかと思いますがご了承下さい。

・添付する画像は各クラウドの個人アカウントでテスト用に作成したリソースから表示しています。シンプルな参考画像と思っていただければ幸いです。

この記事で書くこと

  • 各サービスの主観的な感想
  • 簡単な利用イメージ・印象の記載

この記事で書かないこと

  • 各サービスの詳細な使い方・仕様・性能検証等

コンソール

慣れの問題もあるのですが、個人的にはGoogleCloudの方が使いやすく感じます。(両方使ったことがある人に聞いてみると大体AWSの方が良いと仰っているので、、私が特殊側だと認識してますが..)

コンソールトップページからサービス項目->詳細のページにダイレクトに飛べる点などが好みです。勿論AWSでも各サービス項目を押下して詳細ページへ飛べるので、本当に単なる個人の感覚です。

他にはGoogle CloudのOrganizationの方がプロジェクトを一覧で確認がしやすい (フォルダから全体を選んでIDごとに選択・検索できる)、コンソールで作成時にサービス利用時の見積もり概算を表示してくれる等、AWS側にはない機能が結構好きだったりします。

公式ドキュメント・情報量

AWSは情報量が多く、公式ドキュメント以外にも例えば有名なClass Methodさんの解説記事(developersIO)も充実してますし、企業の技術ブログ等も多数あります。さらに困ったら充実したサポートの回答も得られます。

一方、GoogleCloudも公式ドキュメントはあるものの、比べるとニッチになってしまう分情報量が少ない印象です。

個人的にはAWSの日本語ドキュメントがどうしても理解し難く、気合を入れて読んでみても中々頭に入ってこない事がありがちです。そんな時は一次情報の原文ドキュメントや他の周辺情報と合わせて確認するようにしています。

日本語の公式ドキュメントに限っていえば、GoogleCloudの方がやや理解しやすいように感じています。(GoogleCloudのドキュメントもたまに理解が難しい場合はありますが・・)

EKS:GKE

やはり本家だけあって、GKEが総合的に便利な機能が揃っています。GKEならではの限定機能もあり、使いやすい印象です。

コンソール

業務では、近年はIaC(Terraform, CloudFormation等)を使ってリソース構築する事が一般的ですが、あえてコンソールから作成してみようとすると、GKEではざっくりとしたコスト概算まで確認できます。

スクリーンショット 2023-12-20 18.34.24.png

作成時もそうですが、設定等の編集画面からもノード数の変更、ノード内のPodのステータス、リソース状況、ログやmanifestが簡単に確認可能。さらにmanifest fileをコンソール上から修正して更新する事もできます。Kubernetsにそこまで慣れてない開発者にも扱いやすいと感じます。

スクリーンショット 2023-12-20 18.42.15.png

スクリーンショット 2023-12-20 18.43.03.png

EKSでは、コンソールからGoogleCloudほどには各種情報の確認・リソースの編集更新等が満足にできません。EKSの管理自体はIaC利用前提となっているのではないかと感じます。

スクリーンショット 2023-12-20 18.57.16.png

モニタリング・メトリクス

EKS・GKE共に標準機能での感想です。
Cloud WatchによるEKSのアプリケーション監視経験がない為、正確に比較できませんが、GoogleCloudのCloud Logging・Cloud Monitoringが標準で使いやすかったです。

モニタリングダッシュボードが自動で作成され、ログエクスプローラからもリクエストやログの出力が視認できます。

スクリーンショット 2023-12-20 18.15.51.png

一方、AWSではContainer Insightsが備わっており、こちらもAWS内の監視機能で良い感じに利用できるのではないかと存じます。(利用経験がない為これ以上の言及ができず)

スクリーンショット 2023-12-20 18.46.54.png

自動アップグレード機能 (GKEのみ)

GKEではサージアップグレード方式と、BleuGreenアップグレード機能の2種類が備わっています。(勿論手動対応もできます)

この機能はEKSにはありません。バージョンのライフサイクルが比較的短いKubernetesにおいて、中々重たいアップグレード対応を基本的にダウンタイムなしで素早く実行できるので非常に便利です。実経験としては、DockerイメージからContainerdへの移行対応をBleuGreenアップグレード機能を用いて行いましたが、無事ダウンタイムなく完了しました。

各アップグレード機能についてはリンクの記事が分かりやすくまとまっています。

App Runner(利用経験なし):Cloud Run

※App Runnerは利用経験ないですが、注目しているサービスなので取り上げました
※自分で調べた限りでの情報を元にした記載となっています

サーバレスなコンテナホスティングのマネージドサービスとしては、AppRunnerとCloud Runがありますが、こちらはCloud Runがリードしている印象です。

Cloud Runは以下の点が非常に有用で、個人開発やBot等の利用から商用のWebアプリケーション本番環境まで対応可能です。

  • コンテナ型アプリケーションをマネージド管理できる
  • リクエストを受けて起動して負荷増加時はスケールインする
  • かつリクエストが来ない時はインスタンスをゼロにできてコストを削減可能
  • サイドカー機能が追加されてSaas型監視ツール(Datadog, NewRelic等)との連携が容易になった
  • サーバレスロードバランサー(NEG)と組み合わせて運用が可能
  • 学習コストが低めでインフラにあまり知見がない開発者でも直感的にデプロイ・操作・確認ができる

ただし、しばらくリクエストがなくなりゼロスケールとなった際にコールドスタートしてしまう事象が見受けられますので、Startup CPU boostなどが必要なケースもあります。

App Runnerについてはどこかで個人的に触ってみたいとは考えてますが、リンクの資料情報やSNS等の声を参考にすると、CloudRunに比べてまだまだ不十分な印象です。

Cloud Runレベルまでくれば、常時立ち上げは不要だがECSやFargateで扱ってたサービスからの切り替え、APIGateway+Lambdaを使っているケースの代替など、ハマるパターンが多数出てくるのではないかと。

私個人としてはAWSで一番進化して欲しいサービスの内の1つです。

その他

長くなりましたので、さっと紹介します

ロードバランサー

Google Cloudの方が良い点:暖機運転の申請不要

GKEの負荷試験をする際、LBのリクエスト急増に備えて必要かどうか確認しましたが不要でした。AWSでは最近の公式情報としては公開されていませんが、過去に必要であったとの記事があります。相応のトラフィックが予想される際は念の為申請等の確認をした方が良さそうにみえます。

Google Cloudの不便な点:セルフマネージド証明書→マネージド証明書への切り替え

Google Cloudでは従来セルフマネージド証明書を当てていたLBをマネージド証明書に置き換えようとする際、ダウンタイムが発生するケースがありました。入れ替えの為複数枚の証明書を当てる際に前段・後段の配置順番も重要で、間違えるとサービス断になる恐れがあり、シンプルな対応ながら緊張した記憶があります。

資料:
https://dev.classmethod.jp/articles/tsnote-if-pre-warming-is-set-or-not/

IAM関連

どちらかというほどの差はないですが、権限関連はAWS、組織構成は階層構造(ツリー)のGoogle Cloudの方が好みです。

個人的には、サービスアカウントやGoogle Cloud IAMの概念理解がいまいち腑におちず苦労した記憶があります。

AWS:"どのリソースに対して" "何ができるか" という権限セットを 人に紐づける
GoogleCloud:"誰が" "何をできるか" を "リソースに紐づける"

参考記事:
https://blog.g-gen.co.jp/entry/iam-explained#%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%82%A2%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88

サービス終了

Google関連でネガティブな話題といったらサービス終了がよく取り上げられる印象です..直近ではGoogle Cloud IoT Coreが2023年8月16日に終了しています。AWSではChef OpsWorks Automateが2024年5月5日でサポート終了するようです。

まとめ

AWSもGoogleCloudも素晴らしいサービスだと思いますし、大抵の事はどのクラウドサービスを選定しても実現できると感じます。

大切なのは各機能を上手く使う事で如何にアプリケーションサービスの課題・問題解決に繋げるかです。その中で、より安全・安定的に、より安価に、より早く開発してサービス提供できる事が永遠のテーマですので、本質を忘れずに今後もクラウドサービスと向き合いたいと思います。

その他参考資料

調べている中で色々と面白い資料が見つかったのでメモがわりに記載します

AKS vs EKS vs GKE
https://dev.to/thenjdevopsguy/aks-vs-eks-vs-gke-2459

AWS vs. Azure vs. Google Cloud Platform in 2024
https://cast.ai/blog/cloud-pricing-comparison-aws-vs-azure-vs-google-cloud-platform/

Google公式が出した各クラウドの比較資料
(私が確認した限りでは他のクラウド各社はこのような一覧資料を出していませんでした)
https://cloud.google.com/docs/get-started/aws-azure-gcp-service-comparison?hl=ja

Cloud Runユースケース等:
https://ascii.jp/elem/000/004/145/4145786/#:~:text=Cloud%20Run%E3%81%AB%E6%84%9F%E3%81%98%E3%82%8B%E3%83%A1%E3%83%AA%E3%83%83%E3%83%88,%E4%BD%8E%E3%81%84%E3%81%93%E3%81%A8%E3%81%AA%E3%81%A9%E3%82%92%E6%8C%99%E3%81%92%E3%82%8B%E3%80%82

Cloud Runコールドスタートの検証
https://zenn.dev/cloud_ace/articles/bd95501cb0cd3f

AppRunner AWS資料
https://speakerdeck.com/track3jyo/key-points-of-using-apprunner
https://go-to-k.hatenablog.com/entry/2022/02/13/035248

知人のAppRunnerに関する調査記事
https://zenn.dev/yuta28/articles/app-runner-proxy

5
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?