---
title: エンジニア1年生が10万ユーザーのプロダクトを運用してみた結果
tags: 
author: [小林拓磨](https://docswell.com/user/norit4ma)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/87DYRDL57G.jpg?width=480
description: https://ctoa-wakate.connpass.com/event/318007/ にて登壇した内容です。
published: June 06, 24
canonical: https://docswell.com/s/norit4ma/5RXNJ9-2024-06-06-201535
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/87DYRDL57G.jpg)

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/VJP6WX2DE8.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/2EV38LDG7Q.jpg)

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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/57G35XVDJL.jpg)

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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/4EQ5Z86XJP.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/KJ49324271.jpg)

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


# Page. 7

![Page Image](https://bcdn.docswell.com/page/LE1K1M4KJG.jpg)

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


# Page. 8

![Page Image](https://bcdn.docswell.com/page/GEWD83XPJ2.jpg)

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


# Page. 9

![Page Image](https://bcdn.docswell.com/page/47ZG8V66E3.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/YJ6YP52L7V.jpg)

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


# Page. 11

![Page Image](https://bcdn.docswell.com/page/GJ5GKY2MJ4.jpg)



# Page. 12

![Page Image](https://bcdn.docswell.com/page/9E2YWG4RER.jpg)

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


# Page. 13

![Page Image](https://bcdn.docswell.com/page/D7YGLVM57M.jpg)

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