ちょっと話題の記事

hbstudy#58 に行ってきてGCPに震えてきた

たけたけ

2014.07.05

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

Twitterを見ているとなぜかいつもすぐ埋まるhbstudyに空きがでているとのこと。 ということで急遽申込をして行ってきました。

2時間、 Google Computing Platform(GCP)どっぷりでした。 GoogleのKazunori Sato さんがとても面白くわかりやすく説明してくれました。この話を聞いた後に、実はこの方がブログに書いている内容がほぼ講演内容だったということがわかりましたので、こちらより引用しつつ話を進めます。

注意点としては、クラスメソッドに入社してからAWS原理主義者になりつつある私のバイアスがかかっているかもしれません。

ちなみにgmailヘビーユーザーではありますが、GCPにはログインしたこともないので、そりゃ違うだろというところもあるかもしれません。随時訂正しますので御指摘ください。あ、あと$500のスタートアップクーポンをくれる親切な方がいたら是非御連絡ください(7/7追記:親切な方より無事いただきました。ありがとうございました)

Google Computing Platform(GCP)

以下のようなサービスがあるということでした。括弧内は対応するAWSのサービスとなります。

  • App Engine (これに対応するAWSサービスはないとおもいます。あえていうならBeanstalk?)
  • Compute Engine (EC2)
  • Cloud Storage (S3)
  • Cloud SQL (RDS)
  • Cloud Database (Dynamo)
  • Big Query (Redshift)
  • Cloud Endpoints (REST-APIを隠蔽してくれるRPCツールです)

Google Cloudc DNSは別なのでしょうか。ちょっとよくわかりませんでした。

この中でCompute Engine (GCE)とBig Queryの説明がメインでしたので以下、つづきます。

Compute Engine(GCE)

Googleの提供するEC2のような仮想マシンサービスです。以下のサービスが利用できるということで見た目ほぼEC2とそれほど変わらないかなと感じました

  • VMサービス
  • ブロックストレージ
  • Load balancing

AppEngine(GAE)は並列性を上げるためにプログラム側に制約が多いとのことですが、GAEをフロントとして使い、複雑な処理についてはGCEにまかせるという用途で使えるとのことでした。
以下、GCEのお話でポイントとおもったところを列挙します。

ロードバランサ

少し前に話題になった GoogleのHTTPロードバランサーの破壊力があり過ぎるの話です。1 IPでいきなり100万アクセス/秒の負荷をかけても全然平気という超高性能なロードバランサーの話でした。ポイントとしては、GCPとgoogle.co.jpはリソースを共用しているというところのようで、数十Gbpsでも対応可能とのことです。予見できないバーストでも問題ないというのは魅力ですね。ELBの後ろはGAEと組み合わせるという感じなのでしょうか?

Live Migration

この機能もすごかったです。Rackspaceが負荷テストをかけている際にLive migrationが2度走ったがテスト結果とログをみてもわからなかったというのは凄い話でした。Live migrationだとしても、通常、数秒程度の停止は発生するのですが、やはりGoogle半端ないです。震えます。

異なるリージョンで1つのprivate cloudが作成可能

GoogleはAndromedaと呼ばれるSDNの機能も利用しているとのことですが、抽象化ここに極まれるという感じです。ただ、遅延を考えると場所を意識したほうがよい場合も多々あるので、技術的に凄いとは思いますが、こちらが本当の売りになるのかというとちょっとよくわからないです。

GUI操作をするとCUIコマンドを表示してくれる

インスタンスの起動の操作をGUIでおこなって、下のコマンドというところをクリックするとCUIのコマンドを表示してくれました。 細かいところですが、このデモは素敵でした。是非AWSでも作ってほしいです

IAMロール相当の機能はない

