Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

動画:https://youtu.be/8XgbESz5LUc

https://techcon.mixi.co.jp/d3-8

MIXI ENGINEERS
PRO

March 03, 2023
Tweet

More Decks by MIXI ENGINEERS

Other Decks in Technology

Transcript

  1. 2023/03/03

    TIPSTAR開発部 システム2G アーキテクトチーム

    鈴木 進吾

    TIPSTARがチャレンジを続けていくために取り組んだこと
    〜MIXI TECH CONFERENCE 2023〜
    DAY3 D3-8

    View Slide

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

    View Slide

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

    View Slide

  4. TIPSTARとは

    View Slide

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

    View Slide

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

    View Slide

  7. システム2グループとは

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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日経過する前に

    経路を変更する事で 

    コスト削減を図る


    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

      の格納

    Looker
    参照

    担当者 担当者
    ダッシュボード参
    照
 クエリ

    担当者
    様々なソースの

    スプレッドシート

    Cloud Spanner
    前日までの

     データ

      コピー


    View Slide

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

    View Slide

  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の機能を利用し、異常値を見つけたら担
    当者への通知
    品質の担保されたデータを使った施策
    通知


    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  32. まとめ

    View Slide

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

    View Slide