💡Listoru（リストル）は、Web上の情報から企業の営業リストを自動で収集・作成するツールです。
この「企業DB開発日誌」では、数ある機能の裏側に隠された、私たちの試行錯誤を綴っていきます。
エラー画面には出ない問題や、データとの静かな対話から見えてきたもの。
正解のない開発現場のリアルな空気を、少しだけおすそ分けさせてください。
今日もリストルの裏側で起きた、ひとつの物語をお届けします。
原因不明の遅延。サーバーもデータベースも「暇」だった
ある日から、こういう症状が出るようになりました。
時間のかかる処理を動かしているあいだ、
同じ人が別の画面を開こうとすると、
画面が返ってこない。
固まる、という言い方が近いです。
真っ白なまま、じっと待たされる。
処理が終わると、待たされていた画面が、まとめて開きます。
何事もなかったように。
エラーは、出ません。
壊れたものは、壊れたなりの顔をするものです。
この症状には、その顔がありませんでした。
まず疑ったのは、サーバーでした。
処理が重すぎて、他のことをする余裕がないのだろう。
そう考えるのが自然です。
見に行きました。
余裕がありました。
計算する力も、記憶する場所も、まったく足りています。
息切れしている様子はどこにもない。
いちばん分かりやすい説明が、最初に消えました。
重いから遅いのなら、話は簡単です。
増やせば済むからです。
その道が、ここでふさがりました。
次に疑ったのは、データベースでした。
大量のデータを読み書きしているあいだ、他の読み書きが順番待ちになることはあります。
こちらも見に行きました。
こちらも、元気でした。
待たされている読み書きは、ありません。
サーバーは暇。データベースも暇。
それなのに、画面は返ってこない。
疑う先が、無くなりました。
処理能力ではなく、入り口の「鍵」が握られていた
遅いはずの場所が、どこも遅くない。
それでいて、症状は必ず出ます。
残っている手がかりは、症状そのものだけでした。
次に、症状の出方を細かく見ました。
固まるのは、必ず、重い処理を動かしている最中です。
処理が終わると、待っていた画面が、まとめて開きます。
「まとめて開く」という点が、引っかかりました。
もし処理が重くて余裕がないなら、終わったあとも、しばらくもたつくはずです。
実際には、終わった瞬間に、いっせいに開きます。
まるで、扉が開くのを待っていたかのように。
止められていたのは、処理の能力ではなく、入り口のほうでした。
混んでいないのに、通れない。
こういうときは、たいてい、
どこかで誰かが鍵を持ったままになっています。
手がかりは、症状の出方にありました。
固まるのは、同じ人が別の画面を開いたときだけです。
別の人が同時に使っていても、その人は固まりません。
つまり、詰まっているのは「その人分の何か」です。
サーバー全体でもなく、データベース全体でもない。
利用者ひとりに1つだけ用意されているもの。
絞り込んだあとの調べ方は、こうです。
固まっている最中に、その人分のものが、いま誰に使われているかを見る。
見に行くと、重い処理のほうが握っていました。
握ったまま、返していない。
返すのは、処理が全部終わったときだけ。
ここで、症状のすべてが説明できました。
説明がつくかどうかは、大事な区切りです。
つかないうちは、まだ別の原因があります。
つけば、そこで調査を終えていい。
ログイン状態を保つ仕組みが、それでした。
いま誰がログインしているのか。
どの会社のデータを見ていい人なのか。
その情報は、画面を開くたびに読み書きされます。
この情報は、混ざると危険です。
2つの画面が同時に書き換えたら、状態がおかしくなるかもしれない。
だから、この仕組みには、鍵がかかります。
1つの画面が使っているあいだ、他の画面は待つ。
これは、間違いではありません。むしろ正しい作りです。
鍵をかける仕組みそのものは、外そうと思えば外せます。
外せば、待たされることはなくなります。
けれど、そうすると、2つの画面が同時に状態を書き換える可能性が出ます。
権限の情報が壊れれば、見えてはいけないものが見える事故につながります。
外す、という選択肢は、最初に消えました。
問題は、鍵をいつ手放すかでした。
「最初の一瞬」だけ必要な鍵を持ち続けていた27か所
ログイン状態を読むのは、処理の最初の一瞬です。
誰なのかを確認して、権限を確かめる。
そこから先の、企業データを何万件も処理する時間には、ログイン状態はもう使っていません。
つまり、最初の一瞬だけ鍵を持てばよかった。
けれど、鍵を手放す処理は、一度も書かれていませんでした。
鍵は、処理が完全に終わるまで、持ちっぱなしになっていました。
数十万件を処理する夜間の作業なら、その間ずっとです。
その人が別の画面を開こうとすると、ログイン状態を読むところで止まる。
サーバーは暇なはずです。
データベースも暇なはずです。
待っていたのは、鍵が返ってくること、それだけでした。
つまり、遅かったのではありません。
待たされていただけでした。
処理を速くする話だと思って調べはじめて、行き着いた先は、順番の話でした。
直し方は、拍子抜けするほど簡単でした。
ログイン状態を読み終えたら、その時点で鍵を返す。
それだけです。
書き換える必要がある処理では、書き換えてから返します。
返したあとに書き換えないよう、そこは注意が要ります。
対象になったのは、27の処理でした。
時間のかかるものを片っ端から見ていき、
「最初の一瞬しか使っていないのに、最後まで持っている」
場所を、全部直しました。
27という数字は、多いようで、当然でもありました。
ログイン状態を確認する処理は、ほとんどすべての画面の先頭に書かれています。
同じ書き出しを、何十回も書いてきた結果です。
そして、その書き出しには、鍵を返す行が、最初から含まれていませんでした。
1か所の書き忘れではなく、書き出しの形そのものに、その行が無かった。だから、直すのも1か所ずつでした。
いまは、共通の書き出しのほうに入れてあります。
行列は、道具を強くしても縮まない
この件で学んだのは、遅さの見方です。
遅いとき、私たちはまず「足りない」を疑います。
力が足りない。速度が足りない。台数が足りない。
足りないなら、増やせば直ります。
分かりやすい。買えば済むこともある。
けれど、今回はどれも足りていました。
足りていて、なお進まなかった。
進まない理由は、「足りない」ではなく「待っている」でした。
足りないと待っているは、症状がよく似ています。
そして、対処はまるで違います。
増やしても、待っているものは待ち続けます。
今回も、先に増やすほうを選んでいたら、サーバーは強くなり、症状はそのまま残っていたはずです。
行列は、道具を強くしても、縮みません。
いまは、遅い症状を見たとき、先に1つだけ確認するようにしました。
混んでいるのか、それとも、順番を待っているのか。
見分け方は、そう難しくありません。
混んでいるなら、どこかの数字が高いはずです。
計算する力、記憶する場所、読み書きの量。
どれかが、必ず張り付いています。
どの数字も低いのに遅いなら、待っています。
そして、待っているものを見つけるには、「1つしかないもの」を探します。
利用者ごとに1つ。
処理ごとに1つ。
会社ごとに1つ。
数が1つに決まっているところには、必ず順番ができます。
この件には、後日談があります。
同じ症状が、別の形でもう一度出ました。
今度は、複数の利用者が同時に使ったときでした。
1人が重い処理を動かすと、他の人まで待たされる。
原因は、また別の「1つしかないもの」でした。
会社ごとに1つ用意していた作業用の場所が、処理のあいだ、ずっと押さえられていたのです。
構造は、まったく同じです。
必要な一瞬だけ押さえて、すぐ手放す。
同じ直し方で、直りました。
一度覚えた形は、二度目からは早い。
遅さの原因を「待っている」と疑えるようになったのは、最初の27か所を直したおかげでした。
サーバーも、データベースも、元気でした。
ただ、順番を待っていただけです。
そして、その順番は、誰も呼びに来ないようになっていました。
━━━━━━━━━━━━━━━━━━━━━━━━
次回予告
第7話「33万5,845」
数千件では、何の問題もありませんでした。
数十万件になった日、その処理は動かなくなりました。
登録企業、335,845件。
作りは、何も変えていません。
━━━━━━━━━━━━━━━━━━━━━━━━
リストルは、今日もどこかを直しています⚙️
→ 成果を出す営業リスト3000件が無料で試せる👇
📝営業リスト収集ツール「リストル」
営業リスト収集ツール「Listoru（リストル）」| 最短3分で3,000件取得営業リストで新規開拓を仕組み化！Listoruは270以上のWebサイトから企業リストを自動収集。今すぐ無料で体験！
