【2015年版】AWS ユーザが Google Cloud Platform に15分で入門する!

  • 338
    いいね
  • 0
    コメント
この記事は最終更新日から1年以上が経過しています。

Google Cloud Platform Advent Calendar 2015 の第一夜を光栄にも務めさせていただきます!

Google Cloud Platform.png

第一夜ということで出来るだけそれに相応しいテーマを選ぼうと思い、「AWSは使ったことがあり、Google Cloud Platform(以下GCP)は使ったことがないが、興味がある」ひとがGCPを使ってみよう!と思えるような記事になれば良いなと考えながら書きました。これを見て一人でも多くの方がGCPを使ってみるきっかけになれば幸いです。
また GCP Advent Calendar 2015 の明日以降の記事ではGCPのより深い魅力を掘り下げた良記事がたくさんあることでしょう!そちらも御覧ください。

GCPとは

GCPはGoogleが提供するIaaSであり、Amazonの提供するAWSに相当しますが、Googleが自社インフラとしてのクラウド環境を我々一般客にも丸々開放したという点が特徴的です。私達が使えるようになったのは最近ですが、ぽっと出のサービスなどではなくGoogleが長年培ってきたノウハウの賜物なんです。

参考:YAPC Asia 2015「Google Cloud Platformの謎テクノロジーを掘り下げる」のまとめ

GCPの構成要素

GCPは以下に挙げるようなコンポーネントで構成されています。

App Engine

appengine_s.png

Googleが提供するPaaS
Python, Java, PHP, Goなどで書いたコードをデプロイして実行できる。バージョン管理も簡単。ウェブサーバやデータベースサーバを別途インストールする必要がなく、数100万オーダーのリクエストにも自動スケールする。
リリースされた当初はデータベースとしてBigTableしか利用できなかったため若干クセがあったが、現在は後述するCloud SQLに対応しており、ほとんどMySQLのようにデータを格納することができる。

Compute Engine

google_compute_engine_logo.jpg

Googleが提供するVMインスタンス群とこの管理コンポーネント。AWSのEC2に相当。
Googleのサーチエンジン、Gmail、YouTubeなどなどの構成要素として使われているインスタンスと全く同じインフラ基盤上で動いている(なんだか感動的じゃないですか!)
ハイパーバイザはKVMらしい。
インスタンスの作成・起動が驚くほど早く、またライブマイグレーションが強力で物理サーバのメンテナンス時に自動的にインスタンスをマイグレートしてくれるため非常に強力。

参考:Google Compute Engine Live Migration Passes the Test

本記事では主にこれについて解説します。

Cloud SQL

AWSのRDSに相当。MySQL 5.5, 5.6 が選択可能なフルマネージドRDBサービス。
残念ながらこれを書いている2015年12月時点でオンプレミス環境らAWS RDSとのレプリケーションマスタ・スレーブいずれになることができないので、既存の仕組みを動かしながら移行するのは困難。
RDSはこれを提供しているので個人的にはとても残念!

なお、RDSからGCP上に立てたMySQLにほとんどダウンタイムなく引っ越しする方法は Amazon RDSから外部MySQLにダウンタイムほとんどなく移行する に書いたので良かったらご覧ください!

Cloud Storage

AWSのS3に相当。
余談だが、AWSはAmazon Glacierという大量の静的ファイルを非常に安価にアーカイブできるかわりにデータの復元に数時間かかるサービスを提供しているが、Googleがこれに対する競合として出してきたCloud Storage Nearlineはアーカイブの復元も数秒単位という驚異的スピードで、Googleの本気を垣間見ることができる。

BigQuery

Googleのフルマネージドなビッグデータ解析基盤。膨大な量のアクセスログ等を任意のスキーマで格納し、SQLライクなクエリに気軽に高速に取り出すことができる。
AWSにも対応するサービスがあると思うが、これに関しては私が詳しくないので存じません。すみません。

他にも…

