Portfolioこのトピックについて
システムは作って終わりではなく、運用し続けることが大切です。このプロジェクトでは、導入から運用まで手間がかからない設計を心がけました。
クラウドへの自動デプロイ
ソースコードをアップロードするだけで、自動的にクラウド環境に展開されます。
デプロイの流れ
コードをプッシュ
開発者がGitリポジトリにコードを送信
自動検知
クラウドプラットフォームが変更を検知
ビルド
依存関係のインストール、コンパイル
デプロイ
新バージョンをロールアウト
ヘルスチェック
正常動作を確認して完了
自動デプロイのメリット
自動スケーリング
利用が増えても、クラウド側で自動的にリソースを調整します。
スケーリングの仕組み
閑散時
最小構成でコスト削減。1インスタンスで処理
アクセス増加
通常時
2〜3インスタンスで並列処理
月末繁忙期
繁忙時
自動的にスケールアウト。リクエストを分散処理
スケーリングのポイント
サーバーレス構成のため、使った分だけ課金されます。アクセスがない時間帯は課金が発生しないため、コスト効率が良いです。
環境変数による設定管理
設定は環境変数で管理します。コードを変更せずに、動作を調整できます。
必須設定
オプション設定（デフォルト値あり）
テスト用設定
タイムアウト設定
長時間処理への対応として、適切なタイムアウトを設定しています。
タイムアウトの制御
リクエスト開始
処理を開始、タイマーをセット
処理実行
API呼び出しなどを実行
タイムアウト判定
設定時間を超過したか
時間内
正常に結果を返却
超過
処理を中断、エラーを返却
タイムアウト設定の目安
分散キャッシュの活用
Redis（Upstash）を使った分散キャッシュにより、以下を実現しています。
分散キャッシュは任意ですが、推奨です。設定されていない場合はメモリキャッシュのみで動作しますが、インスタンス間でキャッシュが共有されないため、重複処理のリスクがあります。
運用時のチェックリスト
デプロイ前
- [ ] 必須の環境変数がすべて設定されているか
- [ ] ドライランモードで動作確認済みか
- [ ] トークンの有効期限は十分か
運用中
- [ ] エラーログを定期的に確認
- [ ] レート制限に達していないか
- [ ] レスポンス時間が正常か
トラブル時
- [ ] 構造化ログで問題箇所を特定
- [ ] 必要に応じてドライランモードに切り替え
- [ ] 設定変更後は1件だけテスト
この設計で実現できること
運営側にとって
- 導入コストの最小化: サーバー不要、設定最小限
- 運用負荷の軽減: 自動スケーリング、自動デプロイ
- 柔軟な調整: 環境変数で動作をカスタマイズ
現場担当者にとって
- 安定したサービス: 月末でも遅延なし
- すぐに使える: 複雑なセットアップ不要
- 問題対応が容易: ログとヘルスチェックで状況把握