dropbox·2026년 7월 20일·4분 읽기큐레이션 요약

범용 콘텐츠 처리 플랫폼 Riviera가 AI와 그 너머를 위해 어떻게 진화했는가

Dropbox의 콘텐츠 처리 플랫폼 Riviera는 파일 미리보기 서비스에서 출발해 Search, Replay, Sign, Dash 등 여러 제품이 공유하는 범용 변환 플랫폼으로 발전했다. 핵심 설계는 파일별·제품별 파이프라인을 따로 만드는 대신, PDF 변환·페이지 이미지 생성·텍스트 추출 같은 작은 변환 작업을 재사용 가능한 플러그인으로 조합하는 것이다. AI 제품의 확산으로 문서와 미디어를 일관된 형태로 준비하는 수요가 커지면서, Dropbox는 Riviera의 기능을 외부 개발자와 설계 파트너에게 API와 Model Context Protocol 도구로 공개했다. ## 미리보기 문제에서 시작된 플랫폼 - Dropbox는 300개가 넘는 파일 형식을 지원하며, 각 형식에서 썸네일, 전체 미리보기, 추출 텍스트, 스트리밍 매니페스트, 메타데이터 등 다양한 결과물을 생성해야 했다. - 파일 형식과 출력물마다 별도 서비스를 만들면 다음 문제가 발생한다. - 동일한 변환 로직이 여러 서비스에 중복됨 - 의존성, 패키지 버전, 설정이 서로 달라짐 - 유지보수와 운영 부담이 커짐 - Riviera는 모든 미리보기를 독립적인 기능으로 보지 않고, 재사용 가능한 작은 변환 단계의 조합으로 정의했다. - 예를 들어 PowerPoint 미리보기는 다음처럼 처리할 수 있다. - PowerPoint를 PDF로 변환 - PDF의 각 페이지를 이미지로 변환 - 생성된 이미지를 Dropbox 화면에서 표시 - PDF를 이미지로 바꾸는 단계는 PDF 자체의 미리보기나 다른 페이지 이미지 생성 작업에도 재사용할 수 있다. ## 조정과 실행을 분리한 아키텍처 - Riviera의 중앙 구성 요소는 변환 요청을 수집하고, 작업을 조합하며, 적절한 백엔드 워커에 분배한다. - 중앙 계층은 다음 기능을 담당한다. - 요청 유효성 검증 - 변환 작업 구성 - 결과 캐싱 - 중복되거나 잘못된 작업 차단 - 각 백엔드 워커는 특정 변환 유형을 담당한다. - 기능별로 독립적인 유지보수와 확장이 가능함 - 특정 변환의 처리량에 맞춰 개별적으로 확장할 수 있음 - 새로운 파일 형식이나 변환 유형을 추가할 때 핵심 인프라를 수정하는 대신 플러그인을 추가하면 된다. - 현재 Riviera는 100개가 넘는 변환 기능을 제공하며, 초당 수십만 건의 변환을 처리한다. - 이 구조 덕분에 핵심 플랫폼은 안정적으로 유지하면서 지원 파일 형식과 제품 기능을 계속 확장할 수 있었다. ## 여러 제품이 공유하는 변환 라이브러리 - Riviera는 처음에는 전담 Previews 팀이 운영하는 내부 서비스였지만, 다른 팀들도 동일한 콘텐츠 처리 문제를 겪고 있다는 사실이 드러났다. - 예를 들어 미리보기용으로 만든 160×160 썸네일은 머신러닝 팀의 이미지 정규화에도 활용할 수 있었다. - 같은 결과물을 여러 소비자가 사용하면 변환을 한 번만 수행하면 됨 - Search 팀은 문서를 검색 인덱싱에 적합한 형태로 준비하기 위해 Riviera를 도입했다. - Sign, DocSend, Replay 같은 제품도 기존 변환 기능을 재사용했다. - 이후 Dropbox는 플러그인 모델을 제품 팀에 개방했다. - Riviera 팀은 핵심 아키텍처를 관리 - 각 제품 팀은 필요한 변환 플러그인을 추가 - 추가된 플러그인은 다른 팀도 사용할 수 있는 공유 자산이 됨 ## Replay가 보여준 플러그인 모델의 효과 - 동영상 리뷰 제품인 Replay는 동영상 트랜스코딩과 조작이라는 복잡한 처리 작업이 필요했다. - Riviera의 미디어 변환 기능을 활용함으로써 Replay 팀은 동영상 처리 인프라를 처음부터 구축하지 않아도 됐다. - 제품 팀이 변환 기능을 요청하면 Riviera가 기존 기능을 노출하거나 새 플러그인을 추가하는 방식이 정착됐다. - 그 결과 기존에는 수개월이 걸릴 수 있었던 기능을 수주 안에 출시할 수 있었고, 새로운 플러그인이 추가될수록 다음 제품의 개발도 빨라졌다. ## Dash와 AI가 만든 새로운 요구 - AI 모델이 문서에 답변하거나 보고서를 요약하려면 먼저 문서가 모델이 처리할 수 있는 일관된 형태로 변환되어야 한다. - 필요한 전처리에는 다음 작업이 포함된다. - 텍스트 추출 - 스캔 문서의 페이지 인식 - 메타데이터 추출 - 다양한 파일 형식의 통일된 표현으로 변환 - 이러한 작업은 본질적으로 AI 모델 자체의 문제가 아니라 콘텐츠 변환 문제이며, Riviera가 기존부터 해결해 온 영역이다. - Dash 팀은 Riviera가 이미 지원하던 수백 가지 파일 형식과 변환 기능을 활용해 별도의 문서 처리 시스템을 새로 만들 필요를 줄였다. - Riviera는 미리보기와 미디어 처리뿐 아니라 검색, 문서 자동화, AI용 콘텐츠 준비에도 적용되는 기반 계층으로 확장됐다. ## 외부 개발자를 위한 공개 - Dropbox는 Riviera에서 축적한 콘텐츠 변환 기능을 API와 Model Context Protocol 도구 형태로 개발자 생태계와 설계 파트너에게 제공하기 시작했다. - 활용 사례로는 다음과 같은 작업이 제시된다. - 콘텐츠 관리 시스템 구축 - 문서 처리 워크플로 자동화 - 파일 검색용 인덱싱 - AI 애플리케이션용 문서 전처리 - 핵심 가치는 제품마다 변환 인프라를 새로 구축하지 않고, 검증된 공통 플랫폼을 이용할 수 있다는 점이다. Riviera의 사례는 대규모 콘텐츠 처리를 제품별 기능이 아니라 재사용 가능한 변환 조합과 플러그인 플랫폼으로 설계해야 한다는 점을 보여준다. 특히 AI 애플리케이션을 만들 때 모델 개발에만 집중하기보다, 다양한 파일을 안정적으로 추출·정규화·변환하는 기반을 먼저 확보하는 것이 실용적인 접근이다.

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

분산 시스템AI모델 컨텍스트 프로토콜plugin-architecture+3

aws·2026년 7월 13일·4분 읽기큐레이션 요약

Amazon SQS 20주년: 대규모 환경에서 20년간 이어온 안정적인 메시징 | Amazon Web Services

Amazon SQS는 서비스 간 결합도를 낮추고 장애 전파를 막기 위해 메시지를 비동기적으로 전달하는 AWS의 관리형 메시지 큐 서비스다. 출시 20년 동안 FIFO 고처리량, 암호화 기본 적용, DLQ 복구, 대규모 메시지 처리 등 기능이 크게 발전했지만, 서비스 간 분리·트래픽 버퍼링·장애 격리라는 핵심 역할은 변하지 않았다. 최근에는 멀티테넌트 시스템과 AI 에이전트·추론 워크로드에도 활용 범위가 확대되고 있다. ## 비동기 메시징을 통한 서비스 결합도 완화 - 서비스가 서로 직접 호출하면 호출 대상의 지연이나 장애가 연쇄적으로 전체 시스템에 영향을 줄 수 있다. - SQS를 사용하면 생산자는 메시지를 큐에 저장한 뒤 작업을 계속하고, 소비자는 처리 가능한 시점에 메시지를 가져갈 수 있다. - 이를 통해 다음과 같은 효과를 얻는다. - 서비스 간 의존성 및 결합도 감소 - 트래픽 급증 시 메시지 큐를 버퍼로 활용 - 특정 서비스 장애가 전체 시스템으로 확산되는 것을 방지 - 소비자의 처리 속도에 맞춘 안정적인 작업 처리 ## FIFO 큐의 처리량과 동시성 향상 - 2021년 FIFO 큐 고처리량 모드가 출시되며 API 작업당 초당 3,000건(TPS)을 지원했다. - 이후 처리량이 단계적으로 증가했다. - 2022년: 6,000 TPS - 2023년 8월: 9,000 TPS - 2023년 10월: 18,000 TPS - 2023년 11월: 일부 리전에서 최대 70,000 TPS - 2024년에는 FIFO 큐의 인플라이트 메시지 한도가 20,000개에서 120,000개로 증가했다. - 소비자가 동시에 처리할 수 있는 메시지가 늘어나 대규모 순서 보장 처리에 유리해졌다. ## 암호화와 세분화된 접근 제어 - 2021년 SQS 관리형 키를 사용하는 서버 측 암호화 방식인 SSE-SQS가 도입됐다. - 2022년 10월부터 새로 생성되는 큐에는 SSE-SQS가 기본 적용됐다. - 고객이 직접 암호화 키를 생성하고 관리하지 않아도 메시지를 보호할 수 있다. - 2022년에는 ABAC(Attribute-Based Access Control)가 추가됐다. - 큐의 고정된 리소스 정책 대신 태그를 기준으로 권한을 부여할 수 있다. - 큐와 환경이 늘어나는 대규모 시스템에서 권한 정책 관리 부담을 줄인다. ## DLQ 메시지 복구 기능 강화 - 처리에 실패한 메시지를 보관하는 Dead-Letter Queue(DLQ)에서 원래 큐로 메시지를 되돌리는 기능이 단계적으로 확대됐다. - 2021년에는 SQS 콘솔에서 DLQ 메시지를 소스 큐로 직접 재전송할 수 있게 됐다. - 2023년에는 SDK와 CLI에서도 다음 API를 사용할 수 있게 됐다. - `StartMessageMoveTask`: 메시지 이동 작업 시작 - `CancelMessageMoveTask`: 이동 작업 취소 - `ListMessageMoveTasks`: 이동 작업 목록 조회 - 같은 해 FIFO 큐에도 redrive 기능이 지원됐다. - 운영 중 실패한 메시지를 수동으로 재처리하거나 별도 개발 없이 복구할 수 있다. ## 메시지 처리 성능과 연동성 개선 - 2023년 AWS SDK에 JSON 프로토콜 지원이 추가됐다. - 5KB 페이로드 기준 종단 간 처리 지연을 최대 23% 줄이고, 클라이언트의 CPU·메모리 사용량도 낮췄다. - SQS 콘솔에서 EventBridge Pipes와 큐를 직접 연결할 수 있게 됐다. - 별도의 통합 코드를 작성하지 않고도 큐 메시지를 다양한 AWS 서비스 대상으로 라우팅할 수 있다. ## 대용량 메시지와 페이로드 확장 - 2024년 Python용 Extended Client Library가 제공됐다. - 최대 2GB 크기의 메시지를 Amazon S3에 저장하고, SQS에는 해당 데이터의 참조 정보만 전달할 수 있다. - 2025년에는 표준 큐와 FIFO 큐의 최대 메시지 크기가 256KiB에서 1MiB로 증가했다. - AWS Lambda의 SQS 이벤트 소스 매핑도 이 새로운 페이로드 크기를 지원하도록 업데이트됐다. ## 멀티테넌트 환경을 위한 공정한 처리 - 2025년 표준 큐에 fair queues가 도입됐다. - 메시지를 보낼 때 메시지 그룹 ID를 포함하면 특정 테넌트가 큐를 독점하는 ‘시끄러운 이웃(noisy neighbor)’ 문제를 완화할 수 있다. - 소비자 측 코드를 변경하지 않고도 한 테넌트의 대량 메시지가 다른 테넌트의 처리 지연을 유발하는 상황을 줄일 수 있다. ## AI 시스템으로 확장되는 SQS의 활용 - SQS의 기본 패턴은 AI 워크로드에도 적용된다. - 활용 사례는 다음과 같다. - 대규모 언어 모델 요청을 큐에 저장해 추론 요청량 조절 - 추론 처리량을 소비자 수와 처리 속도에 맞춰 관리 - 독립적으로 동작하는 AI 에이전트 간 작업과 통신 조정 - AI 서비스가 일시적으로 느려지거나 중단돼도 요청을 큐에 보관해 전체 시스템의 안정성을 유지할 수 있다. 실무에서는 서비스 간 직접 호출이 장애 전파나 트래픽 급증 문제를 일으키는 경우 SQS를 우선 검토할 수 있다. 순서 보장과 중복 처리 방지가 필요하면 FIFO 큐를, 실패 메시지 복구가 중요하면 DLQ와 redrive 기능을 함께 설계하는 것이 좋다.

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

