← 문제로

23. 요청 데드라인 전파 부재와 재시도 증폭 (C#)

난이도 상
내 리뷰 · C#
해설 · C#

해설 — 요청 데드라인 전파 부재와 재시도 증폭 (C#)

난이도: 상

요약

각 계층이 자기만의 타임아웃과 재시도를 갖고 있고, 상위 계층이 "언제까지 기다릴 것인가"를 하위로 전달하지 않는다. 그래서 (1) 게이트웨이가 포기한 뒤에도 하위 서비스는 계속 일하고 (고아 작업), (2) 계층별 재시도 횟수가 곱해져 하위 호출량이 폭증하며, (3) 계층별 타임아웃 합이 상위 타임아웃보다 커서 상위 타임아웃이 사실상 유일한 제한이 된다. 장애 시 부하가 줄기는커녕 늘어나 회복을 막는 전형적인 구조다.

문제점

1) 데드라인이 전파되지 않음 — (A)+(B) [데드라인 전파 부재]

  • 증상: 게이트웨이가 5초에 취소해 클라에 실패를 반환해도, 랭킹 서비스는 이미 시작한 하위 호출과 DB 쿼리를 끝까지 수행한다. 아무도 결과를 받지 않는 고아 작업(orphan work) 이 CPU·DB 커넥션·스레드를 계속 소비한다.
  • 재현 조건: 통계 서비스 응답을 8초로 지연시키고 부하를 준다. 게이트웨이 성공률은 0 인데 통계 서비스 QPS 와 DB 부하는 정상 시보다 높게 유지된다.
  • 근본 원인: 남은 시간(deadline)은 요청의 속성인데 각 계층의 로컬 상수로 하드코딩되어 있다. HTTP 요청에 데드라인 헤더가 실리지 않고, RankingService.HandleAsync 는 아예 CancellationToken 을 받지 않는다. 게이트웨이의 cts.Token 은 자기 HTTP 소켓만 끊을 뿐, 원격 서버의 처리를 멈추게 하지 못한다.

2) 재시도의 곱셈 증폭 — (A)+(B) [재시도 증폭/메타스테이블 장애]

  • 증상: 게이트웨이 3회 × 랭킹 3회 = 하위 서비스 호출이 최대 9배. 통계 서비스가 느려질수록 타임아웃 → 재시도가 더 자주 발생해 부하가 더 커지는 양의 되먹임이 생긴다. 원인이 사라져도 부하가 스스로 유지되는 메타스테이블 장애로 이어진다.
  • 재현 조건: 통계 서비스 지연을 3초 이상으로 올리면 즉시 재현된다.
  • 근본 원인: 재시도를 여러 계층에 중복 배치했다. 재시도는 원칙적으로 한 계층에서만 수행해야 하며, 배치할 곳은 보통 가장 바깥(또는 실패 원인을 가장 잘 아는 한 곳)이다.

3) 백오프·지터 부재 — (A)+(B) [thundering herd]

  • 증상: 타임아웃 즉시 재시도하므로, 장애 순간 모든 요청이 같은 리듬으로 동시에 재시도해 하위 서비스에 파상 공격을 가한다.
  • 근본 원인: 지수 백오프와 무작위 지터가 없다.

4) 타임아웃 예산이 계층 간에 맞지 않음 — (A)+(B) [예산 배분]

  • 증상: 게이트웨이 5초인데 랭킹 서비스는 하위 호출당 3초 × 3회 = 최대 9초를 쓸 수 있다. 통계 서비스는 DB 쿼리 10초를 허용한다. 하위 계층의 상한이 상위보다 크면 하위 타임아웃은 작동하지 않는 장식이 된다.
  • 근본 원인: 타임아웃을 계층마다 독립적으로 정했고, "남은 예산"이라는 개념이 없다.

5) 취소 불가능한 재시도 루프 — (B) [취소 전파]

  • CallWithRetryAsync 는 외부 CancellationToken 을 받지 않고 매번 새 CancellationTokenSource 만 만든다. 상위가 취소해도 이 루프를 멈출 방법이 없다.

6) 재시도 대상 구분 부재 — (B) [멱등성]

  • HttpRequestException 을 무조건 재시도한다. 이 예제는 조회라 멱등하지만, 같은 헬퍼가 쓰기 요청에 쓰이면 중복 부수효과가 생긴다. 4xx 같은 재시도 무의미한 오류까지 재시도한다.

수정안

핵심은 데드라인을 요청과 함께 전파하고, 재시도는 한 계층에만, 예산을 계층 간에 배분 하는 것이다.

// ---- 게이트웨이: 데드라인의 유일한 소유자 ----
public sealed class GatewayHandler
{
    private static readonly TimeSpan RequestBudget = TimeSpan.FromSeconds(5);

    public async Task<string> GetRankingAsync(long accountId, CancellationToken clientCt)
    {
        using var cts = CancellationTokenSource.CreateLinkedTokenSource(clientCt);
        cts.CancelAfter(RequestBudget);
        var deadline = DateTimeOffset.UtcNow + RequestBudget;   // 절대 시각

        // (2) 재시도는 여기 한 곳에서만. 남은 예산이 있을 때만 재시도한다.
        int attempt = 0;
        while (true)
        {
            try
            {
                return await _ranking.FetchAsync(accountId, deadline, cts.Token);
            }
            catch (Exception ex) when (IsTransient(ex) && !cts.IsCancellationRequested)
            {
                attempt++;
                var backoff = Backoff(attempt);          // (3) 지수 + 지터
                if (DateTimeOffset.UtcNow + backoff + MinCallTime >= deadline) throw;  // (4)
                await Task.Delay(backoff, cts.Token);
            }
        }
    }

