何も知らない課金システムを移行した話

BuriKaigi 2024でお話しました。

Transcript

1. 相生ゆら/Little_Rubyist
 何も知らない課金システ ムを移行した話

2. 自己紹介
 今回話す人 相生ゆら/Little_Rubyist @Little_Rubyist @Little-Rubyist 2023/02~ Lrama/RBS/RuboCop ニコニコ漫画のバックエンド開発
3. LTデビューも登壇デビューも 地元でうれしいです🎉🎉
4. 自己紹介
 今回話す人 相生ゆら/Little_Rubyist @Little_Rubyist @Little-Rubyist 2023/02~ Lrama/RBS/RuboCop ニコニコ漫画のバックエンド開発
5. 自己紹介
 今回話す人 相生ゆら/Little_Rubyist @Little_Rubyist @Little-Rubyist 2023/02~ Lrama/RBS/RuboCop ニコニコ漫画のバックエンド開発 一年経っていない！
6. 入社2ヶ月でドメイン知識何もないのに
 課金システムの移行をした話

7. 対象にしたい人
 - チームに新しい人が入ってきたときの馴染ませ方を知りたい人 
 - （完全新規ではなく）既存プロジェクトを改修することに慣れていない人 
 
 
 
 
 
 伝えたいこと
 - 新参者は何が不安に繋がるのか、どういうことをすると馴染んでいけるのか 
 - 新参者がやってもらえて嬉しかったこと 
 - サービスを動かしたまま改修する時に意識したこと 
 今回の目標

8. - 前提条件: ニコニコ漫画について 
 - 何をしたのか
 - 今まではどうで、今回の移行でどう変わったのか 
 - どう開発したのか
 - 開発手順と気にしたこと 
 - 入社間もないと分からないこと 
 - よかった/悪かった小咄 
 - これから
 おしながき

9. ニコニコ漫画とは？

10. - コインで漫画を買ったり、作者や作品を応援したりできる 
 - コインはスマホアプリからのみ購入できる 
 - AppleやGoogle Play決済を経由する 
 ニコニコ漫画とは？
 コンテンツ購入 応援ギフト購入
11. 課金システム
 今までとこれから

12. ドワンゴ ブックウォーカー 今まで
 Payment Infrastructure System Payment Subsystem New Rails App PHP user
13. ドワンゴ ブックウォーカー Payment Infrastructure System Payment Subsystem New Rails App PHP user 今まで
 ニコニコ静画から 切り離したもの 様々な課題があるので RailsAppに移植中
14. ドワンゴ ブックウォーカー Payment Infrastructure System Payment Subsystem New Rails App PHP user 今まで
 私が一番触っている部分 テストを書いて 一貫性を担保しつつ PHPからの移植を行う
15. ドワンゴ ブックウォーカー Payment Infrastructure System Payment Subsystem New Rails App PHP user 今まで
 今回の主役 コンテンツ購入などを 処理、管理している Railsで書かれている
16. ドワンゴ ブックウォーカー Payment Infrastructure System Payment Subsystem New Rails App PHP user 今まで
 ドワンゴ側の決済基盤 コインの購入処理や 残高管理をしている
17. ブックウォーカー Payment Subsystem New Rails App PHP user これから
 決済基盤の機能や 検証の機能を持つ
18. 開発しよう

19. - 事前設計
 - 並行運用前に実装出来る部分を実装 
 - 並行運用の開始
 - 移行元にあるデータをmigrationする 
 - 残高などの情報を移行先で用意する 
 - 不整合確認
 - 並行運用の終了
 開発おしながき

20. - 並行運用をしながら開発したい 
 - サービスを止めたくなかった 
 - サービスメンテしてえいやっとリリースするのも検討した 
 - やっぱりこわいよね……となった 
 - 少しずつ試したい
 - お金周りなので慎重にやりたい 
 なぜこの順番なのか？