분산 시스템AWSamazon-s3amazon-sqs+4

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

Meerkat 소개 - 글로벌 합의에 대한 실험

Cloudflare는 330곳이 넘는 글로벌 데이터센터에서 동일한 컨트롤 플레인 상태를 강한 일관성으로 읽고 수정할 수 있는 합의 서비스를 개발하고 있다. 기존 Raft는 리더 장애와 타임아웃 때문에 광역 네트워크에서 쓰기 가용성이 중단될 수 있어, Cloudflare는 모든 복제본이 쓰기에 참여하고 타임아웃으로 진행이 멈추지 않는 QuePaxa 기반의 Meerkat을 만들었다. Meerkat은 아직 실험 단계이며, 우선 데이터베이스 리더십이나 리소스 배치처럼 작은 규모의 내부 컨트롤 플레인 상태를 관리하는 데 사용될 예정이다. ## 글로벌 컨트롤 플레인 데이터의 필요성 - Cloudflare의 여러 서비스는 전 세계 데이터센터에 분산된 머신에서 동일한 제어 상태를 읽고 수정해야 한다. - 대표적인 컨트롤 플레인 데이터는 다음과 같다. - AI 모델 인스턴스 등 리소스의 배치 정보 - 데이터베이스에서 쓰기를 수행할 수 있는 머신을 나타내는 리더십 정보 - 네트워크 단절, 데이터센터 장애, 서버 중단, 큐 포화, 케이블 절단 등 인터넷 환경의 불확실성에도 시스템이 동작해야 한다. - 따라서 다음 두 조건을 동시에 만족하는 데이터 시스템이 필요하다. - 여러 클라이언트가 서로 모순되지 않는 상태를 읽는 강한 일관성 - 일부 머신이나 네트워크 링크가 실패해도 읽기와 쓰기가 가능한 장애 내성 ## 선형화 가능성으로 대표되는 강한 일관성 - 일관성 모델은 동시 읽기와 쓰기에서 시스템이 허용하는 동작 범위를 정의한다. - 약한 일관성에서는 여러 노드에 도착한 쓰기 순서가 재배열될 수 있다. - 더 강한 모델에서는 쓰기 순서는 유지되더라도 읽기가 서로 다른 시점의 값을 볼 수 있다. - 가장 강한 모델인 **선형화 가능성(linearizability)** 은 실제 시간 순서에 맞춰 연산이 실행된 것처럼 보이게 한다. - 어떤 쓰기가 완료된 뒤의 읽기는 반드시 그 쓰기 결과를 볼 수 있다. - 프로그래머는 분산 저장소를 단일 스레드 머신의 메모리처럼 추론할 수 있다. - Meerkat 위에 구축되는 키-값 저장소는 선형화 가능성뿐 아니라 직렬성(serializability)도 제공할 예정이며, 직렬성에 대한 자세한 내용은 후속 글에서 다룬다. ## 요구되는 장애 내성 - 시스템은 전체 머신 수가 `2f + 1`일 때 최대 `f`개의 장애를 감당하는 것을 목표로 한다. - 다음 조건이 유지되면 어느 데이터센터의 클라이언트에서도 읽기와 쓰기가 가능해야 한다. - 전체 머신의 과반수가 살아 있고 서로 통신할 수 있다. - 클라이언트가 과반수의 활성 머신과 연결된 머신 하나에 접속할 수 있다. - 이 조건은 단일 머신 장애나 하나의 네트워크 링크 성능 저하만으로 전체 시스템의 가용성이 떨어지지 않아야 함을 의미한다. - 시스템은 다음과 같은 장애에서도 올바른 상태를 유지해야 한다. - 머신 충돌 및 재시작 - 네트워크 장애와 지연 - 데이터센터 장애 - 네트워크 품질 저하 - 한편 공격자가 악의적으로 잘못된 메시지를 보내는 **비잔틴 장애**는 Raft와 마찬가지로 처리 대상에서 제외한다. - 안전성의 핵심은 최신 상태를 가진 두 머신이 서로 다른 세계를 인식하지 않도록 하는 것이다. 예를 들어 한 머신이 `key1=1`, 다른 머신이 `key1=2`라고 판단하는 상황을 허용하지 않는다. ## Raft가 광역 네트워크에서 겪는 한계 - Raft는 한 번에 하나의 리더만 쓰기를 수행할 수 있도록 한다. - 리더가 충돌하거나 네트워크 지연으로 사실상 접근 불가능해지면 다음 과정이 필요하다. - 다른 복제본이 리더의 실패를 타임아웃으로 감지 - 새로운 리더 선출 - 새 리더가 활동을 시작할 때까지 쓰기 중단 - 인터넷 전반에 걸친 Cloudflare 네트워크에서는 지연 시간이 일정하지 않기 때문에 타임아웃 값을 적절히 설정하기 어렵다. - 타임아웃이 너무 짧으면 정상적인 지연을 장애로 오인하고, 너무 길면 실제 장애 이후 복구가 늦어진다. - Cloudflare는 리더를 사용할 수 없어 합의 기반 시스템이 중단된 여러 장애를 경험했으며, 이것이 새로운 합의 서비스 개발의 배경이 되었다. ## QuePaxa 기반 Meerkat - Meerkat은 EPFL 연구진이 2023년에 발표한 합의 알고리즘 **QuePaxa**를 기반으로 한다. - Raft와 달리 QuePaxa에서는 모든 복제본이 항상 쓰기를 수행할 수 있다. - 특정 리더가 장애를 일으켰을 때 새 리더 선출을 기다리느라 전체 진행이 멈추지 않는다. - 타임아웃 때문에 합의 진행이 중단되지 않는 특성은 지연이 불규칙한 광역 네트워크에 적합하다. - Meerkat은 합의 로그를 제공하고, 그 위에 다음과 같은 애플리케이션을 구축한다. - 트랜잭션 키-값 저장소 - 분산 임대(lease) 및 잠금 시스템 - 데이터베이스 리더십 관리 - Cloudflare는 이를 글로벌 규모에서 산업적으로 배포하는 최초의 QuePaxa 사례가 될 것으로 보고 있다. ## 현재 개발 단계와 적용 범위 - Meerkat은 아직 개발 중인 실험적인 서비스다. - 초기에는 대규모 사용자 데이터가 아니라 작은 컨트롤 플레인 상태를 관리하는 데 집중한다. - 즉시 외부 공개 서비스로 제공하지 않고 Cloudflare 내부 전용으로 운영할 계획이다. - 이번 글은 Meerkat의 배경과 요구사항을 소개하고, 이후 합의 로그와 그 위에 구축되는 저장소 및 리스 시스템에 관한 후속 글의 기반을 마련한다. Meerkat의 핵심 설계 방향은 리더 장애와 고정된 타임아웃에 의존하지 않는 합의를 통해, 글로벌 네트워크에서도 선형화 가능한 데이터와 높은 쓰기 가용성을 함께 확보하는 것이다. 다만 실제 운영에서는 과반수 연결 조건과 비잔틴 장애를 처리하지 않는다는 한계를 함께 고려해야 한다.

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

분산 시스템fault-tolerancekey-value-storequepaxa+4

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

대규모 환경에서 데이터 완전성을 측정하는 방법

