Google Platform Developer Roadshow in Osaka に行ってきました

Google 主催で世界各地で行われている Google Cloud Platform のセミナーに参加してきました。
非常に興味深い話をいろいろ聞けましたので、ブログにまとめておこうと思います。
走り書きのメモから書き起こしているので、間違えているところもあるかもしれないですが、ご容赦下さい。

Googleについて

Google の Cloud に対する取り組みについて

まず、最初に Google がどうクラウドと向き合っているかの話がありました。


●世界中に20弱のデータセンターをもっている

●サーバ製品を製造している会社はたくさんあるが、Googleはその中でも3番目の製造量。そのサーバは全て自社のために利用している

●世界中にネットワーク回線を持っている会社はたくさんあるが、Googleは世界で2位のインフラを持っている

●Google が持つサーバは独自設計で、ファンを取っ払ってしまった。サーバルーム全体をサーバと見立てて部屋ごと冷やしている

●Google は大量のサーバをもっているが、それらのサーバを1つのシステムとして見えるようにソフトウェアを設計している


むき出しのサーバたち

Google が持つ Cloud Platform

Google は多くの Cloud Platform を作り上げ、世に送り出しています。


●Google App Engine
PaaS 形式のサービス。デプロイすると、アクセス量に応じて自動的にインフラが拡縮するようになっており、利用者は実際の利用状況に応じてお金を支払うことになる。

●Google Compute Engine
IaaS 形式のサービス。Amazon EC2 のように時間貸しでサーバを利用することができる。

●Google Cloud Storage
ネットワークストレージサービス。月間1GB 2円ほどでデータを保管できる。

●Google Cloud SQL
中身はMySQL。インフラ管理を Google が行うので、利用者はアプリケーションレイヤーのことだけを考えていればいい。

●Google Cloud Datastore
Google 社内での呼び名は Bigtable。KVSのような形式をとっており、非常にスケーラブル。Google が提供している gmail など全てのサービスでも利用している。

●Google Big Query
Google 社内での呼び方は Dremel。カラム型データベースで非常に高速に動作する。例えば600億行のデータから任意の文字列を含むレコードをフルスキャンで抽出するのに10秒程で処理する。

●Google Cloud Endpoints
モバイルデバイスでサーバと連携することにフォーカスをあてて開発している。
サーバサイドの処理を抽象化して REST 形式で要したサーバAPIをメソッドコールのような形で呼び出せるようにしている。

実例で示す Google Cloud Platform の実力

Google App Engine では現在475万のアプリケーションが動作している。
日々280億件のリクエストが発生しており、それを捌いている。これは Wikipedia のアクセス数の10倍に相当する。

Google App Engine を利用する最大サービスは SnapChat。

Google Cloud Datastore には 6.3超件のデータが登録されている。

セッション1. 価格とトレードオフ

現在のクラウドサービスは料金体系が複雑になりすぎてしまっている。
パブリッククラウドの価格下落率は 6-8%/年 となっており、ハードウェアの価格下落率の 20-30% と比べて開きがある。



Google はもっとユーザに還元するべく4月1日に大幅な値下げを行った。

Google の Cloud Platform では以下のポリシーを持って設計を行なっている。


●NO初期費用

●NO期間拘束

●NO複雑な価格体系

そもそもクラウドのあるべき姿は？

●低コスト

●事前の準備不要

●予約不要

●すぐに捨てられる


と Google は捉えており 、他社が行っているような サーバを一定期間借りることを約束すると割引を行う形はクラウドサービスのあるべき姿ではない気がする。
Google Compute Engine ではサーバの利用期間が長くなれば自動的に利用料金が割り引かれる方式を採用しており、最大30%の割引が適用される。

Google はムーアの法則に従って利用料金を下げていく努力を今後も続けていく。

開発におけるトレードオフ

●市場投入スピードor拡張性

●柔軟性or自動管理

●ビッグデータorリアルタイム


Google は Cloud の力でこれらのトレードオフを解消したい。

この後説明する Managed VM では Google Compute Engine の柔軟性と、Google App Engine の拡張性をいいところ取りした仕組みで、市場投入スピードを高めて、拡張性も持たせようとしている。

github に push すると、Google Compute Engine に自動的にデプロイされる。といった仕組みを用意して、柔軟かつ自動的なデプロイを実現しようとしている。

Google Big Query ではほぼリアルタイムな集計をシャーディングなどの工夫なく、容易に実現できるようにしている。

