toss·2025년 11월 3일원문

토스플레이스 사일로 QA로 일한다는 것 (새 탭에서 열림)

토스플레이스의 QA 팀은 기능 조직으로서의 전문성을 유지함과 동시에 제품 개발 단위인 '사일로(Silo)'에 겸직 형태로 참여하여 제품의 초기 기획 단계부터 배포까지 전 과정을 함께합니다. 이러한 구조적 변화를 통해 QA는 단순한 검수자가 아닌 제품의 히스토리를 깊이 이해하고 리스크를 선제적으로 관리하는 전략적 파트너로 자리 잡았습니다. 결과적으로 품질 관리가 배포를 지연시킨다는 편견을 깨고, 빠른 배포와 높은 품질을 동시에 달성하며 팀 전체의 신뢰를 얻는 성과를 거두었습니다. **사일로 겸직 구조를 통한 품질 관리의 내재화** * QA 매니저는 제품 초기 셋업 단계부터 참여하여 OKR 설계 및 요구사항 정의 과정에서 발생할 수 있는 잠재적 리스크를 사전에 식별합니다. * 제품의 제작 의도와 히스토리를 명확히 파악함으로써 보다 정교한 테스트 범위 산정과 테스트 케이스 설계가 가능해집니다. * 사일로 내부에서 작은 단위의 프로세스 실험을 자유롭게 수행하고, 성과가 검증된 방식은 팀 전체로 확산하는 유연한 운영 방식을 채택하고 있습니다. **협업 효율을 높이는 디자인 및 스펙 리뷰 체계** * '스펙 리뷰 → QnA 세션 → 변경 사항 정리'로 이어지는 흐름을 도입하여 개발 및 QA 과정에서 발생하는 이해관계자 간의 정보 간극을 최소화했습니다. * 디자인 툴(데우스)과 사내 메신저 스레드를 활용해 산재된 변경 내용을 한곳에 모아 관리함으로써 투명성을 높였습니다. * 개발 착수 전 모든 직군이 동일한 이해도를 가질 수 있도록 디자인 픽스 시점에 별도의 리뷰 미팅을 진행합니다. **라이브 모니터링과 품질 책임의 공유** * 릴리즈 이후 QA 혼자 검증하는 한계를 극복하기 위해 모든 팀원이 함께 확인해야 할 '주요 체크리스트'를 도입했습니다. * 개발 외 직군도 직접 제품 상태를 점검하게 함으로써 품질은 QA만의 책임이 아닌 팀 전체의 책임이라는 문화를 형성했습니다. * 이를 통해 최종 스펙을 재검증하고 실환경에서 발생할 수 있는 문제를 조기에 발견하는 환경을 구축했습니다. **개발 효율을 극대화하는 Sanity 테스트 및 백로그 관리** * QA 시작 기준을 명확히 하기 위해 개발 시작 전 'Sanity 테스트' 기준을 수립하고, 정상 시나리오(Happy Case)에 대한 검증을 기본 원칙으로 세웠습니다. * 사내 메신저의 'Send to Notion' 기능을 활용해 대화 중 나오는 아이디어나 작은 이슈들이 누락되지 않도록 즉시 백로그 데이터베이스에 기록합니다. * 이슈의 우선순위를 사용자 경험과 배포 긴급도에 따라 분류하여, 효율적인 리소스 배분과 체계적인 이슈 추적을 실천하고 있습니다. **커뮤니케이션 중심의 도구 최적화 (Jira에서 리스트/캔버스로)** * 소통 채널의 파편화를 막기 위해 기존의 Jira 중심 업무 방식에서 사내 메신저 기반의 '리스트/캔버스' 기능으로 전환을 시도했습니다. * 담당자 지정 및 템플릿 커스터마이징을 통해 이슈 관리와 소통을 한곳에 통합하여 맥락 공유에 드는 리소스를 대폭 줄였습니다. * 도구 자체의 기능보다는 팀의 실제 소통 방식에 가장 적합한 도구를 선택하는 유연함을 발휘하여 업무 속도를 높였습니다. 토스플레이스의 사례는 QA가 제품의 끝단이 아닌 시작점부터 결합될 때 조직의 생산성이 어떻게 극대화될 수 있는지를 잘 보여줍니다. 품질 관리 프로세스를 고정된 틀에 가두지 않고 각 팀의 특성에 맞게 유연하게 설계하고 개선해 나가는 '자율성'과 '실험 정신'은 제품의 신뢰도를 높이고자 하는 모든 IT 조직에 실질적인 영감을 제공합니다.

데이터베이스 설계jiranotionquality-assurance+4

datadog·2025년 10월 15일원문

장애는 피할 수 없다: 대규모 장애에서 배우고 Datadog에서 안정성을 심층적으로 구축하기 (새 탭에서 열림)

2023년 3월에 발생한 대규모 장애를 계기로 데이터독(Datadog)은 시스템 가용성에 대한 근본적인 철학을 재정립했습니다. 당시 인프라의 50~60%가 작동 불능 상태에 빠지자 플랫폼 전체가 완전히 멈춘 것처럼 보이는 '정사각형 파형(Square-wave) 실패' 패턴이 나타났으며, 이는 완벽한 데이터 정확성에만 집착하던 기존 설계의 한계를 드러냈습니다. 이에 데이터독은 모든 장애를 막으려는 시도 대신, 극단적인 상황에서도 일부 기능을 유지하며 가치를 제공하는 '우아한 성능 저하(Graceful Degradation)'를 핵심 전략으로 채택했습니다. ### 장애의 교훈: 정사각형 파형 실패의 발견 * **이진법적 실패:** 2023년 3월, 글로벌 보안 업데이트 과정에서 쿠버네티스 노드의 약 절반이 연결을 소실했습니다. 인프라의 절반은 여전히 작동 중이었음에도 불구하고, 사용자 입장에서는 서비스가 아예 응답하지 않거나 데이터가 전혀 보이지 않는 '전부 아니면 전무(All-or-Nothing)' 식의 장애가 발생했습니다. * **정확성 편향의 부작용:** 기존 시스템은 데이터의 정확성을 보장하기 위해 모든 태그와 메트릭이 완전히 처리될 때까지 쿼리 결과 표시를 대기하도록 설계되었습니다. 평상시에는 올바른 선택이지만, 대규모 장애 시에는 일부 데이터 누락이 전체 시스템의 데이터 가독성을 차단하는 결과를 초래했습니다. * **사후 분석의 한계:** 단순히 장애의 트리거(레거시 업데이트 메커니즘)를 제거하는 것만으로는 충분하지 않았습니다. 인증서 만료, 윤초, 설정 오류 등 장애의 원인은 무한하기 때문에, 원인 차단보다는 장애 발생 시 시스템이 어떻게 반응하느냐가 더 중요하다는 점을 깨달았습니다. ### 실패를 위한 설계: 우아한 성능 저하의 원칙 * **복구력 중심의 사고 전환:** 절대 실패하지 않는(Never-fail) 아키텍처는 불가능하다는 것을 인정하고, '더 잘 실패하는(Failing better)' 시스템을 구축하는 데 집중하기 시작했습니다. * **우선순위의 재정립:** 장애 상황에서도 고객의 비즈니스 연속성을 보장하기 위해 세 가지 원칙을 세웠습니다. ① 데이터는 늦더라도 절대 유실되지 않아야 한다. ② 가용한 자원은 실시간 데이터 처리에 우선 할당한다. ③ 아무것도 보여주지 않는 것보다 부정확하더라도 부분적인 결과를 보여주는 것이 낫다. ### 데이터 유실 방지를 위한 영구 흡수 저장소(Persistent Intake) * **메모리 기반 버퍼의 위험성:** 분석 결과, 초기 데이터 흡수(Intake) 단계에서 데이터가 메모리나 로컬 디스크에만 머물러 있다가 노드 장애 시 복구 불가능하게 유실되는 문제가 확인되었습니다. * **디스크 기반 영구 저장:** 데이터 처리 파이프라인의 가장 앞단에 디스크 기반의 복제 저장소를 도입했습니다. 이를 통해 수집 노드가 중단되더라도 데이터가 유실되지 않도록 보장하며, 다운스트림 시스템이 마비되었을 때도 버퍼 역할을 수행하여 데이터 에이전트의 재시도 실패를 방지합니다. * **지연 시간과 안정성의 균형:** 응답 속도를 위해 최적화되었던 기존 방식에서 벗어나, 데이터 수신 확인(Acknowledgment)을 보내기 전에 복제된 저장소에 안전하게 기록하는 구조로 변경하여 신뢰성을 높였습니다. ### 실용적인 결론 및 제언 대규모 시스템을 운영하는 엔지니어링 팀은 시스템의 **신뢰성(Reliability)**을 단순히 '장애가 없는 상태'로 정의해서는 안 됩니다. 시스템의 일부가 마비되더라도 핵심적인 기능은 작동을 멈추지 않도록 설계해야 합니다. 특히 데이터 정확성과 가용성 사이의 트레이드오프를 재검토하여, 장애 시나리오에서는 '완벽한 데이터'보다 '부분적이지만 즉각적인 가시성'을 제공하는 것이 비즈니스 관점에서 훨씬 유리할 수 있음을 명심해야 합니다.

