💡Listoru（リストル）は、Web上の情報から企業の営業リストを自動で収集・作成するツールです。
この「企業DB開発日誌」では、数ある機能の裏側に隠された、私たちの試行錯誤を綴っていきます。
エラー画面には出ない問題や、データとの静かな対話から見えてきたもの。
正解のない開発現場のリアルな空気を、少しだけおすそ分けさせてください。
今日もリストルの裏側で起きた、ひとつの物語をお届けします。
目次
- 何も変えていない処理が「33万件」で沈黙した日
- 正しい処理の組み合わせが引き起こした「数百万回」の問い合わせ
- いちばん速い処理は「実行しない」こと
- 正しい作りは、規模が変わると正しくなくなる
何も変えていない処理が「33万件」で沈黙した日
ある日、一括処理が動かなくなりました。
正確には、動いてはいます。
始まって、走って、そして終わりません。
終わらない、と言い切るまでにも、時間がかかりました。
遅いだけなら、待てば済みます。
壊れたなら、エラーが出ます。
どちらでもないものは、待つのをやめる理由が見つかりません。
以前は、同じ処理が数分で終わっていました。
何も変えていません。
コードは1行も触っていない。
変わったのは、件数だけでした。
登録企業――335,845件。
数千件のころは、何の問題もありませんでした。
待っていれば終わる。むしろ速いほうだと思っていました。
数十万件になった日、同じ処理が帰ってこなくなりました。
件数が増えた理由は、はっきりしています。
集めたからです。
取り込み、名寄せ、番号の突き合わせ、全国からの発掘。
どれも、件数を増やすための機能です。
増やすことを目的に作ってきて、増えた結果に、別の機能が耐えられなくなった。
自分で自分の前提を壊した形です。
この処理は、名寄せの「保留」を片付けるためのものです。
同じ会社かどうかを機械が判定したとき、確信があれば統合し、迷ったら保留にします。
保留は、人が見て決めるためのものです。
保留の一覧を画面に出す。
それだけの処理でした。
一覧を出すには、保留1件ごとに、「どの会社と迷っているのか」を表示する必要があります。
だから、候補になった会社の名前を取りに行きます。
正しい処理の組み合わせが引き起こした「数百万回」の問い合わせ
取りに行く方法に、問題がありました。
保留1件を表示するたびに、候補の会社を、1社ずつ、順番に問い合わせていたのです。
1社目を問い合わせる。返ってくる。
2社目を問い合わせる。返ってくる。
3社目を……という具合に。
1回の問い合わせは、ごく短時間で終わります。
測れば、ほんのわずかです。
だから、数千件のころは気づきませんでした。
この形の遅さには、特徴があります。
1回ずつ測ると、どこにも遅い場所がありません。
「この処理が重い」という犯人が、見つからない。
全部が軽くて、全体だけが終わらない。
犯人を探す調べ方をしている限り、見つかりません。
実際、しばらく見つかりませんでした。
遅い場所を探しては、どこも遅くないことを確かめる。
その往復を、何度か繰り返しました。
重さを疑うのをやめたところで、調べ方が変わりました。
見つけるには、数を数えるしかありませんでした。
1件を表示するのに、何回の問い合わせが起きているか。
数えてみると、想像より2桁多い数字が出ました。
候補の数は、1件につき最大100社まで持っています。
よくある社名だと、それくらい並びます。
絞り込みすぎると、本当に同じ会社を取りこぼすからです。
そして、保留は数万件ありました。
数万件 × 最大100社。
問い合わせの回数は、数百万回になります。
ほんのわずかな時間も、数百万回集めれば、その日のうちには終わりません。
この構造の厄介なところは、どこも間違っていないことです。
1件を表示する処理は、正しい。
候補を全部見にいくのも、正しい。
候補を最大100社まで持つのも、理由があってのことです。
正しいものを組み合わせた結果、規模が変わった瞬間に、動かなくなりました。
間違いを探す目には、この構造は映りません。
1行ずつ読めば、どの行も正しいからです。
正しさを確かめる読み方では、たどり着けない場所でした。
数百万回という数字を出したとき、最初は計算を疑いました。
そんなに問い合わせていたら、もっと早く問題になっていたはずだ、と。
実際には、なっていました。
数千件のころは、数万回です。
数万回でも、少し待てば終わります。
「少し遅いな」という感覚は、前からありました。
その感覚を、私たちは「件数が多いから仕方がない」で片付けていました。
少しずつ遅くなるものには、警報が鳴りません。
昨日より今日が、わずかに遅い。
毎日見ている目ほど、その差に気づけません。
止まった日に、はじめて、全部がまとめて見えました。
いちばん速い処理は「実行しない」こと
直し方は、問い合わせ方を変えることでした。
1社ずつ聞くのをやめて、まとめて聞く。
必要な会社の番号を全部集めてから、「この会社たちの名前をください」と一度で問い合わせる。
返ってきたものを手元に置いておき、表示するときは、そこから取り出す。
問い合わせの回数は、数百万回から、数十回になりました。
もうひとつ、表示そのものも変えました。
保留を全件いっぺんに画面へ出す必要はありません。
人が確認できる量は、限られています。
一度に扱う量に上限を置き、必要なぶんだけ表示するようにしました。
この2つ目の変更のほうが、効き方は大きいものでした。
数万件を用意しても、人が見るのは最初の数十件です。
残りは、その日には見られません。
つまり、用意した処理のほとんどが、誰にも使われないまま捨てられていました。
速くする前に、そもそも作る必要があったのかを考える。
いちばん速い処理は、実行しない処理でした。
正しい作りは、規模が変わると正しくなくなる
この件のあと、私たちは開発のやり方を1つ変えました。
新しい処理を作るとき、手元の少ない件数で試して終わりにしない。
本番と同じ規模の件数で、一度は流してみる。
数千件で速いことは、何の証明にもなりません。
数千件で速いのは、当たり前だからです。
見るべきなのは、件数が10倍になったとき、時間が10倍で済むのか、100倍になるのか、という形のほうです。
10倍で済むなら、待てば終わります。
100倍になるものは、いつか必ず止まります。
この形を持つ処理は、他にもありました。
一覧を表示するときに、1行ごとに何かを問い合わせている。
集計するときに、1件ごとに関連する情報を取りに行っている。
どれも、書いているときには自然です。
1件分の処理を正しく書いて、それを件数分繰り返す。
プログラムの書き方としては、むしろ素直な形です。
素直な形が、規模の大きい場所では成り立たない。
だから、いまは書きながら1つ確認します。
この処理は、件数ぶん繰り返されるのか。
繰り返される中に、外へ問い合わせる行が入っていないか。
入っていたら、外に出します。
もうひとつ、開発の環境も変えました。
手元で試すためのデータを、本番に近い件数で用意しました。
以前は、数十件でした。
動作を確かめるには、それで足ります。
足りるので、それ以上は用意しませんでした。
いまは、数十万件のデータを持っています。
用意するのに手間はかかりましたが、一度作れば使い回せます。
このデータで流すと、書いた直後に「これは終わらない」と分かります。
本番で気づくのと、書いた直後に気づくのとでは、直す手間が桁違いです。
規模は、あとから足せません。
最初から、そこにあるものとして作るしかありませんでした。
335,845件という数字は、私たちにとって、うれしい数字のはずでした。
集めて、名寄せして、番号を付けて、整えてきた結果です。
その数字が、そのまま重さになった。
作ったときには存在しなかった規模が、何も知らせずに、静かにやってきていました。
正しい作りは、規模が変わると正しくなくなります。
壊れたのではありません。
追い越されたのです。
いま、同じ処理は数十秒で終わります。
335,845件のまま、何も減らしていません。
そして、この件数は、これからも増えます。
増えたときに、また同じことが起きるかもしれません。
だから、直したときに1つ記録を残しました。
この処理は、件数が増えたときにどう伸びるのか。
どこが上限になるのか。
次に止まったとき、同じ場所を最初から調べ直さずに済むように。
━━━━━━━━━━━━━━━━━━━━━━━━
次回予告
第8話「消したまま、残る」
作り直す処理は、まず全部消すところから始まります。
35万件を、一度に読み込もうとしていました。
途中で力尽きたら、どうなるか。
━━━━━━━━━━━━━━━━━━━━━━━━
リストルは、今日もどこかを直しています。
→ 成果を出す営業リスト3000件が無料で試せる👇
📝営業リスト収集ツール「リストル」
営業リスト収集ツール「Listoru（リストル）」| 最短3分で3,000件取得営業リストで新規開拓を仕組み化！Listoruは300以上のWebサイトから企業リストを自動収集。今すぐ無料で体験！w
