kakao·2025년 11월 19일원문

POPM 과정은 어떻게 하나의 ‘제품’이 되었나 (새 탭에서 열림)

카카오의 POPM 교육은 단순한 지식 전달 과정을 넘어, PO와 PM이 공통의 언어로 협업하고 문제를 해결할 수 있도록 돕는 하나의 '제품'으로 설계되었습니다. 교육 과정을 제품 개발 프로세스와 동일하게 '구조화'와 '반복 실험'의 관점에서 접근했으며, 수강생의 피드백을 데이터로 치환하여 지속적으로 기능을 개선하듯 커리큘럼을 고도화했습니다. 결과적으로 이 과정은 전략이 실제 실행으로 이어지도록 만드는 조직 차원의 구조적 프레임워크를 구축하는 성과를 거두었습니다. **POPM 교육의 탄생 배경과 목적** * PO와 PM의 역할이 모호하고 비가시적인 업무가 많아 발생하는 의사결정의 혼선을 줄이기 위해 시작되었습니다. * 문제 정의, 지표 해석, 실험 설계 등 실무에서 반복되는 질문들에 대해 조직이 공유할 수 있는 공통 언어를 수립하는 것이 핵심 목표입니다. * PO의 전략적 고민과 PM의 실행이 단절되지 않고 하나의 목표로 이어질 수 있는 구조적 기틀을 마련하고자 했습니다. **제품 개발 프로세스를 닮은 교육 설계** * 파일럿 과정(1기)의 8개 세션을 시작으로, 매 기수마다 '사용자 피드백'을 반영하여 구조를 최적화했습니다. * 3기부터는 '전략 → 지표 → 실험 → 디자인 → 실행'의 5개 핵심 세션으로 고정하여 흐름을 단순화하고 몰입도를 높였습니다. * 교육 설계자는 PM의 관점에서 교육을 하나의 제품으로, 각 세션을 기능으로, 각 기수를 소프트웨어 버전으로 정의하여 반복 개선을 수행했습니다. **데이터 기반의 기회 점수 도출과 리디자인** * 수강생 대상의 사전/사후 설문을 통해 각 세션의 '중요도'와 '만족도' 매트릭스를 분석했습니다. * 중요도는 높으나 만족도가 낮은 영역(예: 데이터/지표 세션)을 '기회 영역'으로 정의하고, 이를 제품 기능의 우선순위처럼 취급하여 최우선적으로 개선했습니다. * 단순한 내용 수정을 넘어 슬라이드 재구성, 실습 난이도 조정, 워크시트 포맷 변경 등 구조적인 해결책을 적용하여 기회 점수를 관리했습니다. **설계자가 얻은 구조적 인사이트** * 교육은 사람의 변화보다 '구조의 누적'에 집중해야 하며, 시스템이 바뀌지 않으면 동일한 시행착오가 반복된다는 점을 확인했습니다. * 지식의 전달보다 '질문의 리듬'을 설계하는 것이 중요하며, 슬라이드 하나에도 질문과 예시, 흐름을 유기적으로 배치하여 수강생의 사고를 유도했습니다. * 실습의 목적은 정답 작성이 아니라 '생각의 구조화'에 있으며, 실습 과정이 실제 팀의 업무 루틴으로 자연스럽게 이어지도록 설계했습니다. 조직 내 교육이나 프로세스를 설계할 때 이를 하나의 고정된 커리큘럼이 아닌, 지속적으로 개선 가능한 '제품'으로 바라보는 시각이 필요합니다. 수강생을 사용자로 정의하고 그들의 불편함을 데이터로 측정하여 구조를 개선해 나간다면, 교육은 단순한 학습을 넘어 조직의 실행력을 높이는 강력한 도구가 될 수 있습니다.

metrics프로덕트 디자인product-managementdata-analysis+3

datadog·2025년 6월 24일·2분 읽기큐레이션 요약

서버 의존성 없는 실시간