고객의 대시보드·알림·AI 에이전트가 올바르게 작동하려면 Datadog에 유입된 모든 텔레메트리 데이터가 완전하게 전달되어야 한다. Datadog은 수백 개의 분산 파이프라인과 고객별 경로를 실시간으로 추적하기 위해 파이프라인을 세그먼트로 나누고, 각 payload의 생성과 확인(acknowledgment)을 비교한다. 이 방식은 중복·순서 뒤바뀜·지연 데이터가 존재하는 환경에서도 세그먼트별 문제 위치와 전체 파이프라인의 완전성을 계산하도록 설계되었다. ## Datadog에서 데이터 완전성의 의미 - 완전한 데이터란 Datadog에 들어온 모든 payload가 고객에게 제공되는 상태다. - 대상 payload에는 다음과 같은 텔레메트리 데이터가 포함된다. - 메트릭 데이터 포인트 - 로그 - 트레이스 - 기타 수집 데이터 - 완전성은 전역 단위가 아니라 **고객별로** 판단해야 한다. - 고객마다 파티셔닝, 격리 전략, 트래픽 패턴이 다르다. - 따라서 동일한 리전에서도 데이터가 통과하는 경로가 매우 다양하다. - 시스템은 데이터가 누락되었는지뿐 아니라 다음도 즉시 설명해야 한다. - 어느 구간에서 문제가 발생했는가 - 어떤 서비스가 비정상인가 - 문제가 고객에게 영향을 주었는가 - 진단 결과는 운영자가 수 초 안에 대응하거나 자동화된 시스템이 조치하는 데 사용된다. ## 워터마크 방식의 한계 - 초기에는 Flink 같은 스트리밍 시스템의 워터마크 방식을 고려했다. - 데이터가 일정 시간 안에 도착한다고 가정하고 워터마크를 전진시킨다. - 특정 임계점을 넘으면 해당 시점까지 데이터가 완전하다고 판단한다. - 그러나 Datadog 환경에서는 고객이 임의로 지연된 데이터를 보낼 수 있다. - 또한 다음과 같은 특수 상황이 워터마크를 신뢰하기 어렵게 만든다. - 파이프라인 내부의 루프 - 트래픽 재생 - 예측하기 어려운 데이터 지연 - 따라서 데이터 도착 시점만으로 전체 파이프라인의 완전성을 판단하는 방식은 필요한 보장을 제공하지 못했다. ## 파이프라인을 세그먼트로 분할 - Datadog은 전체 파이프라인을 여러 개의 작은 세그먼트로 나누어 추적한다. - 예를 들어 다음과 같은 흐름이 있을 수 있다. - intake → Kafka → processing → Kafka → router - 각 서비스 내부와 서비스 간 연결을 별도의 세그먼트로 정의한다. - `intake-in → intake-out` - `intake-out → processing-in` - 각 세그먼트에서 다음을 독립적으로 측정한다. - 세그먼트에 들어온 payload 수 - 세그먼트에서 나간 payload 수 - 이 구조의 장점은 다음과 같다. - 누락이 발생한 위치를 구체적으로 찾을 수 있다. - 개별 세그먼트 결과를 합쳐 end-to-end 완전성을 계산할 수 있다. - 파이프라인에 분기 경로가 추가되거나 제거되어도 전체 시스템을 재정의할 필요가 적다. ## 생성 이벤트와 확인 이벤트로 payload 추적 - payload가 세그먼트에 들어오면 `create` 이벤트를 기록한다. - payload가 세그먼트를 빠져나오면 동일한 식별자에 대한 `acknowledgment` 이벤트를 기록한다. - 두 이벤트의 수를 비교해 세그먼트에서 데이터가 유실되었는지 판단한다. - 재시도와 중복 처리를 위해 모든 payload에 고유 식별자를 부여한다. ### 시간 버킷을 이용한 멱등성 - 분산 시스템에서는 이벤트가 중복되거나 순서가 뒤바뀐 채 도착할 수 있다. - 이를 처리하기 위해 완전성을 payload가 Datadog에 처음 들어온 시점의 **시간 버킷** 단위로 계산한다. - 고객 시스템의 시계가 아니라 Datadog이 관리하는 타임스탬프를 사용한다. - 각 버킷에서 payload의 세그먼트별 상태를 관리한다. - 생성됨 - 확인됨 - 생성 이벤트보다 확인 이벤트가 먼저 도착함 - 같은 버킷에서 동일한 식별자의 `create` 또는 `acknowledgment`가 반복되면 기존 상태를 확인하고 중복 이벤트를 무시한다. - 이 방식은 별도의 분산 조정 없이도 카운트를 멱등적으로 유지한다. ## 세그먼트 비율로 전체 완전성 계산 - 각 세그먼트의 완전성은 다음 비율로 정의된다. `세그먼트 완전성 = 세그먼트를 빠져나간 payload 수 ÷ 세그먼트에 들어온 payload 수` - 순차적으로 연결된 파이프라인에서는 각 세그먼트의 완전성 비율을 곱한다. - 예를 들어 두 세그먼트의 완전성이 각각 98%, 96%라면 전체 완전성은 다음과 같다. `98% × 96% = 94%` ### 병렬 분기 처리 - 병렬 분기를 단순히 하나의 파이프라인으로 취급하면 문제가 생긴다. - 예를 들어 APM 트레이스가 다음 두 서비스로 동시에 전달될 수 있다. - 오류율·요청 수를 계산하는 서비스 - 지연 시간 분포를 계산하는 서비스 - 한 분기가 늦게 처리되면 다른 분기에서 이미 사용 가능한 데이터까지 전체적으로 불완전한 것처럼 보일 수 있다. - Datadog은 병렬 분기를 **데이터 처리량에 비례한 가중 평균**으로 결합한다. - 각 분기의 기여도를 해당 분기가 처리하는 payload 양에 따라 산정한다. - 데이터가 많은 분기는 전체 결과에 더 큰 영향을 준다. - 예시에서는 한 분기가 98%와 96%의 두 세그먼트를 거쳐 94% 완전성을 보이고, 다른 분기는 100%를 처리한다. - 이후 각 분기의 처리량을 기준으로 가중치를 적용해 전체 파이프라인 완전성을 계산한다. ## 실용적인 결론 대규모 분산 수집 시스템에서는 전체 파이프라인을 한 번에 관찰하기보다, payload의 이동을 세그먼트별로 계측하는 편이 문제 위치와 고객 영향을 더 정확히 파악할 수 있다. 특히 고유 식별자, 시간 버킷, 멱등적인 상태 추적을 함께 사용하면 재시도와 지연 데이터가 많은 환경에서도 실시간 완전성 검증이 가능하다.

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

분산 시스템옵저버빌리티애플리케이션 성능 모니터링Apache Kafka+3

cloudflare·2026년 6월 12일·4분 읽기큐레이션 요약

보안 인사이트 확장: 글로벌 스캔 처리 역량을 10배 향상한 방법

Security Insights는 기존 주 1~2회에 그치던 보안 검사를 모든 계정에 더 자주 적용하기 위해 처리량을 초당 10건에서 100건으로 약 10배 높여야 했다. Cloudflare는 Kafka 소비 병렬화, 느린 작업 분리, Postgres 대량 삽입 최적화, 지역 간 네트워크 지연 분석을 통해 스캔 처리량을 10배 이상 향상시켰다. 그 결과 수백만 고객에게 보안 인사이트를 제공하고 전체 고객의 검사 주기를 두 배로 늘릴 수 있었다. ## 기존 보안 검사 구조와 확장 과제 - 스케줄러가 검사 시점이 된 계정과 Zone을 감지한다. - 검사 작업을 Apache Kafka 메시지로 발행하고, 여러 Go 기반 checker 마이크로서비스가 메시지를 나누어 처리한다. - 각 checker는 특정 자산이나 설정을 검사한 뒤 내부 API로 결과를 전송한다. - API는 결과를 Postgres 데이터베이스에 저장한다. - 기존 시스템은 다음 문제를 겪고 있었다. - 검사가 주 1~2회만 수행되어 위험이 최대 2주간 탐지되지 않을 수 있었다. - 많은 무료 요금제 계정에서 자동 검사가 선택 사항이라 검사 자체가 이뤄지지 않았다. - Kafka backlog 증가, API 타임아웃, 프로세스 충돌이 발생했다. - 모든 계정에 자동 검사를 적용하고 검사 빈도를 높이려면 평균 처리량을 초당 10건에서 100건으로 늘려야 했다. ## Kafka 파티션의 병목 - Kafka는 일반적인 큐와 달리 파티션 내 메시지를 순서대로 소비하고 처리한다. - 하나의 consumer group에서는 파티션당 활성 consumer를 하나만 둘 수 있다. - 따라서: - 처리 시간이 긴 메시지 하나가 뒤따르는 메시지의 처리를 막을 수 있다. - checker별 병렬 소비자 수는 Kafka 파티션 수에 제한된다. - 파티션을 추가하면 확장할 수 있지만, 여러 서비스가 공유하는 Kafka 브로커의 자원 사용량이 증가하므로 최후의 수단으로 남겨두었다. ## 배치 기반 병렬 처리 - 메시지를 하나씩 처리하던 checker를 배치 단위로 소비하도록 변경했다. - 배치 안의 각 메시지는 별도의 Go goroutine에서 동시에 처리했다. - 이 방식의 trade-off는 다음과 같다. - 배치 처리 중 프로세스가 중단되면 이미 처리한 작업을 다시 수행해야 할 수 있다. - 동시에 처리하는 작업이 늘어 메모리 사용량이 증가한다. - 검사 시스템에서는 재처리 비용과 메모리 증가가 감당 가능한 수준이었기 때문에 병렬 처리를 선택했다. ## 느린 작업으로 인한 Head-of-Line Blocking 제거 - 일부 계정이나 Zone은 자산 수가 많아 검사에 수초가 아니라 수분 또는 수시간이 걸릴 수 있었다. - 이런 느린 메시지가 일반 메시지 앞에 있으면 Kafka 소비가 멈춰 빠른 작업까지 지연됐다. - 해결책으로 checker와 consumer group을 두 개의 처리 경로로 분리했다. - **Fast lane**: 빠르게 처리할 수 있는 일반 메시지 담당 - **Slow lane**: 처리 시간이 긴 메시지 전담 - 메시지의 예상 처리 시간을 빠르게 판단하고, fast lane이 느린 메시지를 만나면 건너뛰도록 했다. - 그 결과 느린 작업은 전용 자원을 사용하고, 빠른 작업은 지연 없이 계속 처리할 수 있었다. ## Postgres 대량 저장 최적화 - 기존 API는 인사이트 하나마다 별도의 `INSERT ... ON CONFLICT DO UPDATE` 쿼리를 실행했다. - 한 요청에 최대 50만 개의 인사이트가 포함될 수 있어, 최악의 경우 50만 번의 데이터베이스 왕복과 쿼리 실행이 발생했다. - 처음에는 임시 테이블에 `COPY`하는 Postgres 표준 대량 삽입 방식을 시도했지만, Postgres 시스템 테이블의 bloat가 증가하는 문제가 나타났다. - 최종적으로 입력 규모에 따른 하이브리드 방식을 채택했다. - 작은 데이터셋: `UNNEST`를 사용해 빠르게 삽입 - 큰 데이터셋: `COPY`를 사용해 대량 삽입 - 이 방식은 대규모 데이터에는 수초 수준의 처리 시간을, 소규모 데이터에는 밀리초 수준의 빠른 처리를 제공했다. ## 지역 간 지연으로 발생한 API 타임아웃 - 확장 과정에서 다음 현상이 관찰됐다. - 클라이언트 타임아웃 증가 - checker 처리 시간의 20~90%가 단일 API 호출에 소요 - 대량 검사 시 초기 처리량은 높지만 시간이 지나며 감소 - 원인은 API와 데이터베이스 간 네트워크 지연이었다. - 주 데이터베이스는 미국 오리건주 포틀랜드에 위치했다. - API는 포틀랜드와 네덜란드 암스테르담에서 active-active로 운영됐다. - 포틀랜드 API 호출은 평균 10ms였지만, 암스테르담 인스턴스에서는 거의 3초가 걸렸다. - 암스테르담 API가 데이터베이스 연결을 오래 점유하면서 checker의 클라이언트 연결 풀이 고갈됐다. - 연결을 기다리는 요청이 타임아웃되고, 암스테르담 API에 연결된 Kafka 파티션만 지속적으로 지연됐다. - 결국 API의 단순한 지역 분산이 전체 Kafka 소비 처리량의 불균형과 lag를 유발할 수 있음을 확인했다. ## 실용적인 결론 대규모 이벤트 처리 시스템에서는 소비자 수를 늘리는 것만으로 충분하지 않다. Kafka의 파티션 제약을 고려한 병렬 처리, 느린 작업의 별도 격리, 대량 데이터베이스 작업의 배치화, 데이터베이스와 API 간 지역 지연 관리까지 함께 최적화해야 안정적인 처리량 확장이 가능하다. 특히 분산 배포 환경에서는 평균 latency뿐 아니라 연결 풀 점유 시간과 파티션별 처리 편차까지 함께 측정해야 한다.

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

분산 시스템PostgreSQLApache KafkaAPI+4

google·2026년 6월 12일·4분 읽기큐레이션 요약

사용하지 않는 휴대폰으로 만드는 저탄소 컴퓨팅 플랫폼