    private static TimeSpan Backoff(int attempt) =>
        TimeSpan.FromMilliseconds(
            Math.Min(1000, 50 * Math.Pow(2, attempt)) * (0.5 + Random.Shared.NextDouble() * 0.5));
}

public sealed class RankingClient
{
    public async Task<string> FetchAsync(long accountId, DateTimeOffset deadline, CancellationToken ct)
    {
        var req = new HttpRequestMessage(HttpMethod.Get, $"http://ranking/v1/{accountId}");
        // (1) 남은 시간을 헤더로 전파 (gRPC 의 grpc-timeout 과 같은 역할)
        var remaining = deadline - DateTimeOffset.UtcNow;
        if (remaining <= TimeSpan.Zero) throw new TimeoutException();
        req.Headers.Add("X-Request-Deadline-Ms", ((int)remaining.TotalMilliseconds).ToString());

        var res = await Http.SendAsync(req, ct);
        return await res.Content.ReadAsStringAsync(ct);
    }
}

// ---- 랭킹 서비스: 전달받은 데드라인을 존중하고, 재시도하지 않는다 ----
public sealed class RankingService
{
    public async Task<string> HandleAsync(long accountId, DateTimeOffset deadline, CancellationToken ct)
    {
        var remaining = deadline - DateTimeOffset.UtcNow;
        if (remaining <= TimeSpan.Zero) throw new TimeoutException();   // (1) 시작 전 조기 포기

        using var cts = CancellationTokenSource.CreateLinkedTokenSource(ct);
        cts.CancelAfter(remaining);

        // 병렬 호출: 각자 남은 예산을 그대로 상속한다. 계층 내 재시도 없음.
        var statsTask   = _stats.GetAsync(accountId, deadline, cts.Token);
        var profileTask = _profile.GetAsync(accountId, deadline, cts.Token);
        await Task.WhenAll(statsTask, profileTask);
        return Combine(statsTask.Result, profileTask.Result);
    }
}

서버 진입점(미들웨어)에서 헤더를 읽어 요청 컨텍스트에 데드라인을 심고, 이후 모든 하위 호출이 그 값을 상속하게 한다. 데드라인이 이미 지났으면 작업을 시작하지도 않고 즉시 거절한다. 이것만으로도 장애 시 하위 부하가 급감한다.

// 미들웨어
if (ctx.Request.Headers.TryGetValue("X-Request-Deadline-Ms", out var v) && int.TryParse(v, out int ms))
{
    var deadline = DateTimeOffset.UtcNow + TimeSpan.FromMilliseconds(ms);
    if (deadline <= DateTimeOffset.UtcNow) { ctx.Response.StatusCode = 504; return; }
    ctx.Items["deadline"] = deadline;
}

DB 호출도 남은 예산으로 CommandTimeout 을 설정해야 체인 전체가 일관된다.

더 나은 설계

  • gRPC 사용: grpc-timeout 헤더로 데드라인이 표준적으로 전파되고, 만료 시 서버 측 context.CancellationToken 이 자동으로 취소된다. 트레이드오프 — 프로토콜 전환 비용.
  • 재시도 예산(retry budget) / 어댑티브 재시도: 전체 요청 대비 재시도 비율을 10% 등으로 제한해 장애 시 증폭을 원천 차단한다(Envoy·Finagle 방식). 트레이드오프 — 구현·튜닝 복잡도.
  • 서킷 브레이커 + 격벽: 하위 서비스가 계속 실패하면 회로를 열어 호출 자체를 막고, 서비스별 동시 호출 수를 격리한다. 트레이드오프 — 반열림 구간의 정책 설계 필요.
  • 부분 응답 허용(graceful degradation): 프로필이 늦으면 랭킹만이라도 반환. 게임 UI 에서는 "일부 정보 없음"이 "전체 실패"보다 낫다. 트레이드오프 — 클라 처리 분기 증가.
  • 데드라인은 절대 시각으로: 상대 시간을 계층마다 다시 계산하면 네트워크 지연이 누적 반영되지 않는다. 단, 서버 간 시계 오차가 있으므로 "남은 밀리초"를 전달하고 각 서버가 자기 단조 시계로 절대 시각을 만드는 방식이 안전하다.

면접 포인트

  1. 타임아웃과 데드라인의 차이. 왜 "각 호출 3초"가 아니라 "이 요청은 앞으로 N ms"가 옳은가.
  2. 재시도 증폭(retry amplification). 계층 수 L, 계층별 재시도 R 일 때 최악 호출량이 R^L 이 되는 구조와, 재시도를 한 계층으로 모아야 하는 이유.
  3. 메타스테이블 장애 — 트리거가 사라져도 재시도 부하가 스스로를 유지하는 상태. 벗어나는 방법 (부하 차단, 재시도 예산, 백오프+지터, 조기 거절).
  4. 고아 작업이 왜 위험한가. 아무도 기다리지 않는 계산이 스레드풀·DB 커넥션을 점유해 정상 요청까지 굶기는 경로.
← 문제로 돌아가기