Slide 1
Slide 1 text
スケーラビリティとコスト管理
Google Cloud Spanner
費用最適化の取り組み
株式会社 WFS
シニアエンジニア
結城 慎一郎
Slide 2
Slide 2 text
自己紹介
結城 慎一郎 (ゆうき しんいちろう)
株式会社WFS / ゲーム開発部 / Server Engineering グループ
シニアエンジニア
経歴
Webサービス会社から2013年グリー株式会社に入社。
Webゲーム開発を経て、スマホゲーム「消滅都市」のほか、複数の IPタイトルのゲームバックエンド開発を担
当。
2
Slide 3
Slide 3 text
はじめに
現在、株式会社WFSでは複数ゲームタイトルのインフラを
主に Google Cloud 上で構成・運用しております。
その知見に基づいた費用面についての話にフォーカスしています。
3
Slide 4
Slide 4 text
発表内容
1. Cloud Spanner の概要とTCO
2. Cloud Spanner 費用について
3. コンピューティングノード費用
4. ストレージ費用
5. ストレージ容量の最適化
6. コンピューティング費用の最適化
7. まとめ
4
Slide 5
Slide 5 text
Cloud Spanner の概要とTCO
5
Slide 6
Slide 6 text
Cloud Spanner の概要
● Google Cloud で提供されるリレーショナルデータベース
● フルマネージド
● ノード増減による高いスケーラビリティ
● ノード分散と強整合性の両立
● SQLが使用可能
○ Google Standard SQL
○ PostgreSQL
● 非常に高い99.99%のSLA(Service Level Agreement)
○ マルチリージョン構成なら 99.999%
6
Slide 7
Slide 7 text
Cloud Spanner の概要
● Google Cloud Platform (GCP)で提供するリレーショナルデータベース
● フルマネージド
● ノード増減による高いスケーラビリティ
● ノード分散と強整合性の両立
● SQLが使用可能 (GoogleSQL / PostgreSQL)
● 非常に高いSLA (99.99%)
○ マルチリージョン構成なら 99.999%
7
Slide 8
Slide 8 text
ノード増減による高いスケーラビリティ
● 処理負荷を各コンピュートノードに分散
● ダウンタイムなしにオンラインでノード増減が可能
● オートスケーラーを使えば常に最適なノード数に調整できる
8
instance
node1 node2 node3
Slide 9
Slide 9 text
コンピュートノードとストレージの分離
● 自動レプリケーション
● 自動シャーディング(水平分割)
● オンラインでスキーマ変更が可能
9
instance
node1 node2 node3
storage storage storage
Slide 10
Slide 10 text
管理コストを大幅に削減
TCO (Total Cost of Ownership) で考えることが大事
10
Total Cost
of
Ownership
導入
検証
構築
移行
維持
費用
習得
メンテ
作業
障害
復旧
サポート
セキュ
リティ
Slide 11
Slide 11 text
特に効果が大きかったこと
11
Slide 12
Slide 12 text
ノードの増減だけでスケールする
● ノード数を設定するだけ
● ノードの種類がなく構成がシンプルなので迷う箇所が少ない
○ メモリ・ディスク容量・ CPUコア数 などのスペック
○ サイズ別の単価
● 構築時の設計・レビューが不要
12
instance
node1 node2 node3 node4
Slide 13
Slide 13 text
自動レプリケーション
● ストレージが自動的にレプリケーション
● クラスタにレプリカを追加・削除する作業が不要
○ 関連するインフラチームとの作業依頼
○ 関連する台数見積も不要
13
Table A
Table B
Table A
Table B
Table A
Table B
Table A
Table B
Slide 14
Slide 14 text
自動シャーディング
● ストレージが自動シャーディング
● 分割アルゴリズムの設計不要
● 負荷による再分割・再統合も不要
○ インスタンスの追加・削除作業、レプリケーション作業も不要
14
user_100
user_104
user_101
user_105
user_102
user_106
user_103
user_107
Slide 15
Slide 15 text
Cloud Spanner 費用について
15
Slide 16
Slide 16 text
どこに費用がかかるのか？
Cloud Spannerは処理を行う
コンピュートノードと
ストレージが分離しているため、
費用は3つに分かれます。
16
instance
node1 node2 node3
storage storage storage
Slide 17
Slide 17 text
どこに費用がかかるのか？
Cloud Spannerは処理を行う
コンピュートノードと
ストレージが分離しているため、
費用は3つに分かれます。
1. コンピューティングノード
○ 処理ノード数
17
instance
node1 node2 node3
storage storage storage
Slide 18
Slide 18 text
どこに費用がかかるのか？
Cloud Spannerは処理を行う
コンピュートノードと
ストレージが分離しているため、
費用は3つに分かれます。
1. コンピューティングノード
○ 処理ノード数
2. ストレージ
○ 使用ストレージ容量
18
instance
node1 node2 node3
storage storage storage
Slide 19
Slide 19 text
どこに費用がかかるのか？
Cloud Spannerは処理を行う
コンピュートノードと
ストレージが分離しているため、
費用は3つに分かれます。
1. コンピューティングノード
○ 処理ノード数
2. ストレージ
○ 使用ストレージ容量
3. ネットワーク
※ネットワーク費用は通信量によるため今回取り上げません。
19
instance
node1 node2 node3
storage storage storage
Slide 20
Slide 20 text
コンピューティングノード費用
20
Slide 21
Slide 21 text
コンピューティングノード費用
処理ノード(ユニット)数×時間単位での従量課金
● 1ノード=1,000処理ユニット
● 1,000処理ユニット未満は100処理ユニット単位の利用が可能
● 1,000処理ユニット(1ノード)以降は1ノード単位の追加
21
Slide 22
Slide 22 text
コンピューティングノード費用
ある開発環境の例
● 800処理ユニットで稼働
● 複数タイトルが同一インスタンス上でデータベースを分けて運用中
22
Slide 23
Slide 23 text
コンピューティングノード費用
23
※2023年9月現在、146JPY/USDで算出
項目 単価 1ヶ月(30日)
コンピューティングノード (1ノード/時) $1.17 $842.4
¥122,990
例) 東京・シングルリージョンで1ノード利用した場合
100処理ユニットの場合、上記の 1/10単位での計算になります。
Slide 24
Slide 24 text
コンピューティングノード費用
確約利用割引(Committed use discounts / CUDs)
Committed use discounts | Cloud Spanner
● 確約値を設定することで割引になる
○ オートスケール時に最小になる数値を設定するとよい
○ 確約値の超過分についてはオンデマンド費用と同等
● 変更の可能性もあるので、詳しくは公式ドキュメントをご確認ください
24
Slide 25
Slide 25 text
コンピューティングノード費用
CPU 使用率の目安
https://cloud.google.com/spanner/docs/launch-checklist?hl=ja#ensure_monitoring_is_in_place
> シングルリージョン インスタンスでは 65% 未満
> マルチリージョン インスタンスでは 45% 未満に保つことをおすすめします。
パフォーマンスが劣化するので超えないようノード数を調整したほうがよい
25
※開発環境の例です
25
Slide 26
Slide 26 text
(おまけ) BigQueryの活用
ちょっとした調査等でアドホックにSpannerのデータが欲しいケース
● 簡単なものならバッチ作成などせず直接SQLを実行したい
● ただしConsole から SQLを実行する際に優先度を指定できない
26
Slide 27
Slide 27 text
(おまけ) BigQueryの活用
● 優先度を指定できないので結果的にCPU使用率が上昇する
● クエリ内容によっては事前にノード追加が必要な可能性
● BigQueryから優先度を指定してSpannerに対しSQLを実行できる
27
Slide 28
Slide 28 text
(おまけ) BigQueryの活用
BigQueryからEXTERNAL_QUERYで実行
https://cloud.google.com/bigquery/docs/cloud-spanner-federated-queries?hl=ja
● BigQueryからSpannerのデータを取得できる連携クエリ
● 優先度を指定できるので「低(low)」を指定する
28
SELECT * FROM EXTERNAL_QUERY(
"projects/***/locations/***/connections/***",
"SELECT * FROM gifts",
'{"query_execution_priority":"low"}'
)
BigQueryで実行するクエリ
Slide 29
Slide 29 text
(おまけ) Data Boost
https://cloud.google.com/spanner/docs/databoost/databoost-overview?hl=ja
● 既存のワークロードとは分離して影響を与えないというもの
● 独立したコンピューティングリソースを提供
● 登場する以前から使っているBigQueryから叩く方法で実施しています
○ Data Boost 自体は社内でも費用を含め試用中
29
Slide 30
Slide 30 text
ストレージ費用
30
Slide 31
Slide 31 text
項目 単価 1ヶ月
データベースストレージ (GB/月) $0.39 $399.36
¥58,306
バックアップストレージ (GB/月) $0.10 $102.4
¥14,950
ストレージ費用
31
※2023年9月現在、146JPY/USDで算出
例) 東京・シングルリージョン、1TBを使用した場合
Slide 32
Slide 32 text
ストレージの容量割当上限
● 1ノードごとに4TBの容量割当(上限)
● 100処理ユニット毎に409.6 GB(上限)
下記は開発環境の例
● 800処理ユニットなので、409.6GBx8=3,276.8GB (表示は3.2TB)
32
Slide 33
Slide 33 text
ストレージの容量割当上限
実は昨日(2023/10/12(木)) 公式ブログで新たな発表がありました
Cloud Spanner is now half the cost of Amazon DynamoDB, and with strong
consistency and single-digit ms latency
https://cloud.google.com/blog/products/databases/announcing-cloud-spanner-price-perform
ance-updates/?hl=en
● コンピュートで50%のスループット向上
● 1ノードごとに4TB→10TBの容量割当(上限)
● 数ヶ月以内に全ユーザーに展開する見込み
本資料は2023/10/13発表時点での4TBを前提にしております。ご了承下さい。
33
Slide 34
Slide 34 text
1. ノード(ユニット)あたりのストレージ容量に割り当て上限がある
2. ストレージ実使用量が割り当て上限を超えるとノードを増やす必要がある
3. 当然ながらストレージ使用量に加えてノードの費用も増える
ストレージ使用量が増えるとどうなる？
34
ノード数2・ストレージ容量上限 8TB・使用量 5TB
ノード数3・ストレージ容量上限 12TB・使用量 9TB
ノード追加分
Slide 35
Slide 35 text
実際に起きたケース
CPU使用率に余裕があるから
ノードを減らしたい。が…
ストレージ使用量が多いから
ノードが減らせない！
ストレージ起因でノードが増えると…
35
ノード数3・ストレージ容量上限 12TB・使用量 9TB
Slide 36
Slide 36 text
ストレージ起因でノードが減らせない
36
Slide 37
Slide 37 text
ストレージ容量の最適化
37
Slide 38
Slide 38 text
その1：セカンダリインデックスを見直す
STORING(GoogleSQL) /
INCLUDE(PostresSQL)の見直し
https://cloud.google.com/spanner/docs/secondary-indexes?hl=ja#s
toring-clause
● インデックスの格納データ列
● 余分な結合を防ぐ
● データ内容のコピーで容量を使う
● ユースケースを見直し、カラムを厳選する
38
Slide 39
Slide 39 text
その1：セカンダリインデックスを見直す
ユースケースを精査し、created_atの取得は不要だったため、除外した例
39
CREATE INDEX gifts_by_expiration
ON gifts (user_id, expired_at)
STORING (item_id, created_at);
https://cloud.google.com/spanner/docs/reference/standard-sql/data-definition-language#alter-index
ALTER INDEX gift_by_expiration
DROP STORED COLUMN created_at;
Slide 40
Slide 40 text
その2：PITR期間の見直し
Point In Time Recovery (PITR) とは
https://cloud.google.com/spanner/docs/pitr?hl=ja
すべてのデータとスキーマのすべてのバージョンを保持し、特定の時点に戻すことがで
きる機能です。最長で7日間のデータを保持することができます。
40
Slide 41
Slide 41 text
その2：PITR期間の見直し
● ステイル読み取りを使って特定の過去の時点でのデータを読み込める
● データベースストレージ上に保持している
● このため保持期間が長いほどストレージが必要
41
現在
1日前
2日前
3日前
4日前
5日前
6日前
7日前
例) 保持期間を7日間から4日間にしたイメージ
Slide 42
Slide 42 text
その3：TTLを設定する
テーブルに削除ポリシーを設定する事ができます。
https://cloud.google.com/spanner/docs/ttl/working-with-ttl?hl=ja
レコードの特定のTIMESTAMPカラムが保持日数を過ぎた場合に削除されます。
42
有効期限
2024-01-15T07:12:34.567890Z
2023-12-15T07:12:34.567890Z
2023-11-15T07:12:34.567890Z
2023-10-15T07:12:34.567890Z
2023-09-15T07:12:34.567890Z
Slide 43
Slide 43 text
その3：TTLを設定する
● バッチ処理を書かなくてもバックグラウンドで消してくれる
● 仕様として保持期限を設けられる場合に非常に有効
● テーブル設計時に意識しておくことで消しやすくできる
43
CREATE TABLE gifts (
user_id STRING(36) NOT NULL,
gift_id STRING(36) NOT NULL,
item_id INT64 NOT NULL,
expired_at TIMESTAMP NOT NULL
) PRIMARY KEY (user_id, gift_id),
ROW DELETION POLICY (OLDER_THAN(expired_at, INTERVAL 7 DAY));
例) expired_atカラムの日時が7日間を経過したら削除される giftsテーブル
Slide 44
Slide 44 text
その3：TTLを設定する
例) gifts テーブルの例
44
user_id gift_id item_id expired_at
7b9952c0-7a98-4c4b-b
033-036a05938dec
55711ba2-0723-4292-b
cf1-5182bcd8ac8f
101 2023-10-10T07:12:34.567890Z
ROW DELETION POLICY (OLDER_THAN(expired_at, INTERVAL 7 DAY));
このときはexpired_atの7日後以降、つまり
2023-10-17T07:12:34.567890Z 以降に削除されます。
Slide 45
Slide 45 text
その3：TTLを設定する
● 毎日バックグラウンドプロセスが起動しTTL対象レコードを削除する
○ 優先度は「低」で実行される
● 期限を過すぎれば即座に消えるわけではない
○ したがって「有効かどうか」は別途ロジックで保証する必要がある
● ミューテーション上限を超える量を削除する場合は小分けしてリトライ
● 詳しくはこちらの公式ブログを参照ください。
○ https://cloud.google.com/blog/products/spanner/reduce-costs-and-simplify-compl
iance-with-managed-ttl-in-spanner
45
Slide 46
Slide 46 text
その4：データを一時退避する
一定期間アクセスのないデータを別ストレージへ移動する。
※データベース・テーブル単位のエクスポート機能とは異なります。
46
Slide 47
Slide 47 text
その4：データを一時退避する
1. データをエクスポートしてGCSへアップロード
2. 「データ退避状態」として記録を残し、Cloud Spannerからデータを削除
3. 再度必要になった場合にGCSからダウンロードして復旧
47
アップロード
ダウンロード
「退避状態」
Slide 48
Slide 48 text
1. 該当ユーザーの対象データを取得
(SELECT)
2. JSON化してGCSへアップロード
3. 直後に念のためGCSからダウンロードして内容に問題ないか検証
4. 「退避済み」としてマークし基礎テーブル更新
5. 該当ユーザーの基礎テーブル以外の全データを削除
(DELETE)
実際にデータ退避したときの話
48
JSONアップロード
Slide 49
Slide 49 text
1. 該当ユーザーの対象データを取得
(SELECT)
2. JSON化してGCSへアップロード
3. 直後に念のためGCSからダウンロードして内容に問題ないか検証
4. 「退避済み」としてマークし基礎テーブル更新
5. 該当ユーザーの基礎テーブル以外の全データを削除
(DELETE)
実際にデータ退避したときの話
49
JSONアップロード
JSONダウンロード
Slide 50
Slide 50 text
1. 該当ユーザーの対象データを取得
(SELECT)
2. JSON化してGCSへアップロード
3. 直後に念のためGCSからダウンロードして内容に問題ないか検証
4. 「退避済み」としてマークし記録テーブル更新
5. 該当ユーザーの記録テーブル以外の全データを削除
(DELETE)
実際にデータ退避したときの話
50
JSONアップロード
JSONダウンロード
「退避状態」
全データ削除
Slide 51
Slide 51 text
一時退避による削除結果
● ストレージ使用量も20-30%程度削減に成功
○ ※多少の増減はイベントやキャンペーンによるものです
51
Slide 52
Slide 52 text
コンピューティング費用の最適化
52
Slide 53
Slide 53 text
● コンピューティング費用はノード数x単価x時間
○ 単価は確定利用割引で減る可能性がある
○ 時間は24時間提供するライブゲームにおいては停止できない
● ノード数を減らすのが費用を抑える最も有効な手段
○ 「ストレージ起因で減らせない」状態を回避する
○ CPU使用率が推奨値を上回らないようにする
とにかくノードを減らす
53
instance
node1 node2 node3 node4
Slide 54
Slide 54 text
オートスケーラー
弊社では「上げ下げくん」というツールを使って管理しています
Cloud Spanner をより便利にする運用支援ツールの紹介 / GREE Tech Conference 2021
● CPU使用率に上下範囲の閾値を設け、超えた場合に閾値に収まるよう増減
● イベントの開始時など指定スケジュールに合わせて予めノード数を増減
● ログインボーナスなどデイリーで想定される負荷に予めノード数を設定
● SpreadSheetで管理
54
Slide 55
Slide 55 text
オートスケーラー
Autoscaler tool for Cloud Spanner (公式)
https://cloud.google.com/spanner/docs/autoscaling-overview?hl=ja
● Cloud Functions や GKE 上で動く想定
● Monitoring API を監視(Polling) して台数増減。
Spanner Autoscaler (メルペイ様)
https://github.com/mercari/spanner-autoscaler
● Kubernetes Operator として Kubernetes上に構築される
● 同様に負荷に応じてノード数を増減。
● スケジュール設定も可
55
Slide 56
Slide 56 text
まとめ
56
Slide 57
Slide 57 text
まとめ
● 費用は TCO (Total Cost of Ownership)で考える
● TTLやオートスケーラー、BigQueryなど様々な手法でノード数を節約可能
● まずストレージ容量を抑えることが大事
57
Slide 58
Slide 58 text
58