Google Cloud Platform(2) Advent Calendar 2016 8日目を担当するk-bataです。
Qiitaへ投稿するのは初めてで読みづらい点もあるかと思いますが、最後までお付き合いくださいませ。
今年になってGCPの東京リージョンが発表され、AWSにしか関心がなかった自分がGCPを触ってみたところ、非常に使いやすいと感じました。
特に運用フェーズではGCPの方が使いやすいと感じるところがありましたので、AWSと比較しながら紹介したいと思います。
対象となるかた
- AWSでたくさんのアカウント（VPC）を管理しているインフラ担当
- GCPに興味はあるが、運用で楽できるのか不安に思っている方
ハードウェアメンテナンスで仮想マシンが停止しない
AWSで１００台以上のインスタンスを運用していると、月に一度はどこかの仮想マシンがメンテナンス再起動の必要に迫られます。
AWSから時折り「私達の都合で、２週間後の○月○日○時頃から２時間の間に勝手に再起動します」というメールが送られてきます。そんな時間に再起動してくれるな、という場合は、その前にシャットダウン＆ブートすることでスケジュールメンテナンスを回避できますが、あまり気が進む作業ではありません。
Webサーバのように明らかな冗長構成が組んであるものはいいのですが、そうではないもの（バッチサーバやら特殊なWindowsアプリを稼働させているサーバやらなんたらかんたら）は、アプリケーション担当者と連携して対応する必要があります。運用中の停止＆起動は大抵が初体験になるので、問題ないだろうとは思いつつも「倒れる時は前のめり」の精神で対応することになります。
また、そもそもスケジュールメンテナンスの通知メールが来なかった、というトラブルにも遭遇しており、AWSのハード・ウェアが気になって枕を高くして寝られません。
前置きが長くなりましたが、Googleではライブマイグレーションしてくれるので、そんな心配はいりません。
我々は、仮想マシンを実行し続けながら、積極的なメンテナンスを実行するライブマイグレーション技術と、ソフトウェアおよびデータセンターの革新を兼ね備えた透過的メンテナンスを導入しました。これにより、メンテナンス時に一般的に必要な停止時間や再起動の必要なく、定期的なアップデートと積極的な維持管理のすべての利点を得ることができます。
ライブマイグレーションといえばVMwareが思いつきます。VMwareではメモリを移行先のマシンに用意（コピー）して、最後にエイヤと切り替わるのですが、その瞬間はネットワークが瞬断されます。動作する物理ホストを変えるのですし、瞬断くらい致し方ないと思うのですが、Googleはそうではありません。
旧い記事ですが、Googleと協力して高負荷状態の仮想マシンをライブマイグレーションするテストを行ったRightScaleがこう言っています。
Googleが教えてくれなければ、マイグレーションしたことさえ気づかなかった。。。
私はこれだけでおかわりできそうなくらい、GCPが好きになりました。
仮想マシン起動中にディスク容量を拡張できる
データストアによっては、運用中にどうしてもディスク容量を拡張しなければならない場合があります。GKEのようなコンテナベースのシステムであれば、ディスク容量の拡張なんぞ無縁なのかも（無縁なように設計しなければならない）しれませんが、なかなかそうはいきません。
AWSでディスク容量を拡張する場合、ざっくり以下の手順になります。
- 仮想マシンの停止
- 当該ボリュームのスナップショットを取得
- スナップショットから新しいボリュームを作成(ここでディスクサイズ決定）
- 旧ボリュームをデタッチ＆新ボリュームをアタッチ
- 仮想マシンの起動
大概がデータストアとして運用しているサーバでしょうから、作業中はサービスが停止することになります。ディスク容量やスナップショット取得履歴有無によって異なりますが、早くても数十分の停止が余儀なくされます。社会の休息時間にメンテナンスするのが世の常ですから、ディスク容量の拡張作業はなるべく避けたいところ。かといって、仮想マシン作成時に都合のいい容量を決められるはずもありません。
Googleでは
- コンソールでディスクを拡張
以上。
画面で（コマンドでもいいのですが）、数字を変えるだけです。
対象がルートディスクの場合は再起動の必要がありますが、AWSでの作業で発生するサービス停止の影響を考えると、微々たるものです。
追記 自己責任でルートディスクの拡張もできます。コメント欄をごらんください。
仮想マシンのホスト名だけで簡単にアクセス
私は、AWSでは仮想マシン間のホスト名解決にプライベートDNSを利用しています。
自分がAWSをいじりはじめた２０１２年頃は、プライベートDNSの機能がなかったので、オンプレミスでやっていたころの運用ルールをそのままあてはめていました。
ホスト名とローカルIPアドレスの管理表をつくって、「IPアドレスの第３オクテット１００番台は○○用のサーバ」なんてオレオレルールつくって、IPアドレスだけでなるべくサーバの役割がわかるようにしていました。サービスの障害点を増やしてまでプライベートDNSを運用するに気にはならなかったので、必要な分を必要なサーバのhostsに書いておくという、泥臭い運用です。
AWSのプライベートDNSを使い始めてからは、「仮想マシンのローカルIPが払い出されたら、そのホスト名とIPアドレスをプライベートDNSに登録すればOK」になって、これで管理表やhostsの運用から解放される、と小躍りしていました。
GCPではどうか。
仮想マシン名を決める。
以上。
仮想マシン名なんて、どう考えても必須項目なやつなんですが、それだけでhostnameやらhostsやらに自動設定されていて、GCPがあらかじめ用意してくれているプライベートDNSにも登録してくれているようなのです。
この機能を体験した時、何故か誰かと握手したくなりました。
プロジェクト関係者の管理が簡単
AWSではIAMというユーザー管理機能があって、機能はとてもとても充実しているのですが、使いこなせる気になれません。特に、私のようにAWSアカウント１つにWebサービス（≒プロジェクト）１個程度という運用をしていると、サービスを追加するたびに管理するAWSアカウントが増えてしまいます。
同じ人が複数のプロジェクトに関わるのなんてザラですから、厳正に管理しようとしたら、AWSアカウント毎にユーザーを作成していくことになり、そして、作成するたびにクレデンシャルをダウンロードすることになります。
かといって、１つのAWSアカウントにプロジェクトを詰め込むと、それはそれでユーザーの権限管理が大変になりますし、インスタンスが増えすぎて余計なオペミスを誘発しそうです。
GCPでは、プロジェクトに既存のアカウント（実務ではGoogle Appsアカウントでしょうか）を紐つけるだけです。プロジェクト毎に、わざわざプロジェクト用ユーザーを作成する必要はありません。
チェックボックスだけでCDNを有効化
AWSではCloudFrontというCDNサービスがあります。HTTP/2もサポートするようになり、静的サイトなら、S3経由でAWSのサーバ証明書を設定したCloudFrontで公開するのが最適解のひとつではないでしょうか。
そんなイケてるCloudFrontなのですが、残念に思うのが初期構築＆設定変更にかかる時間で、設定変更でさえ数十分はかかります。世界中のEndpointに設定を反映させるのでしょうから、時間がかかってしまうのは仕方ないと思いつつも、老いていくにつれて気が短くなっていく自分にはつらいところです。
GCPの場合、「Cloud CDN を有効にする」にチェックをいれるのみです。
現状ではロードバランサーに対してしか設定できないようなので、上記の「静的サイトをCDNで運用する」という点では比較はできません。しかし、チェックボックス入れる＆httpヘッダーにお決まりのやつをいれてくれれば、あとはよろしく配信しておくよ、という潔さが単純に好きです。
安い。利用者側が長時間割引のリスクを負わない
安いです。基本的な料金の比較は色々な方がやっているので、ここでは言及しません。何を言いたいかというと「利用者側が長時間割引のリスクを負わない」のです、GCPでは。
AWSには言わずと知れた「リザーブドインスタンス」という長期間利用割引サービスがあります。1年or3年、仮想マシンを使いつづけたら安くなりますよ、というものです。インスタンスプランや期間、支払い方法（前払い有無）によって、割引率は異なりますが、ならすとざっくり3割引きといったところでしょうか。
私は以前、t1シリーズという一番お安いプランがでたときに、t1.microを3年重度使用（ほとんど前払いで、毎月は少額の支払い）で自腹利用しました。2年位たったころでしょうか、t2シリーズが発表され、t1シリーズは過去の遺物となりました。前払いしちゃっているので、インスタンスは起動しつづけていましたが、殆どsshされなくなった彼の背中はとても寂しそうでした。今でも、AWSの新しいインスタンスプランが発表されるたびに、彼の背中を思い出します。
何が言いたかったのかというと、長期間使うというリスクを、AWS側ではなく、私達利用者が負わなくてはならないのです。
期間を持て余したリザーブドインスタンスを他の人に売ることが出来るのですが、もろもろ条件があったりして（アメリカの銀行口座じゃなきゃいけない等）、運用負担がなくなるわけではありません。
GCPでは、長期間使ったら勝手に割引してくれます。まるまる1ヶ月稼働していたら、3割位安くしてくれます。それより稼働時間が短かったら2割引きとか、稼働時間によって割引率を変わります。
もう一回言います。
こちらが何もせずに勝手に割り引いてくれます。
使いたい分だけ使えば、それが最適な価格になっているという。
インスタンスが多くなってくると、どのリザーブドインスタンスにすべきかを検討するのもそれなりの仕事になってくると思います。間違ったら「長期間使うというリスク」を負ってしまう訳ですから。
このGCPの割引システムは、運用負担も無く、フトコロにとっても優しい仕組みではないでしょうか。
## まとめ
多くのAWSアカウントを運用していて、「面倒だな、こうなってくれればいいのに」と感じていたことが、GCPではかなり解決されているので、とても使いやすいと思います。
もちろん、AWSのサービス範囲の広さはとても素晴らしいと思いますし（具体的には、GCPにはElastiCacheサービスのようなものがない）、Auroraなどコスパに優れた製品も魅力的です。
それを差し引いてもなお、GCPを使ってみたいと思いました。特に運用面において、です。
私の友人が、「Googleは撤退も速いから不安を感じざるを得ない」と言っていましたが、たしかにその通りです。ただし、Googleは、無料のコンシューマ向けサービスがそこまで流行らなかった場合に撤退している、という印象があり、法人向けビジネス(Google Apps for Workあらため、G Suiteなど）では、そこまでの印象はありません。また、丁寧かつわかりやすいドキュメント・チュートリアルを見ていると、Googleの本気度と事業継続性に期待せざるを得ません。少なくとも、私は使い続けるつもりです。