近々行われる GoogleIOではもっと色々な発表があるので楽しみにしていてください。

セッション2. IaaS / PaaS の境界を無くすプラットフォーム。Managed VM

Google App Engine

迅速な開発・手間いらずの維持管理・容易なスケールを実現しています。
Google App Engine を使えば、事前にサーバの必要台数を予測する必要はありません。急激なスパイクにも自動的にスケールして対応します。
スパイクに備えて余剰なサーバリソースを持つ必要はなく、支払いは利用した分だけです。

Google App Engine を利用した実例として、AKB総選挙があります。
AKB総選挙はご存知の通り、非常に時間集中の高いサービスで、23000リクエスト/秒 発生しましたが、問題なくサービスを提供しました。

Google Compute Engine

●他社との違いは Google のエンジニアが面倒を見ていること︵ドヤ

●ディスクIOが安定しており、物理HDと比較して 120MB/s で変わらない。最適化によってランダムリードが物理HDと比べて8倍やランダムライトでは32倍近いパフォーマンスがでる

●インスタンスの起動時間も非常に高速で、20〜40秒で起動が完了する︵Amazonは2〜3分かかる︶

●クラスタ内のサーバの台数が増えていっても、インスタンスの起動時間が変わらない

●一貫した性能を提供しており、同一インスタンスタイプであれば一定の性能が提供されることを約束している。他社ではたくさんインスタンスを立てて、性能のいいインスタンスを使うようなことをしているようだが、Google Compute Engine では不要

●データセンター間のバックボーンは全て Google 自前の専用回線。非常に高速。

●ハードウェアのメンテナンスに左右されない。ライブマイグレーションが実施されることでリタイアメントが発生しない。

次世代のクラウド技術

柔軟性 IaaS > PaaS。
IaaS はインフラ基盤が薄くアプリケーション・ミドルウェアの層が厚い。
それによって高い自由度を得ている。

迅速性 PaaS > IaaS。
PaaS はインフラ基盤が厚く、アプリケーションの層が薄い。
それによって開発の迅速性を得ている。


しかし、現状をみると PaaS を積極的に使おうという動きはないかもしれない。
これには PaaS では使いたいミドルウェアが使えないかもしれない。という問題が関わっているように思う。

Managed VM

Google App Engine をベースに開発しており、App Engine では実現できない部分を Compute Engine で実行するハイブリット形式をとっている。

イメージのアップデートやセキュリティパッチの適用は Google App Engine 同様自動的に行われる。

Google App Engine 同様 Datastore などにはアクセス可能。

レプリカプール

Google Compute Engine のデプロイを改善する。
同じ種類の仮想マシン。例えば nginx 50台を設定するような時に効果を発揮する。

セットアップ手順をテンプレート化しておくことで、レプリカプールが自動的に設定を行う。
ヘルスチェック機能があり、落ちてしまった仮想マシンを殺して新しく立て直すようなこともできる。

セッション3. Android Studio + Google Cloud Endpoints

Android Studio とは Android 向けの IDE。InteliJ をベースに開発されている。

Google Cloud Endpoints は Google App Engine をベースにクライアントプログラムの自動生成機能などを追加している
サーバ側の処理は REST 形式の WEB API として実装される。


Mobile Device → Cloud Endpoints Client(自動生成) → Cloud Endpoints → GAE


という流れで処理される。

SnapChat がこの機能を利用しており、1日4億回のAPIコールを行っている。


LIVEコーディングでTODOリストを作成

出来上がったデモのアーキテクチャ

今後 IDE はさらに開発しやすいよう改善されていく予定。

セッション4. Google Big Query の最新動向

Google では日々大量のビックデータが生まれている。
時にはイベントで Google Play の販売本数の TOP20 をその場で瞬時に計算して発表することもある。このような時はビックデータの集計を即時に行う必要がある。

集計処理といえば、Hadoop / MapReduce がある。これは RDBMS ではなく、10台20台といったサーバでクラスタを組んで分散処理で集計を行う。

Hadoop はプログラムを書かなければいけない。
時にはユーザデータをJOINしなければ集計できないことも。
実行には数時間かかることがザラにあり、夜に仕掛けて翌朝まで放置する。なんてことも。
そこまでして実際出てきたデータが間違えていてガッカリすることも。

Big Query は SQL ライク

