【要約】【全5回】引き算で作るiPad受付システムーー選定・フロント・バックエンド・運用の全判断 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者が、小規模なシステム構築において、流行の技術スタックを過剰に採用してしまう問題に直面した。システム規模に対して構成要素が肥大化することで、以下の課題が生じる。
- ・Next.jsやSupabase等の導入による、不要な管理コストと学習コストの増大。
- ・API Gatewayの利用に伴う、構成の複雑化とコストの増加。
- ・Slack Botの応答制限（3秒以内）とLambdaのコールドスタートによるタイムアウト問題。
- ・キオスク端末特有の画面焼き付きや、PWAのキャッシュ更新における技術的障壁。
// Approach
開発者は、システムの規模と要件に基づき、不要なコンポーネントを削ぎ落とす「引き算の設計」を採用した。具体的には以下の手法で最適化を図った。
- ・データ設計：QRコードに情報を埋め込み、DBへの書き込みを最小限に抑えるステートレスな設計。
- ・バックエンド：API Gatewayを廃止し、Lambda Function URLとCloudFront OACを組み合わせる構成。
- ・フロントエンド：素のHTML/CSS/JSとPWAを活用し、実機検証に基づきjsQRを採用。
- ・Slack連携：Bolt for Pythonのlazy listenersを用い、即時応答と非同期処理を分離。
- ・運用：GitHub Actions等の過剰な自動化を避け、Terraformの2層分割と最小権限IAMで管理。
// Result
開発者は、過剰な構成を排除することで、低コストかつ実用的な受付システムを構築した。このアプローチにより、以下の成果を得ている。
- ・API Gatewayの撤廃による、インフラ構成の簡素化とコストの抑制。
- ・Slack Botにおける、タイムアウトを回避した安定的なQR発行機能の実装。
- ・実機（iPad Pro）での検証に基づいた、実用的なQR読み取り性能の確保。
- ・少人数運用に適した、管理負荷の低いTerraformによるインフラ管理の実現。
Senior Engineer Insight
> 非常に健全な判断である。大規模トラフィックを前提とした「標準構成」を疑い、リソース消費と運用コストのバランスを最適化している。特にAPI Gatewayを外してFunction URLを選択する判断は、コストと複雑性のトレードオフを深く理解している証左である。ただし、これはあくまで「局所最適」であり、将来的なスケールアップ時には再設計が必要となる点に留意すべきだ。小規模・低頻度な社内ツールにおいては、これこそが正解と言える。