このエントリーは Google Cloud Platform Advent Calendar 2015 の 16 日目の記事となります。

← 15 日目の記事 GCE の preemptible VM で、インフラの CI を回し始めました
→ 17 日目の記事 JSONなアレに疲れたアナタに贈るGoogle Cloud Deployment Managerのススメ

幸いにも会社のスキル開発プログラムを利用して、今年後半以降に次のトレーニングを受講できました。

  • Google Compute Engine
  • Google BigQuery
  • Google App Engine
  • Google Cloud Storage
  • Google Cloud SQL

以下、GCP ﾁｮｯﾄﾃﾞｷﾙ 的なオンプレ エンジニアが GCP のトレーニングを受講した体験記となります。

エンタープライズ (ビジネスの主役が IT ではない業種) 向け用途を想定しながら書いていますので、クラウド上のシステムでビジネスをされている方からすると、後進的/違和感があるかもしれませんがご諒承下さいませ。

受講者スペック

普段は VMware のハイパーバイザーのストレージ I/O 周り (vSphere APIs for IO Filtering) やコンテナ クラスタをデプロイする製品 (VMware Photon Controller) 周辺のお仕事をしています。

  • GCP 歴: 2014~。 VPS 的に GCE を利用
  • AWS/Azure 歴: 無料枠でお試し程度
  • Java 歴: 1997~2003, 2015~。(Lost decade がとてつもなくツラい)
  • C# 歴: 2006~2008。

いわゆるオンプレの住人になりまが、仕事で関わっている Photon Controller が Kubernetes/Mesos/Swarm のコンテナ クラスタをデプロイする製品ということもあり、多少は今風な領域にも手を出しています。

トレーニング感想

全コースとも、株式会社トップゲートさん提供のトレーニング を受講しました。トレーナーは GAE マイスターの @sinmetal さん。GCP での実案件を数多く経験されているので、実際の事例も交えた講義や質疑応答は GCP を全体的に理解したいと思っていた私にとっては非常に有用でした。

トレーニング内容は アジェンダ で把握できます。トレーニング内容を無理なく理解していくには ある程度インフラの知識なり業務をこなしていないと厳しいかと思います。GCP ではない状態のインフラ、つまりは AWS/Azure/オンプレ との比較をすることによって、より理解が深まります。各コースの製品について、Getting Started を事前にやってみたり、その Getting Started の内容を AWS や Azure やオンプレでどう実現できるだろうか？無理だろうか？と妄想しておくとより理解しやすいと思います。

トレーニング資料は、かなりボリュームがあり Documetation を熟読する前の資料として非常に読みやすく出来ています。もちろん GCP 自体機能の追加が頻繁に行われるので、トレーニング資料が多少古くなるところがありますが、そこはトレーナーから適宜指摘して頂けるので安心です (と書いている側から Cloud SQL が Next-geneneration に !!)。トレーニング資料は Google Drive で共有されるので、トレーニング後でも、いつでもどこでも閲覧することができます。App Engine はボリュームが多く、さらに半分弱が Datastore の内容となっており、オンプレ/RDB 脳の私には慣れるまで時間が掛かりました。AppEngine 脳になれねば ! 米国のトレーニングでは App Engine は 1 日なのだそうですが、日本では 2 日のコースとなっており、受講者にある程度余裕がある時間配分にしているそうです。

なお Cloud SQL は、内容が少ないため 2-3 時間のみ…。がんばれ Cloud SQL !!

会場

本郷三丁目にある Studio Geek の一角の講義室で行われます (10-15 人程度の部屋)。各席の近くに電源があるので、電源タップなどは必要ありません。席によっては朝の日差しでスライドが見えにくいこともあるので、スライドは手元を見ながら受講するのも良いかも知れません。

Studio Geek 内の自販機にはドクターペッパーがあり大変お世話になりました。Studio Geek のあるビルの向かいにファミリーマートがあるので、休憩時間にそちらへ買いに行くのもありでしょう。

