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

by gree_tech

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

久山貴大  2018年グリー入社  2020年 REALITY に転部  2023年 REALITY内のDevOpsチームとして活動開始  REALITY株式会社   DevOpsチームエンジニアマネージャー  2

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

REALITY について   5

Slide 6

Slide 6 text

REALITY   6 スマホひとつでアバター作成、ライブ配信による交流やゲームなどが楽しめる、スマホ向けメタバース  

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

利益を生む、とは   9

Slide 10

Slide 10 text

サービスの継続のためには、利益を出していく必要がある   利益を生む、とは   10

Slide 11

Slide 11 text

11 利益を生む魔法の方程式

Slide 12

Slide 12 text

12 利益 = 収入 - 支出

Slide 13

Slide 13 text

収入の増やし方はサービスによってまちまちで、アプローチもまちまち     今日の話のターゲットではない   収入を増やすには・・・？   13

Slide 14

Slide 14 text

利益を生むには、支出を減らせば良い！    サービスの継続には、常に固定費がかかり続ける   人件費、外注費、サーバー費、 etc...   じゃぁ、利益を生むには・・・？   14

Slide 15

Slide 15 text

このうちクラウドコストに絞って、支出を減らすためのプロジェクトが発足した！   コスト削減プロジェクト発足！   15

Slide 16

Slide 16 text

REALITY では、本プロジェクトによって以前 Google Cloud にかかっていたコストのうち、   1000万円以上を削減することに成功しました！   クラウドコストを減らす   16

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

コストの分析   18

Slide 19

Slide 19 text

より効果の高い削減を行うには？   効率的にクラウドコストの削減を行うためには、   まずどこにお金がかかっているかを調べる必要がある     月々 2,3 万円しかかかっていないようなところを削減したところで削減額はたかがしれているが、   月々100万円かかっているような箇所を削減すれば、数10万の削減が見込めることも   19

Slide 20

Slide 20 text

Google Cloud の費用レポート   20 Google Cloud では費用レポートを見ることで、   どのサービス・SKUにどのくらいお金がかかっているかすぐに見ることができる   23年4月のデータ  

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

効果の大きかったコスト削減施策   24

Slide 25

Slide 25 text

25 ココ！ 

Slide 26

Slide 26 text

Cloud Storage 内に保存されている   配信アーカイブのストレージクラスを変更   26

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

Cloud Storage 内に保存されている   配信アーカイブのストレージクラスを変更   REALITY では、Cloud Storage に今までアプリ上で行われた   配信の生データがアーカイブとして保存されており、全部で 1PiB を超えていた     これらのデータは、通報等があった際に監査を行うために保存されている     つまり、ほとんどのデータは一度保存された後は   アクセスされることがない     なのに、これらのデータは Standard ストレージクラスとして  保存されてしまっていた  28

Slide 29

Slide 29 text

ストレージクラスとは？   Cloud Storage に保存される全てのデータ（オブジェクト）には、   必ずストレージクラスが設定されている     ストレージクラスは Standard, Nearline, Coldline, Archived の４種類     後ろに行くほど、アクセス頻度の少ないデータの保存に適している   ・データの保存にかかる金額： Standard > Nearline > Coldline > Archived   ・データのアクセスにかかる金額：Standard < Nearline < Coldline < Archived   29

Slide 30

Slide 30 text

Cloud Storage 内に保存されている   配信アーカイブのストレージクラスを変更   これらのデータのストレージクラスを Coldline に変更した     また、これらのデータについては保存された後、   数日経ったらストレージクラスを Coldline に変更するように   バケットにライフサイクルの設定を行った     （対象のバケットのライフサイクル→ルールを追加   アクション：ストレージクラスを Coldline に設定する   オブジェクト条件の選択：経過日数を設定）   30

Slide 31

Slide 31 text

Cloud Storage 内に保存されている   配信アーカイブのストレージクラスを変更   注意事項として、ストレージクラスの変更にも料金がかかることに注意    このストレージクラスの変更は、「クラスAオペレーション」として扱われる   厄介なのは、この「クラスAオペレーション」はオブジェクト1つ1つに対してかかる   つまり、オブジェクト数に比例したコストがかかる     一方、オブジェクトの保存のコストは、   どのストレージクラスでもオブジェクトのデータ量に比例してかかる    つまり、オブジェクト1つ1つのデータ量が極端に小さい場合、   ストレージクラスの変更コストを回収するのに時間がかかるので注意！  （幸い、配信アーカイブはオブジェクト1つあたりのデータ量が大きかった）   31

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Cloud SQL インスタンスの使用量削減   33

Slide 34

Slide 34 text

