Folly Code Review · 11/89

folly::Future retry·window·via — 제어 흐름 조합자

2026년 6월 4일 · Hawk · 3분 읽기

cpp folly future retry control

Twitter LinkedIn

한 줄 요약: retry는 실패 시 재시도, window는 동시성 제한, via는 executor 전환이다. 이 세 조합자가 Future 코드의 제어 흐름을 표현한다.

#동기 — 단순 체인을 넘는 제어

.thenValue와 collect만으로는 표현되지 않는 패턴이 있다.

“실패하면 최대 3번 재시도하고, 매번 2배 backoff”
“1000개 요청을 동시에 100개씩만 처리”
“I/O 작업은 IO pool에서, 결과 처리는 다른 CPU pool에서”

이 패턴들은 retry/window/via 세 조합자로 표현된다.

#retry — 재시도 정책

1
#include <folly/futures/Retrying.h>
2

3
// 즉시 재시도, 최대 3회
4
auto sf = folly::futures::retrying(
5
    folly::futures::retryingPolicyBasic(3),
6
    [](size_t attempt) {
7
      LOG(INFO) << "attempt " << attempt;
8
      return doRpc();   // SemiFuture<Response>
9
    });
10

11
// jittered exponential backoff
12
auto sf2 = folly::futures::retrying(
13
    folly::futures::retryingPolicyCappedJitteredExponentialBackoff(
14
        5,                                  // 최대 5회
15
        std::chrono::milliseconds(100),     // base delay
16
        std::chrono::seconds(10),           // max delay
17
        0.1,                                 // jitter ratio
18
        rng,
19
        [](size_t /*attempt*/, exception_wrapper const& ew) {
20
          // shouldRetry — 특정 예외만 재시도
21
          return !ew.is_compatible_with<NonRetryableError>();
22
        }),
23
    [](size_t attempt) {
24
      return doRpc();
25
    });

policy는 (attempt, exception_wrapper) -> SemiFuture<bool>로 재시도할지를 결정한다. true면 delay 후 다시 호출한다.

1
// folly/futures/Retrying.h (개념)
2
template <class Policy, class FF>
3
SemiFuture<R> retrying(Policy policy, FF func) {
4
  return func(0).thenTry([=, p = std::move(policy)](Try<R> t) -> SemiFuture<R> {
5
    if (t.hasValue()) return makeSemiFuture(*std::move(t));
6
    return p(0, t.exception()).thenValue([](bool retry) {
7
      if (!retry) throw t.exception();
8
      return retrying(p, func);   // recursion
9
    });
10
  });
11
}

내부는 recursive로 구현되지만 tail call로 펼쳐지므로 스택이 쌓이지 않는다(Future continuation은 heap에 살아 있음).

#자주 쓰는 policy

Policy	설명
`retryingPolicyBasic(n)`	즉시 재시도 n회
`retryingPolicyCappedJitteredExponentialBackoff`	exponential + jitter
`retryingPolicyCappedExponentialBackoff`	exponential 만
사용자 정의	`(attempt, ew) -> SemiFuture<bool>`

#window — 동시성 제한

1
#include <folly/futures/Future.h>
2

3
std::vector<std::string> urls = ...;  // 10,000개
4

5
// 동시에 100개씩만
6
auto sf = folly::window(
7
    std::move(urls),
8
    [](std::string url) -> SemiFuture<Response> {
9
      return fetchAsync(url);
10
    },
11
    100);   // window size
12

13
// sf: SemiFuture<vector<Try<Response>>>
14
sf.via(&pool).thenValue([](auto results) {
15
  process(results);
16
});

window는 cardinality와 메모리 폭발을 막는다. 10,000 RPC를 한 번에 띄우면 file descriptor가 부족하거나 다운스트림이 throttle한다. window=100이면 100개씩 진행하다 하나 끝날 때마다 다음 하나를 시작한다.

1
// folly/futures/Future-inl.h (개념)
2
template <class Range, class F>
3
SemiFuture<vector<Try<R>>> window(Range input, F func, size_t cap) {
4
  auto ctx = std::make_shared<WindowContext>(input.size());
5
  for (size_t i = 0; i < cap && i < input.size(); ++i) {
6
    spawn(ctx, input, func, i);   // 첫 cap개 시작
7
  }
8
  return ctx->promise.getSemiFuture();
9
}
10