他にも、いま空前のブームであるDockerのクラスタマネージャおよびオーケストレーションシステムである Google Container Engine (GKE) などなど優れたサービスがいっっぱいあるんですが、個人的に一押しなのが Google Cloud Monitoring という監視ツール群です。これは 当アドベントカレンダーの8日目でじっくり解説 したいと思います!

Compute Engineを使ってみよう!

さて、いきなり長くなってしまったので、GCPの中でも花形とも言うべき(勝手に僕が言ってるだけ)Compute Engine を使ってみたいと思います!

Compute Engineの有効化

https://cloud.google.com/

にアクセスして、右上の My console を選択してください。

my console.png

自分のGoogleアカウントでログインします。

google account.png

初めて利用する場合はプロジェクトがないので「プロジェクトを作成」を選択します。

create project.png

任意のプロジェクト名を入力して「作成」を選択します。

new project.png

「Google API を利用する」を選択します。

enabole_google_api_01.png

入力ボックスに「Compute Engine」と入れ、下のリストから「Google Compute Engine」を選択します。

enabole_google_api_02.png

「APIを有効にする」を選択します。

enabole_google_api_03.png

※ 以下のステップで課金情報を入力します!利用量に応じて料金が発生することをご納得の上で入力して下さい!

「課金を有効にする」を選択します。

enabole_google_api_04.png

「請求先アカウントの作成」を選択します。

enabole_google_api_05.png

「名前」に入力し「続行」を選択します。
この名前はユーザの識別の便宜のためのもので、それほど深く考える必要はありません。

enabole_google_api_06.png

国を「日本」にして「確認」を選択します。

enabole_google_api_07.png

請求先の住所や名前を入力し「送信して課金を有効にする」を選択します。

enabole_google_api_08.png

しばらく待つとプロジェクトの作成が完了します。
そうしたら My console を再び選択し、ダッシュボードに入ります。

VMインスタンスの作成

ダッシュボードの左上のハンバーガーメニュー(赤で囲んだ部分)を選択すると、左からドロワーメニューが現れます。

dashboard01.png

ドロワーメニューから「Compute Engine」を選択します。

dashboard02.png

まだ何もないので「VM インスタンス」を選択します。

dashboard03.png

いよいよ初めてのVMインスタンスを作成します!
「インスタンスを作成」を選択します。

instance01.png

「名前」にインスタンス名
「ゾーン」をとりあえず asia-east1-a
「マシンタイプ」を一番安価な micro
「ブートディスク」を任意(ここではDebian 8.2)、ディスクサイズなどは一旦そのまま
「HTTPトラフィックを許可する」にチェック
「作成」を選択

instance02.png

しばらく待つとインスタンスが作成されます!おめでとう!

instance05.png

なお、インスタンスタイプは以下の通り選べます。

instance03.png

また、ブートディスクは以下の通り選べます。

instance04.png

gcloudコマンドの用意

インスタンスの操作等を便利に行うためにGoogle Cloud SDKを入手し、お使いのPCにセットアップします。

https://cloud.google.com/sdk/

を参考に、以下の通り入力していきます。
これは Linux/Mac OS X の例ですが、上記リンクにその他OSの例も載っているので参考にしてください。

$ curl https://sdk.cloud.google.com | bash
$ exec -l $SHELL
$ gcloud init

次に、

$ gcloud auth login

と入力するとブラウザにリダイレクトされ、アカウントの選択と認証画面が表示されます。
「許可」を選択してGoogle Cloud SDKに認可を与えてください。

auth.png

以下の様な画面に遷移すればOKです。

auth_ok.png

VMインスタンスにSSH

インスタンスが作成されたら、いよいよSSHして作業してみましょう!
作成されたインスタンス名をクリックして詳細画面に移動し、「SSH」「gcloudコマンドを表示」と選択します。

ssh01.png

すると、このインスタンスにSSHするための gcloudコマンド が表示されるのでクリップボードにコピーします。

 ssh02.png