認定試験

他の認定試験と異なり、試験会場に赴き隔離部屋で試験ではなく、自宅の PC で試験となります。

他社の試験よりはひっかけも少なく、素直な問題が多いと思います。何よりも時間に余裕があります。試験中はテキストやマニュアルを参照するだけでなく、Google 検索することも出来ます。ですので、講義を集中して受講し、テキストを日本語やマインドマップに写経するなどして復習すれば、それなりの確率で合格できるのではないかと思います。

受講後速やかに受験することをお勧めします…

トレーニングのメリット

ありきたりかも知れませんが、他の有料トレーニングとだいたい同じかと思います。

  • 抑えるべき入門レベル付近の知識を短期間に網羅して学習できる
  • 最低限 Qualified されていることを証明できる
  • Resume/履歴書の肥やし
  • トップゲートさんの 認定者一覧 にリストアップ 🙂

今まで受けてきた他の有料トレーニングと違うのは、教育専門の講師ではなく今現在も実案件をこなしている方が講師であることです。トレーニング中に生々しい話ができるのが トップゲートさんで受講するメリットかと思います。

GCP Office Hour で @sinmetal さんに相談するというのもありやも…

Google Cloud Platform のここがスゴイ (そうに見える)

以下、トレーニングを受講したそれほど GCP を使い込んでいないオンプレ エンジニアが思う GCP のスゴイところを挙げてみます。

  • スピンアップタイム 40 ms の Google App Engine/Go
  • Google Compute Engine のストレージ機能
  • Google Cloud Platform の Network
  • (Google BigQuery)

使い込んでいないが故にべた褒めになっているところはご容赦を。

スピンアップタイム 40 ms の Google App Engine/Go

オンプレでもクラウドでもオートスケールはよくネタになり、数多くの困難が待ち受けています。少し考えるだけでも

  • インスタンスを作成/クローンするトリガーは？
  • アプリの起動完了をどうやって検知してロードバランサーに追加する？
  • インスタンス作成やアプリの起動が遅く、完了したときにはピークが過ぎている？
  • ロードバランサーの Warm-up が必要？
  • インスタンスを削除するタイミングは？

などなど出てきます。特にインスタンスの準備時間とピークの察知からピークの頂点に達するまでの時間の帳尻を合わせることに非常に苦労します。

そんな苦労も スピンアップタイム 40ms の GAE/Go を知ってしまうと、「ねぇ、どんな気持ち？」 的な気分になってしまいます。コンテナを起動する前に、ある程度の数のコンテナホストにユーザーの Go のバイナリを先読ませているのかしら… ? 相変わらずの謎テクですね。

GAE/Go に限らず Google の技術は、そこから得られた結果を喜び、裏側の実装を肴に酒を呑むくらいがちょうど良いんでは…。変に実装を穿ちすぎてもねぇ…。
　
「Spin up time 40 ms」はトレーニングで聞いた覚えや、そのほかイベントでも Google の方と会話したので覚えているのですが、公式ドキュメントで見つけられず。

Google Compute Engine のストレージ機能

Twitter 界隈でも、GCE は起動が速い、ガチャがない、と評されています。Borg でリソース管理された KVM の仮想マシン インスタンスのお陰なのだそう。

実際にお試ししても、インスタンスの作成+インスタンスの起動 の時間を比較すると AWS と Azure よりも早く快適に操作できます。

インスタンス作成の最速は、vSphere+NFS VAAI-NAS によるクローンだと思います (数百 GB 程度ならば 5 秒以下で瞬殺。追記型 (Copy On Write) のストレージに限る)。もちろんデータの配置や可用性など諸々異なるので比較すること自体適切ではありませんが、オンプレでも結構頑張ってると言うことで。

この起動の安定したストレージを数多ある GCE インスタンスに提供するストレージも十分すぎるほどなのですが、最もスゴイと思うのはローカル SSD だと思います。IOPS 性能の高さは当然として、何よりもスゴイのはライブ マイグレーションに対応していることです。

