AWSしか触ったことのないサーバーエンジニアがGCPで本番運用してみた(前編)

VISITSサーバーエンジニアの@kshibata101です。

こちらはVISITS Advent Calendar 2019の6日目の記事です。

会社のAdvent Calendarということで、今までAWSしか触ったことのない自分が入社して最初に携わったプロダクトをGCPで動かすことになった経緯や実際導入してどうだったかを共有しようと思います。

GCPの導入を検討している方や、導入し始めている方の参考になれば幸いです。

思ったより長くなってしまったので前後編に分けて、前編では導入前の調査、後編では導入後分かったGCPの利点やノウハウを共有したいと思います。
タイトル的に運用の話をすると思いきや、前編では運用の話が入りませんでした。。すみません。。

導入前

当時会社にはプロダクトが2つあり、どちらもAWSで動いていました。
両者ともweb serverはEC2で、ELBを使ってロードバランスし、DBはAuroraという割と標準的な構成かと思います。

GCPも一部使ってましたが、分析のためにDataScienceチームがBigQuery使っていたり、処理の関係でCloud Functionsを使っていたりなど、ツールとしての位置付けでした。

そんな中で自分は入社をするのですが、ちょうど他に新しいサービスを作るということでチーム組成され、ビジネス的な観点からGCPを導入したいということになり色々調査を行うことになりました。

導入にあたっての調査

結論としては、基本的なWebサービスを作るための機能は一通り揃っているだろうということと、コストはそれほど違いがなさそうということで、後はエンジニアがやりたいかどうかという点になりました。
自分はちょうど入社したばかりの頃で、そこでいきなり初めてのGCPで本当に動かせるかは不安なところではあったのですが、最終的には勢いで決めたところもあると思います。

以下は調査で調べた内容などをつらつらと書いておきます。

調査の観点

調査にあたっては、以下の観点で選定を行いました。

1. 基本的なWebサービスを作る機能があるか
2. 可能な限りフルマネージド・サービスか
3. 費用

1. webサービスを作る機能

ここは大雑把に

A. web server (process立ち上げてhttpレスポンスを返す)
B. database server (RDBMS/NoSQL)
C. storage

あたりを確認しました。
もちろん、DNS・ファイアウォールなどのネットワーク周りや、CDN、IAM権限管理などの機能も重要ですが、その辺はクラウドだしある程度揃っているだろうということで、上に述べたところを少し重点的に調べることにしました。

2. フルマネージドか

ここは、当時インフラエンジニアの方が常駐ではなかったため、場合によっては対応するのが自分だけという可能性もありました。

インフラ知識の薄い自分でも理解して対応できる状態にしておきたいので、フルマネージドかどうかがポイントにあがってきました。

3. 費用

費用は、AWSと比べてどうか、というところで見ていきました。

実は多少高くてもGCPで行けるなら行きたいというビジネスサイドの要望もあったので、重要度としては3番目に置いています。
が、将来的にサーバー費抑えてねという話は出てくることは見えていたので、どれくらいかかるのかは把握しておきたいところです。

各種サービスの調査

A. Web Server

まず最初に気になるのがweb server周りの技術かと思います。
GCPを調べ始めると、GCPではwebサーバーの提供方法が大きく4種類あることが判明しました。

サービス	種別	カスタマイズ性	難易度
Cloud Functions	FaaS	小	低
App Engine	PaaS	↑	↑
Compute Engine	IaaS	↓	↓
Kubernetes Engine	CaaS*	大	高

*Cass: Container as a service. コンテナ技術を用いたプラットフォームを提供してくれるサービスということらしい。

上の表で、下に行けば行くほど自由度が高い反面、インフラ知識や管理を要求されるようになります。

結論を言うとApp Engine(GAE)を選択しましたが、各サービスの特徴や判断理由なども載せておきます。

A1. Cloud Functions

Cloud FunctionsはいわゆるサーバーレスとかFaaSいうやつで、AWSのLambdaに相当するものです。
何かプロセスを立ち上げて処理を待つという訳ではないので通常イメージするサーバーとは違うかもしれませんが、httpリクエストを受け付けられるので工夫次第ではwebサーバーのように使うこともできるようです。

今回導入したタイミングではRuby on Railsを動かすことが決まっていて、Cloud FunctionsはRubyに対応していないこともあり、Cloud Functionsは見送りました。

