2016年9月8日
私たちがAmazon Web ServicesからGoogle Cloud Platformに乗り換えた理由
本記事は、原著者の許諾のもとに翻訳・掲載して おります。
要約:AWSは素晴らしいが、Googleはその グーゴル 倍素晴らしい。
AWS re:Invent (参加料は1,600ドル)に参加したり、チーフ・エバンジェリストの Jeff Barr をフォローしたりすれば、あなたはたちまち、Amazon Web Servicesのとりこになるでしょう。
毎年何百もの新機能が登場しており、食べ放題・融通が利く・運用担当者不要の、オンデマンドサービスのビュッフェのようです。まあ、実際に食べてみるまでは、の話ですが…。
Amazonは素晴らしいです。しかし、Google Cloudは「開発者によって、開発者のために構築された」ものであり、それが一目で分かるのです。
移行した理由
App Engine
GAE はきちんと機能し、オートスケーリング機能も持ち、ロードバランサや無料のmemcacheも備えています。Cloud SQLに接続したいですか? 仮想のLinuxソケット、 /cloudsql を使ってください。カスタムログを書いて、それをすぐに見たいですか? /var/log/app_engine/custom_logs を追加するか、単にconsole.log()とconsole.error()を使ってください。本番環境であなたのアプリケーションをプロファイリングあるいはデバッグしたいですか? StackDriverにブレークポイントを設定する か、マネージドインスタンスに対してSSHで接続しましょう。
内部を見れば、GAEは100パーセントDockerだということが分かるでしょう。 appspot.comのサービスディスカバリを利用して20個のマイクロサービスを実行 するためにGAEを使うか、より大きな規模で巨大なアプリケーションを1つ実行してください。
追記: 初期のGAE、特にビルトインのデータストアはどのような物だったのかについて、恐ろしい話を耳にしました。私はその当時のGAEやGoogle Cloudを使用した経験がないので、コメントすることができません。ブラインド・デートの前のように、いつでも立ち去れるように準備しておきましょう。キャッシュやデータ、メッセージストアのラッパーをコード化しておけば、テクロノジ(あるいはプロバイダ)を切り替えられます。
フレキシブルなVM
Googleでは、あらゆるCPU/メモリ構成で カスタムマシンタイプ を作れます。ワンクリックでより安い プリエンプティブル ( スポット のような)インスタンスを選ぶことができるようになります。入札やオークションのコードは全く必要ありません。
ネットワーキングと帯域幅
Googleは全てのVMをそれぞれ、高速でレイテンシの短いネットワーキングで接続します。Amazonでは、高価な 10Gの容量があるインスタンス の購入か ネットワーキングの拡張 のどちらか(あるいはその両方)が要求されます。
Googleではシンプルなファイアウォールのルールを設定できます。AmazonではVPCやセキュリティグループ、ネットワークアクセスコントロールリストが提供されますが、 ひどい頭痛 も与えられるでしょう。
追記 :「AWS VPCは優れている。AWS VPCのおかげで、利用者はインスタンスをしっかりと守り、サンドボックスを作って内部ネットワークをコントロールすることができる」とコメントする人もいます。しかし、私には混乱の元です。なぜなら、基本的なポート番号やホームIPのルール以外にはほとんど必要なものがありません。しかし、もし殺人ミステリーのように接続の問題を全て調べたいなら、どうぞご自由に。
課金
Googleの課金は1分単位です(1時間単位ではありません)。しかも 長時間利用に対する自動ディスカウント があります。 無意味なリザーブドインスタンス料金 は全くありません(注意:AWS EC2の料金表のページはブラウザ上でクラッシュするかもしれません)。
Pub/Sub
メッセージバスを使いたいですか? AWSの場合は SNS 、 SQS 、 Kinesis 、 Kinesis Streams 、 Kinesis Firehose があって頭が混乱するでしょう。GCPの場合は Pub/Sub のみが使われ、その上、異常なほどスケーラブルです。
追記: SQS(ホストはRabbitMQ?)とKinesis(ホストはKafka?)が別々のメッセージバスを使っていると気づきました。それより、量や速さに左右されない1つのメッセージプロダクトを使って動かすには、GCPを入手する方が良いように思います。
ビッグデータ
Google BigQuery はGB単位のデータ保存量やTB単位のクエリ処理結果に基づいた申し分のない料金体系があり、 テーブルの日ごとへのパーティショニング がビルトインで用意されており、変更がないパーティションには 料金の50%引き下げ があり(それゆえ比較的長期間にわたってデータを保存できます)、その上、SQLがフルサポートされています。
Google Dataflow は、バッチ処理やストリーミング処理において、データを思う存分に使って処理するための驚異的に優れたフレームワークです。ウィンドウ制御、自動で起動するデータ検証制御があり、変換も簡単です。
追記: AWSは新しいサービスとして”Streams”の追加と組み込みを始めましたが、さらに困惑が深まってしまいました。Dataflowは、全てのI/Oターゲットを入出力の双方あるいは片方として扱うので、AWSよりも理解しやすくなっています。
ユーザ&アクセス許可
Amazonで最も理解しがたいものが IAM です。特定のリソースの利用に時間帯やデバイスを限定するというロールをセットアップするのに優れている一方で、セットアップの時間のほとんどがポリシーのデバッグに取られます。
Googleのセキュリティはもっとリラックスしてセットアップできます。信頼のおける各”プロジェクト”の中で全てのリソースが利用できると想定しているのです。
さらに、Googleアカウントを持っている人しかプロジェクトへ招待できません。Googleアカウントがあればデフォルトで安全であり、通常の場合、セットアップが先に完了しています。
追記 :任意のメールアドレスでGoogleアカウントを持つことができるようですが、もし私のようにシングルサインオン(SSO)にGoogle for Work(Google Apps)を使用しているなら、もう既に設定されています。Amazonも多要素認証(MFA)をサポートしていますが、ユーザを新たに作る必要があります。
欠点は?
実はいくつかあります(順不同)
- GCPのドキュメンテーションとコミュニティサポートは、AWSに及びません(ただし、有償サポートは一流です)
- StackDriver(GCPログ)は、BigQueryと同様に、切り離されているように感じられます(わずかに異なるUI上で実行されます)
- サービスの多くはベータ版で、サービスの品質保証がされていません(Cloud Functions、BigQuery、フレキシブルVM、第2世代Cloud SQLさえもそうです)
- Cloud Datastoreは、かなり機能が制限されていて、乗り換えが困難です
- BigTableは、開始価格が高額(最高で月額1,500ドル)です
- ストリーミングモードのBigQueryやDataflowは、本当に高価で予算を見積もるのが難しいです
- GoogleのCDNは、カスタムソースでは動作しません
- 普通の計算においても、帯域幅はいまだに最もコストがかかる要素です(AWSと同じ価格帯)
まとめ
私たちは、YouTube、Gmail、Googleアナリティクスを実行するインフラストラクチャで作業がしたかったので、GCPへ移行しました。Googleが有望で、はるかにテクノロジに精通していて、ちゃんと動作するプロダクトを提供しているからです。
追記: Google(検索エンジン、YouTube、Gmail)でGCPが使用されているかどうかは分かりません。Googleは確かにGCPを作成し、無事に公開しましたが、内部では次の大仕事に取り組んでいます。
AWSがすばらしいということに変わりはありませんが、re:inventの時期に合わせて新しい中途半端な機能を公開する前に問題を解決してくれることを願っています。
「AWSを使用してクビになった人は今までいないと思います。AWSはクラウド分野でIBMのような存在です」と書いた人がいましたが、全くの同感です。しかし、自分の好きなようにして、さらに先を見たいなら、GCPを選んでください。
ただし、効果は人それぞれです。
特定のプロダクト(つまり、Pub/SubとKinesisや、Google CDNとCloudFront)を比較する詳細な記事を書くつもりですので、ブログか Twitter をフォローしてください。
追記は Hacker News での賛否両論に基づいています。
株式会社リクルート プロダクト統括本部 プロダクト開発統括室 グループマネジャー 株式会社ニジボックス デベロップメント室 室長 Node.js 日本ユーザーグループ代表
- Twitter: @yosuke_furukawa
- Github: yosuke-furukawa