Fantiaから学ぶgcp運用のノウハウ

Copyright 2021 Toranoana Inc.
Fantiaから学ぶ
GCP運用のノウハウ
植竹　惇
虎の穴ラボ株式会社
1

2
Twitterへのご投稿は、
#とらラボ1
でお願いします！
質問、感想・コメント等
※ LT内容に関する
ご質問はYoutubeコメントにお願いします🙏

名前：植竹　惇 
担当業務：Fantiaを始めとする 
　　　　　新規事業開発のマネジメントリーダー 
業務使用言語：Rails 
利用クラウド：GCP、AWS 
最も多くやったこと：Fantiaの負荷対策 
今のブーム：ニチアサ、面白WEB漫画、タイムリープヤンキー漫画 
前のブーム：スポーツ漫画（当の本人は運動できません） 
自己紹介 
3

目次 
 
1. これまでのFantiaの傾向推移 
 
1-1. ファンクラブ数の増加 
1-2. クリエイターカテゴリの変化 
 
2. 利用してきたGCP機能 
 
2-1. InstanceGroups 
2-2. CloudArmor 
2-3. CloudDNS 
2-4. Monitoring 
 
3. 今後利用していきたいGCP機能 
4
ここまでTechDay2と同じ

早速ですが 
5

世は支援プラットフォーム 
戦国時代 
6

7
海外
日本
現在
数年前
Patreon
Onlyfans
PIXIV FANBOX CAMPFIRE Community
note
Ci-en

8
現在の　　　　の立ち位置 
 
・わりと初期にサービスインしている古参 
 
・日本国内（のアダルト部分）で存在感を発揮 
 
・二次元、三次元ともに活発

9
　　　　のファンクラブ増加 
 
中の人も驚愕の 
増加ペース

10
　　　　のPV数増加 
 
1億PV超え！

参入クリエイターの傾向 
11

1年目：イラスト・漫画ファンクラブ中心の黎明期
 
 
 
2年目：3Dアニメ、MMD層の増加
 
 
 
3年目：コスプレイヤー層の増加
 
 
4年目：　　　　〃 
 
 
5年目：Youtuber、女性向け音声層の増加
 
12

現在のFantiaは 
 
（アダルト色が強く） 
幅広いクリエイター層を 
カバーする総合支援プラットフォーム 
13

そんなFantiaを5年間支えたクラウドインフラが 
 
『GCP』です 
14

15
利用しているGCP機能 
 
 
 
　　　　その１. InstanceGroups

16
Instance Groups 
 
 
 
　　　　 
ロードバランサに接続可能な、 
VMインスタンスの集合体。 
 
Kubernetesが登場する以前は 
主流となっていた 
オートスケール可能な 
マネージドサーバー。

17
Instance Groups 
 
 
 
　　　　 
今となっては当たり前だが… 
 
コンソール画面上で、 
サーバーの最小・最大台数を 
自由に設定できる。

18
Instance Groups 
 
 
 
　　　　 
インスタンスグループは、 
『インスタンステンプレート』 
から作成する。 
 
複数のサーバのデータ、スペックを
統一して作成するため、 
元となる設定が必要となる。

19
そんなインスタンスグループと 
内部で作れるVMインスタンスですが、 
 
利用してきてとある問題に 
遭遇しました

20
VMインスタンスのトラブル 
 
 
 
　　　　 
GCPのVMインスタンスは、 
現在「E2」「N2」「N2D」「N1」 
とCPUとメモリのパフォーマンスが 
異なるマシン設定を用意しています。 
 
現在は第2世代の利用が主流に 
なっているようなのですが……

21
 
 
 
　　　　 
インスタンスグループで 
VMインスタンス作成する途中、 
『作成中』の状態のまま止まってしまう 
ことがありました。 
この状態のまま、 
変化しない

22
 
 
 
　　　　 
原因1：アカウントにおけるリソースの予約枠が不足している。 
　アカウントごとに利用されているマシンのリソースは 
　制限されていて、解除のためには申請が必要。 
　IAMの『割り当て』ページで確認可能。

23
 
 
 
　　　　 
原因2：利用するリージョン全体で 
　対象のリソースが不足している。 
 
　この場合はアカウント関係なく、 
　追加の作成が不可能となる。 
 
　解決方法は 
　『リージョンを変える』または 
　『マシンタイプを変える』 
　のいずれか

24
これまでの運用で、 
どちらも経験しました。 
 
リージョン全体でのリソース制限は 
気をつけようがないですが、 
可能性としては十分ありえます。

25
 
 
 
　　　　　その2. CloudArmor

