datadog·2023년 10월 27일·3분 읽기큐레이션 요약

엔지니어링 스포트

Datadog은 Gartner의 ‘Observability Platforms’ 매직 쿼드런트 2026에서 리더(Leader)로 선정되었다고 발표합니다. 글은 Datadog을 인프라부터 애플리케이션, 로그, 보안, 디지털 경험, 소프트웨어 제공, 서비스 관리, AI까지 아우르는 통합 관측성 플랫폼으로 소개합니다. 다만 제공된 내용에는 Gartner 평가의 세부 기준이나 Datadog의 구체적인 강·약점 분석보다 제품 목록과 링크가 중심으로 포함되어 있습니다. ### Gartner 매직 쿼드런트 리더 선정 - Datadog은 Gartner의 **Observability Platforms** 부문에서 리더로 평가되었다고 밝힙니다. - 이번 발표의 핵심 메시지는 Datadog이 다양한 관측성 데이터를 하나의 플랫폼에서 수집·분석하고 운영 대응까지 지원한다는 점입니다. - 본문에 제공된 자료만으로는 Gartner가 어떤 실행 능력이나 비전 항목을 근거로 평가했는지는 확인되지 않습니다. ### 인프라 및 클라우드 관측성 - 인프라 모니터링과 메트릭 수집을 제공합니다. - 컨테이너와 Kubernetes 환경을 모니터링하고, Kubernetes 오토스케일링을 지원합니다. - 네트워크, 서버리스 애플리케이션, 스토리지, GPU를 관측할 수 있습니다. - Cloud Cost Management와 Cloudcraft를 통해 클라우드 비용 및 인프라 구성을 관리합니다. ### 애플리케이션 성능 모니터링 - APM으로 애플리케이션 성능과 서비스 간 동작을 추적합니다. - Universal Service Monitoring을 통해 서비스 상태를 파악합니다. - Continuous Profiler로 코드 실행 중의 CPU·메모리 사용 패턴을 분석할 수 있습니다. - Dynamic Instrumentation을 사용해 코드를 재배포하지 않고 실행 중인 애플리케이션을 조사할 수 있습니다. - AI 에이전트의 동작을 관찰하는 Agent Observability도 포함됩니다. ### 로그와 데이터 관측성 - Log Management를 통해 로그를 수집·검색·분석합니다. - Observability Pipelines로 로그의 라우팅, 필터링, 변환 및 보관 정책을 제어합니다. - Sensitive Data Scanner는 로그 등에서 민감정보를 탐지합니다. - Database Monitoring, Data Streams Monitoring을 통해 데이터베이스와 데이터 파이프라인을 모니터링합니다. - 데이터 품질과 작업 실행 상태를 확인하는 Quality Monitoring, Jobs Monitoring도 제공합니다. ### 보안 플랫폼 통합 - 코드 보안, SAST, IAST, 소프트웨어 구성 분석(SCA), IaC 보안을 제공합니다. - 클라우드 보안 상태, 권한, 취약점 및 컴플라이언스를 관리합니다. - Cloud SIEM과 Workload Protection으로 런타임 보안 이벤트와 워크로드를 분석합니다. - App and API Protection, Secret Scanning, Sensitive Data Scanner 등 애플리케이션 및 데이터 보호 기능을 포함합니다. ### 디지털 경험 모니터링 - Browser와 Mobile RUM을 통해 실제 사용자 경험을 측정합니다. - Product Analytics와 Session Replay로 사용자 행동과 세션 흐름을 분석합니다. - Synthetic Monitoring으로 실제 사용자가 없어도 웹·API·애플리케이션의 가용성을 점검합니다. - Error Tracking, Mobile App Testing, Feature Experiments 등을 통해 오류와 모바일 앱 품질을 관리합니다. ### 소프트웨어 제공과 서비스 운영 - CI Visibility와 Test Optimization으로 빌드·테스트 파이프라인의 성능과 실패 원인을 분석합니다. - Continuous Testing, Code Coverage, IDE Plugins를 통해 개발 및 테스트 과정의 가시성을 높입니다. - Internal Developer Portal과 Software Catalog로 서비스와 개발 자산을 관리합니다. - SLO, Event Management, Incident Response, Case Management를 통해 장애 대응과 서비스 수준을 관리합니다. - Workflow Automation과 App Builder로 반복적인 운영 작업을 자동화할 수 있습니다. ### AI 기반 운영 기능 - Bits AI Agents, Bits Chat, Bits Investigation 등을 활용해 조사와 운영 분석을 지원합니다. - Bits Security Analyst는 보안 분석 업무를 보조합니다. - MCP Server, Agent Builder, Agent Directory 등을 통해 AI 에이전트와 외부 도구의 연계를 지원합니다. - Watchdog은 이상 징후 탐지와 문제 분석을 자동화하는 기능으로 제시됩니다. - GPU Monitoring은 AI 및 머신러닝 워크로드의 GPU 사용 상태를 관찰하는 데 활용됩니다. 실무적으로는 Datadog을 도입할 때 단순히 Gartner의 리더 선정만 볼 것이 아니라, 필요한 영역이 인프라·APM·로그·보안·RUM 중 어디인지와 데이터 수집량에 따른 비용, 기존 도구와의 통합성, 보존 정책을 함께 검토하는 것이 좋습니다.

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

쿠버네티스datadog옵저버빌리티애플리케이션 성능 모니터링+3

datadog·2023년 10월 27일원문

엔지니어링 스포트라이트: 제로미 캐리어 (새 탭에서 열림)

