Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
今すぐ利益に直結する! Google Cloud のクラウドコスト最適化の実践事例紹介!
Search
gree_tech
PRO
October 25, 2024
Video
Technology
1
90
今すぐ利益に直結する! Google Cloud のクラウドコスト最適化の実践事例紹介!
GREE Tech Conference 2024で発表された資料です。
https://techcon.gree.jp/2024/session/TrackC-5
gree_tech
PRO
October 25, 2024
Tweet
Share
Video
More Decks by gree_tech
See All by gree_tech
REALITY株式会社における開発生産性向上の取り組み: 失敗と成功から学んだこと
gree_tech
PRO
2
130
『ヘブンバーンズレッド』におけるフィールドギミックの裏側
gree_tech
PRO
2
91
セキュリティインシデント対応の体制・運用の試行錯誤 / greetechcon2024-session-a1
gree_tech
PRO
1
96
『アナザーエデン 時空を超える猫』国内海外同時運営実現への道のり ~別々で開発されたアプリを安定して同時リリースするまでの取り組み~
gree_tech
PRO
1
78
『アサルトリリィ Last Bullet』におけるクラウドストリーミング技術を用いたブラウザゲーム化の紹介
gree_tech
PRO
1
89
UnityによるPCアプリの新しい選択肢。「PC版 Google Play Games」への対応について
gree_tech
PRO
1
110
実機ビルドのエラーによる検証ブロッカーを0に!『ヘブンバーンズレッド』のスモークテスト自動化の取り組み
gree_tech
PRO
1
110
"ゲームQA業界の技術向上を目指す! 会社を超えた研究会の取り組み"
gree_tech
PRO
1
140
Jamstack でリニューアルするグリーグループのメディア
gree_tech
PRO
2
300
Other Decks in Technology
See All in Technology
スクラムチームを立ち上げる〜チーム開発で得られたもの・得られなかったもの〜
ohnoeight
2
350
IBC 2024 動画技術関連レポート / IBC 2024 Report
cyberagentdevelopers
PRO
0
110
The Role of Developer Relations in AI Product Success.
giftojabu1
0
120
Security-JAWS【第35回】勉強会クラウドにおけるマルウェアやコンテンツ改ざんへの対策
4su_para
0
170
RubyのWebアプリケーションを50倍速くする方法 / How to Make a Ruby Web Application 50 Times Faster
hogelog
3
940
AIチャットボット開発への生成AI活用
ryomrt
0
170
Python(PYNQ)がテーマのAMD主催のFPGAコンテストに参加してきた
iotengineer22
0
470
信頼性に挑む中で拡張できる・得られる1人のスキルセットとは?
ken5scal
2
530
Lambda10周年!Lambdaは何をもたらしたか
smt7174
2
110
サイバーセキュリティと認知バイアス:対策の隙を埋める心理学的アプローチ
shumei_ito
0
380
オープンソースAIとは何か? --「オープンソースAIの定義 v1.0」詳細解説
shujisado
6
670
OCI Vault 概要
oracle4engineer
PRO
0
9.7k
Featured
See All Featured
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
25
1.8k
The Power of CSS Pseudo Elements
geoffreycrofte
73
5.3k
Writing Fast Ruby
sferik
627
61k
Why Our Code Smells
bkeepers
PRO
334
57k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
24k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
246
1.3M
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
Code Review Best Practice
trishagee
64
17k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.4k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.7k
Bash Introduction
62gerente
608
210k
Transcript
今すぐ利益に直結する! Google Cloud のクラウドコスト最適化の 実践事例紹介 REALITY株式会社 エンジニア
久山貴大
久山 貴大 2018年 グリー 入社 2020年 REALITY に転部 2023年 REALITY内のDevOpsチームとして活動開始
REALITY株式会社 DevOpsチームエンジニアマネージャー 2
アジェンダ • REALITY について • 利益を生む、とは •
コストの分析 • 効果の大きかったコスト削減施策 • まとめ 3
アジェンダ • REALITY について • 利益を生む、とは •
コストの分析 • 効果の大きかったコスト削減施策 • まとめ 4
REALITY について 5
REALITY 6 スマホひとつでアバター作成、ライブ配信による交流やゲームなどが楽しめる、スマホ向けメタバース
None
アジェンダ • REALITY について • 利益を生む、とは •
コストの分析 • 効果の大きかったコスト削減施策 • まとめ 8
利益を生む、とは 9
サービスの継続のためには、利益を出していく必要がある 利益を生む、とは 10
11 利益を生む魔法の方程式
12 利益 = 収入 - 支出
収入の増やし方はサービスによってまちまちで、アプローチもまちまち 今日の話のターゲットではない 収入を増やすには・・・? 13
利益を生むには、支出を減らせば良い ! サービスの継続には、常に固定費がかかり続ける 人件費、外注費、サーバー費、 etc... じゃぁ、利益を生むには・・・?
14
このうちクラウドコストに絞って、支出を減らすためのプロジェクトが発足した! コスト削減プロジェクト発足! 15
REALITY では、本プロジェクトによって以前 Google Cloud にかかっていたコストのうち、 1000万円以上 を削減することに成功しました! クラウドコストを減らす
16
アジェンダ • REALITY について • 利益を生む、とは •
コストの分析 • 効果の大きかったコスト削減施策 • まとめ 17
コストの分析 18
より効果の高い削減を行うには? 効率的にクラウドコストの削減を行うためには、 まずどこにお金がかかっているか を調べる必要がある 月々 2,3
万円しかかかっていないようなところを削減したところで削減額はたかがしれているが、 月々100万円かかっているような箇所を削減すれば、数10万の削減が見込めることも 19
Google Cloud の費用レポート 20 Google Cloud では費用レポートを見ることで、 どのサービス・SKUにどのくらいお金がかかっているかすぐに見ることができる
23年4月のデータ
SKU とは? 21 Google Cloud の各サービスにかかる料金をさらに細分化したもの
例えば、オンラインストレージである Cloud Storage にかかる料金は ・データを保存し続けることでかかるストレージ料金 ・データへのアクセス数に応じてかかる料金 ・データ属性変更などに応じてかかる料金 などに細分化される これらそれぞれが個別の SKU として計上される
Google Cloud の費用レポート 22 費用削減プロジェクトでも、 この費用レポートに従い、コストがかかっている箇所から削減に取り組んで行った
アジェンダ • REALITY について • 利益を生む、とは •
コストの分析 • 効果の大きかったコスト削減施策 • まとめ 23
効果の大きかったコスト削減施策 24
25 ココ!
Cloud Storage 内に保存されている 配信アーカイブのストレージクラスを変更 26
Standard Storage Tokyo って どこにかかっているお金? Google Cloud Storage
の(東京リージョンの)バケットに保存されている Standard クラスのオブジェクトのデータ量の合計 に応じてかかる費用 保存されてるデータ量 * 保存期間 で費用がかかる 27 Cloud Storage
Cloud Storage 内に保存されている 配信アーカイブのストレージクラスを変更 REALITY では、Cloud Storage に今までアプリ上で行われた
配信の生データがアーカイブとして保存されており、全部で 1PiB を超えていた これらのデータは、通報等があった際に監査を行うために保存されている つまり、ほとんどのデータは一度保存された後は アクセスされることがない なのに、これらのデータは Standard ストレージクラス として 保存されてしまっていた 28
ストレージクラスとは? Cloud Storage に保存される全てのデータ(オブジェクト)には、 必ずストレージクラスが設定されている ストレージクラスは
Standard, Nearline, Coldline, Archived の4種類 後ろに行くほど、アクセス頻度の少ないデータの保存に適している ・データの保存にかかる金額: Standard > Nearline > Coldline > Archived ・データのアクセスにかかる金額:Standard < Nearline < Coldline < Archived 29
Cloud Storage 内に保存されている 配信アーカイブのストレージクラスを変更 これらのデータのストレージクラスを Coldline に変更した
また、これらのデータについては保存された後、 数日経ったらストレージクラスを Coldline に変更するように バケットにライフサイクルの設定を行った (対象のバケットのライフサイクル→ルールを追加 アクション:ストレージクラスを Coldline に設定する オブジェクト条件の選択:経過日数 を設定) 30
Cloud Storage 内に保存されている 配信アーカイブのストレージクラスを変更 注意事項として、ストレージクラスの変更 にも料金がかかる ことに注意
このストレージクラスの変更は、「クラスAオペレーション」として扱われる 厄介なのは、この「クラスAオペレーション」はオブジェクト1つ1つに対してかかる つまり、オブジェクト数に比例したコストがかかる 一方、オブジェクトの保存のコストは、 どのストレージクラスでも オブジェクトのデータ量 に比例してかかる つまり、オブジェクト1つ1つのデータ量が極端に小さい場合、 ストレージクラスの変更コストを回収するのに時間がかかる ので注意! (幸い、配信アーカイブはオブジェクト1つあたりのデータ量が大きかった) 31
32
Cloud SQL インスタンスの使用量削減 33
この3つってどこにかかっているお金? Cloud SQL for MySQL で利用した CPU、memory の量に応じてかかるお金
Cloud SQL は自動でスケーリングしない ので、 インスタンスごとに設定したCPUスペック、メモリスペックに応じて 毎月ほぼ定額でかかってくる 34 Cloud SQL
複数の対策を組み合わせて、Cloud SQL の CPU利用量、 memory 使用量を最適化していった • DBフラグを調整することによる、
パフォーマンスチューニング ◦ 具体的な設定は省略 • DBのスペック設定時の基準の変更 ◦ REALITYでは元々、過剰気味にスペックが盛られていた(平時のCPU利用率 10 ~ 15 % を目標) • インデックスの見直し ◦ ユーザ検索のために 全文検索インデックス を検索用DBに貼る、等 Cloud SQL インスタンスの設定最適化 35
36 ココ!
BigQuery へのレコードの出力の経路を変更 37
Log Storage Cost って どこにかかっているお金? Google Cloud 上の各サービスが出力したログを
Cloud Logging 上に保存する際にかかる費用 (このログは、30日間無料で保存され、検索も無料) 保存したログのデータ量に比例して課金される 38 Cloud Logging
サーバから出力している行動ログのデータを、 REALITYでは元々以下のような経路で出力していた BigQuery へのレコードの出力の経路を変更 39 サービス群 GKE
Cloud Logging Pub/Sub Dataflow BigQuery 行動ログを出力 ログルーターで 抽出 ジョブを起動 保存
サーバから出力している行動ログのデータを、 REALITYでは元々以下のような経路で出力していた BigQuery へのレコードの出力の経路を変更 40 サービス群 GKE
Cloud Logging Pub/Sub Dataflow BigQuery 行動ログを出力 ログルーターで 抽出 ジョブを起動 保存 ここにお金が かかっていた
サービス群から Pub/Sub に直接データを出力することで、Cloud Logging への出力を不要に BigQuery へのレコードの出力の経路を変更 41
サービス群 GKE Pub/Sub Dataflow BigQuery ジョブを起動 保存 直接出力
サービス群から Pub/Sub に直接データを出力することで、Cloud Logging への出力を不要に BigQuery へのレコードの出力の経路を変更 42
サービス群 GKE Pub/Sub Dataflow BigQuery ジョブを起動 保存 直接出力 Cloud Logging への出力が無くなった分、料金を削減!
Cloud Logging へ保存していたログの一部を BigQuery へ保存 43
REALITYでは、ユーザからの API アクセスごとに必ず Cloud Logging にログを出力していた これらのログは、障害時の調査や、新機能リリース時の監視に利用されている
Cloud Logging へ保存していたログの一部を BigQuery へ 保存 44 GKE ユーザ Cloud Logging APIアクセス アクセスログ出力
しかし逆に言えば、 リリース時以外での正常系のログは、ほとんど利用されない Cloud Logging へ保存していたログの一部を BigQuery へ 保存 45
GKE ユーザ Cloud Logging APIアクセス (正常系) アクセスログ出力 このログはほとんど利用されない
リリース時以外でのログのうち、 正常系のAPIアクセスのほとんどを BigQuery上に保存することに (障害調査のために、全ログの保存は従来通り行う) Cloud Logging へ保存していたログの一部を BigQuery
へ 保存 46 GKE ユーザ Cloud Logging APIアクセス (正常系) アクセスログ出力 BigQuery
また、BigQuery に保存したログの参照性をできるだけ落とさないように、 Cloud Logging ライクにアクセスログを検索できる機能を内部ツール上で実装 BigQuery に保存したログの参照性を強化
47
48 配信音声アーカイブのエンコードを 監査時のみに ココ!
配信音声アーカイブのエンコードを 監査時のみに 49
vCPU Time Streaming Japan って どこにかかっているお金? Dataflow ジョブで利用される
Dataflow ワーカー で消費したCPU 量 に応じてかかる料金 要は、Dataflow を使えば使うだけかかる料金 50 Dataflow
配信音声アーカイブの生成エンコードを、監査時のみに 全ての配信の音声データは Dataflow を通して生データから ogg 形式にエンコードして保存されていた(生 データとエンコード後の音声データ、2つのデータが保存されていた) エンコードされた音声データは、通報があった際にのみ利用される
一方、通報がなければこれらの音声データが利用されることは稀 つまり、通報されていない音声データを エンコードする必要はなかった 51
配信音声アーカイブの生成エンコードを、監査時のみに 音声データの ogg 形式へのエンコードを 全ての配信に対して行うのではなく通報の際に オンデマンドで行うように エンコードされた音声データは、監査ツールから参照可能
52 不適切な配信を通報 監査ツール エンコードジョブ Dataflow ジョブを起動 配信生データ Cloud Storage 音声データ (ogg) Cloud Storage エンコード 参照 ユーザ エンコード後、 数日で削除される
53 ココ!
配信中のデータのやり取りに 利用するリージョンを増設 54
Network Internet Data Transfer Out From A to B ってど
こにかかっているお金? Google Cloud 上の VPC から外部に向かってのデータ転送 にかかる料金 転送したデータのデータ量に比例して課金される REALITY では、配信中に GKE 上のサーバを経由した Websocket 通信で 配信者から視聴者に転送されるモーション・音声データのデータ量が特に多い 55 GKE 配信者 Websocket 通信 視聴者 Websocket 通信 ここの通信量にかかる料金
APAC ってどの地域? 56 アジア太平洋地域 (Asia Pacific) のこと
REALITYではこの地域からの利用者が多い
Japan to APAC のデータ転送 57 REALITY では、配信中のデータのやり取りの中継サーバを 日本
と 北アメリカ に立てていた
Japan to APAC のデータ転送 58 APAC地域のユーザへの配信中のデータ転送では、基本的に日本のサーバを経由していた
シンガポールリージョンに配信用サーバを新設 59 現在の APAC 地域へのトラフィック量から試算したところ、 日本サーバで通信を中継するのではなく、 シンガポールリージョンに新サーバを立てて配信を中継した方が、通信量が安くなることが判明した
NEW!
REALITY の現在のサーバ状況 60 REALITY では現在、 日本、シンガポール、北アメリカ の3リージョンにサーバーを置いています
配信中にやり取りしているデータの削減 61
どういう取り組みを行ったか? 配信中のデータ通信において、 やり取りしているモーションデータのサイズを可能な限り削減した 62 GKE 配信者
Websocket 通信 視聴者 Websocket 通信 モーションデータ
REALITYでは、カメラ画像から BlendShape 値を算出し、 この BlendShape 値をやり取りすることで各クライアントでアバターの表情を再現している モーションデータの削減
63
この BlendShape 値のやり取りを、当初は Protobuf 内の float (0 ~ 1.0) の配列で行っていた
配列でやり取りを行う場合、必ず全ての BlendShape 値をデータに含める必要があり、 float なので各データが必ず 4byte かかっていた モーションデータの削減 64 GKE 配信者 視聴者 モーションデータ (Protobuf) BlendShape: [0.82, 0, …] e.t.c. 左目 (4byte) 右目 (4byte)
この BlendShape 値それぞれを個別に Protobuf の項目として定義 Protobuf ではデフォルト値の場合はデータが省略され、バイト数を削減!
さらに、Blendshape 値を 1000倍して int32 としてやり取りすることで、 各 Blendshape値のデータ量を 2byte 以下に ( int32 のデータ量は可変長) モーションデータの削減 65 GKE 配信者 視聴者 モーションデータ (Protobuf) BlendShape: { LeftEye: 820, …} (右目は0なので省略) e.t.c. 左目 (2byte)
また、モーションデータは数フレームごとにまとめて BlendShape の値を送っていたが、 視聴者側では最後のフレームしか利用していなかった モーションデータの削減 66 GKE
配信者 視聴者 モーションデータ (Protobuf) BlendShape: [ フレーム1のデータ, フレーム2のデータ, … フレーム n のデータ ] e.t.c. 視聴者側は最後のフレームの値だけ利用して表情を再現
なので、配信者側から数フレームごとに送るデータも、最後のフレームの値だけ送るように修正 モーションデータの削減 67 GKE 配信者 視聴者 モーションデータ
(Protobuf) BlendShape: [ フレーム n のデータ ] e.t.c.
68 23年4月のデータ ココ!
Spot VM の利用の促進 69
N2 Instance Core Running in Japan って どこにかかっているお金?
Compute Engine で作成した VM が確保している CPU 量に応じてかかる金額 REALITYでは、主に GKEクラスタのノードとして 利用している 70 Compute Engine
Compute Engine の余剰キャパシティを利用する VM インスタンス GKE のノードとして利用することも可能
通常の VM と比較してはるかに 低価格で利用することができる ただし、 Compute Engine がキャパシティを再利用するために、 Spot VM を事前に停止、または削除(プリエンプト) することがある Spot VM とは 71
プロジェクトで使用する 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日時点)
Spot VM は、Compute Engine によっていつでもプリエンプトされうる いつ停止されるかわからないので、ステートフルなPod群は 移行できない
なので、REALITYではAPIレスポンスに利用しているステートレスなサービスのみを Spot VM 上で稼働させるようにした Spot VM の利用の注意点 73
Spot VM は、常に利用できるわけではない Spot VM は Compute Engine の余剰キャパシティを利用している
→ つまり、有限リソースであり、 いつでも確実に利用できるわけではない(SLA対象外) そのため、REALITYでは 複数のリージョン、複数のマシンタイプを使用する ことで 利用できなくなる確率を下げている また、それでもマシンが確保できない場合は 通常のVMを利用する ようにしている Spot VM の利用の注意点 74
アジェンダ • REALITY について • 利益を生む、とは •
コストの分析 • 効果の大きかったコスト削減施策 • まとめ 75
まとめ 76
まとめ • 月々のサーバー費を削減することで恒久的に利益に貢献できる • 削減の前に、どこにお金がかかっているかを把握するのが大切 • アーキテクチャの見直しが大切
◦ 運用によって、問題が浮き彫りになる ◦ 事業の成長とともに、最適なアーキテクチャは変化していく 77
ご清聴ありがとうございました 78
None