Big Query はSQLライクな命令でデータを検索でき、驚くべきことにインデックスを張る必要がない。
もともと Dremel として社内で使っていた仕組み。

なぜ Big Query が早いか？

Big Query はカラム型データベースを採用している。
カラム型データベース自体は古くからある技術で、データを行単位で保存するのではなく、カラム単位で保存し、カラムごとに保管先を分散する。

カラム単位で保存することで、検索時に分散処理ができるだけなく、データの傾向が似るため圧縮率が高まる効果もある。

Google では数千の Dremel ノードが動いている。
1TB のデータをフルスキャンするのを1秒以内に終わらせようと思うと、5000台のサーバで分散処理する必要があることがわかった。そして Google はそれを実現した。

SQLライクのクエリをツリー型に分解して分散処理することになるが、ここでは検索技術で得たノウハウが生きている。

Google Big Query の利用料金は先日の価格改定で 85% 値下げが行われた。より料金を気にせず利用できるようになった。

User Define Function

近い更新で javascript で記述した関数を Big Query 用のクエリから呼び出せるようになる。
これによって、より複雑な処理を行えるようになり、これが実現されたら Hadoop は必要なくなるかも。
とはいえ、Hadoopを使いたい需要があるかもしれないので、Big Query のデータを HDFS に入れずに直接 Hadoop から利用できるようにする試みも行っている。

Google Big Queryが使われなかった理由

データを流し込むのがめんどくさかった。
しかし、ストリーミングでデータを流し込めるようになった。(10万件/秒)
流し込み先のテーブルをシャードすれば 100万、200万でも対応できる。

fluentd にプラグインができて手軽にデータを流し込めるようになった。

 

Norikraとの連携

オンメモリのデータ解析システムの Norkra と BigQuery が一体になればすごいことができるはず！

70台のWEBサーバのログを BigQuery と Norikra に流し込む。
Google Docs のスプレッドシートにクエリを書いておくと一定間隔でそのクエリを実行して スプレッドシートに集計情報を書き出すようにする。

セッション5. コンテナ技術

最近 Docker の登場でコンテナ界隈が盛んだが、Google では 2006年からコンテナ技術を使っていた。
実際、Googleのデータセンターでは毎週2億台のコンテナがサーバにデプロイされている。

Google App Engine のアプリケーションの起動の早さにはコンテナ技術が生きている。

手続型スクリプトを書くように書くのでなく、宣言的に こうこうこういうコンテナが欲しい。と記述するとコンテナが起動するようにしたい。
docker run のコマンドラインオプションは絶望的。

Reference Node Container Manager を github で公開中。

コンテナを管理するスクリプトを yaml で記述できる。Dockerイメージの種類や、利用するポートマッピングなど。
その情報を元に Reference Node Container Manager がコンテナを起動。
コンテナの死活監視をおこなって、落ちていたら自動的に再起動することも。

まだまだ面白い機能を実装中。

 

--

 

まとめはここまで。
全体的に非常に面白い話だったと思います。

特に Big Query が非常に強力で、600億件のデータをフルスキャンして10秒程度で検索を実行してしまうパワーには驚きです。
そして、そんなすごいインフラを一般にまで公開してくれているのは素晴らしいと思います。

他にも、Compute Engine のライブマイグレーションにも驚きです。
以前ブログで記事にしたことがありますが、AWS にはリタイアメントという仕組みがあり
古くなったハードウェアや、故障したハードウェアの上に仮想マシンが載っていると、Amazonから強制的にサーバを停止するという死刑宣告を受けます。
死刑宣告を受けたサーバは10日程度ある猶予の間にサーバをリプレースしなければなりません。

Google Compute Engine ではここを自動的に新しいハードウェアにダウンタイムなく移行することで、利用者に負担をかけることがないそうです。
さらに驚くことに、動画をストリーミング配信しているホストをライブマイグレーションしてもストリームが途切れることがないくらい Google Compute Engine のライブマイグレーションは強力なようです。

GAEも思想はすごく良くて、勝手にスケールするので、アクセスを見積もらなくてもいいし、突然のスパイクにも勝手に対応する。など運用の手間をほとんどかけないようになっています。
Big Query にしても Google は Amazon とは異なり、真のクラウドサービスを実現しようと頑張っているのだなあ。と思いました。

私は GCP 自体 GAE 以外を触ったことがなかったのですが、500ドルのお試しチケットをいただいたので時間を見つけてもうすこし色々触ってみようかな。と思いました。