Datadog의 Gartner® Observability Platforms 2026 매직 쿼드런트 리더 선정 소식을 홍보하는 페이지로 보입니다. 제공된 내용에는 본문 대신 Datadog 제품 메뉴와 링크 목록이 대부분 포함되어 있어, 선정 근거와 기술적 세부사항은 확인할 수 없습니다. ### Gartner 매직 쿼드런트 리더 선정 - Datadog이 **Gartner® Magic Quadrant™ for Observability Platforms 2026**에서 Leader로 선정되었다고 안내합니다. - 연결된 페이지는 Datadog의 관측성 플랫폼 경쟁력과 관련된 자료를 제공하는 리소스 페이지로 보입니다. - 다만 제공된 텍스트에는 평가 기준, 경쟁사 비교, Datadog의 강점과 개선점에 대한 Gartner의 구체적인 분석이 포함되어 있지 않습니다. ### Datadog의 인프라·애플리케이션 관측성 - 인프라 모니터링 - 호스트, 메트릭, 컨테이너, Kubernetes, 네트워크, 서버리스 환경 모니터링 - GPU, 스토리지, 클라우드 비용 관리 기능 제공 - 애플리케이션 모니터링 - APM, 서비스 모니터링, 지속적 프로파일링, 동적 계측 - AI 에이전트 관측성 기능 포함 - 데이터 및 데이터베이스 - Database Monitoring, Data Streams Monitoring - 데이터 품질 및 작업(Job) 모니터링 ### 로그 및 보안 기능 - 로그 관리와 Observability Pipelines를 통해 로그 수집·처리·전송을 지원합니다. - Sensitive Data Scanner로 민감정보를 탐지하고, Audit Trail로 활동을 추적합니다. - 코드 보안, SAST, IaC 보안, 클라우드 보안, SIEM, 워크로드 보호 등 보안 기능도 플랫폼에 통합되어 있습니다. ### 디지털 경험과 소프트웨어 제공 - Browser·Mobile RUM, 세션 리플레이, Synthetic Monitoring으로 사용자 경험을 분석합니다. - 오류 추적, 제품 분석, 실험 기능을 제공합니다. - CI Visibility, 테스트 최적화, 지속적 테스트, 코드 커버리지, Feature Flags 등 개발·배포 과정도 관측 대상에 포함합니다. ### 서비스 관리와 AI - 이벤트 관리, 서비스 카탈로그, SLO, 인시던트 대응, 워크플로 자동화를 제공합니다. - Watchdog과 Bits 계열 AI 기능을 활용해 이상 탐지, 조사, 자동화, 보안 분석을 지원합니다. - MCP Server, AI 에이전트, GPU 모니터링 등 AI 운영 환경을 위한 기능도 포함되어 있습니다. 실제 글의 핵심 주장과 평가 근거를 정확히 요약하려면, 제품 메뉴가 아닌 본문 전체나 Gartner 평가 내용이 추가로 필요합니다.

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

metrics쿠버네티스datadog옵저버빌리티+3

figma·2025년 2월 10일·3분 읽기큐레이션 요약

의미 있는 지표 만들기 | 디자인

디자인 시스템은 컴포넌트와 문서를 만드는 데서 끝나지 않고, 사용 데이터로 실제 비즈니스 가치를 입증해야 한다. 적절한 지표를 추적하면 디자인 시스템이 작업 속도, 일관성, 확장성에 미친 영향을 정량화하고 투자와 개선의 근거로 활용할 수 있다. Figma의 실험에서는 디자인 시스템을 사용한 디자이너가 그렇지 않은 디자이너보다 작업을 34% 빠르게 완료했다. ### 디자인 시스템의 효과를 수치로 증명하기 - 디자인 시스템 사용으로 얻는 효과는 단순한 시간 절약을 넘어, 제품 전체와 일관된 디자인을 만든다는 자신감 향상으로도 나타난다. - 디자이너 7명이 주당 20시간씩 집중적으로 일하는 팀에서 34%의 효율 향상은 매주 약 3.5명의 디자이너를 추가한 것과 같은 효과다. - Vanguard는 디자인 시스템을 통해 디자인 업데이트 속도를 50% 높였다. - Headspace는 토큰과 변수를 활용해 단순한 작업에서 20~30%, 복잡한 프로젝트에서 최대 50%의 시간을 절약했다. - Swiggy는 체계적인 추적을 도입한 뒤 기능 출시 시간을 절반으로 줄였다. ### 어떤 신호를 측정할 것인가 - **라이브러리 및 컴포넌트 사용량** - 어떤 컴포넌트, 변수, 스타일이 가장 많이 사용되는지 확인한다. - 자주 사용되는 요소는 디자인 시스템의 핵심 자산으로 볼 수 있다. - 사용량이 낮은 요소는 개선하거나 폐기할 후보가 된다. - **도입률** - 팀과 프로젝트가 디자인 시스템을 실제로 얼마나 채택했는지 측정한다. - 시스템이 존재하는 것보다 실제 업무에 활용되는지가 중요하다. - **일관성 점수** - 제품 전반에서 컴포넌트와 스타일이 얼마나 일관되게 사용되는지 확인한다. - 일관성 지표는 디자인 품질과 유지보수성의 변화를 보여준다. - **절약된 시간** - 컴포넌트 재사용으로 줄어든 디자인 시간을 추적한다. - 시간 절약은 이해관계자에게 디자인 시스템의 투자 가치를 설명하기 좋은 지표다. ### 사용량 데이터가 알려주는 것 - 초기에는 컴포넌트 제작과 문서화 자체에 집중하기 쉽지만, 실제 영향력을 파악하려면 adoption과 usage를 함께 측정해야 한다. - 단순히 컴포넌트 수가 많다는 사실보다 어떤 요소가 실제 업무에서 반복적으로 사용되는지가 중요하다. - 데이터는 다음과 같은 개선 방향을 제시한다. - 자주 사용되는 요소의 품질과 문서 개선 - 사용되지 않는 요소의 원인 분석 - 중복 컴포넌트 통합 - 사용성이 낮은 요소의 재설계 또는 폐기 - 이러한 분석을 통해 디자인 시스템을 정적인 리소스가 아니라 지속적으로 개선되는 운영 체계로 만들 수 있다. ### 도구와 자동화의 활용 - 지표를 지속적으로 수집하려면 사용량과 도입률을 수작업으로 조사하기보다 도구와 자동화를 활용해야 한다. - 컴포넌트, 변수, 스타일의 사용 현황을 정기적으로 수집하면 변화 추이를 파악할 수 있다. - 자동화된 측정은 팀 규모가 커져도 동일한 기준으로 성과를 비교하고, 문제를 조기에 발견하는 데 도움이 된다. ### 데이터를 실행으로 연결하기 - 측정 자체가 목적이 아니라, 데이터를 바탕으로 디자인 시스템의 우선순위를 정하는 것이 중요하다. - 사용량이 높은 요소에는 안정성, 접근성, 문서화 개선을 우선 적용할 수 있다. - 도입률이나 일관성이 낮은 영역은 교육, 문서, 지원 프로세스를 보완해야 한다. - 시간 절약과 출시 속도 같은 지표는 디자인 시스템 팀의 활동을 제품 및 비즈니스 성과와 연결해준다. ### 확장을 고려한 측정 - 조직과 제품이 성장할수록 개인의 체감 효과보다 팀 전체의 반복 가능한 지표가 필요하다. - 사용량, 도입률, 일관성, 절약 시간 등을 지속적으로 기록하면 디자인 시스템이 확장 과정에서 효율성을 유지하는지 확인할 수 있다. - 지표는 단순한 보고용 숫자가 아니라, 디자인 시스템의 투자 방향과 운영 방식을 결정하는 기준으로 활용해야 한다. 실무에서는 모든 지표를 한꺼번에 도입하기보다 컴포넌트 사용량, 디자인 시스템 도입률, 작업 시간 절감처럼 측정하기 쉽고 의사결정에 직접 연결되는 지표부터 시작하는 것이 좋다.

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