26
サービス規模とアクセスが増えてくると何が起きるか？

27
セキュリティリスクの増大

28
それを解決するのがCloudArmor

29
CloudArmor 
 
 
 
　　　　 
CloudArmorとは 
 
ロードバランサーと連携する 
かなり優秀な 
セキュリティサービス

30
CloudArmor 
 
 
 
　　　　 
CloudArmorが出来ること 
 
・個別でのIP制限設定 
 
・ルール設定による、アクセス攻撃へのWAF機能 
 
・Google本体も利用している自動DDoSフィルタ

31
CloudArmor 
 
 
 
　　　　 
WAFのルール設定について 
 
右の画像がルール追加のサンプル 
この場合は『sqli-stable』という 
SQLインジェクション防止の 
事前構成ルールの設定。 
 
2番目の引数は除外する 
詳細ルールを設定できる。

32
CloudArmor 
 
 
 
　　　　 
このような詳細ルールが定義されている。 
ルールに合致するアクセスを検知してブロックすることが可能。

33
だがちょっと待たれよ 
 
WAFで弾きたくないアクセスを 
弾いてしまう場合はないか？

34
プレビュー機能を使えば大丈夫

35
CloudArmor 
 
 
 
　　　　 
ルールの設定で 
 
『プレビューのみ』 
の設定を有効にすると、 
 
実際にブロックはせずに、 
ロードバランサーのログに 
『対象のアクセスであること』 
の検知のみ行える。

36
CloudArmor 
 
 
 
　　　　 
ロードバランサーの 
GCPロギングにて、 
 
右画像のような形式で 
記録される。 
 
『previewSecurityPolicy』 
の中身がプレビューで検知した 
内容の詳細となる。 
 
『preconfiguredExprIds』 
が実際に検知した詳細ルール。

37
プレビュー機能で 
安全性を確保してから 
適応することが可能 
①プレビューでWAFルールの設定
②数日稼動
③ログでプレビュー結果を確認
④アクセスに問題なければ
プレビュー無効

38
CloudArmor 
 
 
 
　　　　 
最後にDDoS防御です。 
 
ユーザ自身の設定は必要なく、
 
CloudArmorを設定するだけで、 
Googleが自動で検知し、 
知らぬうちに防いでくれます。 
 
ブロックのログもなく、 
詳細については不明。 
※画像引用元ページ  
https://cloud.google.com/blog/ja/products/gcp/getting-to-know-cloud-armor-d
efense-at-scale-for-internet-facing-services

39
GCPを利用している場合に限りますが 
『CloudArmor』は 
非常におすすめなサービスです。

40
 
 
 
　　　　　その3. CloudDNS

41
サービスの規模が大きくなると 
こう思う人は多いはず

42
AWS Auroraを使いたい！

43
AWS Auroraの利点 
 
・ディスクの容量を気にしなくて良い 
 
・リードDBのオートスケールが可能 
 
・複数のリードDBに対するDNSホストはひとつだけ

44
AWS Auroraの利点 
 
・ディスクの容量を気にしなくて良い 
 
・リードDBのオートスケールが可能 
 
・複数のリードDBに対するDNSホストはひとつだけ 
特に重要

45
Railsでプライマリ/リードDBの切り替え 
 
 
方法1：Rails6のマルチプルデータベース機能を使う 
 
方法2：SwitchPointなどのGemを利用する 
 
 
どちらもリードレプリカのロードバランシングには 
対応しきれてない。

46
AWSもGCPも複数のリードDBを作れるが、 
DBのリソース拡張で差が出てくる。 
primary
read-1 read-2
DNSホスト
アプリケーション処理
primary
read-1 read-2
DNSホスト-2
DNSホスト-1
AWS GCP

47
これを解決するのがCloudDNS

48
ロードバランシングの機能を持ち、 
CloudSQLとの接続が可能。 
 
つまりDNSラウンドロビンの機能を 
持っている。 
 
CloudDNSの接続先IPにアクセスすると 
ホスト1かホスト2のいずれかに 
振り分けてくれる。 
primary
read-1 read-2
DNSホスト-2
DNSホスト-1
GCP
CloudDNS
CloudDNS

49
CloudDNS 
レコードセットの設定 
GCP内のネットワークで使える
DNSホスト名
ロードバランシング先の内部 IP
CloudSQLのIPを設定できる

50
これでシームレスにリードDBでの 
負荷分散が可能になります

51
 
 
 
　　　　　その4. Monitoring

52
規模の大きいサービスには必須の監視機能 
 
GCPだと『Monitoring』がスタンダート