この3つってどこにかかっているお金？   Cloud SQL for MySQL で利用した CPU、memory の量に応じてかかるお金     Cloud SQL は自動でスケーリングしないので、  インスタンスごとに設定したCPUスペック、メモリスペックに応じて毎月ほぼ定額でかかってくる    34 Cloud SQL  

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

36 ココ！ 

Slide 37

Slide 37 text

BigQuery へのレコードの出力の経路を変更   37

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

Cloud Logging へ保存していたログの一部を BigQuery へ保存     43

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

また、BigQuery に保存したログの参照性をできるだけ落とさないように、   Cloud Logging ライクにアクセスログを検索できる機能を内部ツール上で実装   BigQuery に保存したログの参照性を強化   47

Slide 48

Slide 48 text

48 配信音声アーカイブのエンコードを   監査時のみに   ココ！ 

Slide 49

Slide 49 text

配信音声アーカイブのエンコードを   監査時のみに   49

Slide 50

Slide 50 text

vCPU Time Streaming Japan って   どこにかかっているお金？   Dataflow ジョブで利用される   Dataflow ワーカーで消費したCPU 量に応じてかかる料金     要は、Dataflow を使えば使うだけかかる料金   50 Dataflow  

Slide 51

Slide 51 text

配信音声アーカイブの生成エンコードを、監査時のみに   全ての配信の音声データは Dataflow を通して生データから ogg 形式にエンコードして保存されていた（生データとエンコード後の音声データ、2つのデータが保存されていた）   エンコードされた音声データは、通報があった際にのみ利用される   一方、通報がなければこれらの音声データが利用されることは稀     つまり、通報されていない音声データをエンコードする必要はなかった       51

Slide 52

Slide 52 text

配信音声アーカイブの生成エンコードを、監査時のみに   音声データの ogg 形式へのエンコードを   全ての配信に対して行うのではなく通報の際にオンデマンドで行うように    エンコードされた音声データは、監査ツールから参照可能   52 不適切な配信を通報   監査ツールエンコードジョブ Dataﬂow ジョブを起動   配信生データ Cloud Storage 音声データ (ogg) Cloud Storage エンコード  参照  ユーザ  エンコード後、   数日で削除される  

Slide 53

Slide 53 text

53 ココ！ 

Slide 54

Slide 54 text

配信中のデータのやり取りに   利用するリージョンを増設     54

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

配信中にやり取りしているデータの削減   61

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

REALITYでは、カメラ画像から BlendShape 値を算出し、   この BlendShape 値をやり取りすることで各クライアントでアバターの表情を再現している   モーションデータの削減   63

Slide 64

Slide 64 text

この BlendShape 値のやり取りを、当初は Protobuf 内の float (0 ~ 1.0) の配列で行っていた     配列でやり取りを行う場合、必ず全ての BlendShape 値をデータに含める必要があり、   float なので各データが必ず 4byte かかっていた   モーションデータの削減   64 GKE   配信者  視聴者  モーションデータ   (Protobuf)  BlendShape: [0.82, 0, …]   e.t.c.  左目 (4byte)  右目  (4byte) 

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

Spot VM の利用の促進   69

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

Compute Engine の余剰キャパシティを利用する VM インスタンス   GKE のノードとして利用することも可能     通常の VM と比較してはるかに低価格で利用することができる     ただし、 Compute Engine がキャパシティを再利用するために、   Spot VM を事前に停止、または削除（プリエンプト）することがある  Spot VM とは   71

Slide 72

Slide 72 text

プロジェクトで使用する 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日時点）

Slide 73

Slide 73 text

Spot VM は、Compute Engine によっていつでもプリエンプトされうる   いつ停止されるかわからないので、ステートフルなPod群は移行できない     なので、REALITYではAPIレスポンスに利用しているステートレスなサービスのみを   Spot VM 上で稼働させるようにした   Spot VM の利用の注意点   73

Slide 74

Slide 74 text

Spot VM は、常に利用できるわけではない   Spot VM は Compute Engine の余剰キャパシティを利用している   → つまり、有限リソースであり、いつでも確実に利用できるわけではない（SLA対象外）     そのため、REALITYでは複数のリージョン、複数のマシンタイプを使用することで  利用できなくなる確率を下げている   また、それでもマシンが確保できない場合は通常のVMを利用するようにしている  Spot VM の利用の注意点   74

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

まとめ  76

Slide 77

Slide 77 text

まとめ ● 月々のサーバー費を削減することで恒久的に利益に貢献できる   ● 削減の前に、どこにお金がかかっているかを把握するのが大切   ● アーキテクチャの見直しが大切   ○ 運用によって、問題が浮き彫りになる   ○ 事業の成長とともに、最適なアーキテクチャは変化していく   77