데이터독(Datadog)의 제품 엔지니어링 SVP인 제로미 캐리어(Jeromy Carriere)는 엔지니어링 조직의 성패가 단순한 속도가 아닌, 명확한 방향성을 가진 '지속 가능한 속도(Sustained Velocity)'에 달려 있다고 강조합니다. 그는 구글과 페이스북에서의 경험을 바탕으로, 엔지니어링 리더십은 팀의 자율성을 보장하는 것과 결과에 대한 책임을 묻는 것 사이의 균형을 잡는 과정임을 설명합니다. 결론적으로 그는 관측성(Observability)의 미래가 단순한 현상 파악을 넘어 엔지니어가 무엇을 해야 하는지 알려주는 처방적 단계로 진화해야 한다고 주장합니다. **엔지니어링 리더의 다각적 실행 사이클** * **계획 및 실행의 조화:** 분기별 계획 사이클을 통해 팀 간의 협업 기회를 테마별로 연결하고, 실행 사이클에서는 리소스 지원이나 의사결정 정체를 해소하여 팀의 병목 현상을 제거합니다. * **엔지니어링 메타 관리:** 엔지니어링 조직이 어떻게 작동하는지에 대한 프로세스 정의, 채용, 성과 관리 등 조직의 운영 효율성을 높이는 '메타 수준'의 업무에 집중합니다. * **기술적 현장감 유지:** 고위 임원임에도 불구하고 설계 문서와 코드를 읽고, 인시던트 및 사후 분석(Post-mortems)을 관찰하며 전체 스택에서 조직이 어떻게 실행되고 있는지 파악합니다. **데이터독을 선택한 이유: 지속 가능한 속도** * **성장 궤적:** 구글 클라우드 플랫폼 초기 시절 클라우드 모니터링 제품을 구축하며 관측성 분야의 중요성을 체감했고, 이후 페이스북을 거치며 개발자 생산성에 미치는 영향력에 매료되었습니다. * **전략적 속도:** 단순히 빨리 움직이는 것이 아니라, 의도된 전략과 방향성을 가지고 10년 넘게 혁신을 유지하는 데이터독의 '지속 가능한 속도'를 유지하고 확장하는 데 주력하고 있습니다. **실수를 통한 학습과 리더십 철학** * **새로운 실수의 장려:** 과거의 실수를 반복하지 않되, 새로운 실수를 통해 배우고 성장하는 문화를 지향합니다. * **자율성과 책임의 균형:** 초기 커리어의 지나치게 지시적인 태도가 팀의 창의성을 해친다는 것을 깨닫고, 현재는 최대한의 자율성을 부여하되 약속한 결과에 대해서는 엄격히 책임을 묻는 균형점을 추구합니다. * **만족 중심의 커리어 개발:** 5년 단위의 경력 계획보다는 개인이 어떤 업무에서 만족감을 느끼는지 파악하는 것이 중요하며, 리더는 팀원이 이를 발견할 수 있도록 시야를 넓혀주는 역할을 해야 합니다. **관측성 기술의 미래와 실전 경험의 가치** * **처방적 관측성으로의 전환:** 관측성은 "무슨 일이 일어나고 있는가?"라는 질문에서 "내가 무엇을 해야 하며, 어떻게 고쳐야 하는가?"라는 처방적인 단계로 진화하고 있습니다. * **실무 중심의 인재 양성:** 워털루 대학교의 코옵(Co-op) 프로그램이나 데이터독의 인턴십처럼, 학생들이 실제 업무 환경에서 책임감을 가지고 기여할 때 진정한 전문 소프트웨어 개발자로 성장할 수 있습니다. 성공적인 엔지니어링 조직을 구축하기 위해서는 기술적 탁월함만큼이나 조직 운영의 프로세스를 정교하게 다듬는 노력이 필요합니다. 특히 리더는 팀이 스스로 방향을 찾을 수 있도록 자율성을 부여하는 동시에, '지속 가능한 속도'를 유지할 수 있는 전략적 가이드를 끊임없이 제시해야 합니다.

데이터베이스 설계datadog옵저버빌리티software-development+4

datadog·2023년 6월 30일원문

인수 테스트를 신세틱 모니터링으로 마이그레이션한 방법 (새 탭에서 열림)

Datadog의 프론트엔드 개발자 경험(Developer Experience) 팀은 Puppeteer 기반의 불안정한 인수 테스트 시스템을 자사 제품인 'Synthetic Monitoring'으로 전환하여 300명 이상의 엔지니어가 겪던 개발 병목 현상을 해결했습니다. 기존의 수동 스크립팅 방식에서 벗어나 사용자 상호작용을 기록하는 방식으로 전환함으로써 테스트 유지보수 비용을 대폭 절감하고 CI/CD 파이프라인의 안정성을 확보했습니다. 이 과정은 단순한 도구 교체를 넘어, 데이터 기반의 문제 식별과 점진적인 신뢰 구축을 통해 대규모 코드베이스의 테스트 문화를 개선한 사례입니다. ## 기존 Puppeteer 기반 테스트의 문제점 * **높은 불안정성(Flakiness):** 브라우저, 가상 그래픽 엔진, 네트워크 등 제어할 수 없는 외부 요인으로 인해 테스트 결과가 수시로 변하여 개발자들에게 혼란을 주었습니다. * **복잡한 구현 방식:** 버튼 하나를 클릭하기 위해서도 요소의 존재 여부와 활성화 상태를 수동으로 확인하는 스크립트를 작성해야 했으며, 특히 커스텀 드롭다운 같은 복잡한 요소는 구현 난이도가 매우 높았습니다. * **인프라 및 유지보수 부담:** 테스트 코드를 포함한 관련 인프라 코드가 10만 줄에 달했으며, 제품 업데이트 시마다 수동으로 테스트를 수정해야 했습니다. * **긴 실행 시간:** 테스트가 정교해질수록 CI 실행 시간이 늘어나, 가장 긴 작업의 경우 완료까지 약 35분이 소요되는 등 배포 속도를 저해했습니다. ## Synthetic Monitoring을 활용한 솔루션 구축 * **레코딩 기반 테스트:** 코드를 직접 작성하는 대신 실제 페이지 상호작용을 기록하는 방식을 도입하여 스크립팅의 번거로움을 제거했습니다. * **전용 CLI 개발:** CI 환경에서 테스트를 실행하고 결과를 확인할 수 있도록 `synthetics-ci`(이후 `datadog-ci`로 확장)라는 명령줄 도구를 개발했습니다. * **자동화된 워크플로우:** 이 도구는 코드베이스 내의 `.synthetics.json` 파일을 찾아 테스트를 트리거하고, 결과 ID를 폴링(Polling)하여 성공 여부를 사용자에게 가독성 있게 출력합니다. ## 대규모 조직의 성공적인 마이그레이션 전략 * **신뢰 및 데이터 기반 설득:** 정기적인 엔지니어 설문조사를 통해 인수 테스트가 가장 큰 고통임을 데이터로 입증하고, 상세한 문서화와 내부 발표를 통해 새로운 시스템의 이점을 전파했습니다. * **점진적 도입과 비차단(Non-blocking) 모드:** 초기에는 테스트 실패가 전체 빌드를 멈추지 않도록 비차단 작업으로 설정하고 PR 댓글로만 결과를 알림으로써, 개발자들이 시스템에 적응할 시간을 제공했습니다. * **책임 분담과 추적:** Jira를 통해 각 팀에 테스트 소유권을 할당하고 마이그레이션 진행 상황을 추적했으며, 기존 플랫폼을 한 번에 삭제하는 대신 단계적으로 폐지하여 리스크를 최소화했습니다. 이러한 전환 과정은 기술적인 도구의 변화뿐만 아니라, 대규모 조직 내에서 엔지니어들의 신뢰를 얻으며 협업하는 방식의 중요성을 보여줍니다. 새로운 도구가 기존의 고통을 실질적으로 해결해 줄 수 있다는 확신을 주고, 안정적인 전환 프로세스를 제공함으로써 1년여에 걸친 대규모 마이그레이션을 성공적으로 완수할 수 있었습니다.

datadogCI/CDsynthetic-monitoringnode.js+3

datadog·2023년 6월 30일원문

인수 테스트를 신세틱 (새 탭에서 열림)