ユーザー管理部分がGoogleと統合されています。便利そうでしたが、IAMユーザーやIAMロールのような仕組みはないとのことでした。ログインが簡単にできたりするところはよいのですが、なんとなくですがミスした場合のペナルティが大きな感じを受けました。具体的にはアクセス情報が漏れてしまった場合、AWSですと該当IAMユーザーを無効化/削除することですぐに対応可能ですけど、googleのアカウントを削除って影響大きいですよね。

Linux対応、Windows対応

LinuxはSuseとdebianをサポートしているとのことですが、それ以外でもOSを導入する仕組みがあるということでUbuntuやRHELもイメージリストにありました。 Windowsは現在リリースしていないが、計画にはあるとのことです。

BigQuery

BigQueryです。BigTableではないです。AWSだとRedshiftに対応するということでした。 Redshiftについては、私はセミナーで少し触って見積をつくるくらいなので、あまり自信はないのです(社内に強い人間がいます!)が、話を聞く限り、大量のデータを集計するという機能は似ていますが、まったくの別アーキテクチャでした。

Wikipediaの全データ 430GB 120億レコード をBigQueryに入れた後、正規表現 kaz* ではじまる記事数を出力するというデモを行なっていましたが、わずか13秒で結果がでていました。正規表現というのがポイントで、インデックスが使えないのでフルスキャンになります。データベースをさわっている方なら共感してもらえるとおもいますが、これは震えます。

超並列なデータベース

Googleのサービスを理解するポイントは超並列です。これはBigQueryの紹介の中に出てきた言葉ですが、

<

ul>

  • BigQueryは数十msのアクセス時間がかかるが、スケイラビリティがほぼ無限。
  • 400万アプリケーションを1テーブルで実装している。
  • Scanning 1TB in 1 sec takes 5000 disks (5000のディスクに分けられた1TBのデータを1秒でスキャンする)

    • データを分散して保管し、処理できる仕組み、検索のGoogleの力の源泉ですが、これがいろいろな所で効いていると感じてました。 超並列を実現するためにハードウェアからソフトウェアまで全部やってるんですよね。すごいです。震えます。

    ノードが見えない

    Redshiftですと、ノードのサイズ変更、追加、削除という機能がありますが、Big Queryにはありません。そのようなところは全部隠蔽されているようです。

    fluentd対応

    データのロードにfluentdのプラグインが使えるとのことでした。Webサーバーのログをがつがつ流すみたいな使い方が簡単にできます。

    ラムダ・アーキテクチャのデモ

    fluentd経由でnorikraでリアルタイムにログを処理しつつ、BigQueryに流しこんで、現在のステータスと長期のステータスをGoogle Spread Sheetで表示するという素敵なデモをやっていました。意外な弱点があってGoogle Spread Sheetで使っているスクリプトの処理能力がネックになるため複雑な表現は難しいとのことです。専用のアプリケーションをつくればよいだけの話ではありますが。 コードが公開されているとのことです。

    ラムダ・アーキテクチャという言葉があるそうではじめてしりました。ラムダというはλ計算が思い浮かびますが、特に関係なかったです。

    まとめ

    hbstudy #58 で紹介されたGCPの内容についてまとめてみました。googleの技術力の高さに震えてきました。あ、弊社はAWS専業ですのでこの技術に関するお問い合わせはなしでお願いします。

    技術者がまだそれほど多くないらしいので、プログラミング技術があって、英語のコミュニケーションが得意で、AWSはいまさら参入するのはちょっと、、、という方であればよい選択肢だとおもいます。AWSとGCP、二兎を追うのはとても大変だとも思います。クックパッドのエースエンジニアなら出来るかもしれません。

    個人的には、石を投げればAWS技術者に当たるであろう弊社にいるので、様子見かなーとおもってます。とウソをつくのはよくないですね、本当のことを言うとAWSについていくので精一杯です。

    大事な事が抜けてましたので追記します。この講演をしてくれましたKazunori Sato さん、および主催してくれた HEARTBEATS の方ありがとうございました。お礼を忘れるのはよくないですね。気をつけます。

    ではでは。

    AWS