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/2023/d3-8

MIXI ENGINEERS

March 03, 2023
Tweet

More Decks by MIXI ENGINEERS

Other Decks in Technology

Transcript

  1. 自己紹介 • 鈴木進吾 / @mominosin • 2021年1月中途入社 • TIPSTAR開発部 システム2グループ

    ◦ アーキテクトチーム リーダー • 前職までずっと「AWS」で「Google Cloud」少々 • TIPSTARではずっと「Google Cloud」で「AWS」少々
  2. 内容 • TIPSTARとは • システム2グループとは • TIPSTARがチャレンジを続けていくための取り組み ◦ インフラコスト最適化によりコストの障壁を取り除く ◦

    データドリブンな組織のためにデータ基盤改善 ◦ TIPSTAR のリスクに気付く環境づくりなどの施策 • まとめ
  3. システム2グループが取り組んできたこと • インフラ ◦ Google Cloud(GKE、Cloud Spanner、BigQuery)の運用 ◦ Terraformの整理(Module化、tfsec導入) ◦

    CI/CD改善(Argo CD導入、CircleCI/GitHub Actionsの整備) ◦ セキュリティ対応(Renovate、Trivyの導入対応) • KPI計測の仕組みを整備 • ツールの整備 ◦ CI等で利用する静的解析ツールの作成、複雑なコマンドの生成 • 周辺システムの新規構築 ◦ 外部連携、管理画面 • コスト最適化 例
  4. インフラコスト(Google Cloud)最適化 • Spanner Autoscalerの導入 • GKEのpodリソース調整 • Cloud Storageの不要ファイルの削除(Docker

    Imageなど含む) • BigQueryに溜め込んでいるログをCloud Storage(Archive)へ移動 • など やったこと 優先度高く取り組んだタイミング • コストが理由で新しい施策を諦めなくて良い状態を作るため • 昨年の円安の影響を懸念
  5. インフラコスト最適化へのアプローチ例(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日経過する前に
 経路を変更する事で 
 コスト削減を図る

  6. インフラコスト最適化の今後 • 引き続きコストの推移を見守る • コスト感をフィードバックしチーム全体で把握できるようにする • お金だけでなく運用コストの最適化も進める 定期的にコストを確認していく • Google

    Cloudのアップデートの確認 • 確約利用割引(CUD)などの選択肢も検討する • 新機能実装時にはアーキテクチャのレビューでコストの妥当性も見ていく コスト削減を模索
  7. 参照先によってデータが異なる事も データ基盤改善をなぜ行うのか • 速報値として利用しているログの精度が低い ◦ お金に関わるところなどに影響が出ている ◦ リトライなどによりログの重複などの問題 • 担当者毎に認識の齟齬がある

    ◦ 同じデータを取得しているつもりが、 担当者によって結果が違う • データをBigQueryへ格納するジョブの安定性が低い ◦ ジョブが失敗した際には利用できるまでに時間を要する • など TIPSTARのデータ基盤への多くの課題 BigQuery Cloud Logging アプリログ
   の格納
 Looker 参照
 担当者 担当者 ダッシュボード参 照
 クエリ
 担当者 様々なソースの
 スプレッドシート
 Cloud Spanner 前日までの
  データ
   コピー

  8. 推進していくデータ基盤の改善 • データの精度を高める ◦ 異常なデータを検知、修正できる ◦ 欲しい情報を誰が取得しても同じデータを取得できる状態へ ◦ データウエアハウスなどの検討 •

    データ基盤の信頼性、安定性の向上 ◦ データレイクに必要なデータが決まったタイミングに格納されている状態へ ◦ データ基盤のアーキテクチャの改修 ◦ リトライなどエラーハンドリングしやすい構成を検討 • など 理想
  9. 目先のデータ基盤改善 • 精度の低いログを元にしたデータの利用の停止 • 実データを利用する ◦ Cloud Spanner federated queriesを利用

    ▪ BigQueryからCloud Spannerに直接クエリ可能 ▪ 結果をキャッシュしLookerで参照 お金周りは半リアルタイムのデータを利用 Before BigQuery Cloud Logging アプリログ
   の格納
 Looker 参照
 Cloud Spanner 前日までの
  データ
   コピー
 担当者 After BigQuery Looker 参照
 Cloud Spanner 担当者 前日までの
  データ
   コピー
 Cloud Spanner本番DBから
 定期的に取得
 • Lookerの機能を利用し、異常値を見つけたら担 当者への通知 品質の担保されたデータを使った施策 通知

  10. TIPSTARのリスク • 運用していくなかで起きうること ◦ レイテンシの低下、エラーなどにより快適に利用できなくなる ▪ ユーザー、データの増加 ▪ 大規模イベント ▪

    大規模開発のリリース ◦ セキュリティ ▪ 脆弱性の存在やアタックなど ◦ 先程の最適化されていないコストなども含まれる リスクとは
  11. 快適に利用できない可能性に気付く取り組み • 監視システムによるアラート ◦ システムの異常を検知できる ◦ PagerDutyによる呼び出し • 定期的にメトリクスを見る ◦

    徐々に悪化しているものを見つける ◦ イベント前後の負荷の変化 ◦ 監視されていない、検知されない異常を見つける 気付くための取り組み
  12. 週1のメトリクスを見る会 • Slack ハドルを利用 ◦ ファシリの画面共有でダッシュボードを表示 • 過去1、2週間の違和感に意見していく • 出た意見はGitHub

    Issueにまとめる ◦ 細かく追っていくものは個別Issue化 ◦ 次回の会で確認すべき内容 ◦ など Cloud Monitoringのダッシュボードをチームメンバーで眺める
  13. TIPSTARのリスクに気付く取り組みの今後 • SLI/SLOを整備し重要な機能の状態を確認しやすい状態へ ◦ ログなどの整備が必要 • 監視の整理 ◦ ノイズを減らし重要なものだけが通知されるようにする 異常に気付きやすい環境づくり

    • 特定のメンバーだけではなく、チーム誰もが違和感に気付けるようにする ◦ ダッシュボードの整理 ◦ 更なる知見の共有 ◦ など 引き続きメトリクスを見ていく