はじめに
記録時点: 2024-10〜2025-02
この時期は、画面機能の拡張より先にバックエンドの足場を作り直していました。 理由は、APIを増やすたびに「同じ変更なのに直し方が毎回違う」状態が悪化していたためです。 このまま機能追加を続けると、年末以降の移行と改善が確実に詰まると判断しました。
どこで詰まり始めていたか
当時の詰まりは、性能問題より運用の一貫性不足でした。
- 画面Aは同じ認証失敗を
再ログインとして扱うのに、画面Bは汎用エラーとして止まる - API追加時に監視設定の粒度が揃わず、障害時に「どこから壊れたか」がすぐ追えない
- キャッシュ設定を含む公開経路の確認を後ろ倒しにして、動作確認の前提が環境ごとにズレる
「単体では動く」が積み上がって、全体では読みにくい状態になっていました。
最初に手を入れたのは API の作り方
先にやったのは個別APIの改善ではなく、追加時の作法を固定することでした。
揃えたポイント
- 認証の前提
- 失敗時レスポンスの形式
- ログ出力の粒度
- 監視の基本設定
ここを揃えたことで、APIを1本増やすたびに「どこを確認するか」が明確になりました。 逆に言うと、ここが揃う前はレビューの観点が人依存でした。
ドメイン接続を後回しにしなかった理由
もともとは、公開経路の整備を終盤に持っていく予定でした。 ただ途中で方針を変えています。
理由は、本番相当の経路で確認して初めて見える差分が予想以上に多かったからです。 特に、次の2つはローカルでは見えにくい領域でした。
- キャッシュが効く/効かない条件の差
- ヘッダー制御の意図しない不一致
終盤でまとめて当たると、API本体の不具合なのか配信経路の問題なのか、切り分けに時間を取られます。 公開直前の混線を避けるため、接続は早めに済ませました。
重い処理は同期経路から外した
もう1つ効いたのは、重い処理を通常APIと分離したことです。
編集操作と同じ経路に時間の読みにくい処理を置くと、利用者には「時々重い」「時々保存が遅い」と見えます。 この症状は問い合わせで再現しにくく、原因追跡に時間を使いがちです。
そこで、編集時に即時応答が必要な経路と、時間をかけてよい経路を分離しました。 この分離後は、重い処理側で揺れが出ても編集操作まで巻き込みにくくなっています。
採用しなかった案
この時期に検討したが見送った案もあります。
1. 初期段階での過度な共通化
抽象化を強くすると一見きれいですが、要件変更に追従しづらくなります。 初期は「揃えるべき最小限」に絞りました。
2. ドメイン接続をリリース直前にまとめる
作業量は減りますが、検証の同時多発で事故率が上がると判断して見送りました。
3. 重い処理をそのまま同期で最適化する
最適化だけで押し切る案もありましたが、失敗時の影響分離ができないため採用していません。
この時期に残した運用ルール
基盤整備は実装だけでは安定しません。 運用で次を固定しました。
- API追加時のレビュー観点を固定する
- 失敗時の挙動を画面ごとに変えない
- 公開経路の確認を機能開発と同時に回す
まとめ
2024年後半は、機能を増やすより先に「増やしても崩れない形」を作った期間でした。 CDKで作法を揃え、公開経路を早期に接続し、重い処理を分離したことで、その後の実装速度と障害対応の両方が安定しました。