metricsFigma디자인 시스템디자인 토큰+2

datadog·2025년 1월 29일·2분 읽기큐레이션 요약

Husky: Datadog 규모에서의

Datadog이 Gartner의 2026년 Observability Platforms 매직 쿼드런트에서 Leader로 선정되었다는 내용이 핵심입니다. 다만 제공된 본문에는 선정 근거와 평가 세부 내용보다 Datadog 제품 메뉴와 링크가 대부분 포함되어 있어, 기술적 분석이나 구체적인 비교 내용은 확인하기 어렵습니다. ### Gartner 매직 쿼드런트 선정 - Datadog은 Gartner의 Observability Platforms 부문에서 Leader로 소개되었습니다. - 이는 인프라, 애플리케이션, 로그, 사용자 경험 등 여러 관측성 영역을 하나의 플랫폼에서 제공하는 역량과 관련된 것으로 볼 수 있습니다. - 단, 제공된 내용만으로는 Gartner의 평가 기준, Datadog의 구체적인 점수, 경쟁사 대비 강점은 알 수 없습니다. ### Datadog의 관측성 제품 범위 - **인프라 모니터링** - 메트릭, 호스트·컨테이너·Kubernetes 모니터링 - 네트워크, 서버리스, GPU, 클라우드 비용 및 스토리지 관리 - **애플리케이션 성능 관리** - APM, 분산 추적, Continuous Profiler - 동적 계측과 서비스 모니터링 - **로그 및 데이터 관측성** - 로그 관리, Observability Pipelines - 데이터베이스, 데이터 스트림, 데이터 품질 및 작업 모니터링 - **디지털 경험** - Browser·Mobile RUM - 세션 리플레이, Synthetic Monitoring, 오류 추적 및 제품 분석 - **소프트웨어 개발·운영** - CI Visibility, 테스트 최적화, 코드 커버리지 - 서비스 카탈로그, SLO, 인시던트 대응, 워크플로 자동화 - **보안** - 클라우드 보안, 취약점 관리, SIEM - 코드 보안, SAST, IAST, IaC 보안 및 워크로드 보호 - **AI 및 자동화** - Bits AI 에이전트, 조사·보안 분석 도구 - AI 에이전트 관측성, MCP Server, GPU 모니터링 ### 제공된 내용의 한계 - 본문에는 실제 기술 블로그의 상세 설명이나 구현 방식이 포함되어 있지 않습니다. - 링크 경로에는 `husky-storage-compaction`이 표시되지만, Husky 스토리지 압축(compaction)에 관한 본문은 제공되지 않았습니다. - 따라서 스토리지 압축 전략, 데이터 보존 정책, 성능 개선 수치 등의 기술적 결론은 도출할 수 없습니다. 실제 글의 본문을 추가로 제공하면 Gartner 선정 내용이나 Husky 스토리지 컴팩션 설계를 섹션별로 구체적으로 요약할 수 있습니다.

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

metrics쿠버네티스datadog옵저버빌리티+2

datadog·2024년 5월 1일·3분 읽기큐레이션 요약

임의의 규모에서 시간에 따른