사용이 끝난 스마트폰의 메인보드를 모아 클러스터로 구성하면, 새 서버 제조를 줄이면서 저비용·저탄소 클라우드 컴퓨팅 플랫폼으로 재활용할 수 있다. UC 샌디에이고와 Google은 2,000대의 Pixel 스마트폰으로 데이터센터를 구축해 교육·연구용 컴퓨팅을 제공할 계획이다. 이 방식은 스마트폰의 제한된 메모리와 코어 수에 맞는 작업을 선별하고, 대규모 배포에서 소비자용 하드웨어의 신뢰성을 검증하는 것을 목표로 한다. ## 컴퓨팅의 탄소 배출과 스마트폰 재활용 - 컴퓨팅의 탄소발자국은 크게 두 가지다. - **운영 탄소**: 기기 사용 중 소비되는 전력에서 발생하는 배출량 - **내재 탄소**: 하드웨어 제조와 원자재 추출 과정에서 발생하는 배출량 - 전력 효율 향상과 재생에너지 사용으로 운영 탄소는 줄일 수 있지만, 제조 과정의 내재 탄소는 해결이 더 어렵다. - 사람들은 평균 4년마다 스마트폰을 교체하지만, 교체된 기기에도 프로세서, 가속기, 메모리, 저장장치 등 핵심 컴퓨팅 기능이 남아 있다. - 기존 스마트폰을 재사용하면 새 하드웨어 생산과 추가적인 원자재 채굴을 피할 수 있다. ## 스마트폰과 서버의 성능 차이 - 2023년형 Pixel Fold의 고성능 코어는 SPEC 벤치마크에서 일부 최신 데이터센터 서버의 단일 코어 성능을 웃돈다. - 다만 스마트폰은 서버보다 다음과 같은 제약이 있다. - 코어 수가 적고 CPU 구성이 이기종임 - 메모리가 약 8~12GB로 제한됨 - 서버처럼 대규모 멀티스레드 처리나 대용량 메모리를 제공하지 못함 - 따라서 하나의 스마트폰에 들어갈 수 있거나, 여러 기기로 분할할 수 있는 작업이 적합하다. - 벤치마크상 약 25~50대의 스마트폰이 현대적인 서버 한 대에 해당하는 성능을 낼 수 있다. ## 스마트폰을 데이터센터 하드웨어로 개조 - 소비자용 스마트폰을 그대로 데이터센터에 배치하면 비효율적이고 위험하다. - 디스플레이, 배터리, 카메라, 케이스 등 서버에 필요 없는 부품이 공간을 차지함 - 특히 배터리는 데이터센터 환경에서 장시간 사용하기에 적합하지 않을 수 있음 - 따라서 메인보드만 분리해 클러스터에 사용한다. - 메인보드는 스마트폰 내재 탄소의 약 50%를 차지하는 가장 중요한 부품이므로, 이를 재사용하는 것이 환경적 효과가 크다. - Android 기반의 모바일 사용자 공간은 범용 Linux 배포판으로 교체한다. - 클라우드 작업에 필요한 프로그래밍 환경을 제공함 - 모바일 기기용 보호 기능을 제거하거나 조정할 수 있음 - 예를 들어 메모리 부족 시 애플리케이션을 종료하는 ‘Low Memory Killer’의 영향을 줄일 수 있음 - 컨테이너화된 애플리케이션을 Kubernetes로 관리해 25~50대 단위의 자기관리형 클러스터를 구성한다. ## 교육·연구용 저탄소 클라우드 - 대학에서 사용하는 Jupyter 환경, 과제 채점 시스템, 병렬 계산 수업용 애플리케이션 상당수는 스마트폰 한 대 또는 소규모 클러스터로 처리할 수 있다. - 일반적인 과제 채점 백엔드는 AWS t3.micro 수준인 2 vCPU·1GB 메모리 인스턴스에서도 실행된다. - 20대 스마트폰 클러스터를 이용한 실험에서: - 75명 이상 수강하는 수업의 최대 과제 제출량을 처리함 - 일반적인 AWS 백엔드보다 낮은 채점 지연 시간을 기록함 - 약 50초가 걸리는 CPU 집약적 행렬 곱셈 과제도 처리 가능했음 - 2,000대 규모의 클러스터는 약 50대의 서버에 해당하는 컴퓨팅 자원을 제공하고, 동시에 약 100개 수업을 지원할 수 있을 것으로 예상된다. - 2026년 가을 전체 시스템 운영을 시작할 계획이다. ## 대규모 운영에서 검증할 과제 - 소비자용 스마트폰 메인보드를 장기간 데이터센터 부하로 사용할 때의 신뢰성을 검증해야 한다. - 다수 기기의 장애를 감지하고 작업을 재분배하는 클러스터 관리가 중요하다. - 제한된 메모리와 이기종 코어 구조에 맞도록 애플리케이션을 설계해야 한다. - 이 프로젝트는 실제 교육·연구 서비스를 제공하는 동시에 스마트폰 기반 컴퓨팅의 확장성과 지속 가능성을 시험하는 테스트베드 역할을 한다. 사용이 끝난 스마트폰은 서버 전체를 대체하기보다는 교육, 과제 채점, 소규모 웹 서비스처럼 자원 요구량이 제한적인 작업에 재활용하는 것이 현실적이다. 특히 메인보드 재사용과 컨테이너·Kubernetes 기반 클러스터 관리를 결합하면 비용 절감과 제조 탄소 감축을 동시에 달성할 가능성이 있다.

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

분산 시스템쿠버네티스Android클라우드 컴퓨팅+4

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

불은 꺼지고 시스템은 켜진다: 즉각적인 정전 대비 태세 검증

Meta는 데이터센터의 무경고 전력 상실에 대비하기 위해 **Instantaneous PowerLoss Storm**이라는 새로운 재해 대응 테스트 체계를 도입했다. 기존 시스템에 방어 심층화 전략을 적용하고, 지역 전체의 전원을 실제로 차단하는 단계적 검증을 통해 서비스·데이터·시설의 복원력을 확인했다. 목표는 한 지역 전체의 전력 상실을 개별 장애 도메인 손실만큼 안정적으로 처리하는 것이다. ## 무경고 재해에 대비한 새로운 테스트 패러다임 - 기존의 허리케인, 산불, 전력·네트워크 장애 대응책은 사전 경보가 있을 때 효과적이다. - 그러나 순간적인 전력 상실처럼 전혀 예고되지 않는 재해는 기존 전략만으로 대응하기 어렵다. - Instantaneous PowerLoss Storm은 Meta의 기존 Disaster Readiness(재해 대비) “Storm” 프로그램에 추가된 최종 방어선이다. - 알려진 위험뿐 아니라 새롭게 등장하거나 아직 발견되지 않은 위험까지 검증 대상으로 삼는다. ## 데이터센터 전 계층에 적용한 방어 심층화 - 전력 상실 내성을 데이터센터의 전체 스택에 내장했다. - 기계·전기 설비 - 서버 랙 - 스토리지와 컴퓨트 - Twine 컨테이너 오케스트레이터 - 랙 전원이 끊겨도 배터리와 Power Loss Siren(PLS)을 이용해 메모리 데이터를 보존할 수 있도록 했다. - Twine 서비스 간에는 지역 전체에서 동작하는 비동기 신호 체계인 Unavailability Event(UE)를 구축했다. - 기존 기능은 단일 데이터센터의 장애 도메인에서 검증되어 있었지만, 여러 데이터센터가 연결된 지역 전체 장애에서는 다음 문제가 추가로 발생했다. - 장애 규모가 일반 장애 도메인보다 약 50~60배 큼 - 서비스 복제본 배치 문제 - 수백만 개 서비스의 동시 재시작과 자동 발견 - 전원이 꺼진 지역을 스스로 부팅해야 하는 문제 ## 전체 지역 부팅과 순환 의존성 문제 - Twine의 Scheduler, Allocator, Broker, Zelos 같은 제어 플레인 서비스는 다른 서비스를 시작하기 위한 필수 구성요소다. - 전체 지역이 동시에 부팅될 때 제어 플레인 서비스끼리 서로를 필요로 하는 순환 의존성, 즉 “ouroboros” 문제가 발생할 수 있다. - 이를 해결하기 위해: - 핵심 시작 의존성을 식별했다. - CI/CD에서 Belljar 테스트를 지속적으로 실행해 의존성 문제를 조기에 발견했다. - 예기치 않은 순환 의존성을 끊을 수 있도록 Twine recovery kit을 제공했다. - 이 복구 키트는 Twine 자체를 구동하는 서비스에 대한 “jumpstart” 역할을 한다. - Belljar, Twrko, recovery kit을 함께 사용해 지역 전체 부팅 시 발생할 수 있는 순환 의존성 위험을 줄였다. ## 제어 플레인을 종료시키는 ‘부메랑’ 문제 - UE는 서비스 종료와 복구를 조정하는 신호지만, 이 신호를 생성·전달하는 제어 플레인 자체가 UE에 의해 종료될 수 있었다. - 그러면 일부 서비스가 종료 신호를 받지 못한 채 고아 상태로 남을 수 있다. - 특정 서비스를 UE 전달 대상에서 제외하는 복잡한 방식 대신, 전력 관련 UE를 제어 플레인 서비스가 무시하도록 설계했다. - 단순한 예외 처리로 시스템 복잡도와 유지보수 부담을 낮췄다. ## 신뢰성과 개발 속도 사이의 절충 - 순간 장애에 완벽히 대응하려는 설계는 과도한 엔지니어링이나 정상 운영 중 오탐 위험을 만들 수 있다. - 따라서 반드시 방지해야 할 영향과 감수할 수 있는 영향을 구분했다. - 반드시 방지해야 하는 영향: - 스토리지·데이터베이스 데이터 손실 - 데이터센터 기계·전기 설비의 영구 손상 - 단일 지역을 넘어 지속되는 광범위한 장애 - 허용 가능한 영향: - 일시적인 서비스 오류 - 사전에 정한 한도 내의 랙 장애 - 서비스 라우팅 테이블의 제한된 최신성 저하 - 지역 장애 감지의 일시적인 지연 - 사후 복구가 어렵거나 합리적인 MTTR 내에 완화할 수 없는 문제를 허용 범위 밖으로 정의했다. ## 단계적 검증으로 위험과 폭발 반경 축소 - 전원을 직접 차단하는 테스트는 큰 위험을 동반하므로 점진적인 검증 방식을 택했다. - 검증 단계는 다음과 같다. - 신규·사전 운영 지역에서 의존성 등 독립적인 문제를 먼저 테스트 - 운영 지역을 복제한 shadow 지역에서 실험 - 가장 작고 새로운 운영 지역에서 실제 전력 차단 수행 - 이후 스토리지, AI, 데이터 웨어하우스가 위치한 대규모 운영 지역까지 확대 - 최종 단계의 전력 차단 훈련을 Instantaneous PowerLoss Storm이라고 명명했다. ## 실제 Storm 실행 방식 - 전체 지역에 전력 공급 장애를 주입해 즉시 전원을 차단한다. - 실제 장애처럼 보이도록 테스트 전에 선제적인 보호 조치를 최소화했다. - 현실적인 사고 상황의 MTTR을 반영한 뒤, 영향을 받은 지역을 전역 컨트롤러와 스케줄러에서 격리하는 “drain” 조치를 수행했다. - 반복적인 훈련을 통해 인프라와 엔지니어가 지역 전체 장애를 개별 장애 도메인 장애처럼 처리하도록 개선하고 있다. ## 실용적인 결론 대규모 인프라의 무경고 장애 대비에는 단일 복구 기능보다 시설부터 오케스트레이터까지 이어지는 방어 심층화가 중요하다. 특히 전체 시스템 부팅 시의 순환 의존성과 제어 플레인 보호를 사전에 검증하고, 작은 환경에서 시작해 실제 운영 지역으로 단계적으로 확대하는 방식이 안전성과 개발 속도를 함께 확보하는 현실적인 접근이다.

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

분산 시스템CI/CDfault-tolerancedisaster-recovery+3

netflix·2026년 5월 29일·5분 읽기큐레이션 요약

사일로에서 서비스 토폴로지로: 넷플릭스가 실시간 서비스 맵을 구축한 이유

