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

by Yla Aioi

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

自己紹介  今回話す人相生ゆら/Little_Rubyist @Little_Rubyist @Little-Rubyist 2023/02~ Lrama/RBS/RuboCop ニコニコ漫画のバックエンド開発

Slide 3

Slide 3 text

LTデビューも登壇デビューも地元でうれしいです🎉🎉

Slide 4

Slide 4 text

自己紹介  今回話す人相生ゆら/Little_Rubyist @Little_Rubyist @Little-Rubyist 2023/02~ Lrama/RBS/RuboCop ニコニコ漫画のバックエンド開発

Slide 5

Slide 5 text

自己紹介  今回話す人相生ゆら/Little_Rubyist @Little_Rubyist @Little-Rubyist 2023/02~ Lrama/RBS/RuboCop ニコニコ漫画のバックエンド開発一年経っていない！

Slide 6

Slide 6 text

入社2ヶ月でドメイン知識何もないのに  課金システムの移行をした話 

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

ニコニコ漫画とは？ 

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

課金システム  今までとこれから 

Slide 12

Slide 12 text

ドワンゴブックウォーカー今まで  Payment Infrastructure System Payment Subsystem New Rails App PHP user

Slide 13

Slide 13 text

ドワンゴブックウォーカー Payment Infrastructure System Payment Subsystem New Rails App PHP user 今まで  ニコニコ静画から切り離したもの様々な課題があるので RailsAppに移植中

Slide 14

Slide 14 text

ドワンゴブックウォーカー Payment Infrastructure System Payment Subsystem New Rails App PHP user 今まで  私が一番触っている部分テストを書いて一貫性を担保しつつ PHPからの移植を行う

Slide 15

Slide 15 text

ドワンゴブックウォーカー Payment Infrastructure System Payment Subsystem New Rails App PHP user 今まで  今回の主役コンテンツ購入などを処理、管理している Railsで書かれている

Slide 16

Slide 16 text

ドワンゴブックウォーカー Payment Infrastructure System Payment Subsystem New Rails App PHP user 今まで  ドワンゴ側の決済基盤コインの購入処理や残高管理をしている

Slide 17

Slide 17 text

ブックウォーカー Payment Subsystem New Rails App PHP user これから  決済基盤の機能や検証の機能を持つ

Slide 18

Slide 18 text

開発しよう 

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

お片付け - 当時のお気持ち  - 不整合データを持つユーザー以外は問題なし   - 切り離し後対応なので想定通り   - ゴリゴリ消すの気持ちいい   - やりきった実感がある   - とはいえ消すのは不安だけど、モブプロで人の目が常にあるので安心   - 別でPRのレビューも入る   無事に終わった～！

Slide 36

Slide 36 text

- 集計出来るようにBigQueryにデータを流し込む   - LookerStudioでの統計表示   - テーブル構造が少し複雑なので、エンジニアが要望に合わせて用意   - 統計用のテーブルを用意して、スケジュールクエリを設定   その後 

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

- LookerStudioの整備   - 現状クエリが大きくなりがち   - 最終的には非エンジニアも気軽に触れるようにしたい   - DBのテーブル整理  - 今回の移行で既存テーブルが統合出来るように   - テーブル構造をいじるのは丁寧にやりたい   - etc……  - 私が把握していないだけで多分いっぱいある   今後やらないといけないこと  もうすぐ丸1年なので2年目もがんばるぞい٩( 'ω' )و

Slide 42

Slide 42 text

ご清聴ありがとうございました！富山市のガラス美術館、富山県内のお手軽観光地として一生推してるので行ってください 2024-01-20 相生ゆら