なぜ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. サーバーチームの体制 バックエンド全体の開発・運用を 8人で担当している サーバーチーム ↓ 開発・運用を担当 全員が全ドメインを見る バックエンド全体 新機能の開発からオンコールまで担当する 実行形態 RPC server Worker CronJob MIU Tech Night / CyberAgent 6
7. WinTicket のカルチャー「越境」 職種や役割にとらわれず、事業のために領域を越えて動く エンジニアやデザイナーが、自分でプロダクトの改善点を見つけて施策を立ち上げる ドメインごとのチームはない 全員が設計も実装もレビューもする サービス立ち上げ当初からの文化で、今後も変わる可能性は低い MIU Tech Night / CyberAgent 7
8. Before: マイクロサービス構成 業務領域ごとに 1サービス。 Go + gRPC で12サービス サービスの切り方 レース情報 keirin / autorace 1サービスの中身（例 : broker） 会 員 user 投票・決済 キャンペーン broker promotion 通 知 messenger gRPC サーバー 1 Worker（Pub/Sub） 4 本番全体（2026-02） ワークロード 117 CronJob 30 Deployment 40 CronJob 77 コンテナイメージ17種 予 想 tipster 投票1回のリクエストが gateway → broker → keirin とサービスをまたぐ MIU Tech Night / CyberAgent 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 1つのプロセス API の受付処理 ▶ API の受付処理 ↓ 関数呼び出し ↓ ネットワーク越しの通信（gRPC） モジュール プロセス B モジュール間は interface を通して呼び出す モジュール API・Worker・Job のそれぞれで、モジュールを1つのプロセスに統合。同居するモジュールは一緒にデプロイ・スケールし、不 具合の影響も互いに及ぶ MIU Tech Night / CyberAgent 14
15. 3. 移行方法 MIU Tech Night / CyberAgent
16. 構成の変化: サービスごとから実行形態ごとへ 同じ処理を、サービスで縦に束ねていたのをやめ、実行形態で横に束ねた After: 実行形態ごとにイメージ Before: サービスごとにイメージ 競輪 投票・決済 RPC server Worker CronJob 1 n n 1 n n 会員 1 n n ほか9サービス … … … ▶ api worker job 競輪 module module module 投票・決済 module module module 会員 module module module ほか9 … … … 枠1つが1イメージ。モジュール間は関数呼び出し （gRPC 0本） 枠1つが1サービス。サービス間は gRPC で54本の依存 サービス間通信とモジュール間関数呼び出しをDIによって制御できるように中間レイヤー(adapter層)を作成 必要最低限の変更で利アーキテクチャが可能に MIU Tech Night / CyberAgent 16
17. 余談: ジョブ実行基盤の scheduler を新設 別々に動かしていた定期処理・監視の 15個を、1つの常駐プロセスに集めた After Before scheduler（常駐 Deployment 1個・3台） CronJob 11個 監視などの常駐 4個 ▶ プロセス内の cron で19タスクを実行 リーダー選出で、動かすのは3台のうち1台だけ それぞれにマニフェスト・リソース設定・監視が ある 15個のワークロードが1個になった scheduler に載せるのは、冪等で短時間に終わる、頻度の高い処理 ⻑時間・非冪等・外部への副作用が強い処理は、job（CronJob）に残した MIU Tech Night / CyberAgent 17
18. 本番切替: API の送信先を段階的に変更 サービスメッシュのルーティングで、リクエストを重みで旧構成と新構成に振り分けた マイクロサービス ▶ 旧構成へ 重みを下げる レース情報 Istio VirtualService アプリ・ Web ▶ gateway から gRPC で各サービス 投票・決済 会員 … 重みで振り分け モジュラーモノリス ▶ 新構成へ 重みを上げる api の中で関数呼び出し レース情報 MIU Tech Night / CyberAgent 投票・決済 会員 … 18
19. 本番切替: Worker と Job Worker も Job も、新旧を同時に定義しておき、設定の変更だけで切り替えた Worker（Pub/Sub の常駐処理） Job（定時バッチ） 同じサブスクリプション 同じスケジュールの CronJob を2つ定義 ↓ メッセージを新旧で分け合う ↓ どちらか一方だけを動かす 旧 worker 新 worker 旧 CronJob 新 CronJob 台数を減らす 台数を増やす 停止（suspend） 有効 新を0台で追加して1台で開始し、比率を移して旧を0台にする 新旧の有効・無効を1つの PR で入れ替え、戻すときも同じ2行 二重実行できない Job は、新旧が同時に動かないようにした。旧構成の定義は切替後もしばらく残した MIU Tech Night / CyberAgent 19
20. プレモーテムで、失敗を先に洗い出す 本番切替の前に「リリースが失敗した」と仮定して、原因と発生時の対応を決めておいた ポストモーテム は、障害が起きた後に原因と再発防止策を振り返ること プレモーテム は、実施する前に「失敗した」と仮定して、考えられる原因と対応を洗い出すこと 実際の1行（API の統合） 進め 方 環境変数の設定漏れで、期待しない挙動になる 1. リリースの前提を書き出す 観測される事象 2. 考えられる失敗をチームで1行ずつ挙げる （57件） 根本の原因 マイクロサービスとモノリスの設定のドリフト 重要度 高 事前の対策 E2E、API の網羅性確認、ドリフト検知 3. 1行ずつチケットにして担当者を決める この事象は外部向け 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