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

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

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

TIPSTARとは

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

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

システム2グループとは

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

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

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

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

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

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

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

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

インフラコスト最適化へのアプローチ例（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日経過する前に
 経路を変更する事で 
 コスト削減を図る


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

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

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

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

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

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


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

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


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

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

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

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

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

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

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

まとめ

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