데이터독(Datadog)은 기존에 사용하던 Puppeteer 기반의 불안정한 인수 테스트 시스템을 자사 제품인 'Synthetic Monitoring'으로 전환함으로써 개발자 경험과 배포 효율성을 대폭 개선했습니다. 1년여에 걸친 이 마이그레이션 과정은 단순한 도구 교체를 넘어, 300명 이상의 엔지니어가 참여하는 대규모 코드베이스의 테스트 신뢰도를 높이고 유지보수 비용을 절감하는 성과를 거두었습니다. 결과적으로 팀은 더 빠른 피드백 루프를 확보하고 안정적인 지속적 통합(CI) 환경을 구축할 수 있었습니다. ### 기존 인수 테스트의 문제점과 한계 * **높은 불안정성(Flakiness):** Puppeteer와 Chromium 헤드리스 브라우저를 기반으로 한 커스텀 러너는 가상 그래픽 엔진과 네트워크 등 제어할 수 없는 외부 요인으로 인해 예기치 않은 테스트 실패가 잦았습니다. * **복잡한 구현 및 유지보수:** 버튼의 활성화 상태를 확인하고 클릭하는 등의 단순한 상호작용조차도 수동 스크립트로 일일이 작성해야 했으며, 제품 업데이트 시마다 수백 개의 테스트 파일을 직접 수정해야 하는 번거로움이 있었습니다. * **인프라 부하 및 실행 시간:** 테스트 규모가 커짐에 따라 CI 작업 시간이 35분 이상으로 늘어났고, 10만 줄 이상의 테스트 관련 코드와 인프라를 유지하기 위해 많은 리소스가 소모되었습니다. ### Synthetic Monitoring 기반의 해결책 도입 * **노코드(No-code) 방식의 테스트 생성:** 직접 스크립트를 작성하는 대신 사용자의 페이지 상호작용을 기록하는 방식을 채택하여 테스트 작성 난이도를 낮추고 직관성을 높였습니다. * **CI/CD 통합 도구 개발:** CI 환경에서 테스트를 트리거하고 결과를 수집하기 위해 `synthetics-ci`(이후 `datadog-ci`로 범용화) CLI를 개발했습니다. 이를 통해 `.synthetics.json` 설정 파일을 기반으로 테스트를 자동 실행할 수 있게 되었습니다. * **유연한 구성 관리:** API를 통해 테스트 결과 ID를 폴링하고 휴먼 리더블(human-readable)한 출력을 제공하여, 개발자가 CI 단계에서 문제를 즉각 파악할 수 있도록 설계했습니다. ### 대규모 조직을 위한 마이그레이션 전략 * **점진적 신뢰 구축:** 초기에는 테스트 실패가 배포를 막지 않는 'Non-blocking' 단계를 도입하여, 엔지니어들이 새로운 시스템에 익숙해질 수 있는 여유를 제공하고 PR 댓글로 결과만 공지했습니다. * **데이터 기반의 설문과 지원:** 분기별 엔지니어 만족도 조사를 통해 고충을 파악하고, 테스트를 가장 많이 보유한 팀들을 대상으로 직접적인 마이그레이션 지원과 교육 세미나를 진행했습니다. * **체계적인 추적과 일몰(Sunset) 전략:** 모든 마이그레이션 과정을 Jira 티켓으로 관리하며 팀별 담당자를 지정했습니다. 기존 플랫폼을 한 번에 제거하는 대신, 개별 테스트가 안정화될 때마다 단계적으로 폐쇄하여 리스크를 최소화했습니다. E2E(End-to-End) 테스트의 유지보수 비용과 불안정성으로 인해 생산성이 저하되고 있다면, 코드 기반의 무거운 테스트 프레임워크 대신 사용자 시나리오 녹화 기능과 CI 통합이 강화된 'Synthetic Monitoring' 류의 도구 도입을 검토해야 합니다. 특히 대규모 조직일수록 기술적 전환뿐만 아니라 문서화, 비차단적(Non-blocking) 테스트 운영 등을 통한 문화적 접근이 마이그레이션 성공의 핵심입니다.

datadog웹 개발synthetic-monitoringnode.js+2

datadog·2023년 6월 16일원문

2023-03-08 사건: 플랫폼 수준 복구에 대한 심층 분석 | Datadog (새 탭에서 열림)

2023년 3월 발생한 대규모 장애 당시 Datadog은 전체 컴퓨팅 용량의 60%를 상실했으며, 이를 복구하기 위해 계층화된 쿠버네티스 구조에 따른 체계적인 재부팅 전략을 수행했습니다. EU1 리전의 복구 과정에서 팀은 단순한 노드 재가동을 넘어 클라우드 제공업체의 피어링 그룹 제한과 서브넷 IP 고갈이라는 예상치 못한 인프라 한계에 직면했습니다. 이 글은 대규모 인프라 장애 시 제어 평면(Control Plane)의 복구 순서와 백로그 처리를 위한 과도한 스케일 아웃이 유발하는 2차 병목 현상을 상세히 다룹니다. **계층적 쿠버네티스 구조와 복구 전략** * Datadog은 관리 효율성을 위해 '부모(Parent)-자식(Child)' 형태의 계층적 클러스터 구조를 사용합니다. 부모 클러스터는 자식 클러스터의 제어 평면을 포드(Pod) 형태로 호스팅하며, 자식 클러스터는 실제 애플리케이션 워크로드를 실행합니다. * 장애의 원인이 된 시스템 패치(Ubuntu 22.04의 systemd-networkd 관련 이슈)로 인해 네트워크 연결이 끊긴 노드들을 복구하기 위해 엄격한 순서에 따른 재부팅을 진행했습니다. * 복구는 (1) 부모 클러스터 제어 평면 노드 재시작, (2) 부모 노드 위에서 실행되는 자식 클러스터 제어 평면 포드 복구, (3) 수천 개의 자식 클러스터 애플리케이션 노드 재시작 순으로 이루어졌습니다. * 특히 제어 평면에 과부하가 걸리지 않도록 노드 재시작 속도를 조절했으며, 워크로드의 중요도에 따라 클러스터별 복구 우선순위를 설정했습니다. **인프라 확장 제한으로 인한 복구 지연** * 모든 컴퓨팅 용량을 복구한 후, 장애 동안 쌓인 대규모 데이터 백로그를 처리하기 위해 급격한 스케일 아웃(Scale-out)을 시도하는 과정에서 예상치 못한 제한에 부딪혔습니다. * **GCP 네트워크 피어링 제한:** EU1 리전 내 인스턴스 수가 15,500개에 도달하며 구글 클라우드의 네트워크 피어링 그룹 제한에 걸려 약 4시간 동안 추가 인스턴스 생성이 차단되었습니다. 이는 구글 측과의 긴급 협력을 통해 한도를 증설하여 해결했습니다. * **서브넷 IP 주소 고갈:** 로그 및 트레이스 처리를 담당하는 특정 클러스터들이 평상시보다 2배 이상 스케일 아웃을 시도하면서 서브넷 내 사용 가능한 IP 주소가 바닥났습니다. * 평소 IP 사용률을 66% 이하로 유지하도록 모니터링해왔으나, 백로그 처리를 위한 폭발적인 수요는 평상시 변동 폭을 훨씬 상회하는 수준이었습니다. 결과적으로 특정 클러스터들은 약 6시간 동안 최적의 속도로 데이터를 처리하지 못했습니다. **교훈 및 실용적 권장사항** 복구 계획을 세울 때는 단순히 시스템을 정상화하는 것을 넘어, 장애 이후 발생할 '데이터 백로그 처리'를 위한 초과 용량 확보 시나리오를 반드시 고려해야 합니다. 클라우드 제공업체의 하드웨어 리소스 한계뿐만 아니라 네트워크 피어링, 서브넷 IP 할당 범위와 같은 소프트웨어적/구성적 제한 사항을 사전에 파악하고, 극단적인 스케일링 상황에서도 유연하게 대처할 수 있는 여유 용량(Headroom) 설계가 필수적입니다.

