仕事柄、GoogleのIaaSであるGoogle Compute Engine (GCE)を使ったり、またはガッツリ使っている人の話を聞いたりすることが多いので、これまで感じたり耳にしたりしたGCEの良い所・そうでもない所をまとめておく。
まずは、あんまりイケてない点。
ここがイケてない！
データセンターが東京ではなさそう
Googleは今年4月にアジア地域にGoogle Cloud Platform (GCP)のデータセンターを開設しており、ここが日本からは最寄りのDCということになる。実際、ゾーンとして「asia-east1-a」等を指定して作成したインスタンスを作成し、pingを打ってみると、おおよそ40msくらいの距離にあることが分かる。東京ではなさそうだ。なので、この遅延がユーザー・エクスペリエンスに影響するようなシビアなリアルタイム性の要求される用途には向いていない。
GCEのインスタンス作成画面
一方で、グローバル市場向けサービスで日本からの遅延がそれほど問題とならないケースや、ms単位のリアルタイム性の要求されない一般的なゲーム、Webアプリ等には十分なレスポンス。例えばテレビ朝日による昨年末のMステシンクロライブ事例では、15万ユーザーのスマホWebアプリをGCEによるWebSocket接続でリアルタイム制御し、ゴールデンボンバーやPerfumeの曲進行に合わせてスマホ画面を切り替えたりしていた。テレビイベントによる恐ろしく極端なトラフィックのスパイクにも難なく耐えられる太い帯域が用意されているのはGoogleらしいところ。
日本語の情報が足りない・知名度低い
GCEは昨年12月に正式公開されたばかりの新しいサービスなので、まだまだ日本語の情報が少ない。知名度も低い。Googleもクラウドやってたんだ！ってくらいの勢いで知られていない。開発者コミュニティも大きくなく、他のIaaSのようにネット上に豊富にブログ記事等が転がってるわけではない。正直、まだアーリーアダプター期である。英語のドキュメントやフォーラム等を読みこなして仕事していけるエンジニアでないと使いこなしは難しい。
しかし私のまわりでGCEを触り始めた人たちを見回してみると、おぉなるほど、こういう人たちがアーリーアダプターと呼ばれるのだなぁ。。という印象がある。ポピュラーなIaaSの使いこなしはマスターしたので、ロードバランサーやBigQuery等に代表されるGoogleの尖ったテクノロジーをひとつ試してやろうというギーク魂を持った人が集まっている感じだ。いまGCEのコミュニティに参加すると、そうしたエッジな人たちとお友達になれそう。ちなみに日本語の入門書はまもなく出てくるらしいので期待したい。
ここがイケてる！
つづいてGCEがイケてるところ。かなり細かいけど。。
インスタンス作成が20〜30秒程度
これは速い。ラクだ。インスタンス作成コマンドを叩いてから返ってくるまであっという間だ。なので、スクラップ&ビルドのサイクルを速く回せ、生産性高くインフラを構築できる。インスタンス作成の速さは、GCEを使っている人が誰しも驚いている＋喜んでいる点。
開発者アカウントを自動でuseradd、鍵配布でパスワードいらず
これも地味にしかし確実に便利。GCEではまずGCPの「プロジェクト」を作成し、その下にGCEインスタンスをぽこぽこ作るのだけど、そのプロジェクトに開発者として登録されているGmailアカウント／Google Appsアカウントと同じユーザーアカウントがすべてのGCEインスタンスに標準で自動登録され、sudoersやssh鍵の登録もやってくれる。つまり、20秒でインスタンス作ったら即sshで入ってsudoできる。これに慣れるともう他の環境には戻れない。
Webコンソールで操作した内容がコマンド例で出てくる
GCEのインスタンス管理等を司るコマンドインタフェースはかなり使いやすいのだけど、最初はオプション等をすべて覚えているわけではないので慣れが必要だ。でも、GCEの管理用コンソールでインスタンス作成等の操作を行うと、それがそのまま等価なコマンド行としてコピペできるという地味に便利な機能が付いてて嬉しい。
Web UIで操作した内容がコマンド例で出てくる
なので初回はUI上でドロップダウンを選択してインスタンス作成を行い、それに相当するコマンド行をコピっておけば、後でスクリプトで使ったり等が簡単。ドキュメント首っ引きでオプション指定で悪戦苦闘する必要はない。地味に便利だ。。
インスタンスごとの性能のバラつきがない（7/7追記）
hbstudyでインフラエンジニアの皆さんとお話したところ、GCEの大きな特徴は、インスタンスごとのCPUやネットワーク等の性能のバラつきがとても少ない点、と皆さん強調されていた。確かにGCEではインスタンスをたくさん作った場合でも、性能は一定している。
Live Migrationがなにげにスゴい
これも、Googleの技術がスゴすぎて一体何がスゴいのかよく分からないくらいスゴい一例なのだけど……GCEにもれなく付いてくるLive Migrationという機能。
といっても、使う側は何も意識する必要はない。GCEインスタンスを動かしっぱなしにしておくと、DCのメンテナンスが発生した場合に自動的に他のサーバーにお引っ越ししてくれる。GCEインスタンスの稼働を停めずに、である。つまりGCEでは、こっちが気づかないうちにGoogleがサーバーハードウェアやホストOSをびしばしアップグレードしまくっているのだ...!
確かにこれまでの仮想化ソフトウェアでもこうしたライブマイグレーションは実現されていたけど、切替時には普通1〜2秒の瞬断が発生したりする。いくらGoogle謹製でも、ネットワーク越しにインスタンスの中身を引っ越しするとなるとちょっとは固まったりするだろ、、そんな怪しいこと勝手にやるんじゃねえよ、、ということでRightScaleがGCEのLive Migrationに対するガチな負荷テストを実施している。
From Google Compute Engine Live Migration Passes the Test
図のように、10台のPHPアプリサーバーと2台のLB、そして2台のMySQL間でレプリケーションする本格構成。MySQLのスレーブ以外はすべて同一のゾーンで稼働させて、インターネット越しに20台のクライアントから負荷を4時間かけ続ける。この4時間の間、GoogleはRightScaleのGCEインスタンスに対してテストのLive Migrationを2回実施した。その結果がこう：
We took a look at our log files and all the data in the database and we saw…nothing unusual. In other words, if Google hadn’t told us that our instances had been migrated, we would have never known. All our logs and data looked normal, and we saw no changes in the RightScale Cloud Management dashboard to any of our resources, including the zone, instance sizes, and IP addresses.
つまり、ログやコンソール、IPアドレス等々、どこをどう見てもインスタンスの動作に通常時からの変化は一切見られず、Googleに言われなければハードウェアが入れ替わってることに気づかなかっただろう、とのこと。もちろんほんの一瞬の停止は起きているのだろうけど。。ボーズ・アインシュタイン凝縮体によるVM移動とか実用化してるんですかねGoogleは。
このLive Migrationのおかげで、Googleは我々のGCEを一切止めることなくハードウェアをビシバシ交換でき、つねに最新インフラ上で運用してくれるのだ。ちなみに、GCEの管理ログにはLive Migrationが実施された記録が残る。
SSDが速いらしい
GCE用のSSDのLimited Previewが開始され、どうもこれがものっそく速い様子。これまでFusion-ioを使い倒したのちに現在フルGCEでばりばりのソーシャルゲームを開発してるZeadleの長谷川さんいわく：
From https://www.facebook.com/yusuke.exzm/posts/10203846443303633
どの程度速いのですか。。！長谷川さん、早くブログ書いてください！ｗ
気づいたらリージョンまたぎのプライベートネットワークができていた
GCEインスタンス作るとデフォルトでdefaultって名前のネットワークができていて、同じプロジェクト配下のGCEインスタンスはすべてprivate IPで通信できるのだけど、このときインスタンスのリージョンは自由に指定できる。つまり、気がついたらリージョンまたぎのプライベートネットワークができている。
Metadata serverで構成管理、タグでファイアウォール一括設定
構成管理用に自由に使えるマネージドなKVSとしてMetadata serverという仕組みが用意されており、REST APIでGCEインスタンスの各種メタ情報（ホスト名、IP、コンポーネント構成、イメージ名、起動スクリプトetc）を取得できるほか、任意のkey-valueペアを保存して構成管理に使える。例えばweb、db、redisといったタグを個々のインスタンスにつけておいて、このタグでファイアウォールを一括設定したりできる。Metadata serverはプライベートネットワーク内のDNSとしても使え、インスタンス名はそのままホスト名としてどこでも簡単にプライベートIPを引ける。このMetadata serverへの問い合わせ結果はすべてJSONでも取得できるので、構成管理ツールも作りやすい。
Google最新のSDN、Andromedaで動く
GoogleのDCといえばネットワーク・インフラが独自のSoftware Defined Network (SDN)で構築されているのが有名だが、今年4月にはその最新版であるAndromedaが公開された。GCEのインスタンス間通信やロードバランサーとの通信は、このAndromedaで構築されたSDN上で稼働するので、とっても速い（当社比）らしい... Hadoopの商用ディストリビューションで有名なMapRがMinuteSortベンチマークを取った時はGoogle Compute Engineを使っているのだけど、いちばん売っている先のはずの他社クラウドを使わなかった理由はネットワークの速さにあったりするのかな...?
From Enter the Andromeda zone - Google Cloud Platform’s latest networking stack
AWSユーザーによるGCE通信速度ベンチ（7/13追記）
AWSユーザーであるhirutaさんが実施したGCEのネットワーク速度計測によると、
- GCEは異なるゾーン間で1.6Gbps
- 他社は同一ゾーン内でも310Mbps
とのこと。やっぱ速いなGCE。
Dockerとコンテナ管理ツールを標準装備
GCEインスタンス作成時のイメージとしてContainer VMというDebianイメージを選ぶと、Docker 1.xが最初から組み込み済み。さらには、Googleが開発したDockerコンテナ管理ツールであるContainer Agentが付いていて、コンテナ構成（イメージ名やポート設定、volume設定等）をyamlに書いておくとインスタンス起動時に自動的にdocker runしてかつ死活監視・コンテナ再起動もしてくれる。いまどきだ。
インスタンスをプーリングするReplica Pool気になる
GCEインスタンスをあらかじめ起動してプーリングしておき、そこからさくっと取り出して使えるReplica Poolなる機能がLimited Preview中で、かなり気になる。
ロードバランサー最強
これはここに書いたとおり。
その他
よしづみさんがAWSよりGoogle Compute Engineを選びたくなる10の理由を訳してくれてて、そこにもいろいろ。
"クラウドってより、クラウドのプラットフォーム"
と、ここまで書いたところでZeadleの長谷川さんに「他になにかGCEのよい所ってありますかね？」と聞いてみたところ、長谷川さんはこう答えてくれた。
Platformだってことっすね
やっぱ他社クラウドとかと比較すると
GCEって人とアカウントとシステムがけっこう密接につながってて
シームレスっすよね
ここはすごい楽なんすよね
BigQueryとかもVM作成時の権限だけじゃないですか
ここをちょっと補足すると、GCEではインスタンス時のオプション指定で、GCPの他サービスへのアクセス権限付与が可能だ。この設定をしておくと、例えばGoogle Cloud Storageへのファイル読み書きや、BigQueryのクエリ実行、分散キューサービスやMySQLサービス等へのアクセスのために、いちいちOAuth 2.0の一連のやりとりをゼロから面倒見る必要がない。
GCEインスタンス作成時のアクセス権限設定
このようにアクセス権を設定しておくと、そのインスタンスにサービスアカウントが割り当てられ、Metadata serverからRESTでアクセストークンを取得できる。そのトークンを使ってBigQuery等のクエリを投げたり、またCloud Storage等を操作するコマンドツールも認証不要ですぐに使える。GCEを含むGCP全体がひとつのプラットフォームとして認証が統合化されている。
バックオフィス環境も含めたプラットフォーム
もう一点、長谷川さんが強調するのはGmailやGoogle Appsと連携されているところ。
クラウドっていうよりクラウドのプラットフォームなんすよね
使いはじめると誰も気がつかないと思いますけど
アカウント管理って大企業だと地獄っすｗ
LDAP/AD化されててもですｗ
CloudStorageとかもそうですよね
アカウントと紐付いてたりとか
開発で使ってます
JavaScriptのアニメーション部分とか
社内レビューするために
認証ありなし選択できたりとか
地味っすけどね
大きいっすよ
GoogleApps使ってると尚すんばらしいっすねｗ
いや基本的に
Mail
FileServer
Web
OSの認証
その他いろいろ発生するじゃないですか
GoogleApps使ってると
そのままクラウド側の管理系と繋がるんで
一部に権限委譲したりとか
楽そうですね
前にもGoogleAppsを使ってましたが
やっぱりファイルサーバーとかばらばらなんすよね
AD化したもののGoogleAppsとの連携とかWindows系のエンジニアが嫌がったりとかｗ
簡単なのにｗ
オレ検証したんですけど
やれって言ったらゴネてましたｗ
まあそこら辺がシームレスだなと
メールとかって必須じゃないですか
もちろんWebサービスやるためにはサーバーも必要なんですが
そこ繋がってるからより良いっすよね
すんごい楽っす
勝手にOS側の鍵とかも管理してくれますし
Gmail、Cloud Storage、Docsもろもろ、バックオフィス環境や開発者の認証統合も含めたクラウドプラットフォームをまるっと利用できるのがGCEのメリットだ。
Google Cloud Platformのプロジェクトメンバー権限管理
例えば外部のデザイナーさんに作ってもらった素材をCloud StorageのWebコンソールからアップしてもらい、フロントエンド担当がGoogle SpreadsheetとApps Scriptでワークフローを管理し、バックエンド担当がGCEに入ってStorage上のファイルをデプロイし、ディレクターがAndroid端末から管理画面を見て状況チェックし、チーム全員でGoogleハングアウトで打ち合わせ……といったひと通りのお仕事環境が、各人にひとつのGoogleアカウントできちっとラクに権限管理できる。GCEはGoogleのクラウドプラットフォームである点は、地味だけどじわじわくる良さである。
Google Compute Engine、楽しいかも。
というわけで、後半はGCEの地味に便利なところをまとめてみた。DCの場所等があまり気にならない用途なら、productionでがしがし使える段階になっている。Googleでしか味わえないテクノロジーと利便性を肌で感じることのできる楽しいIaaSと言えよう。#マ
Disclaimer この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり､私の雇用者には関係はありません｡