21. - 事前設計
 - 並行運用前に実装出来る部分を実装 
 - 並行運用の開始
 - 移行元にあるデータをmigrationする 
 - 残高などの情報を移行先で用意する 
 - 不整合確認
 - 並行運用の終了
 開発おしながき

22. タスクの洗い出し
 - 実際の運用で何が使われているか整理 
 DB設計
 - 移行元の構造をベースに関連付けやindexを設計 
 - enum値も分かりやすいものに変更 
 事前設計

23. - 背景を知らないとどのAPIが必要か判断出来ない 
 - チームメンバーに説明してもらいながらタスクを作った 
 - ここでしっかり全体像を確認出来たのでその後の開発が楽になった 
 - DB構造など、最終的にほしい状態を最初に共有できた 
 事前設計 - 当時のお気持ち

24. - 事前設計
 - 並行運用前に実装出来る部分を実装 
 - 並行運用の開始
 - 移行元にあるデータをmigrationする 
 - 残高などの情報を移行先で用意する 
 - 不整合確認
 - 並行運用の終了
 開発おしながき

25. - Apple/Google Playのレシート検証 
 - 自分たちのコードは影響しないので開発しやすい 
 - エラーが出たとしても追いやすい 
 - 購入系APIやコイン付与などINSERTが伴う処理 
 - 移行元と移行先両方に処理を走らせる 
 - 並行運用の開始
 - 後からやる作業を減らす+検証時間の確保 
 開発

26. - ドメイン知識がなくても開発出来るので、 成功体験を得られる 
 - 明確に成果が出るので、貢献したという実感がある 
 - 個人的にはこれがとても嬉しかったです :) 
 - ドメイン依存の部分も簡単な部分から実装することで導入が容易 
 - transactionなどの気にしたいところはメンバーに教えてもらった 
 開発 - 当時のお気持ち

27. - 事前設計
 - 並行運用前に実装出来る部分を実装 
 - 並行運用の開始
 - 移行元にあるデータをmigrationする 
 - 残高などの情報を移行先で用意する 
 - 不整合確認
 - 並行運用の終了
 開発おしながき

28. - TSVをS3に置いて、それをAuroraにインポートする 
 - 参考：Amazon S3 バケットのテキストファイルから Amazon Aurora MySQL DB クラスターへの データのロード
 - 問題が色々起こって大変だった 
 - TSVとDBのレコードでPKが重複したときにtable lockされてアプリ側がエラー 
 - LOAD DATAがtransactionをずっと掴んでいるせい 
 - 重複の可能性がある期間のデータはRubyを経由させた 
 - データに想定していない重複や不足が見つかった 
 - 後から見つかったので何度かmigrationをやり直した 
 - 1ヶ月くらいかけた
 データmigration

29. - 移行元の仕様に影響するのでややこしい 
 - 把握する必要のある範囲が広い 
 - 調査漏れで後から3種類くらい変なデータパターンを見つけた 
 - 終わったと思っても新たに見つかって、当時は結構辛かった 
 - 発見しても誰も責めずに粛々と対応していた 
 - 雰囲気が重くならない 
 - 一度立ち止まって原因や影響範囲、対応を考える時間を取った 
 - お金のことなので運営側とも相談 
 - 調査の途中で、思考の整理にもなって良かった 
 データmigration - 当時のお気持ち

30. - 事前設計
 - 並行運用前に実装出来る部分を実装 
 - 並行運用の開始
 - 移行元にあるデータをmigrationする 
 - 残高などの情報を移行先で用意する 
 - 不整合確認
 - 並行運用の終了
 開発おしながき

31. - コンテンツ購入のコイン消費処理 
 - コイン失効処理
 - 残高情報やコイン購入履歴の情報取得API 
 - migrationが終わらないと用意できなかった 
 - 移行元と移行先両方で処理をする 
 残りの処理実装

