Logo

1장 더 빠른 이유: 네 가지 핵심 메커니즘

FileBolt의 속도 우위는 전송 계층, 병렬 청크 분할, 글로벌 토폴로지, 멀티 소스 스케줄링이 결합된 결과입니다. 이 장에서는 어떤 메커니즘이 최대 처리량을 높이고, 어떤 메커니즘이 패킷 손실이나 네트워크 전환 상황에서 안정성과 복구 가능성을 높이는지 검증 가능한 방식으로 설명합니다.

1.1 설계 목표(속도 관점)

  • 목표 A: 대역폭 상한에 근접합니다. 일반적인 조건에서 사용 가능한 대역폭을 최대한 꽉 채우도록 합니다.
  • 목표 B: 안정적인 처리량. 패킷 손실, 지터, 네트워크 전환, 리전 간 높은 RTT 상황에서도 처리량이 갑자기 무너지지 않고 쓸 만한 수준으로 유지되도록 합니다.
  • 목표 C: 복구 가능한 실패. 오류가 발생했을 때 적은 양의 데이터만 다시 전송하는 수준으로 비용을 제한하고, 0%부터 다시 시작하는 일을 피합니다.

1.2 전송 계층 최적화: HTTP/3(QUIC)

  • 클라이언트와 엣지 진입점은 HTTP/3(QUIC)을 우선 사용하는 것이 좋습니다. 브라우저, 네트워크 또는 미들박스가 이를 지원하지 않으면 시스템은 가용성을 유지하기 위해 HTTP/2/HTTP/1.1로 자동 전환해야 합니다.
  • 패킷 손실이 있을 때 QUIC의 전송 및 혼잡 제어는 HOL(head-of-line) 블로킹이 종단 간 처리량에 미치는 영향을 줄여 안정성을 높여 주는 경우가 많습니다(결과는 네트워크 상태에 따라 다릅니다).
  • 0-RTT와 더 빠른 핸드셰이크 경로는 특정 조건에서만 가능한 세션 재개 기능입니다. 조건이 충족되면 시스템이 이점을 얻을 수 있지만, 이를 유일한 성능 향상 수단으로 의존해서는 안 됩니다.

확인 방법

  • 브라우저 개발자 도구(예: Network / Protocol 항목이며 UI는 브라우저마다 다름)에서 요청이 h3(HTTP/3)를 사용하는지, 아니면 h2/h1로 전환되었는지 확인할 수 있습니다.
  • 같은 네트워크 조건에서 h3와 h3가 아닌 경우의 연결 설정 시간과 처리량 안정성(특히 RTT가 길거나 패킷 손실이 있을 때)을 비교하면 눈에 띄는 차이가 나타날 수 있습니다.

1.3 극단적인 동시성: 청크 스트리밍(Chunked Streaming)

  • 시스템은 대용량 파일을 논리적으로 여러 청크로 반드시 분할해야 하며, 각 청크는 업로드, 재시도, 복구의 최소 단위입니다(2장 참조).
  • 클라이언트는 제한된 동시성(예: 여러 개의 병렬 파이프라인)으로 여러 청크를 전송하는 것이 좋습니다. 이렇게 하면 대역폭 상한에 더 가까워지고 단일 연결의 지터에 덜 민감해집니다.
  • 클라이언트는 이어 받기(재개 가능한 전송)를 반드시 지원해야 합니다. 복구할 때는 완료된 청크를 건너뛰고 누락된 청크만 가져와 파일 전체를 다시 전송하지 않아야 합니다(2장 참조).
  • 동시성과 청크 분할은 단일 요청이 막혀서 생기는 대기(HOL 블로킹과 재전송 대기 포함)를 크게 줄여 주지만, 특정 네트워크 현상을 “완전히 없앤다”고 주장해서는 안 됩니다. 목표는 영향을 줄이고 안정적인 처리량을 높이는 것입니다.