あとは任意のターミナルにペーストするだけ!

/Users/shiroyama% gcloud compute --project "shiroyama-first-gcp" ssh --zone "asia-east1-a" "my-first-instance"

Updated [https://www.googleapis.com/compute/v1/projects/shiroyama-first-gcp].
Warning: Permanently added 'XXX.XXX.XXX.XXX' (ECDSA) to the list of known hosts.
Warning: Permanently added 'XXX.XXX.XXX.XXX' (ECDSA) to the list of known hosts.

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
shiroyama@my-first-instance:~$

おめでとうございます!ログインできました!
試しにNginxでも入れてみましょう。なんといってもネット越しに確認しやすいですからね。

shiroyama@my-first-instance:~$ sudo apt-get install nginx
shiroyama@my-first-instance:~$ sudo systemctl start nginx.service
shiroyama@my-first-instance:~$ sudo systemctl status nginx.service
● nginx.service - A high performance web server and a reverse proxy server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled)
   Active: active (running) since Mon 2015-11-30 13:27:08 UTC; 25s ago
 Main PID: 1458 (nginx)
   CGroup: /system.slice/nginx.service
           ├─1458 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
           ├─1459 nginx: worker process
           ├─1460 nginx: worker process
           ├─1461 nginx: worker process
           └─1462 nginx: worker process

Nov 30 13:27:08 my-first-instance systemd[1]: Failed to read PID from file /run/nginx.pid: Invalid argument
Nov 30 13:27:08 my-first-instance systemd[1]: Started A high performance web server and a reverse proxy server.
Nov 30 13:27:26 my-first-instance systemd[1]: Started A high performance web server and a reverse proxy server.

インスタンス作成時にHTTPのトラフィックを許可しているので何もしなくてもブラウザから確認できるはずです。
インスタンスの「外部IP」に表示されているIPをブラウザにコピペしてアクセスしてみましょう。

nginx.png

表示されました!おめでとうございます!
以上が非常に駆け足でしたが、Compute Engineで初めてのインスタンスを起動するまででした!

Compute Engineの各種メニューとAWSとの対応

Compute Engineには「VMインスタンス」以外にも色々なメニューがありますが、理解するまではちょっと取っ付きにくいかも知れません。従って以下に AWSの○○に対応 という形で列挙させていただきました。
少しでも理解の助けになれば幸いです。

また、以下は自分の独自調査ばかりなので理解が間違っていたりする場合があるので御了承ください。
内容もメモ的でややとりとめがないので後日画像付きで大幅に加筆するかもしれません。

ディスク

外部ディスク。インスタンスにアタッチしてマウントしたり、そのままrootボリュームとして使う。AWSでいうEBSのボリューム。

イメージ

インスタンスのイメージ。イメージから簡単にインスタンスを起動できる。AWSのAMIイメージに相当すると思うがちょっと違う。(後述の通りテンプレート的には利用できない(そのためにインスタンステンプレートがある)のでちょっと違うけど)
(ブートディスクがインストールされた)ディスクから新しいイメージを作れるが、ソースとなれるディスクはインスタンスにアタッチされていてはダメ。
この場合はインスタンスを停止し、インスタンスを消してもディスクが残るように設定し、その上でインスタンスを削除する必要がある。
この状態でブートディスクをソースにしてイメージを作成すると、このAMIイメージのようなものが作られてインスタンステンプレートなどで利用できる。ただし、このイメージからインスタンスを起動するとそのままこのイメージがインスタンスにアタッチされ、使い回しできない。従ってテンプレートのように使うものではない。

スナップショット

