なぜWINTICKETはマイクロサービスをやめたのか

Transcript

1. なぜ WinTicket は マイクロサービスをやめたのか モジュラーモノリスへのリアーキテクチャ 表 陸人 MIU Tech Night / CyberAgent
2. 自己紹介 表 陸人 / Omote Rikuto 2024年新卒入社 WINTICKET サーバーチーム 開発リード MIU Tech Night / CyberAgent 2
3. 目次 1. WinTicket について 2. なぜモジュラーモノリスに？ 3. 移行方法 4. 学び 5. 今後の展望 MIU Tech Night / CyberAgent 3
4. 1. WinTicket について MIU Tech Night / CyberAgent
5. WINTICKET とは 競輪・オートレースのネット投票サービス 出走表・オッズ・ライブ映像も アプリの中で見られる 競輪投票サービスシェア No.1 競輪の市場規模は年間 約1.5兆円 MIU Tech Night / CyberAgent 5
6. サーバーチームの体制 バックエンド全体の開発・運用を7人で担当している サーバーチーム ↓ 開発・運用を担当 全員が全ドメインを見る 新機能の開発からオンコールまで担当する バックエンド全体 実行形態 RPC server Worker CronJob MIU Tech Night / CyberAgent 6
7. WinTicket のカルチャー「越境」 職種や役割にとらわれず、事業のために領域を越えて動く エンジニアやデザイナーが、自分でプロダクトの改善点を見つけて施策を立ち上げる ドメインごとのチームはない 全員が設計も実装もレビューもする サービス立ち上げ当初からの文化で、今後も変わる可能性は低い MIU Tech Night / CyberAgent 7
8. Before: マイクロサービス構成 業務領域ごとに1サービス。Go + gRPC で12サービス サービスの切り方 1サービスの中身（例: broker） レース情報 会員 投票・決済 キャンペーン keirin / autorace broker 通知 user promotion 予想 gRPC サーバー 1 Worker（Pub/Sub） 4 CronJob 30 messenger tipster ほか5サービス。gateway から各サービスへ gRPC で呼ぶ 投票1回のリクエストが gateway → broker → keirin とサービスをまたぐ MIU Tech Night / CyberAgent 本番全体（2026-02） ワークロード 117 Deployment 40 CronJob 77 コンテナイメージ17種 8
9. マイクロサービスへの印象 マイクロサービスってなんかカッコいいよね 2026年、入社2年半 2023年、内定者のころ よくわからんけど大規模サービスといえばマイクロ サービス なんか難しそう 技術的に学べること多そう（これは本当にそうでし た） なんか辛くね……？ MIU Tech Night / CyberAgent 9
10. 2. なぜモジュラーモノリスに？ MIU Tech Night / CyberAgent
11. 結論 開発体制に合わせたアーキテクチャへ MIU Tech Night / CyberAgent
12. マイクロサービスの利点を活かせていたか マイクロサービスの特徴とそれによる恩恵 観点 独立したデプロイ 独立した技術選択 独立した障害範囲 独立したスケーリング 独立した権限 私たちの場合 機能ごとに複数サービスの変更点を考慮して、順序を決める必要がある すべて Go で、言語を分ける必要がない 全サービスが互いに依存し、1つの障害が全体に波及しうる 必要ないのに、117のワークロードを個別に見積もっていた 活かせていた。各サービスが自分の DB とシークレットだけを扱えた 一方で、サービスメッシュや分散トレーシング、ネットワーク障害など、マイクロサービスによる複雑さは抱えていた MIU Tech Night / CyberAgent 12
13. モジュラーモノリスへの移行を決断 MIU Tech Night / CyberAgent
14. モジュラーモノリスとは 業務領域ごとのコードを分けたまま、同じプロセスで動かす 1つのデプロイ単位を業務領域ごとのモジュールに分け、公開したインターフェースだけで依存させる構成 Before After 別プロセスに分かれている プロセス A API の受付処理 ↓ ネットワーク越しの通信（gRPC） プロセス B 同じプロセスの中の関数呼び出し ▶ 1つのプロセス API の受付処理 ↓ 関数呼び出し モジュール モジュール間は interface を通して呼び出す モジュール MIU Tech Night / CyberAgent 14
15. 3. 移行方法 MIU Tech Night / CyberAgent
16. 構成の変化: サービスごとから実行形態ごとへ 同じ処理を、サービスで縦に束ねていたのをやめ、実行形態で横に束ねた Before: サービスごとにイメージ RPC server Worker CronJob 競輪 1 n n 投票・決済 1 n n 会員 1 n n ほか9サービス After: 実行形態ごとにイメージ ▶ … … … 枠1つが1サービス。サービス間は gRPC で54本の依存 競輪 投票・決済 会員 ほか9 api worker job module module module module module module module module module … … … 枠1つが1イメージ。モジュール間は関数呼び出し（gRPC 0本） MIU Tech Night / CyberAgent 16
17. 余談: Job 実行基盤の Scheduler Server を新設 別々に動かしていた定期処理・監視の15個を、1つの常駐プロセスに After Before CronJob 11個 監視などの常駐 4個 ▶ scheduler（常駐 Deployment 1個・3台） プロセス内の cron で19タスクを実行 それぞれにマニフェスト・リソース設定・監視が 必要 scheduler に載せるのは、冪等で短時間に終わる、頻度の高い処理 MIU Tech Night / CyberAgent 17
18. 本番切替: API の送信先を段階的に変更 サービスメッシュのルーティングで、リクエストを重みで旧構成と新構成に振り分けた ▶ 旧構成へ 重みを下げる アプリ・Web ▶ Istio VirtualService 重みで振り分け ▶ 新構成へ 重みを上げる MIU Tech Night / CyberAgent マイクロサービス gateway から gRPC で各サービス レース情報 投票・決済 会員 … モジュラーモノリス api の中で関数呼び出し レース情報 投票・決済 会員 … 18
19. 本番切替: Worker と Job Worker も Job も、新旧を同時に定義しておき、設定の変更だけで切り替えた Worker（Pub/Sub の常駐処理） Job（定時バッチ） 同じサブスクリプション 同じスケジュールの CronJob を2つ定義 ↓ メッセージを新旧で分け合う 旧 worker 台数を減らす ↓ どちらか一方だけを動かす 新 worker 旧 CronJob 台数を増やす 停止（suspend） 新を0台で追加して1台で開始し、比率を移して旧を0台にする 新 CronJob 有効 新旧の有効・無効を1つの PR で入れ替え、戻すときも同じ2行 MIU Tech Night / CyberAgent 19
20. プレモーテムで、失敗を先に洗い出す 本番切替の前に「リリースが失敗した」と仮定して、原因と発生時の対応を決めておいた ポストモーテムは、障害が起きた後に原因と再発防止策を振り返ること プレモーテムは、実施する前に「失敗した」と仮定して、考えられる原因と対応を洗い出すこと 進め方 1. リリースの前提を書き出す 2. 考えられる失敗をチームで1行ずつ挙げる （57件） 3. 1行ずつチケットにして担当者を決める 実際の1行（API の統合） 環境変数の設定漏れで、期待しない挙動にな 観測される事象 る 根本の原因 マイクロサービスとモノリスの設定のドリフト 重要度 高 事前の対策 E2E、API の網羅性確認、ドリフト検知 この事象は外部向け API を本番の5%にした当日に実際に起き、決めておいた対応どおり約20分で0%に戻した MIU Tech Night / CyberAgent 20
21. 4. 学び MIU Tech Night / CyberAgent
22. 学び①: 1つのアーキテクチャに縛られなくていい チームとして「どちらか」に決めず、部分ごとに合う形を選ぶ 1つの方式に揃える 全体をどちらかに決める 「うちはマイクロサービス」 「うちはモノリス」 部分ごとに選ぶ ▶ 本体はモノリス、性質の違う部分だけ分ける 選ぶときに見るもの チーム体制 リリース頻度 負荷 セキュリティ 条件が変われば、選び直す ドメイン 例: 外部システムとの接続を常に保つ部分は、リリースで接続が切れないよう別のサーバーで動かしている MIU Tech Night / CyberAgent 22
23. 学び②: 大きな移行ほど、確認を機械的なチェックに任せる 規模が大きいほど、人の確認より機械的なチェックの方が工数も見落としも少ない チェックのツールも、今は AI エージェ ントで手軽に作れる 今回 AI エージェントで作った例 新旧の環境変数の差分チェック API の網羅性チェック 人の確認 数工るかかに認確 人の確認は、物量・人数・期間が増えるほど工数 が増え、見落としも増える 機械的なチェックなら、規模が増えてもほぼ一定 機械的なチェックに任せる ※ イメージ 移行の規模（物量・人数・期間） MIU Tech Night / CyberAgent 23
24. 学び③: ミスは起きる前提で進める もしもの際に事業影響を小さくするためには？ 予防 範囲 復旧 プレモーテムで事前対策を決める 影響する範囲を絞る まず本番の5%だけ新構成へ切り替え る 早く気づく 異常の兆候を先に決め、新しい Job の失敗は担当者を呼び出す 早く戻す 発生時の対応を決めておき、約20分 で旧構成へ戻した 一度に全部を切り替え、気づくのも戻すのも遅い場合 範囲を絞る 囲範るす響影 検知 起きる回数を減らす 早く気づき、早く戻す 範囲と時間を縮めた影響 発生 検知 MIU Tech Night / CyberAgent 復旧 時間 24
25. 5. 今後の展望 MIU Tech Night / CyberAgent
26. アーキテクチャに合わせて仕組みを整える 開発・運用・セキュリティの仕組みはこれから 揃えたもの: アーキテクチャ モジュール間の gRPC 依存が0に 統合したモジュールを同じイメージで更新 管理するワークロード数を削減 これから揃えるもの リリースフロー ▶ コード規約 負荷試験基盤 権限の最小化 MIU Tech Night / CyberAgent 26
27. ご清聴ありがとうございました MIU Tech Night / CyberAgent