TIPSTARがチャレンジを続けていくために取り組んだこと【MIXI TECH CONFERENCE 2023】

MIXI TECH CONFERENCE 2023
にてお話した鈴木の資料です。

動画：https://youtu.be/8XgbESz5LUc
セッション詳細：https://techcon.mixi.co.jp/2023/d3-8

Transcript

1. 2023/03/03
 TIPSTAR開発部 システム2G アーキテクトチーム
 鈴木 進吾
 TIPSTARがチャレンジを続けていくために取り組んだこと 〜MIXI TECH CONFERENCE 2023〜 DAY3 D3-8
2. 自己紹介 • 鈴木進吾 / @mominosin • 2021年1月中途入社 • TIPSTAR開発部 システム２グループ ◦ アーキテクトチーム リーダー • 前職までずっと「AWS」で「Google Cloud」少々 • TIPSTARではずっと「Google Cloud」で「AWS」少々
3. 内容 • TIPSTARとは • システム2グループとは • TIPSTARがチャレンジを続けていくための取り組み ◦ インフラコスト最適化によりコストの障壁を取り除く ◦ データドリブンな組織のためにデータ基盤改善 ◦ TIPSTAR のリスクに気付く環境づくりなどの施策 • まとめ
4. TIPSTARとは
5. TIPSTARとは TIPSTAR TIPSTARとは、365日配信されるレース映像と、 競輪・PIST6・オートレースのネット投票を、 基本無料で楽しむことができるサービスです。
6. TIPSTARと周辺の構成 各場の映像 AI による 映像編集 ユーザ・決済基盤 競輪・オートレース PIST6 認証・認可・決済 etc. レース情報取得・投票 レース情報取得・投票 ユーザ
7. システム2グループとは
8. TIPSTAR開発部 システム2グループとは • ユーザが安全かつ快適に使えるサービスを提供する • 開発組織が自律的に課題解決できる開発基盤と文化をつくる • 事業成長を阻害するリスクやコストを技術を用いて減らし、最適化する システム2グループのミッション • システム１グループ：TIPSTAR本体の開発運用 • システム２グループ：開発組織のサポート TIPSTAR開発部のサーバーサイドの開発グループの１つ
9. システム2グループが取り組んできたこと • インフラ ◦ Google Cloud(GKE、Cloud Spanner、BigQuery)の運用 ◦ Terraformの整理（Module化、tfsec導入） ◦ CI/CD改善（Argo CD導入、CircleCI/GitHub Actionsの整備） ◦ セキュリティ対応（Renovate、Trivyの導入対応） • KPI計測の仕組みを整備 • ツールの整備 ◦ CI等で利用する静的解析ツールの作成、複雑なコマンドの生成 • 周辺システムの新規構築 ◦ 外部連携、管理画面 • コスト最適化 例
10. TIPSTARがチャレンジを 続けていくための取り組み
11. チャレンジを続けていくための状態を作る取り組み • その状態を作るためのシステム２グループのミッション ◦ 事業成長を阻害するリスクやコストは技術を用いて減らし、最適化する ◦ 開発組織が自律的に課題解決できる開発基盤と文化をつくる ◦ ユーザが安全かつ快適に使えるサービスを提供する 開発組織が本来立ち向かうべき課題に注力できる状態 • インフラコスト最適化によりコストの障壁を取り除く • データドリブンな組織のためのデータ基盤改善 • TIPSTAR のリスクに気付く環境づくり 取り組んでいる内容（本発表の本題）
12. インフラコスト最適化に よりコスト障壁を取り除く
13. インフラコスト(Google Cloud)最適化 • Spanner Autoscalerの導入 • GKEのpodリソース調整 • Cloud Storageの不要ファイルの削除（Docker Imageなど含む） • BigQueryに溜め込んでいるログをCloud Storage(Archive)へ移動 • など やったこと 優先度高く取り組んだタイミング • コストが理由で新しい施策を諦めなくて良い状態を作るため • 昨年の円安の影響を懸念
14. インフラコスト最適化へのアプローチ例（1/4） • サービス利用料TOP10を見る ◦ 利用料が高いところのほうが選択肢が 多いしコスパが良い 愚直にがんばる
15. インフラコスト最適化へのアプローチ例（2/4） 引き続き愚直にがんばる • TOP10の詳細（SKU）を見ていく ◦ BigQueryの例では以下のコストが高い ▪ 長期保存用ストレージ • Long Term Logical Storage
16. インフラコスト最適化へのアプローチ例（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日経過する前に
 経路を変更する事で 
 コスト削減を図る

