【要約】日本の開発者向けに無料APIサービスを作った話 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者は、正確な日本特有のデータを提供しようとした際、LLMの不正確さとインフラの制約という2つの課題に直面した。
- ・LLMによる祝日判定や住所変換における、計算ロジックの不正確さ。
- ・Railway環境におけるDockerfileの環境変数（$PORT）展開の失敗。
- ・SQLite使用時におけるBigInteger型のautoincrement不具合。
- ・12万件の郵便番号データをメモリに保持することによるメモリ不足。
// Approach
開発者は、利用者の利便性を最大化しつつ、限られたリソース内で動作させるための設計を採用した。
- ・認証なしのGETエンドポイントを提供し、試行のハードルを極限まで下げた。
- ・郵便番号データをJSONではなくSQLiteに格納し、メモリ消費を最小化した。
- ・Dockerfile内でシェル経由のコマンド実行を行い、ポート指定問題を解決した。
- ・IP単位とAPIキー単位でレート制限を分ける、段階的な認証設計を導入した。
// Result
開発は順調に進み、サービスは当初の想定を大幅に上回る規模へと成長した。
- ・エンドポイント数が2本から30本以上に拡大した。
- ・12万件の郵便番号データに対し、低メモリかつ高速な検索を実現した。
- ・「気軽に試す」から「アカウント作成」への自然なユーザー導線を構築した。
Senior Engineer Insight
> PaaSの制約を逆手に取った設計は、極めて合理的である。特に、大量のマスターデータをメモリに載せず、軽量なSQLiteに逃がして検索性を確保する判断は、リソース制約下での定石と言える。ブランディング目的の低コスト運用としては、非常に完成度が高い。ただし、将来的にトラフィックが増大した際は、ステートレスな設計への再構築と、PostgreSQLへの完全移行が不可欠となるだろう。また、IPベースのレート制限は、プロキシ環境下での誤検知リスクを考慮すべきである。