cloudflare·2026년 8월 7일·3분 읽기큐레이션 요약

Workers AI와 AI Gateway를 하나의 AI 제어 플레인으로 통합하기

AI Gateway와 Workers AI는 각각 모델 호출 프록시와 Cloudflare 관리형 추론 서비스로 출발했지만, 이제 하나의 통합 AI 제어 평면으로 수렴하고 있다. 사용자는 단일 바인딩과 REST API를 통해 Workers AI를 포함한 여러 모델 제공자를 호출하면서 관측성, 로깅, 보안, 비용 관리, 결제를 한곳에서 처리할 수 있다. 향후에는 제공자가 아니라 원하는 모델을 기준으로 자동 라우팅·장애 조치·부하 분산까지 수행하는 모델 우선 라우팅을 제공할 계획이다. ## 통합된 바인딩과 REST API - Workers AI와 AI Gateway는 별도의 호출 경로가 아니라 동일한 `env.AI.run()` 바인딩으로 통합된다. - `gateway: { id: "default" }`를 지정하면 기본 AI Gateway를 통해 Workers AI 모델을 호출할 수 있다. - REST API도 통합되어 다음과 같은 `/ai/` 엔드포인트를 사용한다. - `https://api.cloudflare.com/client/v4/accounts/{account_id}/ai/run/{model}` - `cf-aig-gateway-id: default` 헤더로 기본 게이트웨이를 지정 - 사용자는 처음부터 Workers AI와 AI Gateway 중 어느 제품을 선택할 필요 없이 관측성과 제어 기능이 포함된 경로를 사용할 수 있다. - 여러 애플리케이션을 분리하거나 애플리케이션별 정책을 적용해야 하는 경우에는 별도의 이름 있는 게이트웨이를 지정할 수 있다. ## 자동 관측성과 제어 - AI Gateway를 사전에 생성하지 않아도 `default` 게이트웨이를 처음 인증 요청에 사용하면 자동으로 생성된다. - 별도 대시보드 설정 없이 다음 정보가 기록된다. - 요청 및 응답 전문 - 모델별 토큰 사용량 - 요청 비용 및 비용 귀속 - 지연 시간 분석 - 오류율 - 기존 Workers AI 직접 호출에 게이트웨이 옵션만 추가하면 전체 관측성을 활성화할 수 있다. - 이후 캐싱 규칙을 사용자 지정하거나 애플리케이션별로 트래픽을 분리하려면 이름 있는 게이트웨이로 변경하면 된다. - 프롬프트와 응답까지 확인할 수 있어 모델 동작 디버깅과 AI 출력 감사에 유용하다. ## AI Gateway 크레딧과 Workers AI 통합 결제 - 기존에는 AI Gateway 크레딧을 OpenAI, Anthropic 등 외부 제공자에만 사용할 수 있었다. - 이제 동일한 크레딧 지갑으로 다음 서비스의 사용량을 결제할 수 있다. - OpenAI - Anthropic - Workers AI - 기타 지원 모델 제공자 - Workers AI에도 선불 결제가 적용된다. - AI Gateway 통합 결제를 사용하는 Workers AI 이용자에게는 더 높은 요청 한도가 제공될 수 있다. - 실제 한도와 상향 요청 방법은 최신 개발자 문서를 확인해야 한다. ## 모델 우선 라우팅 - 현재는 사용자가 특정 제공자를 직접 선택해야 하므로, 해당 제공자의 장애나 속도 제한이 애플리케이션 장애로 이어질 수 있다. - 향후에는 “어느 제공자를 호출할지”가 아니라 “어떤 모델이 필요한지”를 지정하는 방식으로 전환한다. - 추론 능력이 높은 모델 - 빠른 요약 모델 - 저렴한 임베딩 모델 - AI Gateway가 모델을 호스팅하는 제공자를 선택하고 다음 작업을 자동으로 처리한다. - 제공자 선택 - 장애 조치 - 부하 분산 - 용량 부족 시 다른 제공자로의 투명한 전환 - 예를 들어 `kimi-k2.7-code`를 요청하면 Workers AI, Moonshot API 또는 동일 가중치를 제공하는 다른 검증된 제공자 중 적절한 경로가 선택될 수 있다. - 원하면 특정 제공자에 고정할 수도 있다. - 검증된 제공자를 사용하고 Zero Data Retention(ZDR) 같은 데이터 처리 요구사항도 반영할 예정이다. ## 실용적인 적용 방향 새 프로젝트라면 `default` 게이트웨이를 사용해 별도 설정 없이 로그, 토큰 사용량, 비용, 오류율을 확보하는 것이 권장된다. 애플리케이션이 커지면 이름 있는 게이트웨이로 분리하고 캐싱·보안·라우팅 정책을 세분화하면 된다. 장기적으로는 특정 제공자에 강하게 결합하기보다 모델 중심으로 호출 구조를 설계하는 편이 장애 대응과 비용 최적화에 유리하다.