데이터베이스 설계쿠버네티스datadog클라우드 컴퓨팅+4

datadog·2023년 6월 16일원문

2023-03-08 장애: 플랫폼 차원의 복구 심층 분석 (새 탭에서 열림)

Datadog은 2023년 3월 시스템 패치 오류로 인해 전체 컴퓨팅 용량의 60%를 상실하는 대규모 장애를 겪었으며, 이를 해결하기 위해 EU1 리전을 중심으로 계층적 클러스터 복구 전략을 실행했습니다. 복구 과정에서 쿠버네티스의 부모-자식(Parent-Child) 구조를 활용한 순차적 재부팅을 통해 제어 평면과 워크로드를 정상화했으나, 이후 데이터 백로그 처리를 위한 급격한 확장 단계에서 클라우드 인프라의 물리적 한계에 부딪히기도 했습니다. 결과적으로 이번 사례는 복구 우선순위 설정과 클라우드 공급자의 서비스 임계치 이해가 대규모 인프라 운영에 얼마나 중요한지를 보여줍니다. ## 쿠버네티스 클러스터 계층 구조와 복구 전략 Datadog은 관리 효율성을 위해 쿠버네티스 클러스터 간의 엄격한 계층 구조를 운영하고 있으며, 이는 복구 순서를 결정하는 핵심 요인이 되었습니다. * **부모(Parent) 클러스터**: 각 리전에 존재하며, 다른 클러스터(자식)의 제어 평면(Control Plane) 구성 요소를 파드(Pod) 형태로 호스팅합니다. 부모 클러스터 자체의 제어 평면은 가상 머신(VM)에서 직접 실행됩니다. * **자식(Child) 클러스터**: 실제 Datadog 애플리케이션 워크로드가 실행되는 곳이며, 이들의 제어 평면은 부모 클러스터의 워커 노드 위에서 돌아갑니다. * **복구 메커니즘**: Ubuntu 22.04 패치로 인해 네트워크가 단절된 노드들은 재부팅을 통해 복구가 가능했습니다. 하지만 제어 평면에 접근할 수 없는 상태였기에 가시성 확보와 복구 작업에 초기 난항을 겪었습니다. ## 단계별 클러스터 복구 프로세스 인프라의 의존성을 고려하여 부모 클러스터에서 자식 클러스터 순으로 엄격한 순서에 따라 복구가 진행되었습니다. * **부모 제어 평면 복구 (08:45 UTC 완료)**: 가장 먼저 부모 클러스터의 제어 평면 노드들을 재부팅하여 시스템의 뿌리를 정상화했습니다. * **자식 제어 평면 복구 (09:30 UTC 완료)**: 부모 클러스터 노드 위에서 실행 중인 자식 클러스터용 제어 평면 서비스들을 복구하여 애플리케이션 노드들을 관리할 수 있는 상태로 만들었습니다. * **애플리케이션 노드 복구 (12:05 UTC 완료)**: 수십 개의 클러스터에 퍼져 있는 수천 개의 인스턴스를 재부팅했습니다. 제어 평면의 과부하를 방지하기 위해 워크로드의 중요도에 따라 순차적으로 진행되었습니다. ## 확장 단계에서의 기술적 제약 사항 클러스터 자체는 복구되었으나, 장애 기간 동안 쌓인 데이터 백로그를 처리하기 위해 인프라를 확장하는 과정에서 예상치 못한 한계에 직면했습니다. * **GCP 피어링 그룹 인스턴스 제한**: 백로그 처리를 위해 인스턴스를 늘리던 중, 구글 클라우드(GCP)의 VPC 피어링 그룹당 최대 인스턴스 제한인 15,500개에 도달하여 확장이 중단되었습니다. 이는 문서화된 제한이었으나 극한의 상황에서 임계치에 도달하며 복구를 지연시켰습니다. * **서브넷 IP 주소 고갈**: 로그 및 트레이스 처리를 담당하는 특정 클러스터들이 평상시의 2배 이상으로 오토스케일링을 시도하면서 할당된 서브넷의 IP 주소가 모두 소진되었습니다. * **대응 결과**: Google Cloud 팀의 긴급 지원을 통해 피어링 제한을 상향 조정하고, 리소스 우선순위를 재조정함으로써 대규모 백로그 처리 능력을 확보할 수 있었습니다. 대규모 인프라 장애 복구 시에는 구성 요소 간의 의존성을 명확히 파악하여 복구 순서를 정의하는 것이 필수적입니다. 또한, 평상시에는 도달하기 어려운 클라우드 서비스의 논리적/물리적 임계치(Quota)를 재해 복구 시나리오에 포함하여 확장성 계획을 수립해야 합니다.

쿠버네티스옵저버빌리티클라우드 컴퓨팅cloud-infrastructure+4

datadog·2023년 6월 1일원문

2023-03-08 장애: 장애 대응 심층 분석 (새 탭에서 열림)

2023년 3월 발생한 Datadog의 사상 첫 글로벌 장애는 대규모 복합 시스템을 운영하는 조직에 있어 장애는 '발생 여부'가 아닌 '발생 시기'의 문제임을 다시 한번 각인시켰습니다. Datadog은 수백 명의 엔지니어가 투입된 이 전례 없는 위기 상황에서 '직접 만든 사람이 직접 운영한다(You build it, you own it)'는 원칙과 체계적인 사고 대응(Incident Response) 프로세스를 통해 시스템을 복구할 수 있었습니다. 이번 장애 대응 과정은 기술적 해결을 넘어, 유연한 조직 구조와 비난 없는 문화(Blameless Culture)가 복잡한 시스템의 장애를 해결하는 데 얼마나 결정적인 역할을 하는지 증명했습니다. ### 데이터독의 상시 모니터링 및 대응 체계 * **다중 모니터링 전략:** 서비스 내부 모니터링뿐만 아니라, 플랫폼 전체가 중단된 상황에서도 작동할 수 있도록 외부 인프라에서 독립적으로 구동되는 '아웃 오브 밴드(Out-of-band)' 모니터링을 운영합니다. * **소유권 중심 모델:** 엔지니어가 자신이 구축한 서비스의 온콜(On-call) 업무를 직접 담당하며, 장애 발생 시 수 분 이내에 응답하는 것을 원칙으로 합니다. * **자동화된 협업 환경:** 장애가 선포되면 Slack 앱이 자동으로 전용 채널을 생성하고 상황을 공유하여, 직접 호출되지 않은 엔지니어도 자발적으로 참여할 수 있는 환경을 제공합니다. ### 고난도 장애를 위한 지휘 체계와 역할 분담 * **인시던트 커맨더(Incident Commander, IC):** 고객 영향도가 크거나 여러 팀의 협력이 필요한 고차원 장애 시, 숙련된 시니어 엔지니어가 IC 역할을 맡아 전체 대응을 진두지휘합니다. * **전담 커뮤니케이션 관리:** IC는 복구 작업에 집중하고, 별도의 커뮤니케이션 리드와 고객 연락 담당자(Customer Liaison)가 내부 상황 전파 및 대외 공지를 전담하여 혼선을 방지합니다. * **경영진의 참여:** 심각한 장애 시에는 엔지니어링 임원이 참여하여 비즈니스 맥락에 따른 의사결정을 지원하고 필요한 자원을 즉각 투입합니다. ### 훈련을 통한 숙련도 향상과 자율성 보장 * **낮은 장애 선포 장벽:** 평소 아주 작은 문제라도 장애로 규정하고 대응 프로세스를 가동함으로써, 엔지니어들이 도구와 절차에 익숙해지도록 유도합니다. * **정기적인 온콜 교육:** 모든 엔지니어는 6개월마다 온콜 교육을 이수해야 하며, 여기에는 기술적 절차뿐만 아니라 비난 없는 조사 방식에 대한 교육이 포함됩니다. * **사람 중심의 프로세스:** 미리 정의된 딱딱한 복구 절차(Runbook)에 의존하기보다, 시스템을 가장 잘 아는 엔지니어가 현장에서 최선의 판단을 내릴 수 있도록 자율성을 부여합니다. ### 3월 8일 글로벌 장애의 기술적 분석 및 교훈 * **장애 원인:** `systemd` 업그레이드 과정에서 발생한 예기치 못한 문제가 '무인 업그레이드(Unattended upgrades)'를 통해 확산되며 쿠버네티스 클러스터 실패를 유발했습니다. * **신속한 초기 대응:** 장애 발생 3분 만에 이상이 감지되었고, 30분 이내에 글로벌 장애로 진단되어 대응 체계가 가동되었습니다. * **심리적 안전감의 중요성:** 극심한 스트레스가 동반되는 글로벌 장애 상황에서 비난 없는 문화는 엔지니어들이 위축되지 않고 창의적인 해결책을 찾는 토대가 되었습니다. **실용적인 결론** 대규모 시스템의 장애는 완벽히 막을 수 없으므로, 조직은 **'사람과 문화'**에 투자해야 합니다. 기술적 자동화도 중요하지만, 장애 상황에서 유연하게 대처할 수 있는 숙련된 엔지니어를 양성하고 이들이 비난받을 두려움 없이 복구에 전념할 수 있는 환경을 조성하는 것이 가장 효과적인 재난 대비책입니다. 또한, 평상시 아주 작은 장애라도 공식 프로세스를 거쳐 대응하고 사후 분석(Postmortem)을 작성하는 습관을 통해 조직 전체의 복원력을 높여야 합니다.

