metrics

8 개의 포스트

Measure Less to Learn More: Using Fewer, Higher-quality Metrics to Capture What Matters (새 탭에서 열림)

디스코드(Discord)는 조직이 성장함에 따라 늘어나는 지표 측정의 욕구, 즉 '지표에 대한 소외 불안(Metrics FOMO)'이 오히려 실험의 정확도를 떨어뜨릴 수 있음을 경고합니다. 무분별하게 확장된 기본 지표 리스트는 연산 비용을 높일 뿐만 아니라, 통계적 유의성을 판단하는 과정에서 치명적인 트레이드오프(trade-off)를 발생시킵니다. 결론적으로 디스코드는 복잡한 통계 기법에 의존하기보다, 상호 배타적이고 품질 높은 소수의 지표를 선택하는 것이 실험의 신뢰도를 높이는 가장 효과적인 해결책임을 강조합니다. ## 지표 비대화와 'Metrics FOMO' * 조직이 성장하고 팀이 다양해짐에 따라 실험마다 포함되는 '기본 지표 리스트(Default Metric List)'가 지속적으로 비대해지는 경향이 있음. * 데이터 팀은 더 많은 데이터를 수집해야 패턴을 더 잘 찾을 수 있다는 강박(Metrics FOMO)을 가지기 쉬우며, 이로 인해 지표를 삭제하기보다는 추가하는 데만 집중하게 됨. * 하지만 과도하게 많은 지표는 단순히 계산 리소스를 낭비하는 것을 넘어, 실험 결과를 해석하고 의사결정을 내리는 과정을 더욱 복잡하게 만듦. ## 다중 비교의 통계적 트레이드오프 * **제1종 오류(False Positives)의 증가**: p-value 임계값을 5%로 설정했을 때 지표가 100개라면, 실제로는 아무런 효과가 없더라도 통계적 우연에 의해 5개의 지표가 유의미한 것으로 잘못 나타날 수 있음. * **교정 기법의 한계**: '다중 가설 교정(Multiple Hypothesis Correction)'을 통해 거짓 양성을 줄일 수 있으나, 이는 동시에 실제 의미 있는 변화를 감지하는 능력인 재현율(Recall, True Positive를 잡아내는 비율)을 떨어뜨리는 결과를 초래함. * 결과적으로 지표의 수를 무작정 늘리면 분석의 정밀도가 떨어지거나, 반대로 실제 성과를 놓치는 이분법적인 문제에 봉착하게 됨. 실험의 질을 높이기 위해서는 수많은 지표를 통계적인 기법으로 해결하려 하기보다, 실험 설계 단계에서부터 측정 대상을 엄격하게 제한해야 합니다. 서로 중복되지 않는 고유한 개념을 담은 고품질 지표를 선별하여 집중하는 것이 데이터에 휘둘리지 않고 명확한 인사이트를 얻는 최선의 방법입니다.

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

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

Introducing Husky, Datadog's third-generation event store (새 탭에서 열림)

데이터독(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) 관리와 격리 메커니즘을 포함했습니다. 시스템을 설계할 때 단순히 현재의 성능 개선에만 집중하는 것이 아니라, 향후 데이터의 기하급수적인 증가와 다양한 제품 요구사항(비용, 삭제, 격리)을 수용할 수 있는 아키텍처 유연성을 확보하는 것이 중요합니다. 특히 대규모 멀티테넌트 환경에서는 '폭포수 장애'를 방지하기 위해 각 구성 요소를 최대한 독립적으로 격리하는 설계가 필수적입니다.

디자인 시스템의 가치 측정하기 (새 탭에서 열림)