원문 읽기(새 탭에서 열림)

load-balancing옵저버빌리티rest-apiai-gateway+3

figma·2026년 5월 4일·3분 읽기큐레이션 요약

PGKeeper: Postgres에 꼭 필요했던 보안관 만들기 | Figma 블로그

Figma는 데이터베이스 트래픽과 제품 규모가 커지면서 기존 PgBouncer의 확장성·부하 제어·연결 관리 한계에 부딪혔고, 이를 대체할 자체 서비스 PGKeeper를 구축했다. PGKeeper는 DBProxy와 PostgreSQL 사이에서 연결 풀링과 트래픽 관리를 담당하며, 과부하로부터 데이터베이스와 연결을 보호하는 것을 목표로 한다. 글은 Figma의 데이터베이스 구조와 PgBouncer를 교체하게 된 이유, 그리고 PGKeeper를 직접 개발한 배경을 설명한다. ## Figma의 PostgreSQL 데이터베이스 구조 - PostgreSQL은 Figma의 OLTP 시스템 기반이다. - 데이터 증가에 대응하기 위해 데이터베이스를 수평·수직으로 확장하고 여러 PostgreSQL 인스턴스를 운영했다. - 애플리케이션이 샤딩 구조를 직접 알 필요 없도록 **DBProxy**라는 요청 라우팅 계층을 구축했다. - DBProxy는 쿼리를 분석해 적절한 PostgreSQL 인스턴스를 선택하고, 필요하면 여러 인스턴스를 대상으로 쿼리를 재작성한다. - DBProxy와 PostgreSQL 사이에는 연결 풀러가 위치한다. - 각 PostgreSQL 머신에는 전용 연결 풀러 복제본 그룹이 배치되어, 여러 풀러가 하나의 데이터베이스에 연결되는 n-to-1 구조를 이룬다. ## PgBouncer가 한계에 도달한 이유 - **확장성 부족** - PgBouncer는 단일 스레드 아키텍처라 수직 확장에 한계가 있었다. - 복제본을 늘려 수평 확장했지만 트래픽 분배가 치우치면서 성능 저하가 발생했다. - **정교한 부하 관리 부재** - 중요한 트래픽을 낮은 우선순위의 문제성 트래픽보다 먼저 처리할 수 없었다. - 백프레셔가 없어 급격한 트래픽 증가를 우아하게 제어하기 어려웠다. - 대기 시간에 기반해 작업을 버리는 CoDel(Controlled Delay) 같은 부하 완화 알고리즘도 지원하지 않았다. - **연결 폭증과 연결 churn 위험** - PostgreSQL 연결은 많은 자원을 사용한다. - 연결이 빠르게 생성되거나 과도하게 재생성되면 데이터베이스 안정성이 크게 떨어진다. - 장애 이후 무제한으로 연결을 다시 만들면 복구 과정 자체가 PostgreSQL을 압박할 수 있다. - 이로 인해 연결 churn과 연쇄적인 과부하가 장시간 지속될 수 있다. - **확장성과 운영 제어의 한계** - 트래픽 유형별 admission control, 공정한 자원 분배 등 세밀한 정책이 필요했다. - 심층적인 관측성, 기능 플래그 기반의 안전한 롤아웃도 요구됐다. - PgBouncer에 작은 수정 사항을 유지하는 것만으로도 부담이 컸기 때문에, 대규모 확장은 장기적인 유지보수 비용을 초래할 가능성이 컸다. ## DBProxy에 연결 풀링을 통합하지 않은 이유 - PostgreSQL 인스턴스 하나의 연결 풀은 대략 100개 규모로 운영됐다. - 반면 DBProxy는 수백 개의 상태 비저장 복제본으로 구성됐다. - 각 DBProxy가 독립적으로 연결 풀을 관리하면: - 전체 PostgreSQL 연결 제한을 초과할 수 있고, - 복제본 간 복잡한 조정이 필요하며, - 고정된 소규모 연결 풀을 수백 개 인스턴스에 분산하기 어렵다. - 따라서 연결 풀링은 DBProxy 내부가 아니라 별도의 중앙화된 계층에서 담당해야 했다. ## PGCat 대신 자체 서비스를 만든 배경 - Figma는 PgBouncer의 단일 스레드 한계를 해결하기 위해 멀티스레드 PostgreSQL 프록시인 PGCat도 검토했다. - 그러나 필요한 기능을 추가하려면 PGCat의 핵심 실행 경로를 크게 수정해야 했다. - 관측성, 기능 플래그, admission control을 upstream에 반영하기도 쉽지 않았다. - 결국 PGCat을 포크해 장기적으로 유지해야 할 가능성이 높았으므로, Figma는 요구사항에 맞는 Go 기반 자체 서비스 **PGKeeper**를 개발했다. ## PGKeeper의 역할 - PGKeeper는 DBProxy와 PostgreSQL 사이에 위치하는 Go 서비스다. - 주요 목적은 다음과 같다. - 데이터베이스를 과도하거나 잘못된 트래픽으로부터 보호 - PostgreSQL 연결의 급격한 생성과 churn 방지 - 트래픽 우선순위와 자원 사용을 세밀하게 제어 - 대규모 환경에 맞는 확장성과 운영 도구 제공 - 이름은 골키퍼처럼 위험한 트래픽이 시스템을 압도하지 못하도록 막고, 연결 자체도 보호한다는 의미에서 붙여졌다. Figma의 사례는 단순히 연결 풀러를 교체한 것이 아니라, 데이터베이스 앞단에서 트래픽을 선별하고 과부하를 제어하는 별도 인프라 계층이 필요해졌음을 보여준다. PostgreSQL 연결 수가 제한적이고 프록시 복제본이 많은 환경에서는 풀링을 애플리케이션 프록시에 분산하기보다, 독립적인 계층으로 관리하는 편이 적합하다.

