Portfolioこのトピックについて
システムは作って終わりではなく、運用し続けることが大切です。このプロジェクトでは、導入から運用まで手間がかからない設計を心がけました。
クラウドへの自動デプロイ
ソースコードをアップロードするだけで、自動的にクラウド環境に展開されます。
デプロイの流れ
コードをプッシュ
開発者がGitリポジトリにコードを送信
自動検知
クラウドプラットフォームが変更を検知
ビルド
依存関係のインストール、コンパイル
デプロイ
新バージョンをロールアウト
ヘルスチェック
正常動作を確認して完了
自動デプロイのメリット
| メリット | 説明 |
|---|---|
| サーバー調達不要 | 物理サーバーやVPSの準備が不要 |
| 設定の手間削減 | OSやミドルウェアの設定が不要 |
| 即座に反映 | コードプッシュから数分で本番反映 |
| ロールバック可能 | 問題があれば前バージョンに戻せる |
サーバー調達不要
説明物理サーバーやVPSの準備が不要
設定の手間削減
説明OSやミドルウェアの設定が不要
即座に反映
説明コードプッシュから数分で本番反映
ロールバック可能
説明問題があれば前バージョンに戻せる
自動スケーリング
利用が増えても、クラウド側で自動的にリソースを調整します。
スケーリングの仕組み
閑散時
最小構成でコスト削減。1インスタンスで処理
アクセス増加
通常時
2〜3インスタンスで並列処理
月末繁忙期
繁忙時
自動的にスケールアウト。リクエストを分散処理
スケーリングのポイント
| 状況 | インスタンス数 | 対応 |
|---|---|---|
| 夜間・休日 | 最小（0〜1） | コスト最小化 |
| 通常営業時間 | 2〜3 | 安定したレスポンス |
| 月末集計 | 自動増加 | 処理待ちを防止 |
夜間・休日
インスタンス数最小（0〜1）
対応コスト最小化
通常営業時間
インスタンス数2〜3
対応安定したレスポンス
月末集計
インスタンス数自動増加
対応処理待ちを防止
サーバーレス構成のため、使った分だけ課金されます。アクセスがない時間帯は課金が発生しないため、コスト効率が良いです。
環境変数による設定管理
設定は環境変数で管理します。コードを変更せずに、動作を調整できます。
必須設定
| 変数名 | 説明 | 例 |
|---|---|---|
| RUN_TOKEN | 認証用の秘密トークン | 32文字以上の文字列 |
| FREEE_CLIENT_ID | 請求書サービスのクライアントID | APIから発行されるID |
| FREEE_CLIENT_SECRET | 請求書サービスのクライアントシークレット | APIから発行される秘密鍵 |
| FREEE_REFRESH_TOKEN | トークン更新用のリフレッシュトークン | APIから発行されるトークン |
RUN_TOKEN
説明認証用の秘密トークン
例32文字以上の文字列
FREEE_CLIENT_ID
説明請求書サービスのクライアントID
例APIから発行されるID
FREEE_CLIENT_SECRET
説明請求書サービスのクライアントシークレット
例APIから発行される秘密鍵
FREEE_REFRESH_TOKEN
説明トークン更新用のリフレッシュトークン
例APIから発行されるトークン
オプション設定（デフォルト値あり）
| 変数名 | 説明 | デフォルト |
|---|---|---|
| RATE_LIMIT_PER_MINUTE | 1分あたりのリクエスト上限 | 60 |
| CONCURRENT_FREEE_CALLS | 同時API呼び出し数 | 2 |
| RETRY_MAX_ATTEMPTS | リトライ最大回数 | 5 |
| REQUEST_TIMEOUT_MS | タイムアウト（ミリ秒） | 30000 |
RATE_LIMIT_PER_MINUTE
説明1分あたりのリクエスト上限
デフォルト60
CONCURRENT_FREEE_CALLS
説明同時API呼び出し数
デフォルト2
RETRY_MAX_ATTEMPTS
説明リトライ最大回数
デフォルト5
REQUEST_TIMEOUT_MS
説明タイムアウト（ミリ秒）
デフォルト30000
テスト用設定
| 変数名 | 説明 | 用途 |
|---|---|---|
| FREEE_DRY_RUN | ドライランモード（true/false） | 本番送信せずにテスト |
| ENABLE_STRUCTURED_LOGGING | 詳細ログ出力（true/false） | デバッグ時に有効化 |
FREEE_DRY_RUN
説明ドライランモード（true/false）
用途本番送信せずにテスト
ENABLE_STRUCTURED_LOGGING
説明詳細ログ出力（true/false）
用途デバッグ時に有効化
タイムアウト設定
長時間処理への対応として、適切なタイムアウトを設定しています。
タイムアウトの制御
リクエスト開始
処理を開始、タイマーをセット
処理実行
API呼び出しなどを実行
タイムアウト判定
設定時間を超過したか
時間内
正常に結果を返却
超過
処理を中断、エラーを返却
タイムアウト設定の目安
| 処理 | 推奨設定 | 理由 |
|---|---|---|
| 単一API呼び出し | 30秒 | 通常は数秒で完了 |
| バッチ処理（〜100件） | 2分 | ページングを考慮 |
| 大規模処理（〜500件） | 5分 | クラウドの上限まで活用 |
単一API呼び出し
推奨設定30秒
理由通常は数秒で完了
バッチ処理（〜100件）
推奨設定2分
理由ページングを考慮
大規模処理（〜500件）
推奨設定5分
理由クラウドの上限まで活用
分散キャッシュの活用
Redis（Upstash）を使った分散キャッシュにより、以下を実現しています。
| 機能 | 説明 | メリット |
|---|---|---|
| べき等性キャッシュ | 処理済みキーを7日間保持 | 複数インスタンス間で共有 |
| トークンキャッシュ | アクセストークンを有効期限まで保持 | API呼び出しを削減 |
| 分散ロック | 同時更新を防止 | データ整合性を確保 |
べき等性キャッシュ
説明処理済みキーを7日間保持
メリット複数インスタンス間で共有
トークンキャッシュ
説明アクセストークンを有効期限まで保持
メリットAPI呼び出しを削減
分散ロック
説明同時更新を防止
メリットデータ整合性を確保
分散キャッシュは任意ですが、推奨です。設定されていない場合はメモリキャッシュのみで動作しますが、インスタンス間でキャッシュが共有されないため、重複処理のリスクがあります。
運用時のチェックリスト
デプロイ前
- [ ] 必須の環境変数がすべて設定されているか
- [ ] ドライランモードで動作確認済みか
- [ ] トークンの有効期限は十分か
運用中
- [ ] エラーログを定期的に確認
- [ ] レート制限に達していないか
- [ ] レスポンス時間が正常か
トラブル時
- [ ] 構造化ログで問題箇所を特定
- [ ] 必要に応じてドライランモードに切り替え
- [ ] 設定変更後は1件だけテスト
この設計で実現できること
運営側にとって
- 導入コストの最小化: サーバー不要、設定最小限
- 運用負荷の軽減: 自動スケーリング、自動デプロイ
- 柔軟な調整: 環境変数で動作をカスタマイズ
現場担当者にとって
- 安定したサービス: 月末でも遅延なし
- すぐに使える: 複雑なセットアップ不要
- 問題対応が容易: ログとヘルスチェックで状況把握