第14章：キーの寿命（TTL）とお掃除（データ肥大化対策）🧹⏳
この章のゴール🎯
- 冪等キー（Idempotency Key）を どれくらいの期間だけ有効にするか（TTL） を、根拠つきで決められるようになる😊
- 保存データが増えすぎて DBが重くなる事故 を防げるようになる💥
- 安全なお掃除（削除・間引き・アーカイブ） のやり方を身につける🧼✨
1) TTLってなに？🕰️
TTL（Time To Live）は、ざっくり言うと
- 「この冪等キーは、この期限までは同じ結果として扱う」
- 「期限を過ぎたら、古い冪等キーとして扱わない（またはエラー）」
という“寿命”のことだよ🔑⏳
TTLがないと起こること😇
冪等キーを保存し続けると…
- テーブルが 肥大化（容量＆インデックスも増える）📈
- 検索・挿入・削除が じわじわ遅くなる🐢
- バックアップが重い、復旧が遅い、運用コストが増える💸
- レスポンスを保存している場合は、個人情報や機密の保持期間 が長くなりがち⚠️
なので、TTLとお掃除は「冪等キー方式の必須パーツ」だよ🧩✨
2) TTLを決める “実務のものさし” 📏✨
TTLは「なんとなく」で決めると、だいたい事故る😵💫 だから、次の順で決めるのが安定だよ✅
2-1. まずは “リトライが起きうる時間” を想像する📶
- ユーザーの連打（秒〜数十秒）👆👆👆
- ネットワーク不安定（数十秒〜数分）🌧️
- クライアントの自動リトライ（数分〜数時間）🔁
- モバイルで一旦圏外→復帰（数分〜数時間）📱
2-2. 次に “ビジネス的に危険な重複期間” を考える💳🛒
- 決済・課金：短くても必ず守りたい（二重課金は地獄）🔥
- 注文作成：同じ注文が翌日に再送されても困る？どう困る？🤔
- 予約：二重予約は取り返しがつかないことが多い📅💥
2-3. 最後に “運用・コスト・データ保持” を合わせる🧾
- レスポンスを保存するなら、保持期間が長いほどリスク＆容量が増える⚠️
- 監査ログや問い合わせ対応の都合で、最低限の情報だけ長めに残したいこともある📌
3) よくあるTTLの目安（業界の例つき）🧠✨
「絶対こう！」はないけど、実例を“物差し”にすると決めやすいよ😊
- 24時間：決済系でよく見る“短め基準” Stripe では、冪等キーを 少なくとも24時間 で扱う前提があり、古いキーは自動的に取り除ける（prune）考え方が示されてるよ。(Stripe Docs)
- 7日：もう少し長めに守りたい基準 Adyen では、冪等キーが 最低7日間有効 と明記されてるよ。(Adyen Docs)
- “サーバーが保存している間だけ有効”：API提供側は有効期間を明示してね、という考え方 Idempotency-Key のIETFドラフトでも、サーバー側が 有効期限ポリシーを定めてドキュメント化すべき とされてるよ。(IETF Datatracker)
つまり「24時間〜7日」あたりが“現実的な範囲”になりやすい、ってことだね🔁✨
4) TTLを短くしすぎる vs 長くしすぎる😇💥
短すぎ事故（例：TTL 10分）⏱️💣
- ちょっとした障害でリトライが遅れただけで、同じキーが“新規扱い”になって二重実行😱
- 問い合わせ対応で「昨日の再送なのに別注文になった…」みたいな混乱が起きる🌀
長すぎ事故（例：TTL 180日）📦💥
- テーブルが太り続けて、インデックスが肥大化＆性能劣化🐢
- レスポンス保存してると、個人情報の保持が長くなって怖い😵
- 「同じキーをうっかり再利用」した時の影響が長期間残る（思わぬ衝突）⚠️
5) 超おすすめ：保存を “2段階” にする設計🧽🧺
現場でめちゃくちゃ効く考え方👇
ステップA：短期（例：24時間）📮✅
- 同じキーなら同じレスポンスを返す（結果再利用）
- ここが一番“便利で強い”💪
ステップB：中期（例：7日）🧾🔒
- レスポンス本文は捨てる（容量＆機密リスクを下げる）
- でも “このキーは使われた” という最小情報（注文ID/状態など）は残して、二重実行だけは防ぐ
この方式だと、
- 便利さ（短期）と
- 安全＆コスト（中期） を両取りしやすいよ✨
6) DB設計（最小構成）🗃️✨
冪等キー保存テーブル例（教材用の形）👇
Id（PK）IdempotencyKey（ユニーク）🔑CreatedAtUtc（作成時刻）🕰️ExpiresAtUtc（キーの有効期限＝TTL終わり）⏳Status（InProgress / Succeeded / Failed など）🚦ResponseStatusCode（任意）ResponseBodyJson（任意：短期だけ保存したいとき）📦RequestHash（同じキーで別内容を投げた時に弾く用）🧷
インデックスの超重要ポイント📌
IdempotencyKeyは UNIQUE（重複登録をDBで止める）🛡️ExpiresAtUtcに INDEX（期限切れ掃除が速くなる）🚀
7) C#実装：期限切れをお掃除する🧹（定期バッチ）
ここでは「期限切れレコードを定期的に消す」一番わかりやすい形にするよ😊
7-1. EF Core エンティティ例🧩
public enum IdempotencyStatus
{
InProgress = 0,
Succeeded = 1,
Failed = 2
}
public sealed class IdempotencyRecord
{
public long Id { get; set; }
public string IdempotencyKey { get; set; } = default!;
public DateTimeOffset CreatedAtUtc { get; set; }
public DateTimeOffset ExpiresAtUtc { get; set; }
public IdempotencyStatus Status { get; set; }
public int? ResponseStatusCode { get; set; }
public string? ResponseBodyJson { get; set; }
// 同じキーで別payloadを投げたら弾くための指紋
public string RequestHash { get; set; } = default!;
}
7-2. DbContext 設定（ユニーク制約＆インデックス）🛡️
using Microsoft.EntityFrameworkCore;
public sealed class AppDbContext : DbContext
{
public DbSet<IdempotencyRecord> IdempotencyRecords => Set<IdempotencyRecord>();
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
var e = modelBuilder.Entity<IdempotencyRecord>();
e.HasIndex(x => x.IdempotencyKey).IsUnique();
e.HasIndex(x => x.ExpiresAtUtc);
e.Property(x => x.IdempotencyKey).HasMaxLength(255);
e.Property(x => x.RequestHash).HasMaxLength(128);
}
}
7-3. お掃除サービス（BackgroundService）🧹✨
ポイントは ExecuteDeleteAsync を使って、1件ずつ読み込まずに“まとめて削除”すること！（速い＆軽い） EF Core では ExecuteDelete/ExecuteDeleteAsync が公式に案内されてるよ。(Microsoft Learn)
using Microsoft.EntityFrameworkCore;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
public sealed class IdempotencyCleanupService : BackgroundService
{
private readonly IServiceScopeFactory _scopeFactory;
private readonly ILogger<IdempotencyCleanupService> _logger;
// 例：1時間ごとに掃除
private static readonly TimeSpan Interval = TimeSpan.FromHours(1);
public IdempotencyCleanupService(IServiceScopeFactory scopeFactory, ILogger<IdempotencyCleanupService> logger)
{
_scopeFactory = scopeFactory;
_logger = logger;
}
protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
using var timer = new PeriodicTimer(Interval);
while (await timer.WaitForNextTickAsync(stoppingToken))
{
try
{
await CleanupAsync(stoppingToken);
}
catch (OperationCanceledException) when (stoppingToken.IsCancellationRequested)
{
// 終了時は静かに抜ける
}
catch (Exception ex)
{
_logger.LogError(ex, "Idempotency cleanup failed 😵");
}
}
}
private async Task CleanupAsync(CancellationToken ct)
{
var now = DateTimeOffset.UtcNow;
using var scope = _scopeFactory.CreateScope();
var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();
var deleted = await db.IdempotencyRecords
.Where(x => x.ExpiresAtUtc <= now)
.ExecuteDeleteAsync(ct);
if (deleted > 0)
{
_logger.LogInformation("Idempotency cleanup 🧹 deleted={Deleted} at={Now}", deleted, now);
}
}
}
7-4. 登録（DI）📌
builder.Services.AddHostedService<IdempotencyCleanupService>();
8) “2段階掃除” をやるなら（ちょい実務っぽい）🧽🧺
- まず 本文（ResponseBodyJson）だけ先に捨てる（短期）
- その後で レコード自体を削除（中期）
例：
- 本文保持：24時間
- キー保持：7日
private static readonly TimeSpan BodyRetention = TimeSpan.FromHours(24);
private static readonly TimeSpan KeyRetention = TimeSpan.FromDays(7);
private async Task CleanupTwoPhaseAsync(AppDbContext db, CancellationToken ct)
{
var now = DateTimeOffset.UtcNow;
// ①本文を捨てる（容量＆機密対策）
var pruneBefore = now - BodyRetention;
await db.IdempotencyRecords
.Where(x => x.CreatedAtUtc <= pruneBefore && x.ResponseBodyJson != null)
.ExecuteUpdateAsync(s => s.SetProperty(x => x.ResponseBodyJson, (string?)null), ct);
// ②キーの寿命を過ぎたら削除
var deleteBefore = now - KeyRetention;
await db.IdempotencyRecords
.Where(x => x.CreatedAtUtc <= deleteBefore)
.ExecuteDeleteAsync(ct);
}
この“二段階”は、 Stripe（24時間）と Adyen（7日）みたいな「短期と中期の基準差」を、うまく設計に落とし込みやすいよ🧠✨(Stripe Docs)
9) テスト観点🧪✅（地味だけど超大事）
- TTL内：同じキーは 同じ結果（または処理中）を返す🔁
- TTL外：ポリシー通りに動く（例：キー期限切れエラー、または新規扱い）⏳
- 掃除後：DBが肥大化しない（期限切れが消える）🧹
- 監視：掃除が止まったら気づける（ログ/メトリクス）🚨
10) ミニ演習📝🌸
演習1：TTLを決めよう（根拠つき）🧠
題材：注文作成API（POST /orders）🛒 次の3つを埋めてみてね👇
- TTL：◯時間 / ◯日
- 理由（リトライ・ビジネス・運用の観点で各1行）
- “TTL外のキー再送” が来た時の方針（エラーにする？新規扱い？）
演習2：掃除の頻度を決めよう⏱️
- 1分ごと / 1時間ごと / 1日1回 どれにする？ 「削除対象が多い時」「少ない時」も想像して理由を書こう✍️
11) 小テスト🎓✨（答えつき）
Q1. TTLを決めるとき、一番最初に考えるべきは？
A. DBの空き容量 B. クライアントが再送しうる時間（リトライ窓） C. 開発者の好み
✅答え：B（まずは“再送が起きる現実”に合わせるのが基本だよ📶）
Q2. TTLを長くしすぎると起こりやすい問題は？（複数選択）
A. DBが肥大化して遅くなる B. 個人情報の保持が長くなりがち C. 冪等性が強くなりすぎて安全になるだけ
✅答え：A と B（Cは“安全だけ”じゃ済まないのが落とし穴😵）
Q3. “有効期限ポリシーをドキュメント化すべき” という考え方は？
✅答え：サーバー側が有効期限を定めて公開するのが望ましい、という方向性（IETFドラフト）だよ📌(IETF Datatracker)
12) AI活用🤖✨（Copilot/Codex向けプロンプト例）
- 「IdempotencyRecord に TTL（ExpiresAtUtc）を持たせて、期限切れを ExecuteDeleteAsync で削除する BackgroundService を作って。例外処理とログも入れて」🧹
- 「レスポンス本文だけ先に削除→後でレコード削除、の2段階クリーンアップ案をC#で」🧽
- 「TTL外の再送が来た時のAPI設計案（HTTPステータスとレスポンス例）を3案」📮
- 「IdempotencyKey の再利用事故が起きるパターンを5つ。防止策も」🔒
まとめ✨
- TTLは「DBを守るため」だけじゃなく、冪等性の成立条件そのもの だよ🔁
- 目安は 24時間〜7日 あたりが現実的になりやすい（実例あり）📏(Stripe Docs)
- 掃除は ExpiresAtUtc にINDEX＋まとめて削除（ExecuteDeleteAsync） が気持ちよく強い🧹🚀(Microsoft Learn)
- 余裕があれば “2段階掃除”（本文だけ先に捨てる）で、容量＆リスクをさらに下げられる🧽🧺
補足メモ📝
今どきのC#学習・実務は .NET の最新LTS（例：.NET 10）前提で進めると、長期サポート面でも安心だよ🛡️(Microsoft Learn)