확인 방법

  • Network 패널에서 여러 개의 업로드/다운로드 요청이 동시에 병렬로 진행되는 것(청크 동시성)을 확인할 수 있습니다.
  • 네트워크 연결을 끊거나 페이지를 새로 고친 뒤에 전송을 재개하더라도 0%부터 다시 시작하지 않아야 합니다(누락된 청크만 이어서 전송).

1.4 토폴로지 이점: Anycast 최근접 엣지 접속(엣지 네트워크)

  • 시스템은 Anycast와 엣지 진입점을 통해 사용자 요청을 가장 가까운 노드로 라우팅하여, 리전 간 홉으로 인한 RTT와 지연/지터를 줄이는 것이 좋습니다.
  • 최근접 엣지 접속은 병렬 청크 분할의 전반적인 효율을 높여 줍니다. RTT가 낮을수록 보통 동시 플로우 각각의 실효 처리량 상한이 올라가 회선을 꽉 채우기가 더 쉬워집니다.
  • 엣지 커버리지와 위치 수는 인프라가 발전함에 따라 달라질 수 있습니다. 외부에는 “엣지 커버리지 / 최근접 진입점”으로 설명하고, 숫자는 엄격한 보장이 아니라 참고 수치로 다루세요.

확인 방법

  • traceroute나 브라우저의 연결 정보를 이용하면 연결이 더 가까운 진입점에서 종료되는 것을 확인할 수 있는 경우가 많습니다(방법은 환경에 따라 다름).
  • 리전 간 비교(예: 미국↔유럽, 일본↔미국)에서는 대체로 RTT 감소가 가장 눈에 띕니다.

1.5 멀티 소스 동시성: 지능형 스케줄링(Multi-Source)

  • 시스템은 링크 품질 신호(처리량, 지연 시간, 오류율 등)를 바탕으로 동적으로 선택하는 것이 좋습니다. 이렇게 하면 청크마다 더 나은 노드/배치를 여러 개 할당할 수 있어, 한 지점의 혼잡이 전체 처리량에 미치는 영향을 줄일 수 있습니다.
  • 다운로드할 때 클라이언트는 여러 소스에서 서로 다른 청크를 동시에 가져와 “멀티 소스 풀(pull)” 가속 효과를 얻을 수 있습니다. 멀티 소스를 사용할 수 없을 때는 가용성을 유지하기 위해 단일 소스 다운로드로 자동 전환해야 합니다(3장 참조).
  • 이를 “AI”로 홍보한다면, 스케줄링과 의사 결정을 위한 알고리즘 시스템으로 표현하고 입력/출력과 성능 저하(degradation) 시의 동작을 명확히 정의하여 모호한 주장을 피하는 것이 좋습니다.

확인 방법

  • 다운로드하는 동안 서로 다른 소스/연결에서 오는 동시 요청을 확인할 수 있습니다(구현 방식과 브라우저에서 보이는 정보에 따라 다름).
  • 혼잡이나 패킷 손실이 있을 때 멀티 소스 동시성은 더 안정적인 처리량을 제공하는 경우가 많습니다. 조건이 충족되지 않으면 자동으로 성능이 낮아지지만 계속 사용할 수 있습니다.

1.6 다음 장들과의 연결

  • 2장에서는 “청크 분할, 동시성, 멱등성, 이어 올리기”를 구현 가능한 흐름과 제약 조건(MUST/SHOULD/MAY)으로 풀어 설명하고, 이것들이 업로드 속도와 안정성을 직접 좌우하는 이유를 설명합니다.
  • 3장에서는 “병렬 다운로드, 복구 및 재조립”과, 약한 네트워크에서 중복 다운로드로 인한 속도 저하를 피하는 방법을 설명합니다.
  • 4장에서는 성능과 복구 가능성에 관련된 최소한의 스토리지 모델(객체 계층과 상태 계층, TTL/삭제 의미)만 다룹니다.