53
サーバーやDB、ロードバランサなど 
様々な機能の数値をグラフで可視化 
してくれる機能。 
 
監視できる値はかなり多彩なので、 
全容の把握はなかなか難しい…。 
Monitoring

54
特に便利だと思った 
メトリクス（計測指標）設定 
を紹介します

55
スロークエリ監視メトリクス  
 
●Resource type 
Cloud SQL Database  
 
●metric 
Logbytes 
 
●Filters 
log=mysql-slow.log  
 
CloudSQLのスロークエリログを  
監視する。 
 
クエリの量が多いとグラフが大きく  
上がったりするので、  
DBの負荷問題が検知しやすい。  
Monitoring

56
CloudArmorプレビュー監視メトリクス 
 
●Resource type 
Network Security Policy  
 
●metric 
Previewed request count  
 
●Filters 
blocked=true 
 
CloudArmorのプレビュー検知数を  
出力する。 
 
プレビューで引っかかったアクセスが  
どれくらいあるかを見るときに便利。  
実際にブロックした数も出せる。  
Monitoring

57
LBレイテンシー監視メトリクス 
 
●Resource type 
Load Balancing Rule  
 
●metric 
Backend latency 
 
●Filters 
backend_target_name=LBのバックエンド名 
 
ロードバランサーにおけるバックエンド側の  
レイテンシー（遅延時間）を見れる。  
 
負荷対策の結果や、機能開発での速度が  
変わっているかなどをチェックするときに  
重宝する。 
Monitoring

58
これらを駆使することで 
問題の検知や実績の計測が 
よりスムーズになりました

59
ここからはまだ実働していないですが 
今後導入してみたい機能の話です

60
今後利用していきたいGCP機能 
 
 
新しい何かを導入したい！ 
 
しかしFantiaは24時間稼動し続ける 
大規模なサービスで 
安定した稼動が求められる……

61
 
サービス開発・運用あるあるな欲求  
新しいインフラ機能を 
導入したい 
インフラ費用を 
削減したい 
開発効率を上げたい 
稼動可能な 
エンジニアの条件を 
増やしたくない 
デプロイを早くしたい 
障害を防ぎたい 
開発工数を 
最小限に

開発者が求めるもの
サービスオーナーが求めるもの
62
 
導入したい 
稼動可能な 
開発工数を 
最小限に 
削減したい

63
 
導入したい 
稼動可能な 
開発工数を 
最小限に 
新しい仕組みを導入するには、  
左側をある程度満たした上で  
実現する必要がある  
削減したい

64
 
 
 
新しい『何か』を導入したいだけでは 
動機としては不十分

65
 
導入したい 
稼動可能な 
開発工数を 
最小限に 
削減したい 
WinWinで最も重要

66
 
 
一部の処理だけを切り出して 
新しい機能を使いつつ 
障害予防を行いたい 
 
（できればコスト削減も）

67
 
① セッション保持しない外部からのREST API 
　ーアクセス頻度をコントロールしにくい 
 
　ー柔軟なオートスケールが必要だが、本体サービスとは切り離したい 
 
 
② 定期バッチ処理 
　ーバッチ処理がサービス拡大とともに増えてゆくリスク 
 
　ー単一サーバーだけで実施する場合はメモリ不足の懸念など

68
 
 
 
Cloud Runを使って 
これらを実現できないか

69
 
CloudRun　　とは 
 
GoogleKubernetesEngineと同様の 
コンテナ環境による 
オートスケールプラットフォーム 
 
Kubernetesベースのサービスではないため、 
Kubernetesの習熟が不要

70
 
確かめたいこと 
 
① RailsをCloudRunで稼働できるのか 
 
② GCEと同様のAPI動作を実現できるのか 
 
③ 定期バッチ処理を実現できるのか

71
 
やったこと 
 
① userデータを取得するサンプルアプリ作成 
 
② 上記アプリをDocker化 
 
③ 『Container Registry API』でイメージをプッシュ 
ここに関して
今回は省略

72
 
Container Registry APIにプッシュするには 
 
① gcloud auth configure-docker　で認証 
 
② docker build -t ローカルイメージ名 . 
でイメージ作成 
 
③ docker tag ローカルイメージ名ホスト名/プロジェクト名/イメージ名:タグ 
　　でタグ作成 
 
④ docker push ホスト名/プロジェクト名/イメージ名:タグ 
　　にてプッシュ

73
 
こんな形で、GCPのContainer Registryに保存されます

74
環境変数の設定 
 
 
アプリ構築において大事な要素
 
 
GUI上で項目が用意されており、
 
 
簡単に設定することができる。

75
Cloud SQLへの接続設定が可能 
 