원문 읽기(새 탭에서 열림)

load-balancingPostgreSQLGodatabase-sharding+3

google·2025년 3월 19일원문

무작위 작업 도착 (새 탭에서 열림)

구글 리서치(Google Research)의 Ravi Kumar와 Manish Purohit는 대규모 클러스터 관리 시스템에서 필수적인 부하 분산(Load balancing) 문제를 최신 온라인 알고리즘 이론으로 분석했습니다. 연구팀은 작업이 무작위 순서로 도착하는 환경을 가정하고, 결정적(deterministic) 온라인 알고리즘이 가질 수 있는 성능의 이론적 한계를 새롭게 정립했습니다. 이 연구는 기존의 최악 조건 분석을 넘어 현실적인 무작위 작업 흐름에서 알고리즘이 달성할 수 있는 최선의 성능이 $\sqrt{\log n}$ 수준임을 입증하며 이론적 간극을 메웠습니다. ### 트리 균형 게임을 통한 부하 분산 모델링 * **모델의 정의**: 부하 분산 문제를 기하학적인 '트리 균형 게임'으로 치환하여 설명합니다. 트리 내의 노드는 서버(머신)를, 노드를 연결하는 간선(edge)은 처리해야 할 작업(job)을 의미합니다. * **목표와 규칙**: 간선이 하나씩 제시될 때마다 알고리즘은 이를 두 끝점 중 하나로 방향을 정해야(orient) 합니다. 최종 목표는 특정 노드로 향하는 간선의 수(내차수, indegree)의 최댓값을 최소화하는 것입니다. * **경쟁 분석(Competitive Analysis)**: 미래의 모든 정보를 알고 있는 오프라인 최적 알고리즘의 결과와 온라인 알고리즘의 결과를 비교하여 알고리즘의 효율성을 측정합니다. ### 결정적 알고리즘의 전통적 한계 * **최악의 시나리오**: 1990년대부터 알려진 바에 따르면, 적대적인 공격자(adversary)가 작업 순서를 정할 경우 어떤 결정적 알고리즘도 최대 부하를 $\log n$($n$은 노드 수) 미만으로 유지할 수 없습니다. * **정보의 비대칭성**: 공격자는 알고리즘이 어떤 선택을 해도 부하가 높아질 수밖에 없는 순서로 간선을 배치하며, 이는 시스템 성능의 하한선을 결정하는 근거가 됩니다. * **그리디 알고리즘의 한계**: 단순히 부하가 적은 쪽으로 작업을 배정하는 탐욕적(Greedy) 방식은 작업 도착 순서에 따라 성능이 크게 좌우되는 취약점을 가집니다. ### 무작위 도착 순서에서의 새로운 이론적 하한선 * **무작위 순서 모델**: 모든 작업의 순열이 동일한 확률로 발생하는 환경을 가정합니다. 이는 실제 데이터 센터의 워크로드와 더 유사한 모델입니다. * **성능 격차의 발견**: 이전 연구에서는 무작위 순서일 때 그리디 알고리즘이 $\log n$보다 약간 나은 성능을 보인다는 점을 밝혔으나, 다른 정교한 알고리즘이 얼마나 더 잘할 수 있는지는 미지로 남아있었습니다. * **재귀적 구조를 통한 증명**: 본 연구는 재귀적으로 구성된 새로운 사례를 통해, 무작위 순서에서도 결정적 알고리즘이 $\sqrt{\log n}$보다 나은 경쟁비를 보장할 수 없음을 증명했습니다. 이는 기존 예측보다 하한선을 지수적으로 높인 결과입니다. 이 연구는 구글의 보그(Borg)와 같은 대규모 클러스터 관리 시스템에서 자원 할당 효율성을 높이기 위한 이론적 토대를 제공합니다. 작업이 무작위로 유입되는 실제 환경에서도 알고리즘이 극복할 수 없는 수학적 한계가 존재함을 이해함으로써, 더욱 견고하고 현실적인 스케줄링 전략을 설계하는 지침으로 활용될 수 있습니다.