데이터베이스 설계쿠버네티스data-loss-preventiongraceful-degradation+4

datadog·2025년 10월 1일원문

Husky 쿼리 엔진 내부: 100조 개 이벤트에 대한 실시간 액세스 (새 탭에서 열림)

Datadog은 매일 100조 개 이상의 이벤트와 수십억 개의 쿼리를 처리하기 위해 3세대 이벤트 저장소인 'Husky'를 구축했습니다. Husky의 쿼리 엔진은 고정된 스키마가 없고 데이터 볼륨이 가변적인 대규모 멀티테넌트 환경에서도 오브젝트 스토리지에 저장된 페타바이트급 데이터를 실시간으로 조회할 수 있도록 설계되었습니다. 이를 위해 시스템은 쿼리 플래너, 오케스트레이터, 메타데이터 서비스, 리더 서비스로 역할을 분산하여 성능과 비용 효율성을 동시에 달성했습니다. ### Husky의 데이터 모델과 주요 쿼리 패턴 Husky는 로그나 네트워크 트래픽과 같이 타임스탬프와 다양한 속성을 가진 '이벤트' 데이터를 저장하며, 서비스별로 상이한 데이터 형태를 유연하게 수용합니다. * **가변적인 스키마 지원:** 테넌트나 사용 사례(로그 vs 네트워크 데이터)에 따라 속성의 종류와 데이터의 크기가 극명하게 달성하더라도 효율적으로 처리할 수 있습니다. * **Needle-in-a-haystack 검색:** 수많은 데이터 중 특정 IP나 에러 메시지, 트레이스 ID 등을 찾아내는 고도로 선택적인 필터링 쿼리를 지원합니다. * **분석형(Analytics-style) 검색:** 특정 기간 동안의 서비스 지연 시간 추이나 지역별 매출 분석과 같이 대규모 데이터를 집계하여 시각화하는 쿼리를 최적화합니다. ### 쿼리 실행의 4단계 아키텍처 Husky의 쿼리 경로는 네 가지 핵심 서비스로 나뉘어 멀티테넌트 환경에서 안정적으로 동작합니다. * **쿼리 플래너(Query Planner):** 모든 쿼리의 진입점으로, 쿼리 유효성 검사 및 최적화를 수행합니다. 통계 데이터를 기반으로 쿼리를 시간 단위의 여러 단계로 분할하고 실행 결과를 최종 병합합니다. * **쿼리 오케스트레이터(Query Orchestrator):** 데이터 저장소의 관문 역할을 하며 메타데이터 조회, 프래그먼트(데이터 파일) 할당, 집계 조율을 담당합니다. 특히 '존 맵(Zone-map) 프루닝'을 통해 불필요한 데이터를 걸러냄으로써 다운스트림 작업량을 평균 30~60% 절감합니다. * **메타데이터 서비스(Metadata Service):** FoundationDB의 프런트엔드로서 데이터 컴팩션 중에도 쿼리 결과의 원자성(Atomicity)을 보장합니다. DB 내부 로직을 추상화하여 전체 쿼리 경로와 분리하는 역할을 합니다. * **리더 서비스(Reader Service):** 실제 오브젝트 스토리지에 저장된 프래그먼트에서 데이터를 읽어 응답을 반환하는 핵심 실행 엔진입니다. ### 리더(Reader) 서비스의 데이터 스캔 최적화 오브젝트 스토리지는 비용이 저렴하지만 읽기 속도가 느리므로, 리더 서비스는 "읽지 않아도 되는 데이터를 스캔하지 않는 것"을 최우선 목표로 삼습니다. * **행 그룹(Row Groups) 구조:** 수백만 행을 가진 대용량 프래그먼트를 '행 그룹' 단위로 물리적으로 배치하여 관리합니다. 이는 쿼리 실행 시 전체 파일을 메모리에 올리는 부담을 줄이고 메모리 부족(OOM) 오류를 방지합니다. * **입출력(I/O) 최소화:** 오브젝트 스토리지에 대한 GET 요청은 비용이 많이 들기 때문에, 쿼리에 꼭 필요한 행 그룹만 선택적으로 가져와 비용 효율성과 응답 속도를 극대화합니다. * **반복자 기반 실행 모델:** Volcano 모델에서 영감을 받은 반복자(Iterator) 방식을 사용하여 데이터를 효율적으로 스트리밍하며 처리합니다. Husky의 사례는 대규모 시계열 이벤트를 처리할 때 고정된 인덱스에 의존하기보다, 메타데이터 기반의 프루닝과 물리적인 데이터 레이아웃 최적화를 통해 오브젝트 스토리지의 한계를 극복할 수 있음을 보여줍니다. 저비용 고성능의 로그 분석 시스템을 설계한다면 데이터의 물리적 구조화와 단계별 쿼리 분산 처리가 핵심이 될 것입니다.

데이터베이스 설계data-architecturefoundationdbhusky+3

datadog·2025년 9월 18일원문

수작업으로 튜닝한 Go에서 자기 최적화 코드까지: BitsEvolve 구축하기 (새 탭에서 열림)

