Airbnb / distributed-systems

My Journey to Airbnb — Anna Sulkina (새 탭에서 열림)

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

From Static Rate Limiting to Adaptive Traffic Management in Airbnb’s Key-Value Store (새 탭에서 열림)

에어비앤비는 분산 키-밸류 저장소인 'Mussel'의 트래픽 관리 방식을 단순 요청 횟수 제한(QPS)에서 자원 기반의 적응형 제어 시스템으로 진화시켰습니다. 이 시스템은 요청의 실제 비용을 계산하는 자원 인식형 속도 제한(RARC)과 우선순위 기반의 부하 차단(Load Shedding) 계층을 도입하여 시스템의 유용 작업량(Goodput)을 극대화합니다. 결과적으로 Mussel은 예기치 못한 트래픽 급증이나 DDoS 공격 상황에서도 핵심 서비스의 성능을 안정적으로 유지할 수 있게 되었습니다. ### 정적 QPS 제한의 한계와 자원 인식형 제어(RARC)의 도입 기존의 단순 QPS 제한 방식은 요청의 복잡도와 상관없이 동일한 할당량을 차감했기에 효율적인 자원 관리가 불가능했습니다. * **비용 가변성 해결**: 단일 행 조회와 수만 행의 스캔 작업을 동일하게 취급하던 문제를 해결하기 위해, 행 수, 바이트 크기, 대기 시간(latency)을 결합한 '요청 단위(RU, Request Unit)' 개념을 도입했습니다. * **RU 계산 모델**: 읽기 비용은 $1 + w_r \times \text{읽은 바이트} + w_l \times \text{대기 시간}$과 같은 선형 모델을 통해 산출되며, 이는 하드웨어 리소스(CPU, I/O)에 가해지는 실제 부하를 더 정확하게 반영합니다. * **토큰 버킷 알고리즘**: 각 디스패처(Dispatcher)는 짧은 에포크(Epoch)마다 할당된 RU를 로컬 토큰 버킷에 채우고, 요청마다 실시간으로 계산된 비용을 차감하여 할당량 초과 시 즉각적으로 요청을 거부합니다. ### 지연 시간 비율 기반의 적응형 부하 차단 트래픽이 급격히 변하거나 특정 샤드에 병목이 발생할 때, 시스템 전체의 붕괴를 막기 위해 실시간 신호를 기반으로 한 부하 차단 메커니즘을 운용합니다. * **지연 시간 비율(Latency Ratio) 활용**: '장기 p95 지연 시간'을 '단기 p95 지연 시간'으로 나눈 비율을 시스템 스트레스 지표로 사용합니다. 이 비율이 설정값(예: 0.3) 이하로 떨어지면 시스템 부하가 급증한 것으로 판단합니다. * **임계치 기반의 단계적 대응**: 시스템 스트레스가 감지되면 낮은 우선순위의 클라이언트 그룹부터 RU 비용을 가중해 부과함으로써 자연스럽게 트래픽 백프레셔(Backpressure)를 유도합니다. * **P² 알고리즘 적용**: 고정된 메모리 내에서 대기 시간의 백분위수(Percentile)를 추정하는 P² 알고리즘을 사용하여, 별도의 샘플 저장소나 노드 간 통신 없이도 개별 디스패처가 신속하게 의사결정을 내릴 수 있습니다. ### 데이터 접근 패턴 최적화 및 안정성 확보 단순히 요청을 차단하는 것을 넘어, 데이터 접근의 불균형으로 인한 병목 현상을 해결하는 메커니즘을 포함합니다. * **핫키(Hot-key) 탐지 및 완화**: 특정 키에 대한 요청이 집중되는 패턴을 실시간으로 감지하여, 백엔드 저장소에 도달하기 전 캐싱하거나 중복 요청을 하나로 합치는(Coalescing) 방식으로 저장소 계층을 보호합니다. * **트래픽 분리 및 고립**: 특정 클라이언트의 데이터 패턴으로 인해 발생한 병목이 전체 클러스터로 전이되지 않도록 격리 수준을 높여 다중 사용자(Multi-tenant) 환경의 안정성을 강화했습니다. 멀티 테넌트 환경의 대규모 시스템을 운영한다면 단순한 횟수 기반의 제한보다는 자원 소비량을 기반으로 한 RU 모델과 시스템 상태에 반응하는 적응형 부하 차단 전략을 도입하는 것이 서비스 가용성 확보에 훨씬 유리합니다.

