
Play + SBTでプロジェクト分割管理
初めまして、アドテク本部でインフラエンジニアをしております山下といいます。
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に設定した秘密鍵が設定された状態でインスタンスを作成することが可能です。
ざっとこんなところになります。この中でも特筆すべき点を抽出します。
GCPではちょうどGoogleドライブでスプレッドシートを共有するようなイメージで、プロジェクトへの招待(追加)が可能です。
また、プロジェクトへ追加した人に対してはメール通知を行うこともできます。
さらに利用者として見た場合、自分が参照できるプロジェクトを自由に行き来することができるため、アカウントを意識する必要が無くなりますので、以下の点がAWSより便利だと感じました。
AWSは新しいエンジニアの方がジョインした場合、既存のキーペアを共有する必要がありますが、
GCPの場合、各々で鍵を登録できるため鍵を共有する側としては手間が省けて助かります。
EC2より早く、且つ無停止で複製できる点が素晴らしいです。
後述するライブマイグレーションの機能を使っているのでしょうか?
ただしここで言うクローンはインスタンスの設定をそのままに新規インスタンスを作成することを指しています。
本来の意味のクローンを行う場合はAWSと同じ要領でスナップショットを取得し、それを元にインスタンスを作成する必要があります。
DDoSのような事態が起きて、緊急で特定のIP範囲からの接続を防ぎたい場合を想定するとACLが無いというのは不便です。
AWSではサブネット単位でACLの制御ができましたが、GCPはミドルウェア側で頑張るしかないのでしょうか。
今回はGCEしか使ってみていないので、もしかすると他の回避策があるのかもしれません。
ポイントはネットワーク(AWSで言うところのVPC)内にリージョンを問わずサブネットを追加できる点だと思います。
これができることでリージョン間の通信も同一ネットワーク内であればプライベート通信が可能となっているようです。
そのネットワークですが、作成する際に以下2つのモードが選択できます。
調べているとGCEには他にも注目すべきポイントがありました。
インスタンスの利用時間が毎月計算され、自動的な割引が発生し、1ヶ月間 24時間稼働させた場合、30%オフとなるようです。
ホスト障害等が発生した際にインスタンスを止めること無く無停止で別ホストに移動させることができます。
インスタンスタイプのスペックをカスタマイズすることが可能なので、CPUに尖ったインスタンス・メモリに尖ったインスタンス…などといったものが作成できます。
インスタンスをしばらく起動し続けると一覧の画面上でリソースを使っていない旨の警告、及びおすすめのインスタンスタイプが表示されます。
停止は伴いますが、その場でおすすめインスタンスタイプへの変更も可能です。
AWSの場合はTrusted Advisorから得られるような情報でもひと目で把握できる点は非常に良いですね。
24時間以内のどこかで終了することが決まっている分、コストの安いインスタンスです。(コア時間あたりわずか $0.01)
止まっても問題ない一時的な処理をする際の利用が考えられます。
また、インスタンスの作成画面からプリエンプティブルインスタンスの使用有無が選択できるため、AWSスポットインスタンスより手軽に利用できそうです。
さんざん各所でやり尽くされている内容と思いますが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