Datadog은 대규모 인프라에서 Go 언어로 작성된 핵심 함수의 성능을 최적화하여 연간 수십만 달러의 비용을 절감했으며, 이 과정에서 얻은 노하우를 'BitsEvolve'라는 내부 AI 에이전트 시스템으로 자동화했습니다. 단순히 코드 효율을 높이는 것에 그치지 않고, 호출 빈도가 높고 오토스케일링이 적용되는 '핫 패스(Hot-path)' 지점을 데이터 기반으로 식별하여 실제 비즈니스 가치인 비용 절감으로 연결했습니다. 이 글은 전문가의 수동 최적화 기법이 어떻게 대규모 조직을 위한 자동화된 성능 최적화 시스템의 청사진이 되었는지를 상세히 설명합니다. ### 최적화 대상 선정을 위한 세 가지 조건 성능 최적화가 실제 인프라 비용 절감으로 이어지기 위해서는 다음과 같은 조건이 충족되어야 합니다. * **실행 규모:** 함수가 연간 수백만 또는 수십억 번 이상 호출되는 핵심 경로에 있어야 합니다. * **오토스케일링 환경:** CPU 사용량 감소가 단순히 서버의 유휴 시간을 늘리는 것이 아니라, 실제 운영되는 머신 대수의 감소로 이어질 수 있도록 공격적인 오토스케일링이 적용된 서비스여야 합니다. * **유의미한 자원 절감:** 전체 컴퓨팅 자원의 0.5%와 같이 작은 비중을 차지하는 함수라도, 대규모 호출 환경에서는 수만 달러의 비용 절감 효과를 낼 수 있는 지점을 타겟팅합니다. ### 컴파일러 경계 검사 제거를 통한 성능 향상 가장 빈번하게 호출되는 태그 정규화 함수(`isNormalizedASCIITag`)를 최적화하기 위해 하위 수준의 분석을 수행했습니다. * **문제 식별:** Compiler Explorer를 활용해 어셈블리 코드를 분석한 결과, Go 컴파일러가 루프 내부에서 인덱싱 안전성을 확신하지 못해 불필요한 배열 경계 검사(`runtime.panicBounds`)를 반복 실행하는 것을 발견했습니다. * **코드 재구조화:** 컴파일러가 경계 검사를 생략할 수 있도록 루프 구조를 미세하게 재설계했습니다. * **결과:** 함수 실행 속도가 25% 향상되었으며, 이는 서비스 전체 CPU 사용량의 0.75% 감소와 연간 수만 달러의 비용 절감으로 이어졌습니다. ### 관측 데이터 기반의 비관적 코드 개선 모든 예외 상황을 고려하는 방어적인 코드를 실제 데이터에 기반하여 '낙관적'으로 개선함으로써 극적인 성능 향상을 이뤄냈습니다. * **데이터 분석:** 임의의 입력을 처리하는 함수(`NormalizeTagArbTagValue`)가 모든 바이트를 의심하며 검사하고 있었으나, 관측 결과 입력값의 97%가 단순 ASCII였으며 잘못된 UTF-8 데이터는 0.01% 미만이었습니다. * **Fast-path 도입:** 대다수를 차지하는 일반적인 케이스(ASCII)를 즉시 통과시키는 최적화 경로를 추가하여 예외 처리 로직의 부하를 줄였습니다. * **결과:** 해당 함수의 성능을 90% 이상 개선하여 연간 수십만 달러의 인프라 비용을 절감하는 성과를 거두었습니다. ### 수동 최적화에서 에이전틱 자동화 시스템으로의 확장 전문 엔지니어의 수동 최적화는 성과가 크지만 조직 전체로 확장하기 어렵다는 한계가 있습니다. * **BitsEvolve 구축:** 전문가들이 수동 최적화 과정에서 사용한 휴리스틱과 분석 기법을 LLM 기반의 에이전틱 시스템인 'BitsEvolve'의 로직으로 이식했습니다. * **반복 가능한 프로세스:** 특정 전문가의 '영웅적 활약'에 의존하던 방식에서 벗어나, 관측 가능한 데이터를 기반으로 최적화 지점을 찾고 코드를 수정하는 과정을 자동화하고 표준화했습니다. * **지식의 자산화:** 수동으로 해결한 복잡한 최적화 사례들은 AI 시스템이 학습하고 모방해야 할 중요한 데이터 세트이자 벤치마크가 되었습니다. 성능 최적화의 진정한 가치는 단순히 실행 시간을 단축하는 것이 아니라, 관측 데이터(Observability)를 통해 비즈니스 비용과 직결된 병목 구간을 정확히 찾아내는 데 있습니다. 대규모 시스템을 운영하는 엔지니어라면 방어적인 코딩 관습에 의문을 제기하고, 실제 트래픽 특성을 반영한 'Fast-path' 설계와 컴파일러 최적화 원리를 이해함으로써 가시적인 비용 절감을 실현할 수 있습니다.

데이터베이스 설계옵저버빌리티Goai-assisted-coding+4

datadog·2025년 8월 12일원문

규모를 줄여 100배 향상한 실시간 프로세스 메트릭 효율성 (새 탭에서 열림)

Datadog은 프로세스 및 컨테이너 모니터링 시스템의 실시간 데이터 처리 방식을 '호스트 구독(Host Subscription)' 기반 모델로 전환하여 확장성 문제를 해결했습니다. 사용자가 현재 화면에서 보고 있는 특정 호스트(최대 50개)에 대해서만 2초 간격의 고빈도 수집을 활성화함으로써, 전체 트래픽 볼륨을 100배 줄이고 인프라 비용을 98% 절감하는 성과를 거두었습니다. 이 글은 불필요한 데이터 수집을 최소화하면서도 사용자 경험과 시스템 효율성을 동시에 개선한 기술적 여정을 다룹니다. ## 기존 실시간 데이터 수집의 한계 * **전체 활성화 방식의 비효율성:** 기존에는 테넌트 내 한 명의 사용자만 페이지를 조회해도 해당 테넌트 전체 인프라의 모든 호스트에서 2초 간격의 데이터 수집이 시작되었습니다. 이로 인해 초당 수백만 개의 프로세스 데이터가 유입되는 부하가 발생했습니다. * **수평적 확장 불가능:** 실시간 정렬 기능을 제공하기 위해 테넌트의 모든 데이터를 단일 서버의 메모리에 보관해야 했습니다. 이는 시스템을 수평적으로 확장하는 것을 불가능하게 만들었으며, 서버 사양을 높이는 수직적 확장에만 의존하게 했습니다. * **리소스 낭비:** 실제 사용자가 한 번에 확인하는 프로세스는 약 50개 내외임에도 불구하고, 보이지 않는 수만 개의 프로세스 데이터를 실시간으로 수집하고 처리하는 비효율이 존재했습니다. ## 사용자 가시성 중심의 설계 전환 * **실시간 수집 대상의 최소화:** 사용자가 보고 있는 화면에 노출된 프로세스가 실행 중인 호스트에 대해서만 실시간 모드를 활성화하도록 전략을 수정했습니다. * **데이터 용도 분리 및 정렬 로직 최적화:** 2초 간격의 실시간 데이터는 화면 갱신에만 사용하고, 10초마다 수행되는 정렬 작업에는 일반적인 10초 간격 데이터를 활용하도록 변경했습니다. * **시스템 단순화:** 실시간 뷰와 히스토리 뷰에서 동일한 정렬 로직을 사용할 수 있게 되어 시스템 복잡성이 줄어들었고, 고빈도 메트릭을 메모리에 상주시켜야 할 필요성도 사라졌습니다. ## 호스트 구독 모델 및 필터링 최적화 * **호스트 구독(Host Subscription) 도입:** 사용자가 현재 보고 있는 호스트 목록을 추적하고, 이 상태를 Kafka를 통해 인테이크(Intake) 서비스와 라이브 서버 간에 공유합니다. * **조기 필터링(Early Filtering):** 구독 정보를 바탕으로 데이터 수집 단계(Intake)에서부터 필요한 데이터만 선별하여 처리합니다. 이는 Datadog 에이전트와 백엔드 서버 모두의 부하를 줄이는 핵심 기여를 했습니다. * **성능 개선 결과:** 개념 증명(PoC) 단계에서 이미 라이브 데이터 서버의 메모리 사용량은 85%, CPU 사용량은 33% 감소했으며, 이는 시스템 전체의 안정성 향상으로 이어졌습니다. 대규모 인프라 모니터링 환경에서 모든 데이터를 실시간으로 수집하는 것은 막대한 비용과 확장성 문제를 야기합니다. 사용자의 가시성 범위 내로 수집 대상을 제한하고 데이터의 용도(갱신 vs 정렬)에 따라 수집 빈도를 이원화하는 접근 방식은 리소스 효율성을 극대화하면서도 고성능 실시간 뷰를 제공할 수 있는 실용적인 해결책이 됩니다.