11
void spawn(ctx, input, func, idx) {
12
  func(input[idx]).setCallback_([=](Try<R> t) {
13
    ctx->results[idx] = std::move(t);
14
    size_t next = ctx->nextIdx.fetch_add(1);
15
    if (next < input.size()) spawn(ctx, input, func, next);
16
    if (ctx->remaining.fetch_sub(1) == 1) ctx->promise.setValue(...);
17
  });
18
}

#via — executor 전환

1
folly::IOThreadPoolExecutor io(2);
2
folly::CPUThreadPoolExecutor cpu(8);
3

4
fetchAsync(url)
5
  .via(&cpu)                   // 받은 body를 CPU pool에서 parse
6
  .thenValue(parse)
7
  .via(&io)                    // 결과를 IO pool에서 write
8
  .thenValue(writeFile)
9
  .get();

.via(executor)는 그 이후 continuation이 도는 executor를 바꾼다. I/O와 CPU 작업을 다른 thread pool에 분리할 때 핵심이다.

SemiFuture<T>::via(Executor*)는 SemiFuture를 Future로 바인딩하지만, Future<T>::via(Executor*)는 재바인딩한다.

1
template <class T>
2
Future<T> Future<T>::via(Executor::KeepAlive<> e) && {
3
  auto sf = std::move(*this).semi();   // 먼저 SemiFuture로
4
  return std::move(sf).via(std::move(e));
5
}

#within — timeout

1
fetchAsync(url)
2
  .within(std::chrono::seconds(5))   // 5초 안에 안 끝나면 timeout
3
  .thenError(folly::tag_t<folly::FutureTimeout>{}, [](auto&) {
4
    return Response::timeout();
5
  });

내부적으로 timer thread를 사용해 지정 시간 후 cancellation을 트리거한다. 원래 작업은 계속 돌 수도 있지만 결과는 무시된다.

onTimeout은 비슷하지만 기본값을 직접 반환하는 변형이다.

1
fetchAsync(url).onTimeout(std::chrono::seconds(5), [] {
2
  return Response::cached();
3
});

#조합 예 — retry + window + via

1
// 1000개 URL을 동시 50개씩, 각각 최대 3회 재시도, CPU pool에서 처리
2

3
folly::window(
4
    std::move(urls),
5
    [](std::string url) {
6
      return folly::futures::retrying(
7
          folly::futures::retryingPolicyBasic(3),
8
          [url](size_t) { return fetchAsync(url); });
9
    },
10
    50)
11
  .via(&cpu)
12
  .thenValue([](std::vector<Try<Response>> results) {
13
    size_t ok = 0;
14
    for (auto& r : results) if (r.hasValue()) ++ok;
15
    LOG(INFO) << "ok=" << ok;
16
  });

선언적 표현으로 동시성 + 재시도 + executor가 모두 한 화면에 들어온다.

#std/Abseil과 비교

표준에는 없다. Abseil도 없다. Folly의 retry/window/via는 고유한 영역이다.

C++26 senders/receivers (P2300) 에서는 let_value/bulk/schedule 조합으로 표현된다.

1
Folly                   std::execution
2
─────────────────       ─────────────────
3
.via(e)                 on(scheduler, sender)
4
window(range, f, n)     bulk(range, f) + scheduler
5
retry(policy, f)        let_error(sender, retry_logic)
6
within(d)               stop_when(sender, timer(d))

#코드 리뷰 포인트

retry policy가 모든 예외에 적용되는가? non-retryable error를 분류하지 않으면 무한 재시도 위험.
window cap이 합리적인가? 다운스트림 capacity와 일치하는지 확인.
via 후 다음 thenValue가 어느 executor에서 도는지 명확한가? 마지막 .via가 우세하다.
within 후 timeout 처리가 있는가? .thenError<FutureTimeout> 또는 .onTimeout 사용.

#자주 보는 안티패턴

1
// 1. retry policy 없음 — 무한 재시도
2
folly::futures::retrying([](size_t) { return doRpc(); });   // 컴파일 OK지만 위험
3

4
// 2. window cap이 너무 큼
5
folly::window(million_urls, fetch, 1'000'000);   // window 의미 없음 — collect와 동일
6

7
// 3. via를 한 번도 안 부르고 thenValue 체인
8
computeSemi().deferValue(...).deferValue(...).get();
9
// 내부적으로 InlineExecutor — caller thread에서 dom
10

11
// 4. within timeout이 실제 작업보다 짧음 (의도된 게 아니라면)
12
fetchAsync(slowUrl).within(std::chrono::milliseconds(1)).get();
13
// 거의 항상 timeout