넷플릭스는 수천 개의 마이크로서비스 간 실제 의존성을 실시간으로 보여주는 ‘Service Topology’를 구축했다. 기존의 지표·로그·트레이스는 시스템의 일부만 보여주므로, 장애 원인과 영향 범위를 파악하려면 엔지니어가 정보를 직접 조합해야 했다. Service Topology는 여러 데이터 소스로 네트워크와 애플리케이션 의존성 그래프를 만들고, 이를 통합해 빠르게 탐색할 수 있도록 하는 것이 핵심이다. ## 분산 시스템에서 의존성 파악이 어려운 이유 - 넷플릭스의 하나의 재생 요청도 인증, 추천, 인코딩 선택, 재생 최적화 등 수많은 서비스 호출을 발생시킨다. - 장애 상황에서 엔지니어가 즉시 확인해야 하는 질문은 다음과 같다. - 어떤 서비스가 서로 의존하는가? - 특정 서비스 장애나 점검의 영향 범위는 어디까지인가? - 문제가 상위 의존 서비스에서 시작됐는가, 현재 서비스가 다른 서비스로 전파하고 있는가? - 기존 관측 도구의 한계: - 메트릭은 성능 저하나 오류 같은 증상을 보여준다. - 로그는 개별 서비스의 동작을 보여준다. - 트레이스는 특정 요청의 흐름을 보여준다. - 그러나 시스템 전체의 지속적인 서비스 연결 구조를 한눈에 보여주지는 못한다. - 여러 도구의 정보를 엔지니어가 머릿속으로 조합해야 하므로, 장애 대응이 느리고 오류가 발생하기 쉽다. ## 실시간 서비스 맵이 필요한 배경 - 넷플릭스는 수천 개의 마이크로서비스와 수백 개의 엔지니어링 팀으로 운영된다. - 라이브 프로그램과 광고 지원 요금제 등 새로운 기능이 추가되면서 장애 조사와 모니터링의 신속성이 더욱 중요해졌다. - 특히 라이브 이벤트는 긴 장애 분석을 기다릴 수 없기 때문에 실시간에 가까운 의존성 정보가 필요하다. - 엔지니어 지원 요청을 분석한 결과, 다음과 같은 의존성 관련 질문이 반복적으로 제기됐다. - 상·하위 의존 서비스는 무엇인가? - 장애가 내 서비스 문제인가, 의존 서비스 문제인가? - 서비스를 중단하면 어떤 서비스가 영향을 받는가? - 메트릭에서 특정 서비스가 `Unknown`으로 표시되는 이유는 무엇인가? - 최근 호출 경로가 어떻게 바뀌었으며, 그것이 현재 문제와 관련 있는가? ## 기존 접근 방식에서 얻은 교훈 넷플릭스는 외부 그래프 데이터베이스와 상용 플랫폼을 검토하고, 다양한 저장 기술과 데이터 모델로 내부 프로토타입을 만들며 접근 방식을 발전시켰다. - **실시간성이 중요하다** - 하루 전 또는 몇 시간 전의 토폴로지는 자주 배포되는 환경에서는 이미 오래된 정보다. - 서비스 배포와 트래픽 변화에 따라 토폴로지가 거의 실시간으로 갱신되어야 한다. - **대규모 환경에서는 확장성이 핵심이다** - 소규모 환경에서 동작하는 저장소와 그래프 모델도 넷플릭스의 서비스 수와 트래픽 규모에서는 한계에 도달한다. - **기존 관측 생태계와의 통합이 필요하다** - 엔지니어가 새로운 도구와 작업 방식을 별도로 배워야 해서는 안 된다. - 기존 메트릭, 로그, 트레이스와 자연스럽게 연결되어야 한다. - **데이터 품질이 중요하다** - 누락되거나 잘못된 의존성 정보는 정보가 없는 것보다 위험하다. - 장애 상황에서 잘못된 원인이나 영향 범위를 판단하게 만들 수 있기 때문이다. - **단일 데이터 소스만으로는 부족하다** - 네트워크 연결 정보에는 애플리케이션 수준의 의미가 부족하다. - 애플리케이션 메트릭은 계측된 서비스만 포함할 수 있다. - 따라서 여러 관점의 데이터를 결합해야 한다. ## Service Topology의 요구사항 넷플릭스가 구축하려 한 것은 정적인 아키텍처 다이어그램이 아니라, 운영 상태를 계속 반영하는 ‘살아 있는 지도’였다. - 서비스 배포, 트래픽 변화, 신규 의존성 생성과 기존 의존성 제거를 실시간에 가깝게 반영한다. - 호출 그래프 탐색 결과를 1초 이내에 제공해야 한다. - 다음 두 계층을 모두 표현한다. - **네트워크 계층**: 실제로 어떤 서비스가 통신하는가 - **애플리케이션 계층**: 어떤 API와 엔드포인트가 호출되는가 - 단순한 연결 관계 외에도 다음 정보를 함께 표시한다. - 서비스 상태와 가용성 - 중요도 및 availability tier - 비즈니스 도메인 - 서비스 소유 팀 - 기타 운영 메타데이터 - 엔지니어가 탐색할 수 있는 UI뿐 아니라 자동화 시스템도 사용할 수 있는 프로그래밍 API를 제공한다. - 복원력 프레임워크 - 영향 범위 계산기 - 장애 대응 자동화 시스템 ## 세 가지 데이터 소스를 결합하는 구조 핵심 설계는 하나의 데이터 소스에 의존하지 않고, 서로 다른 관점에서 별도의 의존성 그래프를 구축하는 것이다. - 네트워크 계층, IPC 계층, 트레이싱 계층을 물리적으로 분리해 저장한다. - 각 계층은 독립적으로 발전하고 병렬로 조회할 수 있다. - 통합된 뷰가 필요할 때는 각 계층의 그래프를 동시에 탐색한 뒤 결과를 병합한다. - 이 구조를 통해 여러 계층을 함께 조회하더라도 1초 이내의 응답 시간을 목표로 한다. - 필요에 따라 통합된 그래프를 보거나, 특정 계층의 그래프만 독립적으로 분석할 수 있다. ## eBPF 기반 네트워크 흐름 첫 번째 데이터 소스는 커널 수준에서 eBPF로 수집한 네트워크 흐름 정보다. - 실제 네트워크 통신을 기반으로 어떤 서비스가 어떤 서비스에 연결되는지 기록한다. - 애플리케이션 계측 여부와 관계없이 실제 트래픽이 발생하는 모든 서비스를 포착할 수 있다. - 클러스터 간 통신과 애플리케이션 간 통신을 모두 파악할 수 있다. - 네트워크 트래픽이라는 실제 운영 데이터를 사용하므로 네트워크 계층의 기준점 역할을 한다. - 다만 네트워크 정보만으로는 어떤 API나 애플리케이션 기능이 호출됐는지 알기 어렵다. - 따라서 eBPF 데이터는 포괄적인 연결 관계를 제공하지만, 애플리케이션 의미를 해석하려면 IPC나 트레이싱 같은 추가 데이터가 필요하다. ## 운영 관점의 의미 - 서비스 토폴로지는 장애 원인 분석을 단순화하고, 상·하위 의존성 및 장애 전파 경로를 빠르게 확인하게 한다. - 서비스 중단이나 유지보수 전에 영향받을 서비스와 관련 팀을 파악할 수 있다. - UI와 API를 함께 제공함으로써 사람의 장애 대응과 자동화된 복원력·영향 분석을 모두 지원한다. - 정적인 아키텍처 문서보다 실제 트래픽과 현재 운영 상태를 반영하는 동적 지도가 분산 시스템에 더 유용하다. 실무적으로는 단일 관측 도구에 의존하기보다 네트워크 흐름, 애플리케이션 호출, 트레이싱 데이터를 결합해 의존성 정보를 구성하는 것이 좋다. 특히 대규모 마이크로서비스 환경에서는 실시간성, 데이터 정확성, 빠른 그래프 탐색, 기존 도구와의 통합을 초기 설계부터 핵심 요구사항으로 삼아야 한다.

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

분산 시스템옵저버빌리티마이크로서비스ebpf+2

gitlab·2026년 5월 11일·5분 읽기큐레이션 요약

GitLab Act 2

GitLab은 에이전트 중심의 소프트웨어 개발 시대에 맞춰 회사의 조직과 기술 기반을 동시에 재편하겠다고 밝혔다. 이를 위해 구조조정, 조직 계층 축소, R&D 팀 재편, AI 기반 내부 프로세스 자동화를 추진하며, 플랫폼도 기계 규모의 작업과 전 생애주기 오케스트레이션을 지원하도록 재설계한다. GitLab은 이러한 변화가 개발자의 역할을 없애는 것이 아니라, 복잡한 설계·판단·문제 해결을 담당하는 엔지니어의 중요성을 더욱 높일 것이라고 주장한다. ## 구조조정과 운영 방식의 변화 - 구조조정 계획을 공개적으로 진행하고, 자발적 퇴직 프로그램도 함께 운영한다. - 새로운 회사 구조는 가능한 경우 2026년 6월 1일까지 확정할 계획이며, 지역별 법적 절차가 필요한 경우 해당 절차가 끝난 뒤 변경한다. - 소규모 팀이 있는 국가를 중심으로 운영 국가 수를 최대 30% 줄이고, 해당 시장은 파트너 네트워크를 통해 지원한다. - 일부 조직에서 관리 계층을 최대 3단계 줄여 리더와 실무진 사이의 거리를 좁힌다. - R&D를 약 60개의 소규모·자율 팀으로 재편하고, 각 팀이 기능의 시작부터 끝까지 책임지도록 한다. - 검토, 승인, 인계 같은 내부 프로세스에 AI 에이전트를 도입해 업무 속도를 높이고, 이에 맞춰 역할과 인력 규모를 조정한다. - 구조조정의 최종 범위와 재무 영향은 이사회 승인 후 6월 2일 실적 발표에서 공개할 예정이다. - 회사는 1분기 및 FY27 연간 가이던스를 유지한다고 밝혔다. ## 에이전트 시대에 대한 전략적 관점 - 앞으로 소프트웨어는 사람이 직접 작성하기보다, 사람이 방향과 판단을 제시하고 기계가 계획·코딩·리뷰·배포·복구를 수행하는 방식으로 발전한다고 본다. - 인간은 아키텍처 설계, 고객 문제의 본질 파악, 트레이드오프 판단처럼 높은 수준의 의사결정을 맡는다. - 소프트웨어 생산 비용과 시간이 감소하면 소프트웨어에 대한 수요가 크게 증가할 것으로 전망한다. - 개발자 플랫폼의 경제적 가치가 기존 사용자당 월 수십 달러 수준에서 수백 달러, 장기적으로 수천 달러 수준으로 커질 수 있다고 주장한다. - 자동화가 확대되어도 분산 시스템, 장애 분석, 복잡한 시스템 통합, 모호한 상황에서의 의사결정 등 고난도 엔지니어링 업무는 오히려 늘어난다. - GitLab은 2026년 1월 출시한 Duo Agent Platform의 초기 도입 성과를 바탕으로 에이전트 기능을 더욱 가속화할 계획이다. ## 기계 규모를 위한 인프라 재설계 - AI 에이전트는 동시에 여러 머지 리퀘스트를 생성하고, 지속적으로 파이프라인을 실행하며, 인간 팀보다 훨씬 빠르게 커밋을 발생시킨다. - 기존 Git과 개발 플랫폼은 인간 중심의 작업량을 전제로 설계됐기 때문에 에이전트 수준의 부하를 감당하려면 근본적인 재설계가 필요하다고 본다. - GitLab은 다음과 같은 방향을 제시한다. - Git 자체를 기계 규모의 작업량에 맞게 재설계 - 모놀리식 구조를 현대적인 API 우선·조합형 서비스로 전환 - 에이전트가 인간용 인터페이스를 우회하지 않고 플랫폼의 일급 사용자로 동작할 수 있는 전용 API 제공 - 목표는 에이전트 작업량을 기본값으로 처리할 수 있는 100배 규모의 인프라와 높은 성능·신뢰성을 확보하는 것이다. ## 전체 개발 생애주기의 오케스트레이션 - 단일 에이전트가 코드를 작성하거나 머지 리퀘스트를 만드는 것만으로는 기업의 목표인 안정적인 운영 소프트웨어 제공을 달성할 수 없다. - 오케스트레이션 계층은 여러 에이전트를 조정하고 다음 작업을 담당한다. - 작업 할당 - 상태 관리 - 실행 단계 간 컨텍스트 전달 - 충돌 해결 - 정책 적용 - 중요한 단계에서의 인간 검토 유지 - 기존 CI/CD 파이프라인은 사람이 생성하는 커밋을 안전하게 배포하도록 설계됐지만, 앞으로는 에이전트를 조정하고 결과를 검증하며 가드레일을 적용하는 런타임으로 재구성된다. - 최종적으로 에이전트의 작업을 운영 환경까지 안전하게 연결하는 것이 목표다. ## 연결된 컨텍스트를 경쟁력으로 활용 - 코드 생성 기능 자체는 개발 도구 업체 간에 비슷해져 상품화될 가능성이 높다고 본다. - 차별화 요소는 모델이 활용할 수 있는 기업 고유의 컨텍스트다. - GitLab은 계획, 코드, 리뷰, 보안, 배포, 운영 정보를 프로젝트와 저장소 전체에 걸쳐 연결하는 데이터 모델을 핵심 자산으로 삼는다. - 이 데이터 모델을 API로 제공하면 사람과 에이전트의 모든 작업이 축적되어 시간이 지날수록 더 풍부한 컨텍스트가 만들어진다. - 충분한 컨텍스트가 있으면 에이전트가 불필요한 토큰을 덜 사용하면서도 더 정확한 결과를 낼 수 있다는 설명이다. ## 플랫폼에 내장하는 거버넌스 - 기업이 에이전트의 속도를 활용하려면 동시에 통제력을 유지해야 한다. - 에이전트가 수행할 수 있는 작업이 늘어날수록 다음 기능이 플랫폼의 기본 요소가 되어야 한다. - 누가 무엇을 실행할 수 있는지 정의하는 신원 및 권한 관리 - 어떤 작업이 언제, 왜 수행됐는지 확인하는 감사 기록 - 에이전트와 파이프라인의 행동을 제한하는 정책 집행 - 민감한 코드와 데이터를 적절한 위치에 보관하는 배포 유연성 - 이러한 거버넌스를 별도 제품으로 덧붙이는 대신, 모든 에이전트·파이프라인·머지 리퀘스트가 기본적으로 통과하는 핵심 플랫폼 서비스로 만들 계획이다. ## 하나의 플랫폼, 세 가지 운영 모드 - 글은 GitLab이 기존 소프트웨어를 전면 재작성하지 않고도 에이전트 시대에 대응할 수 있도록 “하나의 플랫폼, 세 가지 모드”라는 방향을 제시한다고 소개한다. - 다만 제공된 본문은 이 항목의 설명이 `T...`에서 중단되어 있어 세 가지 모드의 구체적인 내용은 확인할 수 없다. GitLab의 계획은 단순한 AI 기능 추가가 아니라, 조직 구조·내부 운영·Git 인프라·CI/CD·데이터 모델·거버넌스를 함께 바꾸는 전사적 전환이다. 기업 고객 입장에서는 에이전트의 생산성보다도 권한 통제, 감사 가능성, 컨텍스트 연결, 안정적인 배포를 지원하는지가 도입 판단의 핵심이 될 것으로 보인다.

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