쿠버네티스datadog자동화monitoring+4

datadog·2023년 6월 1일원문

2023-03-08 사건: 우리의 사건 대응에 대한 심층 분석 | Datadog (새 탭에서 열림)

Datadog은 2023년 3월 발생한 사상 첫 글로벌 서비스 장애를 겪으며 자사의 장애 대응(Incident Response) 프로세스와 문화를 실전에서 검증했습니다. 수백 명의 엔지니어가 투입된 이번 사태를 통해 Datadog은 "직접 만든 사람이 직접 운영한다(You build it, you own it)"는 원칙과 비난 없는 사후 분석(Blameless Postmortem)의 중요성을 다시 한번 확인했습니다. 이 글은 전례 없는 대규모 장애 상황에서 유연한 의사결정과 체계적인 협업 시스템이 어떻게 복구를 견인했는지에 대한 기술적 기록을 담고 있습니다. **Datadog의 장애 모니터링 및 대응 체계** * **소유권 기반 모델:** 모든 엔지니어링 팀은 자신이 구축한 서비스의 운영을 직접 책임지며, 24시간 모니터링 경보에 몇 분 내로 응답해야 하는 "You build it, you own it" 모델을 따릅니다. * **대역 외(Out-of-band) 모니터링:** 플랫폼 자체가 중단될 경우를 대비해 인프라 외부에서 API를 호출하여 사용자 관점에서 상태를 체크하는 별도의 독립적인 모니터링 시스템을 운영합니다. * **Slack 기반 협업:** 장애 발생 시 전용 앱이 Slack 채널을 자동으로 생성하며, 관련 없는 엔지니어도 자유롭게 참여하여 도움을 줄 수 있는 개방적인 환경을 조성합니다. **고심도 장애(High-Severity) 관리 및 역할 분담** * **장애 지휘관(Incident Commander):** 대규모 장애 시 숙련된 시니어 엔지니어가 투입되어 전체 대응을 진두지휘하며, 복구 전략과 커뮤니케이션을 총괄합니다. * **전담 커뮤니케이션 팀:** 고객 지원 매니저와 경영진이 포함된 별도 팀이 구성되어 외부 고객 및 비즈니스 이해관계자에게 정확한 상태 정보를 전달합니다. * **지속적인 훈련:** 장애 선언 문턱을 낮게 설정하여 일상적으로 장애 대응 프로세스를 연습하며, 모든 엔지니어는 6개월마다 필수 리프레시 교육을 이수해야 합니다. **자율성과 비난 없는 조직 문화** * **절차보다 사람 우선:** 고정된 복구 매뉴얼은 복잡한 시스템의 변화 속도를 따라갈 수 없으므로, 엔지니어가 현장에서 상황에 맞는 최선의 판단을 내릴 수 있도록 자율권을 부여합니다. * **비난 없는 문화(Blameless Culture):** 장애의 원인을 개인의 실수가 아닌 시스템의 결함으로 간주하여, 엔지니어가 압박감 속에서도 창의적인 해결책을 찾을 수 있도록 지원합니다. * **강화된 사후 분석:** 모든 고심도 장애 이후에는 자동화된 알림을 통해 상세한 포스트모템 작성을 독려하며, 이를 통해 유사 장애의 재발을 방지합니다. **3월 8일 글로벌 장애 타임라인 및 초기 진단** * **장애 트리거(06:00 UTC):** systemd 업데이트가 시작되면서 예상치 못한 인프라 연쇄 반응이 발생했습니다. * **신속한 감지(06:03~06:18 UTC):** 장애 발생 3분 만에 모니터링 시스템이 문제를 감지했고, 15분 이내에 고심도 장애로 격상되었습니다. * **원인 파악(07:20~11:36 UTC):** 쿠버네티스(Kubernetes) 노드 실패가 글로벌 장애의 핵심 원인임을 식별했으며, 최종적으로 '무인 업데이트(Unattended upgrades)'가 트리거였음을 밝혀냈습니다. * **인프라 복구(12:05~19:00 UTC):** EU1 및 US1 리전의 컴퓨팅 용량을 순차적으로 복구하고 재발 방지를 위한 완화 조치를 적용하여 전체 인프라를 정상화했습니다. 대규모 시스템을 운영하는 조직이라면 고정된 대응 매뉴얼에 의존하기보다 엔지니어의 자율성을 존중하고, 장애를 학습의 기회로 삼는 비난 없는 문화를 구축하는 것이 중요합니다. 특히 플랫폼 전체가 마비되는 최악의 상황을 대비해 인프라 외부에서 독립적으로 작동하는 '대역 외 모니터링' 체계를 반드시 갖출 것을 추천합니다.

쿠버네티스datadog자동화slack+4

datadog·2023년 5월 26일·2분 읽기큐레이션 요약

단순한 네트워크 지연 문제가