32. - この時点では慣れてきてるので困ることはそんなにない 
 - モブプロでの開発にも馴染んでいる頃 
 - 両方に処理を通すので順番に気をつかった 
 - ここもモブプロで間違ってたら教えてもらえるので安心 
 - 既にPRをたくさん出せているのでチームの一員感がある 
 - 小さくPRを切っていたのでPR量が多かった 
 残りの処理実装 - 当時のお気持ち

33. - 事前設計
 - 並行運用前に実装出来る部分を実装 
 - 並行運用の開始
 - 移行元にあるデータをmigrationする 
 - 残高などの情報を移行先で用意する 
 - 不整合確認
 - 並行運用の終了
 開発おしながき

34. 不整合調査
 - 購入後に移行元と移行先で残高が一致するか確認 
 - ズレてたらSlack通知 
 - コインの消費でズレたものを検知したい 
 並行運用と切り替え 
 - フラグなどを利用して段階的に開放 
 - 使わなくなったコードはお掃除 
 - API/テストの削除
 - 並行運用のために分離させていた部分のリファクタ 
 - transactionもこの段階で正しく設定する 
 お片付け

35. お片付け - 当時のお気持ち
 - 不整合データを持つユーザー以外は問題なし 
 - 切り離し後対応なので想定通り 
 - ゴリゴリ消すの気持ちいい 
 - やりきった実感がある 
 - とはいえ消すのは不安だけど、モブプロで人の目が常にあるので安心 
 - 別でPRのレビューも入る 
 無事に終わった～！
36. - 集計出来るようにBigQueryにデータを流し込む 
 - LookerStudioでの統計表示 
 - テーブル構造が少し複雑なので、エンジニアが要望に合わせて用意 
 - 統計用のテーブルを用意して、スケジュールクエリを設定 
 その後

37. まとめ
 入社したてで困ったこと

38. - 環境構築ドキュメントが更新されていない 問題
 - AWSで何をやるにも権限不足になっていた 
 - READMEが古くて情報不足 
 - コアタイム外何したらいいか分からない 問題
 - ドメイン知識がないとタスクも拾えない 
 - メンバーの休みで一緒に休んだら有給がごりごり減った 
 - 入社したては有給が少ない 
 - チーム外の人とのMTG何もわからん 問題
 - 会話を止めて質問しにくい 
 - これは今でも結構ある 
 - MTG後に質問してカバー 
 入社したての困りごと

39. まとめ
 良かったこと悪かったこと

40. よかった
 - コアタイム中のモブプロ
 - 分からないところは全部聞ける 
 - 一般的な処理からの実装
 - 入社直後でも貢献できる 
 - テストを書く習慣がある
 - ドキュメントの代わりをしてくれる 
 - 「自由に勉強していいよ」時間
 - 足りない部分を補える 
 - 前提知識を要求しない
 - 一般的な知識でも1から説明する 
 - 知らない/わからない は言いにくい
 （強いて言うなら）わるかった 
 - コアタイム外の作業がしにくい
 - 前述のとおり
 - モブプロ、分からない所だと黙りがち
 見てるだけだと貢献できてないな…とな る
 - 今はあまり気になっていない 
 - 大きな案件は情報が雪崩になる
 - 多分前にも聞いたけど忘れたな…が結 構発生した
 - 馴染むためにも、最初は小さいタスク からやるべき
 まとめ

41. - LookerStudioの整備 
 - 現状クエリが大きくなりがち 
 - 最終的には非エンジニアも気軽に触れるようにしたい 
 - DBのテーブル整理
 - 今回の移行で既存テーブルが統合出来るように 
 - テーブル構造をいじるのは丁寧にやりたい 
 - etc……
 - 私が把握していないだけで多分いっぱいある 
 今後やらないといけないこと
 もうすぐ丸1年なので2年目も がんばるぞい٩( 'ω' )و
42. ご清聴ありがとうございました！ 富山市のガラス美術館、 富山県内のお手軽観光地として 一生推してるので行ってください 2024-01-20 相生ゆら