분산 시스템AI 에이전트CI/CDgitlab+4

discord·2026년 4월 29일·4분 읽기큐레이션 요약

메일이 (너무 많이) 도착했습니다: 3/25/26 음성 서비스 장애의 이면

Discord의 2026년 3월 25일 음성·영상 장애는 세션 관리 서버의 설정 변경에서 시작되어 여러 시스템을 거친 연쇄 장애로 확대됐다. Kubernetes 마이그레이션 중 세션 서버의 복제본 수를 줄이자 한 가용 영역에서 세션의 상당 부분이 비정상 종료됐고, 재연결·상태 정리 트래픽이 급증했다. 그 결과 사용자는 통화에 참여하지 못하고 “Awaiting Endpoint” 메시지를 보았으며, 장애는 12:13부터 15:30 PDT까지 이어졌다. ## 장애의 규모와 직접적인 증상 - 장애 발생 시점은 3월 25일 12:13 PDT, 복구 시점은 15:30 PDT였다. - Discord의 음성·영상 통화를 시작하거나 참여하기 어려웠다. - 많은 사용자가 통화 상태에서 **“Awaiting Endpoint”** 메시지를 확인했다. - 세션 관리 서버의 약 17%가 동시에 사라지면서 후속 시스템에 대규모 부하가 전달됐다. - 최종적으로 음성·영상 통화를 적절한 서버로 라우팅하는 서비스가 과부하를 겪었다. ## Kubernetes 마이그레이션과 변경 배경 - Discord는 Elixir 기반 실시간 서비스를 Kubernetes 환경으로 이전하고 있었다. - Elixir 서비스는 각 호스트에서 수천 개의 상태를 가진 프로세스를 실행한다. - 길드 - 사용자 presence - 통화 - 사용자 세션 - 서버를 종료할 때는 프로세스의 상태를 다른 노드로 넘긴 뒤 종료해야 서비스 중단을 피할 수 있다. - 배포 시스템은 서버의 엔터티 수가 0이 될 때까지 기다린 후 pod를 종료하도록 설계돼 있었다. - 주말 CPU 사용률이 높아지자 다음과 같은 리소스 조정을 시도했다. - pod당 CPU와 메모리 증가 - 전체 pod 수를 비례적으로 감소 - 스케줄러 사용량이 pod 수에 따른 고정 비용인지 측정 ## 세션 서버의 비정상 종료 - 변경 사항은 먼저 한 가용 영역에 배포됐다. - 복제본 수를 줄이는 과정에서 Kubernetes가 해당 영역의 pod 중 50%를 종료했다. - 서비스는 Kubernetes의 종료 신호를 받으면 프로세스를 다른 노드로 이전하려고 한다. - 그러나 진행 중인 다른 이벤트가 끝날 때까지 기다리는 안전 검사 때문에, Kubernetes의 종료 유예 시간이 먼저 만료됐다. - 결과적으로 프로세스 핸드오프가 시작되기 전에 pod가 종료됐다. - 세 영역이 균등하게 구성돼 있었기 때문에 Discord 전체 세션의 약 17%가 비정상적으로 중단됐다. ## Elixir GenServer와 모니터링 메시지의 폭증 - Discord의 실시간 시스템은 Elixir의 `GenServer` 프로세스를 기반으로 동작한다. - 각 프로세스는 자신의 mailbox에서 한 번에 하나의 메시지만 처리한다. - 단일 메시지 처리 방식은 동시성 문제를 줄인다. - 반대로 짧은 시간에 메시지가 폭증하면 처리 지연이 발생할 수 있다. - Elixir의 `Process.monitor` 또는 Discord의 확장형 `ZenMonitor`는 감시 대상 프로세스가 종료되면 `{:DOWN, ...}` 메시지를 전달한다. - 세션 17%가 동시에 종료되면서 해당 세션을 감시하던 여러 프로세스에 종료 알림이 일제히 전송됐다. - 이 메시지 폭풍은 실시간 시스템 전반으로 전파됐고, 가장 먼저 Gateway 서비스에 영향을 미쳤다. ## 사용자 재연결로 확대된 부하 - Gateway 서비스는 Discord의 모든 WebSocket 트래픽에 대한 입구이자 출구 역할을 한다. - 클라이언트가 연결되면 Gateway는 세션 서비스를 통해 사용자 세션을 만들고, 길드·채널·DM 등의 데이터를 전달한다. - 세션의 갑작스러운 종료는 클라우드 장애, 네트워크 오류, 클라이언트 환경 등에서도 발생할 수 있으므로 Gateway는 이를 감지하고 재연결을 유도한다. - 세션이 끊기면 Gateway는 사용자를 즉시 재연결시키고, 기존 세션을 낙관적으로 복구하려 한다. - 이번 장애에서는 대규모 세션 종료가 동시에 발생하면서 정상적인 복구 절차 자체가 대규모 재연결 부하로 변했다. - 제공된 글 내용은 이 재연결 과정과 이후 음성 라우팅 시스템의 상세한 연쇄 장애를 설명하기 직전에서 끝난다. ## 실용적인 교훈 - 상태를 가진 서비스를 Kubernetes에서 축소할 때는 replica 감소 자체보다 **상태 이전과 종료 유예 시간의 상호작용**을 검증해야 한다. - 장애 복구용 재연결 로직도 대규모 동시 장애에서는 부하 증폭기가 될 수 있으므로 재연결 속도 제한과 단계적 복구가 필요하다. - 한 서비스의 작은 설정 변경이 모니터링 메시지, WebSocket 재연결, 음성 라우팅 등 여러 계층을 거쳐 전혀 다른 병목을 압박할 수 있다. - 분산 시스템 변경은 단일 서비스의 CPU·메모리 지표뿐 아니라 장애 전파 경로와 최악의 동시 부하까지 함께 검증해야 한다.

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

분산 시스템쿠버네티스websocketselixir+2

cloudflare·2026년 4월 10일원문

500 Tbps의 용량: 글로벌 네트워크 확장의 16년 (새 탭에서 열림)

