拡張①「店舗側メンテナンス管理」完結編 ― Docker・AWS未経験からのEC2デプロイと、第三弾・第四弾との双方向連携

## はじめに

第三弾の開発記の中で、私は「店舗側のメンテナンス管理は今後の課題」と書いていました。あの時点では構想だけで、実装には手をつけていませんでした。

それから時間が経ち、気づけば拡張①は完成し、AWSにデプロイされ、第三弾・第四弾とAPIで繋がっていました。当時「今後の課題」と書いた自分に、今なら「終わったよ」と報告できます。この記事は、その完結報告です。

## なぜこのプロジェクトだったのか

拡張①の目的は最初からはっきりしていました。新しい技術スタックの実務経験を積むことです。

FastAPIはすでに慣れていたのでそのまま採用し、その代わりに

- PostgreSQL(それまではSQLite中心)

- Docker

- AWS(EC2)

を新しく学ぶ対象に選びました。逆にKubernetesやTerraformは今回は見送り、一度に手を広げすぎないようにしました。既存の予約システム群(第一〜五弾)とはあえて別リポジトリ・別DBにして、技術的な実験場として切り離したことも、後から振り返ると良い判断だったと思います。

## 何を作ったか

拡張①は、ボウリング場の貸出用品(シューズ・ボール)と整備記録を管理するシステムです。

- rental_items:貸出用品(種別・サイズ/重さ・状態・取得日)

- maintenance_log:整備記録(対象種別・対象ID・整備種別・カテゴリ・状態・修理方法・業者名・実施者・コスト・実施日・メモ)

このテーブル設計は、Groqを含む複数のAIに合議してもらって固めました。rental_itemsの削除は物理削除ではなく論理削除(statusを「廃棄」に変更)を採用し、廃棄履歴が追えるようにしています。

## 開発の流れ

1. Docker ComposeでFastAPI+PostgreSQLをローカル構築

2. SQLAlchemy+Alembicでモデル・マイグレーションを整備

3. rental_items・maintenance_logのAPI実装(CRUD)

4. Dockerイメージの本番相当化

5. AWSデプロイ(EC2+Docker Composeというシンプル構成から)

Docker・AWSともに完全に未経験からのスタートでした。ローカルでの動作確認、.envによるDB認証情報の分離、--reloadを外して本番相当の起動コマンドにする、といった一つ一つが初めての作業でした。

## AWSデプロイでのつまずきと突破

EC2インスタンスを立ち上げ、セキュリティグループにSSH・HTTP・8000番ポートのルールを追加。SSH接続では.pemファイルの権限エラーにぶつかりましたが、icaclsで権限を自分のみに絞ることで解決しました。

サーバーへのデプロイ方法は**GitHub経由(git clone)**を選びました。ポートフォリオとしての公開価値と、その後の更新のしやすさ(git pull一発で反映できる)を優先した判断です。

最終的にEC2上でdocker compose up -dを実行し、Alembicマイグレーションを適用。http://<EC2のIP>:8000/docsで全エンドポイントへの公開アクセスに成功しました。Step1〜5、すべて完了です。

## 第三弾との連携 ― セキュリティを一歩深める

ここで終わらず、第三弾(店舗管理システム)との連携に進みました。「実際に店舗を運営する立場なら」と考え、書き込み系エンドポイント(POST/PATCH/DELETE)にAPIキー認証(X-API-Keyヘッダー)を追加。GET系は認証なしのままとし、用途に応じてセキュリティレベルを使い分けました。

第三弾側にはHTTPクライアントを実装し、レーンが新たに「故障中」になったタイミングだけ拡張①へ自動登録する仕組みを作りました。同じ故障状態での重複登録を防ぐフラグ設計も入れています。「拡張①が落ちていても第三弾側の処理を止めない」という例外設計も意識しました。

## 第四弾との連携 ― 双方向という選択

第四弾(会員のマイギア管理)とは、片方向ではなく双方向連携で設計しました。

- 第四弾 → 拡張①:会員が整備依頼を出す

- 拡張① → 第四弾:整備完了情報を会員のマイギア履歴に反映

第四弾は第三弾と同じSQLite+FastAPI構成でしたが、拡張①独自のmaintenance_logとは別に、第四弾側にもリマインド計算専用のシンプルな実施記録モデルがあり、混同しないよう整理しながら進めました。

## つまずきから得た学び

実装過程では、地味だけれど実務的な学びがいくつもありました。

- .envの自動読み込み(python-dotenv)が入っていないプロジェクトがあり、load_dotenv()の追加が必要だった

- デスクトップ上に同名プロジェクトフォルダが複数存在し、.envを誤って別フォルダに保存してしまうトラブルが発生

- Docker Composeで.envを変更した際、コンテナ再起動だけでは反映されず--force-recreateが必要な場合がある

- PowerShellでダブルクォートを使うと変数展開されてしまうため、コンテナ内環境変数の確認にはシングルクォートが必須

- Swagger UIのPATCH操作は、サンプル雛形を一部だけ書き換えると他の項目がサンプル値で上書きされてしまうため、本文を一度全部消してから必要な項目だけ書く必要がある

どれも「動かない」で立ち止まった瞬間から生まれた学びです。

## おわりに

Docker・AWSともに未経験だった状態から、EC2への本番デプロイ、そして既存システムとの双方向API連携まで実機で確認できたことは、この拡張①プロジェクトの一番の成果だと思っています。

かつて「今後の課題」と書いた一行が、こうして「完了しました」に変わる瞬間は、開発を記録に残してきたからこそ味わえるものだと感じます。

スポーツボウリング場構想・拡張①の開発記録は、これで一区切りです。🎳