【要約】名前からIDを計算してはいけない — ハッシュURLが1,000ページの孤児を生んだ話 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
パチスロデータサイトの運営者が、店舗ページのURL設計に店名のmd5ハッシュを用いたことで、大量の孤児ページが発生した。店名の表記ゆれや改名が、意図しない新しいURLの生成を招いたのである。
- ・店名の表記ゆれ（全角・半角、空白の有無）により、同一店舗が別IDとして扱われた。
- ・データ元の改名により、既存のURLが機能しない孤児状態となった。
- ・正規化ルールを強化しても、改名という構造的変化には対応できない設計上の欠陥があった。
// Approach
運営者は、IDを計算で求めるのではなく、初出時に発行して保存する台帳（Ledger）方式を採用した。これにより、URLの不変性を保ちつつ、同一店舗の識別を可能にした。
- ・IDは初出時に一度だけ発行し、台帳に保存して以後は台帳を引く設計とした。
- ・既存のURL（古いハッシュ）を維持し、正規化名で台帳を検索する非対称なLookupを行う。
- ・新規発行の暴走を防ぐため、一晩の新規発行件数に閾値（20件）を設けた。
- ・改名などの重大な変更は、機械的な処理を避け、人間による承認フローを通す仕組みとした。
- ・発行点を一箇所に限定し、書き込みの競合を防ぐために単一スレッドでの処理を徹底した。
// Result
この設計変更により、運営者は約1,000件の孤児ページを整理し、URLの増殖を食い止めることに成功した。
- ・既存のURLを動かさずに、表記ゆれを吸収する仕組みを構築した。
- ・新規発行件数のログ（H/Kログ）により、台帳が正常に機能しているかを監視可能にした。
- ・「完璧な正規化」を追わず、運用可能な終了条件を定義することで、整備作業を完遂させた。
Senior Engineer Insight
> 決定論的なハッシュによるID生成は、実装が容易な反面、実世界のデータの不確実性を許容できない。本記事の教訓は、IDを「計算結果」ではなく「台帳による管理対象」と定義し直した点にある。書き込みの直列化や承認フローといった運用コストは増大するが、URLの不変性を守ることはSEOやデータ整合性の観点から極めて重要だ。システムの設計において、「楽な実装」が将来的な「技術負債（孤児ページ）」を招く典型例と言える。