Datadog의 Heatmap은 시간에 따른 값의 분포를 시각화해 평균이나 단일 백분위수만으로는 보이지 않는 이상치와 분산을 보여준다. 핵심은 대규모 원시 데이터를 모두 저장하거나 조회하지 않고도 분포 정보를 유지하는 근사 자료구조와 다단계 집계를 활용하는 것이다. 그 결과 데이터 규모와 조회 범위가 커져도 일정한 응답성과 시각화 품질을 제공한다. ## 평균 그래프만으로는 부족한 이유 - 평균값은 데이터의 분산, 꼬리 분포, 이상치를 숨길 수 있다. - 예를 들어 요청 시간의 평균이 200ms여도 일부 요청이 수 초 이상 걸리면 사용자 경험에 큰 문제가 생길 수 있다. - Heatmap은 다음 두 축을 함께 표현한다. - 가로축: 시간 - 세로축: 관측값의 크기 - 색상: 해당 시간대와 값 구간에 포함된 데이터 수 또는 밀도 - 이를 통해 특정 시간대에 지연 시간이 어느 구간에 집중됐는지, 긴 꼬리가 발생했는지 확인할 수 있다. ## 대규모 분포 데이터를 다루는 문제 - 모든 원시 측정값을 저장한 뒤 요청마다 분포를 계산하면 저장 공간과 조회 비용이 지나치게 커진다. - 데이터가 많을수록 정확한 히스토그램을 만들기 위해 필요한 값 구간도 복잡해진다. - 시간 범위와 화면 크기에 따라 필요한 시간 버킷 수가 달라지므로, 고정된 해상도의 데이터만으로는 확대·축소와 다양한 쿼리를 지원하기 어렵다. - 따라서 저장 단계에서부터 분포를 압축하고, 조회 시 필요한 해상도로 재구성할 수 있어야 한다. ## 스케치 기반 분포 집계 - Datadog은 개별 값을 모두 보관하는 대신 분포를 요약하는 스케치 자료구조를 사용한다. - 스케치는 값의 정확한 목록을 저장하지 않고, 값이 어떤 범위에 얼마나 많이 존재하는지를 근사한다. - 이러한 구조는 다음 특성을 가진다. - 메모리 사용량이 데이터 개수에 비례해 계속 증가하지 않는다. - 여러 호스트나 서비스에서 생성한 스케치를 병합할 수 있다. - 분산 환경에서 수집기와 저장소가 독립적으로 집계할 수 있다. - 평균, 분위수, 개수 등 분포 관련 질의를 효율적으로 계산할 수 있다. - 특히 로그 형태의 값 분포를 다룰 때는 작은 값에는 세밀한 구간을, 큰 값에는 상대적으로 넓은 구간을 적용해 넓은 값 범위를 적은 수의 버킷으로 표현할 수 있다. ## 시간축과 값축의 버킷화 - Heatmap은 데이터를 시간 구간과 값 구간의 2차원 셀로 나누어 표현한다. - 각 셀에는 해당 시간·값 범위에 속하는 관측치의 개수가 저장된다. - 시간축은 조회 범위와 화면의 픽셀 수에 맞춰 적절한 해상도로 조정된다. - 값축 역시 선형 또는 로그 스케일로 변환할 수 있어, 밀리초 단위의 작은 지연과 수 초 단위의 큰 지연을 동시에 표현할 수 있다. - 확대하면 더 세밀한 버킷을 사용하고, 축소하면 여러 버킷을 합쳐 전송 데이터와 렌더링 비용을 줄인다. ## 병합 가능한 집계의 장점 - 각 에이전트, 호스트, 서비스 또는 시간 파티션에서 만든 요약 데이터를 중앙에서 병합할 수 있다. - 병합은 원시 데이터를 다시 전송하는 것보다 훨씬 적은 네트워크·저장 비용으로 수행된다. - 서로 다른 집계 수준의 데이터를 조합할 수 있으므로 짧은 기간은 높은 정밀도로, 긴 기간은 낮은 정밀도로 조회할 수 있다. - 이 방식은 데이터 수가 매우 많아져도 처리 비용을 원시 이벤트 수가 아닌 요약 데이터 크기에 가깝게 유지한다. ## 시각화와 성능의 균형 - 브라우저가 모든 이벤트를 직접 처리하지 않고, 서버가 화면에 필요한 형태의 버킷 데이터를 반환한다. - 프런트엔드는 반환된 셀의 개수와 색상 강도를 이용해 캔버스 또는 유사한 그래픽 방식으로 Heatmap을 그린다. - 데이터 해상도를 화면 크기에 맞추면 다음 효과를 얻을 수 있다. - 불필요한 데이터 전송 감소 - 렌더링 속도 향상 - 확대·축소와 시간 범위 변경에 대한 빠른 응답 - 다만 근사 집계이므로 정확한 원시값 목록이 필요한 분석에는 적합하지 않고, 전체적인 분포와 이상 패턴을 파악하는 용도로 사용하는 것이 적절하다. ## 실용적인 결론 평균이나 단일 백분위수만으로 시스템 상태를 판단하기보다 Heatmap으로 분포 전체를 확인하면 지연 시간 급증, 이상치, 특정 구간의 집중 현상을 더 쉽게 발견할 수 있다. 대규모 관측 데이터를 처리하는 시스템을 설계할 때는 원시 데이터 보존과 별개로 병합 가능한 스케치, 다단계 시간 버킷, 화면 해상도 기반 쿼리를 함께 고려하는 것이 효과적이다.

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

metricsdatadog옵저버빌리티data-visualization+1

datadog·2022년 5월 17일원문

Datadog의 3세대 이벤트 스토어, Husky를 소개합니다 (새 탭에서 열림)