料金

一応料金体系としては、こちらに書かれている通り

• リクエスト100万回ごとに$0.4 (200万回までは無料)
• 処理時間1GB秒で$0.0000025 (40万GB秒まで無料)
• 1GHz秒で$0.00001 (20万GHz秒まで無料)
• ネットワーク(下り)1GBごとに$0.12 (5GBまで無料)

ということですが、実際無料枠が十分大きいのでよほどの使い方をしない限り大丈夫ということで、ここではさらっと触れるだけにしたいと思います。

A2. App Engine(GAE)

GAEはPaaSよろしく、コードと設定を用意すれば後は良しなにやってくれる優秀なやつです。

単純なアプリケーションサーバーだけでなく、内部でnginx含めたロードバランス機能も持っていて、設定ファイルに応じてスケーリングしたり、バージョンごとにデプロイを管理できたりします。

いずれもインフラやデプロイ周りはGCPがやってくれるので、インフラエンジニアや特別インフラに詳しい人がいなくてもサービス提供できるのは大きい魅力です。

当時会社にインフラエンジニアがいなかったことが大きく、試す中でも簡単に動いてくれることを確認できたのでGAEに踏み切りました。

Standard or Flexible

GAEはさらに2種類に細分化されます。

Standard Environment(SE)は制約がありますがコードと設定があれば動くやつで、Flexible Environment(FE)はもう少し柔軟にやりたい場合に使います。

項目	SE	FE
言語	Python/Java/Node.js/PHP/Go/Ruby（かつバージョン固定)	Dockerさえ動けばいいので任意の言語
デプロイ	1-3分	5-10分
起動(スケール)	数秒	数分
リクエストの最大タイムアウト	60 秒	60 分
バックグラウンド スレッド	○（制限付き）	○
バックグラウンド プロセス	×	○
SSH デバッグ	×	○
スケーリング	手動、基本、自動	手動、自動
ゼロにスケーリング	○	×（最小 1 インスタンス）
ローカル ディスクへの書き込み	△(できないものもあり)	○（エフェメラル、各 VM の起動時に初期化されたディスク）
ランタイムの変更	×	○（Dockerfile 経由）

※表は一部抜粋および補足あり

SEの方が制約が大きい分、デプロイ速度の面では圧倒的です。

ただ、やはり制約が厳しいのはダメージとしては大きく、しかも当時まだrubyが対応外でした。
バージョンが固定されていることもネックで、現在でもrubyは2.5.3でベータ版なので、開発側の要件でバージョンを上げたいと思ってもインフラ側でロックされてしまうのは痛いところです。

その点FEは自由度が高く、Dockerにも対応してるのでDockerfileさえあればいいというのは非常にありがたいです。
手元の環境とサービスの提供環境をほぼ同じにできるので、インフラ面での差異も気にしなくてよくなりますね。

料金

GAEはSEとFEで料金体系が異なります。

SEはインスタンスクラスと呼ばれるCPU-メモリスペックの組ごとに料金が決まります。

クラス	メモリ制限	CPU 制限	1時間あたりの費用
F1	256 MB	600 MHz	$0.07
F2	512 MB	1.2 GHz	$0.13
F4	1024 MB	2.4 GHz	$0.26
F4_1G	2048 MB	2.4 GHz	$0.39
B1	256 MB	600 MHz	$0.07
B2	512 MB	1.2 GHz	$0.13
B4	1024 MB	2.4 GHz	$0.26
B4_1G	2048 MB	2.4 GHz	$0.39
B8	2048 MB	4.8 GHz	$0.52

一方、FEはvCPU/メモリそれぞれごとに料金が決定されます。

リソース	単位	単価
vCPU	コア時間あたり	$0.0666
メモリ	GB 時間あたり	$0.0089
永続ディスク	GB/月	$0.0520

今回想定したアプリケーションではRails+pumaで複数プロセス/スレッドで動かすことを前提にしていた関係で、vCPUが2コア以上、メモリが2GB程度必要になりました。

上記の前提だと、SEではB4_1GまたはF4_1Gのインスタンスクラスになるので、価格としては

	インスタンス	価格
SE	B4_1G または F4_1G	$0.39
FE	vCPU2コア +2GBメモリ + 10GBのdisk	$0.169