제공된 내용에는 본문이 포함되어 있지 않고, Datadog 웹사이트의 내비게이션 메뉴와 “Gartner® Observability Platforms 매직 쿼드런트의 리더” 홍보 문구만 포함되어 있습니다. 링크 제목으로 보아 네트워크 지연 문제를 다루는 글로 추정되지만, 원인 분석·해결 방법·기술적 결론은 확인할 수 없습니다. ### 제공된 글에서 확인되는 내용 - Datadog이 Gartner의 Observability Platforms 매직 쿼드런트에서 리더로 선정되었다는 홍보 문구가 표시되어 있습니다. - 링크의 캠페인 URL에는 `gartnermq2026-obsplat`가 포함되어 있어 2026년 관측성 플랫폼 평가와 관련된 콘텐츠로 보입니다. - 본문 링크는 `not-just-another-network-latency-issue`이며, 네트워크 지연 문제가 단순한 네트워크 장애가 아닐 수 있다는 주제를 암시합니다. ### Datadog 플랫폼 구성 - **인프라 모니터링** - 호스트, 컨테이너, Kubernetes, 네트워크, 서버리스 환경 모니터링 - 메트릭, 클라우드 비용, 스토리지, GPU 관측성 지원 - **애플리케이션 및 데이터** - APM, 분산 추적, 프로파일링, 동적 계측 - 데이터베이스, 데이터 스트림, 작업 및 데이터 품질 모니터링 - **로그 및 보안** - 로그 관리, 민감 데이터 탐지, 감사 추적, 관측성 파이프라인 - 코드·클라우드·런타임 보안, SIEM, 취약점 및 워크로드 보호 - **디지털 경험** - 브라우저·모바일 RUM, 세션 리플레이, 신세틱 모니터링 - 오류 추적, 제품 분석, 모바일 앱 테스트 - **소프트웨어 전달 및 서비스 관리** - CI 가시성, 테스트 최적화, 코드 커버리지, 기능 플래그 - 인시던트 대응, SLO, 이벤트 관리, 워크플로 자동화 - **AI 기능** - AI 에이전트 관측성, GPU 모니터링, AI 기반 조사 및 대화형 분석 - MCP 서버와 에이전트 빌더 등 개발자용 AI 도구 ### 실용적인 결론 현재 제공된 텍스트만으로는 네트워크 지연 문제에 대한 기술적 요약을 작성하기 어렵습니다. 원문 본문이나 링크의 실제 내용을 제공하면 지연 원인, 관측성 데이터 활용 방식, 문제 해결 절차와 결론을 섹션별로 정확하게 정리할 수 있습니다.

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

쿠버네티스datadog옵저버빌리티애플리케이션 성능 모니터링+3

datadog·2023년 5월 26일원문

단순한 또 하나의 네트워크 지연 문제가 아니었다: 숨겨진 병목 현상의 연쇄를 파헤친 과정 (새 탭에서 열림)

사용량 추정 서비스의 배포 시마다 반복되는 높은 시작 지연 시간(Startup Latency) 문제를 해결하기 위해, 시스템 전반의 네트워크 경로와 인프라 계층을 다각도로 조사했습니다. 단순히 애플리케이션 코드를 수정하는 수준을 넘어, 사이드카 프록시 설정, 리눅스 커널 버그, 클라우드 인스턴스의 네트워크 대역폭 한계 등 복합적인 병목 현상을 단계별로 추적해 해결했습니다. 최종적으로 인프라 최적화와 우아한 종료(Graceful Shutdown) 메커니즘을 결합하여 서비스 안정성을 확보하고 팀의 경보 피로도를 대폭 낮추는 결론에 도달했습니다. **Envoy 사이드카의 CPU 병목 해소** * 배포 단계에서 원격 캐시 데이터를 대량으로 불러올 때, 사이드카 프록시인 Envoy가 모든 쿼리를 배치 처리하며 과도한 CPU를 사용함을 확인했습니다. * Envoy가 할당된 CPU 자원(2코어)을 모두 소진하여 쓰로틀링(Throttling)이 발생했고, 이로 인해 패킷 처리 지연과 TCP 재전송(Retransmit)이 급증했습니다. * Envoy에 할당되는 CPU 자원을 늘려 1차적인 지연 시간 수치를 개선했으나, 여전히 배포 중 지연 시간이 300ms에서 1s 사이를 진동하는 문제가 남았습니다. **리눅스 커널 버그 패치 및 트래픽 분산** * 조사 과정에서 AWS의 Elastic Network Adapter(ENA)를 사용할 때 발생하는 리눅스 커널 버그를 발견했습니다. * 해당 버그는 네트워크 트래픽을 8개의 전송 큐(Transmit Queue)에 분산하지 않고 첫 번째 큐에만 몰아넣어 병목을 유발하고 있었습니다. * 트래픽을 모든 큐에 골고루 분산시키는 핫픽스를 적용하여, 배포 기간 외에 간헐적으로 발생하던 지연 시간 스파이크 문제를 해결했습니다. **AWS 인스턴스 네트워크 대역폭 최적화** * 커널 수정 후에도 배포 중 지연이 지속되자 AWS 전용 메트릭인 `bw_in_allowance_exceeded`와 `bw_out_allowance_exceeded`를 분석했습니다. * 분석 결과, 배포 시 발생하는 급격한 트래픽이 인스턴스 유형별로 할당된 최대 네트워크 대역폭을 초과하여 하이퍼바이저 수준에서 패킷 드롭이 발생하고 있었습니다. * 이를 해결하기 위해 더 높은 대역폭을 제공하는 네트워크 최적화(Network-optimized) EC2 인스턴스로 마이그레이션하여 대역폭 제한 문제를 해결했습니다. **종료되는 파드로의 요청 라우팅 방지** * 모든 인프라 개선 후에도 남아있던 1초 가량의 지연 스파이크가 원격 캐시 파드의 종료(Terminating) 시점과 일치함을 포착했습니다. * 기존의 우아한 종료 로직이 Envoy 클라이언트의 처리 중인 요청(In-flight requests)을 충분히 기다리지 못해, 종료 중인 파드에 요청이 전달되어 타임아웃과 재시도가 발생하고 있었습니다. * 파드에 `preStop` 훅을 구현하여 종료 전 유지 관리 모드 상태임을 클라이언트에 알리고, 모든 요청이 완료될 때까지 대기하도록 설정하여 지연 시간을 최종적으로 안정화했습니다. 성능 최적화 과정에서 단일 원인을 찾기보다 네트워크 스택의 각 계층(프록시, OS 커널, 클라우드 인프라, 애플리케이션 생명주기)을 체계적으로 검증하는 접근 방식이 중요합니다. 특히 대규모 트래픽이 발생하는 배포 시점에는 시스템의 숨겨진 한계치가 드러나기 쉬우므로, 클라우드 제공업체의 전용 메트릭과 네트워크 큐 상태를 면밀히 모니터링할 것을 권장합니다.

데이터베이스 설계linux-kernelaws-ec2envoy+4

datadog·2023년 5월 24일원문

2023-03-08 장애: 플랫폼 수준의 영향에 대한 심층 분석 (새 탭에서 열림)

