Google Cloud と AWS の印象の違いについて雑感

この記事は GiXo アドベントカレンダー の 8 日目の記事です。
昨日は、 データ受領で気を付けるポイント でした。

Data-Informed 事業本部 Technology Div. の川田です。私は今年 GiXo に中途入社してきたのですが、入社以降、主に Google Cloud を利用したシステム開発をしています。一方で前職では、主に AWS を利用していました。そこで、 Google Cloud と AWS の印象の違いについて、私なりの簡単な雑感を話したいと思います。

尚お断りですが、本記事は両者クラウド・サービスの優劣を比較するようなものではありません。両者サービスの違いから感じ取れる思想の違いを比較し、本記事を読んでくれた方の「心の中のへぇボタン」を押してもらえるような、そんなつもりで記事を書いています。

分散メッセージングシステムを例にとり比較してみる

それでは、 Google Cloud と AWS がそれぞれ提供する「大量ストリーミングデータを扱う Pub/Sub 型の分散メッセージングシステム（いわゆる Apache Kafka ）」のサービスを例にとり、比較をしてみます。

Google Cloud では、該当のサービスにあたるものとして以下があります。

• (Google) Cloud Pub/Sub

一方 AWS では、以下のものとなります。

• Amazon Managed Streaming for Apache Kafka
• Amazon Kinesis Family
  • Amazon Kinesis Data Stream
  • Amazon Kinesis Data Firehose

「 Amazon Kinesis (Family) 」は、2013年に発表されたサービスであり、現在も多くのシステムで利用され、継続的にアップデートがされています。「 Amazon Managed Streaming for Apache Kafka 」は、その名の通り AWS が提供するマネージドな Apache Kafka 環境であり、2018年の AWS re:Invent で発表された後、こちらも継続的なアップデートがされています。

そうなんです。 AWS では、「 Amazon Kinesis Family 」と「 Managed Kafka 」という2つのサービスがあるのです。また、「 Amazon Kinesis Family 」内でも、その用途によって複数のサービスに分かれています。

Terraform のパラメーター数を比較してみる

続いて、「 (Google) Cloud Pub/Sub 」と AWS 側で近い機能を提供する「 Amazon Kinesis Data Firehose 」とを、 Terraform でのリソース作成時に利用するパラメーター総数で比較してみます。

• (Google) Cloud Pub/Sub
  • 約40個
  • 以下の総数（google provider Ver 4.2.1）
    • google_pubsub_topic
    • google_pubsub_schema
    • google_pubsub_subscription
• Amazon Kinesis Data Firehose
  • 約110個
  • 以下の総数（aws provider Ver 3.68.0）
    • aws_kinesis_firehose_delivery_stream

AWS 側ではパラメーター総数が100個を超えていますが、実際に Kinesis Data Firehose を設定する際に、100個以上のパラメーターを設定しないといけない訳ではありません。100個以上パラメーターを設定するようなことは、 Kinesis Data Firehose のサービス仕様上あり得ないものです。しかしながら、両者の違いが分かりやすいよう、 Terraform の公式ドキュメントに記載されているパラメーター数を全て数えてみました。

両者の比較から思うこと雑感

「AWS は Kinesis があるのに、どうして Managed Kafka のサービスを使ったのだろう 」、「 AWS のサービスのパラメーターは、どうしてここまで多岐にわたるのだろう 」と疑問があがります。その理由は「 利用者がその機能を求めたからだよね 」と、前職時代によく同僚と会話していました。

Google Cloud のサービスは、そのパラメーター数から分かるように、 AWS のサービスと比較するとシンプルな印象を受けます。サービスとして完結している、という印象も近いです。「こんな機能を実現したいのであれば、こんなサービスが分かりやすいよね」「このパラメーターさえ入力してもらえれば、残りはクラウド側でよしなに設定しておくよ。そっちの方がエンジニアは便利だよね」 Google Cloud のサービスを利用していると、Google エンジニアのそんな声が聞こえてくる気がします。

一方で、 AWS はビルディング・ブロックとしての思想が強いです。ビルディング・ブロックとは、1つ1つのサービスをユーザーが組み合わせることで、1つのシステム（クラウド・アーキテクチャー）を作り上げるという思想です。そのビルディング・ブロックの部品として、幾つものサービス・多岐にわたるパラメーターが用意されており、それら部品とはつまり、ユーザーが求めたアップデートであると感じています。 Google Cloud のようなエンジニアの思想も当然感じられるのですが、 AWS のサービスからは「顧客の求める要求を網羅しようとする」という Amazon の顧客第一主義の思想を強く感じます。

Google Cloud / AWS を利用してみて、双方それぞれの良さがあり、どちらか優れているかは結論出せない問題と考えています。一方で両者のクラウドサービスを比較してみると、そのサービスの印象の違いから Google / Amazon という会社そのものの違いを感じられるというのは、面白い話だなと思っています。

おわりに

本記事は、みなさんの「心の中のへぇボタン」を押すことはできたでしょうか。

明日のアドベントカレンダーは、CEO Office 所属 熊谷による「GiXoの成長を支える制度について」の記事になります。

Atsushi Kawata
Data-Informed 事業本部 / Technology Div. 所属