데이터독(Datadog)은 폭발적인 데이터 증가와 다양한 제품군의 요구사항을 충족하기 위해 새로운 이벤트 저장 시스템인 '허스키(Husky)'를 구축했습니다. 기존 시스템은 대규모 멀티테넌트 환경에서 발생하는 성능 간섭과 고비용 구조, 데이터 삭제의 어려움이라는 한계에 봉착했으며, 이를 해결하기 위해 저장소와 클러스터링을 분리하고 효율성을 극대화한 새로운 아키텍처가 필요했습니다. 결과적으로 허스키는 로그, RUM, 보안 데이터 등 다양한 고카디널리티(High-cardinality) 이벤트를 경제적이고 안정적으로 처리할 수 있는 기반이 되었습니다. ### 메트릭과 로그의 기술적 차이 * **메트릭의 효율성:** 메트릭 시스템은 데이터를 `<timeseries_id, timestamp, float64>` 형태의 튜플로 사전 집계하여 저장합니다. '델타-오브-델타(delta-of-delta)' 인코딩을 통해 16바이트 데이터를 2바이트 미만으로 압축할 수 있어 매우 효율적이지만, 태그 카디널리티에 제한이 있습니다. * **로그의 복잡성:** 로그는 이벤트당 킬로바이트(KB) 단위의 크기를 가지며, UUID나 스택 트래적(stack traces)과 같은 고카디널리티 데이터를 포함해야 합니다. 로그 시스템은 모든 문맥(context)을 보존하면서 쿼리 시점에 임의의 차원으로 집계할 수 있는 능력이 필수적입니다. ### 초기 아키텍처의 한계와 클러스터링 개선 * **초기 버전의 문제:** 멀티테넌트 클러스터 내에서 단일 노드의 장애나 특정 테넌트의 과부하가 전체 클러스터의 가용성을 떨어뜨리는 '노이즈 네이버(Noisy Neighbor)' 문제가 빈번했습니다. * **저장소와 클러스터링 분리:** 두 번째 버전에서는 저장 엔진과 클러스터링 로직을 분리했습니다. '샤드 라우터(Shard Router)'가 카프카(Kafka)를 통해 데이터를 샤드 단위로 정리하고, 각 노드는 독립적인 유닛으로 동작하게 하여 장애 전파를 차단했습니다. * **커스텀 쿼리 엔진:** 여러 샤드에 분산된 데이터를 쿼리하고 부분 집계 결과를 병합하는 전용 엔진을 도입하여 신뢰성을 높였습니다. ### 플랫폼 급성장과 새로운 요구사항의 등장 * **제품군의 확장:** 로그뿐만 아니라 네트워크 성능 모니터링(NPM), 실제 사용자 모니터링(RUM), 프로파일러 등 다양한 제품이 출시되면서 저장해야 할 이벤트의 양과 종류가 급증했습니다. * **장기 보관 비용 문제:** 가끔 쿼리하지만 장기간 보관이 필요한 데이터를 기존 아키텍처에서 운영하는 것은 비용 효율성이 낮았습니다. * **데이터 관리 편의성:** GDPR 대응을 위한 특정 데이터의 정밀한 삭제 기능과 테넌트 간의 완전한 자원 격리에 대한 요구가 강해졌습니다. ### 허스키(Husky)의 설계 방향 * **범용 이벤트 저장소:** 로그와 유사한 구조를 가진 모든 유형의 데이터를 수용할 수 있는 유연한 스키마 구조를 지향합니다. * **비용 효율적인 확장:** 스토리지 계층화를 통해 자주 사용되지 않는 데이터는 저렴한 저장소에 보관하면서도 즉시 쿼리가 가능한 구조를 구축했습니다. * **격리 및 제어권 강화:** 특정 테넌트의 트래픽 급증이 다른 테넌트의 쿼리 성능에 영향을 주지 않도록 정교한 할당량(Quota) 관리와 격리 메커니즘을 포함했습니다. 시스템을 설계할 때 단순히 현재의 성능 개선에만 집중하는 것이 아니라, 향후 데이터의 기하급수적인 증가와 다양한 제품 요구사항(비용, 삭제, 격리)을 수용할 수 있는 아키텍처 유연성을 확보하는 것이 중요합니다. 특히 대규모 멀티테넌트 환경에서는 '폭포수 장애'를 방지하기 위해 각 구성 요소를 최대한 독립적으로 격리하는 설계가 필수적입니다.

metrics데이터베이스 설계datadogApache Kafka+4

datadog·2019년 9월 23일·3분 읽기큐레이션 요약

DDSketch로 정확한 백