이 글은 2023년 3월 8일 발생한 Datadog의 대규모 서비스 장애 원인을 분석하고 있습니다. 장애의 근본 원인은 Ubuntu 22.04에 포함된 **systemd-networkd의 기본 동작 변경**과 **자동 보안 업데이트(unattended-upgrades)**가 결합되어, 전 세계 모든 리전의 호스트에서 네트워크 라우팅 규칙이 동시에 삭제되었기 때문입니다. 결과적으로 리전 간 격리 원칙에도 불구하고 클라우드 제공업체와 무관하게 전사적인 네트워크 마비가 발생했습니다. ### systemd-networkd의 동작 변경과 잠복된 위험 * **새로운 기본값 도입:** systemd v248부터 `systemd-networkd`가 시작될 때 자신이 인식하지 못하는 모든 IP 규칙(IP rules)을 삭제(flush)하는 동작이 추가되었습니다. * **버전별 차이:** 이전 LTS 버전인 Ubuntu 20.04(systemd v245)에서는 이 문제가 없었으나, Datadog이 도입한 **Ubuntu 22.04(systemd v249)**는 이 새로운 동작이 기본값으로 설정되어 있었습니다. * **발견 지연의 이유:** 이 현상은 호스트가 처음 생성될 때가 아니라, 실행 중인 상태에서 `systemd-networkd`가 **재시작**될 때만 발생합니다. 평상시에는 재시작할 일이 거의 없었기 때문에 대규모 배포 과정에서도 위험이 감지되지 않았습니다. ### 자동 업데이트(Unattended Upgrades)와 트리거 * **보안 패치의 배포:** 2023년 3월 7일, systemd의 CVE 취약점 해결을 위한 패치가 Ubuntu 저장소에 배포되었습니다. * **자동 업데이트의 동작:** Datadog 서버들은 Ubuntu 기본 설정에 따라 `unattended-upgrades`가 활성화되어 있었으며, 매일 정해진 시간(06:00~07:00 UTC 사이)에 보안 업데이트를 수행하도록 설정되어 있었습니다. * **네트워크 규칙 삭제:** 보안 패치가 설치되면서 `systemd-networkd` 서비스가 재시작되었고, 이 과정에서 Kubernetes 네트워킹 등에 필요한 커스텀 IP 라우팅 규칙들이 "알 수 없는 규칙"으로 간주되어 모두 삭제되었습니다. ### 전 리전 동시 장애 발생 원인 * **일관된 구성의 역설:** 모든 리전이 동일하게 Ubuntu 22.04를 사용하고 동일한 업데이트 타이머 설정을 가지고 있었기 때문에, 리전 간의 물리적 격리에도 불구하고 업데이트와 그에 따른 네트워크 마비가 전 세계적으로 거의 동시에 일어났습니다. * **점진적 배포의 한계:** Datadog은 평소 인프라 변경 시 리전별로 단계적 배포를 수행하지만, OS 패키지 저장소에서 직접 내려받는 자동 보안 업데이트는 이러한 통제된 배포 프로세스를 우회하여 직접 호스트에 적용되었습니다. 이 사건은 인프라의 안정성을 위해 도입한 **자동 보안 패치**가 오히려 시스템의 기저 동작(low-level behavior) 변경과 맞물려 거대한 단일 장애점(Single Point of Failure)이 될 수 있음을 시사합니다. 운영 환경에서는 OS 패키지 업데이트를 포함한 모든 변경 사항이 통제된 파이프라인과 단계적 배포 전략을 거치도록 관리하는 것이 중요합니다.

쿠버네티스cloud-infrastructuresystemdubuntu+4

datadog·2023년 5월 24일원문

2023-03-08 사건: 플랫폼 수준의 영향 깊이 살펴보기 | Datadog (새 탭에서 열림)

2023년 3월 8일 발생한 Datadog의 전사적 서비스 장애는 시스템 관리 데몬인 systemd의 동작 변경과 자동 보안 업데이트 설정이 결합되어 발생한 이례적인 사건입니다. Ubuntu 22.04 환경에서 systemd-networkd가 재시작될 때 기존 IP 라우팅 규칙을 모두 삭제하는 새로운 기본 동작이 활성화되었고, 이것이 전 지역 노드에 동시다발적인 자동 패치로 실행되면서 대규모 네트워크 중단으로 이어졌습니다. 이 사고는 인프라 전반에 걸친 자동화된 변경 관리와 점진적 배포 원칙이 보안 패치라는 예외 상황에서 어떻게 무력화될 수 있는지를 보여줍니다. **systemd-networkd의 IP 규칙 삭제 동작** * 2020년 12월 배포된 systemd v248부터 `systemd-networkd`는 시작 시 자신이 파악하지 못한 모든 IP 규칙(IP rules)을 삭제(flush)하는 동작을 도입했습니다. * 이후 v249에서 `ManageForeignRoutingPolicyRules` 설정을 통해 이 동작을 거부할 수 있는 옵션이 추가되었으나, 기본값은 여전히 기존 규칙을 삭제하는 방식이었습니다. * Datadog이 마이그레이션 중이던 Ubuntu 22.04는 이 위험한 기본 설정이 포함된 systemd v249를 사용하고 있었습니다. **보안 패치와 자동 업데이트의 결합** * 2023년 3월 7일, systemd의 CVE 취약점을 해결하기 위한 보안 패치가 Ubuntu 저장소에 업데이트되었습니다. * Datadog의 서버들은 Ubuntu의 기본 설정인 `unattended-upgrades`를 사용하고 있었으며, 이는 매일 특정 시간(06:00 UTC)에 보안 업데이트를 자동으로 수행하도록 설정되어 있었습니다. * 이 보안 패치가 설치되면서 `systemd-networkd` 서비스가 재시작되었고, 그 즉시 노드의 핵심적인 네트워크 라우팅 규칙들이 모두 삭제되었습니다. **점진적 배포 전략의 무력화** * Datadog은 평소 새로운 OS나 설정을 도입할 때 실험용 클러스터부터 시작해 스테이징, 소규모 리전, 대규모 리전 순으로 수주에 걸쳐 점진적으로 배포하는 엄격한 프로세스를 따릅니다. * 하지만 시스템 레벨의 자동 업데이트(unattended-upgrades)는 이러한 점진적 배포 통제를 우회하여 전 세계 모든 리전의 노드에 거의 동시에 적용되었습니다. * 결과적으로 전체 서버의 90% 이상을 차지하던 Ubuntu 22.04 노드들이 동시다발적으로 네트워크 불능 상태에 빠지게 되었습니다. **실용적인 교훈과 권장사항** 운영 환경에서 OS 배포판을 업그레이드할 때는 시스템 구성 요소(특히 systemd와 같은 핵심 데몬)의 기본 동작 변경 사항을 상세히 검토해야 합니다. 또한, 보안을 위한 자동 업데이트라 할지라도 인프라 전체에 동시에 적용되는 방식은 위험할 수 있으므로, 업데이트 주기를 리전별로 분산하거나 자체적인 패키지 미러를 통해 보안 패치 역시 점진적 배포 파이프라인의 통제하에 두는 것이 권장됩니다.

쿠버네티스Docker & 컨테이너systemdubuntu+4

datadog·2023년 4월 17일원문

fetch를 현실로 만들기: 범용 쿼리 및 렌더링 스케줄러 구축 (새 탭에서 열림)

