今すぐ利益に直結する！ Google Cloud のクラウドコスト最適化の実践事例紹介！

GREE Tech Conference 2024で発表された資料です。
https://techcon.gree.jp/2024/session/TrackC-5

Transcript

1. 今すぐ利益に直結する！ 
 Google Cloud のクラウドコスト最適化の 
 実践事例紹介 
 REALITY株式会社 エンジニア 久山貴大

2. 久山 貴大
 2018年 グリー 入社
 2020年 REALITY に転部
 2023年 REALITY内のDevOpsチームとして活動開始
 REALITY株式会社 
 DevOpsチームエンジニアマネージャー
 2
3. アジェンダ 
 • REALITY について 
 • 利益を生む、とは 
 • コストの分析 
 • 効果の大きかったコスト削減施策 
 • まとめ
 3
4. アジェンダ 
 • REALITY について 
 • 利益を生む、とは 
 • コストの分析 
 • 効果の大きかったコスト削減施策 
 • まとめ
 4
5. REALITY について 
 5
6. REALITY 
 6 スマホひとつでアバター作成、ライブ配信による交流やゲームなどが楽しめる、スマホ向けメタバース 

8. アジェンダ 
 • REALITY について 
 • 利益を生む、とは 
 • コストの分析 
 • 効果の大きかったコスト削減施策 
 • まとめ
 8
9. 利益を生む、とは 
 9
10. サービスの継続のためには、利益を出していく必要がある 
 利益を生む、とは 
 10
11. 11 利益を生む魔法の方程式
12. 12 利益 = 収入 - 支出
13. 収入の増やし方はサービスによってまちまちで、アプローチもまちまち 
 
 今日の話のターゲットではない 
 収入を増やすには・・・？ 
 13
14. 利益を生むには、支出を減らせば良い ！
 
 サービスの継続には、常に固定費がかかり続ける 
 人件費、外注費、サーバー費、 etc... 
 じゃぁ、利益を生むには・・・？ 
 14
15. このうちクラウドコストに絞って、支出を減らすためのプロジェクトが発足した！ 
 コスト削減プロジェクト発足！ 
 15
16. REALITY では、本プロジェクトによって以前 Google Cloud にかかっていたコストのうち、 
 1000万円以上 を削減することに成功しました！ 
 クラウドコストを減らす 
 16
17. アジェンダ 
 • REALITY について 
 • 利益を生む、とは 
 • コストの分析 
 • 効果の大きかったコスト削減施策 
 • まとめ
 17
18. コストの分析 
 18
19. より効果の高い削減を行うには？ 
 効率的にクラウドコストの削減を行うためには、 
 まずどこにお金がかかっているか を調べる必要がある 
 
 月々 2,3 万円しかかかっていないようなところを削減したところで削減額はたかがしれているが、 
 月々100万円かかっているような箇所を削減すれば、数10万の削減が見込めることも 
 19
20. Google Cloud の費用レポート 
 20 Google Cloud では費用レポートを見ることで、 
 どのサービス・SKUにどのくらいお金がかかっているかすぐに見ることができる 
 23年4月のデータ 

21. SKU とは？ 
 21 Google Cloud の各サービスにかかる料金をさらに細分化したもの 
 
 
 例えば、オンラインストレージである Cloud Storage にかかる料金は 
 
 ・データを保存し続けることでかかるストレージ料金 
 ・データへのアクセス数に応じてかかる料金 
 ・データ属性変更などに応じてかかる料金 
 
 などに細分化される 
 これらそれぞれが個別の SKU として計上される 

22. Google Cloud の費用レポート 
 22 費用削減プロジェクトでも、 
 この費用レポートに従い、コストがかかっている箇所から削減に取り組んで行った 

23. アジェンダ 
 • REALITY について 
 • 利益を生む、とは 
 • コストの分析 
 • 効果の大きかったコスト削減施策 
 • まとめ
 23
24. 効果の大きかったコスト削減施策 
 24
25. 25 ココ！

26. Cloud Storage 内に保存されている 
 配信アーカイブのストレージクラスを変更 
 26
27. Standard Storage Tokyo って 
 どこにかかっているお金？ 
 Google Cloud Storage の（東京リージョンの）バケットに保存されている 
 Standard クラスのオブジェクトのデータ量の合計 に応じてかかる費用 
 
 保存されてるデータ量 * 保存期間 で費用がかかる 
 27 Cloud Storage 

28. Cloud Storage 内に保存されている 
 配信アーカイブのストレージクラスを変更 
 REALITY では、Cloud Storage に今までアプリ上で行われた 
 配信の生データがアーカイブとして保存されており、全部で 1PiB を超えていた 
 
 これらのデータは、通報等があった際に監査を行うために保存されている 
 
 つまり、ほとんどのデータは一度保存された後は 
 アクセスされることがない 
 
 なのに、これらのデータは Standard ストレージクラス として
 保存されてしまっていた
 28