17. インフラコスト最適化へのアプローチ例（4/4） • 監査ログをBigQueryに保存する期間を１ヶ月にする • 監査ログをBigQueryからCloud Storageへ移動するジョブを作成 実際にコストを下げる対応 • Long Term Logical Storageの減少（青） • Archive Storageの微増（紫） • 6月と9月を比較し半減 対応の結果
18. アプローチの結果 • 本番環境ではピークと比較して大幅に削減 • 開発環境も本番環境ほどではないが削減 ドルベースで大幅なコストの削減を実現
19. その他アプローチ • 新機能によりコスト削減の手法が打てることも 最新のアプデを確認する • 推奨事項の確認 ◦ 不要なリソースが確認できる ◦ 確約利用割引(CUD)の提案を確認できる Google Cloudの機能を利用する
20. インフラコスト最適化の今後 • 引き続きコストの推移を見守る • コスト感をフィードバックしチーム全体で把握できるようにする • お金だけでなく運用コストの最適化も進める 定期的にコストを確認していく • Google Cloudのアップデートの確認 • 確約利用割引（CUD）などの選択肢も検討する • 新機能実装時にはアーキテクチャのレビューでコストの妥当性も見ていく コスト削減を模索
21. データドリブンな組織 のためのデータ基盤改善
22. 参照先によってデータが異なる事も データ基盤改善をなぜ行うのか • 速報値として利用しているログの精度が低い ◦ お金に関わるところなどに影響が出ている ◦ リトライなどによりログの重複などの問題 • 担当者毎に認識の齟齬がある ◦ 同じデータを取得しているつもりが、 担当者によって結果が違う • データをBigQueryへ格納するジョブの安定性が低い ◦ ジョブが失敗した際には利用できるまでに時間を要する • など TIPSTARのデータ基盤への多くの課題 BigQuery Cloud Logging アプリログ
 　　の格納
 Looker 参照
 担当者 担当者 ダッシュボード参 照
 クエリ
 担当者 様々なソースの
 スプレッドシート
 Cloud Spanner 前日までの
 　データ
 　　コピー

23. 推進していくデータ基盤の改善 • データの精度を高める ◦ 異常なデータを検知、修正できる ◦ 欲しい情報を誰が取得しても同じデータを取得できる状態へ ◦ データウエアハウスなどの検討 • データ基盤の信頼性、安定性の向上 ◦ データレイクに必要なデータが決まったタイミングに格納されている状態へ ◦ データ基盤のアーキテクチャの改修 ◦ リトライなどエラーハンドリングしやすい構成を検討 • など 理想
24. 目先のデータ基盤改善 • 精度の低いログを元にしたデータの利用の停止 • 実データを利用する ◦ Cloud Spanner federated queriesを利用 ▪ BigQueryからCloud Spannerに直接クエリ可能 ▪ 結果をキャッシュしLookerで参照 お金周りは半リアルタイムのデータを利用 Before BigQuery Cloud Logging アプリログ
 　　の格納
 Looker 参照
 Cloud Spanner 前日までの
 　データ
 　　コピー
 担当者 After BigQuery Looker 参照
 Cloud Spanner 担当者 前日までの
 　データ
 　　コピー
 Cloud Spanner本番DBから
 定期的に取得
 • Lookerの機能を利用し、異常値を見つけたら担 当者への通知 品質の担保されたデータを使った施策 通知

25. データ基盤改善の今後 • ログのフォーマット変更などをテストで検知で きるようにする ログの品質向上 • メタデータを整備し扱いやすい状況を作る KPI用メタデータの整備とドキュメント化 • データを取得する場所を整える データウエアハウスを整備
26. TIPSTAR のリスクに 気付く環境づくり
27. TIPSTARのリスク • 運用していくなかで起きうること ◦ レイテンシの低下、エラーなどにより快適に利用できなくなる ▪ ユーザー、データの増加 ▪ 大規模イベント ▪ 大規模開発のリリース ◦ セキュリティ ▪ 脆弱性の存在やアタックなど ◦ 先程の最適化されていないコストなども含まれる リスクとは
28. 快適に利用できない可能性に気付く取り組み • 監視システムによるアラート ◦ システムの異常を検知できる ◦ PagerDutyによる呼び出し • 定期的にメトリクスを見る ◦ 徐々に悪化しているものを見つける ◦ イベント前後の負荷の変化 ◦ 監視されていない、検知されない異常を見つける 気付くための取り組み
29. 週1のメトリクスを見る会 • Slack ハドルを利用 ◦ ファシリの画面共有でダッシュボードを表示 • 過去1、2週間の違和感に意見していく • 出た意見はGitHub Issueにまとめる ◦ 細かく追っていくものは個別Issue化 ◦ 次回の会で確認すべき内容 ◦ など Cloud Monitoringのダッシュボードをチームメンバーで眺める
30. 週1のメトリクスを見る会の効果 • インデックスの追加や、コードの修正に着手 性能が低下しているAPIの早期発見 • TIPSTAR側で変更がなくても変化が起こりうる知見を得る Google Cloud起因での性能の変化に気づける • 運用の経験から気にしていなかった値に、切り込んで意見を貰える ◦ よくよく調べると問題が出ていた事も ◦ ダッシュボードの良くないところの指摘 • メトリクス見る勘所を共有する機会ができた 歴の長さに関係なく意見を出し合える
31. TIPSTARのリスクに気付く取り組みの今後 • SLI/SLOを整備し重要な機能の状態を確認しやすい状態へ ◦ ログなどの整備が必要 • 監視の整理 ◦ ノイズを減らし重要なものだけが通知されるようにする 異常に気付きやすい環境づくり • 特定のメンバーだけではなく、チーム誰もが違和感に気付けるようにする ◦ ダッシュボードの整理 ◦ 更なる知見の共有 ◦ など 引き続きメトリクスを見ていく
32. まとめ
33. チャレンジを続けていくための取り組みにより • コスト最適化を行い、続けていくことで、コストに怯えず開発が続けられる インフラコスト最適化によりコストの障壁を取り除く • 利用するデータの信頼性を高め、正しいデータを元に開発が続けられる データドリブンな組織のためのデータ基盤改善 • 日々のモニタリングにより、開発運用に伴うリスクの肥大化を抑え、安定した開 発が続けられる TIPSTAR のリスクに気付く環境づくり