Viaduct, Five Years On: Modernizing the Data-Oriented Service Mesh (새 탭에서 열림)

에어비앤비는 자사의 데이터 중심 서비스 메시인 'Viaduct'의 5년간의 운영 성과를 공유하며, 이를 오픈소스로 공개하고 차세대 아키텍처인 'Viaduct Modern'으로의 전환을 발표했습니다. Viaduct는 중앙 집중식 스키마와 서버리스 비즈니스 로직 호스팅, 재진입(Re-entrancy) 구조를 통해 트래픽이 8배 성장하는 과정에서도 운영 효율성과 비용 선형성을 유지해 왔습니다. 이번 개편은 파편화되었던 API를 단순화하고 실행 엔진과 비즈니스 로직 사이의 추상화 경계를 강화하여, 거대해진 코드베이스의 유지보수성과 개발 생산성을 높이는 데 중점을 두었습니다. ### Viaduct의 핵심 설계 원칙 * **중앙 스키마(Central Schema):** 전사의 모든 도메인을 하나의 통합된 그래프로 연결합니다. 개발은 팀별로 분산되어 진행되지만, 사용자는 단일한 접점을 통해 모든 데이터와 기능에 접근할 수 있어 내부 요청의 75%가 Viaduct 내에서 처리됩니다. * **호스팅된 비즈니스 로직(Hosted Business Logic):** GraphQL 서버를 단순한 게이트웨이로 사용하는 대신, 비즈니스 로직을 직접 실행하는 서버리스 플랫폼으로 운영합니다. 이를 통해 개별 마이크로서비스 운영 부담을 줄이고 개발자가 로직에만 집중할 수 있는 환경을 제공합니다. * **재진입성(Re-entrancy):** Viaduct에 호스팅된 로직이 다른 로직을 호출할 때 GraphQL 프래그먼트와 쿼리를 사용하도록 설계되었습니다. 이는 대규모 코드베이스에서 직접적인 코드 의존성을 방지하고 모듈성을 유지하는 핵심 장치입니다. ### Viaduct Modern의 API 단순화 * **Tenant API의 통합:** 과거에는 기능 구현 방식이 복잡하고 파편화되어 있었으나, 이를 '노드 리졸버(Node Resolver)'와 '필드 리졸버(Field Resolver)' 두 가지 메커니즘으로 대폭 통합하여 개발자 경험을 개선했습니다. * **결정 트리 제거:** 구현 방식을 고민해야 했던 복잡한 결정 과정을 없애고, 스키마 자체의 정의에 따라 리졸버 유형이 자연스럽게 결정되도록 설계하여 학습 곡선을 낮췄습니다. ### 테넌트 모듈성과 협업 구조 * **테넌트 모듈(Tenant Module):** 스키마와 구현 코드를 팀별 소유권 단위로 묶어 관리합니다. 팀 간의 직접적인 코드 참조는 지양하고 GraphQL 인터페이스를 통해서만 소통합니다. * **선언적 데이터 의존성:** 예를 들어 '메시징 팀'이 '사용자 팀'의 타입에 새로운 필드를 추가할 때, `@Resolver` 어노테이션에 필요한 데이터 필드(예: 성, 이름)를 선언하기만 하면 됩니다. * **코드 의존성 해소:** 데이터 수요를 선언적으로 명시함으로써, 다른 팀의 내부 로직이나 데이터 소스가 무엇인지 알 필요 없이 독립적으로 기능을 확장할 수 있습니다. ### 프레임워크 계층화 및 유지보수성 * **강력한 추상화 경계:** GraphQL 실행 엔진, 테넌트 API, 애플리케이션 코드 사이의 인터페이스를 명확히 분리했습니다. 과거의 느슨했던 경계를 강화하여 서비스 로직의 중단 없이 엔진 성능을 개선하거나 라이브러리를 업데이트할 수 있는 구조를 갖췄습니다. * **운영 안정성:** 이러한 구조적 개선을 통해 개발자 수와 코드 라인 수가 급격히 증가함에도 불구하고 장애 시간을 절반으로 줄이는 성과를 거두었습니다. Viaduct는 대규모 조직에서 데이터 접근 방식을 통합하고 비즈니스 로직을 효율적으로 관리하려는 팀에게 강력한 모델을 제시합니다. 특히 마이크로서비스의 복잡도를 낮추고 싶은 조직이라면, Viaduct의 재진입 구조와 서버리스 호스팅 개념을 도입하여 개발 민첩성과 시스템 안정성을 동시에 확보하는 방향을 고려해 볼 만합니다.