데이터독(Datadog)은 복잡한 대시보드의 성능 최적화를 위해 쿼리와 렌더링 작업을 효율적으로 관리하는 범용 스케줄러를 개발했습니다. 기존의 복잡한 규칙 기반 시스템을 단순화하고 브라우저 네이티브 API를 활용함으로써, UI 응답성을 높이고 백엔드 부하를 안정화하는 성과를 거두었습니다. 이 글은 기존 스케줄러의 한계를 극복하고 모든 애플리케이션에 적용 가능한 유연한 스케줄링 모델로 전환한 과정을 다룹니다. ### 기존 스케줄러(v1)의 문제점 * **지나친 복잡성:** 약 20여 개의 매개변수가 얽힌 복잡한 휴리스틱(heuristics)으로 운영되어, 개발자가 시스템의 동작 방식을 예측하거나 추론하기 어려웠습니다. * **로직의 결합:** 쿼리(데이터 호출)와 렌더링(화면 표시) 스케줄링이 명확히 분리되지 않았습니다. 예를 들어, 렌더링 대기 작업이 많다는 이유로 연관 없는 쿼리 요청이 지연되는 등의 비효율이 발생했습니다. * **낮은 범용성:** 대시보드 환경에만 특화되어 설계되었기 때문에, 데이터독의 다른 제품군이나 일반적인 위젯 컴포넌트에서 재사용하기 어려운 구조적 한계가 있었습니다. ### 데이터 쿼리 스케줄링의 단순화 * **가시성 기반 우선순위:** 화면에 보이는(visible) 위젯의 쿼리는 요청 즉시 실행하고, 화면 밖(offscreen) 위젯은 별도의 대기열에 추가하여 지연 처리합니다. * **고정 시간 윈도우 알고리즘:** 복잡한 계산 대신 2,000ms라는 고정된 시간 창(window) 동안 최대 10개의 태스크만 실행하도록 제한하여 작업 분포를 평탄화했습니다. * **대기열 관리 최적화:** 백엔드에 펜딩된 요청이 너무 많으면 실행을 일시 중단하며, 화면 밖 작업들은 대기열에 들어온 순서대로 처리하여 공정성을 유지합니다. * **도입 결과:** 로직이 단순해졌음에도 불구하고 서버의 '429(Too many requests)' 에러가 크게 감소했으며, 쿼리 재시도 횟수가 줄어들어 전체적인 데이터 로딩 속도가 향상되었습니다. ### Browser Scheduling API를 활용한 렌더링 최적화 * **자원 상태 인지:** 기존 스케줄러는 브라우저의 CPU나 메모리 가용 상태를 알지 못한 채 작업을 할당했으나, 새로운 시스템은 브라우저 네이티브 기능을 활용합니다. * **우선순위 세분화:** 최신 `Browser Scheduling API`의 `postTask` 메서드를 도입하여 작업의 성격에 따라 우선순위(user-blocking, user-visible, background)를 부여합니다. * **효율적인 메인 스레드 사용:** 브라우저가 직접 작업의 우선순위를 제어하게 함으로써, 중요한 UI 업데이트는 즉시 처리하고 덜 중요한 렌더링은 브라우저가 유휴 상태일 때 실행하도록 최적화했습니다. 복잡한 웹 애플리케이션에서 성능을 확보하려면 스케줄링 로직을 최대한 단순화하고 브라우저가 제공하는 표준 API를 적극적으로 활용해야 합니다. 이는 개발자에게는 시스템에 대한 통제력을 제공하며, 사용자에게는 더 매끄러운 인터랙션 경험을 선사합니다.

데이터베이스 설계성능 최적화query-schedulingbrowser-scheduling-api+4

datadog·2023년 4월 17일원문

fetch 실현하기: 범용 (새 탭에서 열림)

Datadog은 대규모 대시보드의 복잡한 데이터 페칭과 렌더링 성능을 최적화하기 위해 기존의 복잡한 휴리스틱 기반 스케줄러를 단순화하고 범용적인 시스템으로 재설계했습니다. 새로운 스케줄러는 쿼리와 렌더링 로직을 분리하고 가시성 중심의 작업 분배 알고리즘을 도입하여 백엔드 부하를 줄였으며, 최신 브라우저 스케줄링 API를 통해 런타임 성능을 극대화했습니다. 결과적으로 코드의 복잡성은 대폭 낮아졌고, API 호출 오류 감소와 함께 전반적인 사용자 경험이 향상되는 성과를 거두었습니다. ### 기존 스케줄러(v1)의 구조적 한계 * 20개 이상의 복잡한 매개변수와 서로 얽힌 휴리스틱으로 구성되어 있어, 개발자가 시스템의 동작을 예측하거나 유지보수하기 매우 어려웠습니다. * 쿼리(데이터 페칭)와 렌더링 스케줄링이 명확히 분리되지 않아, 렌더링 작업이 지연될 때 연관 없는 쿼리까지 함께 지연되는 비효율이 발생했습니다. * 대시보드 환경에만 특화된 로직으로 작성되어 있어, Datadog 내의 다른 제품이나 일반적인 위젯 컴포넌트에서 재사용하기 어려운 구조였습니다. ### 단순하고 효율적인 쿼리 스케줄링 알고리즘 * 화면에 보이는(Visible) 위젯의 쿼리는 즉시 실행하고, 비가시적 위젯의 쿼리는 큐에 쌓아 순차적으로 처리하는 단순한 방식을 채택했습니다. * 비가시적 쿼리는 2000ms의 고정된 시간 윈도우 내에서 최대 10개까지만 실행하도록 제한하여 백엔드 서비스의 부하를 안정화했습니다. * 브라우저가 자체적으로 처리하는 탭 포커스 여부 확인 등의 불필요한 체크 로직을 제거하여 관리 매개변수를 20개에서 6개로 줄였습니다. * 효율적인 작업 분산을 통해 '429(Too many requests)' 에러 발생률을 낮추었으며, 이는 결과적으로 재시도 횟수를 줄여 데이터 로딩 속도를 개선했습니다. ### Browser Scheduling API를 통한 렌더링 제어 * 브라우저의 CPU 및 메모리 자원 상태를 고려하지 못하던 기존 방식의 한계를 극복하기 위해 네이티브 브라우저 스케줄링 API(`postTask`)를 도입했습니다. * 작업을 중요도에 따라 `user-blocking`(사용자 차단), `user-visible`(사용자 가시), `background`(백그라운드) 세 단계로 분류하여 브라우저가 최적의 시점에 실행하도록 위임했습니다. * 중요도가 낮은 렌더링 작업은 브라우저가 유휴 상태일 때 실행되도록 설정하여 메인 스레드의 병목 현상을 방지하고 부드러운 UI 반응성을 확보했습니다. * `TaskController`를 활용해 특정 그룹의 작업 우선순위를 일괄 변경하거나 불필요한 작업을 즉시 중단(abort)할 수 있는 제어 구조를 갖추었습니다. 애플리케이션의 성능 최적화를 고려한다면 복잡한 자체 규칙을 만들기보다 가시성(Visibility)과 같은 핵심 지표에 집중하고, 최신 브라우저가 제공하는 스케줄링 표준 API를 활용하여 시스템 자원을 효율적으로 관리하는 것이 바람직합니다.

datadogquery-schedulingbrowser-scheduling-apitask-optimization+3

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 환경에서는 워커가 처리하는 테넌트의 카디널리티를 물리적으로 제한하는 것이 스토리지 관리 비용을 결정짓는 핵심 요소가 됩니다.

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