ローカル SSD のデータはライブ マイグレーション時に、メモリ上のデータと一緒に別の物理ホストに移動させなければなりません。そして、ローカル SSD 上のデータを移動している最中にもローカル SSD 上のデータは相当な勢いで変更されていきます。つまり、ライブ マイグレーション先の物理ホストに送らなければならないデータが増えてしまいます。ローカル SSD のデータをネットワーク送信する速度を超えるローカル SSD への I/O が発生してしまい、永遠にライブマイグレーションが終わらないということが考えられます。ローカル SSD というネットワークの転送速度を上回ってしまいかねないストレージ デバイスがあるにも関わらず、ライブマイグレーション対応とした Google Cloud Platform の底力が垣間見えます。

VMware vSphere ではローカルストレージを含むライブマイグレーションにおいてそのような状況を検知した場合、ライブマイグレーション先の物理ホストへのストレージ I/O のミラーリング処理を完全同期として対応します。結果ローカルストレージへの I/O を遅くすることで、ネットワークのデータ転送速度をストレージの I/O 速度が追い越さないようにしています。また、ライブ マイグレーションの並列度も絞っています。
vSphere 5.1 vMotion deep dive

将来的に NVM (NVMe ではなく) 対応するともっと熱い世界が垣間見えるのではないかと期待したいところです。

Google Cloud Platform の Network

これは使用感や技術論だけではなく印象でしかなく恐縮してしまうのですが、プロダクトとして表に出ないモノの Google Cloud Platform のネットワーク基盤も常識からは一線を画していると感じています。TRILL、Leaf-Spine、オーバーレイ ネットワークなどオンプレのネットワークも進化し続けています。しかし、Jupiter ネットワークや、Andromeda によるパケット制御、自前の海底ケーブルは、それらとは次元の異なるアプローチを取っているように感じます。

Zone 間や Region 間のレプリケーションや、さらに追加されるであろうサービスを支えるには、ここまでやるのかと感服するばかりです。

Google BigQuery

これは方々で語り尽くされているようなので簡単に。1TB を 1 秒でスキャンするのに 5,000 台の HDD が必要、という数による解決の発想がベースですが、BigQuery がスゴイのは、Query を多重にしても十分な速度で対応できることだと思います。スキャンだけでなくクエリー単位の並列処理も数で解決、これはオンプレでは厳しい。クォータで 20 並列と制限が掛かっていますが、それでも 100,000 台ごときの HDD は Google にとっては塵のような量でしょうから問題無いのでしょうね。

こんな例もあったみたいですが、この辺はクラウド使う上でのトレードオフかとも思います。が、クエリーに対してもクォータは設定できた方が安心かしら…

2015/12/16 追記

とエントリーを公開した直後に BigQuery のコスト上限設定が可能に 🙂 。早いわ〜。 BigQueryのコスト上限設定が可能に。蕎麦屋の出前のようで恐縮です。それとQuery Explain機能も。

終わりに

GCP を触ってみて感じるのは、ネットワーク、ストレージの基礎能力の高さです。この 2 つは他のサービスを実装する土台となっているので、これらが超弩級に高性能であれば、自ずとその他のサービスも高性能になることが期待できます。

固定のワークロードや現状持ち出せないデータがある場合はオンプレ、逆立ちしてもオンプレでは実装できない超弩級のウルトラ テクノロジーを使うために GCP、というハイブリッドなクラウドが、企業向けのクラウドとしてベストなのではないかとも思います。

まだまだ触り始めな段階ですが、API/SDK レベルで使いこなせていければと考えています。

このエントリーは Google Cloud Platform Advent Calendar 2015 の 16 日目の記事となります。
← 15 日目の記事 GCE の preemptible VM で、インフラの CI を回し始めました
→ 17 日目の記事 JSONなアレに疲れたアナタに贈るGoogle Cloud Deployment Managerのススメ