Datadog의 글은 대규모 분산 시스템에서 정확한 백분위수(percentile)를 효율적으로 계산하기 위해 DDSketch를 사용하는 방법을 설명합니다. 평균이나 단순한 히스토그램은 지연 시간처럼 분포가 치우친 데이터의 꼬리 구간을 제대로 표현하지 못하지만, DDSketch는 상대 오차를 일정하게 제한하면서 적은 메모리로 값을 집계합니다. 또한 분산 환경에서 여러 스케치를 병합할 수 있어 p95, p99 같은 지표를 안정적으로 계산할 수 있습니다. ## 백분위수 계산이 어려운 이유 - 평균은 데이터 분포의 꼬리 부분을 숨길 수 있습니다. - 예를 들어 대부분의 요청이 빠르더라도 일부 요청이 매우 느리면 평균만으로는 사용자 경험을 설명하기 어렵습니다. - p95나 p99는 전체 값을 정렬해야 정확히 계산할 수 있습니다. - 대규모 트래픽에서는 모든 원본 값을 저장하고 정렬하는 비용이 매우 큽니다. - 단순한 고정 폭 히스토그램은 구간 경계에 따라 정확도가 달라집니다. - 작은 값에서는 정밀하지만 큰 값에서는 오차가 커지거나, 반대로 큰 값에 맞추면 작은 값의 차이를 구분하지 못합니다. - 여러 서버에서 수집한 데이터를 중앙에서 합치려면 집계 구조가 병합 가능해야 합니다. ## 절대 오차보다 상대 오차가 적합한 이유 - DDSketch는 “실제 값과 추정값의 차이가 일정한 절대값 이하”가 아니라 “실제 값 대비 일정 비율 이하”가 되도록 설계됩니다. - 예를 들어 상대 오차를 1%로 설정하면: - 실제 값이 100인 경우 추정값은 대략 99~101 범위입니다. - 실제 값이 10,000인 경우에도 약 9,900~10,100 범위입니다. - 지연 시간이나 처리량처럼 값의 규모가 크게 달라지는 데이터에서는 상대 오차 보장이 더 일관된 품질을 제공합니다. ## 로그 스케일 기반의 DDSketch - DDSketch는 값을 로그 스케일의 버킷에 매핑합니다. - 인접한 버킷의 대표값이 일정한 비율을 갖도록 만들어, 값이 커져도 상대 오차가 일정하게 유지됩니다. - 양수 값과 음수 값은 별도의 저장소에 기록하고, 0에 가까운 값은 별도의 zero bucket으로 처리합니다. - 각 원본 값을 저장하는 대신 다음 정보만 유지합니다. - 값이 속한 버킷의 인덱스 - 해당 버킷에 포함된 값의 개수 - 조회 시에는 버킷의 대표값과 누적 개수를 이용해 원하는 순위의 값을 추정합니다. ## 메모리 사용량과 정확도의 균형 - 상대 오차 설정값을 작게 할수록 더 많은 버킷이 필요하고 메모리 사용량이 증가합니다. - 반대로 허용 오차를 키우면 더 적은 메모리로 처리할 수 있지만 백분위수의 정밀도가 낮아집니다. - DDSketch는 원본 데이터 전체가 아니라 분포를 근사하므로, 높은 트래픽에서도 메모리 사용량을 예측하기 쉽습니다. - 매우 큰 값 범위가 입력되더라도 로그 매핑을 사용하기 때문에 선형 히스토그램보다 효율적으로 다룰 수 있습니다. ## 분산 환경에서의 병합 - 각 호스트나 애플리케이션 인스턴스가 독립적으로 DDSketch를 생성할 수 있습니다. - 중앙 집계 단계에서는 각 스케치의 동일한 버킷 개수를 더해 하나의 스케치로 병합합니다. - 이 방식은 원본 요청 데이터를 네트워크로 전송할 필요가 없어 수집 및 전송 비용을 줄입니다. - 병합 후에도 설정한 상대 오차 보장이 유지되므로, 분산 시스템 전체의 p95·p99 지연 시간을 계산하는 데 적합합니다. ## 저장소 구조와 큰 데이터 범위 처리 - DDSketch의 내부 저장소는 버킷 인덱스와 카운트를 관리하는 구조로 구현됩니다. - 일반적인 범위에서는 밀집 배열을 사용해 빠르게 접근할 수 있습니다. - 값의 범위가 지나치게 커져 메모리 사용량이 증가할 경우에는 저장소 크기를 제한하고 오래된 범위나 덜 중요한 범위를 압축하는 collapsing store를 사용할 수 있습니다. - 이로 인해 정확도와 메모리 상한 사이의 트레이드오프를 제어할 수 있습니다. 실무에서는 지연 시간처럼 분포의 꼬리가 중요한 지표에 DDSketch 같은 상대 오차 기반 스케치를 적용하는 것이 유용합니다. 다만 허용 오차와 메모리 제한을 서비스 특성에 맞게 설정하고, p99 등 핵심 백분위수의 정확도를 실제 원본 데이터와 비교해 검증하는 것이 좋습니다.

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

metrics쿠버네티스datadog옵저버빌리티+3

datadog·2017년 6월 8일원문

Python에서 Protobuf 파싱하기 (새 탭에서 열림)

