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

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

5. Cloud Spanner の概要とTCO
   5
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

15. Cloud Spanner 費用について
    15
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View 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 Slide

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

    View Slide

30. ストレージ費用
    30
    

    View Slide

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

    View Slide

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

    View 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 Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View 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 Slide

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

    View Slide

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

    View 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 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 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 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 Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View 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 Slide

56. まとめ
    56
    

    View Slide

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

    View Slide

58. 58
    

    View Slide