となり、倍くらいSEがかかる計算となりました。
実際には複数インスタンスで運用するため、この差は運用が長くなると大きく効いてきそうです。

Railsのようにフレームワークのオーバーヘッドが大きく、インスタンスのスペックをある程度上げざるを得ないようなケースでは、FEの方が値段面でお得にはなりそうです。

ちなみに費用の観点ではインスタンス費用以外にも、ネットワーク(下り)の料金もかかりますが、

	ネットワーク料金
SE	$0.12/GB
FE	\$0.14~\$0.12/GB (使用量に応じて変わる、GCEと同じ)

ということでほとんど違いはありません。

上記も踏まえて、GAEでFlexibleを選択することにしました。

A3. Compute Engine(GCE)

Compute EngineはVMで、AWSにおけるEC2に相当するやつです。
とりあえずコード配置してサーバープロセス立ち上げれば、サーバーはさくっと作れるかと思います。

ロードバランサー

ただし、単体のサーバーで運用することはなく、実際にはロードバランサー(LB)を組み合わせることになるかと思います。
GCPはLBもいくつか用意してくれています。

• HTTP(S)
• SSLプロキシ
• TCPプロキシ
• ネットワークTCP/UDP
• 内部TCP/UDP
• 内部HTTP(S)

通常web serverとしてhttp(s)で提供する場合はHTTP(S)ロードバランサーを選択すれば、スケーリングはうまくやってくれます。
http以外のプロトコルを用いたい場合は他のロードバランサーを使えば良さそうですが、標準的なwebアプリケーションを作る場合は必要なさそうです。

また、インスタンスグループという仕組みを使うことで、コンテナイメージからインスタンス立ち上げも特に気にせずやってくれるようになり便利です。

最初に結果GAEを選択したと言いましたが、メインのアプリケーションの前段にnginxサーバーを置く構成を取りたかったのですが、nginxサーバーに関してはこのHTTPSロードバランサー形式を取りました。

ただし、ロードバランサーの種類が多い、インスタンスグループとインスタンスなど登場人物が多いなどことから、サーバーを初めて構築する方はやはりGAEが良いかなと思います。
逆にAWSで同様の構成を取っているなど、経験がある方はこの方式でも違和感なく導入できそうです。

料金

GCEも同じくインスタンス起動時間とネットワーク(下り)の料金がかかります。

ネットワーク(下り)に関しては、GAEのFEと同じ料金体系となっています。

インスタンス起動時間比例のものについては、SEよりも種類の多いマシンタイプごとに料金が決まってきます。

以下にはN1シリーズの標準タイプをあげてみます。

マシンタイプ	仮想 CPU 数	メモリ	料金（米ドル）	プリエンプティブル料金（米ドル）
n1-standard-1	1	3.75GB	$0.0610	$0.01325
n1-standard-2	2	7.5GB	$0.1220	$0.0265
n1-standard-4	4	15GB	$0.2440	$0.0530
n1-standard-8	8	30GB	$0.4880	$0.1060
n1-standard-16	16	60GB	$0.9760	$0.2120
n1-standard-32	32	120GB	$1.9520	$0.4240
n1-standard-64	64	240GB	$3.9040	$0.8480

また上記のCPU・メモリの組が好みのものでない場合、以下のN1カスタムの料金体系で自由に組み合わせることもできます。
このあたりがAWSと違うポイントになってくるでしょうか。

項目	オンデマンド料金	プリエンプティブル料金	1 年間の確約利用割引価格	3 年間の確約利用割引価格
カスタム vCPU	$0.040618 / vCPU hour	$0.00883 / vCPU hour	$0.025589 / vCPU hour	$0.018278 / vCPU hour
カスタムメモリ	$0.005418 / GB hour	$0.001178 / GB hour	$0.003414 / GB hour	$0.002438 / GB hour

GAEと同じくvCPU2コア・メモリ2GBで考えるとN1カスタムということで、約\$0.09/hとかなりお安くなります。

さらにGCEは確約利用と継続利用で安くすることが可能です。

確約利用は1年間等の長い期間使い続ける代わりに57%あるいは70%安くなるというもので、継続利用は月の半分以上起動し続けていると勝手に最大30%まで割引してくれるというものです。

確約利用はロックインの期間が長いので、検証しながら使う場合継続利用で十分だと思います。
上のケースでは約\$0.06/hになりますね。

