서브 마이크로초 지연을 위한 설계

Source: Dev.to

최소 실행 엔진 구축에서 얻은 교훈

대부분의 프레임워크는 처리량, 개발자 속도, 혹은 수평 확장성을 최적화합니다. 꼬리 지연시간, 결정론, 그리고 서브‑마이크로초 수준의 중요한 경로가 중요할 때, 이러한 추상화는 오히려 부담이 될 수 있습니다. 저는 SubMicro Execution Engine을 만들어 지연시간—기능이 아니라—을 주요 설계 제약으로 삼았을 때 어떤 일이 일어나는지 탐구했습니다. 아래는 시스템을 형성한 몇 가지 실용적인 교훈입니다.

지연시간은 핵심 로직이 아니라 가장자리에서 발생한다

시스템이 실제로 수행하는 “작업” 자체가 병목이 되는 경우는 드뭅니다. 지연시간은 다음에 숨어 있습니다:

• 메모리 할당
• 캐시 라인 경쟁
• 분기 예측 실패
• 스케줄러 전환
• 동기화 프리미티브

핵심 실천 방안

• 핫 경로를 할당 없이 유지
• 평탄하고 캐시 친화적인 데이터 레이아웃 선호
• 암묵적인 동기화 회피
• L1/L2 캐시 안에 들어갈 수 있는 실행 흐름 설계

핫 경로를 메모리에서 그릴 수 없으면 지연시간을 제어할 수 없습니다.

결정론이 원시 처리량을 능가한다

초당 1 M 연산을 수행하는 시스템이 가끔은 200 k 연산을 항상 수행하는 시스템보다 덜 유용합니다.

설계 선택을 이끈 요소

• 안정적인 실행 순서
• 예측 가능한 스케줄링
• 핫 경로에서 최소한의 동적 동작

이는 피크 처리량을 포기하고, 실시간 및 트레이딩 시스템에서 훨씬 더 중요한 긴밀한 지연시간 분포를 얻는 트레이드오프입니다.

추상화는 비용이 있다 — 무자비하게 측정하라

추상화 자체가 나쁜 것은 아니지만, 측정되지 않은 추상화는 위험합니다.

저지연 시스템에서:

• 가상 디스패치는 로직 자체보다 더 큰 비용이 될 수 있다
• 제네릭 컨테이너는 메모리 접근 패턴을 숨긴다
• “깨끗한” 인터페이스는 실행 경로를 파편화시키는 경우가 많다

대신 목표

• 실행에 대한 명시적 제어
• 데이터 이동을 눈에 보이게
• 단순하고 검사 가능한 구성 요소

코드 가독성은 레이어를 추가하는 것이 아니라 제거함으로써 유지됩니다.

스케줄링은 지연시간 기능이다

스케줄러는 작업이 언제 일어나는지를 결정합니다 — 이는 무엇이 일어나는 것만큼 중요합니다.

설계 고려 사항

• 최소한의 컨텍스트 스위칭
• 선택적인 busy‑polling 전략
• 핫 경로에서 OS 간섭을 피하는 실행 모델

목표는 실행을 CPU에 가깝게 유지하고, 큐와 스레드 사이를 오가는 것을 최소화하는 것입니다.

평균이 아닌 꼬리를 측정하라

평균 지연시간은 속일 수 있습니다.

엔진은 다음을 전제로 설계되었습니다:

• p99와 p99.9가 평균보다 더 중요하다
• 가끔 발생하는 스파이크가 실시간 시스템을 깨뜨린다
• 계측은 프로덕션에서도 사용할 수 있을 만큼 가벼워야 한다

꼬리를 측정하지 않으면 눈이 먼 채로 최적화를 시도하는 것입니다.

마무리 생각

이 프로젝트는 의도적으로 최소화되었습니다. 이것은 프레임워크가 아니라 모든 설계 결정이 다음 질문에 답하도록 하는 탐구입니다:

이것이 예측 불가능성을 줄이거나 늘리는가?

Repository: submicro-execution-engine
Demo site: https://submicro.krishnabajpai.me/