데이터베이스 설계datadogApache KafkaDocker & 컨테이너+4

datadog·2025년 8월 4일원문

대규모 성능을 위해 Rust로 구축한 실시간 시계열 저장소를 다시 발전시키다 (새 탭에서 열림)

데이터독(Datadog)은 급증하는 데이터 볼륨과 고카디널리티(high-cardinality) 워크로드를 처리하기 위해 Rust 기반의 6세대 실시간 시계열 데이터베이스 엔진을 새롭게 설계했습니다. 기존 시스템의 한계를 극복하기 위해 인제스션(Ingestion), 저장, 쿼리 실행 구조를 근본적으로 재구성함으로써 수집 성능은 60배, 쿼리 속도는 최대 5배까지 향상시키는 성과를 거두었습니다. 이 글은 지난 15년간 데이터독이 카산드라에서 시작해 Rust 기반의 전용 엔진에 이르기까지 거쳐온 기술적 진화 과정과 그 과정에서 얻은 교훈을 다룹니다. ### 데이터독 시계열 저장소의 아키텍처 데이터독의 메트릭 플랫폼은 데이터의 효율적인 처리를 위해 실시간 저장소와 인덱스 데이터베이스를 분리하여 운영합니다. * **RTDB (Real-time DB):** `<timeseries_id, timestamp, value>` 형태의 원시 메트릭 데이터를 저장하고 집계하며, 최신 데이터를 실시간으로 서빙합니다. * **인덱스 데이터베이스:** 메트릭 식별자와 태그 정보를 `<timeseries_id, tags>` 형태로 관리합니다. * **데이터 흐름:** 쿼리가 발생하면 상위 서비스가 RTDB와 인덱스 노드에 각각 접속하여 결과를 가져오고, RTDB 노드 내부는 인테이크(Intake), 스토리지 엔진, 스냅샷 모듈, gRPC 쿼리 실행 계층 등으로 구성되어 유기적으로 동작합니다. ### 1세대부터 3세대: 확장성과 운영 효율의 탐색 초기 데이터독은 기성 솔루션을 활용하며 실시간 쿼리 성능과 운영 편의성을 확보하는 데 집중했습니다. * **Gen 1 (Cassandra):** 뛰어난 쓰기 확장성을 제공했으나, 알람 및 분석에 필요한 복잡한 실시간 쿼리를 지원하기 어렵고 대규모 데이터셋 반환 시 효율이 떨어지는 한계가 있었습니다. * **Gen 2 (Redis):** 빠른 읽기 속도와 운영 가시성을 제공했지만, 싱글 스레드 특성상 라이브 트래픽 처리 중 스냅샷 작업이 어려웠고 데이터 직렬화/역직렬화에 따른 CPU 및 메모리 비용이 증가했습니다. * **Gen 3 (MDBM):** `mmap`을 통해 OS 페이지 캐시를 활용하는 메모리 맵 방식의 키-값 저장소를 도입했으나, 대규모 워크로드에서 성능과 정확성 이슈가 발생하며 명시적인 I/O 관리의 필요성을 체감했습니다. ### 4세대와 5세대: 커스텀 엔진과 기능 확장 성능 한계를 돌파하기 위해 범용 DB를 벗어나 전용 스토리지 엔진을 직접 구현하기 시작했습니다. * **Gen 4 (Go 기반 B+ Tree):** Go 언어로 구현된 커스텀 B+ 트리 엔진을 도입하여 '코어당 스레드(thread-per-core)' 모델의 기초를 닦았으며, 처리량과 지연 시간 면에서 큰 진전을 이루었습니다. * **Gen 5 (RocksDB 통합):** 분포 메트릭(distribution metrics)과 DDSketch 타입을 지원하기 위해 RocksDB를 병행 도입했습니다. 하지만 기존 Go 엔진과 RocksDB가 공존하는 구조는 관리가 복잡하고 효율성이 분산되는 결과를 낳았습니다. ### 6세대: Rust 기반의 통합 엔진으로의 전환 파편화된 엔진을 통합하고 성능을 극대화하기 위해 Rust를 선택하여 차세대 시스템을 구축했습니다. * **통합 및 최적화:** 스칼라 값과 스케치 데이터를 모두 처리할 수 있는 단일 엔진을 Rust로 구축하여 언어 차원의 안정성과 고성능 I/O 제어권을 확보했습니다. * **성능 성과:** 이 구조적 변화를 통해 데이터 수집 성능을 60배 높였으며, 피크 시간대 쿼리 속도를 5배 향상시켜 전례 없는 규모의 트래픽을 효율적으로 수용하게 되었습니다. **결론 및 추천** 시스템 규모가 커짐에 따라 범용 데이터베이스나 `mmap`과 같은 추상화 계층은 오히려 성능 병목이 될 수 있습니다. 데이터독의 사례처럼 워크로드의 특성에 맞춰 I/O와 메모리 레이아웃을 직접 제어할 수 있는 전용 엔진을 구축하는 것이 기술적 부채를 해결하고 폭발적인 성장을 뒷받침하는 핵심 전략이 될 수 있습니다. 특히 Rust와 같은 시스템 프로그래밍 언어는 고성능 실시간 시스템을 재설계할 때 강력한 도구가 됩니다.

데이터베이스 설계Rustredisgrpc+4

line·2025년 8월 1일원문

일 평균 30억 건을 처리하는 결제 시스템의 DB를 Vitess로 교체하기 - 2. 개발 및 운영기 (새 탭에서 열림)