ただし、GAEにはLBが含まれているため、なるべく同じ比較を行うためGCEもLBの費用を考えます。
LBは転送ルールごと課金という不思議な料金体系となっていますが、ルールが5つまでなら追加\$0.038/hで済むため、継続利用の30%割引にこれを加えても\$0.10/h程度となります。

GAEのFEが\$0.17/h程度だったので、それと比較してどうかというところでしょうか。
もちろん台数が増えればこの差も大きくなるため、費用と機能の豊富さのバランスになってくるかと思います。

AWSとの比較

GCEはAWSのEC2と比較されることになるかと思います。
機能面の差異はそれほどないと思いますので、主に費用面だけ見たいと思います。
ちなみにインスタンスタイプをすべてあげると両者とも大変な数になるため、シンプルなものだけ比較します。

EC2の料金はこちらになります。

	vCPU	ECU	メモリ (GiB)	インスタンスストレージ (GB)	Linux/UNIX の料金
t3.nano	2	変数	0.5 GiB	EBS のみ	0.0068USD/時間
t3.micro	2	変数	1 GiB	EBS のみ	0.0136USD/時間
t3.small	2	変数	2 GiB	EBS のみ	0.0272USD/時間
t3.medium	2	変数	4 GiB	EBS のみ	0.0544USD/時間
t3.large	2	変数	8 GiB	EBS のみ	0.1088USD/時間
t3.xlarge	4	変数	16 GiB	EBS のみ	0.2176USD/時間
t3.2xlarge	8	変数	32 GiB	EBS のみ	0.4352USD/時間
t3a.nano	2	変数	0.5 GiB	EBS のみ	0.0061USD/時間
t3a.micro	2	変数	1 GiB	EBS のみ	0.0122USD/時間
t3a.small	2	変数	2 GiB	EBS のみ	0.0245USD/時間
t3a.medium	2	変数	4 GiB	EBS のみ	0.049USD/時間
t3a.large	2	変数	8 GiB	EBS のみ	0.0979USD/時間
t3a.xlarge	4	変数	16 GiB	EBS のみ	0.1958USD/時間
t3a.2xlarge	8	変数	32 GiB	EBS のみ	0.3917USD/時間

例のvCPU2コア、メモリ2GBということであれば t3.small に該当するため、EC2では\$0.0272/hになります。
GCEが継続利用で\$0.06/hと考えると、さすがEC2という感じがしますね。

A4. Kubernetes Engine(GKE)

こちらはkubernetesをマネージドで動かしてくれるサービスです。
ほぼほぼymlファイル書くだけで、あとインスタンスを立てるとかは自動でやってくれます。

何にせよkubernetesに関する知識は必須なので、知識ない状態で初めてGCPでやるにはハードルが高いです。

上に述べたように、nginxはGCEで、アプリケーションはGAEで、その他は~~で、みたいに登場人物が増えてくるとお金もかかるし管理も複雑になってくるので、そのあたりを効率化したいとなった段階でkubernetes化しても大丈夫かと思います。

現在は一部プロダクトで導入が進んでるのですが、今も手探り状態であるので最初からは無理だったなと思います。

料金

