エンジニア1年生が10万ユーザーのプロダクトを運用してみた結果

エンジニア1年生が10万ユーザーのプロダクトを 運用してみた結果 Finatext @takuma5884rbb © 2024 Finatext Holdings Ltd.

Agenda ● 自己紹介 ● 2023年度にやったこと ● 体験したこと① ● 体験したこと② ● まとめ © 2024 Finatext Holdings Ltd. 1

自己紹介 ● 小林拓磨 ● 2023 (株)Finatext 入社 ● ソフトウェアエンジニア ○ Goを用いたアプリケーション開発 ○ AWS, Terraformを用いたインフラ運用 ○ 最近はフロント(Vue3)もちょっと ● 短期インターンの企画 ● 趣味 ○ 料理 ○ 日本酒・クラフトビール © 2024 Finatext Holdings Ltd. 2

私が2023年度にやったこと ● 金融商品を扱うサービスのフロントアプリから業務システムまでフルリプレース ○ 主要機能の実装からサービスイン、本番運用を経験 ● リプレースなので、サービスインから10万人程度のユーザーを抱えている ● 主につみたて周りでいくつかのバッチ処理が必要 ⇨そこで得た教訓をお話しします！ © 2024 Finatext Holdings Ltd. 3

私が2023年度にやったこと ● つみたて発注フロー © 2024 Finatext Holdings Ltd. 4

体験したこと①：バッチの実行時間という制約 ● バッチの処理時間は短ければ短いほどいい ○ Inputの締めはサービス仕様として存在する ○ 社外のシステムに接続する場合はOutputの締めも ○ そうでなくても、リカバリの際に時間がかかると運用負荷がかかる © 2024 Finatext Holdings Ltd. 5

体験したこと①：バッチの実行時間という制約 ● 開発都合による問題点 ○ 開発スケジュールの都合で、アプリ用APIで利用していた機能（＝1ユーザーを対象とした 処理）をバッチにも使いまわしていた ○ 1ユーザーずつ処理しているのでは時間がかかる ■ 特に外接との通信時間が支配的 ○ Goは並列処理が得意 ■ goroutine生やしてchannelで並列数だけ制御しておけばOK →アプリ用の処理を1人ずつ回し、それを並列化していた © 2024 Finatext Holdings Ltd. 6

体験したこと①：バッチの実行時間という制約 ● 実際に運用してみて...... ○ 無理やり早くするのではボロが出る ■ map同時に触ってバグる ■ channel解放し忘れてた...... ■ 外接先の負荷が上がって落ちる ○ テスト段階で気づくには？ ■ Dryrun、もしくはStaging環境に本番同等のデータを仕込む ● 性能面のチェック ● 本番データを匿名化しつつクローンする→本番に近い状態でテストする ○ https://github.com/nucleuscloud/neosync © 2024 Finatext Holdings Ltd. 7

• https://github.com/nucleuscloud/neosync

体験したこと②：リカバリを通して学んだこと ● データ構造 ○ 締め時間（＝過去のある時点）でのデータで処理をするので、「ある時点でのスナップショッ ト」で処理を行うことが必要 ○ データ構造としてはステータスの履歴を持っておいて、スナップショットはロジックで計算す るようにしていた ■ スナップショットがクエリでパッとわからず、リカバリ時に困った（思ったよりスナップ ショットのデータが必要だった） ● 後から追うことを意識したデータも用意しておけばよかった © 2024 Finatext Holdings Ltd. 8

まとめ ● バッチ処理にはソフトウェア開発のエッセンスが詰まっている ○ 設計：必要なデータは何か、ロジックはどうコードに落とし込めるか ○ DB：集計のクエリ、そもそものデータ構造 ● 自分で実装したものを自分で運用することで、エンジニアとして実感を持って成長できた ○ 自分で運用するので、「どういう場合に」「どういうデータが欲しいか」がわかる ○ 自分事で運用負荷を減らしたくなる © 2024 Finatext Holdings Ltd. 9

Appendix：履歴を持つデータ・テーブル構造 注文ID 注文ID 設定ID ステータス （有効・停止） 作成時間 作成時間 注文ID ステータス （有効・停止） 注文のステータスが変わると、ス テータステーブルに新しい レコードができる 作成時間 © 2024 Finatext Holdings Ltd. 11

Appendix：履歴を持つデータ・テーブル構造 注文ID 注文ID 設定ID ステータス （有効・停止） 作成時間 作成時間 バッチでは締め時間以前での 最新を採用する 締め時間 注文ID ステータス （有効・停止） アプリでは常に最新を表示する 作成時間 © 2024 Finatext Holdings Ltd. 12