디자인 시스템의 성공을 증명하기 위해서는 단순히 라이브러리의 크기를 측정하는 수준을 넘어, 그것이 비즈니스 목표와 어떻게 연결되는지 입증해야 합니다. 이 글은 단순한 수치 나열(허영 지표)에서 벗어나 조직의 효율성과 제품의 품질에 실질적으로 기여하는 데이터를 수집하고 활용하는 방법을 제시합니다. 결국 적절한 지표 설정은 디자인 시스템 팀이 조직 내에서 지속적인 지원과 투자를 끌어내는 강력한 도구가 됩니다. ### 허영 지표(Vanity Metrics)의 함정 많은 팀이 측정하기 쉽다는 이유로 단순히 숫자에 매몰되는 실수를 범하곤 합니다. * **컴포넌트 개수와 다운로드 수:** 생성된 컴포넌트의 수나 피그마 라이브러리 다운로드 횟수는 시스템의 활성도를 보여줄 순 있지만, 그것이 실제 제품의 가치로 이어졌는지는 설명하지 못합니다. * **데이터의 맥락 부재:** 단순히 "많이 쓰이고 있다"는 지표는 해당 컴포넌트가 올바르게 사용되고 있는지, 혹은 개발 효율성을 정말로 높이고 있는지에 대한 해답을 주지 않습니다. * **위험성:** 이러한 지표에만 의존하면 비즈니스 결정권자들에게 디자인 시스템의 진정한 ROI(투자 대비 효율)를 설득하는 데 실패할 가능성이 높습니다. ### 비즈니스 가치를 증명하는 지표 설정 디자인 시스템의 성과를 측정할 때는 '무엇을(What)'이 아닌 '그래서 어떠한가(So what)'에 집중해야 합니다. * **효율성 및 속도 (Efficiency):** 기능 구현 단계에서 디자인 시스템 도입 전후의 작업 시간을 비교합니다. 예를 들어, 동일한 복잡도의 페이지를 구축하는 데 걸리는 시간이 얼마나 단축되었는지 측정합니다. * **품질 및 일관성 (Quality):** 사용자 경험의 파편화를 줄이고 버그 발생률을 낮추는 능력을 평가합니다. 코드베이스에서 중복되는 CSS 선언이나 커스텀 컴포넌트의 감소율을 추적하는 것이 구체적인 예시입니다. * **팀의 만족도 (Morale):** 시스템 사용자가 느끼는 작업의 편의성과 도구에 대한 신뢰도를 설득력 있는 지표로 활용합니다. 정기적인 서베이를 통해 순수 추천 지수(NPS)를 관리합니다. ### GSM(Goal-Signal-Metric) 프레임워크 활용 체계적인 측정을 위해 목표(Goal)에서 지표(Metric)로 이어지는 논리적인 단계가 필요합니다. * **목표(Goal):** 우리가 달성하고자 하는 비즈니스 결과는 무엇인가? (예: 제품 출시 속도 향상) * **신호(Signal):** 목표 달성을 알 수 있는 사용자 행동의 변화는 무엇인가? (예: 개발자가 기존 컴포넌트를 사용하여 UI를 구성하는 빈도 증가) * **지표(Metric):** 그 신호를 어떻게 수치화할 것인가? (예: 전체 코드 중 시스템 컴포넌트가 차지하는 비중, 즉 Adoption Rate) ### 도입 단계별 측정 전략 디자인 시스템의 성숙도에 따라 집중해야 할 지표가 달라져야 합니다. * **초기 단계:** 시스템 채택률(Adoption)에 집중합니다. 얼마나 많은 팀이 시스템을 사용하기 시작했는지, 주요 라이브러리가 프로젝트에 얼마나 설치되었는지를 추적합니다. * **성장 및 성숙 단계:** 사용성(Usability)과 효율성에 집중합니다. 컴포넌트가 가이드라인에 맞게 올바르게 사용되고 있는지, 시스템을 통해 절약된 시간과 비용이 어느 정도인지를 구체적으로 산출합니다. 디자인 시스템 지표는 한 번 정하고 끝내는 것이 아니라 제품의 성장과 함께 진화해야 합니다. 처음부터 완벽하고 복잡한 대시보드를 만들기보다는, 조직의 현재 비즈니스 우선순위에 가장 부합하는 2~3개의 핵심 지표를 설정해 데이터를 쌓기 시작하는 것이 좋습니다. 측정된 데이터를 바탕으로 시스템의 기여도를 정량화하여 공유할 때, 디자인 시스템은 단순한 도구 모음을 넘어 조직의 핵심 자산으로 인정받을 수 있습니다.

디자인 시스템을 뒷받침 (새 탭에서 열림)