GKEはノードがGCEで動いていることから、GCEの料金体系に準じます。(https://cloud.google.com/kubernetes-engine/pricing?hl=ja)

Kubernetesは管理用のマスターノードが存在するため、普通に構築するとこのノード分もお金がかかることになります。
ただし、嬉しいことにGKEではこのマスターノードの分のお金はかかりません。

このため、通常のノードがいくつ作られるか次第ということになります。
単純にはノードに複数のPod(アプリケーション)を詰め込めるため理論上安くなるはずですが、最終的にはアプリケーションの構成次第になりそうです。

B. Database Server

続いてデータベースサーバーです。

データの永続化周りに関しても、GCP側で整理してくれてるものがあります。
https://cloud.google.com/products/databases/

いわゆるリレーショナル・データベースとしての選択肢はCloud SQLかCloud Spannerになってきます。

２つの違いは基本的にはスケーラビリティということで、中程度の規模までであればCloud SQL、高トラフィックをさばく必要があるならCloud Spannerという棲み分けのようです。

またCloud Spannerに関してはパフォーマンスを出すために一部設計の制約があり、MySQLやPostgreSQLとは違った形で設計しないといけないということで、SQLの選択肢に自由度がある場合に利用できそうです。

よほど高いトラフィックをさばく必要がなければ、まずはCloud SQLから入る形でしょうか。

GCP導入時点ではRailsの標準的なアプリケーションでMySQLを利用したかったため、Cloud SQLほぼ一択でした。

Cloud SQL

Cloud SQLはマネージドなMySQL/PostgreSQLサーバー(2019年11月時点ではSQL ServerもBeta版)です。
バージョンはMySQLであれば5.6 or 5.7など固定されてしまっていますが、その分面倒な設定やフェイルオーバーの処理などはすべてCloud SQL側でやってくれます。

レプリケーションも failover replica と 通常のread replicaの2種類が作れるようになっているため、概ねマネージドでやってくれることは大丈夫そうです。

パフォーマンスに関しては秒間数百qps程度だったら大丈夫ではあるみたいで、readが多い分に関してはreplicaで対応できるので、書き込みが多いアプリケーションでなければ動くようです。

リクエストがそれ以上の頻度になってくるとCloud Spannerにした方がいいということでした。
Google内部で使われていたということで、Googleくらいの規模になるとCloud SQLで耐えられるレベルではないということですかね。

ただ、Cloud Spannerは割と設計思想のところから違うので、単純にCloud SQLからパッと移行できるものではないようです。
なので、最初から規模が大きいと想定される場合はSpannerの利用を前提に調査をした方が良さそうです。

料金

Cloud SQLはMySQL系とPostgreSQL系で料金体系が少し違います。
MySQL系はインスタンスクラスに応じて決まるのに対し、PostgreSQLはCPU/メモリごとといった形になっています。

同じインスタンスクラスのスペックだとややMySQLの方が安いようですが、ほぼ違いはなさそうです。

マシンタイプ	仮想 CPU 数	RAM（GB）	最大ストレージ容量	最大接続数	料金（米ドル）	継続利用価格（米ドル）
db-f1-micro*	共有	0.6	3,062 GB	250	$0.0195	$0.0137
db-g1-small*	共有	1.7	3,062 GB	1,000	$0.0650	$0.0455
db-n1-standard-1	1	3.75	30,720 GB	4,000	$0.1255	$0.0878
db-n1-standard-2	2	7.5	30,720 GB	4,000	$0.2509	$0.1756
db-n1-standard-4	4	15	30,720 GB	4,000	$0.5018	$0.3513
db-n1-standard-8	8	30	30,720 GB	4,000	$1.0036	$0.6485
db-n1-standard-16	16	60	30,720 GB	4,000	$2.0079	$1.4055

db-f1-micro/db-g1-smallは本番用には使わない方がいいということで、db-n1-standard-1あたりから採用することになります。
また、データベースで基本はずっとつけっぱなしになっているかと思いますので、料金は継続利用価格を主に見ます。
ストレージは後で増やせるのでいいとして、db-n1-standard-1で\$0.0878/h(継続利用)ということで割とお安く使えると思います。

もちろんここにストレージとネットワークの値段がかかってきます。

ストレージ	料金
SSD	$0.22 per GB/month
HDD	$0.12 per GB/month
Backup	$0.10 per GB/month

ネットワーク出力先	料金
Compute Engine インスタンス	同じリージョン内: 無料
	北米内のリージョン間: \$0.12/GB 北米外のリージョン間: \$0.12/GB
Google プロダクト（Compute Engine を除く）	大陸内: 無料、大陸間: $0.12/GB
インターネット下り（Cloud Interconnect を使用する場合）	$0.05/GB
インターネット下り（Cloud Interconnect を使用しない場合）	$0.19/GB

AWSとの比較

フルマネージドなMySQLサーバーというとやはり Amazon Aurora ですね。
このあたりのフルマネージドサービスはAWSが先を行っている印象があります。

	時間あたりの料金
スタンダードインスタンス – 現行世代	リザーブド(1年)
db.t3.small	0.063USD
db.t3.medium	0.125USD

db.とついていますが、EC2とスペックが同じだとすると単純にスペックの違いが価格に現れている気がします。
もちろんAuroraも継続利用前提でリザーブド料金で考えると多少割安感はありますが、そこまで安いといった感じは受けません。

ストレージ・ネットワークは以下の料金です。

ストレージ料金	GB あたり月額料金 0.12USD
I/O 料金	100 万件のリクエストあたり 0.24USD

ストレージはHDDのCloud SQLと同額、IOは計測単位が違うので比較が難しいところですね。

いずれにせよDatabase周りは試算上大きな差は見られなさそうです。

NoSQL系

NoSQL系はCloud Bigtable, Cloud Firestore, Firebase Realtime Database, Cloud Memorystoreの4種類があり、それぞれ微妙に特徴が違っているようです。

なお、以前あったCloud DatastoreはCloud Firestoreに統合されたようです。

あとFirebase Realtime Databaseは当時あったかどうか覚えてません。Firestoreよろしく、Firebase関連はNatvieアプリで使われる場面が多いと思うので、サーバーサイド視点では見逃してる可能性が高いです。

このタイミングではキャッシュサーバーとしてNoSQLを採用を考えていたため、Cloud Memorystoreだけ調査しました。

Cloud Bigtable や Cloud Firestore はある程度構造化されたようなjson形式のようなデータを扱うのが得意なようでしょうか。ただその構造化度合いによって使い分けが発生するようです。

Cloud Memorystore

こちらはRedisのフルマネージドサービスです。Memoryと名乗っている通りインメモリでデータを扱ってくれるため高速です。
Redis自体は永続化も保証してくれると思いますが、GCPではインメモリと書いてあるので保証されてるか分かりません。
基本的にはキャッシュ用途として使うのが良さそうです。

自分がはじめに関わったプロダクトでは、railsのジョブ処理の仕組みであるsidekiqのキューとして考えていたのですが、

• ジョブは非同期なので、アプリケーション側もRedisの生存が必須ではない
• 最悪死んでても業務時間中に復帰できれば問題ないくらいのジョブしか存在しない
• やりたいことに対して値段が高い

ということで、結果としては最初のアプリケーションでの採用は見送り、GCEでredisサーバーを建てることとしました。
こういう場面ではインフラの手の数よりも費用を優先することもあります。

ただ、次に関わったプロダクトでは可用性の重要度が上がったため、Cloud Memorystoreをフル活用することとなりました。

料金

値段が高いと書きましたが、料金体系としてはこのような形になります。Basicは高可用性なし、スタンダードが高可用性ありということのようです。

サービス階層	容量階層	最大ネットワーク パフォーマンス	料金（米ドル、GB あたり/時間）
Basic	M1（1～4 GB）	3 Gbps	$0.065
	M2（5～10 GB）	3 Gbps	$0.040
	M3（11～35 GB）	3 Gbps	$0.032
	M4（36～100 GB）	6 Gbps	$0.024
	M5（100 GB 超）	12 Gbps	$0.019
スタンダード	M1（1～4 GB）	3 Gbps	$0.114
	M2（5～10 GB）	3 Gbps	$0.075
	M3（11～35 GB）	3 Gbps	$0.063
	M4（36～100 GB）	6 Gbps	$0.047
	M5（100 GB 超）	12 Gbps	$0.037

Cloud Memorystoreはこれまでのサービスとは異なり、確保した容量によって値段が決定されます。
高可用性があるなしで値段が倍くらい違いますが、高可用性なしで10GBの容量で\$0.4/hといった感じになってきます。

もちろん容量も重要な要素ですが、GCEでただredisを立ち上げる場合では\$0.1/hを切ってくるかと思いますので、そう考えると気軽に増やせない場所です。
最終的にはお値段との相談で、ここはマネージドでなくていいという判断になりました。

AWSとの比較

AWSでcache関連のマネージド・サービスとしては Amazon ElastiCache があります。
料金体系はこのようになっていて、こちらは今まで同様スペックベースの料金体系です。

キャッシュノードタイプ	vCPU	メモリ (GiB)	ネットワークパフォーマンス	時間あたりの料金	リザーブド(1年)
cache.t3.micro	2	0.5	最大 5 ギガビット	0.026USD	0.018USD
cache.t3.small	2	1.37	最大 5 ギガビット	0.052USD	0.035USD
cache.t3.medium	2	3.09	最大 5 ギガビット	0.103USD	0.071USD

こちらは容量ベースではないのでGCPよりは安くなりそうです。これくらいの価格なら普通に採用できそうですね。

C. Storage (GCS)

こちらはAWSのS3に相当する、何でもファイル置き場ですね。
GCPではCloud Storageがこちらに該当します。

マルチリージョンに配置ができたり、使う頻度に応じて料金を最適化できるなど一通り揃っている印象で、S3とほぼ違いを感じません。
実際使ってみると権限周りの細かい差異とかバージョニングとか、勝手が違うなーというところもありますが、この辺はAWSもGCPも拡張の過程で変わってくるところになるかなと思います。

ちなみにGCS単体でもファイルのホスティングができたりしますが、ちゃんとしたアプリケーションを組もうと思うとセキュリティで色々気になることが出てくるので、nginxを前段に置いたりそういう機能のあるCDNを配置したり、など必要になってきますね。

AWSだとAmazon CloudFrontとS3でその辺かんたんに設定できると聞いたので、まだGCSは(もしくは自分の情報が)遅れてるかもしれません。
そこがクリティカルポイントになるようであればGCPは選択できませんが、そこが分かれ目になるケースは多くはなさそうです。
ストレージに関してもGCPで十分そうです。

料金

Cloud Storageの料金は

• ストレージ
• ネットワーク使用量
• オペレーション使用量
• 取得と早期削除(nearline, coldlineのみ)

の4つからなっているようです。

ストレージは1GB1ヶ月あたり以下のような体系でした。

クラス	Asia マルチリージョン	東京リージョン
Standard Storage	$0.026	$0.023
Nearline Storage	$0.010	$0.016
Coldline Storage	$0.007	$0.006

ネットワークは1GBあたり以下のような料金です。アジアマルチリージョンでの料金で、リージョンを変えると少し料金が変わってきます。

月間使用量	下り送信先: 世界（アジア、オーストラリアを除く）	下り送信先: アジア（中国を除くが香港は含む）	下り送信先: 中国（香港を除く）	下り送信先: オーストラリア
0～1 TB	$0.12	$0.12	$0.23	$0.19
1～10 TB	$0.11	$0.11	$0.22	$0.18
10 TB～	$0.08	$0.08	$0.20	$0.15

オペレーション料金はさらに複雑で、バケットに対する操作によって課金額が変わってきます。

ただし、正直いうとS3でもそうですが、ストレージ系は普通のサービスでは価格の決定力を持たないほど小額になると思います。
動画を保存して配信するような容量をたくさん使うサービスでは重要になってくると思うので、サービスによって優先事項を変えながら調査するのが良さそうですね。

AWSとの比較

一応S3の料金体系も載せておくと、

ストレージ

	ストレージ料金表
最初の 50 TB/月	0.025USD/GB
次の 450 TB/月	0.024USD/GB
500 TB/月以上	0.023USD/GB

ネットワーク

	ネットワーク(下り)
1 GB まで/月	0.00USD/GB
次の 9.999 TB/月	0.114USD/GB
次の 40 TB/月	0.089USD/GB
次の 100 TB/月	0.086USD/GB
150 TB /月より大きい	0.084USD/GB

ということで、やはりややAWSの方が安いです。

ただ、ストレージに関してもプランの種類が多すぎて、全貌を把握するのが大変です。
作るプロダクト・アプリケーションの性質などをある程度決めてから調べていくのが効率良さそうですね。

調査を踏まえて

入社して最初の2週間程度時間をもらって色々調べさせてもらいましたが、意外とGCPも普通に動きそうという印象を持ちました。

費用は調べた当時はGCPの方が安いものもありましたが、改めて調べたらAWSの方が安くなってるケースも多いですね。
正直この辺はクラウド事業者間の競争もあって下がる傾向にはあるので、今後GCPがまた安くなっている未来もありそうです。

あとは記載があっても正しく動作するか実際に試してみないと分からないなーというところがあったり、多少機能が不足しても他で補える範囲なら自分の触れたことない技術を試してみたいな、ということでGCPで行くことにしました。

それにしてもGCPってサービスが全部青いアイコンで統一されてるのはなんでなんですかねー。見分けがつきにくい。

まとめ

ぶっちゃけGCPの情報整理で終わってしまいました。
後編では、導入後のGCPのあれこれについて共有しようと思います。

明日は、社内でエンジニア面のダークサイドに陥ると噂される、若手の@zawawahogeです！
お楽しみに。