Cloudflare는 지난 16년간의 성장을 통해 전 세계 330개 이상의 도시에서 총 500Tbps의 외부 연결 용량을 확보하며 글로벌 네트워크의 중추적인 역할을 수행하고 있습니다. 이 거대한 용량은 단순히 트래픽을 처리하는 것을 넘어 대규모 DDoS 공격을 감내할 수 있는 '보안 예산'의 역할을 하며, 네트워크 전체에 분산된 지능형 소프트웨어를 통해 인간의 개입 없이도 초당 수십 테라비트급의 공격을 자동으로 방어합니다. 결과적으로 Cloudflare는 단순한 콘텐츠 전달 네트워크를 넘어 에지 컴퓨팅과 차세대 라우팅 프로토콜을 주도하는 지능형 인프라로 진화했습니다. ### 500 Tbps 용량의 의미와 네트워크 확장 * 500 Tbps는 피크 트래픽 수치가 아니라, transit 제공업체, 피어링 파트너, 인터넷 교환지(IX) 등과 연결된 모든 외부 포트 용량의 합계를 의미합니다. * 2010년 단일 서비스 제공업체로 시작한 이후, 현재는 전 세계 웹 트래픽의 20% 이상을 보호하는 330개 도시 규모의 거대 네트워크로 성장했습니다. * 일상적인 트래픽은 이 용량의 일부만 사용하며, 나머지 유휴 용량은 대규모 DDoS 공격을 흡수하고 차단하기 위한 일종의 '보안 버퍼'로 활용됩니다. ### 분산형 자동 방어 체계: 31.4 Tbps 공격의 차단 과정 * 2025년 발생한 31.4 Tbps 규모의 Aisuru-Kimwolf 봇넷 공격을 엔지니어의 개입 없이 단 35초 만에 자동으로 완화했습니다. * 모든 서버는 xdpd(eXpress Data Path)와 eBPF 기반의 l4drop 프로그램을 실행하여, 공격 트래픽이 CPU 자원을 소모하기 전에 네트워크 카드(NIC) 수준에서 즉시 폐기합니다. * dosd(DoS 데몬)가 각 서버의 샘플링 데이터를 바탕으로 공격 패턴을 분석하면, 이 규칙이 Quicksilver(분산 KV 저장소)를 통해 전 세계 모든 데이터 센터에 수초 내로 전파되어 동시 대응이 이루어집니다. * 중앙 집중식 스크러빙 센터로 트래픽을 돌리지 않고, 공격이 유입된 현장에서 즉시 처리함으로써 지연 시간을 최소화하고 가용성을 보장합니다. ### 차세대 라우팅 보안: RPKI와 ASPA * BGP 하이재킹과 경로 왜곡을 방지하기 위해 RPKI(리소스 공공키 기반구조)를 전면 도입하여 잘못된 경로로 유입되는 트래픽을 원천 차단합니다. * RPKI가 경로의 '소유권'을 확인한다면, 새롭게 도입 중인 ASPA(자율 시스템 제공자 인증)는 트래픽이 거쳐온 '경로의 정당성'까지 검증하여 경로 누출(Route Leak) 사고를 예방합니다. * Cloudflare는 이러한 프로토콜의 초기 채택자로서, 인터넷 전체의 보안 표준을 높이고 더 안전한 글로벌 라우팅 환경을 구축하는 데 기여하고 있습니다. ### AI 에이전트 부상에 따른 트래픽 변화 대응 * 현재 전체 HTML 요청의 4% 이상이 AI 크롤러와 학습 파이프라인에서 발생하고 있으며, 이는 기존 검색 엔진 크롤러에 필적하는 수준입니다. * AI 크롤러는 일반 사용자 브라우저와 달리 쉼 없이 최대 대역폭으로 리소스를 긁어가는 특성이 있어, 이를 일반적인 공격 트래픽과 구분하는 것이 새로운 기술적 과제로 부상했습니다. * TLS 핑거프린팅, 행동 분석, 로봇 배제 표준(robots.txt) 준수 신호 등을 결합하여 정당한 AI 트래픽은 허용하고 악의적인 수집은 차단하는 정교한 탐지 시스템을 운영합니다. Cloudflare의 사례는 현대 인프라가 단순히 하드웨어의 확장을 넘어, 소프트웨어 기반의 지능형 자동화와 강력한 에지 컴퓨팅 역량을 갖추어야 함을 시사합니다. 기업들은 전 세계 어디서나 일관된 성능과 보안을 제공받기 위해, 대규모 분산 네트워크 인프라와 결합된 클라우드 네이티브 보안 모델을 적극적으로 고려해야 합니다.

분산 시스템cloudflarenetwork-securityebpf+4

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

피그마의 차세대 데이터 캐싱 플랫폼 | 피그마 블로그

Figma는 Redis 기반 캐싱 인프라가 성장하면서 연결 수 한계, 급격한 확장 시 연결 폭주, 관측성 부족 등으로 가용성 위협이 커지자 이를 근본적으로 재설계했다. 그 결과 stateless RESP 프록시인 FigCache를 구축해 Redis 연결과 클라이언트 서비스 규모를 분리하고, 라우팅·보안·관측성을 중앙화했다. 2025년 하반기 핵심 API에 도입한 이후 캐싱 계층은 99.9999% 가동률을 달성했다. ## Redis 캐싱 인프라의 성장통 - Figma의 Redis는 단순한 보조 구성 요소에서 사이트 가용성에 직접 영향을 주는 핵심 의존성으로 발전했다. - Redis 클러스터의 연결 수가 한계에 가까워졌고, 클라이언트 서비스가 빠르게 확장될 때 대규모 연결 생성이 동시에 발생하는 ‘thundering herd’ 문제가 나타났다. - 중앙화된 트래픽 관리와 일관된 접근 방식이 없어 애플리케이션이 서로 다른 클러스터의 데이터를 오염시키거나 손상시킬 위험이 있었다. - 클라이언트 라이브러리마다 관측 기능이 달라 장애 원인 분석과 대응이 어려웠다. - 장애 조치나 토폴로지 변경 시 클라이언트 상태가 올바르게 유지되는지 전체 서비스에 일관된 보장을 제공하기도 어려웠다. - Figma는 일부 API 시스템에서 Redis 의존성을 제거하고, 서비스별 연결 풀링을 도입해 단기적으로 장애 영향을 줄였지만 장기적인 공통 플랫폼이 필요하다고 판단했다. ## 장기적인 설계 목표 - **클라이언트 연결 변동성으로부터 Redis 격리** - Redis가 처리하는 연결 수를 클라이언트 애플리케이션의 규모와 탄력적 확장성에서 분리한다. - 서비스가 급격히 확장될 때 Redis로 연결 요청이 몰리는 현상을 막는다. - **기본 제공 observability** - 서비스 소유자와 플랫폼 운영자가 멀티테넌트 환경에서 개별 워크로드의 가용성과 성능을 확인할 수 있도록 한다. - 여러 계층에서 일관되고 세밀한 모니터링 기능을 제공한다. - **투명한 수평 확장** - 클라이언트가 인프라 확장이나 축소를 직접 알 필요 없도록 한다. - 클러스터 확장·축소, 노드 장애 조치, 샤드 전체 손실 같은 복잡한 Redis Cluster 동작을 클라이언트 라이브러리 아래 계층에서 처리한다. - **단일 범용 엔드포인트** - 여러 Redis 클러스터를 애플리케이션별 개별 설정 없이 중앙 라우팅한다. - 클러스터 격리 수준, 내구성, 중요도, 트래픽 규모가 서로 다른 환경의 분할 결정을 중앙에서 관리한다. - **대체 저장소의 플러그인 가능성** - 같은 프로토콜과 API를 유지하면서 필요에 따라 진정한 내구성을 제공하는 다른 저장 기술을 연결할 수 있도록 한다. - **기본 확장성** - 인라인 데이터 암호화, 보호 장치(guardrail), 트래픽 백프레셔 등 Figma 고유의 데이터 플레인 기능을 애플리케이션마다 반복 구현하지 않도록 한다. ## FigCache의 구조와 역할 - FigCache는 **stateless RESP-wire-protocol 프록시 서비스**다. - Redis 데이터 플레인과 진입 계층 역할을 하며, 애플리케이션에는 언어와 무관한 일관된 Redis 인터페이스를 제공한다. - 여러 Redis 클러스터와 백엔드 사이의 트래픽 라우팅 및 클러스터 관리 복잡성을 애플리케이션에서 숨긴다. - 연결 멀티플렉서로 동작해 클라이언트 서비스의 연결 변동이 Redis에 직접 전달되지 않도록 한다. - FigCache 자체와 함께 Figma가 관리하는 전용 클라이언트 라이브러리를 제공해 캐싱 스택 전반의 동작을 표준화한다. ## 플랫폼 전환의 효과 - Redis 연결 확장성과 클라이언트 서비스의 용량 변동을 분리할 수 있게 됐다. - 중앙화된 라우팅으로 애플리케이션이 여러 클러스터의 엔드포인트를 직접 관리할 필요가 줄었다. - 보안 정책과 트래픽 제어를 공통 계층에서 적용할 기반이 마련됐다. - 전체 캐싱 스택에 걸친 종합적인 관측성을 확보했다. - 2025년 하반기 Figma의 메인 API 서비스에 적용한 뒤 캐싱 계층은 **99.9999% 가동률**이라는 안정성 목표를 달성했다. ## 실용적인 시사점 Redis를 서비스의 핵심 경로에서 사용할 때는 개별 애플리케이션의 연결 풀링만으로 문제를 해결하기보다, 연결 중계·라우팅·클러스터 토폴로지 관리·관측성을 공통 플랫폼으로 분리하는 것이 효과적이다. 특히 클라이언트 수가 탄력적으로 변하는 환경에서는 프록시 계층을 통해 Redis가 직접 연결 폭주를 겪지 않도록 설계하는 것이 중요하다.

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

분산 시스템옵저버빌리티rediscaching+2

github·2026년 2월 24일·3분 읽기큐레이션 요약

멀티 에이전트 워크

멀티 에이전트 워크플로는 에이전트들이 상태, 실행 순서, 검증 방식에 대해 암묵적으로 가정하기 때문에 쉽게 실패한다. 이를 안정적으로 운영하려면 에이전트를 대화형 인터페이스가 아니라 분산 시스템의 구성 요소처럼 다뤄야 하며, 타입 스키마·명시적 액션·강제된 인터페이스가 필요하다. 특히 MCP(Model Context Protocol)는 이러한 계약을 실행 전에 검증해 잘못된 상태가 시스템에 전파되는 것을 막는다. ## 멀티 에이전트 시스템이 실패하는 이유 - 이슈 분류, 변경 제안, 테스트 실행, 풀 리퀘스트 생성처럼 관련 작업을 여러 에이전트가 나눠 처리하면 상태와 순서에 대한 암묵적 가정이 생긴다. - 한 에이전트가 이슈를 열자마자 다른 에이전트가 이를 닫거나, 후속 검사를 알지 못한 채 변경 사항을 배포하는 문제가 발생할 수 있다. - 자연어와 일관되지 않은 JSON만으로 통신하면 필드명, 자료형, 형식이 쉽게 달라져 자동화가 불안정해진다. ## 타입 스키마로 데이터 계약 정의 - 에이전트 간 데이터 교환에는 기계적으로 검증 가능한 타입과 엄격한 스키마를 사용해야 한다. - 예를 들어 사용자 프로필을 다음처럼 정의할 수 있다. - `id`: 숫자 - `email`: 문자열 - `plan`: `free`, `pro`, `enterprise` 중 하나 - 잘못된 메시지는 다음 단계로 전달하기 전에 실패시켜야 한다. - 재시도 - 메시지 수정 - 사람에게 에스컬레이션 - 디버깅도 로그를 해석하는 방식에서 “어떤 스키마 계약을 위반했는가”를 확인하는 방식으로 바뀐다. ## 액션 스키마로 의도 명확히 하기 - 데이터 형식이 올바르더라도 “분석하고 팀이 행동하도록 돕는다”처럼 지시가 모호하면 에이전트마다 다른 결정을 내릴 수 있다. - 가능한 결과를 제한된 액션 집합으로 정의하면 자동화 가능한 결과만 반환하게 만들 수 있다. - 예시 액션: - 추가 정보 요청: 필요한 정보 목록 포함 - 담당자 지정: 담당자 식별자 포함 - 중복 이슈로 종료: 원본 이슈 번호 포함 - 조치 없음 - 에이전트는 반드시 하나의 유효한 액션을 반환해야 하며, 그 외 결과는 검증 실패로 처리해 재시도하거나 에스컬레이션한다. - 글은 멀티 에이전트 장애의 상당수가 데이터 자체보다 “잘못된 행동 선택”에서 발생한다고 설명한다. ## MCP로 인터페이스 강제 - 스키마와 액션 규칙을 문서로만 정해두면 관례에 불과하며, 모든 에이전트가 이를 지킨다는 보장이 없다. - MCP는 각 도구와 리소스에 명시적인 입력·출력 스키마를 제공하고, 도구 호출 전에 이를 검증한다. - 예를 들어 `create_issue` 도구에 입력 스키마와 출력 스키마를 함께 정의할 수 있다. - MCP를 사용하면 에이전트가 다음과 같은 오류를 일으키기 어렵다. - 존재하지 않는 필드 생성 - 필수 입력 누락 - 에이전트 간 인터페이스 형식 변경 - 실행 전에 검증하므로 잘못된 호출이 운영 시스템에 영향을 주기 전에 차단된다. ## 실용적인 적용 방향 - 에이전트 간 모든 경계에 타입 스키마를 적용한다. - 자연어 지시의 최종 결과는 제한된 액션 스키마로 변환한다. - 도구 호출과 데이터 교환에는 MCP 같은 검증 계층을 둔다. - 스키마 위반을 자동 재시도, 수정, 에스컬레이션 대상으로 명시한다. - 멀티 에이전트 시스템을 챗봇이 아니라 계약과 인터페이스를 갖춘 소프트웨어 컴포넌트로 설계하는 것이 핵심이다.

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

