Slide 1

Slide 1 text

2023/03/03
 TIPSTAR開発部 システム2G アーキテクトチーム
 鈴木 進吾
 TIPSTARがチャレンジを続けていくために取り組んだこと 〜MIXI TECH CONFERENCE 2023〜 DAY3 D3-8

Slide 2

Slide 2 text

自己紹介 ● 鈴木進吾 / @mominosin ● 2021年1月中途入社 ● TIPSTAR開発部 システム2グループ ○ アーキテクトチーム リーダー ● 前職までずっと「AWS」で「Google Cloud」少々 ● TIPSTARではずっと「Google Cloud」で「AWS」少々

Slide 3

Slide 3 text

内容 ● TIPSTARとは ● システム2グループとは ● TIPSTARがチャレンジを続けていくための取り組み ○ インフラコスト最適化によりコストの障壁を取り除く ○ データドリブンな組織のためにデータ基盤改善 ○ TIPSTAR のリスクに気付く環境づくりなどの施策 ● まとめ

Slide 4

Slide 4 text

TIPSTARとは

Slide 5

Slide 5 text

TIPSTARとは TIPSTAR TIPSTARとは、365日配信されるレース映像と、 競輪・PIST6・オートレースのネット投票を、 基本無料で楽しむことができるサービスです。

Slide 6

Slide 6 text

TIPSTARと周辺の構成 各場の映像 AI による 映像編集 ユーザ・決済基盤 競輪・オートレース PIST6 認証・認可・決済 etc. レース情報取得・投票 レース情報取得・投票 ユーザ

Slide 7

Slide 7 text

システム2グループとは

Slide 8

Slide 8 text

TIPSTAR開発部 システム2グループとは ● ユーザが安全かつ快適に使えるサービスを提供する ● 開発組織が自律的に課題解決できる開発基盤と文化をつくる ● 事業成長を阻害するリスクやコストを技術を用いて減らし、最適化する システム2グループのミッション ● システム1グループ:TIPSTAR本体の開発運用 ● システム2グループ:開発組織のサポート TIPSTAR開発部のサーバーサイドの開発グループの1つ

Slide 9

Slide 9 text

システム2グループが取り組んできたこと ● インフラ ○ Google Cloud(GKE、Cloud Spanner、BigQuery)の運用 ○ Terraformの整理(Module化、tfsec導入) ○ CI/CD改善(Argo CD導入、CircleCI/GitHub Actionsの整備) ○ セキュリティ対応(Renovate、Trivyの導入対応) ● KPI計測の仕組みを整備 ● ツールの整備 ○ CI等で利用する静的解析ツールの作成、複雑なコマンドの生成 ● 周辺システムの新規構築 ○ 外部連携、管理画面 ● コスト最適化 例

Slide 10

Slide 10 text

TIPSTARがチャレンジを 続けていくための取り組み

Slide 11

Slide 11 text

チャレンジを続けていくための状態を作る取り組み ● その状態を作るためのシステム2グループのミッション ○ 事業成長を阻害するリスクやコストは技術を用いて減らし、最適化する ○ 開発組織が自律的に課題解決できる開発基盤と文化をつくる ○ ユーザが安全かつ快適に使えるサービスを提供する 開発組織が本来立ち向かうべき課題に注力できる状態 ● インフラコスト最適化によりコストの障壁を取り除く ● データドリブンな組織のためのデータ基盤改善 ● TIPSTAR のリスクに気付く環境づくり 取り組んでいる内容(本発表の本題)

Slide 12

Slide 12 text

インフラコスト最適化に よりコスト障壁を取り除く

Slide 13

Slide 13 text

インフラコスト(Google Cloud)最適化 ● Spanner Autoscalerの導入 ● GKEのpodリソース調整 ● Cloud Storageの不要ファイルの削除(Docker Imageなど含む) ● BigQueryに溜め込んでいるログをCloud Storage(Archive)へ移動 ● など やったこと 優先度高く取り組んだタイミング ● コストが理由で新しい施策を諦めなくて良い状態を作るため ● 昨年の円安の影響を懸念

