Play + SBTでプロジェクト分割管理
Blog
[Google Cloud Platform] AWSしか使ったことがない私から見たGCE
初めまして、アドテク本部でインフラエンジニアをしております山下といいます。
GCP東京リージョンの開設が近づいているこのタイミングで、GCPをネタに記事を書くことになりました。
GCPと言えば、先日ポケモンGoのバックエンドとして利用されていることでも話題になりました。
しかし、私自身GCPに全く触れたことが無く、まだ私にはパブリッククラウド＝AWSのイメージがあります。
そこで、パブリッククラウドの基本的なサービスであり、必ずついて回るであろうIaaSにフォーカスし
AWSしか使ったことがない私がGCE(Google Compute Engine)を触ってみて感じたEC2との違いをまとめることにしました。
早速、私がGCEに触れてみて感じたAWS(EC2)との違いを一覧にまとめてみます。
比較表
| 項目 | AWS（EC2） | GCP（GCE） |
| サービス利用方法 | AWSアカウントを作成 | プロジェクトを作成 |
| ユーザー | AWSアカウントごとに必要なIAMを作成 | Googleアカウントを必要なプロジェクトに適宜追加 |
| SSH鍵 | キーペアを作成し適宜共有
この時作成される公開鍵がインスタンス内に入っている状態で起動※1 |
GCEのメニューより
メタデータ -> SSH鍵からユーザ名/公開鍵を登録。 メタデータに追加したユーザと対になるユーザと公開鍵がインスタンス作成時に自動で設定される。 |
| SSHログインユーザ | ユーザはOSによって異なる（ec2-user or ubuntu etc…) | メタデータに追加したユーザ名が起動時に作成される。 |
| クローン | AMIを取得（数分待つ）し、取得したAMIでインスタンスを作成 | スナップショットを取得後、取得したスナップショットからインスタンスを作成。
インスタンス詳細画面にクローンボタンがあり1クリックすることで無停止でのインスタンス複製が可能 ただしストレージ周りはクローンされず、インスタンスの設定がクローン元と同じ空のインスタンスが作成される。 |
| ネットワーク | vpc作成時にあらかじめCIDRを設定し、CIDR範囲の中でサブネットを設定する | vpcに相当するネットワークを作成。CIDRを指定する必要はない。
ネットワーク作成後好きなリージョンにサブネットを設定していく。 |
| ファイヤーウォール | Security Groupを作成し、インスタンスやELBなどの各リソースに適応する | ファイヤーウォールを作成し、どのネットワークへ適応するかを選択。 またリソースにはタグ付けが出来、どのネットワークの・どのタグが付いているリソースへ適応させるか選択できる。 （ネットワーク全体への適応も可能） |
| ルートテーブル | Routing Tableを作成し、サブネットへ適応 | Routing Tableを作成し、ネットワークへ適応 |
| Network ACL | ACLを作成し、サブネットへ適応 | なし |
※1 Opsworksを使用すれば、IAMとIAMに設定した秘密鍵が設定された状態でインスタンスを作成することが可能です。
ざっとこんなところになります。この中でも特筆すべき点を抽出します。
Good
プロジェクト・ユーザ周り
GCPではちょうどGoogleドライブでスプレッドシートを共有するようなイメージで、プロジェクトへの招待（追加）が可能です。
また、プロジェクトへ追加した人に対してはメール通知を行うこともできます。
さらに利用者として見た場合、自分が参照できるプロジェクトを自由に行き来することができるため、アカウントを意識する必要が無くなりますので、以下の点がAWSより便利だと感じました。
- 管理者として
- AWSで新規アカウントを作成する際に、必要な人数分のIAMを作成する必要がある
- 作成したIAM情報の共有
- 利用者として
- AWSアカウントが複数ある場合、アカウント管理に工夫が必要
- AWSアカウントを行き来することはできず、複数のブラウザを使う必要がある
SSH鍵の管理
AWSは新しいエンジニアの方がジョインした場合、既存のキーペアを共有する必要がありますが、
GCPの場合、各々で鍵を登録できるため鍵を共有する側としては手間が省けて助かります。
迅速で無停止なクローン
EC2より早く、且つ無停止で複製できる点が素晴らしいです。
後述するライブマイグレーションの機能を使っているのでしょうか？
ただしここで言うクローンはインスタンスの設定をそのままに新規インスタンスを作成することを指しています。
本来の意味のクローンを行う場合はAWSと同じ要領でスナップショットを取得し、それを元にインスタンスを作成する必要があります。
注意
Network ACL
DDoSのような事態が起きて、緊急で特定のIP範囲からの接続を防ぎたい場合を想定するとACLが無いというのは不便です。
AWSではサブネット単位でACLの制御ができましたが、GCPはミドルウェア側で頑張るしかないのでしょうか。
今回はGCEしか使ってみていないので、もしかすると他の回避策があるのかもしれません。
ネットワーク
ポイントはネットワーク（AWSで言うところのVPC）内にリージョンを問わずサブネットを追加できる点だと思います。
これができることでリージョン間の通信も同一ネットワーク内であればプライベート通信が可能となっているようです。
そのネットワークですが、作成する際に以下2つのモードが選択できます。
autoモード
- 各リージョンに1つずつサブネットが自動生成される
- 自動生成されるサブネットはユーザ側で追加、削除、変更ができない（CIDRも変更不可）
customモード
- ユーザ側でサブネットの追加、削除を行う（追加時にはリージョンも選択可能）
- サブネットワークが被らなければ、同じネットワーク内で好きなリージョンに自由にサブネットを追加できる。
- 既存のネットワークで使用されているサブネットワークは、新規作成するネットワークでも使用可能。
他にもあった！良ポイント
調べているとGCEには他にも注目すべきポイントがありました。
自動割引
インスタンスの利用時間が毎月計算され、自動的な割引が発生し、1ヶ月間 24時間稼働させた場合、30％オフとなるようです。
ライブマイグレーション
ホスト障害等が発生した際にインスタンスを止めること無く無停止で別ホストに移動させることができます。
インスタンスタイプのカスタマイズ
インスタンスタイプのスペックをカスタマイズすることが可能なので、CPUに尖ったインスタンス・メモリに尖ったインスタンス…などといったものが作成できます。
コストアドバイス
インスタンスをしばらく起動し続けると一覧の画面上でリソースを使っていない旨の警告、及びおすすめのインスタンスタイプが表示されます。
停止は伴いますが、その場でおすすめインスタンスタイプへの変更も可能です。
AWSの場合はTrusted Advisorから得られるような情報でもひと目で把握できる点は非常に良いですね。
プリエンプティブルインスタンス（Preemptible VM）
24時間以内のどこかで終了することが決まっている分、コストの安いインスタンスです。（コア時間あたりわずか $0.01）
止まっても問題ない一時的な処理をする際の利用が考えられます。
また、インスタンスの作成画面からプリエンプティブルインスタンスの使用有無が選択できるため、AWSスポットインスタンスより手軽に利用できそうです。
UnixBench
さんざん各所でやり尽くされている内容と思いますがAWSとGCP 同等スペックのインスタンスでUnixBenchを取りました。
ただし、GCPはリージョンによってCPUの世代やスペックが微妙に異なるそうです。
東京リージョンのGCEではどうなるか分かりませんが、
東京から最寄りの台湾リージョンで立てたインスタンスと東京リージョンに立てたEC2でUnixBenchを取ってみました。
スペックと料金に関しては以下のとおりです。
なお、それぞれの料金は下記のページから算出しました。
AWS：https://calculator.s3.amazonaws.com/index.html
GCP：https://cloud.google.com/products/calculator/
| AWS（EC2） | GCP（GCE） | |
| インスタンスタイプ | m3.medium | n1-standard |
| CPU | 1 core
Intel Xeon E5-2670 v2 (Ivy Bridge) |
1 core
|
| メモリ | 3.75GB | 3.75GB |
| 1ヶ月の料金 | $ 70.28※1 | $ 28.11※2 ※3 |
※1 EBSボリュームやEIP、データ転送は未入力で計算
※2 24時間を1週間フルで使う設定でAWSと同様にインスタンス以外の項目は未入力で計算。自動割引 30%引きが適応。
※3 日本リージョンの価格が出ました。台湾よりもやや高めの n1-standard で $33.88 です。
結果は以下です。
結論から言うとAWSに比べてGCPは1.5倍程度の性能が優れているようです。
私的には性能差以前にカタログスペックが同じなのであれば、半額以下で利用できるGCPを使ってみたいなと思いました。
EC2
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
# ./Run ： ： System Benchmarks Index Values BASELINE RESULT INDEX Dhrystone 2 using register variables 116700.0 16767944.7 1436.8 Double-Precision Whetstone 55.0 2062.2 374.9 Execl Throughput 43.0 2684.1 624.2 File Copy 1024 bufsize 2000 maxblocks 3960.0 690739.4 1744.3 File Copy 256 bufsize 500 maxblocks 1655.0 189510.3 1145.1 File Copy 4096 bufsize 8000 maxblocks 5800.0 1468204.9 2531.4 Pipe Throughput 12440.0 1348736.8 1084.2 Pipe-based Context Switching 4000.0 221731.6 554.3 Process Creation 126.0 8068.3 640.3 Shell Scripts (1 concurrent) 42.4 3466.3 817.5 Shell Scripts (8 concurrent) 6.0 467.4 778.9 System Call Overhead 15000.0 1940750.2 1293.8 ======== System Benchmarks Index Score 949.8 |
GCE
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
# ./Run ： ： System Benchmarks Index Values BASELINE RESULT INDEX Dhrystone 2 using register variables 116700.0 35214310.9 3017.5 Double-Precision Whetstone 55.0 4166.9 757.6 Execl Throughput 43.0 4335.8 1008.3 File Copy 1024 bufsize 2000 maxblocks 3960.0 849444.9 2145.1 File Copy 256 bufsize 500 maxblocks 1655.0 238005.7 1438.1 File Copy 4096 bufsize 8000 maxblocks 5800.0 1945748.9 3354.7 Pipe Throughput 12440.0 1561828.0 1255.5 Pipe-based Context Switching 4000.0 338198.5 845.5 Process Creation 126.0 14503.5 1151.1 Shell Scripts (1 concurrent) 42.4 5771.6 1361.2 Shell Scripts (8 concurrent) 6.0 764.7 1274.4 System Call Overhead 15000.0 2487150.4 1658.1 ======== System Benchmarks Index Score 1446.4 |
まとめ
GCP（GCE）はコスト面やリソースの自在さ、ライブマイグレーションなどAWSを意識していてかゆいところに手が届いているなと感じました。
とはいえ使っていく中でAWSに劣る点も見えてくるかと思いますし、AWSとGCPでネットワークに関する考え方の違いも今回知ることができました。
いよいよ東京リージョンがオープンするGCP！お試しとして1度本格的に使ってみたいと思いました。
Author
shogo