29. ストレージクラスとは？ 
 Cloud Storage に保存される全てのデータ（オブジェクト）には、 
 必ずストレージクラスが設定されている 
 
 ストレージクラスは Standard, Nearline, Coldline, Archived の４種類 
 
 後ろに行くほど、アクセス頻度の少ないデータの保存に適している 
 ・データの保存にかかる金額： Standard > Nearline > Coldline > Archived 
 ・データのアクセスにかかる金額：Standard < Nearline < Coldline < Archived 
 29
30. Cloud Storage 内に保存されている 
 配信アーカイブのストレージクラスを変更 
 これらのデータのストレージクラスを Coldline に変更した 
 
 また、これらのデータについては保存された後、 
 数日経ったらストレージクラスを Coldline に変更するように 
 バケットにライフサイクルの設定を行った 
 
 （対象のバケットのライフサイクル→ルールを追加 
 アクション：ストレージクラスを Coldline に設定する 
 オブジェクト条件の選択：経過日数 を設定） 
 30
31. Cloud Storage 内に保存されている 
 配信アーカイブのストレージクラスを変更 
 注意事項として、ストレージクラスの変更 にも料金がかかる ことに注意
 
 このストレージクラスの変更は、「クラスAオペレーション」として扱われる 
 厄介なのは、この「クラスAオペレーション」はオブジェクト1つ1つに対してかかる 
 つまり、オブジェクト数に比例したコストがかかる 
 
 一方、オブジェクトの保存のコストは、 
 どのストレージクラスでも オブジェクトのデータ量 に比例してかかる
 
 つまり、オブジェクト1つ1つのデータ量が極端に小さい場合、 
 ストレージクラスの変更コストを回収するのに時間がかかる ので注意！
 （幸い、配信アーカイブはオブジェクト1つあたりのデータ量が大きかった） 
 31
33. Cloud SQL インスタンスの使用量削減 
 33
34. この3つってどこにかかっているお金？ 
 Cloud SQL for MySQL で利用した CPU、memory の量に応じてかかるお金 
 
 Cloud SQL は自動でスケーリングしない ので、
 インスタンスごとに設定したCPUスペック、メモリスペックに応じて 毎月ほぼ定額でかかってくる
 
 34 Cloud SQL 

35. 複数の対策を組み合わせて、Cloud SQL の CPU利用量、 memory 使用量を最適化していった 
 
 • DBフラグを調整することによる、 パフォーマンスチューニング 
 ◦ 具体的な設定は省略
 • DBのスペック設定時の基準の変更 
 ◦ REALITYでは元々、過剰気味にスペックが盛られていた（平時のCPU利用率 10 ~ 15 % を目標）
 • インデックスの見直し 
 ◦ ユーザ検索のために 全文検索インデックス を検索用DBに貼る、等
 Cloud SQL インスタンスの設定最適化 
 
 35
36. 36 ココ！

37. BigQuery へのレコードの出力の経路を変更 
 37
38. Log Storage Cost って 
 どこにかかっているお金？ 
 Google Cloud 上の各サービスが出力したログを Cloud Logging 上に保存する際にかかる費用 
 （このログは、30日間無料で保存され、検索も無料） 
 
 保存したログのデータ量に比例して課金される 
 38 Cloud Logging 

39. サーバから出力している行動ログのデータを、 
 REALITYでは元々以下のような経路で出力していた 
 BigQuery へのレコードの出力の経路を変更 
 39 サービス群 GKE Cloud Logging Pub/Sub Dataflow BigQuery 行動ログを出力 
 ログルーターで 
 抽出
 ジョブを起動 
 保存

40. サーバから出力している行動ログのデータを、 
 REALITYでは元々以下のような経路で出力していた 
 BigQuery へのレコードの出力の経路を変更 
 40 サービス群 GKE Cloud Logging Pub/Sub Dataflow BigQuery 行動ログを出力 
 ログルーターで 
 抽出
 ジョブを起動 
 保存
 ここにお金が 
 かかっていた 

41. サービス群から Pub/Sub に直接データを出力することで、Cloud Logging への出力を不要に 
 BigQuery へのレコードの出力の経路を変更 
 41 サービス群 GKE Pub/Sub Dataflow BigQuery ジョブを起動 
 保存
 直接出力

42. サービス群から Pub/Sub に直接データを出力することで、Cloud Logging への出力を不要に 
 BigQuery へのレコードの出力の経路を変更 
 42 サービス群 GKE Pub/Sub Dataflow BigQuery ジョブを起動 
 保存
 直接出力
 Cloud Logging への出力が無くなった分、料金を削減！ 

43. Cloud Logging へ保存していたログの一部を BigQuery へ保存 
 
 43