디자인 시스템의 성공을 증명하고 지속적인 운영 동력을 얻기 위해서는 단순한 컴포넌트 구축을 넘어 데이터 기반의 성과 측정이 필수적입니다. 이 글은 디자인 시스템이 비즈니스 가치에 기여하는 방식을 증명하기 위해 정량적 지표와 정성적 지표를 결합하는 프레임워크를 제시하며, 지표 그 자체보다 데이터가 전달하는 '맥락'이 중요함을 강조합니다. 결과적으로 지표는 팀의 의사결정을 돕고 디자인 시스템의 로드맵을 최적화하는 핵심 도구로 기능해야 합니다. ### 지표 설정의 목적과 비즈니스 정렬 * 지표는 단순히 숫자를 나열하는 것이 아니라, 디자인 시스템이 해결하고자 하는 문제(예: 일관성 부족, 개발 속도 저하)와 비즈니스 목표를 연결하는 매개체가 되어야 합니다. * 성공적인 지표 설정을 위해 '무엇을 측정할 것인가(What)', '어떻게 측정할 것인가(How)', '그것이 왜 중요한가(Why)'라는 세 가지 질문을 통해 지표의 타당성을 검토해야 합니다. * 지표는 팀원들에게 신뢰를 주고, 경영진에게는 시스템에 대한 투자 가치(ROI)를 입증하는 근거로 사용됩니다. ### 정량적 데이터 분석: Figma 라이브러리 분석 활용 * **컴포넌트 사용량 및 채택률(Adoption):** 디자인 파일 내에서 시스템 컴포넌트가 얼마나 활발히 사용되는지 추적하여 시스템의 영향력을 파악합니다. * **컴포넌트 해제(Detachments) 추적:** 디자이너가 시스템 컴포넌트를 해제하여 사용하는 시점과 이유를 분석함으로써, 현재 라이브러리의 부족한 점이나 유연성이 필요한 부분을 식별합니다. * **라이브러리 삽입 수:** 특정 기간 동안 새로운 컴포넌트가 디자인에 도입된 빈도를 측정하여 팀의 작업 흐름에 시스템이 얼마나 깊게 침투했는지 확인합니다. ### 정성적 데이터 분석: 사용자 경험과 만족도 * **설문 조사(Surveys):** 정기적인 만족도 조사를 통해 디자인 시스템이 작업 속도를 높여주는지, 사용하기 편리한지 등 사용자(디자이너 및 개발자)의 실제 체감 수치를 측정합니다. * **인터뷰 및 피드백 루프:** 숫자로 나타나지 않는 구체적인 고충점(Pain points)을 파악하기 위해 사용자 인터뷰를 진행하고, 이를 통해 시스템 고도화의 우선순위를 정합니다. * **Net Promoter Score (NPS):** 디자인 시스템을 동료에게 추천할 의향이 있는지를 측정하여 시스템에 대한 전반적인 신뢰도와 충성도를 가늠합니다. ### 효율성 및 비즈니스 임팩트 측정 * **시장 출시 속도(Time-to-market):** 디자인 시스템 도입 전후의 프로젝트 소요 시간을 비교하여, 재사용 가능한 자산이 개발 및 디자인 프로세스를 얼마나 단축시켰는지 계산합니다. * **코드 일관성:** 디자인 사양과 실제 구현된 코드 사이의 일치도를 검토하여 불필요한 커스텀 코드를 줄이고 유지보수 비용을 절감하는 효과를 측정합니다. * **협업 효율성:** 디자이너와 개발자 간의 소통 횟수나 핸드오프 과정에서의 마찰이 얼마나 줄어들었는지를 평가합니다. 디자인 시스템 지표는 한 번에 완성되는 것이 아니라 시스템의 성숙도에 따라 함께 진화해야 합니다. 초기에는 컴포넌트 채택률과 같은 기본 지표에 집중하고, 시스템이 안정화됨에 따라 업무 효율성과 비즈니스 가치를 증명하는 복합적인 지표로 확장해 나가는 것을 권장합니다. 데이터를 수집하는 것만큼이나 중요한 것은 그 데이터를 바탕으로 팀과 소통하고 실제 시스템 개선으로 연결하는 실행력입니다.

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 시스템과 완벽히 호환되면서도 고성능인 데이터 처리 파이프라인을 구축할 것을 권장합니다.

The trouble with mounting (새 탭에서 열림)

데이터독(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) 작업을 반드시 별도 스레드로 격리하고 엄격한 타임아웃을 적용하는 설계가 중요합니다.

동료 응원하기: 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 형태로 존재하기만 한다면, 어떤 외부 활동이라도 전문적인 인프라 모니터링 도구를 통해 실시간 대시보드로 구현할 수 있습니다.