LINE Billing Platform 팀은 일 평균 30억 건의 요청을 처리하는 대규모 결제 시스템을 운영하기 위해 기존 Nbase-T에서 Vitess로 성공적인 데이터베이스 마이그레이션을 수행했습니다. 이 글에서는 성능 문제와 개발 편의성을 고려해 gRPC 대신 MySQL 프로토콜을 선택한 과정과 효율적인 데이터 처리를 위한 샤딩 전략을 상세히 다룹니다. 또한 VTOrc와 Prometheus를 활용한 자동 복구 및 모니터링 체계를 구축하여 분산 데이터베이스 환경에서도 높은 안정성을 확보한 실무 노하우를 공유합니다. ### 프로토콜 선정 및 개발 환경 구축 * VTGate는 gRPC와 MySQL 프로토콜을 모두 지원하지만, gRPC 사용 시 `http2: frame too large` 에러와 CPU 오버헤드가 발생하여 최종적으로 MySQL 프로토콜을 채택했습니다. * Java 클라이언트 사용 시 gRPC 프로토콜은 쿼리 결과를 객체로 변환하는 과정이 번거롭고 Vitess 측에서도 현재 MySQL 프로토콜 사용을 권장하고 있습니다. * 익숙한 MySQL 프로토콜을 사용함으로써 기존 개발 경험을 유지하면서도 Vitess의 샤딩 기능을 안정적으로 활용할 수 있게 되었습니다. ### 키스페이스 설계 및 데이터 처리 방식 * 시스템은 크게 두 개의 키스페이스로 분리되어 있습니다. '글로벌 키스페이스'는 단일 샤드로 구성되어 자동 증가(Auto-increment)하는 샤딩 키를 관리합니다. * 실제 데이터가 저장되는 '서비스 키스페이스'는 N개의 샤드로 분산되어 있으며, 코인 잔액 및 충전/사용 내역 등의 데이터를 저장합니다. * 서비스 키스페이스는 'Hash Vindex'를 사용하여 데이터를 균등하게 분산하며, 애플리케이션이 쿼리에 샤딩 키를 포함하면 VTGate가 해당 샤드를 자동으로 특정해 효율적인 요청 처리가 가능합니다. ### MySQL 호환성 및 주요 기능 활용 * 트랜잭션 격리 수준은 단일 샤드일 경우 `REPEATABLE READ`, 다중 샤드일 경우 `READ COMMITTED`가 적용됩니다. * Vitess는 MySQL 프로토콜을 지원하지만 일부 쿼리 제약 사항이 존재하므로, `unsupported_cases.json`을 통해 사전에 호환성을 확인해야 합니다. * 분산 샤드 간 트랜잭션을 지원하는 'Two-Phase Commit(2PC)' 기능과 쿼리 실행 계획을 분석하는 'VEXPLAIN/VTEXPLAIN' 등을 통해 분산 환경의 제약을 보완하고 있습니다. ### 안정적인 운영을 위한 모니터링 및 장애 복구 * 자동 복구 도구인 'VTOrc'를 도입하여 토폴로지 서버와 VTTablet의 데이터를 기반으로 문제를 자동 감지하고 복구합니다. * Prometheus를 통해 VTOrc의 지표(Metrics)를 수집하며, 장애 발생 시 이메일과 Slack으로 알람이 전달되도록 구성했습니다. * VTAdmin 웹 UI를 활용해 복구 내역을 시각적으로 확인하고, `tablet_alias`를 통해 문제가 발생한 MySQL 노드를 즉각적으로 식별하여 운영 효율성을 높였습니다. 대규모 분산 환경에서 Vitess를 도입할 때는 성능과 유지보수를 위해 gRPC보다는 MySQL 프로토콜 사용을 우선적으로 고려하는 것이 좋습니다. 또한 단일 샤드와 다중 샤드 간의 트랜잭션 격리 수준 차이 및 쿼리 제약 사항을 면밀히 검토하여 애플리케이션 로직을 설계해야 하며, VTOrc와 같은 도구를 적극 활용하여 고가용성 운영 체계를 구축하는 것이 중요합니다.

데이터베이스 설계grpcmysqldatabase-migration+4

datadog·2025년 7월 17일원문

수백 개의 파드에서 Go 1.24 메모리 회귀를 추적해 찾아낸 방법 (새 탭에서 열림)

Go 1.24로의 업그레이드 이후, 새로운 맵 구현인 스위스 테이블(Swiss Tables)에 대한 기대와 달리 일부 서비스에서 메모리 사용량(RSS)이 약 20% 증가하는 현상이 발견되었습니다. 조사 결과, Go 런타임 내부의 메모리 관리 지표는 안정적이었으나 시스템 레벨의 실제 물리 메모리 점유가 늘어난 것으로 확인되었습니다. 이는 Go 1.24에서 진행된 `mallocgc` 함수의 리팩토링 과정에서 발생한 미묘한 메모리 할당자 회귀(Regression) 현상이 원인이었습니다. ### 런타임 지표와 시스템 지표의 불일치 * Go 1.24 업그레이드 후 데이터 처리 서비스의 RSS(Resident Set Size)가 눈에 띄게 증가했으나, Go 런타임 지표와 힙 프로파일상에는 아무런 변화가 기록되지 않았습니다. * 이는 Go 런타임 입장에서는 메모리를 더 사용하고 있지 않다고 판단하지만, 운영체제(Linux) 입장에서는 프로세스가 더 많은 물리 메모리를 점유하고 있는 상태임을 의미합니다. * Kubernetes의 메모리 제한(Limit)이나 OOM 킬러는 시스템 지표인 RSS를 기준으로 작동하기 때문에, 런타임 지표에 나타나지 않는 이러한 증가는 서비스 안정성에 치명적일 수 있습니다. ### 주요 변경 사항에 대한 가설 검증 * 먼저 Go 1.24의 핵심 변화인 '스위스 테이블'과 '스핀 비트 뮤텍스(Spin bit mutex)'를 원인으로 의심하고 실험을 진행했습니다. * `GOEXPERIMENT=noswissmap` 및 `GOEXPERIMENT=nospinbitmutex` 플래그를 사용하여 해당 기능들을 각각 비활성화한 후 빌드하여 배포했으나, 메모리 증가 현상은 해결되지 않았습니다. * 이를 통해 이번 문제는 새로운 기능 자체가 아니라, 런타임의 더 깊은 곳에서 발생한 변화 때문임을 확인했습니다. ### 가상 메모리와 물리 메모리의 매핑 분석 * 리눅스의 `/proc/[pid]/smaps` 파일을 분석하여 프로세스의 메모리 영역별 가상 메모리(Size)와 물리 메모리(RSS)의 차이를 추적했습니다. * 분석 결과, Go 1.23에서는 힙 영역의 RSS가 가상 메모리 크기보다 약 300 MiB 낮게 유지되었으나, Go 1.24에서는 가상 메모리 크기와 RSS가 거의 일치하는 현상이 발견되었습니다. * 결과적으로 Go 1.24의 런타임이 이전 버전보다 가상 메모리를 실제 물리 RAM에 더 공격적으로 할당(Commit)하고 있다는 사실을 밝혀냈습니다. ### mallocgc 리팩토링과 할당자 이슈 * Go 1.24 변경 로그를 정밀 분석한 결과, 메모리 할당의 핵심 로직인 `mallocgc` 함수에 대대적인 리팩토링이 있었음을 확인했습니다. * 이 과정에서 발생한 의도치 않은 로직 변화가 할당된 메모리를 실제 물리적 공간에 매핑하는 방식에 영향을 주어 RSS 상승을 유도한 것으로 파악되었습니다. * 작성자는 이 문제를 Go 개발 팀과 공유하여 원인을 확인했으며, 이는 런타임 리팩토링으로 인한 성능 회귀의 일종으로 결론지어졌습니다. Go 1.24 업그레이드를 고려 중인 팀은 런타임 내부 지표(Heap usage)뿐만 아니라 시스템 레벨의 RSS 지표를 면밀히 모니터링해야 합니다. 비록 메모리 할당자에서 미묘한 RSS 증가가 관측되었지만, 동시에 도입된 스위스 테이블은 대규모 인메모리 맵을 사용하는 서비스에서 수백 기가바이트의 메모리를 절약할 수 있는 잠재력을 가지고 있으므로 서비스 특성에 따른 비교 분석이 필요합니다.

데이터베이스 설계쿠버네티스GoLinux+4

datadog·2025년 7월 17일원문

Go 1.24의 스위스 테이블로 수백 기가바이트를 절약한 방법 (새 탭에서 열림)

