schulte-operation

GitHub ↗ 最終push: 2026/4/28 12:37

WIP（現在進行中）

Work In Progress

このプロジェクトで現在進行中の作業と、過去のスナップショットを記録する。

現在の状況

🎉 schulte v1 → v2 移行 + 撤退 + RDS Private 化、全完了。月額約 $24 削減 + セキュリティ向上。

v2 (Lightsail / FastAPI / Python 3.13) が schulte.thomsonsapp.com の 100% トラフィック処理
swap 1GB + uvicorn workers=2 で長期稼働の安定性強化済み
旧 v1 EC2 (1号機・2号機) は完全削除（terminate）
ALB taki から schulte 関連 (リスナールール × 2 / TG) を完全除去（taki ALB 自体は他4アプリ用に残置）
Lambda 3つ (TCM_observeALB_*) から Schulte 行コメントアウト済
Route53 から alb-v1 レコード削除済、lightsail-v2 のみ
RDS footballnext baseballnext を PubliclyAccessible=false 化（月 -$7.3、セキュリティ向上）
EIP の状況: cron 用 1個のみ存続、他は全部 release or AWS 自動解放
dev-timer #3 (4/28 7:42) はもう過ぎてしまった（観測は wrap-up 直前で実施、問題なし）

月額コスト効果（最終）:

項目	削減
EC2 t3.nano × 2	-$15.2
EBS 8GB × 2	-$1.6
RDS 用 EIP × 2	-$7.3
合計削減	-$24.1
Lightsail micro_3_0 (新規)	+$7.0
正味	約 -$17.1/月（年約$205）

次にやること（優先度順）:

（別プロジェクトで）共通 phpmyadmin (~/cdev/common-php-my-admin) を SSH トンネル経由に改修
- 引き継ぎ.md を作成済み、別 Claude セッションが即作業開始できる状態
（オプション）kizuna RDS も PubliclyAccessible=false 化（月 -$3.65 追加削減、phpmyadmin SSH トンネル整備後）
schulte-unity を CodeCommit → GitHub に移行（今四半期内のロードマップ項目、本当の残課題）
「いつか」項目（認証機構 / レート制限 / メトリクス / pytest / Docker compose / CloudWatch Logs 集約）

未決事項:

ALB 用 EIP × 2 (175.41.232.218 / 54.92.6.226) は amazon-elb 管理で release 不可 → ALB taki 自体を削除しない限り動かせない（taki は他4アプリ用なので削除しない、許容）
旧 ACM 証明書 (arn:aws:acm:.../4eec...) の SAN 確認は未実施。他ホスト名 (baseballnext / footballnext / sposhin / machiga) も含まれてる前提で残置
認証機構の追加（チート対策）は v1 と同じく未実装

過去のWIPアーカイブ

2026-04-27 19:43 時点のスナップショット

🎯 v2 100% 稼働中、v1 1号機を停止。翌朝 (12h 後) のタイマー通知で観測再開予定。

v2 が schulte.thomsonsapp.com の全トラフィックを処理中
v1: 1号機 (Schulte_maintenance タグで stopped)、2号機 (元から stopped)
ALB schulte TG: 1号機 deregister 済み、流入ゼロ
ALB taki: schulte リスナールールはまだ残置、流入ゼロ
DNS: alb-v1 (Weight 0) 残置、lightsail-v2 (Weight 100) 稼働中
dev-timer #3 が 2026/4/28 7:42 に発火予定

次にやること（翌朝確認後の撤退仕上げ）: DNS alb-v1 削除 / ALB taki から schulte リスナールール削除 / ALB schulte TG 削除 / Lambda 整理 / EC2 1号機・2号機 terminate。

2026-04-27 19:33 時点のスナップショット

🎯 本番 100% v2 切り替え完了、安定稼働中。残るは v1 撤退作業のみ。

schulte.thomsonsapp.com → 100% Lightsail (52.68.176.128)
ALB schulte TG への流入: 19:26 以降 0 RPM
v2 トラフィック: avg 0.08 RPS、5xx ゼロ、メモリ available 424MB
監視 (senrigan-observer) の URL は /healthcheck に変更済み
ALB Alias レコードは Weight 0 で残置（即時切り戻し用）

次にやること: 観測 → ALB 1号機 deregister → EC2 停止 → Lambda 整理 → terminate。

2026-04-27 18:51 時点のスナップショット

本番ドメイン切り替えの準備が完全に整った。次セッションで切り替え発射。

Lightsail で v2 が完全稼働、両ドメイン (v2-test / schulte) の SSL 証明書取得済み
Nginx は HTTP/HTTPS 両方受け、各 server_name で別々の証明書を読む構成
curl --resolve で本番 DNS を変えずに HTTPS 動作確認済み
切り戻し用情報は DEVLOG に inline 記録

重要な定数: schulte zone Z035498717N5DORY02AM0、現 Alias Target dualstack.taki-879563088.ap-northeast-1.elb.amazonaws.com.、ALB Hosted Zone Z14GRHDCWA56QT、Lightsail IP 52.68.176.128

次にやること: Route53 Weighted Routing で v2 を 10% → 50% → 100% に段階切り替え発射。

2026-04-27 18:07 時点のスナップショット

v2 が https://v2-test.thomsonsapp.com で完全稼働。残るは本番ドメイン切り替えのみ。

v2 全 8 エンドポイントが HTTPS 経由で本番 RDS / 本番 S3 と疎通確認済み
v2-test.thomsonsapp.com は A レコードで Lightsail (52.68.176.128) 向き、TTL 60秒
Let's Encrypt 証明書（CN=v2-test.thomsonsapp.com、自動更新）
Nginx は HTTP/HTTPS 両方受ける構成

次にやること: 本番ドメイン切り替え準備（schulte 用証明書、Nginx schulte server block、切り戻し情報整備）。

2026-04-27 17:51 時点のスナップショット

Lightsail で v2 が本番相当環境で完全稼働。残るは SSL + DNS 切り替えのみ。

v2 全 8 エンドポイントが本番 RDS / 本番 S3 に対して動作確認済み
Lightsail 構成: micro_3_0/1GB/Ubuntu 24.04、静的 IP 52.68.176.128、systemd + Nginx + 専用 IAM
v2 最新コミット b6fedd2（pydantic-settings の extra='ignore' 修正）
本番 v1 は schulte 1号機のみ稼働、2号機は停止中

次にやること: ファイアウォール 443 開放、SSL 取得、DNS 切り替え準備、段階切り替え。

2026-04-27 17:32 時点のスナップショット

Lightsail インスタンス上で v2 が動作確認済み。次は systemd 化 + Nginx + S3 認証。

Lightsail インスタンス作成済み（schulte-server-v2, micro_3_0/1GB, Ubuntu 24.04）
静的 IP: 52.68.176.128、VPC Peering 有効、RDS SG 許可済み
インスタンス内: uv + Python 3.13 + git + gh セットアップ済み
リポジトリ clone 済み + .env 配置済み
uvicorn 動作確認: /healthcheck/db で MySQL 8.4.8 接続, /v1/sync で本番データ取得確認

次にやること: systemd service 化、Nginx リバプロ、IAM ユーザー作成、uploadRanking* 本番確認。

2026-04-27 17:06 時点のスナップショット

v2 (Python/FastAPI) の v1 同等機能 API 全 8 本実装完了。次は Lightsail へのデプロイ。

実装済みエンドポイント (本番 RDS / 本番 S3 で全ケース動作確認済み):
- GET /healthcheck / GET /healthcheck/db
- POST /v1/sendScore
- POST /v1/createPlayer
- POST /v1/updatePlayerName
- GET /v1/sync
- GET /v1/downloadRankingTsv/{mode}/{term}
- GET /v1/uploadRankingTsvToS3/{mode}/{term}/{delay}
- GET /v1/uploadRankingScoresAndPlayersJsonData/{mode}/{term}/{delay}
v2 最新コミット: dfac086
開発時の S3 認証は ~/.aws/credentials の thomson-ik プロファイル経由

次にやること: Lightsail インスタンス構築、本番用 IAM 作成、切り替え手順設計。

2026-04-27 16:51 時点のスナップショット

v2 (Python/FastAPI) の DB 系 API 6本実装完了。残るはバッチ系2本のみ。