load-balancingscheduling-algorithmsgraph-theoryonline-algorithms+3

datadog·2025년 2월 19일원문

스트리밍 플랫폼으로 대규모 환경에서 흔들림 없는 Kafka 안정성 달성 (새 탭에서 열림)

데이터독(Datadog)은 매일 수백 조 건의 이벤트를 처리하기 위해 수천 개의 토픽과 수백 개의 아파치 카프카(Apache Kafka) 클러스터를 운영하고 있습니다. 기존의 정적인 카프카 설정으로는 대규모 환경에서 발생하는 하드웨어 장애나 트래픽 변동에 유연하게 대응하기 어렵기 때문에, 데이터독은 카프카 인프라를 추상화한 '스트리밍 플랫폼(Streaming Platform)'이라는 제어 계층을 구축했습니다. 이를 통해 애플리케이션의 재설정이나 배포 없이도 실시간으로 트래픽을 리디렉션하고 클러스터를 관리함으로써 시스템의 복원력과 확장성을 극대화했습니다. ### 스트림(Streams)을 통한 파이프라인 복원력 강화 - **논리적 추상화**: 물리적인 카프카 토픽 대신 '스트림'이라는 추상화된 단위를 사용합니다. 스트림은 여러 클러스터와 가용 영역(AZ)에 걸쳐 존재할 수 있으며, 생산자와 소비자는 실제 카프카 토폴로지를 알 필요 없이 안정적인 식별자를 통해 데이터에 접근합니다. - **인프라 디커플링**: 애플리케이션이 특정 카프카 리소스에 종속되지 않기 때문에, 인프라 구성을 실시간으로 변경하거나 트래픽을 새로운 토픽/클러스터로 원활하게 재라우팅할 수 있습니다. ### 실시간 트래픽 페일오버 및 리밸런싱 - **무중단 전환**: 특정 클러스터에 문제가 발생하면 제어 계층이 즉시 새로운 토픽을 생성하고 트래픽을 리디렉션합니다. 생산자는 즉시 새 토픽으로 데이터를 보내고, 소비자는 기존 토픽의 잔량을 처리한 후 새 토픽으로 넘어가는 방식을 통해 데이터 유실 없이 전환이 이루어집니다. - **유연한 운영**: 장애 대응뿐만 아니라 클러스터 폐기, 파티션 수 조정, 부하 분산 등의 작업을 애플리케이션 수정 없이 수 초 내에 수행할 수 있습니다. ### 대규모 환경에 최적화된 Assigner와 소비자 모델 - **자체 코디네이터 개발**: 카프카의 기본 그룹 코디네이터는 세션 타임아웃에 의존하여 반응이 느리다는 단점이 있습니다. 이를 대체하기 위해 개발된 'Assigner'는 클러스터 상태와 CPU 부하 등의 메트릭을 실시간으로 모니터링하여 수 초 내에 워크로드를 재분배합니다. - **병렬 처리 극대화**: 엄격한 순서 보장보다는 '최소 한 번(at-least-once)' 전달 모델을 채택하고 소비 단계에서의 순서 제약을 완화했습니다. 이를 통해 대규모 병렬 처리를 구현하고, 순서 보장이 필요한 경우 이벤트 저장소 하단에서 처리하도록 설계했습니다. ### Head-of-line Blocking 문제 해결 및 고급 커밋 로그 - **스트림 레인(Stream Lanes)**: 서비스 품질(QoS)에 따라 트래픽을 독립적인 '레인'으로 분리합니다. 우선순위가 높은 실시간 데이터가 일시적인 트래픽 급증이나 낮은 우선순위 데이터로 인해 지연되는 것을 방지합니다. - **Dead-letter Queue(DLQ)**: 특정 이벤트(Poison Pill)가 처리를 방해할 경우 이를 별도의 DLQ로 격리하여 파티션 전체가 멈추는 현상을 방지합니다. - **메타데이터 기반 커밋**: 카프카의 단일 포인터 오프셋 커밋 방식에서 벗어나, 커밋 메타데이터 공간을 활용해 파티션 내 여러 오프셋 범위를 동시에 추적합니다. 이를 통해 소비자가 이전 데이터를 재처리하는 동안에도 최신 트래픽을 동시에 처리할 수 있는 유연성을 확보했습니다. 카프카를 대규모로 운영할 때는 인프라를 고정된 자산이 아닌 '교체 가능한 소모품'으로 취급하는 제어 계층이 필수적입니다. 데이터독의 사례처럼 물리적 인프라와 논리적 데이터 흐름을 분리하는 추상화 계층을 구축함으로써, 운영 복잡성을 낮추고 대규모 장애 상황에서도 시스템의 연속성을 보장할 수 있습니다.