Go 1.24에서 도입된 새로운 맵(map) 구현체인 '스위스 테이블(Swiss Tables)'은 대규모 인메모리 데이터를 다루는 서비스에서 획기적인 메모리 절감 효과를 제공합니다. Datadog의 실제 서비스 적용 사례에 따르면, 특정 고부하 환경에서 라이브 힙(Live Heap) 사용량이 500 MiB 감소했으며, 가비지 컬렉터(GOGC)의 영향을 고려할 때 전체 물리 메모리(RSS)는 약 1 GiB까지 절약되었습니다. 이는 Go 1.24의 다른 런타임 오버헤드를 상쇄하고도 남는 수준의 성능 향상을 보여줍니다. **실서비스에서의 메모리 절감 수치** * `ShardRouter` 패키지 내의 `shardRoutingCache`라는 대형 맵에서 약 500 MiB의 라이브 힙 사용량이 감소했습니다. * Go의 기본 GOGC 설정(100)을 기준으로 계산하면, 힙 사용량 감소는 실제 물리 메모리(RSS)에서 약 1 GiB(500 MiB x 2)의 절감으로 이어집니다. * Go 1.24의 다른 회귀 문제(mallocgc 이슈)로 인해 예상되는 400 MiB의 RSS 증가를 고려하더라도, 결과적으로 600 MiB의 순 메모리 감소가 확인되었습니다. **데이터 구조와 메모리 추정** * 해당 맵은 `string`을 키로, `Response` 구조체를 값으로 가집니다. * `Response` 구조체는 `ShardID`(int32), `ShardType`(int), `RoutingKey`(string header), `LastModified`(*time.Time)로 구성됩니다. * 64비트 아키텍처 기준으로 키-값 쌍 하나당 패딩을 포함해 약 56바이트를 차지하며, 서비스 시작 시 대량으로 생성된 후 런타임 중에는 거의 변경되지 않는 특성을 보입니다. **Go 1.23의 버킷 기반 맵 방식과 한계** * 기존 Go 1.23은 8개의 슬롯을 가진 '버킷' 배열로 해시 테이블을 관리했으며, 버킷 수는 항상 2의 거듭제곱으로 유지되었습니다. * 데이터 삽입 시 버킷 내부의 모든 요소를 순차적으로 스캔해야 하므로 CPU 오버헤드가 발생하며, 버킷이 가득 차면 '오버플로우 버킷'을 체이닝 방식으로 추가했습니다. * 평균 로드 팩터(Load Factor)가 13/16(약 81%)을 초과하면 버킷 배열의 크기를 2배로 늘리는 재할당이 발생하는데, 이 과정에서 점진적 복사(Evacuation) 방식을 사용하여 지연 시간을 관리했습니다. **결론 및 권장사항** 대규모 맵 데이터를 메모리에 유지하는 Go 애플리케이션은 Go 1.24로의 업그레이드만으로도 상당한 메모리 효율성 개선을 기대할 수 있습니다. 특히 읽기 중심의 거대 캐시 시스템이나 데이터 라우팅 테이블을 운영하는 경우, 스위스 테이블 기반의 최적화된 메모리 레이아웃이 비용 절감과 성능 향상에 큰 기여를 할 것입니다.

데이터베이스 설계Gogarbage-collectionmemory-optimization+4

datadog·2025년 6월 24일원문

서버 의존성 없이 실시간 클라이언트 사이드 노이즈 억제 라이브러리를 구축한 방법 (새 탭에서 열림)

Datadog의 CoScreen 팀은 원격 협업 중 발생하는 배경 소음을 실시간으로 제거하기 위해, 높은 성능과 이식성을 갖춘 오픈소스 라이브러리인 `dtln-rs`를 개발했습니다. 기존의 노이즈 억제 도구들은 WebRTC와의 통합이 어렵거나 고성능 서버 자원을 요구한다는 한계가 있었으나, 이 라이브러리는 클라이언트 측에서 효율적으로 동작하도록 설계되었습니다. 결과적으로 M1 맥북 프로 기준 1초의 오디오를 단 33ms 만에 처리하며, 서버 의존성 없이 다양한 플랫폼에서 고품질의 실시간 소음 제거를 가능하게 합니다. **dtln-rs: 경량화된 실시간 노이즈 억제 라이브러리** * DTLN(Dual-Signal Transformation LSTM Network) 모델을 기반으로 구축된 Rust 언어 기반의 프로젝트입니다. * WebAssembly(WASM), Native Rust, Node.js 네이티브 모듈 등 다양한 타겟으로 빌드할 수 있어 웹 브라우저와 네이티브 앱 모두에 쉽게 통합 가능합니다. * 실제 테스트에서 이웃의 잔디 깎는 기계 소음을 완전히 제거할 정도로 뛰어난 성능을 보여주었으며, 이를 통해 사용자에게 실제적인 가치를 전달합니다. **DTLN 모델의 작동 원리와 효율성** * STFT(단시간 푸리에 변환)를 사용하여 소리를 작은 단위로 분해하고, 주파수별 볼륨(크기 스펙트럼)과 위상(Phase) 정보를 분석합니다. * LSTM(장단기 메모리) 신경망이 포함된 모델을 통해 분석된 데이터 중 어떤 부분이 음성이고 어떤 부분이 소음인지 실시간으로 판단합니다. * 위상 정보와 크기 성분을 모두 활용하는 딥러닝 방식 덕분에 에어컨 소음, 카페 소음, 종이 부스럭거리는 소리 등 다양한 환경에 동적으로 적응하며 즉각적인 감쇠가 가능합니다. **기존 기술의 한계와 개발 배경** * 기존의 고성능 AI 노이즈 제거 모델들은 대부분 강력한 서버 하드웨어를 필요로 하며, 이는 추가적인 지연 시간(Latency)과 막대한 서버 비용을 발생시킵니다. * WebRTC는 널리 쓰이는 오픈소스 기술임에도 불구하고 내장된 노이즈 제거 기능은 구세대 솔루션에 머물러 있어 현대적인 협업 도구들의 품질 요구 수준을 충족하지 못했습니다. * Google 등 대기업이 사용하는 최첨단 모델은 비공개 소스이거나 전용 서버 인프라에 종속되어 있어, 소규모 팀이나 일반 개발자들이 자신들의 앱에 고품질 기능을 구현하기에는 제약이 컸습니다. 실시간 오디오 및 비디오 애플리케이션을 개발하면서 서버 비용 부담 없이 고성능 노이즈 캔슬링 기능을 추가하고 싶다면 `dtln-rs`를 검토해 보시기 바랍니다. 클라이언트 측 리소스를 효율적으로 활용하면서도 WebRTC와 매끄럽게 결합되는 이 라이브러리는 사용자 경험을 한 단계 끌어올리는 실용적인 해결책이 될 것입니다.

데이터베이스 설계Rust딥러닝webassembly+4

datadog·2025년 6월 23일원문

수천 개의 예측 불가능한 엔드포인트에 안정적으로 로그를 전달한 방법 (새 탭에서 열림)