Datadog은 Kubernetes 메트릭 수집 효율을 높이기 위해 kube-state-metrics의 프로토콜 버퍼(Protobuf) 지원 기능을 도입하고 그 성능을 검증했습니다. 이 글은 텍스트 형식 대비 Protobuf의 효율성을 정량적으로 확인하기 위한 과정과, 특히 파이썬 환경에서 다중 메시지 스트리밍을 처리하는 구체적인 기술적 구현 방법을 다룹니다. 결론적으로 대규모 데이터 통신에서 이진 포맷이 제공하는 속도와 자원 효율성 이점을 실무에 어떻게 적용할 수 있는지에 대한 가이드를 제공합니다. ## 프로토콜 버퍼의 기초와 데이터 직렬화 * 프로토콜 버퍼(Protobuf)는 구조화된 데이터를 빠르고 효율적으로 이진 스트림으로 직렬화하는 방식으로, 머신 간 통신 및 RPC(원격 프로시저 호출)에 최적화되어 있습니다. * 데이터의 구조를 정의하는 `.proto` 파일을 작성한 후, `protoc` 컴파일러를 통해 파이썬 등 다양한 언어에 맞는 소스 코드를 생성하여 사용할 수 있습니다. * 텍스트 기반 형식과 달리 엄격한 타입 정의를 통해 데이터의 일관성을 보장하며, 페이로드 크기를 획기적으로 줄여 HTTP API 성능을 개선합니다. ## 다중 메시지 스트리밍의 기술적 과제 * Protobuf는 자체 구분자(Self-delimiting)가 없는 설계 특성상, 여러 개의 메시지를 하나의 파일이나 소켓 스트림에 연속적으로 담을 때 각 메시지의 경계를 식별하기 어렵습니다. * 이 문제를 해결하기 위해 각 메시지를 직렬화하기 전, 해당 메시지의 크기(Size) 정보를 머리말(Prefix)로 추가하는 방식이 권장됩니다. * Java 구현체는 `parseDelimitedFrom`과 같은 내장 메서드를 통해 이를 지원하지만, 파이썬 표준 라이브러리는 이러한 기능을 기본적으로 제공하지 않아 별도의 구현이 필요합니다. ## 파이썬에서의 Varint 기반 스트리밍 구현 * 메시지 크기를 기록할 때는 작은 정수에 더 적은 바이트를 사용하는 가변 길이 정수 인코딩 방식인 'Varint'를 사용하며, 이는 효율적인 이진 통신을 가능하게 합니다. * 파이썬에서는 `google.protobuf.internal` 패키지에 포함된 내부 함수인 `_VarintBytes`(인코딩용)와 `_DecodeVarint32`(디코딩용)를 활용하여 Java와 호환되는 스트리밍 구조를 만들 수 있습니다. * 직렬화 시에는 메시지의 `ByteSize()`를 측정해 Varint로 먼저 쓰고 데이터를 기록하며, 역직렬화 시에는 버퍼에서 Varint를 읽어 메시지 길이를 파악한 후 해당 바이트만큼 데이터를 추출하여 파싱합니다. 데이터 전송 효율이 중요한 대규모 Kubernetes 모니터링 환경에서는 텍스트 포맷보다 Protobuf를 사용하는 것이 성능상 매우 유리합니다. 특히 파이썬 환경에서 다수의 메트릭을 스트리밍할 때는 표준 라이브러리 내부의 Varint 유틸리티를 활용하여 데이터 경계를 구분함으로써, Java 시스템과 완벽히 호환되면서도 고성능인 데이터 처리 파이프라인을 구축할 것을 권장합니다.

metrics쿠버네티스datadogPython+4

datadog·2017년 1월 23일원문

마운트의 문제점 (새 탭에서 열림)

데이터독(Datadog) 에이전트가 특정 환경에서 응답을 멈추고 종료조차 되지 않는 문제는 NFS(Network File System)의 '하드 마운트' 속성과 시스템 콜의 작동 방식 때문에 발생했습니다. 하드 마운트된 NFS 서버와의 연결이 끊기면 디스크 정보를 확인하는 `statvfs` 시스템 콜이 무한 대기에 빠지며, 이는 결과적으로 에이전트 전체의 중단으로 이어졌습니다. 이를 해결하기 위해 데이터독은 디스크 체크 로직을 별도 스레드로 분리하고 타임아웃을 적용함으로써, 고객사의 시스템 설정에 관계없이 에이전트의 가용성을 확보하는 설계를 도입했습니다. **에이전트 정지 현상과 원인 분석** * 일부 시스템에서 모든 메트릭 수집이 중단되고 에이전트가 '종료 불가능한(unkillable)' 상태로 멈추는 버그가 보고되었습니다. * 조사 결과, 에이전트는 항상 디스크 체크 과정에서 멈췄으며 구체적으로 파이썬의 `os.statvfs` 함수 호출 시점에서 병목이 발생했습니다. * `os.statvfs`는 내부적으로 glibc의 `statvfs` 시스템 콜을 호출하는데, 이는 리눅스 환경에서 파일 시스템의 상태 정보를 가져오는 표준적인 방법입니다. **NFS 하드 마운트와 시스템 콜의 무한 대기** * NFS를 '하드 마운트(hard mount)' 옵션으로 연결하면, 서버가 응답하지 않을 때 시스템 콜이 타임아웃 없이 성공할 때까지 영구적으로 재시도합니다. * 하드 마운트는 데이터의 일관성을 보장하지만 네트워크 불안정 시 해당 마운트 지점에 접근하는 프로세스를 '좀비' 상태로 만들 수 있으며, 이는 NFS의 기본 설정이기도 합니다. * 특히 glibc의 `statvfs` 구현체는 정보를 찾기 위해 `/proc/mounts`에 나열된 모든 디렉토리를 순회하므로, 현재 조사하려는 대상이 아닌 다른 NFS 마운트에 문제가 생겨도 시스템 전체가 멈추는 현상이 발생합니다. **별도 스레드 및 타임아웃 도입을 통한 해결** * 데이터독 에이전트는 고객이 설정한 마운트 옵션을 강제로 변경할 수 없으므로, 어떤 환경에서도 정상 동작할 수 있는 방어적인 코드가 필요했습니다. * 문제를 해결하기 위해 `statvfs` 호출을 별도의 스레드에서 실행하도록 구조를 변경하고, 메인 스레드에는 타임아웃 로직을 추가했습니다. * 만약 특정 마운트 지점에서 시스템 콜이 응답하지 않더라도, 메인 스레드는 지정된 시간 이후 작업을 포기하고 다음 메트릭 수집으로 넘어감으로써 에이전트의 전체 성능을 보존합니다. * 이 방식은 하드 마운트가 활성화된 시스템에서 약간의 메모리 사용량 증가를 야기하지만, 다양한 이질적 환경에서 모니터링 연속성을 보장하기 위한 필수적인 트레이드오프(Trade-off)로 채택되었습니다. 서버 환경에서 NFS를 운용할 때는 `soft` 마운트 옵션이나 `intr(interruptible)` 옵션을 검토하여 시스템 콜이 무한 대기에 빠지는 상황을 예방해야 합니다. 또한, 모니터링 도구와 같이 외부 환경에 민감한 애플리케이션을 개발할 때는 외부 시스템 콜(I/O) 작업을 반드시 별도 스레드로 격리하고 엄격한 타임아웃을 적용하는 설계가 중요합니다.