実装済みエンドポイント (本番 RDS で全ケース動作確認済み):
- GET /healthcheck / GET /healthcheck/db
- POST /v1/sendScore
- POST /v1/createPlayer
- POST /v1/updatePlayerName
- GET /v1/sync
- GET /v1/downloadRankingTsv/{mode}/{term}
v2 最新コミット: ad714bc (https://github.com/ichirokisanuki/schulte-server-v2/commit/ad714bc)
本番は schulte 1号機のみ稼働、2号機は停止中（AppName=Schulte_maintenance）

次にやること（優先度順）:

バッチ系2本実装: uploadRankingTsvToS3, uploadRankingScoresAndPlayersJsonData（aioboto3 で S3 連携）
v2 を Lightsail に新規構築してデプロイ動作検証
ALB taki から schulte TG を外す or DNS 切り替えで v2 へトラフィック寄せる手順設計

未決事項:

S3 書き込み認証情報をどう持たせるか（次セッション最初の論点）
v2 の動作確認方針: 現状は本番 RDS にテスト送信→削除でやっているが、ローカル MySQL を Docker Compose で立てる方が綺麗（優先度低）
認証機構: 現状 v1 と同じく認証なし。チート対策は v2 完全切り替え後に考える

2026-04-27 16:41 時点のスナップショット

v2 (Python/FastAPI) のコア実装フェーズ。DB 接続 + 主要 API 2本まで完了。

DB スキーマを実 RDS から吸い出し済み (schulte-server-v2/schema/init.sql)
v2 に DB 接続実装済み (aiomysql + SQLAlchemy 2.x async)、本番 RDS (MySQL 8.4.8) で疎通確認
実装済みエンドポイント:
- GET /healthcheck
- GET /healthcheck/db
- POST /v1/sendScore (本番 RDS で4ケース動作確認済み、テストレコードは削除済み)
- GET /v1/sync (本番 RDS で 37 players / 500 scores 取得確認)
v2 最新コミット: 3480683 (https://github.com/ichirokisanuki/schulte-server-v2/commit/3480683)
本番は schulte 1号機のみ稼働、2号機は停止中（AppName=Schulte_maintenance）

次にやること（優先度順）:

残り API 3本実装: createPlayer, updatePlayerName, downloadRankingTsv（DB 操作のみで完結）
バッチ系2本実装: uploadRankingTsvToS3, uploadRankingScoresAndPlayersJsonData（aioboto3 で S3 連携、IAM 認証情報の準備要）
v2 を Lightsail に新規構築してデプロイ動作検証
ALB taki から schulte TG を外す or DNS 切り替えで v2 へトラフィック寄せる手順設計

未決事項:

v2 の動作確認方針: 現状は本番 RDS にテスト送信→削除でやっているが、ローカル MySQL を Docker Compose で立てる方が綺麗。優先度は低いがいつか整備したい
v2 から S3 への書き込み認証: Lightsail 上で動かすときの IAM ロール / アクセスキーをどう持たせるか（環境変数 / IAM Role for EC2 相当の機能 / アクセスキー直書き）
認証機構: 現状 v1 と同じく認証なし。チート対策は v2 完全切り替え後に考える

2026-04-27 15:50 時点のスナップショット

v2 (Python/FastAPI) 開発を本格スタートしたところ。

schulte-server-v2 リポジトリ作成完了 → https://github.com/ichirokisanuki/schulte-server-v2
ローカル: ~/cdev/schulte-operation/schulte-server-v2/
最小スケルトン (/healthcheck) 動作確認済み
本番は schulte 1号機 (i-039d46fb13dc9f81d) のみで継続稼働中
2号機 (i-06541bacc1fd226ea) は停止中、AppName タグ Schulte_maintenance で Lambda 監視対象から外している
ALB taki は schulte 含む5アプリ共有 → v2 移行時に経路変更が必要

次にやること（優先度順）:

DB スキーマを実 RDS (footballnext) から SHOW CREATE TABLE で吸い出す
v2 に DB 接続 (aiomysql + SQLAlchemy async) を実装
v2 に sendScore エンドポイント実装
v2 に sync エンドポイント実装
残りエンドポイント (createPlayer / updatePlayerName / downloadRankingTsv / バッチ系) 実装
v2 を Lightsail に新規構築してデプロイ動作検証

未決事項:

v1 から v2 への切り替え方式: DNS 切り替え or ALB ルール変更で v2 にトラフィック寄せる流れになる想定だが、具体手順は要設計（特にダウンタイムをどう扱うか）
2号機の今後: 永久停止 or v1 のまま塩漬け。本番1台運用で問題なさげなので、当面は停止継続で良さげ
v1 のソースコード (CodeCommit) を GitHub 移行する話は v2 で書き直す方針になり優先度が大きく下がった。完全撤退時に CodeCommit ごと閉じる運用で良さそう

2026-04-27 13:11 時点のスナップショット

プロジェクトの初期セットアップ段階。

リポジトリ直下に schulte-server/ schulte-unity/ を物理配置済み（.gitignore で除外、別管理）
CLAUDE.md にプロジェクト概要を記入済み（Unity + PHP / EC2 nano × 2台 + LB / RDS 間借り）
直近ロードマップ3項目を .devnotes/ROADMAP.md 「今月」に登録済み
1. EC2 nano × 2台 → Lightsail 1台への縮小
2. schulte-server を CodeCommit → github.com に移行
3. schulte-unity を CodeCommit → github.com に移行（要検討）

次にやること: 上記3項目のうちどれから着手するか方針決定。着手する場合の準備として、CodeCommit 側のリポジトリ実態（サイズ・ブランチ）を把握する必要がある。

未決事項: schulte-unity のリポジトリサイズが大きい場合、GitHub に上げるかどうか（LFS 利用 / 一部除外 / 移行見送りなどの選択肢）。

ROADMAP（計画）

ロードマップ

今週

すべて完了。

今月

本番 DNS 切り替え発射: Route53 Weighted Routing で v2 を 10% → 50% → 100% に段階切り替え
監視サービス (senrigan-observer) の URL を /healthcheck に変更
翌朝 (2026/4/28 7:42 の dev-timer 通知) で v2 安定稼働確認
ALB schulte TG から 1号機を deregister
1号機 EC2 停止 (AppName=Schulte_maintenance タグで Lambda 自動再起動防止)
DNS の alb-v1 Weight 0 レコード削除
ALB taki から schulte リスナールール + schulte TG 削除
Lambda TCM_observeALB_* の Schulte 関連分削除
旧 schulte EC2 (1号機・2号機) を terminate
v2 リソース増強 (swap 1GB + uvicorn workers=2)
本番 RDS (footballnext / baseballnext) を PubliclyAccessible=false 化（月 -$7.3）

今四半期

schulte-unity を CodeCommit → github.com に移行（リポジトリ容量次第）
（別リポジトリ ~/cdev/common-php-my-admin 側で）SSH トンネル経由 phpmyadmin の整備
（オプション）kizuna RDS も PubliclyAccessible=false 化（月 -$3.65 追加削減）

いつか

認証機構の追加（チート対策、現状はスコア偽造可能）
IP ベースのレート制限
レスポンスタイム計測やエラー集計（メトリクス）の整備
v2 のテスト整備（pytest + httpx）
ローカル開発用 MySQL を Docker Compose で立てる
v2 のログを CloudWatch Logs / Loki などに集約（現状 systemd journal のみ）
旧 ACM 証明書 (arn:aws:acm:.../4eec...) の SAN 確認 → schulte 用 SAN だけ削れるなら削除

DECISIONS（意思決定）

意思決定記録

このプロジェクトで下した重要な意思決定を記録する。最新が上に来る。

2026-04-28: 本番 RDS は PubliclyAccessible=false に統一（コスト削減 + セキュリティ）

背景: 撤退作業の延長で AWS account 内の EIP 一覧を確認した結果、4個の Elastic IP が RequesterManaged で残存していた。うち 2個は ALB 用 (release 不可)、2個は RDS 用 (amazon-rds 管理) で、PubliclyAccessible=true ゆえに保持されていることが判明。2024-02-01 から AWS は auto-assigned Public IPv4 にも課金するようになっており、Public 維持のコストが顕在化していた。

決定: 本番 RDS (footballnext / baseballnext) は PubliclyAccessible=false に統一する。インターネット経由での到達は不要（接続元はすべて同 VPC 内 EC2 / VPC Peering 経由 Lightsail）。phpmyadmin など外部から直接接続していたツールは SSH トンネル方式へ切り替える。

理由:

2 RDS で月 $7.3 のコスト削減（EIP × 2 が amazon-rds 管理で自動解放される）
DNS 解決でも RDS のホスト名が世界から見えなくなり、攻撃面の縮小
Public 接続点を持たない方が、SG ミス時のフォールバックも安全
phpmyadmin 系は SSH トンネル経由の方が現代的な運用

2026-04-28: ALB 用 EIP (`amazon-elb` RequesterManaged) は触らない方針

背景: ALB taki にぶら下がる Elastic IP × 2 (175.41.232.218 / 54.92.6.226) は RequesterManaged=true、RequesterId=amazon-elb で AWS が自動管理。release-address を試しても OperationNotPermitted で拒否される。手動解放の手段は ALB 自体を削除するしかない。

決定: ALB 用 EIP は触らない。ALB taki は schulte 以外の4アプリで継続使用するため削除しない。

理由:

ALB taki を削除すると baseballnext / footballnext / machiga / sposhin の経路が壊れる
ALB を残す限り EIP も AWS が自動でメンテし続けるので、release できないことに実害はない
ALB の月額に EIP 課金分は事実上含まれており、別計上で動かせない構造

2026-04-28: v2 のリソース増強 (swap 1GB + uvicorn workers=2)

背景: 100% v2 切り替え後の長期運用に向けて、深夜帯の安定性をリスク分析した。Lightsail micro_3_0 (1GB RAM) は swap なし、uvicorn は single worker で起動していた。OOM 時のフェイルセーフがなく、長時間処理がリクエストをブロックする構成。

決定: Lightsail インスタンスに以下を追加。

/swapfile 1GB を作成し /etc/fstab で永続化
systemd unit の ExecStart に --workers 2 を追加して uvicorn を 2 worker に

理由:

swap は OOM Killer 発動前のセーフティネット。physical メモリが枯渇しても緩やかに劣化（即座に kill されない）
workers=2 なら長時間処理（uploadRanking* 等）の最中でも他リクエストが詰まらない
追加コストはゼロ（既存 Lightsail プラン内のリソース）
メモリ available 356MB 確保できているので実害なし

2026-04-28: phpmyadmin 接続は SSH トンネル方式に切り替える（本番 RDS Public 戻しはしない）

背景: RDS Private 化の副作用で ~/cdev/common-php-my-admin (mydb.ikapps.com) から footballnext / baseballnext へ接続不可になった。Public に戻す案 (月 +$7.3) と、SSH トンネル経由でアクセスする案を比較。

決定: SSH トンネル方式を採用する。多目的サーバー (Lightsail) から cron インスタンス (52.194.87.168) を踏み台にして、systemd 管理の常時 SSH トンネルを張る。config.inc.php の host を 127.0.0.1:13306 127.0.0.1:13307 に変更。

理由:

Public に戻すと月 $7.3 のコストが復活、セキュリティ面でも逆行
SSH トンネルは追加コストゼロ、踏み台 (cron インスタンス) は既に存在
RequesterManaged 解放後の状態を維持したまま、phpmyadmin の利便性を取り戻せる
同じ仕組みで kizuna も Private 化可能（オプション、追加で月 -$3.65）

実作業の場所: 別リポジトリ ~/cdev/common-php-my-admin 側で対応。引き継ぎは 引き継ぎ.md に記載済み。

2026-04-27: 監視サービスの死活監視 URL は v2 標準の `/healthcheck` に統一

背景: schulte.thomsonsapp.com/v1/healthcheck は v1 のみのエンドポイント (PHP datetime() 文字列を返す)。v2 では /v1/healthcheck を実装せず /healthcheck ({"status":"ok"} を返す) を持っている。本番切り替え中に外部監視サービス senrigan-observer/0.1 が /v1/healthcheck を死活監視していることが判明し、振り分けされた瞬間に 404 でアラートが鳴る問題に直面した。

決定: 監視 URL を /v1/healthcheck から /healthcheck に変更する。v2 に /v1/healthcheck 互換実装を追加するのではなく、v1 撤退完了に向けて素直に v2 標準のエンドポイントに監視も寄せる方針。

理由:

100% v2 切り替えと同時に v1 が完全停止するなら、/v1/* 互換性を v2 で保つ意味は薄い
監視 URL は外部サービス側で書き換えるだけで完結（v2 のコード変更なし）
/healthcheck は v2 標準のシンプルな名前で、新規 API 設計とも自然

2026-04-27: 切り戻し用に ALB Alias レコードを Weight 0 で残置する

背景: 100% v2 切り替え後、ALB へのトラフィックは完全にゼロ (CloudWatch メトリクスで確認)。ALB Alias レコードを削除すれば Route53 構成はシンプルになるが、即時切り戻しの選択肢を失う。

決定: ALB Alias レコード (alb-v1) を Weight 0 のまま残置する。十分な観測期間（少なくとも数時間〜1日）を経て安定確認できたら、その後で削除する。

理由:

Weighted Routing で Weight 0 のレコードは選択されないため、実害ゼロ
万一 v2 で何か問題が出ても、Weight を 100/0 から 0/100 に戻すだけで即時切り戻し可能（TTL 60秒で復旧）
削除コストは1分なので、撤退時にいつでもクリーンアップできる

2026-04-27: v1 → v2 切り替えはサブドメイン事前検証 + Weighted Routing で段階切り替え

背景: v2 の本番投入時、schulte.thomsonsapp.com の DNS A レコードを直接 Lightsail 静的 IP に切り替えると、リアルユーザーへの影響が一括で発生する。レスポンス形式の微妙な差異や負荷耐性の不明なまま全切り替えするのはリスクが高い。

決定: 以下の3段構えで切り替えを進める。

事前検証: v2-test.thomsonsapp.com というテスト用サブドメインを切り、Lightsail に向ける。Let's Encrypt 証明書も別途取得し、HTTPS で全エンドポイント動作確認する（本番影響ゼロ）。
TTL 短縮: 本番 schulte.thomsonsapp.com の TTL を切り替え数日前に短縮（現在 ALB の Alias なのでそもそも TTL 効かない可能性、要確認）。
段階切り替え: Route53 Weighted Routing を使い、v2 への割合を 10% → 50% → 100% と段階的に増やす。各段階で観測し、問題があれば即 v1 に戻す。

理由:

「全か無か」の切り替えは個人開発でもリスクが大きすぎる
Weighted Routing は Route53 標準機能で追加コストなし
切り戻しは DNS レコードの重みを 0 に戻すだけ、TTL 60秒なら 1分以内で復帰可能
サブドメイン検証は本番影響ゼロでフルテストできる、典型的な Blue/Green 戦法に近い

2026-04-27: SSL 証明書は Let's Encrypt + DNS-01 challenge (certbot-dns-route53)

背景: v2 は HTTPS 必須（Unity クライアントが https://schulte.thomsonsapp.com/v1/... で叩いてくる）。ALB にある既存 ACM 証明書は Lightsail で流用できないため、Lightsail 側で独自に証明書を持つ必要がある。HTTP-01 challenge と DNS-01 challenge から方式選択。

決定: Let's Encrypt + DNS-01 challenge を採用。certbot-dns-route53 plugin を使い、専用 IAM ユーザー schulte-server-v2-cert のクレデンシャルで Route53 を操作する。

理由:

HTTP-01 はドメインが既に Lightsail に向いている必要があり、本番ドメインの切り替え前には使えない
DNS-01 はドメインの実所属に依存せず、Route53 にレコードを置くだけで検証完了
本番ドメイン (schulte.thomsonsapp.com) も切り替え前に証明書を準備しておけるので、切り替え時の手間が減る
IAM は route53:ChangeResourceRecordSets を arn:aws:route53:::hostedzone/<zone> 限定の最小権限
certbot は Ubuntu apt 経由でインストールすると systemd timer による自動更新が組み込まれる

2026-04-27: v2 用 IAM ユーザーは最小権限 (s3:PutObject + PutObjectAcl on rankings/* のみ)

背景: v2 の S3 連携 (uploadRanking* バッチ) を本番 Lightsail 環境で動かすにあたり、使う IAM ユーザーの権限設計が必要だった。広い権限のユーザー (ichirokisanuki のような S3FullAccess 持ち) を流用する案もあったが、本番運用ではキー漏洩時の被害最小化を優先。

決定: 専用ユーザー schulte-server-v2-s3 を新規作成し、インラインポリシー S3PutObjectRankings で s3:PutObject + s3:PutObjectAcl を arn:aws:s3:::schulte-thomsons/rankings/* のみに許可する。それ以外（DELETE、GetObject、他バケット、他サービス）は一切許可しない。

理由:

万一キーが漏洩しても、schulte-thomsons バケットの rankings/ 配下の上書きしかできず、被害は v1 cron が次の周期で上書きすれば自動修復可能
削除権限なし → 既存ファイルを消されることはない
他バケット・他サービス不可 → 横展開のリスクなし
個人開発でも本番運用での衛生的な分離を選んだ

2026-04-27: pydantic-settings の Settings には必ず `extra='ignore'` を明示する

背景: v2 を Lightsail で systemd 化した際、.env に AWS_ACCESS_KEY_ID 等を追加したら起動が失敗。原因は pydantic-settings v2 のデフォルトが extra='forbid' で、Settings 未定義の環境変数があるとバリデーションエラーになる仕様だった。さらに、エラーメッセージ input_value='...' に secret access key の生値 が含まれて journalctl に出力され、ローカルターミナル / Claude session context に露出した（即無効化で実害なし）。

決定: 全プロジェクトで Settings クラスに model_config = SettingsConfigDict(..., extra="ignore") を必ず明示する。これにより、.env に Settings 未定義のキー（AWS 認証情報など、SDK が直接環境変数から拾うもの）を書いてもエラーにならず、かつ秘密情報がエラーメッセージに混入しない。

理由:

pydantic のエラーは入力値を input_value=... でそのまま出すため、秘密情報を含む環境変数では深刻な情報漏洩源になる
aioboto3 / boto3 は AWS_* を環境変数から自動で拾うので、Settings で受け取る必要はない
「未定義の env は無視する」が現代的な API 設計でも一般的な振る舞い

2026-04-27: Lightsail プランは micro_3_0 ($7/月, 1GB RAM, dual stack)

背景: Lightsail プラン選定で当初 $5 (nano dual stack) を希望したが、AWS CLI で get-bundles した結果、$5/dual stack は 0.5GB RAM であり、v1 が 461MB で破綻していたのと同程度のメモリ余裕しかないことが判明。$5 で 1GB を取るには IPv6 only プランしかなく、モバイルアプリ（IPv4 必須）には不適。

決定: micro_3_0 (1GB RAM / 2 vCPU / 40GB SSD / 2TB transfer / dual stack, $7/月) を採用。

理由:

v1 のメモリ問題（mod_php5 prefork で 392MB / 461MB 占有）の悲劇を避けたい
v2 の uvicorn + FastAPI は起動時 100-150MB と軽いが、ピーク時の余裕とバッファキャッシュ用に 1GB は欲しい
$5 → $7 の差額 $2/月は EC2 nano × 2 + ALB の現状（$30/月以上）からは劇的なコスト減のうち

2026-04-27: Lightsail OS は Ubuntu 24.04 LTS、AZ は ap-northeast-1a

背景: Lightsail で利用可能な Linux ディストリビューションのうち、Ubuntu 24.04 / 22.04 / Amazon Linux 2023 などから選ぶ必要があった。

決定: Ubuntu 24.04 LTS、AZ は ap-northeast-1a。

理由:

Ubuntu 24.04 は LTS（〜2034 サポート）で長期運用に向く
Python 3.13 は OS 標準にはないが、uv python install 3.13 で即取得できるため OS 選定にほぼ影響なし
情報量が多く、トラブルシューティングが容易
AZ は RDS footballnext と同じ ap-northeast-1a に揃え、ネットワークレイテンシを最小化

2026-04-27: Lightsail ↔ RDS の接続は VPC Peering + RDS SG に Lightsail CIDR /16 許可

背景: Lightsail インスタンスは Lightsail 専用 VPC に置かれ、AWS の default VPC（RDS が居る）とは別ネットワーク。接続経路として (a) RDS を public access に変更 + IP 制限、(b) VPC Peering 有効化 + RDS SG にプライベート IP 許可、の2案を比較。

決定: Lightsail VPC Peering を有効化（無料、API ボタン1つ）+ RDS の Security Group に inbound 172.26.0.0/16:3306 を追加（Lightsail 全体の private CIDR を許可）。

理由:

VPC Peering なら通信が AWS 内部完結、インターネット経由なし → セキュリティ・レイテンシともに有利
RDS の public access 化は影響範囲が広く、運用ミスで世界に晒すリスクあり、却下
/32 でインスタンスごとの IP を許可する案もあったが、再起動や再作成で IP 変動するたび手作業が増えるため、個人開発の運用コスト優先で /16 採用

2026-04-27: 開発時の S3 認証は AWS CLI プロファイル `thomson-ik` 経由

背景: v2 の S3 連携 (uploadRanking* バッチ) を実装するにあたり、開発時の AWS 認証情報をどう持たせるか3案あった: (A) 既存 ~/.aws/credentials の thomson-ik プロファイル流用、(B) .env に IAM アクセスキー埋め込み、(C) 専用の最小権限 IAM ユーザー新規作成。

決定: (A) の既存プロファイル流用を採用。aioboto3 は SDK のデフォルト認証チェーン（環境変数 → ~/.aws/credentials → IAM Role）を辿るので、コード側で profile 名を埋めず aioboto3.Session() だけで動く。起動時に AWS_PROFILE=thomson-ik を渡す運用。

理由:

開発はローカルマシンに閉じる、追加の IAM 操作不要で即着手できる
コードに認証情報を埋め込まないので、本番デプロイ時もコード変更ゼロで動く（環境変数 / .env の値だけ切り替え）
本番用の最小権限 IAM ユーザー作成 (s3:PutObject on schulte-thomsons のみ) は Lightsail 構築時に別タスクとして実施する方針。設計が綺麗

2026-04-27: schulte-server-v2 として Python / FastAPI で書き直す（v1 のレガシー継承を断念）

背景: schulte-server (v1) は Amazon Linux 1 + PHP 5.3 + CakePHP 2.0.4 + Apache 2.2 という EOL 続きのレガシースタックで、Lightsail 移行に際して PHP-FPM 化や OS/PHP アップグレードを行うには大幅な改修が必要。一方で実 API は 8 本のみ、認証なし、外部連携は S3 のみと構造が極めてシンプルだった。

決定: v1 のレガシースタック継承（PHP-FPM 化、PHP/OS アップグレード）を断念し、Python 3.13 + FastAPI で schulte-server-v2 として完全に書き直す。v1 と v2 を並行運用しつつ徐々に v2 に切り替える。

理由:

実 API 8本という小規模で、書き直し工数は週末ハッカソン〜1〜2週間規模
レガシー継承は短期的にメモリ問題は解決するが、Lightsail 移行時に結局 PHP/OS アップグレードが必要になり「やり直し」感が強い
Python / FastAPI は LLM 補助との相性が最も良く、個人開発の長期保守に向く
DB は既存 RDS の schulte データベースを流用、書き換えコストは API コードのみで済む

2026-04-27: schulte-server-v2 リポジトリは operation 直下に物理配置、別 GitHub 管理

背景: v2 リポジトリの配置として、(A) ~/cdev/schulte-server-v2/ に独立配置、(B) ~/cdev/schulte-operation/schulte-server-v2/ に operation 直下同居、を比較した。

決定: operation 直下 ~/cdev/schulte-operation/schulte-server-v2/ に物理配置する。git 管理は別リポジトリ ichirokisanuki/schulte-server-v2 (private) として独立。operation 側の .gitignore に /schulte-server-v2/ を追加して除外する。

理由:

既存の schulte-server/ schulte-unity/ と同じパターンで一貫性がある
v1 のソースと並べて参照しながら v2 を書ける（実装時の生産性が高い）
git 管理は完全に独立しているので互いの履歴は混じらない

2026-04-27: schulte-server-v2 の開発メモは operation 側 .devnotes/ に集約

背景: v2 リポジトリにも .devnotes/ を置くと「どっちに書くか問題」が発生し、メモが分散して .devnotes/ 運用の設計が壊れる懸念があった。

決定: v2 リポジトリには .devnotes/ を置かない。schulte-operation 全体を「アプリ運用全体のオペレーション」と位置付け、v2 開発のメモも operation 側の .devnotes/ 4ファイルに集約する。v2 リポジトリの README で「開発メモは operation/.devnotes/ 参照」と明記する。

理由:

個人開発において運用と開発の境界は曖昧で、operation = アプリ運用全体のメモ置き場とする位置付けが綺麗
メモが一元管理されることで意思決定の追跡が容易
v2 リポジトリは「コードのみ、自己完結」のシンプル構造を保てる

2026-04-27: v1 の PHP-FPM 化（メモリ問題改善）は実施しない

背景: v1 のメモリ余裕がない原因 = mod_php5 prefork (各 child 約45MB × 9) を解決するため、Apache 2.4 + php-fpm 化（α: mod_fcgid + php-cgi、γ: httpd24 + mod_proxy_fcgi + php-fpm）の検証を進めていた。2号機を ALB から detach し、AppName タグ書き換えで Lambda 監視対象から外したところまで実施済み。

決定: PHP-FPM 化は実施しない。v2 路線への方針転換に伴い、v1 はメモリ問題を抱えたまま残り稼働期間を耐えさせる。

理由:

v1 を改修してもいずれ v2 に置き換えるため、改修コストが無駄になる
本番は1台のみでも CPU 1%、ピーク 0.3 RPS と余裕があり、現状でも運用継続可能
2号機は停止して、本番1台運用で v2 リプレース完了まで耐える運用に切り替える

2026-04-27: schulte-operation を「運用リポジトリ」と位置付け、実装ソースは同居させない

背景: リポジトリ直下に schulte-server/（PHP バックエンド）と schulte-unity/（Unity クライアント）を物理配置するが、これらをこの operation リポジトリ自身でバージョン管理するか、別リポジトリ管理のまま .gitignore で除外するかを決める必要があった。

決定: schulte-operation はインフラ・運用ドキュメント・ロードマップを置く「運用リポジトリ」と位置付ける。schulte-server/ schulte-unity/ は .gitignore で除外し、本リポジトリの履歴・コミット対象には含めない。

理由:

実装ソースと運用情報をひとつのリポジトリに混ぜると、コミット履歴が肥大化し、運用変更と実装変更の区別が付きにくくなる
特に schulte-unity はリポジトリサイズが大きそうで、operation 側に巻き込むのは現実的でない
直近ロードマップで両者を CodeCommit → github.com に独立移行する予定があり、それぞれは独立したリポジトリのまま運用するのが自然

DEVLOG（作業ログ）

開発日誌

このプロジェクトでの作業を時系列で記録する。最新のエントリが上に来る。

2026-04-28

12:25 - 撤退完了 + v2 リソース増強 + RDS Private 化で月$24削減 + phpmyadmin 引き継ぎ書

やったこと:

(1) v2 のリソース増強（深夜帯の安定運用に向けて）

起動から長時間稼働での安定性を分析
swap 1GB 追加 (/swapfile、fstab で永続化) → OOM 時のセーフティネット
uvicorn workers=2 に変更 (--workers 2) → 長時間処理でブロックしない
メモリ available 356MB + swap 1GB、systemd Restart=on-failure で完成形
追加コストゼロ（既存 Lightsail プランのリソース内）

(2) 撤退作業残タスク完遂（観測時間を待たずに進めた）

DNS の alb-v1 (Weight 0) レコード削除（切り戻し用残置を解除）
ALB taki から schulte 用 listener rule × 2 (HTTP/HTTPS) を削除
ALB schulte TG 自体を削除（taki ALB 自体は他4アプリ用に残置）
Lambda 3つ (TCM_observeALB_*) の Schulte 行をコメントアウトして再デプロイ
EC2 1号機・2号機を terminate-instances で完全削除
dev-timer #4 (4/29 19:50 terminate リマインダ) を done でキャンセル

(3) EIP 課金問題の深堀り

ユーザー指摘で「EC2 stopped 後の Public IPv4 課金は $0 (auto-assigned IP は解放済み)」を確認
AWS account 内の EIP 一覧を確認 → 5 個中 4 個が InstanceId: null、月 $14.6 の浪費に見えた
詳細確認したところ: 4個とも実は RequesterManaged=true で AWS 管理（ALB taki 用 × 2 / RDS 用 × 2）
ALB 用 2 個は ALB を残す限り解放不可（amazon-elb 管理）

(4) RDS の PubliclyAccessible=false 化（コスト削減 + セキュリティ向上）

baseballnext footballnext の PubliclyAccessible を true → false に変更（即時反映）
副作用: amazon-rds が管理してた EIP 2 個 (3.115.155.164 / 52.198.72.205) が自動解放 された
月 -$7.3 のコスト削減 + DNS 解析で RDS が見えなくなる security 向上

(5) phpmyadmin 接続不可問題の発覚と方針決定

(4) の副作用で、別 account の Lightsail (mydb.ikapps.com の phpmyadmin) から footballnext / baseballnext へ接続不可に
「Public 経由で繋いでた」前提が崩れた
ユーザー判断: Public 戻し（月 $7.3 増）は不採用、SSH トンネル方式で復活させる方針
作業は別リポジトリ (~/cdev/common-php-my-admin) 側で行うため、引き継ぎ.md を作成 → 即作業開始できるよう「背景・構成案・やること詳細・必要情報・注意点」を網羅

(6) kizuna RDS の調査（PubliclyAccessible=true なのに EIP がない件）

別 account (ichirokisanuki, 776364707178) の RDS、2015年作成
Public IP は auto-assigned（describe-addresses には出ないが、2024-02 以降月 $3.65 課金されている）
前回の説明「PubliclyAccessible=true → EIP が付く」は 不正確だったと訂正
正しい説明: 「Public IP（auto-assigned が標準、EIP は特殊ケース）が付く。いずれも 2024-02 以降は課金対象」
footballnext / baseballnext は EIP が手動 associate されてた特殊状態だったことが判明
kizuna も同じ仕組みで Private 化すれば月 $3.65 削減可能（オプション、phpmyadmin SSH トンネル整備後に検討）

(7) ロードマップ整理

今月の撤退タスクすべて完了マーク
残るのは「明朝 dev-timer #3 通知での観測（自動）」と「今四半期: schulte-unity GitHub 移行」のみ

決めたこと:（→ DECISIONS.md 参照）

v2 のリソース増強: swap 1GB 追加 + uvicorn workers=2
本番 RDS は PubliclyAccessible=false に統一する方針
phpmyadmin 経由のアクセスは SSH トンネル方式で代替（Public に戻さない）
ALB 用 EIP (amazon-elb RequesterManaged) は触らない（ALB を維持する限り release 不可）

詰まったこと / 気づき:

pydantic-settings の extra='forbid' のときに journalctl にエラー値が露出した過去のヒヤリハットを思い出す形で、AWS のエラーメッセージや IAM operation も同様に「変数値が出る可能性」を意識
OperationNotPermitted は権限ではなくリソース管理状態（RequesterManaged）が原因
modify-db-instance で --apply-immediately --no-publicly-accessible は数十秒で反映、ENI の Public IP が外れて EIP も自動解放（amazon-rds 管理だから）
2024-02 から auto-assigned Public IPv4 にも課金されるようになった点は、見落としやすい

次回やること:

明朝の dev-timer #3 (2026/4/28 7:42) はもう過ぎているので、結局 wrap up 前にスナップショット観測を兼ねた
共通 phpmyadmin 側で SSH トンネル化（別リポジトリ ~/cdev/common-php-my-admin/引き継ぎ.md 参照）
その後オプションで kizuna も PubliclyAccessible=false 化（月 -$3.65 追加削減）
大物として schulte-unity の CodeCommit → GitHub 移行（今四半期内）

2026-04-27

19:43 - 撤退作業の最初の一歩: 1号機停止 + 12h タイマー

やったこと:

(1) dev-timer に翌朝の確認用リマインダ登録

--in 12h --project schulte-operation "v2 切り替え後の安定稼働確認 (翌朝)"
ID #3、発火予定 2026/4/28 7:42:16（明朝）

(2) 1号機 (i-039d46fb13dc9f81d) の停止

AppName タグ: Schulte → Schulte_maintenance（2号機と同じ運用、Lambda 自動再起動防止）
ALB schulte TG から deregister-targets (draining 開始)
stop-instances 実行（running → stopping → 数十秒で stopped へ）
順序が大事: AppName 変更を先にしないと、stop 後に startEC2 Lambda が拾って再起動してしまう

詰まったこと / 気づき:

detach Lambda (TCM_observeALB_detachEC2FromTargetGroup) は AppName でフィルタリングしてないので、unhealthy 7分後に「detach + stop」+ SNS アラートを鳴らす可能性があった。手動 deregister + stop で先回りして回避

次回やること:

翌朝 (12h タイマーで通知が来てから) v2 が深夜帯〜朝のピークを耐えたか確認
問題なければ撤退の続き: DNS alb-v1 レコード削除 → ALB schulte リスナールール削除 → ALB schulte TG 削除 → Lambda 整理 → EC2 terminate

19:33 - 🎯 本番 DNS 切り替え完了 (10% → 50% → 100%)、v2 が完全稼働

やったこと:

(1) 本番切り替え発射 (10% Lightsail / 90% ALB)

change-resource-record-sets で schulte.thomsonsapp.com を Weighted Routing 構成に変更
- DELETE 旧 Alias レコード → CREATE alb-v1 (Weight 90, Alias) + lightsail-v2 (Weight 10, A=52.68.176.128)
INSYNC 確認、dig 50回で実測振り分け確認
10 分観測: cron インスタンス (52.194.87.168) からの uploadRanking* 3件が v2 で 200 OK
- 一番重要な動作: 本番 S3 バケット schulte-thomsons への書き込みが v2 経由で成功
Unity からの sendScore はサンプル小（0.3 RPS × 10% × 10分 ≒ 数件期待）でログには現れず

(2) 50% に拡大

alb-v1 / lightsail-v2 ともに Weight 50 に UPSERT
10 分観測:
- Unity SchulteTable/2 CFNetwork/... からの POST /v1/sendScore が 27 件全部 200 OK（実 iOS クライアント動作確認）
- cron uploadRanking* も 19 件全 200 OK
- 5xx エラーゼロ、uvicorn 例外ゼロ、メモリ余裕

(3) /v1/healthcheck 404 問題

ユーザーから「移管されてない」報告 → ブラウザで https://schulte.thomsonsapp.com/v1/healthcheck を叩いたら 404
原因究明: /v1/healthcheck は v1 のみ実装 (datetime 文字列を返す)、v2 は /healthcheck のみ実装
ログを見ると senrigan-observer/0.1 という外部監視サービスが /v1/healthcheck を死活監視していた → 50% 振り分けの半分が 404 でアラート出る恐れ
対応案: (a) v2 に /v1/healthcheck 互換実装 / (b) 100% v2 後に監視先を /healthcheck に変更
ユーザー判断で (b) を採用、ただし先に 100% v2 に切り替える順序で

(4) 100% v2 に切り替え

alb-v1 → Weight 0 (削除はせず残置、即時切り戻し用)
lightsail-v2 → Weight 100
INSYNC 確認、dig 50回 → 50/50 全部 Lightsail に向く
ユーザー側で監視サービスの URL を /v1/healthcheck → /healthcheck に変更（404 アラート解消）

(5) 100% 切り替え後 5 分観測

ALB schulte TG への RequestCountPerTarget: 19:26 以降 0 RPM （切り替え時刻から完全にゼロ）
v2 へのトラフィック: 5分で 24 リクエスト = avg 0.08 RPS
エンドポイント別: sendScore 33 / uploadRankingTsvToS3 23 / uploadRankingScoresAndPlayersJsonData 23 / sync 4 / healthcheck 9
200 ステータス: 79 件、5xx ゼロ、uvicorn 例外ゼロ、メモリ available 424MB

決めたこと:（→ DECISIONS.md 参照）

監視サービス (senrigan-observer) の URL を /v1/healthcheck → /healthcheck (v2 仕様) に変更
ALB schulte TG への振り分け (alb-v1 レコード) は Weight 0 で残置、即時切り戻し用に保持

詰まったこと / 気づき:

DNS Weighted Routing は確率分散なので、サンプル数 50 では誤差 ±10〜20% は普通。実トラフィックが少ないと観測値が想定からズレる
大切なのは「ALB 経由のリクエスト数 (CloudWatch メトリクス)」を見ること。直接的に「v2 にどれくらい流れたか」がわかる
/v1/healthcheck の存在を v2 で実装し忘れていたが、結果的に「100% 切り替え後に監視を v2 標準の /healthcheck に揃える」が綺麗な解決になった

次回やること:

数時間〜1日の安定運用観測
観測 OK 後、撤退フェーズ:
- ALB schulte TG から 1号機 (i-039d46fb13dc9f81d) を deregister
- 1号機 EC2 停止
- DNS の alb-v1 (Weight 0) レコード削除
- Lambda TCM_observeALB_* の Schulte 関連分削除
- ALB taki の schulte リスナールール削除 (taki ALB は他4アプリで継続使用)

18:51 - 本番ドメイン切り替え準備完了（証明書、Nginx、切り戻し情報）

やったこと:

(1) schulte.thomsonsapp.com の Hosted Zone と現在の DNS レコード把握

委任先 zone id: Z035498717N5DORY02AM0（thomsonsapp.com 本体 zone から NS で分離されてる）
現在の A レコード: Alias で dualstack.taki-879563088.ap-northeast-1.elb.amazonaws.com. (ALB taki)
HostedZoneId of ALB: Z14GRHDCWA56QT、EvaluateTargetHealth: true

(2) certbot 用 IAM ユーザー schulte-server-v2-cert のポリシー更新

route53:ChangeResourceRecordSets の Resource を 2 zone に拡張
- arn:aws:route53:::hostedzone/ZN306RXECIMLN（thomsonsapp.com）
- arn:aws:route53:::hostedzone/Z035498717N5DORY02AM0（schulte.thomsonsapp.com）

(3) schulte.thomsonsapp.com 用 SSL 証明書取得（DNS-01 challenge）

Lightsail 内で certbot certonly --dns-route53 -d schulte.thomsonsapp.com
取得成功、有効期限 2026-07-26、自動更新タスクあり

(4) Nginx config 更新

server_name schulte.thomsonsapp.com の HTTPS server block を追加
v2-test.thomsonsapp.com 用も並存（default_server も兼ねる）
HTTP 80 は default_server _ で全ホスト名を受け（cron からの HTTP curl 用）

(5) 動作確認（本番 DNS 未変更、curl --resolve で Lightsail に直接接続）

curl --resolve schulte.thomsonsapp.com:443:52.68.176.128 https://schulte.thomsonsapp.com/...
証明書 CN = schulte.thomsonsapp.com、Issuer = Let's Encrypt → 正しい証明書が返る
/v1/sync で本番データ取得 OK、v2-test 経路も並存して動作 OK

(6) 切り戻し情報の inline 記録（バックアップファイルは作らずここに記録）

切り戻し用情報（重要）:

現在の schulte.thomsonsapp.com (zone Z035498717N5DORY02AM0) の A レコードは Route53 Alias:

{
    "Name": "schulte.thomsonsapp.com.",
    "Type": "A",
    "AliasTarget": {
        "HostedZoneId": "Z14GRHDCWA56QT",
        "DNSName": "dualstack.taki-879563088.ap-northeast-1.elb.amazonaws.com.",
        "EvaluateTargetHealth": true
    }
}

→ 切り戻し時はこの内容で change-resource-record-sets の UPSERT を実行する。

切り替え時の v2 用 A レコード:

{
    "Name": "schulte.thomsonsapp.com.",
    "Type": "A",
    "TTL": 60,
    "ResourceRecords": [{"Value": "52.68.176.128"}]
}

詰まったこと / 気づき:

schulte.thomsonsapp.com は別 zone に NS 委任されてる構成だった。同じ thomsonsapp.com zone 内にあると思い込んでた
Alias レコードは TTL を直接持たず Route53 が短い TTL で管理する → TTL 短縮の追加作業は不要。Lightsail 用に切り替えると Alias から普通の A レコード (TTL 60) に変わる
.devnotes/ 配下に backup ディレクトリを作ったが、session-wrap-up スキルの「4ファイル以外を作らない」ルールに違反するので削除し、切り戻し情報は本 DEVLOG にインライン記録する方針に切り替え

次回やること:

本番切り替え発射: Route53 Weighted Routing で v2 を 10% → 50% → 100% に段階切り替え
各段階で systemd journal を観測（500 エラー / レスポンスタイム異常）
100% 到達後、v1 EC2 2台停止 + 関連 Lambda (TCM_observeALB_*) 整理

18:07 - HTTPS 化完了、v2 が `https://v2-test.thomsonsapp.com` で全エンドポイント動作

やったこと:

(1) Lightsail ファイアウォール 443 開放（22/80/443 の3 port）

(2) Route53 IAM 権限の追加

ichirokisanuki ユーザーは attached managed policy が 10 個（上限）
11個目を attach できないため、インラインポリシー Route53Access (route53:*) で対応
既存の LightsailFullAccess インラインに続いて2件目

(3) Unity クライアント URL 確認

schulte-unity/Assets/ を grep → 全エンドポイント https://schulte.thomsonsapp.com/v1/... で叩いてる
ALB taki にも HTTPS 443 リスナーがあり、ACM 証明書 (arn:aws:acm:.../4eec...) でサーブ中
Lightsail に切り替えるなら独自に SSL 証明書が必要（ACM は ALB/CloudFront 専用、Lightsail には流用不可）

(4) DNS 切り替え方針の検討

ALB ターゲットは VPC 内 IP のみ → Lightsail インスタンスは ALB 配下に入れられない
→ DNS 切り替え方式に確定
切り替え時のリスクを下げるため v2-test.thomsonsapp.com サブドメインで事前検証 案を採用

(5) v2-test.thomsonsapp.com 用 DNS レコード作成

thomsonsapp.com の Hosted Zone ID ZN306RXECIMLN
A レコード: v2-test.thomsonsapp.com → 52.68.176.128、TTL 60秒
INSYNC 確認 + Google DNS で浸透確認

(6) certbot 用 IAM ユーザー作成 (最小権限)

schulte-server-v2-cert 新規作成
インラインポリシー CertbotDnsRoute53:
- route53:ListHostedZones, route53:GetChange (Resource: *)
- route53:ChangeResourceRecordSets (Resource: arn:aws:route53:::hostedzone/ZN306RXECIMLN 限定)
アクセスキー発行 → Lightsail /etc/letsencrypt/aws-credentials (mode 600) に配置

(7) Let's Encrypt 証明書取得 (DNS-01 challenge)

apt install certbot python3-certbot-dns-route53 (certbot 2.9.0)
certbot certonly --dns-route53 -d v2-test.thomsonsapp.com --email ichirokisanuki@gmail.com --agree-tos
取得成功、有効期限 2026-07-26、自動更新タスクもセットアップ済み
DNS-01 challenge を選んだ理由: 本番 DNS 切り替えに依存せずいつでも証明書取得・更新できる

(8) Nginx SSL 設定

80 / 443 両方で受ける構成（80 は cron からの HTTP curl 用）
listen 443 ssl http2 default_server（nginx 1.24 では旧形式 listen ... ssl http2; が必要、新形式 http2 on; は未対応）
TLSv1.2 + TLSv1.3、HIGH:!aNULL:!MD5

(9) https://v2-test.thomsonsapp.com で全 8 エンドポイント動作確認

/healthcheck, /healthcheck/db, /v1/sync, /v1/uploadRankingTsvToS3, /v1/uploadRankingScoresAndPlayersJsonData すべて 200
本番 RDS / 本番 S3 への書き込みも確認

決めたこと:（→ DECISIONS.md 参照）

v1 → v2 切り替えは v2-test.thomsonsapp.com で事前検証 → 本番ドメインは Route53 Weighted Routing で段階切り替え
証明書取得は DNS-01 challenge（certbot-dns-route53 plugin）で行う

詰まったこと / 気づき:

IAM の attached managed policy には ユーザーあたり 10 個の hard limit がある。インラインポリシーは別枠なので、上限を超えそうなら Inline で。
Ubuntu 24.04 の nginx 1.24 では http2 on; 新ディレクティブ非対応。listen ... ssl http2; の旧形式を使う
IAM ユーザーのアクセスキー発行直後は数十秒の propagation 遅延があるのが恒例。AccessDenied や InvalidAccessKeyId が出ても 30 秒待てばたいてい通る
certbot は systemd timer で自動更新タスクを勝手にセットしてくれる（Ubuntu apt 経由インストール時）

次回やること:

schulte.thomsonsapp.com 用の SSL 証明書も DNS-01 で先に取得（切り替え時の手間ゼロ）
本番 schulte.thomsonsapp.com の TTL を短縮（現在いくつかは要確認）
Route53 Weighted Routing で v2 を 10% → 50% → 100% に段階切り替え
観測 → 問題なければ完了、問題あれば即 ALB に戻す
v1 EC2 2台の停止 + 関連 Lambda (TCM_observeALB_*) の整理

17:51 - Lightsail で systemd 化 + Nginx + 専用 IAM、v2 が本番相当環境で完全動作

やったこと:

(1) systemd service 化

/etc/systemd/system/schulte-server-v2.service を作成
User=ubuntu, WorkingDirectory=~/apps/schulte-server-v2, ExecStart=uv run uvicorn ...
Restart=on-failure, RestartSec=5 で自動再起動
enable + start → active running, memory 76.8MB（軽量）

(2) Nginx インストール + リバースプロキシ

nginx 1.24.0 を apt 経由で導入
/etc/nginx/sites-available/schulte-server-v2 を作成
- listen 80 default_server
- proxy_pass http://127.0.0.1:8000 + 標準的な X-Forwarded-* ヘッダ
default サイトを無効化、新 config を enable → reload
外部から http://52.68.176.128/healthcheck で 200 確認

(3) 専用 IAM ユーザー作成（最小権限）

schulte-server-v2-s3 ユーザーを新規作成
インラインポリシー S3PutObjectRankings:
- s3:PutObject + s3:PutObjectAcl on arn:aws:s3:::schulte-thomsons/rankings/* のみ
- DELETE 不可、他バケット不可、それ以外も不可
アクセスキー発行 → Lightsail .env に追加（DB_* と並べて）
systemd の EnvironmentFile=/home/ubuntu/apps/schulte-server-v2/.env で Python プロセスに環境変数として渡す

(4) ヒヤリハット: AWS_SECRET_ACCESS_KEY が journalctl に露出

pydantic-settings v2 のデフォルトが extra='forbid' で、.env に Settings 未定義の AWS_* を書いた瞬間バリデーションエラー
エラーメッセージ input_value='...' に secret access key の生値 が含まれた
それが journalctl -u schulte-server-v2 の出力に乗り、ローカルターミナル / Claude session context に残った
対処:
- 漏洩キー AKIA4S3DSMNCJ6IVYWKR を発覚から約60秒以内に delete-access-key で無効化（実害ゼロ）
- app/config.py に extra='ignore' を明示してコミット b6fedd2
- 新キー発行 → Lightsail .env を再生成 → 今度はエラーなく起動
教訓: pydantic のエラー出力は変数値を含む。秘密情報を扱う設定では必ず extra='ignore' を明示すること

(5) 全 8 エンドポイント本番動作確認

/healthcheck, /healthcheck/db（MySQL 8.4.8）
/v1/sync 37 players / 500 scores
/v1/uploadRankingTsvToS3/4/1/0 → S3 に書き込み (810 rows / 19,637 bytes)
/v1/uploadRankingScoresAndPlayersJsonData/4/1/0 → S3 に書き込み (79 players / 500 scores / 22,465 bytes)
S3 で LastModified が更新されていることを aws s3api list-objects-v2 で確認

決めたこと:（→ DECISIONS.md 参照）

v2 用 IAM ユーザーは schulte-server-v2-s3、ポリシーは s3:PutObject + s3:PutObjectAcl on rankings/* の最小権限
pydantic-settings の Settings には必ず extra='ignore' を明示する（秘密情報露出の再発防止）

詰まったこと / 気づき:

IAM アクセスキー発行直後の propagation 遅延で InvalidAccessKeyId が出た（30秒待ったら通った）。前の AttachStaticIp の遅延と同パターン。IAM 系は数十秒見ておくのが安全
systemd の EnvironmentFile= は KEY=VALUE 形式の .env をそのまま読める。pydantic-settings の env_file と同じファイルを共用できて便利
journalctl の出力に変数値が乗ることへの認識が薄かった。Bash tool で取得する前にどんな出力か想定する習慣を持つべき

次回やること:

Lightsail ファイアウォール: 443 を開ける（80 はリダイレクト用に残す）、8000 は閉じたまま
Let's Encrypt で SSL 証明書取得（certbot + nginx プラグイン or DNS-01 challenge）
DNS の準備: 現在 schulte.thomsonsapp.com は ALB 経由。Lightsail 静的 IP に切り替える手順整備（TTL 短縮 → 切り替え → 戻し）
切り戻し手順の整備（v2 で問題が出たら ALB 経由に戻す）

17:32 - Lightsail インスタンス構築 + v2 が Lightsail 上で動作確認

やったこと:

(1) IAM 権限の準備

ichirokisanuki ユーザーに Lightsail 操作権限がなかった
インラインポリシー LightsailFullAccess (lightsail:*) を新規追加
Lightsail 専用の AWS マネージドポリシーは存在しないので、最小限のインライン定義
IAM 反映に約 30 秒かかったが、その後は問題なし

(2) Lightsail プラン・OS 選定

当初 $5 (nano dual stack) を希望したが、AWS CLI で get-bundles した結果 nano = 0.5GB RAM だと判明
v1 (461MB) で破綻していた経緯から余裕を持たせて micro_3_0 ($7/月, 1GB RAM, dual stack) を採用
OS は Ubuntu 24.04 LTS（情報量・サポート期間の長さ）
AZ は ap-northeast-1a（RDS footballnext と同 AZ、ネットワークレイテンシ最小）

(3) Lightsail インスタンス作成

名前: schulte-server-v2
静的 IP: 52.68.176.128 (allocate + attach)
VPC Peering 有効化（無料、Lightsail コンソール 1 ボタン相当の API）
Lightsail のデフォルト鍵 (LightsailDefaultKey-ap-northeast-1) をローカルに download

(4) RDS Security Group 調整

RDS footballnext の SG に inbound rule を追加: TCP 3306 from 172.26.0.0/16 (Lightsail VPC)
/16 で広めに許可（個人開発のため運用簡略優先、再起動で IP 変わっても影響なし）

(5) Lightsail インスタンス内セットアップ

uv 公式インストーラーで導入（~/.local/bin/uv）
uv python install 3.13 で Python 3.13.13 取得
gh CLI を apt 経由で導入
ssh-keygen で ed25519 鍵を生成 → 公開鍵を GitHub に登録（ユーザー手動）
- 自動登録を試みたが、ローカル gh トークンに admin:public_key スコープがなく失敗、手動登録に切り替え

(6) v2 デプロイと動作確認

git clone git@github.com:ichirokisanuki/schulte-server-v2.git ~/apps/schulte-server-v2
.env 配置（DB_HOST は VPC peering 経由で直接 RDS、ポート 3306 そのまま）
uv sync で依存インストール成功
uvicorn 起動 → /healthcheck 200, /healthcheck/db で MySQL 8.4.8 接続確認, /v1/sync?mode=4 で本番データ取得 (37 players / 500 scores)

決めたこと:（→ DECISIONS.md 参照）

Lightsail プラン: micro_3_0 (1GB RAM, dual stack, $7/月)
Lightsail OS: Ubuntu 24.04 LTS、AZ ap-northeast-1a
Lightsail ↔ RDS の接続: VPC Peering + RDS SG に 172.26.0.0/16:3306 を inbound 許可

詰まったこと / 気づき:

Lightsail の AttachStaticIp が一度 AccessDenied で失敗。原因は IAM ポリシー追加直後で propagation が遅延（30秒待ってリトライ成功）。policy simulator では allowed と判定されてた
gh ssh-key add で SSH 鍵を自動登録しようとしたが、ローカル gh のトークンに admin:public_key スコープがなく NG。gh auth refresh -s admin:public_key で追加できるが対話的なので手動登録を選択
Lightsail の最新料金: 同じ $5 でも dual stack だと 0.5GB、IPv6 only だと 1GB。モバイルアプリ用途では dual stack 必須なので $5/0.5GB or $7/1GB の二択
Lightsail インスタンスの bash heredoc は set -e 入れないと中途半端に止まることがある（ssh -T git@github.com は exit 1 で正常終了）

次回やること:

systemd service 化（uvicorn を常時稼働、再起動時に自動起動）
Nginx リバースプロキシ（80/443 → 8000）
本番用最小権限 IAM ユーザー作成（s3:PutObject on schulte-thomsons のみ）+ アクセスキー → .env に追加
Lightsail ファイアウォールで 443 を開ける、8000 は閉じたまま
DNS 切り替え + Let's Encrypt SSL（v1 → v2 切り替えのタイミングで）

17:06 - v2 にバッチ系2本実装 + S3 連携、v1 同等機能の API 全実装完了

やったこと:

(1) S3 認証方針の決定

開発時: ローカル ~/.aws/credentials の thomson-ik プロファイルを使用（aioboto3 が SDK デフォルトチェーンで自動取得）
本番時 (Lightsail): IAM Role for EC2 相当の機能がないため、別途 IAM ユーザー作成 + アクセスキー → Lightsail 内 .env に配置運用を想定（次フェーズ）

(2) v1 のバッチ実装を再確認

getRankingTsvData(mode, term): term=1 daily / 2 weekly / 3 monthly / 4 total、score 昇順 1000件
getRankingScoresAndPlayersJsonData(mode, term): 同条件で 500件、{players, scores} 形式
出力先: s3://schulte-thomsons/rankings/{daily|weekly|monthly|total}/mode{N}.{tsv|json}
ACL: public-read（クライアントが直接 S3 から取得）

(3) v2 実装

app/s3.py 新規: aioboto3 セッション + put_public_object() ヘルパー（バケット・リージョン定数化）
app/main.py に共通関数追加: _fetch_ranking_rows() _rows_to_tsv_bytes() _rows_to_json_payload()
GET /v1/uploadRankingTsvToS3/{mode}/{term}/{delay} 実装
- TSV は csv.writer(delimiter='\t') で v1 PHP fputcsv 互換（タブ・改行・クォートを含む name のエスケープを v1 と揃える）
GET /v1/uploadRankingScoresAndPlayersJsonData/{mode}/{term}/{delay} 実装
- JSON は json.dumps(separators=(',', ':'), ensure_ascii=False) で v1 PHP json_encode のスペースなし出力に合わせる
- UTF-8 直出力なので v1 の \uXXXX エスケープよりサイズが小さい
delay パラメータは await asyncio.sleep(delay) でサポート（cron が同時実行を分散させる用途）

(4) 本番 S3 で動作確認

mode=4 term=1 (daily) で TSV/JSON 両方をアップロード成功
v1 cron 直前出力 → v2 上書き → アップロード前後で LastModified が更新されたことを確認
TSV: 796 rows / 19,372 bytes
JSON: 80 players / 500 scores / 22,478 bytes
内容も日本語名・絵文字含めて正常
5 分以内に v1 cron が次の周期で上書きするので影響残らず

(5) v2 commit & push

コミット dfac086 https://github.com/ichirokisanuki/schulte-server-v2/commit/dfac086

決めたこと:（→ DECISIONS.md 参照）

開発時の S3 認証は ~/.aws/credentials の thomson-ik プロファイル経由（コードに認証情報を埋めない）

詰まったこと / 気づき:

json.dumps のデフォルトは , : でスペースを入れる。PHP json_encode 互換にするには separators=(',', ':') 必須
ただし日本語の出力サイズは v2 (UTF-8 そのまま) < v1 (\uXXXX エスケープ) で v2 の方が約 5% 小さい
csv.writer の lineterminator="\n" を明示しないと OS によって CRLF が入る可能性あり、明示しておく方が安全
aioboto3 の Session() は SDK デフォルトの認証チェーン（環境変数 → ~/.aws/credentials → IAM Role）を辿るため、コード側で profile 名を埋めなくて良い

次回やること:

v2 を Lightsail に新規構築してデプロイ動作検証
本番用の最小権限 IAM ユーザー作成（s3:PutObject on schulte-thomsons だけ）+ アクセスキー発行
ALB taki から schulte TG を外す or DNS 切り替えで v2 にトラフィックを寄せる手順設計

16:51 - v2 に残り API 3本実装 (createPlayer / updatePlayerName / downloadRankingTsv)

やったこと:

(1) v1 の3エンドポイント仕様再確認 (schulte-server/app/Controller/V1Controller.php)

createPlayer: name 受け取り → 重複チェック → 7文字 ID 生成 → INSERT
updatePlayerName: id name 受け取り → 同名の他プレイヤー除外チェック → INSERT ON DUPLICATE KEY UPDATE
downloadRankingTsv: パス引数 mode/term → TSV 1000行 + Content-Disposition

(2) v2 に実装 (app/main.py 追記)

POST /v1/createPlayer (Form: name)
- 重複時は errorCode=1
POST /v1/updatePlayerName (Form: id, name)
- 同名の他プレイヤー時は errorCode=1
- 自分自身が同名の場合は通す（v1 と同じ挙動）
GET /v1/downloadRankingTsv/{mode}/{term} (Path)
- term: 1=daily, 2=weekly, 3=monthly, 4=total
- Content-Disposition: attachment; filename="modeN_<term>.tsv"

(3) 本番 RDS で動作確認 (7ケース)

createPlayer 新規 / 別名 / 重複 → errorCode=1
updatePlayerName リネーム成功 / 他人と同名 → errorCode=1
downloadRankingTsv mode=4 term=2: 1000行 TSV
downloadRankingTsv mode=5 term=1: 1000行 TSV
DB 確認で -renamed の name 反映を確認、テスト用 player 2件削除

(4) v2 commit & push

コミット ad714bc https://github.com/ichirokisanuki/schulte-server-v2/commit/ad714bc

詰まったこと / 気づき:

v1 の Util::generateRandomId(7) は7文字ランダム ID 生成。v2 でも random.choices(ascii_letters + digits, k=7) で同じ仕様
v1 の insertOnDuplicateKeyUpdate を SQLAlchemy 2.x で再現するには mysql_insert(...).on_duplicate_key_update(...) が綺麗
TSV 出力は FastAPI の Response で media_type="application/octet-stream" + Content-Disposition ヘッダで行ける（StreamingResponse は不要、1000行程度なら一括返却で十分）
curl -I (HEAD) を GET エンドポイントに送ると 405 が返る。GET のヘッダ確認は curl -D - -o /dev/null を使うべき

次回やること:

バッチ系 2本実装: uploadRankingTsvToS3, uploadRankingScoresAndPlayersJsonData（aioboto3 で S3 連携）
S3 認証情報の準備をどうするか相談（.env に IAM アクセスキー / Lightsail 上の IAM 経由 / 直書き等）

16:41 - DB スキーマ吸い出し + v2 に DB 接続 + sendScore / sync 実装

やったこと:

(1) DB スキーマ吸い出し

1号機経由で本番 RDS (footballnext / MySQL 8.4.8) のスキーマを取得
当初ローカル mysql 9.6 + SSH トンネル経由で接続を試みたが Access denied で失敗（mysql 9 系クライアントの認証方式と RDS の組み合わせで弾かれた）
1号機内 PHP CLI から mysqli 経由で接続成功 → SHOW CREATE TABLE を全テーブル分実行 → ローカルの schulte-server-v2/schema/init.sql に保存
全10テーブル: cake_sessions / connection_test / mode4-7_scores / players / test / test_players / users
スコア合計約380万件、プレイヤー 6.3万人。AUTO_INCREMENT は mode5_scores が最大の 1,755,789

(2) v2 に DB 接続実装

依存追加: aiomysql, sqlalchemy[asyncio], greenlet, cryptography, pydantic-settings, python-multipart
Python 3.13 固定（.python-version 配置、最初は uv が 3.14 を選んでた）
app/config.py: pydantic-settings で .env 読み込み
app/db.py: SQLAlchemy 2.x async engine + sessionmaker + DI 用 get_session
app/models.py: Player, Mode4-7Score（共通 Mixin で4テーブル定義）
app/main.py: lifespan で engine.dispose、/healthcheck/db で MySQL バージョン取得確認
.env に SSH トンネル経由 RDS 接続用の値を設定（gitignore 済み）
.env.example をサンプル値で配置

(3) /v1/sendScore 実装

INSERT IGNORE で unique_key 重複検知
重複時は既存 playerId を返す
playerId 空のときは7文字ランダム生成 + players に INSERT
del カラムは Python 予約語回避のため del_ でマップ
異常系（score=0 / unique_key=""）は isSuccessed: false で即返却

(4) /v1/sync 実装

直近1週間 (timestamp >= now - 1week) かつ del=0 のスコアを取得
スコア昇順 (速い順) で 500 件
Player JOIN で名前取得
isSmart=true で軽量化形式（players は dict、scores は配列の配列）

(5) 本番 RDS で動作確認

/v1/sync?mode=4: 37 players / 500 scores 取得成功（実プレイヤー名・絵文字含む日本語も正常）
/v1/sendScore 4ケース成功:
- 新規 playerId=9HAqPDI 生成
- 同じ unique_key 再送 → 既存 playerId 返却（重複検知）
- 別 unique_key + 既存 playerId で2件目スコア記録
- 異常系（score=0, unique_key 空）は拒否
テストレコード（unique_key LIKE 'v2-test-%'）は1号機経由 PHP で削除済み、本番 DB は元通り

(6) v2 commit & push

コミット 3480683 https://github.com/ichirokisanuki/schulte-server-v2/commit/3480683

詰まったこと / 気づき:

ローカル mysql 9.6 クライアントから RDS 接続が Access denied で失敗。原因は MySQL 9 系クライアントの認証プラグイン挙動。aiomysql (PyMySQL ベース) は問題なく接続できたので開発に支障なし
PHP 5.3 は [] 短い配列構文や func()[0] の即時参照が NG（5.4+）。1号機内 PHP スクリプトは array() と一旦変数代入で書く必要がある
uv init --python 3.13 してもローカル Python 3.14 が使われた（requires-python = ">=3.13" だと 3.14 もマッチ）。.python-version で固定するのが確実
sendScore のテストは「本番 RDS に v2-test- prefix の unique_key で送り、後で削除」運用を採用。今後の動作確認でも踏襲

次回やること:

残り API 3本実装: createPlayer, updatePlayerName, downloadRankingTsv（DB 操作のみ）
バッチ系2本実装: uploadRankingTsvToS3, uploadRankingScoresAndPlayersJsonData（aioboto3 で S3 連携、認証情報の準備が要る）

15:50 - Lightsail 移行検証 → schulte-server-v2 への方針転換 + 最小スケルトン作成

やったこと:

(1) Lightsail 1台移行に耐えられるかの事前検証

ALB taki が schulte 含む5アプリ共有と判明（baseballnext / footballnext / machiga / schulte / sposhin）
schulte EC2 2台 (t3.nano) のメトリクス取得: CPU 平均 0.85% / 最大 3.6%、月転送量約 8GB → 性能的には Lightsail 1台で完全に耐えうると判定
ALB schulte TG リクエスト数: ピーク 0.33 RPS（2台合計）、5XX エラーは7日間ゼロ
RDS footballnext: ピーク CPU 56%、Freeable Memory 最低 54MB（他アプリ込み、要注意）

(2) EC2 詳細調査（深刻なレガシー発覚）

OS: Amazon Linux 1 (2018.03)、AWS サポートは 2023-12 で終了済み
PHP 5.3.29 (2014年 EOL)、Apache 2.2.34、CakePHP 2.0.4（2011年）
メモリ余裕無しの原因 = mod_php5 prefork で httpd 各 child 約45MB × 9 = 392MB / 461MB を占有
swap 84MB 使用中、CodeDeploy/CloudWatch Agent 等の常駐サービスが追加で約 130MB

(3) PHP-FPM 化（メモリ改善策）の検討と中断

Apache 2.2 には mod_proxy_fcgi が無いため、選択肢: α (mod_fcgid + php-cgi) or γ (httpd24 + mod_proxy_fcgi + php-fpm)
検証用に2号機を ALB から detach
AppName タグを Schulte → Schulte_maintenance に変更し Lambda 自動 attach を回避（後述）
後段の方針転換でこの作業は中断

(4) Lambda 監視機構の発見

TCM_observeALB_startEC2 / attachToTargetGroup / detachEC2FromTargetGroup の3つが per1min で動作
ALB から単純に detach すると、最大1分以内に attach Lambda が再 attach する仕組み
回避策として AppName タグ書き換えで Lambda の対象から外す方法を採用（v2 路線への切替時にも有効）

(5) 大方針転換: schulte-server-v2 構想

レガシー（PHP 5.3 / CakePHP 2.0.4）継承を断念し、Python / FastAPI でゼロから書き直す方針
schulte-server の API 規模感把握: 実 API 8個（sendScore, createPlayer, updatePlayerName, sync, downloadRankingTsv, uploadRankingTsvToS3, uploadRankingScoresAndPlayersJsonData, healthcheck）
認証なし、外部連携 = S3 のみ（バケット schulte-thomsons、public-read）
ランキングは S3 に TSV 公開、クライアントは S3 から直接取得 → 低 EC2 負荷の理由
cron は別サーバー（cron EC2 インスタンス）から HTTP で 20 ジョブ叩く構成（cron.txt 確認）
DB スキーマは CakePHP Schema には無く、実 RDS から SHOW CREATE TABLE で取得が必要

(6) schulte-server-v2 リポジトリ作成

ローカル: ~/cdev/schulte-operation/schulte-server-v2/
GitHub: ichirokisanuki/schulte-server-v2 (private)
スタック: Python 3.13 + FastAPI + uv + uvicorn + aiomysql + SQLAlchemy 2.x (async) + aioboto3 + Pydantic v2
最小スケルトン (/healthcheck, /docs) ローカル動作確認済み (HTTP 200)
初回コミット e9d63d8 push 済み
operation 側の .gitignore に /schulte-server-v2/ 追加

(7) 2号機停止

AppName タグは Schulte_maintenance のまま、EC2 stop 実行
Lambda 監視対象外なので自動再起動されない、本番は1号機のみで継続稼働中

決めたこと:（→ DECISIONS.md 参照）

Python / FastAPI で v2 を書き直す
v2 は operation 直下に物理配置、別 GitHub リポジトリ管理
v2 の開発メモは operation/.devnotes/ に集約（v2 側には .devnotes/ を置かない）
PHP-FPM 化検証は中止

詰まったこと / 気づき:

ALB taki が共有 ALB だった。v2 移行時には他4アプリへの影響を考慮した経路変更が必要
Lambda 自動 attach/start/detach 機構が存在し、運用変更時には AppName タグで監視対象から外す必要
メモリ問題の本質は OS/PHP/Apache のレガシー構成。v2 で全部刷新すれば自然に解消する

次回やること:

DB スキーマを実 RDS (footballnext.ckdbljv81o1g.ap-northeast-1.rds.amazonaws.com) から SHOW CREATE TABLE players, mode4_scores, ... で吸い出す
v2 に DB 接続 (aiomysql + SQLAlchemy async) 実装
v2 に sendScore sync を実装

13:11 - プロジェクト初期セットアップ（概要記入＋直近ロードマップ）

やったこと:

リポジトリ直下に物理配置する schulte-server/ schulte-unity/ を .gitignore に追加（先頭スラッシュ付きでルート直下のみ対象）
CLAUDE.md の「プロジェクト概要」「開発メモ」を埋めた
- アプリ概要（iOS/Android リリース済み、App Store / Google Play リンク）
- 構成（Unity クライアント + PHP バックエンド、EC2 nano × 2台 + LB、RDS は footballnext インスタンスに間借り）
- schulte-server / schulte-unity は別管理である旨
.devnotes/ROADMAP.md の「今月」に直近やりたいこと3点を追記
- インフラ縮小（EC2 nano × 2台 → Lightsail 1台）
- schulte-server を CodeCommit → github.com に移行
- schulte-unity を CodeCommit → github.com に移行（重そうなので要検討）
ユーザーレベルメモリーに project_overview.md と roadmap_2026q2.md を保存し、MEMORY.md インデックスを作成

決めたこと:

schulte-operation は「運用リポジトリ」と位置付け、実装ソース（schulte-server / schulte-unity）は同居させず別リポジトリで管理する（→ DECISIONS.md 参照）

次回やること:

ロードマップ3項目のうち、どれから着手するか方針決め
schulte-server の GitHub 移行に着手する場合、まず CodeCommit 側のリポジトリサイズと現状ブランチ構成の確認

schulte-operation

WIP（現在進行中）

Work In Progress

現在の状況

過去のWIPアーカイブ

2026-04-27 19:43 時点のスナップショット

2026-04-27 19:33 時点のスナップショット

2026-04-27 18:51 時点のスナップショット

2026-04-27 18:07 時点のスナップショット

2026-04-27 17:51 時点のスナップショット

2026-04-27 17:32 時点のスナップショット

2026-04-27 17:06 時点のスナップショット

2026-04-27 16:51 時点のスナップショット

2026-04-27 16:41 時点のスナップショット

2026-04-27 15:50 時点のスナップショット

2026-04-27 13:11 時点のスナップショット

ROADMAP（計画）

ロードマップ

今週

今月

今四半期

いつか

DECISIONS（意思決定）

意思決定記録

2026-04-28: 本番 RDS は PubliclyAccessible=false に統一（コスト削減 + セキュリティ）

2026-04-28: ALB 用 EIP (amazon-elb RequesterManaged) は触らない方針

2026-04-28: v2 のリソース増強 (swap 1GB + uvicorn workers=2)

2026-04-28: phpmyadmin 接続は SSH トンネル方式に切り替える（本番 RDS Public 戻しはしない）

2026-04-27: 監視サービスの死活監視 URL は v2 標準の /healthcheck に統一

2026-04-27: 切り戻し用に ALB Alias レコードを Weight 0 で残置する

2026-04-27: v1 → v2 切り替えはサブドメイン事前検証 + Weighted Routing で段階切り替え

2026-04-27: SSL 証明書は Let's Encrypt + DNS-01 challenge (certbot-dns-route53)

2026-04-27: v2 用 IAM ユーザーは最小権限 (s3:PutObject + PutObjectAcl on rankings/* のみ)

2026-04-27: pydantic-settings の Settings には必ず extra='ignore' を明示する

2026-04-27: Lightsail プランは micro_3_0 ($7/月, 1GB RAM, dual stack)

2026-04-27: Lightsail OS は Ubuntu 24.04 LTS、AZ は ap-northeast-1a

2026-04-27: Lightsail ↔ RDS の接続は VPC Peering + RDS SG に Lightsail CIDR /16 許可

2026-04-27: 開発時の S3 認証は AWS CLI プロファイル thomson-ik 経由

2026-04-27: schulte-server-v2 として Python / FastAPI で書き直す（v1 のレガシー継承を断念）

2026-04-27: schulte-server-v2 リポジトリは operation 直下に物理配置、別 GitHub 管理

2026-04-27: schulte-server-v2 の開発メモは operation 側 .devnotes/ に集約

2026-04-27: v1 の PHP-FPM 化（メモリ問題改善）は実施しない

2026-04-27: schulte-operation を「運用リポジトリ」と位置付け、実装ソースは同居させない

DEVLOG（作業ログ）

開発日誌

2026-04-28

12:25 - 撤退完了 + v2 リソース増強 + RDS Private 化で月$24削減 + phpmyadmin 引き継ぎ書

2026-04-27

19:43 - 撤退作業の最初の一歩: 1号機停止 + 12h タイマー

19:33 - 🎯 本番 DNS 切り替え完了 (10% → 50% → 100%)、v2 が完全稼働

18:51 - 本番ドメイン切り替え準備完了（証明書、Nginx、切り戻し情報）

18:07 - HTTPS 化完了、v2 が https://v2-test.thomsonsapp.com で全エンドポイント動作

17:51 - Lightsail で systemd 化 + Nginx + 専用 IAM、v2 が本番相当環境で完全動作

17:32 - Lightsail インスタンス構築 + v2 が Lightsail 上で動作確認

17:06 - v2 にバッチ系2本実装 + S3 連携、v1 同等機能の API 全実装完了

16:51 - v2 に残り API 3本実装 (createPlayer / updatePlayerName / downloadRankingTsv)

16:41 - DB スキーマ吸い出し + v2 に DB 接続 + sendScore / sync 実装

15:50 - Lightsail 移行検証 → schulte-server-v2 への方針転換 + 最小スケルトン作成

13:11 - プロジェクト初期セットアップ（概要記入＋直近ロードマップ）

最近のコミット

README

schulte-operation

概要

セットアップ

使い方

2026-04-28: ALB 用 EIP (`amazon-elb` RequesterManaged) は触らない方針

2026-04-27: 監視サービスの死活監視 URL は v2 標準の `/healthcheck` に統一

2026-04-27: pydantic-settings の Settings には必ず `extra='ignore'` を明示する

2026-04-27: 開発時の S3 認証は AWS CLI プロファイル `thomson-ik` 経由

18:07 - HTTPS 化完了、v2 が `https://v2-test.thomsonsapp.com` で全エンドポイント動作