Datadog은 수천 개의 외부 엔드포인트로 로그를 안정적으로 전달하기 위해 물리적인 택배 배송 서비스의 원리를 소프트웨어 아키텍처에 도입했습니다. 특히 Kafka의 엄격한 순차 처리(FIFO) 특성으로 인해 발생하는 '특정 목적지의 장애가 전체 시스템을 마비시키는 문제'를 해결하는 데 집중했습니다. 이를 통해 저지연, 고처리량, 그리고 높은 신뢰성을 보장하는 멀티테넌트 로그 전달 시스템을 구축할 수 있었습니다. ### 로그 포워딩의 역할과 내부 데이터 흐름 * Datadog 로그 포워딩은 내부에서 처리된 JSON 형식의 로그를 ElasticSearch, Splunk, 또는 커스텀 HTTP 엔드포인트와 같은 외부 목적지로 전송하는 디지털 배송 서비스입니다. * 모든 로그 데이터는 내부적으로 Kafka 토픽을 통해 이동하며, 이는 마치 물류 센터의 컨베이어 벨트처럼 작동하여 데이터의 순서를 보장합니다. * 다양한 고객과 목적지로 향하는 로그들이 Kafka 파티션 내에 혼합되어 흐르기 때문에, 이를 목적지별로 다시 그룹화하여 효율적으로 전달하는 과정이 필요합니다. ### 외부 엔드포인트 연동 시 발생하는 병목 현상 * **엔드포인트 불확실성**: 외부 수신 서버는 Datadog의 통제 밖에 있으며, 수시로 응답이 느려지거나 일시적으로 오프라인 상태가 될 수 있습니다. * **Head-of-Line Blocking**: Kafka는 파티션 내의 데이터를 순서대로 처리(Commit)해야 합니다. 만약 특정 목적지의 서버가 응답하지 않아 전송에 실패하면, 해당 파티션에 담긴 다른 모든 목적지의 로그들까지 전송이 중단되는 병목 현상이 발생합니다. * **데이터 유실과 중복의 트레이드오프**: 전송 성공 확인 없이 다음 데이터를 읽으면 유실 위험이 있고, 성공할 때까지 무한히 재시도하면 전체 시스템의 지연 시간(Latency)이 급격히 증가합니다. ### 대규모 멀티테넌시 환경의 설계 제약 * **리소스 효율성**: 수만 개의 목적지마다 별도의 Kafka 토픽을 생성하는 것은 운영 오버헤드와 리소스 낭비가 너무 커서 현실적으로 불가능합니다. * **처리량 최적화**: 매 로그마다 HTTP 요청을 보내는 대신, 택배를 모아서 한 번에 배송하듯 적절한 '배치(Batch)' 처리를 통해 네트워크 오버헤드를 줄여야 합니다. * **보호 메커니즘**: 고객의 엔드포인트가 과부하로 인해 다운되지 않도록 전송 속도를 조절(Rate Limiting)하는 기능이 필수적입니다. ### 실용적인 결론 대규모 분산 시스템에서 외부 시스템과 연동하는 기능을 설계할 때는 **"단일 장애 지점이 전체 시스템에 미치는 영향"**을 최소화하는 격리 전략이 핵심입니다. Kafka와 같은 FIFO 기반 시스템을 사용할 경우, 장애가 발생한 데이터 스트림을 별도의 재시도 경로로 분리하여 정상적인 데이터 흐름이 방해받지 않도록 아키텍처를 구성해야 합니다.

데이터베이스 설계datadogApache Kafkajson+4

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

모놀리스 해체: 대규모

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

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

데이터베이스 설계datadog옵저버빌리티마이크로서비스

datadog·2025년 6월 17일원문

수천 개의 워크로드 컨테이너에 빠르고 안정적인 구성 배포를 확장한 방법 (새 탭에서 열림)

데이터독(Datadog)은 초당 수백만 개의 로그를 처리하는 대규모 분산 환경에서 사용자가 설정한 로그 파싱 규칙 등 '컨텍스트 데이터'를 수천 개의 컨테이너에 실시간으로 전파해야 하는 과제에 직면해 있습니다. 단순히 데이터베이스를 조회하거나 짧은 주기의 캐시를 사용하는 방식은 대규모 트래픽 환경에서 DB 부하와 지연 시간 문제를 야기하며, 이를 해결하기 위해 데이터독은 안정성과 확장성을 모두 고려한 독자적인 설정 전파 시스템을 구축했습니다. ### 실시간 설정 전파의 기술적 도전 과제 * **컨텍스트 데이터의 중요성**: 로그 파싱 규칙, 민감 데이터 스캐너 설정, 저장 쿼터 등 사용자별(per-tenant) 설정 데이터는 데이터독 서비스가 고객 데이터를 처리하는 방식의 핵심을 이룹니다. * **낮은 지연 시간 요구**: 사용자가 UI에서 설정을 변경하면 '라이브 테일(Live Tail)'과 같은 실시간 서비스에 즉각 반영되어야 하며, 이는 수천 개의 워크로드 컨테이너가 변경 사항을 거의 동시에 인지해야 함을 의미합니다. * **고도의 신뢰성**: 컨텍스트 데이터는 데이터 처리에 필수적이므로, 이 데이터를 공급하는 시스템은 어떤 장애 상황에서도 견고하게 동작해야 하는 '록 솔리드(rock solid)'한 수준의 안정성이 요구됩니다. ### 단순 접근 방식의 한계 * **온디맨드 조회의 불가능**: 로그가 들어올 때마다 DB에서 설정을 읽어오는 방식은 초당 수십만 건의 읽기 요청을 발생시켜 DB가 감당할 수 없는 수준의 부하를 줍니다. * **로컬 캐싱의 트레이드오프**: 각 컨테이너에 데이터를 캐싱하고 일정 시간마다 갱신하는 방식은 DB 부하를 줄일 수 있지만, 캐시 만료 시간만큼 설정 반영이 늦어져 사용자 경험을 저해합니다. 캐시 기간을 늘릴수록 지연은 심해지고, 줄일수록 DB 부하는 급증하는 딜레마가 발생합니다. ### V1 아키텍처: Kafka 기반 캐시 무효화 * **작동 원리**: 사용자가 설정을 변경하면 DB에 저장된 후 Kafka를 통해 무효화 알림(invalidation message)이 브로드캐스트됩니다. 이를 수신한 모든 워크로드 컨테이너는 해당 테넌트의 데이터만 DB에서 다시 읽어와 캐시를 갱신합니다. * **장점**: 수년간 잘 작동했으며, 평상시 DB 읽기 횟수를 최소화하면서도 설정 변경 시에만 신속하게 업데이트를 수행할 수 있었습니다. * **확장성 한계**: 데이터독의 규모가 커짐에 따라 한 번의 설정 변경이 수천 개의 컨테이너에서 동시에 DB 조회를 일으키는 '천둥 벌거숭이(thundering herd)' 문제를 야기했습니다. 이는 중앙 DB에 막대한 부하를 주며, DB 장애 시 설정 전파가 완전히 중단되는 취약점을 드러냈습니다. 사용자 설정 변경이 실시간으로 반영되어야 하는 대규모 분산 시스템에서는 중앙 집중식 데이터베이스에 직접 의존하는 구조를 탈피해야 합니다. 워크로드 컨테이너가 DB에 직접 접근하여 데이터를 가져오는 대신, 변경 사항을 안정적으로 밀어넣어 주거나 중간에 완충 역할을 하는 계층을 두어 DB 부하를 격리하고 시스템 전체의 복원력을 높이는 설계가 권장됩니다.

데이터베이스 설계datadog옵저버빌리티로그 관리+4

datadog·2025년 6월 17일원문

모놀리스를 분해하기: 대규모 환경에서 공유 데이터베이스를 분리하는 방법 (새 탭에서 열림)