metrics데이터베이스 설계datadogPython+3

datadog·2016년 10월 27일원문

동료 응원하기: Dat (새 탭에서 열림)

데이터독(Datadog)의 엔지니어들은 6일 동안 약 850km를 달리는 초장거리 레이스에 출전한 동료를 응원하기 위해 실시간 레이스 모니터링 대시보드를 구축했습니다. 이 프로젝트는 웹 스크래핑 기술과 데이터독의 지표 수집 기능을 결합하여 외부 데이터를 대시보드에 시각화하는 과정을 보여줍니다. 이를 통해 기술적인 도구가 단순한 시스템 관제를 넘어 커뮤니티의 결속과 응원을 위한 도구로 어떻게 활용될 수 있는지 증명했습니다. ### 데이터 추출 및 파싱 대시보드 구축의 첫 단계는 대회 공식 웹사이트에서 선수의 실시간 데이터를 가져오는 것이었습니다. - 파이썬(Python)의 인기 라이브러리인 **Requests**를 사용하여 웹페이지의 HTML 코드를 수집하는 간단한 크롤러를 구현했습니다. - 수집된 HTML 데이터는 **BeautifulSoup** 라이브러리를 통해 파싱되어 현재 순위, 총 주행 거리 등 필요한 수치 데이터로 변환되었습니다. - 대회 사이트가 일반 텍스트 형태의 HTML로 데이터를 제공했기에 복잡한 API 없이도 손쉽게 데이터를 확보할 수 있었습니다. ### StatsD를 활용한 지표 전송 확보된 데이터는 데이터독 에이전트와 StatsD를 통해 실시간 지표(Metrics)로 변환되었습니다. - **dog.gauge** 메서드를 사용하여 세 가지 핵심 지표를 생성했습니다: 주행 거리(`runner.distance`), 현재 순위(`runner.ranking`), 경과 시간(`runner.elapsed_time`). - 각 지표에는 `name` 태그를 부여하여 여러 러너의 데이터를 구분하고 개별적으로 필터링할 수 있도록 설계했습니다. - 파이썬 스크립트를 통해 주기적으로 데이터를 갱신함으로써 실시간에 가까운 데이터 흐름을 유지했습니다. ### 대시보드 구성 및 시각화 수집된 지표들은 뉴욕과 파리 사무실에서 누구나 볼 수 있는 인터랙티브 대시보드로 구성되었습니다. - 단순히 숫자만 나열하는 것이 아니라 실시간 비디오 스트리밍과 재미를 위한 GIF 이미지를 포함하여 시각적 즐거움을 더했습니다. - 거리 차이(Lead)와 남은 시간 등 레이스 상황을 한눈에 파악할 수 있는 유의미한 지표들을 배치했습니다. - 이를 통해 전 세계 사무실의 동료들이 원격으로 레이스 상황을 공유하며 선수를 응원할 수 있는 환경을 조성했습니다. 만약 특정 이벤트나 실시간 경주 데이터를 모니터링하고 싶다면, 이 사례와 같이 파이썬의 웹 스크래핑 라이브러리와 데이터독의 Gauge 지표 기능을 결합해 보시기 바랍니다. 데이터가 HTML 형태로 존재하기만 한다면, 어떤 외부 활동이라도 전문적인 인프라 모니터링 도구를 통해 실시간 대시보드로 구현할 수 있습니다.

metricsdatadogPythonbeautifulsoup+3