44. REALITYでは、ユーザからの API アクセスごとに必ず Cloud Logging にログを出力していた 
 
 これらのログは、障害時の調査や、新機能リリース時の監視に利用されている 
 Cloud Logging へ保存していたログの一部を BigQuery へ 保存
 44 GKE 
 ユーザ
 Cloud Logging 
 APIアクセス 
 アクセスログ出力 

45. しかし逆に言えば、
 リリース時以外での正常系のログは、ほとんど利用されない 
 Cloud Logging へ保存していたログの一部を BigQuery へ 保存
 45 GKE 
 ユーザ
 Cloud Logging 
 APIアクセス 
 （正常系）
 アクセスログ出力 
 このログはほとんど利用されない 

46. リリース時以外でのログのうち、 
 正常系のAPIアクセスのほとんどを BigQuery上に保存することに
 （障害調査のために、全ログの保存は従来通り行う） 
 Cloud Logging へ保存していたログの一部を BigQuery へ 保存
 46 GKE 
 ユーザ
 Cloud Logging 
 APIアクセス 
 （正常系）
 アクセスログ出力 
 BigQuery 

47. また、BigQuery に保存したログの参照性をできるだけ落とさないように、 
 Cloud Logging ライクにアクセスログを検索できる機能を内部ツール上で実装 
 BigQuery に保存したログの参照性を強化 
 47
48. 48 配信音声アーカイブのエンコードを 
 監査時のみに 
 ココ！

49. 配信音声アーカイブのエンコードを 
 監査時のみに 
 49
50. vCPU Time Streaming Japan って 
 どこにかかっているお金？ 
 Dataflow ジョブで利用される 
 Dataflow ワーカー で消費したCPU 量 に応じてかかる料金 
 
 要は、Dataflow を使えば使うだけかかる料金 
 50 Dataflow 

51. 配信音声アーカイブの生成エンコードを、監査時のみに 
 全ての配信の音声データは Dataflow を通して生データから ogg 形式にエンコードして保存されていた（生 データとエンコード後の音声データ、2つのデータが保存されていた） 
 エンコードされた音声データは、通報があった際にのみ利用される 
 一方、通報がなければこれらの音声データが利用されることは稀 
 
 つまり、通報されていない音声データを エンコードする必要はなかった 
 
 
 51
52. 配信音声アーカイブの生成エンコードを、監査時のみに 
 音声データの ogg 形式へのエンコードを 
 全ての配信に対して行うのではなく通報の際に オンデマンドで行うように
 
 エンコードされた音声データは、監査ツールから参照可能 
 52 不適切な配信を通報 
 監査ツール エンコードジョブ Dataflow ジョブを起動 
 配信生データ Cloud Storage 音声データ (ogg) Cloud Storage エンコード
 参照
 ユーザ
 エンコード後、 
 数日で削除される 

53. 53 ココ！

54. 配信中のデータのやり取りに 
 利用するリージョンを増設 
 
 54
55. Network Internet Data Transfer Out From A to B ってど こにかかっているお金？ 
 Google Cloud 上の VPC から外部に向かってのデータ転送 にかかる料金 
 転送したデータのデータ量に比例して課金される 
 
 REALITY では、配信中に GKE 上のサーバを経由した Websocket 通信で 
 配信者から視聴者に転送されるモーション・音声データのデータ量が特に多い 
 55 GKE 
 配信者
 Websocket 通信 
 視聴者
 Websocket 通信 
 ここの通信量にかかる料金 

56. APAC ってどの地域？ 
 56 アジア太平洋地域 (Asia Pacific) のこと 
 
 REALITYではこの地域からの利用者が多い 
 
 

57. Japan to APAC のデータ転送 
 57 REALITY では、配信中のデータのやり取りの中継サーバを 
 日本 と 北アメリカ に立てていた

58. Japan to APAC のデータ転送 
 58 APAC地域のユーザへの配信中のデータ転送では、基本的に日本のサーバを経由していた 
 

59. シンガポールリージョンに配信用サーバを新設 
 59 現在の APAC 地域へのトラフィック量から試算したところ、 
 日本サーバで通信を中継するのではなく、 
 シンガポールリージョンに新サーバを立てて配信を中継した方が、通信量が安くなることが判明した 
 NEW!

60. REALITY の現在のサーバ状況 
 60 REALITY では現在、 
 日本、シンガポール、北アメリカ の３リージョンにサーバーを置いています 

61. 配信中にやり取りしているデータの削減 
 61
62. どういう取り組みを行ったか？ 
 配信中のデータ通信において、 
 やり取りしているモーションデータのサイズを可能な限り削減した 
 62 GKE 
 配信者
 Websocket 通信 
 視聴者
 Websocket 通信 
 モーションデータ 

