現在の会社に入社して初めてGoogle Cloudを触って、かれこれ半年近くが経ったのですが、それまで利用していたAWSと比較して色々気付かされることがあったので一通りまとめてみました。
これからどのクラウドソリューションを利用するかを検討している方や各クラウドの違いが気になっている方の参考になれば幸いです。
前提事項
最初に私の経歴をざっと話すとAWSが3年、Google Cloudが半年です。そのためAWSに知識が偏重している傾向があります。一方で業務としてAWSを最後に触っていたのが2020年3月頃までなので、それ以降にアップデートされた情報については知見がありません。
こうした事情があるため公正さと正確性が不充分であることをご了承ください。
各サービスの違い
EKS vs GKE
GKEにかなり分があると思います。流石にKubernetesの本家だけあって機能が充実しています。
特に便利だと思うのがオペレーション スイートのネイティブ結合とノードの自動アップグレードです。GKEではCloud Monitoringおよび Cloud Loggingという2つの機能がデフォルトでインテグレーションされており、GEKクラスタを作成すると自動的にモニタリング ダッシュボードが作成され、標準出力したログがCloud Loggingというサービスに転送されるようになります。
※Cloud Loggingについては後述します
EKSではノードをEC2とFargateの2つから選択できます。Fargateを選択するとノードの管理からは開放されるのですが、Kubernetesの幾つかの機能に対応していなかったりと、自分が知っている範囲では運用面ではまだまだ使いづらい印象でした。
ちなみに私は以前の職場でオンプレでKubernetesを使っていたのですが、GKEだとこんなに簡単に運用できるのだとかなり感動しました。
RDS vs Cloud SQL
RDBに関してはAWSのほうが良いと思います。MySQLやPostgreSQLなど基本的なRDBは両者揃っているのでおおきな差はないと思いますが、AWSだとAuroraを選択可能なので、幾らか分があると思います。エンタープライズだとAuroraはかなり利用価値があると思います。
一方でRDB以外のDBに目を向けるとBigQueryやSpannerを擁するGoogle Cloudに分があると思います（DynamoDBも良いサービスですが）。
Elastic Load Balancing vs Cloud Load Balancing
反論はあるかもしれませんが、私はElastic Load Balancingを推します。Cloud Load Balancingを使って思った不満が以下の通りです。
- セルフ証明書からマネージド証明書に変更しようとすると接続できない時間帯が発生してしまう
- リソースとしての抽象度が低い
最後の「リソースとしての抽象度が低い」ですが、Cloud Load Balancingは「フロントエンド」、「URLマップ」、「バックエンド」の3つのリソースの集合体として定義されています。コンソール画面から手動で作成する場合には気にならないのですが、terraformのようなIaCで管理しようとするとこの辺りを明確に理解していないとコーディングができず辛いです。
Googleとしては「Load Balancingってそういうものだよね？」という事なのかもしれませんが、Elastic Load Balancingと比べると扱いづらい感じは否めません。
一方でCloud Load Balancingは静的IPを設定でき、この点で優位は確かにあります。ですが個人的には上記の運用上の不便さを補うほどのメリットではないと感じています。
S3 vs Cloud Storage
S3のほうが良いと感じています。大きな違いとしてはオブジェクトに対するIP制御を設定できる点です。S3と違い、Cloud Storageはオブジェクトに付与されたURLへのアクセスをIPで制御することができません。
VPC Service Controlsというサービスを使うことでIP制御することができますが、GCPプロジェクト全体に影響のあるサービスなので場面によっては使うことが難しく、Cloud Storageの機能不足を完全に補っているとは言い難いです。
Cloud Watch Logs vs Cloud Logging
Cloud Loggingのほうが良いと思います。私が利用経験のあるGoogle Cloudのサービスのなかで最良のサービスはGKE、Cloud RunそしてCloud Loggingの3つです。
ログ エクスプローラの画面はUIがスッキリとしていて分かりやすく、フィルタリング機能も直感的でほとんど学習せずに使えるようになっています。
Lambda vs Cloud Function
Lambdaのほうが良いです。サポートされている言語が多いのもそうですが、Lambda レイヤーが顕著な差だと思います。Cloud FunctionにはLambda レイヤーのようなライブラリ層の概念が存在しないので、インフラレベルで個々のサービスの共通部分を管理することが出来ません。
コンソール画面の使いやすさ
圧倒的にAWSだと思います。UIの使い勝手は人それぞれなので置いておくにしても（個人的には断然AWSが使いやすいです）、そもそもレスポンス時間が目に見えて違います。またどちらのコンソールも比較的短期間でアップグレードされるのですが、AWSでは必ず一つ前のバージョンに戻るナビゲーションが付いています。
こうした細やかなユーザへの配慮はUIだけでなく、AWSのサービス全体に渡って息づいているように思います。
サポートの品質
サポートでも大きくAWSがリードしていると思います。というよりGoogle Cloudのサポートは控えめに言っても低品質です。Google Cloudでサポートを利用する場合は、状況をきちんと整理してあらかじめ関連ドキュメントに一通り目を通しておく必要があります。そうでないと数日後にドキュメントのリンクが貼られただけの返答が返ってきます。これはかなり酷い例ですが、決して稀なことではありません。
私はより長い期間AWSを利用していましたが、似たような品質のサポートを目にしたことはありませんでした。
ドキュメントの品質
これはどちらも充実しているので良い勝負だと思います。ただやはりAWSのほうが量は多いと思います。また、Qiita等の非公式のドキュメントも合わせるとシェアの差がドキュメントの量に跳ね返ってくるので、この点でもAWSに分があると思います。
結局どちらが良いのか？
ありきたりの答えで恐縮ですが、どちら素晴らしいサービスで、優れた点があるので利用する方の状況によります。
例えばあなたが最初のクラウドサービスを選ぼうとしているのならAWSをおすすめします。AWSはサービスとして初学者に理解しやすいよう配慮がなされており、サポートやドキュメントの品質でも充分なサポートをしてくれます。
またある程度クラウドの経験がある方でも引き続きAWSを使うのは良い選択です。AWSは主要クラウドのなかでも最も幅広い領域をカバーしていて、恐らくほとんどのユースケースに耐えられます。
ではGoogle Cloudを使うほうが望ましい状況とはどのような時なのでしょうか？
一つはあなたのワークロードをKubernetesで動かしたい場合です。GKEとその周辺のエコシステム（Cloud LoggingやCloud Monitoring等...）は非常に洗練されています。AWSで同じ事をやるのは可能ですが、より多くの事を考慮する必要があるでしょう。
確かなことは、どちらのサービスを選ぼうとも魅力あるクラウドの旅が始まるということです。インフラエンジニアから見て、オンプレにはオンプレの良さがありますが、クラウドにも特有の良さがあります。是非あなたに合ったクラウドサービスを選択して、その魅力に触れてみてください。