분산 시스템AI 에이전트모델 컨텍스트 프로토콜github-copilot+2

airbnb·2026년 2월 11일원문

나의 에어비앤비 입 (새 탭에서 열림)

안나 술키나(Anna Sulkina)는 20년 이상의 경력을 가진 엔지니어링 리더로, 하드웨어 진단에서 시작해 프론트엔드와 백엔드를 거쳐 현재 에어비앤비의 인프라 및 클라우드 부문을 이끌고 있습니다. 그녀는 트위터 재직 당시 대규모 분산 시스템의 기술적 한계를 극복하고 조직적 합의를 통해 GraphQL 도입을 성공시킨 경험을 바탕으로, 기술적 역량과 리더십의 조화를 강조합니다. 현재 그녀는 에어비앤비에서 개발자 플랫폼의 전략적 방향성을 설정하고 고성과 팀을 구축하여 비즈니스 가치를 극대화하는 데 전념하고 있습니다. ### 기술적 호기심의 시작과 초기 경력의 도전 * 소련 붕괴 시기 우크라이나에서 성장하며, 컴퓨터 하드웨어를 조립하던 오빠의 영향으로 기술에 대한 호기심을 키웠습니다. * 미국 이주 초기에는 프로그래밍 언어보다 영어 소통에 더 큰 어려움을 겪었으나, 버클리 익스텐션 등을 통해 C++과 Java 지식을 확장하며 전문성을 쌓았습니다. * 첫 직장인 하드웨어 진단 분야를 시작으로 기술 스택의 아래 단계로 점진적으로 내려가며 하드웨어, 프론트엔드, 백엔드를 아우르는 폭넓은 시각을 갖게 되었습니다. ### 리더십으로의 전환과 팀 구축의 즐거움 * 개인 기여자(IC)로서의 역량뿐만 아니라 리더십 잠재력을 인정받아 텔레콤 스타트업과 컴캐스트(Comcast)를 거치며 엔지니어링 매니저로 성장했습니다. * 좋은 리더가 있는 팀과 그렇지 않은 팀의 차이를 직접 목격하며 사람을 코칭하고 고성과 팀을 만드는 과정에서 큰 흥미를 느꼈습니다. * 기술 스택의 깊이가 깊어질수록 리더십의 책임 또한 커지는 궤적을 그리며 인프라 부문의 리더로 자리매김했습니다. ### 트위터에서의 분산 시스템 설계와 기술 혁신 * 약 9년 동안 트위터에 재직하며 'Fail Whale' 시기와 엘런 디제너러스의 셀카 사건 등 대규모 트래픽 장애를 해결하는 핵심적인 역할을 수행했습니다. * **실패를 위한 설계:** 모놀리스 구조에서 마이크로서비스 아키텍처로 전환하며, 복잡한 분산 시스템에서는 실패를 피하는 것이 아니라 '실패를 대비한 설계'가 필수적임을 배웠습니다. * **합의를 통한 혁신:** 해커톤에서 시작된 GraphQL 도입을 위해 전사적인 기술적 합의를 이끌어냈으며, 이는 기존 REST 서비스를 대체하고 제품 개발 속도를 획기적으로 높이는 결과로 이어졌습니다. ### 에어비앤비에서의 전략적 정렬과 플랫폼 고도화 * 평소 여행을 좋아하고 에어비앤비 서비스의 팬이었던 점이 이직의 결정적 계기가 되었으며, 개인적 관심사와 기술적 전문성을 일치시켰습니다. * **개발자 플랫폼 개선:** 파편화되어 있던 개발자 플랫폼 조직의 전략을 명확히 하고, 내부 이해관계자들과의 신뢰를 구축하는 데 집중했습니다. * **조직적 정렬:** "우리는 왜 여기에 모였는가?"와 같은 근본적인 질문에 답하며 리더십 코칭과 팀 간 정렬을 통해 비즈니스 가치를 창출하는 고성과 조직을 재정비했습니다. 안나 술키나의 여정은 복잡한 시스템일수록 기술적 완벽주의보다는 실패를 수용하는 유연한 설계가 중요하다는 점을 시사합니다. 또한, 기술적 혁신은 단순히 뛰어난 코드로 완성되는 것이 아니라, 조직 내의 합의를 이끌어내고 구성원들의 목표를 하나로 정렬하는 리더십을 통해 비로소 실현될 수 있음을 보여줍니다.

분산 시스템마이크로서비스JavaGraphQL+3

kakao·2026년 2월 8일·4분 읽기큐레이션 요약

잃어버린 리포트를 찾아서: 카카오 메시징 시스템의 경쟁 조건 문제와 안티 패턴 제거 과정

KIMS의 메시지 상태가 `SENT`에 멈춘 원인은 벤더사의 전송 결과 리포트가 메시지 레코드의 DB 커밋보다 먼저 도착하는 경쟁 조건이었다. 특히 응답이 빠른 특정 벤더와, 과금 후처리로 트랜잭션이 길어진 유료 메시지에서 문제가 집중되었으며, 전체 메시지의 약 0.02%에서 발생했다. 트랜잭션 범위를 줄이고 각 보장의 필요성을 재검토하는 과정에서, 불필요한 장기 트랜잭션과 외부 이벤트 발행을 분리해야 한다는 결론에 도달했다. ### KIMS 메시지 처리 구조 - KIMS는 카카오 내부 서비스용 SMS 전송 플랫폼으로, 하루 약 100만 건을 처리한다. - 다수의 IDC와 MSA 컴포넌트, 여러 외부 SMS 벤더로 구성되어 있다. - 기본 흐름은 다음과 같다. - API Server가 품질 지표를 기준으로 벤더를 선택한다. - 벤더 호출 후 메시지를 `SENT` 상태로 DB에 기록한다. - 벤더가 전송 결과 리포트를 전달한다. - Report Server가 메시지를 `REPORTED` 상태로 갱신한다. - 각 단계가 비동기적으로 분리되어 있어, 처리 순서가 뒤집힐 가능성이 존재했다. ### `SENT` 상태에 멈춘 메시지 - 일부 메시지가 리포트를 수신했음에도 `REPORTED`로 갱신되지 않았다. - Report Server 로그에는 벤더 리포트 수신 기록이 남아 있었다. - 즉, 리포트가 네트워크에서 유실된 것이 아니라 DB 반영 전에 폐기된 상황이었다. - 문제가 전체 메시지가 아닌 약 0.02%에서만 발생해 재현과 원인 분석이 어려웠다. ### 빠른 벤더와 긴 트랜잭션이 만든 경쟁 조건 - 리포트 누락은 특정 벤더로 전송된 메시지에서 집중적으로 발생했다. - 해당 벤더는 API 호출 후 평균 약 20ms, 문제 사례에서는 약 8ms 만에 리포트를 보냈다. - 반면 API Server는 벤더 호출 이후 후처리와 DB 영속화를 진행하고 있었다. - 유료 메시지는 과금 이벤트 발행 로직까지 하나의 `@Transactional` 범위에 포함되어 트랜잭션이 더 오래 유지됐다. - 결과적으로 처리 순서가 다음처럼 역전될 수 있었다. - API Server가 벤더 호출 - 과금 후처리와 이벤트 발행 수행 - 벤더가 리포트 전송 - Report Server가 상태 갱신 시도 - 아직 메시지 레코드가 DB에 없어 리포트가 유효하지 않은 것으로 판단되어 Drop - API Server가 뒤늦게 메시지를 DB에 저장 - 메시지의 초기 상태를 기록하는 Write 경로와 리포트를 읽어 상태를 갱신하는 Read 경로가 같은 시점에 교차하면서 Race Condition이 발생했다. ### 트랜잭션 범위 줄이기 - 기존 트랜잭션에는 DB 상태 변경뿐 아니라 Kafka 이벤트 발행 등 비즈니스 로직도 포함되어 있었다. - 이로 인해 Long-lived Transaction이 발생하고 DB Commit 시점이 지연됐다. - 과금 이벤트 발행을 `@Async`, `@TransactionalEventListener` 기반으로 분리해 커밋 이후 별도 스레드에서 실행하도록 변경했다. - 트랜잭션 책임을 상태 변경과 DB 영속화까지로 제한했다. - 평균 커밋 시점이 약 10ms 앞당겨졌고, 리포트 누락도 눈에 띄게 감소했다. - 외부 이벤트 발행 실패 때문에 DB 트랜잭션 전체가 롤백되는 Dual-write 문제도 완화됐다. - 외부 시스템으로 보내는 이벤트는 DB 트랜잭션과 본질적으로 동시에 롤백할 수 없으므로, 트랜잭션 내부에 무리하게 포함하는 방식은 부적절했다. ### 트랜잭션 보장의 필요성 재검토 글은 단순히 트랜잭션을 짧게 만드는 데서 그치지 않고, 해당 업무에 트랜잭션 자체가 필요한지 질문한다. MySQL의 `REPEATABLE READ`에서 제공되는 보장을 세 가지로 나누어 검토했다. - **원자성** - 여러 쓰기 작업 중 일부만 성공하는 상황을 막고 전체를 롤백하는 기능이다. - 해당 로직의 DB 쓰기는 사실상 단일 작업이었다. - 여러 테이블이나 레코드에 걸친 원자성이 필요하지 않다면 트랜잭션의 Abortability는 필수적이지 않을 수 있다. - **읽기 격리** - 라우팅 벤더 정보와 실시간 품질 지표를 조회하고 있었다. - 품질 지표는 분 단위로 갱신되며, 1분 전 데이터가 사용되어도 문제가 없었다. - 서로 독립적인 메타데이터를 조회하므로 동일한 스냅샷에서 읽어야 할 필요도 크지 않았다. - **쓰기 격리** - 변경 내용을 커밋 전까지 다른 트랜잭션에 노출하지 않는 보장이다. - JPA/Hibernate의 Dirty Checking에서는 변경 사항이 먼저 Persistence Context의 1차 캐시에 반영되고, 실제 DB Write는 트랜잭션 종료 시점까지 지연될 수 있다. - 이 지연이 리포트 처리보다 DB 저장이 늦어지는 직접적인 원인이 되었다. ### 실용적인 설계 교훈 - 외부 시스템의 응답 시간이 매우 짧을 수 있다는 전제에서 비동기 흐름을 설계해야 한다. - “호출 후 DB 저장”처럼 순서를 가정한 구조는 벤더별 응답 편차 때문에 경쟁 조건을 만들 수 있다. - 트랜잭션에는 반드시 원자적으로 처리해야 하는 DB 작업만 포함하고, 이벤트 발행·외부 API 호출·긴 후처리는 분리하는 것이 좋다. - 트랜잭션의 원자성·읽기 격리·쓰기 격리가 실제 비즈니스 요구사항인지 각각 검토해야 한다. - 리포트 처리에서는 아직 원본 메시지가 저장되지 않은 경우를 단순 Drop하지 말고, 재시도·지연 큐·Transactional Outbox 같은 보완책을 함께 고려해야 한다.

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

분산 시스템Apache Kafkamysqlrace-condition+4