Slide 14

Slide 14 text

インフラコスト最適化へのアプローチ例(1/4) ● サービス利用料TOP10を見る ○ 利用料が高いところのほうが選択肢が 多いしコスパが良い 愚直にがんばる

Slide 15

Slide 15 text

インフラコスト最適化へのアプローチ例(2/4) 引き続き愚直にがんばる ● TOP10の詳細(SKU)を見ていく ○ BigQueryの例では以下のコストが高い ■ 長期保存用ストレージ ● Long Term Logical Storage

Slide 16

Slide 16 text

インフラコスト最適化へのアプローチ例(3/4) ● 一定期間保持し続ける監査ログがコストに ○ 調査したいときに使えれば良いのでBigQueryと いう形でなくても良い BigQueryのコストを削減できないか? ● Cloud StorageのArchive Storageが 安いので移動できないか? ○ $0.01/GB ⇨ $0.0012/GB 代替案は無いか? BigQuery Cloud Logging Acitive Storage Long Term Logical Storage 監査ログを格納
 90日経過した
 データが格納
 される
 Cloud Storage 90日経過する前に
 経路を変更する事で 
 コスト削減を図る


Slide 17

Slide 17 text

インフラコスト最適化へのアプローチ例(4/4) ● 監査ログをBigQueryに保存する期間を1ヶ月にする ● 監査ログをBigQueryからCloud Storageへ移動するジョブを作成 実際にコストを下げる対応 ● Long Term Logical Storageの減少(青) ● Archive Storageの微増(紫) ● 6月と9月を比較し半減 対応の結果

Slide 18

Slide 18 text

アプローチの結果 ● 本番環境ではピークと比較して大幅に削減 ● 開発環境も本番環境ほどではないが削減 ドルベースで大幅なコストの削減を実現

Slide 19

Slide 19 text

その他アプローチ ● 新機能によりコスト削減の手法が打てることも 最新のアプデを確認する ● 推奨事項の確認 ○ 不要なリソースが確認できる ○ 確約利用割引(CUD)の提案を確認できる Google Cloudの機能を利用する

Slide 20

Slide 20 text

インフラコスト最適化の今後 ● 引き続きコストの推移を見守る ● コスト感をフィードバックしチーム全体で把握できるようにする ● お金だけでなく運用コストの最適化も進める 定期的にコストを確認していく ● Google Cloudのアップデートの確認 ● 確約利用割引(CUD)などの選択肢も検討する ● 新機能実装時にはアーキテクチャのレビューでコストの妥当性も見ていく コスト削減を模索

Slide 21

Slide 21 text

データドリブンな組織 のためのデータ基盤改善

Slide 22

Slide 22 text

参照先によってデータが異なる事も データ基盤改善をなぜ行うのか ● 速報値として利用しているログの精度が低い ○ お金に関わるところなどに影響が出ている ○ リトライなどによりログの重複などの問題 ● 担当者毎に認識の齟齬がある ○ 同じデータを取得しているつもりが、 担当者によって結果が違う ● データをBigQueryへ格納するジョブの安定性が低い ○ ジョブが失敗した際には利用できるまでに時間を要する ● など TIPSTARのデータ基盤への多くの課題 BigQuery Cloud Logging アプリログ
   の格納
 Looker 参照
 担当者 担当者 ダッシュボード参 照
 クエリ
 担当者 様々なソースの
 スプレッドシート
 Cloud Spanner 前日までの
  データ
   コピー


Slide 23

Slide 23 text

推進していくデータ基盤の改善 ● データの精度を高める ○ 異常なデータを検知、修正できる ○ 欲しい情報を誰が取得しても同じデータを取得できる状態へ ○ データウエアハウスなどの検討 ● データ基盤の信頼性、安定性の向上 ○ データレイクに必要なデータが決まったタイミングに格納されている状態へ ○ データ基盤のアーキテクチャの改修 ○ リトライなどエラーハンドリングしやすい構成を検討 ● など 理想

Slide 24

Slide 24 text