63. REALITYでは、カメラ画像から BlendShape 値を算出し、 
 この BlendShape 値をやり取りすることで各クライアントでアバターの表情を再現している 
 モーションデータの削減 
 63
64. この BlendShape 値のやり取りを、当初は Protobuf 内の float (0 ~ 1.0) の配列で行っていた 
 
 配列でやり取りを行う場合、必ず全ての BlendShape 値をデータに含める必要があり、 
 float なので各データが必ず 4byte かかっていた 
 モーションデータの削減 
 64 GKE 
 配信者
 視聴者
 モーションデータ 
 (Protobuf)
 BlendShape: [0.82, 0, …] 
 e.t.c.
 左目 (4byte)
 右目
 (4byte)

65. この BlendShape 値それぞれを個別に Protobuf の項目として定義 
 Protobuf ではデフォルト値の場合はデータが省略され、バイト数を削減！ 
 
 さらに、Blendshape 値を 1000倍して int32 としてやり取りすることで、 
 各 Blendshape値のデータ量を 2byte 以下に ( int32 のデータ量は可変長) 
 モーションデータの削減 
 65 GKE 
 配信者
 視聴者
 モーションデータ 
 (Protobuf)
 BlendShape: { 
 LeftEye: 820, 
 …} (右目は0なので省略) 
 e.t.c.
 左目 (2byte)

66. また、モーションデータは数フレームごとにまとめて BlendShape の値を送っていたが、 
 視聴者側では最後のフレームしか利用していなかった 
 モーションデータの削減 
 66 GKE 
 配信者
 視聴者
 モーションデータ 
 (Protobuf)
 BlendShape: [ 
 フレーム1のデータ, 
 フレーム２のデータ, 
 …
 フレーム n のデータ 
 ]
 e.t.c.
 視聴者側は最後のフレームの値だけ利用して表情を再現 

67. なので、配信者側から数フレームごとに送るデータも、最後のフレームの値だけ送るように修正 
 モーションデータの削減 
 67 GKE 
 配信者
 視聴者
 モーションデータ 
 (Protobuf)
 BlendShape: [ 
 フレーム n のデータ 
 ]
 e.t.c.

68. 68 23年4月のデータ 
 ココ！

69. Spot VM の利用の促進 
 69
70. N2 Instance Core Running in Japan って 
 どこにかかっているお金？ 
 Compute Engine で作成した VM が確保している CPU 量に応じてかかる金額 
 
 REALITYでは、主に GKEクラスタのノードとして 利用している
 70 Compute Engine 

71. Compute Engine の余剰キャパシティを利用する VM インスタンス 
 GKE のノードとして利用することも可能 
 
 通常の VM と比較してはるかに 低価格で利用することができる 
 
 ただし、 Compute Engine がキャパシティを再利用するために、 
 Spot VM を事前に停止、または削除（プリエンプト） することがある
 Spot VM とは 
 71
72. プロジェクトで使用する VM を Spot VM に変更するだけで、かなり安くすることができる 
 （通常のVMの 1/3 ~1/4 ほどの値段で使える） 
 Spot VM の料金 
 72 通常
 Spot VM
 0.042649
 CPU料金
 ($ / vCPU Hour)
 メモリ料金
 ($ / GB Hour)
 0.005690
 0.010149
 0.001354
 N2カスタムマシンの料金表 
 （2024年9月17日時点）
73. Spot VM は、Compute Engine によっていつでもプリエンプトされうる 
 いつ停止されるかわからないので、ステートフルなPod群は 移行できない 
 
 なので、REALITYではAPIレスポンスに利用しているステートレスなサービスのみを 
 Spot VM 上で稼働させるようにした 
 Spot VM の利用の注意点 
 73
74. Spot VM は、常に利用できるわけではない 
 Spot VM は Compute Engine の余剰キャパシティを利用している 
 → つまり、有限リソースであり、 いつでも確実に利用できるわけではない（SLA対象外） 
 
 そのため、REALITYでは 複数のリージョン、複数のマシンタイプを使用する ことで
 利用できなくなる確率を下げている 
 また、それでもマシンが確保できない場合は 通常のVMを利用する ようにしている
 Spot VM の利用の注意点 
 74
75. アジェンダ 
 • REALITY について 
 • 利益を生む、とは 
 • コストの分析 
 • 効果の大きかったコスト削減施策 
 • まとめ
 75
76. まとめ
 76
77. まとめ • 月々のサーバー費を削減することで恒久的に利益に貢献できる 
 • 削減の前に、どこにお金がかかっているかを把握するのが大切 
 • アーキテクチャの見直しが大切 
 ◦ 運用によって、問題が浮き彫りになる 
 ◦ 事業の成長とともに、最適なアーキテクチャは変化していく 
 77
78. ご清聴ありがとうございました 78