スケーラビリティとコスト管理 Google Cloud Spanner 費用最適化の取り組み

GREE Tech Conference 2023で発表された資料です。
https://techcon.gree.jp/2023/session/TrackB-2

Transcript

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