インスタンスのスナップショット。起動中にも簡単にスナップショットを取れる。スナップショットから簡単にインスタンスを起動できる。
イメージと違いスナップショットからインスタンスを起動してもスナップショットは残り続ける。
AWSでいうEBSのスナップショット。
いまあるインスタンスのブートディスクをそのままスナップショットして例えば別のネットワーク上げることも簡単にできる。
最初VMインスタンスメニューの「クローン」がそれをしてくれるのかと思ったけど、このクローンは「設定が同じで空のVMを上げる」挙動に見える。このクローンの挙動は分かりにくいので、これをしたければスナップショットを使うと覚えておこう。

インスタンステンプレート

インスタンスのテンプレート。後述するインスタンスグループで利用できる。
マシンタイプやイメージ、ディクスタイプなども指定した状態で保存しておける。
ここではスナップショットは利用できないようなので不便。前述のステップでイメージを作っておくこと。

インスタンスグループ

インスタンスをまとめる機能。ここで作ったインスタンスグループをLBの下にぶら下げたりオートスケールの設定をしたりできる。
インスタンスグループはインスタンステンプレートを元にするか、既に起動している既存のインスタンスを選んでグループにまとめることも可能。
オートスケーリングはインスタンステンプレートを利用したときだけ使えるように見える。そらそうか。
既存のインスタンスを選ぶときはゾーンを変更したらさっきのゾーンのインスタンスは消えちゃったんだけど、これは同一ゾーンのインスタンスしかまとめられないということだろうか?
追記:ロードバランサのバックエンドにはインスタンスグループを複数登録できる。つまりゾーンごとに別のインスタンスグループを作っておいて両方ともLBの下に置けば良さそう。

外部IPアドレス

静的な外部アドレス。AWSのElastic IPと同じなので難しいことは何もない。

ファイアウォール ルール

ファイアウォール。AWSのSecurity Groupに相当する。だいたい同じことが出来るが、少し考え方が違うのでメモしておく。
最初に書いておくと、GCPのファイアウォールではアウトバウンドのパケット制御はできない。そういうのはiptablesとかで個別にやってねと明言されている。

基本的なルールとして、すべてのインバウンドアクセスは閉じられており、適宜ファイアウォールルールでアクセス許可をしていくイメージ。
インスタンスには後述する「ターゲットタグ」を付けることができ、特定のタグがついたインスタンスのみで有効になるアクセスルールを書けるのでそれを活用していくことになる。
ターゲットタグは単なる文字列であり、ドロップダウンリストから選ぶような形式でもないのでタイポに注意する。
また、ファイアウォールルールの名前とターゲットタグは関係がない(一緒にしても別にいい)
最初ルール名とターゲットタグが何か意味があるのかと思ってしまったが全然関係がない。ルール名は我ら管理者が分かればいいだけでアクセスルールには無関係。

ファイアウォールはネットワークごとに設定する。ネットワークについては後述。デフォルトでdefaultというネットワークがひとつだけあるはずなのでとりあえずこれ前提で解説。
「ソースフィルタ」はアクセス元を制限するルール

  • IP範囲…アクセス元をIPで設定。0.0.0.0/0, 192.168.2.0/24 のようにCIDR記法で、カンマ区切りで指定できる
  • インスタンスタグ…「ここで指定するタグの付いたソースからのトラフィックのみが許可されます。複数のタグを入力するには、各タグの名前の後で Return を押します。」のとおり。AWSのSGでも同じようなのがあるよね。
  • すべてのソースから許可 (0.0.0.0/0)…書いてある通り

「許可対象プロトコルとポート」もそのまま。tcp; udp:80; udp:5000-6000 みたいな感じ。

「ターゲットタグ(省略可)」…「ここで指定するタグの付いたインスタンスに対してのみ、トラフィックが転送されます。複数のタグを入力するには、各タグの名前の後で Return を押します。」
これだけちょっとAWSのSGと考え方が違う。ここで何もしないと↑のルールが「すべてのターゲット」に対して適用される。
うっかりtcp:80を指定してターゲットタグを空欄にしてしまうとこのネットワークのすべてのインスタンスにこのルールが適用されてアクセス可能になっているので注意すること。

