Python

HTTP HEAD事前チェック · High-Water Mark逆順スキャン · Score閾値ノイズフィルタリング 公共データポータル 81MB CSV → PostgreSQL サーバーレス同期実践記 問題定義 — なぜ最適化が必要だったのか 建築法規レビューAIシステムで「地区詳細計画告示マッチング」機能を実装していました。VWorld APIで特定住所の地区詳細計画情報を照会すると ntfc_sn（告示シリアル番号）が返されますが、この番号だけでは実際の告示文書にアクセスできません。 eum.go.kr（土地情報ポータル）に告示リストがありますが、そのサイトのWAFがAWS IPレンジをブロックしており、直接API呼び出しが不可能でした。代替案として、公共データポータルから提供される告示リストCSVファイルをPostgreSQL DBに入れてマッチングする戦略を選択しました。 データ規模 項目 値 CSVファイルサイズ 約81MB 総レコード数 448,100件 うち地区詳細計画関連 約28,300件 CSV更新頻度 月1〜2回 新規追加量 数十〜数百件/月 問題は、この448K件を毎回全てダウンロードしてパースすると約52秒かかることでした。エージェントがユーザーの質問に回答する過程で52秒待たせるわけにはいきません。 制約条件 — サーバーレス環境の限界 システムはAWS Bedrock AgentCore上でサーバーレスに動作します。この環境には以下の制約があります： ローカルファイルシステムなし：コンテナが毎回新しく起動するため、CSVをローカルにキャッシュできません。 コールドスタートの考慮：最初の呼び出し時でも合理的な応答時間が必要です。 DBが唯一の永続ストレージ：PostgreSQLだけが状態を維持できる場所です。 HTTP Range非対応：data.go.krがRangeリクエストをサポートしておらず、部分ダウンロードが不可能です。 核心的な質問：「毎月数十件しか追加されないのに、毎回448K件を全て処理する必要があるのか？」 全体アーキテクチャ — 3-Layer最適化戦略 「できる限り何もしない」を原則に3段階最適化を設計しました。各Layerで早期に抜け出すほど、全体コストが下がります。 Layer 戦略 コスト スキップ条件 Layer 1 HEADリクエスト → Content-Length比較 0.3秒 ファイルサイズが同じなら即終了 Layer 2 全体ダウンロード + 逆順ラインスキャン ~2秒 max_seq境界でスキャン中断 Layer 3 新規分のみ csv.reader パース + INSERT ~0.01秒 新規件のみ処理 この戦略の核心は「ほとんどの呼び出しがLayer 1で終わる」という点です。CSVが更新されていなければ、HEADリクエスト1回（0.3秒）で全プロセスが終了します。 ...