目先のデータ基盤改善 ● 精度の低いログを元にしたデータの利用の停止 ● 実データを利用する ○ Cloud Spanner federated queriesを利用 ■ BigQueryからCloud Spannerに直接クエリ可能 ■ 結果をキャッシュしLookerで参照 お金周りは半リアルタイムのデータを利用 Before BigQuery Cloud Logging アプリログ
   の格納
 Looker 参照
 Cloud Spanner 前日までの
  データ
   コピー
 担当者 After BigQuery Looker 参照
 Cloud Spanner 担当者 前日までの
  データ
   コピー
 Cloud Spanner本番DBから
 定期的に取得
 ● Lookerの機能を利用し、異常値を見つけたら担 当者への通知 品質の担保されたデータを使った施策 通知


Slide 25

Slide 25 text

データ基盤改善の今後 ● ログのフォーマット変更などをテストで検知で きるようにする ログの品質向上 ● メタデータを整備し扱いやすい状況を作る KPI用メタデータの整備とドキュメント化 ● データを取得する場所を整える データウエアハウスを整備

Slide 26

Slide 26 text

TIPSTAR のリスクに 気付く環境づくり

Slide 27

Slide 27 text

TIPSTARのリスク ● 運用していくなかで起きうること ○ レイテンシの低下、エラーなどにより快適に利用できなくなる ■ ユーザー、データの増加 ■ 大規模イベント ■ 大規模開発のリリース ○ セキュリティ ■ 脆弱性の存在やアタックなど ○ 先程の最適化されていないコストなども含まれる リスクとは

Slide 28

Slide 28 text

快適に利用できない可能性に気付く取り組み ● 監視システムによるアラート ○ システムの異常を検知できる ○ PagerDutyによる呼び出し ● 定期的にメトリクスを見る ○ 徐々に悪化しているものを見つける ○ イベント前後の負荷の変化 ○ 監視されていない、検知されない異常を見つける 気付くための取り組み

Slide 29

Slide 29 text

週1のメトリクスを見る会 ● Slack ハドルを利用 ○ ファシリの画面共有でダッシュボードを表示 ● 過去1、2週間の違和感に意見していく ● 出た意見はGitHub Issueにまとめる ○ 細かく追っていくものは個別Issue化 ○ 次回の会で確認すべき内容 ○ など Cloud Monitoringのダッシュボードをチームメンバーで眺める

Slide 30

Slide 30 text

週1のメトリクスを見る会の効果 ● インデックスの追加や、コードの修正に着手 性能が低下しているAPIの早期発見 ● TIPSTAR側で変更がなくても変化が起こりうる知見を得る Google Cloud起因での性能の変化に気づける ● 運用の経験から気にしていなかった値に、切り込んで意見を貰える ○ よくよく調べると問題が出ていた事も ○ ダッシュボードの良くないところの指摘 ● メトリクス見る勘所を共有する機会ができた 歴の長さに関係なく意見を出し合える

Slide 31

Slide 31 text

TIPSTARのリスクに気付く取り組みの今後 ● SLI/SLOを整備し重要な機能の状態を確認しやすい状態へ ○ ログなどの整備が必要 ● 監視の整理 ○ ノイズを減らし重要なものだけが通知されるようにする 異常に気付きやすい環境づくり ● 特定のメンバーだけではなく、チーム誰もが違和感に気付けるようにする ○ ダッシュボードの整理 ○ 更なる知見の共有 ○ など 引き続きメトリクスを見ていく

Slide 32

Slide 32 text

まとめ

Slide 33

Slide 33 text

チャレンジを続けていくための取り組みにより ● コスト最適化を行い、続けていくことで、コストに怯えず開発が続けられる インフラコスト最適化によりコストの障壁を取り除く ● 利用するデータの信頼性を高め、正しいデータを元に開発が続けられる データドリブンな組織のためのデータ基盤改善 ● 日々のモニタリングにより、開発運用に伴うリスクの肥大化を抑え、安定した開 発が続けられる TIPSTAR のリスクに気付く環境づくり