load-balancing데이터베이스 설계쿠버네티스Apache Kafka+4

datadog·2023년 2월 22일원문

Husky: 대규모 환경에서의 정확히 한 번 데이터 수집과 멀티테넌시 (새 탭에서 열림)

Datadog의 3세대 이벤트 저장소인 Husky는 대규모 멀티테넌트 환경에서 데이터 중복 없는 '정확히 한 번(Exactly-once)'의 인입을 보장하기 위해 데이터 지역성(Locality) 기반의 라우팅 아키텍처를 도입했습니다. 스캔과 집계에 최적화된 Husky의 특성상 고성능 포인트 조회가 어렵다는 점을 극복하기 위해, 결정론적 샤딩을 통해 중복 제거의 범위를 샤드 단위로 한정하여 시스템 복잡도를 낮췄습니다. 이를 통해 테넌트별 데이터 격리 비용을 최소화하고, 가변적인 트래픽 상황에서도 효율적으로 스토리지와 컴퓨팅 자원을 확장할 수 있는 기반을 마련했습니다. ## 샤드 라우터를 통한 데이터 지역성 확보 * **결정론적 매핑**: 업스트림 서비스인 'Shard Router'를 사용하여 이벤트의 ID와 타임스탬프를 기반으로 특정 샤드(파티션 그룹)에 이벤트를 할당합니다. * **샤드 할당 전략**: 각 테넌트에게 고정된 리스트의 샤드를 할당하고, 해당 리스트 내에서 이벤트 ID를 해싱하여 샤드를 선택함으로써 무작위 라우팅을 방지합니다. * **테넌트 격리**: 개별 워커 노드가 노출되는 테넌트와 인덱스의 수를 최소화하여, 시스템 전체의 복잡도를 관리 가능한 수준으로 유지합니다. ## 데이터 지역성 도입의 기술적 이점 * **중복 제거(Deduplication) 효율화**: 동일한 ID를 가진 이벤트는 항상 같은 샤드로 라우팅되므로, 전체 시스템이 아닌 샤드 내부에서만 중복 여부를 확인하면 됩니다. 이벤트 ID 세트가 메모리에 수용 가능한 크기로 유지되어 처리 속도가 비약적으로 향상됩니다. * **스토리지 비용 절감**: Husky는 테넌트별로 데이터를 전용 테이블에 격리하며 파일 단위로 저장합니다. 지역성을 통해 워커당 처리하는 테넌트 수를 제한하면 생성되는 파일 수가 줄어들어, 클라우드 스토리지 비용과 후속 컴팩션(Compaction) 작업의 부하를 동시에 낮출 수 있습니다. * **성능 최적화**: 워커 노드가 처리해야 할 논리적 네임스페이스의 카디널리티(Cardinality)가 낮아짐에 따라 쓰기 성능이 개선되고 리소스 효율성이 높아집니다. ## 동적 환경에서의 라우팅 도전 과제 * **할당 변경 관리**: 특정 테넌트의 트래픽이 갑자기 수십 배 증가하거나 전체 샤드 수가 변경될 때, 기존의 결정론적 규칙을 유지하면서도 유연하게 샤드 배정을 변경해야 합니다. * **분산 노드 간 합의**: 모든 샤드 라우터 노드가 동일한 라우팅 규칙을 공유해야 중복 데이터 유입을 방지할 수 있으며, 이를 위해 노드 간의 일관성 있는 결정 메커니즘이 필수적입니다. * **부하 분산(Load Balancing)**: 모든 샤드에 인입 트래픽이 균등하게 배분되도록 설계하여 특정 워커 노드에 부하가 집중되는 '핫스팟' 현상을 방지해야 합니다. 대규모 분산 시스템에서 데이터 일관성을 유지하며 비용을 최적화하려면, 무상태(Stateless) 라우팅보다는 데이터의 특성에 맞춘 지역성 설계를 우선 고려해야 합니다. 특히 테넌트 수가 많은 SaaS 환경에서는 워커가 처리하는 테넌트의 카디널리티를 물리적으로 제한하는 것이 스토리지 관리 비용을 결정짓는 핵심 요소가 됩니다.

load-balancing데이터베이스 설계Apache Kafka분산 시스템+4

datadog·2022년 4월 13일·1분 읽기큐레이션 요약

언제나 DNS 문제다...

제공된 내용에는 본문이 아니라 Datadog 웹사이트의 메뉴와 링크 목록만 포함되어 있어, 기술 블로그 글의 주장이나 기술적 세부사항을 정확히 요약할 수 없습니다. 링크 주소상 글은 **gRPC의 DNS 및 로드 밸런싱 관련 장애 분석 글**로 보이지만, 본문 없이 내용을 추정하면 부정확할 수 있습니다. 글의 본문을 붙여 주시면 요청하신 형식에 맞춰 다음과 같이 정리해 드리겠습니다. - 핵심 주장과 결론을 2~4문장으로 요약 - DNS 해석, gRPC 로드 밸런싱, 장애 원인 등 섹션별 설명 - 구체적인 기술적 원인과 대응 방법 - 실용적인 운영 권장사항

원문 읽기(새 탭에서 열림)

load-balancing옵저버빌리티grpcdns+1