他のGCPサービスに接続するには 
サーバーレスVPCコネクタが 
必要となる 
 
例： 
Cloud Run ⇒ Memorystore 
Cloud Run ⇒ Bigquery

76
設定をした上での 
デプロイは左記のような 
コマンドで実行が可能 
gcloud beta run deploy cloud-run-sample  
--image asia.gcr.io/サービス名/cloud_run_sample  
--add-cloudsql-instances cloud-run-sample-db  
--allow-unauthenticated  
--min-instances 1  
--region asia-northeast1  
--memory 512Mi  
--set-env-vars "  
RAILS_ENV=production,  
RACK_ENV=production,  
MYSQL_CONNECT=CloudProxyによるCloudSQL接続先, 
MYSQL_PASSWORD=DBパスワード,  
SECRET_KEY_BASE=Railsのシークレットキー  
"

77
Dockerの設定に応じて、 
URLのパスでそのままアクセスが可能。

78
CloudRun初期設定時に、 
トラフィックの設定を選べる。 
 
CloudLoadBalancingとの接続も 
可能なため、CloudArmorを経由して 
セキュアな構成にすることも可能。

79
 
構築してみて 
 
① 手順はかなりシンプルだが制限はいくつかある 
 
② 他のGCPサービスとの連携は個別に設定が必要 
 
③ 機能は徐々に増えているので、 
　今後活躍の幅は大きく広がりそう

80
 
一部のAPI処理をCloudRunに置き換える場合 
デメリット 
 
・GCP内のサービスを扱うのに  
　個別の設定が必要となる  
 
・アプリのサーバーに必要な鍵ファイルが  
　あれば渡し方を考える必要がある  
 
・マシンスペックの幅が広くない  
　最大が4vCPUのメモリ8GB  
メリット 
 
・オートスケールが楽  
 
・デプロイがかなり高速  
 
・リージョン障害があった場合でも  
　切り替えが容易 
 
・メンテナンスによる瞬断の心配がなくなる  
 
・前提知識が最小限なので、  
　GCP限定のガラパゴス技術にはなりにくい

81
 
 
 
 
 
CloudRunで定期バッチ 
を実行するにはどうすれば？

82
 
 
 
 
 
GCPの公式で『Cloud Scheduler』 
による方法を案内している 
参考：https://cloud.google.com/run/docs/triggering/using-scheduler?hl=j a

83
 
 
CloudRunはHTTPSでの公開しかできない 
よって以下の方法でタスク実行を実現 
 
① Cloud Schedulerでトリガーを設定 
 
② Scheduler内部でCloudRunのアクセスを実行 
 
③ 限定公開されているCloudRunが受信して処理を実行

84
Cloud Schedulerのジョブ作成画面です。  
 
 
CloudRunのURLを設定すればよいだけなので、  
かなり簡単です。 
 
ただしセキュリティリスクがあるので、  
HTTPヘッダーにトークンキーを設定したり、  
CloudRunでの受け取り側でスケジュールからの  
実行のみを受け付けるようにするなどの、  
対応が必要となります。

85
 
定期バッチをCloudRunに置き換える場合 
デメリット 
 
・セキュリティ対策をしっかりしないと危ない  
 
・CloudRunのタイムアウト時間が  
15分なので長時間稼動するバッチには  
　使えない 
 
・マシンスペックが限定的なので、  
　メモリを多く消費するようなバッチ作業は  
　不可能 
メリット 
 
・サーバー管理が楽に  
 
・デプロイがかなり高速  
 
・必要なリソースだけを適切に立ち上げるので  
　コスト削減につながる

86
 
 
 
 
 
APIも定期バッチもデメリット以上に、 
Cloud Runで実行するメリットがあるので、 
実用する価値はあるかと思います

本日のまとめ 
 
1. これまでのFantiaの傾向推移 
 
クリエイターはかなり増えてきており、時期によって増加の傾向が異なる  
 
2. 利用してきたGCP機能 
 
現在利用しているサーバー機能の「InstanceGroups」 
セキュリティに対する「CloudArmor」、 
負荷に対する「CloudDNS」「Monitoring」の使い方を紹介 
 
3. 今後利用していきたいGCP機能 
 
「CloudRun」を中心に、既に稼働しているサービスで使う方法を検証してみた 
87

Fantiaから学ぶgcp運用のノウハウ

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Fantiaから学ぶgcp運用のノウハウ

Similar to Fantiaから学ぶgcp運用のノウハウ (20)

More from 虎の穴開発室

More from 虎の穴開発室 (20)

Recently uploaded

Recently uploaded (20)