こんにちは。新規事業部門でエンジニアをやっている重本です。2025年5月にReproへ入社し、この記事を書いている今でちょうど3ヶ月が経ちました。
わずか3ヶ月ながらも、プロダクトの一部を担う責任や、技術的に解くべき課題の難しさ、そしてそれらを支える人や文化に、日々驚きと学びの連続でした。入社を検討している方や、同じような課題意識を持つ方の参考になればと思い、この記事を書くことにしました。
入社経緯
私はこれまでSESを中心に、複数の会社・案件で開発を経験してきました。ある程度のアプリケーションは作れるようになってきた反面、「この先、エンジニアとして何を積み上げていけば良いのか？」という漠然とした悩みもありました。
そんな中、Reproの面談で率直にその悩みを話してみたところ、「じゃあウチで修行してみる？」という一言で話が進みました。
「修行」と聞くと少しストイックな印象もありますが、私にとってはとてもポジティブな響きでした。「技術力を本質的に高める機会がありそう」「高いレベルのエンジニアに囲まれて、ハードな課題に取り組めそう」と直感的に感じたのが入社の決め手です。
3ヶ月で起こったこと
新規事業ながら、すでにRepro という規模が大きくなっているプロダクト・ソリューションをもっているため、最初から一定の規模のユーザーに安定したサービスを提供できるケイパビリティを担保していました。 しかしちょうど私が入社したタイミングで大規模なユーザーを抱えるアプリ／サービスでのご利用が複数案件重なり、その結果いくつかの問題が顕在化しました。
Slowqueryの発生
程なくして、いくつかのクエリでSlowqueryの警告が鳴るようになりました。 Reproでは将来障害となりうる小さな芽は最優先で潰しておくという文化があります。 個人的にSlowqueryの対処をやったことはありませんでしたが、経験のために対応したいといったところ、任せてもらえました。
やったこと
- Explainを用いて、ボトルネックとなっている箇所を洗い出す
- 複合indexを張る
- 複合indexを活かすクエリに変更する
- 適切なパーティションに分ける
- RDB内で集計し中間テーブルを作成している場合、可能であれば集計テーブルの作成をBigQueryに任せる
これまで大量のデータを扱うシステムに関わった経験がなかったため、インデックス設計などについて深く考えたことはありませんでした。 しかし実際にチューニングを行ってみると、処理速度が10倍に向上するなど、その効果の大きさに驚きました。 同時に、インデックスの貼り方ひとつで逆にパフォーマンスが大きく低下する可能性もあると実感し、日々の開発において常に意識する必要があると感じました。
突発的なスループットの増加
大量のトラフィックとはいえ、キャパシティプランニングがある程度考えられた構成となっていたので、レイテンシーの増加やメトリクスの悪化などはありましたが、データ自体は時間内に捌けていました。 しかしある晩、一部のデータが処理されるべき時間内に処理できず残っているという警告が鳴りました。 放っておいても次のバッチ処理で処理されるので問題ないといえば問題ないのですが、もし仮に残ったデータの量が一度の処理できる総量を超えた場合、 永遠に処理が終わらないという事態になりかねないので、原因を追求し潰すことにしました。
やったこと
- 警告が出た時刻あたりのの処理データ量の確認
- メトリクスの確認
犯人は突発的なスループットの増加でした。 よくよく調べてみると、一時的に止めていた施策を再開した際、それまで堰き止められていたデータがダムの放水後の鉄砲水みたいに雪崩れ込んだようでした。 ただ、処理のリトライや冪等性は考えられていたシステムだったのでエラーにはならずそれはよかったと思います。 瞬間的なスループットの激増も初めての経験だったので、「そんなこともあるのか」と印象に残った事象でした。
3ヶ月を完走した感想
先述した他にも、ETL (Extract, Transform, Load) を行う複数ワーカーの保守、修正や非同期処理（pub/sub等）による処理スループットのコントロールなどに触れる機会がありました。 3ヶ月でここまで成長を実感したのは初めてかもしれません。
実は事前に勉強しておいて欲しいことリストを貰い、それをインプットしてから入社しました。 以下はその一部です。
中でも『データ指向アプリケーションデザイン』は、私にとって特に難解な本でした。 読んではいたものの、「本当にこんな知識を使う場面なんて来るの？」と半信半疑で、仮にあったとしてもごくレアなケースだろうと思っていました。 実際、これまで関わってきたのは基幹系や業務効率化系のアプリケーションが多く、整合性は重視されるもののトラフィックはそこまで大きくない。そのため、この手の知識はあまり必要ないと感じていましたし、現場で困った経験も特にありませんでした。
ところが、Reproではいきなりその知識が必要になりました。 「え、これって本に書いてあったあれじゃん？」「まさか本当にこのケースが現実に出てくるなんて…」と、警告メッセージと向き合いながら驚くことになりました。 読んでなかったら即死でしたね。。
おわりに
この3ヶ月で、自分自身の成長を強く実感することができました。 とはいえ、現在私が担当しているのはバッチ処理が中心のシステムであり、Repro本体のようにストリーミングで大量のデータを捌くようなアーキテクチャはこれからです。 将来的にはそうしたシステムを設計・構築できるようになりたいですし、並行処理や順序保証キューの運用、書き込み分散の最適化など、Reproで学べることはまだまだ山ほどあります。
これからも事業の成長に貢献しながら、自分自身ももっと強くなっていけたらと思っています。
WE ARE HIRING!
最後に、Reproでは開発者を募集しています。 単純なアプリケーションだけでなく、ストリーミングで大量のデータを捌くようなシステムにも携わってみたい。といった方はぜひお話しましょう！
