Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

gree_tech
October 13, 2023

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

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

gree_tech

October 13, 2023
Tweet

More Decks by gree_tech

Other Decks in Technology

Transcript

  1. スケーラビリティとコスト管理
    Google Cloud Spanner
    費用最適化の取り組み
    株式会社 WFS
    シニアエンジニア
    結城 慎一郎

    View full-size slide

  2. 自己紹介
    結城 慎一郎 (ゆうき しんいちろう)
    株式会社WFS / ゲーム開発部 / Server Engineering グループ
    シニアエンジニア
    経歴
    Webサービス会社から2013年グリー株式会社に入社。
    Webゲーム開発を経て、スマホゲーム「消滅都市」のほか、複数の IPタイトルのゲームバックエンド開発を担
    当。
    2

    View full-size slide

  3. はじめに
    現在、株式会社WFSでは複数ゲームタイトルのインフラを
    主に Google Cloud 上で構成・運用しております。
    その知見に基づいた費用面についての話にフォーカスしています。
    3

    View full-size slide

  4. 発表内容
    1. Cloud Spanner の概要とTCO
    2. Cloud Spanner 費用について
    3. コンピューティングノード費用
    4. ストレージ費用
    5. ストレージ容量の最適化
    6. コンピューティング費用の最適化
    7. まとめ
    4

    View full-size slide

  5. Cloud Spanner の概要とTCO
    5

    View full-size slide

  6. Cloud Spanner の概要
    ● Google Cloud で提供されるリレーショナルデータベース
    ● フルマネージド
    ● ノード増減による高いスケーラビリティ
    ● ノード分散と強整合性の両立
    ● SQLが使用可能
    ○ Google Standard SQL
    ○ PostgreSQL
    ● 非常に高い99.99%のSLA(Service Level Agreement)
    ○ マルチリージョン構成なら 99.999%
    6

    View full-size slide

  7. Cloud Spanner の概要
    ● Google Cloud Platform (GCP)で提供するリレーショナルデータベース
    ● フルマネージド
    ● ノード増減による高いスケーラビリティ
    ● ノード分散と強整合性の両立
    ● SQLが使用可能 (GoogleSQL / PostgreSQL)
    ● 非常に高いSLA (99.99%)
    ○ マルチリージョン構成なら 99.999%
    7

    View full-size slide

  8. ノード増減による高いスケーラビリティ
    ● 処理負荷を各コンピュートノードに分散
    ● ダウンタイムなしにオンラインでノード増減が可能
    ● オートスケーラーを使えば常に最適なノード数に調整できる
    8
    instance
    node1 node2 node3

    View full-size slide

  9. コンピュートノードとストレージの分離
    ● 自動レプリケーション
    ● 自動シャーディング(水平分割)
    ● オンラインでスキーマ変更が可能
    9
    instance
    node1 node2 node3
    storage storage storage

    View full-size slide

  10. 管理コストを大幅に削減
    TCO (Total Cost of Ownership) で考えることが大事
    10
    Total Cost
    of
    Ownership
    導入
    検証
    構築
    移行
    維持
    費用
    習得
    メンテ
    作業
    障害
    復旧
    サポート
    セキュ
    リティ

    View full-size slide

  11. 特に効果が大きかったこと
    11

    View full-size slide

  12. ノードの増減だけでスケールする
    ● ノード数を設定するだけ
    ● ノードの種類がなく構成がシンプルなので迷う箇所が少ない
    ○ メモリ・ディスク容量・ CPUコア数 などのスペック
    ○ サイズ別の単価
    ● 構築時の設計・レビューが不要
    12
    instance
    node1 node2 node3 node4

    View full-size slide

  13. 自動レプリケーション
    ● ストレージが自動的にレプリケーション
    ● クラスタにレプリカを追加・削除する作業が不要
    ○ 関連するインフラチームとの作業依頼
    ○ 関連する台数見積も不要
    13
    Table A
    Table B
    Table A
    Table B
    Table A
    Table B
    Table A
    Table B

    View full-size slide

  14. 自動シャーディング
    ● ストレージが自動シャーディング
    ● 分割アルゴリズムの設計不要
    ● 負荷による再分割・再統合も不要
    ○ インスタンスの追加・削除作業、レプリケーション作業も不要
    14
    user_100
    user_104
    user_101
    user_105
    user_102
    user_106
    user_103
    user_107

    View full-size slide

  15. Cloud Spanner 費用について
    15

    View full-size slide

  16. どこに費用がかかるのか?
    Cloud Spannerは処理を行う
    コンピュートノードと
    ストレージが分離しているため、
    費用は3つに分かれます。
    16
    instance
    node1 node2 node3
    storage storage storage

    View full-size slide

  17. どこに費用がかかるのか?
    Cloud Spannerは処理を行う
    コンピュートノードと
    ストレージが分離しているため、
    費用は3つに分かれます。
    1. コンピューティングノード
    ○ 処理ノード数
    17
    instance
    node1 node2 node3
    storage storage storage

    View full-size slide

  18. どこに費用がかかるのか?
    Cloud Spannerは処理を行う
    コンピュートノードと
    ストレージが分離しているため、
    費用は3つに分かれます。
    1. コンピューティングノード
    ○ 処理ノード数
    2. ストレージ
    ○ 使用ストレージ容量
    18
    instance
    node1 node2 node3
    storage storage storage

    View full-size slide

  19. どこに費用がかかるのか?
    Cloud Spannerは処理を行う
    コンピュートノードと
    ストレージが分離しているため、
    費用は3つに分かれます。
    1. コンピューティングノード
    ○ 処理ノード数
    2. ストレージ
    ○ 使用ストレージ容量
    3. ネットワーク
    ※ネットワーク費用は通信量によるため今回取り上げません。
    19
    instance
    node1 node2 node3
    storage storage storage

    View full-size slide

  20. コンピューティングノード費用
    20

    View full-size slide

  21. コンピューティングノード費用
    処理ノード(ユニット)数×時間単位での従量課金
    ● 1ノード=1,000処理ユニット
    ● 1,000処理ユニット未満は100処理ユニット単位の利用が可能
    ● 1,000処理ユニット(1ノード)以降は1ノード単位の追加
    21

    View full-size slide

  22. コンピューティングノード費用
    ある開発環境の例
    ● 800処理ユニットで稼働
    ● 複数タイトルが同一インスタンス上でデータベースを分けて運用中
    22

    View full-size slide

  23. コンピューティングノード費用
    23
    ※2023年9月現在、146JPY/USDで算出
    項目 単価 1ヶ月(30日)
    コンピューティングノード (1ノード/時) $1.17 $842.4
    ¥122,990
    例) 東京・シングルリージョンで1ノード利用した場合
    100処理ユニットの場合、上記の 1/10単位での計算になります。

    View full-size slide

  24. コンピューティングノード費用
    確約利用割引(Committed use discounts / CUDs)
    Committed use discounts | Cloud Spanner
    ● 確約値を設定することで割引になる
    ○ オートスケール時に最小になる数値を設定するとよい
    ○ 確約値の超過分についてはオンデマンド費用と同等
    ● 変更の可能性もあるので、詳しくは公式ドキュメントをご確認ください
    24

    View full-size slide

  25. コンピューティングノード費用
    CPU 使用率の目安
    https://cloud.google.com/spanner/docs/launch-checklist?hl=ja#ensure_monitoring_is_in_place
    > シングルリージョン インスタンスでは 65% 未満
    > マルチリージョン インスタンスでは 45% 未満に保つことをおすすめします。
    パフォーマンスが劣化するので超えないようノード数を調整したほうがよい
    25
    ※開発環境の例です
    25

    View full-size slide

  26. (おまけ) BigQueryの活用
    ちょっとした調査等でアドホックにSpannerのデータが欲しいケース
    ● 簡単なものならバッチ作成などせず直接SQLを実行したい
    ● ただしConsole から SQLを実行する際に優先度を指定できない
    26

    View full-size slide

  27. (おまけ) BigQueryの活用
    ● 優先度を指定できないので結果的にCPU使用率が上昇する
    ● クエリ内容によっては事前にノード追加が必要な可能性
    ● BigQueryから優先度を指定してSpannerに対しSQLを実行できる
    27

    View full-size slide

  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で実行するクエリ

    View full-size slide

  29. (おまけ) Data Boost
    https://cloud.google.com/spanner/docs/databoost/databoost-overview?hl=ja
    ● 既存のワークロードとは分離して影響を与えないというもの
    ● 独立したコンピューティングリソースを提供
    ● 登場する以前から使っているBigQueryから叩く方法で実施しています
    ○ Data Boost 自体は社内でも費用を含め試用中
    29

    View full-size slide

  30. ストレージ費用
    30

    View full-size slide

  31. 項目 単価 1ヶ月
    データベースストレージ (GB/月) $0.39 $399.36
    ¥58,306
    バックアップストレージ (GB/月) $0.10 $102.4
    ¥14,950
    ストレージ費用
    31
    ※2023年9月現在、146JPY/USDで算出
    例) 東京・シングルリージョン、1TBを使用した場合

    View full-size slide

  32. ストレージの容量割当上限
    ● 1ノードごとに4TBの容量割当(上限)
    ● 100処理ユニット毎に409.6 GB(上限)
    下記は開発環境の例
    ● 800処理ユニットなので、409.6GBx8=3,276.8GB (表示は3.2TB)
    32

    View full-size slide

  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

    View full-size slide

  34. 1. ノード(ユニット)あたりのストレージ容量に割り当て上限がある
    2. ストレージ実使用量が割り当て上限を超えるとノードを増やす必要がある
    3. 当然ながらストレージ使用量に加えてノードの費用も増える
    ストレージ使用量が増えるとどうなる?
    34
    ノード数2・ストレージ容量上限 8TB・使用量 5TB
    ノード数3・ストレージ容量上限 12TB・使用量 9TB
    ノード追加分

    View full-size slide

  35. 実際に起きたケース
    CPU使用率に余裕があるから
    ノードを減らしたい。が…
    ストレージ使用量が多いから
    ノードが減らせない!
    ストレージ起因でノードが増えると…
    35
    ノード数3・ストレージ容量上限 12TB・使用量 9TB

    View full-size slide

  36. ストレージ起因でノードが減らせない
    36

    View full-size slide

  37. ストレージ容量の最適化
    37

    View full-size slide

  38. その1:セカンダリインデックスを見直す
    STORING(GoogleSQL) /
    INCLUDE(PostresSQL)の見直し
    https://cloud.google.com/spanner/docs/secondary-indexes?hl=ja#s
    toring-clause
    ● インデックスの格納データ列
    ● 余分な結合を防ぐ
    ● データ内容のコピーで容量を使う
    ● ユースケースを見直し、カラムを厳選する
    38

    View full-size slide

  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;

    View full-size slide

  40. その2:PITR期間の見直し
    Point In Time Recovery (PITR) とは
    https://cloud.google.com/spanner/docs/pitr?hl=ja
    すべてのデータとスキーマのすべてのバージョンを保持し、特定の時点に戻すことがで
    きる機能です。最長で7日間のデータを保持することができます。
    40

    View full-size slide

  41. その2:PITR期間の見直し
    ● ステイル読み取りを使って特定の過去の時点でのデータを読み込める
    ● データベースストレージ上に保持している
    ● このため保持期間が長いほどストレージが必要
    41
    現在
    1日前
    2日前
    3日前
    4日前
    5日前
    6日前
    7日前
    例) 保持期間を7日間から4日間にしたイメージ

    View full-size slide

  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

    View full-size slide

  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テーブル

    View full-size slide

  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 以降に削除されます。

    View full-size slide

  45. その3:TTLを設定する
    ● 毎日バックグラウンドプロセスが起動しTTL対象レコードを削除する
    ○ 優先度は「低」で実行される
    ● 期限を過すぎれば即座に消えるわけではない
    ○ したがって「有効かどうか」は別途ロジックで保証する必要がある
    ● ミューテーション上限を超える量を削除する場合は小分けしてリトライ
    ● 詳しくはこちらの公式ブログを参照ください。
    ○ https://cloud.google.com/blog/products/spanner/reduce-costs-and-simplify-compl
    iance-with-managed-ttl-in-spanner
    45

    View full-size slide

  46. その4:データを一時退避する
    一定期間アクセスのないデータを別ストレージへ移動する。
    ※データベース・テーブル単位のエクスポート機能とは異なります。
    46

    View full-size slide

  47. その4:データを一時退避する
    1. データをエクスポートしてGCSへアップロード
    2. 「データ退避状態」として記録を残し、Cloud Spannerからデータを削除
    3. 再度必要になった場合にGCSからダウンロードして復旧
    47
    アップロード
    ダウンロード
    「退避状態」

    View full-size slide

  48. 1. 該当ユーザーの対象データを取得
    (SELECT)
    2. JSON化してGCSへアップロード
    3. 直後に念のためGCSからダウンロードして内容に問題ないか検証
    4. 「退避済み」としてマークし基礎テーブル更新
    5. 該当ユーザーの基礎テーブル以外の全データを削除
    (DELETE)
    実際にデータ退避したときの話
    48
    JSONアップロード

    View full-size slide

  49. 1. 該当ユーザーの対象データを取得
    (SELECT)
    2. JSON化してGCSへアップロード
    3. 直後に念のためGCSからダウンロードして内容に問題ないか検証
    4. 「退避済み」としてマークし基礎テーブル更新
    5. 該当ユーザーの基礎テーブル以外の全データを削除
    (DELETE)
    実際にデータ退避したときの話
    49
    JSONアップロード
    JSONダウンロード

    View full-size slide

  50. 1. 該当ユーザーの対象データを取得
    (SELECT)
    2. JSON化してGCSへアップロード
    3. 直後に念のためGCSからダウンロードして内容に問題ないか検証
    4. 「退避済み」としてマークし記録テーブル更新
    5. 該当ユーザーの記録テーブル以外の全データを削除
    (DELETE)
    実際にデータ退避したときの話
    50
    JSONアップロード
    JSONダウンロード
    「退避状態」
    全データ削除

    View full-size slide

  51. 一時退避による削除結果
    ● ストレージ使用量も20-30%程度削減に成功
    ○ ※多少の増減はイベントやキャンペーンによるものです
    51

    View full-size slide

  52. コンピューティング費用の最適化
    52

    View full-size slide

  53. ● コンピューティング費用はノード数x単価x時間
    ○ 単価は確定利用割引で減る可能性がある
    ○ 時間は24時間提供するライブゲームにおいては停止できない
    ● ノード数を減らすのが費用を抑える最も有効な手段
    ○ 「ストレージ起因で減らせない」状態を回避する
    ○ CPU使用率が推奨値を上回らないようにする
    とにかくノードを減らす
    53
    instance
    node1 node2 node3 node4

    View full-size slide

  54. オートスケーラー
    弊社では「上げ下げくん」というツールを使って管理しています
    Cloud Spanner をより便利にする運用支援ツールの紹介 / GREE Tech Conference 2021
    ● CPU使用率に上下範囲の閾値を設け、超えた場合に閾値に収まるよう増減
    ● イベントの開始時など指定スケジュールに合わせて予めノード数を増減
    ● ログインボーナスなどデイリーで想定される負荷に予めノード数を設定
    ● SpreadSheetで管理
    54

    View full-size slide

  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

    View full-size slide

  56. まとめ
    ● 費用は TCO (Total Cost of Ownership)で考える
    ● TTLやオートスケーラー、BigQueryなど様々な手法でノード数を節約可能
    ● まずストレージ容量を抑えることが大事
    57

    View full-size slide