【要約】太陽のくしゃみが自作チャットに届く。フレア×地震の観測ダッシュボードを外部サービスゼロで作った [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者が以前、Cloud RunとCloud Schedulerを用いて地震通知システムを構築した際、運用上の課題に直面した。具体的には、サーバーレス特有の挙動がリアルタイムな監視を阻害していた。
- ・Cloud Runのスケールtoゼロにより、内蔵クローラーが停止する。
- ・ファイルシステムの揮発性により、SQLiteのデータが消失する。
- ・ポーリング方式により、検知に最大5分の遅れが生じる。
// Approach
開発者は、サーバーレス環境の制約を回避するため、既存のVPSへ常駐型のワークロードとして再構築する手法を採用した。
- ・さくらVPS上にDockerコンテナをデプロイし、24時間稼働を実現。
- ・SQLiteをローカルディスクに保持し、データの永続性を確保。
- ・Nostr（NIP-17）を用いて、自作チャットアプリ「Kizuna」へ暗号化通知を送信。
- ・Caddyを用いてSSL証明書を管理し、HTTPS通信を確立。
// Result
開発者は、外部サービスに依存しない、プライバシーに配慮した観測・通知システムを構築した。
- ・地震発生から約3分後の第1報を即時に検知・通知することに成功。
- ・震源情報が判明した後に「続報」を自動送信する仕組みを実装。
- ・今後はWebSocket化による低遅延化や、時系列データの分析を目指している。
Senior Engineer Insight
> サーバーレスの特性と常駐型タスクのミスマッチを的確に分析している。コストと信頼性のトレードオフにおいて、既存リソース（VPS）を活用する判断は合理的だ。ただし、ポーリングによる最大5分の遅延は、災害情報の即時性を求める用途では致命的になり得る。実戦投入にはWebSocket等のPush型への移行が不可欠である。また、Nostrを用いた通知経路の自前化は、プライバシー観点では優れるが、運用負荷の増大を招く点に留意すべきだ。