ネットワーク

GCPすべてのインスタンスはいずれかのネットワーク(1つのみ)のメンバーとなる。最初からdefaultというネットワークが用意されている。
ネットワークは現実世界でルータが成す役割と同じ。小さなプライベートネットワークがいくつもあり、インスタンスはそのネットワークから出る時にはゲートウェイを経由して通信する。
制限事項としては現在IPv4しかサポートされていないことと、IPv4のpoint-to-point通信であること。何が言いたいかというと同一LANのようにみえてもブロードキャストやマルチキャストはできない。
言い換えれば、同一サブネット内での通信もゲートウェイを経由するということになる。

GCP内に論理的なプライベートネットワークを作る機能がある。
アドレス範囲には10.0.0.0/8などの一般的なプライベートネットワークのIPを指定する必要がある。
ネットワークはゾーンをまたがることができる。これによって地域を気にせず自然な論理的プライベートネットワークを作ることが可能。
ただしAWSのVPCのように同一subnetにいるから通信が早いとかそういうことは当然ない。なんせ論理的LANなので。

前述のdefaultネットワークはこんな感じのLANになっている。
* IPv4Range - 10.240.0.0/16
* gatewayIPv4 - 10.240.0.1
* name - default
最低限のファイアウォールルールも一緒に作られる。

詳しくは
https://cloud.google.com/compute/docs/networking

ルート

ルートはルーティングテーブルを提供する機能。
ある宛先(送信先IP範囲)へのパケットがどこへ行くのかを制御できる。
あるパケットがルーティングテーブルのルールにマッチした場合はそのルーティング設定によって次の行き先(ネクストホップ)が決まる。

GCPのネットワークにはデフォルトで2つのルートが定義されている。すなわちインターネットに出て行く経路と同一ネットワーク内の経路である。
ネクストホップには
* デフォルトインターネットゲートウェイ
* インスタンスを指定
* IPアドレスを指定
を選ぶことができる。インスタンスを指定すると、いわゆるLinuxルータの設定をしたインスタンスにパケットを送ってこの人が行き先を柔軟に制御することができる。

一番シンプルな例だと、セキュリティ等の理由からかならず有る宛先へのパケットは一度このインスタンスに集めて(必要に応じてログを残したりし)このインスタンスがIPマスカレード(NAPT)して目的の宛先に透過的に届ける、という用途が考えられる。その辺は以下に詳しい。この場合このインスタンスの処理能力やネットワーク帯域などが直接ボトルネックになりうる。その辺の制限もすべて公式サイトに書いてある。ネットワーク性能は端的に言ってインスタンスのコア数に比例するのでドキュメントを読むこと。

[ネットワークとファイアウォール]
https://cloud.google.com/compute/docs/networks-and-firewalls
[ルーティング]
https://cloud.google.com/compute/docs/networking#routing
[Linuxルータに関して]
http://redhatlinux.kt.fc2.com/cont/router.htm

おわりに

僕が勤める 株式会社マナボ では創業当時からサービスの全インフラをAWS上に構築してきましたが、

  • コスパの良さ
  • AppEngine, BigQueryなどとの親和性の高さ(Google提供なので当然ですね)
  • CTOがGoogle Develper ExpertなのでもともとGoogleのサービス全般を日々有効活用している

等々様々な事情や縁があって、2015年10月に全サービス基盤をGCP上に移行しました。
僕自身、AWSは前職から慣れ親しんでいましたがGCPは初めてということもあり移行作業はそれなりに苦労しましたが、コストパフォーマンスの面では非常に満足しており、苦労のしがいがあったと感じています。

まだまだ機能の豊富さはAWSに一日の長がありますが、GCPも非常に成熟してきたなと率直に感じます。
本記事でひとりでも多くの方がGCPを試していただければこれに勝る幸いはありません!それでは!

この投稿は Google Cloud Platform Advent Calendar 20151日目の記事です。