Datadog은 성장에 따라 대규모 공유 관계형 데이터베이스가 초래하는 관리 복잡성과 운영 리스크를 해결하기 위해, 공유 데이터베이스를 독립적인 인스턴스로 분리하는 전략을 채택했습니다. 이를 위해 서비스 구축 프레임워크인 'Rapid'와 관리형 Postgres 플랫폼인 'OrgStore'라는 두 가지 핵심 플랫폼에 투자하여, 개별 팀이 운영 부담 없이 직접 데이터베이스를 소유하고 관리할 수 있는 환경을 조성했습니다. 결과적으로 이러한 플랫폼 기반의 접근 방식은 복잡한 데이터베이스 분리 과정을 안전하고 확장 가능한 구조로 전환하는 데 성공했습니다. ### 공유 데이터베이스의 한계와 분리 신호 * **운영 효율의 역설:** 초기에는 단일 데이터베이스가 조인(Join)의 용이성과 낮은 오퍼레이션 비용으로 빠른 제품 출시를 돕지만, 규모가 커지면 데이터베이스 스키마 자체가 API 역할을 하게 되어 변경 시 다른 팀에 미치는 영향을 파악하기 어려워집니다. * **성능 및 안정성 저하:** 단일 머신의 한계를 넘어서는 데이터 크기, 느린 복제 속도, 그리고 특정 서비스의 부하가 전체에 영향을 주는 '노이즈 네이버(Noisy Neighbor)' 문제로 인해 사용자 장애와 성능 저하가 빈번해집니다. * **취약한 스키마 관리:** 한 팀의 스키마 변경이 예상치 못하게 다른 팀의 시스템을 중단시키는 등 데이터 모델 진화가 극도로 위험해지는 시점이 분리의 적기입니다. ### 분리를 가로막는 현실적인 장벽 * **높은 기회비용:** 새로운 서비스를 구축하고 데이터베이스를 이전하는 작업은 분기별 제품 목표 달성을 방해할 만큼 많은 시간을 소요합니다. * **운영 부담의 전이:** 데이터베이스 인스턴스를 직접 소유하게 될 팀에게는 데이터베이스 관리, 백업, 보안 등 추가적인 운영 업무가 큰 부담으로 작용합니다. * **마이그레이션의 난이도:** 기존의 공유 데이터베이스에서 새로운 인스턴스로 데이터를 옮기는 과정이 수동적이고 숙련된 기술을 요하는 '예술적 작업'에 가깝기 때문에 팀들이 선뜻 시작하기 어렵습니다. ### 플랫폼 투자를 통한 해결책: Rapid와 OrgStore * **Rapid 프레임워크:** Datadog 내에서 API 및 gRPC 서비스를 신속하게 구축할 수 있는 표준 프레임워크입니다. 서비스 생성 및 유지보수 비용을 획기적으로 낮춰, 팀이 반나절 만에 새로운 서비스를 배포하고 관리할 수 있게 지원합니다. * **OrgStore 플랫폼:** Postgres 데이터베이스를 관리형으로 제공하는 플랫폼입니다. 팀들이 직접 인프라를 관리하지 않고도 독립적인 데이터베이스 인스턴스를 소유할 수 있게 하여 운영 부담을 제거했습니다. * **구조적 변화:** 이러한 도구들은 "데이터베이스 직접 쿼리"에서 "서비스 API를 통한 데이터 접근"으로의 패러다임 전환을 가능하게 하며, 도메인 간 경계를 명확히 설정할 수 있는 기술적 토대가 되었습니다. ### 성공적인 데이터 분리를 위한 전략 * **기능적 경계 식별:** 데이터베이스를 나누기 전, 기능적 단위로 명확한 도메인 경계를 정의하는 것이 최우선입니다. * **추상화 계층 도입:** 다른 도메인의 데이터가 필요한 경우 데이터베이스에 직접 접근하는 대신, 해당 도메인의 서비스를 통해서만 데이터를 가져오도록 강제하여 의존성을 해소해야 합니다. * **자동화된 마이그레이션:** 수동 작업을 최소화하고 위험을 줄이기 위해 표준화된 마이그레이션 도구와 절차를 구축하여 안전하게 데이터를 이전해야 합니다. 공유 데이터베이스에서 벗어나는 과정은 단순한 기술적 이전을 넘어 플랫폼 공학적인 접근이 필요합니다. 서비스 구축과 데이터베이스 운영 비용을 플랫폼 차원에서 낮추어 주는 것이 팀들이 자발적으로 마이그레이션에 참여하게 만드는 가장 강력한 동기부여가 됩니다.

데이터베이스 설계옵저버빌리티PostgreSQLgrpc+4

datadog·2025년 6월 3일원문

결함 있는 배포 탐지: 라벨링되지 않은 데이터에서 지도 학습까지의 여정 (새 탭에서 열림)

배포는 소프트웨어 개발의 핵심이지만, 구글 SRE에 따르면 전체 장애의 약 70%가 배포와 관련되어 있을 만큼 위험 요소가 큽니다. Datadog은 APM(Application Performance Monitoring) 데이터를 활용해 결함이 있는 배포를 신속히 식별하는 '자동 결함 배포 탐지' 기능을 개발했으며, 이를 위해 레이블이 없는 대규모 데이터셋에서 시작해 정교한 모델을 구축했습니다. 이 과정에서 비지도 학습과 반복적인 프레임워크를 도입하여 데이터 불균형과 서비스별 다양성 문제를 성공적으로 해결했습니다. **결함 배포 탐지의 주요 장애물** - **데이터 레이블의 부재**: 서비스마다 '결함'에 대한 기준이 다르고 명확한 정답 데이터(Ground Truth)가 없어 일반적인 지도 학습 모델을 적용하기 어려웠습니다. - **데이터 불균형**: 결함 배포는 전체 배포 중 극히 일부에 불과한 희귀 이벤트이므로, 단순히 무작위 샘플링을 통해 모델을 학습시키는 방식은 정밀도가 매우 낮았습니다. - **서비스의 다양성**: 트래픽의 계절성, 낮은 트래픽 빈도, 잦은 배포 주기 등 애플리케이션마다 다른 프로필을 가지고 있어 일관된 기준을 적용하기 까다로웠습니다. **결함 배포를 정의하는 세 가지 핵심 속성** - **영향도(Impact)**: 전체 오류 수가 기준치보다 충분히 높아야 하며, 이전 버전들과 비교했을 때 오류율 증가가 유의미하게 높아야 합니다. - **시간적 상관관계(Temporal Correlation)**: 관찰된 오류율의 증가가 새로운 버전의 배포 시점과 명확하게 일치하는지 검증합니다. - **지속성(Persistence)**: 배포 과정에서의 일시적인 노이즈를 배제하기 위해, 증가한 오류율이 일정 시간 동안 안정적으로 유지되는지 확인합니다. **반복적 프레임워크를 통한 모델 고도화** - **통계적 규칙 결합**: 배포 후 60분간의 데이터를 바탕으로 오류율 변화를 비교하는 단순 규칙에서 시작하여, 점차 복잡한 통계적 체크 항목을 늘려나갔습니다. - **만장일치 투표 방식의 앙상블 모델**: 여러 통계적 체크 항목이 모두 결함이라고 판단할 때만 최종적으로 결함 배포로 분류하는 방식을 채택하여 정밀도를 높였습니다. - **반복적 개선 프로세스**: 초기에는 높은 재현율(Recall)을 목표로 설정한 뒤, 수동 레이블링을 통해 오탐(False Positive)을 분석하고 이를 걸러낼 새로운 체크 항목을 추가하며 정밀도를 보정했습니다. - **데이터 피드백 루프**: 탐지되지 않은 결함(False Negative)을 찾기 위해 실제 발생한 인시던트 데이터와 버전 롤백 이력을 활용하여 모델의 임계값을 지속적으로 튜닝했습니다. 실제 환경에서 결함 탐지 모델을 구축할 때는 완벽한 레이블을 기다리기보다, 영향도·상관관계·지속성이라는 핵심 지표를 설정하고 반복적인 피드백 루프를 통해 비지도 학습 모델을 정교화하는 전략이 매우 효과적입니다.

데이터베이스 설계애플리케이션 성능 모니터링incident-managementstatistical-analysis+4