naver·2025년 11월 17일원문

6개월 만에 연간 수십조를 처리하는 DB CDC 복제 도구 무중단/무장애 교체하기 (새 탭에서 열림)

네이버페이는 차세대 아키텍처 개편 프로젝트인 'Plasma'의 최종 단계로, 연간 수십조 원의 거래 데이터를 처리하는 DB CDC 복제 도구인 'ergate'를 성공적으로 개발하여 무중단 교체했습니다. 기존의 복제 도구(mig-data)가 가진 유지보수의 어려움과 스키마 변경 시의 제약 사항을 해결하기 위해 Apache Flink와 Spring Framework를 조합한 새로운 구조를 도입했으며, 이를 통해 확장성과 성능을 동시에 확보했습니다. 결과적으로 백엔드 개발자가 직접 운영 가능한 내재화된 시스템을 구축하고, 대규모 트래픽 환경에서도 1초 이내의 복제 지연 시간과 강력한 데이터 정합성을 보장하게 되었습니다. ### 레거시 복제 도구의 한계와 교체 배경 * **유지보수 및 내재화 필요성:** 기존 도구인 `mig-data`는 DB 코어 개발 경험이 있는 인원이 순수 Java로 작성하여 일반 백엔드 개발자가 유지보수하거나 기능을 확장하기에 진입 장벽이 높았습니다. * **엄격한 복제 제약:** 양방향 복제를 지원하기 위해 설계된 로직 탓에 단일 레코드의 복제 실패가 전체 복제 지연으로 이어졌으며, 데이터 무결성 확인을 위한 복잡한 제약이 존재했습니다. * **스키마 변경의 경직성:** 반드시 Target DB에 칼럼을 먼저 추가해야 하는 순서 의존성이 있어, 작업 순서가 어긋날 경우 복제가 중단되는 장애가 빈번했습니다. * **복구 프로세스의 부재:** 장애 발생 시 복구를 수행할 수 있는 인원과 방법이 제한적이어서 운영 효율성이 낮았습니다. ### Apache Flink와 Spring을 결합한 기술 아키텍처 * **프레임워크 선정:** 저지연·대용량 처리에 최적화된 **Apache Flink(Java 17)**를 복제 및 검증 엔진으로 채택하고, 복잡한 비즈니스 로직과 복구 프로세스는 익숙한 **Spring Framework(Kotlin)**로 이원화하여 구현했습니다. * **Kubernetes 세션 모드 활용:** 12개에 달하는 복제 및 검증 Job을 효율적으로 관리하기 위해 세션 모드를 선택했습니다. 이를 통해 하나의 Job Manager UI에서 모든 상태를 모니터링하고 배포 시간을 단축했습니다. * **Kafka 기반 비동기 처리:** nBase-T의 binlog를 읽어 Kafka로 발행하는 `nbase-cdc`를 소스로 활용하여 데이터 유실 없는 파이프라인을 구축했습니다. ### 데이터 정합성을 위한 검증 및 복구 시스템 * **지연 컨슈밍 검증(Verifier):** 복제 토픽을 2분 정도 지연하여 읽어 들이는 방식으로 Target DB에 데이터가 반영될 시간을 확보한 뒤 정합성을 체크합니다. * **2단계 검증 로직:** 1차 검증 실패 시, 실시간 변경으로 인한 오탐인지 확인하기 위해 Source DB를 직접 재조회하여 Target과 비교하는 보완 로직을 수행합니다. * **자동화된 복구 흐름:** 일시적인 오류는 5분 후 자동으로 복구하는 '순단 자동 복구'와 배치 기반의 '장애 자동 복구', 그리고 관리자 UI를 통한 '수동 복구' 체계를 갖추어 데이터 불일치 제로를 지향합니다. ### DDL 독립성 및 성능 개선 결과 * **스키마 캐싱 전략:** `SqlParameterSource`와 캐싱된 쿼리를 이용해 Source와 Target의 칼럼 추가 순서에 상관없이 복제가 가능하도록 개선했습니다. Target에 없는 칼럼은 무시하고, 있는 칼럼만 선별적으로 반영하여 운영 편의성을 극대화했습니다. * **성능 최적화:** 기존 대비 10배 이상의 QPS를 처리할 수 있는 구조를 설계했으며, CDC 이벤트 발행 후 최종 복제 완료까지 1초 이내의 지연 시간을 달성했습니다. * **모니터링 강화:** 복제 주체(ergate_yn)와 Source 커밋 시간(rpc_time)을 전용 칼럼으로 추가하여 데이터의 이력을 추적할 수 있는 가시성을 확보했습니다. 성공적인 DB 복제 도구 전환을 위해서는 단순히 성능이 좋은 엔진을 선택하는 것을 넘어, **운영 주체인 개발자가 익숙한 기술 스택을 적재적소에 배치**하는 것이 중요합니다. 스트림 처리는 Flink에 맡기고 복잡한 복구 로직은 Spring으로 분리한 ergate의 사례처럼, 도구의 장점을 극대화하면서도 유지보수성을 놓치지 않는 아키텍처 설계가 대규모 금융 플랫폼의 안정성을 뒷받침합니다.

쿠버네티스Apache KafkaKotlinmysql+4

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

복제가 재정의되다: 저지연 멀티 테넌트 데이터 복제 플랫폼을 어떻게 구축했는가 | Datadog

제공된 내용에는 본문이 포함되지 않고, Datadog 제품 내비게이션과 “CDC replication search” 링크만 있습니다. 따라서 글의 주장, 구현 방식, 성능 개선 수치 등은 정확히 요약할 수 없습니다. 링크 제목으로 보아 변경 데이터 캡처(CDC)를 활용해 데이터베이스 변경 사항을 검색 시스템에 복제하는 기술을 다룬 글로 추정됩니다. ### 확인 가능한 주제: CDC 기반 검색 데이터 복제 - CDC(Change Data Capture)는 데이터베이스의 `INSERT`, `UPDATE`, `DELETE` 변경 사항을 실시간으로 감지하는 방식입니다. - 원본 데이터베이스를 주기적으로 전체 조회하지 않고 변경분만 전달하므로 검색 인덱스를 효율적으로 갱신할 수 있습니다. - 일반적으로 다음과 같은 흐름으로 구성됩니다. - 데이터베이스 트랜잭션 로그에서 변경 이벤트 수집 - 이벤트를 메시지 큐나 스트리밍 시스템으로 전달 - 변경 이벤트를 검색 저장소에 반영 - 검색 인덱스와 원본 데이터베이스의 일관성 및 재처리 상태 관리 ### 본문에서 확인할 수 없는 세부 사항 - 사용한 데이터베이스와 검색 엔진 - CDC 이벤트 수집·전달 도구 - 이벤트 순서 보장 및 중복 처리 방식 - 장애 복구와 재처리 전략 - 대규모 트래픽에서의 지연 시간과 처리량 - 스키마 변경 및 삭제 이벤트 처리 방식 원문 본문이나 링크의 실제 내용을 제공하면, 요청하신 형식에 맞춰 기술적 세부 사항까지 정확하게 요약할 수 있습니다.

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

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

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

셰프 인프라 개선: 방해받지 않는 안전

Slack은 Chef Policyfiles로 전환하는 대신, 기존 cookbook과 role을 유지하면서 EC2 프로비저닝 구조를 개선하는 방식을 선택했다. 단일 프로덕션 환경을 `prod-1`부터 `prod-6`까지 분리하고, 카나리와 단계적 릴리스 트레인을 도입해 잘못된 변경의 영향 범위를 줄였다. 그 결과 대규모 확장이나 배포 중에도 문제를 조기에 발견하고 안전하게 롤백·수정할 수 있는 경로를 마련했다. ## Policyfiles 대신 기존 구조 개선 - Policyfiles를 도입하면 roles와 environments를 대체하고 여러 팀의 cookbook을 수정해야 했다. - 장기적으로는 안전성이 높아질 수 있지만, 단기적으로는 수십 개 팀의 대규모 작업과 새로운 변경 위험이 발생했다. - Slack은 기존 cookbook과 role을 변경하지 않고 EC2 프레임워크를 보강하는 방향을 택했다. ## 단일 프로덕션 환경의 위험 - 기존에는 모든 인스턴스가 하나의 `production` Chef environment를 공유했다. - 인스턴스별 cron 작업을 가용 영역(AZ)마다 분산해 Chef 실행 시점을 staggered 방식으로 조정했다. - 이 방식은 잘못된 변경이 전체 노드에 동시에 적용되는 것을 막아 주었지만, 새로 생성된 노드는 즉시 최신 변경을 가져갔다. - 따라서 대규모 scale-out 중 잘못된 cookbook 버전이 수십~수백 개의 새 노드에 한꺼번에 적용될 수 있었다. ## `prod-1`~`prod-6` 환경 분리 - 단일 production environment를 다음과 같이 6개 bucket으로 나눴다. - `prod-1` - `prod-2` - `prod-3` - `prod-4` - `prod-5` - `prod-6` - 서비스 팀은 계속 인스턴스를 “prod”로 실행하지만, 실제 Chef environment는 인스턴스의 AZ에 따라 결정된다. - 노드가 여러 환경에 균등하게 분산되므로 하나의 변경이 전체 프로덕션에 미치는 blast radius가 줄어든다. - 각 environment를 독립적으로 업데이트할 수 있어 특정 AZ 그룹만 대상으로 변경을 검증할 수 있다. ## Poptart Bootstrap의 역할 - Slack의 기본 AMI에는 부팅 시 실행되는 `Poptart Bootstrap` 도구가 포함되어 있다. - 주요 역할은 다음과 같다. - Chef node object 생성 - 필요한 DNS 레코드 설정 - 부팅 성공·실패 결과를 Slack 채널에 알림 - 환경 분리를 위해 노드의 AZ ID를 검사하고 해당 노드를 `prod-1`~`prod-6` 중 하나에 자동 배정하도록 확장했다. - 서비스 팀이 별도의 프로비저닝 방식을 학습하거나 cookbook을 수정하지 않아도 인프라 구조 변경을 적용할 수 있었다. ## 카나리 환경 `prod-1` - `prod-1`은 카나리 프로덕션 환경으로 사용된다. - 새 cookbook 변경이 있으면 매시간 최신 버전을 배포한다. - sandbox와 dev를 거친 변경을 실제 프로덕션 환경에서 작은 규모로 먼저 실행한다. - 모든 production 환경을 통과한 뒤에야 테스트하는 방식보다, 변경이 도입된 시점과 장애 발생 시점의 거리가 짧아 원인 추적이 쉽다. - 누적된 대규모 변경이 아니라 비교적 작은 단위의 artifact를 검증할 수 있다. ## `prod-2`~`prod-6`의 릴리스 트레인 - `prod-2`부터 `prod-6`까지는 순차적인 release train 방식으로 업데이트된다. - 새 버전을 `prod-2`에 배포하기 전, 기존 버전이 `prod-2`에서 `prod-6`까지 성공적으로 진행됐는지 확인한다. - 각 환경의 배포가 완료되어야 다음 단계가 진행되므로 회귀 문제가 전체 프로덕션으로 확산되는 것을 방지한다. - 여러 production environment가 항상 일정한 버전 순서를 유지하도록 설계되어 있다. ## 시간 기반 배포 흐름 - 매시 정각에 최신 cookbook 변경을 sandbox에 반영한다. - 이후 Kubernetes CronJob이 dev 환경으로 변경을 진행한다. - 매시 30분부터 production rollout이 시작된다. - 예를 들어 artifact A가 생성되면: - 정각: sandbox와 dev가 A로 업데이트 - 30분: `prod-1`이 A를 받아 카나리 테스트 - 이후: `prod-2`부터 `prod-6`까지 단계적으로 A를 적용 - 그 사이 새 변경으로 artifact B, C가 생성되더라도 기존 릴리스 트레인의 진행 상태를 고려해 순차적으로 배포한다. 실용적으로는 기존 배포 시스템을 전면 교체하기보다, 환경 분리·카나리·단계적 rollout처럼 변경의 영향 범위를 줄이는 장치를 먼저 도입하는 것이 효과적이다. 특히 대규모 인프라에서는 새 노드가 어떤 버전을 자동으로 받는지와, 실패한 변경이 어디까지 확산될 수 있는지를 별도로 통제해야 한다.

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

쿠버네티스aws-ec2chefcanary-deployment+3

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

LLM을 활용한 대규모

Datadog이 Gartner®의 2026년 Observability Platforms Magic Quadrant에서 Leader로 선정되었다는 내용만 확인됩니다. 제공된 본문에는 선정 기준, 평가 결과, 제품별 강점이나 Gartner의 구체적인 분석은 포함되어 있지 않고, Datadog의 제품·기능 링크 목록이 대부분입니다. ### Gartner Magic Quadrant 리더 선정 - Datadog이 **Gartner® Magic Quadrant™ for Observability Platforms 2026**에서 Leader로 소개됩니다. - 원문 링크는 Datadog의 관련 발표 자료로 연결됩니다. - 다만 제공된 텍스트만으로는 다음 내용을 확인할 수 없습니다. - Gartner의 평가 기준 - Datadog의 실행력 및 비전 평가 - 경쟁사 대비 순위와 강점 - Gartner가 제시한 한계나 주의점 ### Datadog이 제공하는 관측성 제품군 제공된 메뉴에는 Datadog이 단일 모니터링 도구가 아니라 여러 영역을 통합하는 플랫폼으로 구성되어 있음을 보여주는 제품 목록이 포함되어 있습니다. - **인프라 모니터링** - 메트릭, 컨테이너, Kubernetes 오토스케일링 - 네트워크, 서버리스, GPU, 스토리지 및 클라우드 비용 모니터링 - **애플리케이션 성능 관리** - APM, 서비스 모니터링, 지속적 프로파일링 - 동적 계측 및 AI 에이전트 관측성 - **로그·데이터 관측성** - 로그 관리, 민감 데이터 탐지, 감사 추적 - 데이터베이스, 데이터 스트림, 데이터 품질 및 작업 모니터링 - **보안** - SAST, IAST, 소프트웨어 구성 분석, IaC·클라우드 보안 - SIEM, 워크로드 보호, API 보호, 시크릿 스캐닝 - **디지털 경험** - 브라우저·모바일 RUM, 세션 리플레이 - 신세틱 모니터링, 오류 추적, 제품 분석 - **소프트웨어 전달과 서비스 관리** - CI 가시성, 테스트 최적화, 코드 커버리지 - 이벤트·사고 관리, SLO, 서비스 카탈로그, 워크플로 자동화 - **AI 기능** - Bits AI 에이전트, 조사·보안 분석 기능 - MCP 서버, GPU 모니터링, AI 에이전트 관측성 ### 제공된 글의 한계 - 실제 기사 본문이 아니라 Datadog 웹사이트의 헤더와 제품 내비게이션 일부만 제공되어 있습니다. - 따라서 “Leader” 선정 사실과 제품 범위 외에 상세한 기술적 주장이나 결론을 도출하기는 어렵습니다. - 정확한 요약을 위해서는 Gartner 평가 내용과 Datadog 발표문의 본문이 추가로 필요합니다. 원문 본문을 제공하면 Gartner의 평가 근거, Datadog의 차별점, 한계와 실무 적용 시 고려사항까지 포함해 다시 요약할 수 있습니다.

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

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

datadog·2025년 10월 15일원문

실패는 피할 수 없습니다: (새 탭에서 열림)

2023년 3월, 데이터독(Datadog)은 인프라의 약 50~60%가 중단되는 대규모 장애를 겪으며 시스템의 일부가 마비될 때 플랫폼 전체가 완전히 다운된 것처럼 보이는 '정방형 파형(Square-wave)' 장애 패턴을 확인했습니다. 이를 계기로 데이터독은 모든 장애 상황을 완벽히 방지하는 것은 불가능하다는 점을 인정하고, 장애 발생 시에도 시스템이 점진적으로 기능을 유지하는 '우아한 성능 저하(Graceful Degradation)'를 최우선 가치로 삼게 되었습니다. 데이터 유실 방지, 실시간 데이터 우선 처리, 부분적인 결과 제공을 핵심 원칙으로 설정하여 인프라 전반의 회복 탄력성을 재설계하는 대대적인 변화를 추진하고 있습니다. **"결함 없음" 설계의 한계와 Square-wave 장애** - 과거 데이터독은 데이터의 '정확성'을 보장하기 위해 100% 완벽한 데이터가 수집될 때까지 쿼리 결과를 반환하지 않도록 시스템을 최적화했습니다. - 이러한 설계는 일부 노드가 다운되었을 때 시스템 전체가 응답을 멈추게 하여, 사용자에게는 플랫폼이 완전히 중단된 것처럼 보이는 이진적(Binary) 장애를 초래했습니다. - 고전적인 근본 원인 분석(RCA)을 통해 특정 트리거를 제거할 수는 있지만, 소프트웨어 업데이트, 인증서 만료 등 무한한 장애 원인을 모두 예방하는 것은 불가능하다는 결론에 도달했습니다. **우아한 성능 저하를 위한 새로운 우선순위** - 시스템 구성 요소가 완벽하게 작동해야만 가치를 제공하는 '결함 방지(Never-fail)' 아키텍처에서 '더 잘 실패(Fail better)'하는 구조로 전환했습니다. - 데이터 유실 방지: 처리가 늦어지더라도 고객의 데이터가 영구적으로 사라지지 않도록 보장합니다. - 실시간성 우선: 가용 자원이 부족할 때 오래된 데이터보다 실시간 데이터를 우선적으로 처리하여 현재 상태를 파악할 수 있게 합니다. - 부분 결과 제공: 모든 데이터가 준비되지 않았더라도 정확도가 확인된 범위 내에서 부분적인 데이터를 즉시 시각화합니다. **데이터 유실 방지를 위한 영구적 수집 저장소(Persistent Intake Storage)** - 장애 당시 메모리나 로컬 디스크에만 머물던 미복제 데이터가 노드 유실과 함께 사라졌던 문제를 해결하기 위해 파이프라인 초기 단계에 디스크 기반 영구 저장소를 도입했습니다. - 수집(Intake) 직후 데이터를 복제된 저장소에 즉시 기록함으로써, 후속 처리 시스템이 정체되거나 노드가 유실되더라도 데이터 손실 없이 재처리가 가능하도록 설계했습니다. - 이를 통해 네트워크 지연이나 하위 시스템의 과부하 상황에서도 데이터 수집 단계에서의 안정성을 확보했습니다. 모든 장애를 차단하려는 시도보다는, 장애 상황에서도 시스템이 어떻게 부분적으로나마 작동할 수 있을지를 설계 단계부터 고민해야 합니다. 대규모 분산 시스템을 운영한다면 데이터의 완전성(Completeness)과 가용성(Availability) 사이의 균형을 재검토하고, 최악의 순간에도 사용자에게 최소한의 가시성을 제공할 수 있는 복구 탄력성을 구축하는 것이 권장됩니다.

쿠버네티스system-designgraceful-degradationincident-analysis+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

airbnb·2025년 10월 9일원문

에어비앤비의 키-값 저장소에서 정적 속도 제한에서 적응형 트래픽 관리로 (새 탭에서 열림)

에어비앤비는 분산 키-밸류 저장소인 '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 모델과 시스템 상태에 반응하는 적응형 부하 차단 전략을 도입하는 것이 서비스 가용성 확보에 훨씬 유리합니다.

쿠버네티스분산 시스템redisrate-limiting+4

discord·2025년 10월 8일·4분 읽기큐레이션 요약

단일 노드에서 멀티 GPU

Discord는 ML 모델과 데이터 규모가 커지면서 단일 머신으로는 학습·추론을 감당하기 어려워지자 Ray 기반의 분산 컴퓨팅 플랫폼을 구축했다. 핵심은 Ray 자체보다 CLI, Dagster·KubeRay 오케스트레이션, X-Ray 관측성 도구를 결합해 분산 ML의 사용성을 높인 데 있다. 그 결과 엔지니어들은 복잡한 Kubernetes·GPU 설정 없이 멀티 GPU 작업을 실행할 수 있었고, Ads Ranking 모델은 매일 재학습되는 프로덕션 딥러닝 파이프라인으로 발전했다. ## 단일 노드 ML의 확장 한계 - 모델이 단순 분류기에서 대규모 모델로 발전하고 데이터셋도 커지면서 단일 머신에 담기 어려운 작업이 늘어났다. - 일부 학습 작업은 여러 GPU를 필요로 했고, 기존 인프라보다 빠른 연산 능력과 분산 학습이 요구됐다. - Discord는 오픈소스 분산 컴퓨팅 프레임워크인 **Ray**를 기반으로 선택했지만, 프레임워크만 도입해서는 충분하지 않다고 판단했다. - 실제 목표는 분산 ML을 소수의 인프라 전문가가 아니라 일반 ML 엔지니어도 쉽게 사용할 수 있게 만드는 것이었다. ## 수작업 Ray 클러스터의 문제 - 초기에는 엔지니어들이 오픈소스 문서를 참고해 각자 Ray 클러스터를 직접 구성했다. - 팀마다 클러스터 설정과 리소스 관리 방식이 달라 표준화가 어려웠다. - 작업 스케줄링, 모니터링, 클러스터 운영을 위한 공통 기능도 부족했다. - 결국 각 팀이 동일한 인프라 문제를 반복해서 해결하고 있었고, Discord 내부에 Ray 플랫폼이 필요해졌다. ## YAML 대신 단일 CLI 명령 - Discord는 GPU 종류, 워커 수, 메모리 등 필요한 리소스를 인자로 받는 **매개변수화된 단일 템플릿**을 만들었다. - CLI가 실행 시점에 전체 Kubernetes 클러스터 사양과 보안 설정을 생성하도록 했다. - 엔지니어는 복잡한 YAML 파일을 직접 작성하지 않고 자신의 요구에 맞는 멀티 GPU 클러스터를 한 번의 명령으로 생성할 수 있다. - CLI는 클러스터 생성부터 작업 실행, 삭제까지 전체 생명주기를 관리한다. - 이를 통해 다음 효과를 얻었다. - 팀 간 클러스터 설정의 일관성 확보 - 하드웨어 역량에 맞는 리소스 요청 - YAML 디버깅 부담 감소 - 엔지니어별 맞춤형 클러스터 제공 ## Dagster·KubeRay·Ray 기반 오케스트레이션 Discord는 일회성 실험을 정기적이고 재현 가능한 작업으로 전환하기 위해 세 가지 도구를 결합했다. - **Dagster** - 워크플로, 설정, 의존성을 정의한다. - 모델명, 데이터셋 기간, GPU 풀 등의 구조화된 설정을 사용한다. - 스키마 검증과 기본값을 제공해 필수 파라미터 누락으로 인한 실패를 줄인다. - UI 또는 예약 실행을 통해 학습 파이프라인을 시작할 수 있다. - **KubeRay** - Kubernetes에서 Ray 클러스터를 동적으로 생성한다. - 적절한 네임스페이스, 서비스 계정, GPU 노드 풀을 연결한다. - CLI와 동일한 내부 설정 로직을 사용한다. - **Ray** - 생성된 클러스터에서 학습, 평가, 배치 추론 작업을 여러 GPU에 분산 실행한다. 작업 흐름은 다음과 같다. 1. 엔지니어가 Dagster에서 파이프라인을 실행하거나 예약한다. 2. Dagster가 Ray Job Operator에 작업 사양을 전달한다. 3. KubeRay가 적절한 Kubernetes 환경에 Ray 클러스터를 생성한다. 4. Ray가 여러 GPU에 학습 작업을 분배한다. 5. 로그와 메트릭이 Dagster 및 모니터링 시스템으로 전달된다. 이 구조는 버전 관리된 설정을 통한 **예측 가능성**, 파이프라인과 인프라 리소스를 함께 정의하는 **재현성**, SSH 없이 로그와 클러스터 상태를 확인하는 **가시성**을 제공한다. 대표적으로 GPU 사용량이 큰 광고 관련성 모델은 엔지니어가 클러스터 설정을 직접 수정하지 않아도 매일 학습할 수 있게 됐다. ## X-Ray를 통한 통합 관측성 - Ray 사용량이 늘면서 여러 클러스터의 상태를 한곳에서 확인할 필요가 생겼다. - Discord는 **X-Ray**라는 중앙 웹 UI를 구축했다. - X-Ray에서 다음 정보를 실시간으로 확인할 수 있다. - 실행 중인 Ray 클러스터 - 클러스터 소유자 - 머신 및 GPU 종류 - 클러스터 상태 - 관련 대시보드 - 엔지니어는 X-Ray에서 실험용 인터랙티브 노트북도 시작할 수 있어 운영과 실험 환경을 한 인터페이스에서 관리할 수 있다. ## Ads Ranking의 프로덕션 성과 - Ads Ranking은 사용자가 어떤 Quest 광고에 관심을 가질지 결정하는 모델이다. - 도입 전에는 주로 XGBoost를 사용했으며, 기존 인프라에는 다음 기능이 없었다. - 데이터 및 모델 샤딩 - 멀티 GPU 학습 - 필요한 주기의 대규모 재학습 - Ray 도입 후 Ads Ranking은 샤딩된 신경망을 멀티 GPU 클러스터에서 학습하게 됐다. - 성과는 다음과 같다. - Quest 참여 사용자 수 2배 증가 - 광고 트래픽 적용 범위가 약 40%에서 거의 100%로 확대 - 매일 재학습하고 새 버전을 지속적으로 배포하는 프로덕션 딥러닝 파이프라인 구축 - 비즈니스 지표 약 200% 개선 ## 실용적인 시사점 분산 ML 도입에서는 Ray 같은 실행 엔진만 선택하는 것보다, 표준화된 CLI, 선언적 오케스트레이션, 자동화된 클러스터 프로비저닝, 통합 관측성을 함께 제공하는 것이 중요하다. 특히 엔지니어가 인프라 세부사항 대신 모델과 데이터 문제에 집중하도록 만드는 개발자 경험이 분산 시스템의 실제 채택과 운영 성과를 좌우한다.

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

쿠버네티스xgboostraygpu-computing+3

slack·2025년 10월 7일·4분 읽기큐레이션 요약

안전한 배포: 변경

Slack은 고객 영향의 대부분(73%)이 배포를 비롯한 Slack 내부 변경에서 발생한다는 분석을 바탕으로 Deploy Safety Program을 시작했다. 이 프로그램은 자동 감지·복구, 영향 범위 제한, 안전장치와 문화 개선을 통해 고객 영향 시간을 줄이는 것을 목표로 했으며, 2025년 1월에는 정점 대비 고객 영향 시간이 90% 감소했다. 핵심은 특정 배포 시스템만 엄격하게 관리하는 대신, 모든 배포 방식에 반복 적용 가능한 안전 패턴을 구축하면서 개발 속도도 유지하는 것이다. ## 변화가 안정성에 미치는 영향 - Slack이 고객 업무에서 더욱 중요한 제품이 되면서 안정성에 대한 기대 수준이 높아졌다. - 고객 대상 장애의 73%가 Slack 내부 변경으로 발생했으며, 특히 코드 배포가 주요 원인이었다. - 장애 영향은 시스템마다 달랐고, 고객이 사용하는 기능에 따라 피해 정도도 달라졌다. - Slack에는 수백 개의 내부 서비스와 여러 배포 시스템이 있어, 단일한 배포 방식만 개선해서는 문제를 해결하기 어려웠다. - 기존에는 개별 서비스나 배포 시스템에 수동 절차를 추가하는 방식이 많았지만, 이는 개발 속도와 엔지니어링 사기를 떨어뜨렸다. - 고객은 약 10분을 넘는 중단을 단순한 “일시적 문제”가 아닌 심각한 장애로 인식하는 경향이 있었다. ## Deploy Safety의 목표 초기에는 중요도가 높은 서비스 전체를 대상으로 다음과 같은 North Star 목표를 세웠다. - 배포로 인한 영향 시간 단축 - 자동 감지 및 복구: 10분 이내 - 수동 감지 및 복구: 20분 이내 - 영향 심각도 감소 - 전체 플릿의 10%에 도달하기 전에 문제가 있는 배포 감지 - 개발 속도 유지 - 안정성을 높이되 변화와 혁신의 속도를 희생하지 않음 이 목표는 이후 모든 배포 시스템과 프로세스에 적용되는 Deploy Safety Manifesto로 확장됐다. 단순한 운영 절차가 아니라 자동화, 배포 안전장치, 조직 문화의 변화를 함께 추진한 것이 특징이다. ## 고객 영향 시간을 측정하는 지표 Slack은 프로그램의 성과를 측정하기 위해 다음 지표를 정의했다. - **고심각도 및 일부 중간 심각도 변경 유발 장애로 인한 고객 영향 시간** - 장애 심각도는 현재 또는 예상되는 고객 영향을 나타내지만, 실제 최종 영향과 항상 일치하지는 않는다. - 따라서 중간 심각도 장애는 실제 고객 영향 수준을 기준으로 별도 선별해야 했다. - 이 지표는 고객 감정을 직접 측정하는 값이 아니라, 고객 경험을 추정하는 실용적인 대리 지표다. Slack은 다음 세 요소 사이의 연결이 완벽하지 않다는 점도 인정한다. - 고객의 실제 만족도 - Deploy Safety 프로그램 지표 - 개별 프로젝트 지표 따라서 지표를 설계할 때 결과를 측정할 수 있는지, 무엇을 측정하는지 명확한지, 주관적 판단이 일관적인지, 실제 고객 피드백과 계속 비교되는지를 중요하게 봤다. ## 투자할 프로젝트를 고르는 방법 프로그램 초기에는 어떤 프로젝트가 가장 큰 효과를 낼지, 효과가 언제 나타날지 알기 어려웠다. 장애 데이터는 과거 결과를 보여주는 후행 데이터였지만 고객은 이미 현재 문제를 겪고 있었기 때문이다. 이에 따라 Slack은 다음과 같은 투자 전략을 사용했다. - 초기에는 여러 영역에 폭넓게 투자하고 빠르게 실행 - 이미 고객 피해가 확인된 영역을 우선 개선 - 성과가 확인된 프로젝트와 패턴에 추가 투자 - 효과가 낮은 영역의 투자는 축소 - 결과에 따라 바뀔 수 있는 짧고 유연한 로드맵 운영 프로젝트는 주로 다음 중 하나 이상의 목표에 기여하도록 설계했다. - 배포 과정에서 문제를 더 일찍 감지 - 자동 복구 시간 단축 - 수동 복구 시간 단축 - 격리 경계를 설계해 장애의 확산 범위와 심각도 축소 ## Webapp 배포 개선 사례 변경 유발 장애의 가장 큰 원인으로 Webapp backend가 지목되면서 단계적인 개선이 진행됐다. - 자동 메트릭 모니터링 구축 - 자동 알림과 수동 롤백으로 고객 영향 여부 검증 - 자동 배포 및 자동 롤백 도입 - 자동 롤백을 통해 고객 영향 시간을 10분 이하로 유지하는 성과 확인 - 추가 메트릭 모니터링과 수동 롤백 최적화 - Frontend 수동 롤백 기능 추가 - 중앙 집중식 배포 오케스트레이션 시스템으로 패턴 확대 - Slack Bedrock과 Kubernetes를 넘어 여러 배포 시스템에 메트릭 기반 배포와 자동 복구 적용 이 과정을 통해 Webapp backend와 frontend, 일부 인프라 배포가 훨씬 안전해졌으며 분기별로 계속 개선되는 결과를 보였다. ## 반복 가능한 안전 패턴 Slack의 접근 방식은 처음부터 완벽한 시스템을 설계하는 것이 아니었다. - 문제를 해결할 수 있는 작은 프로젝트를 먼저 시도 - 실제 고객 영향과 지표 변화를 통해 효과 검증 - 성공한 방식을 다른 서비스와 배포 시스템에 복제 - 결과가 낮은 영역은 투자를 줄이고 새로운 접근을 시도 즉, Deploy Safety는 하나의 도구나 배포 시스템을 도입하는 프로젝트가 아니라, 측정과 실험을 반복해 조직 전체에 안전한 변경 방식을 확산하는 프로그램이다. 실무적으로는 모든 배포를 수동 승인으로 막기보다, 고객 영향과 직접 연결된 메트릭을 기반으로 조기 감지·자동 롤백·영향 범위 제한을 구축하는 것이 효과적이다. 또한 안정성 지표를 정기적으로 실제 고객 피드백과 비교하고, 효과가 입증된 안전 패턴을 다른 시스템에 재사용해야 개발 속도와 안정성을 함께 확보할 수 있다.

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

쿠버네티스incident-managementaws-pipelinesdeployment-orchestration+2

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

Husky 쿼리 엔진 내부

제공된 내용은 Datadog이 Gartner의 「Observability Platforms」 매직 쿼드런트에서 Leader로 선정됐다는 홍보 문구와 Datadog 제품 메뉴 목록이 중심입니다. 따라서 관측 가능성 플랫폼의 평가 근거나 Husky Query 아키텍처의 기술적 내용은 본문에 포함되어 있지 않아 구체적인 분석은 어렵습니다. 링크의 실제 글 본문이 제공되어야 기술적인 요약이 가능합니다. ### Gartner 매직 쿼드런트 선정 - Datadog이 Gartner의 「Observability Platforms」 부문에서 Leader로 선정됐다고 소개합니다. - 연결된 링크는 Datadog의 Gartner 평가 관련 리소스 페이지입니다. - 평가 기준, 경쟁사 비교, Datadog이 Leader로 분류된 근거는 제공된 텍스트에 포함되지 않았습니다. ### Datadog의 제품 영역 제공된 메뉴는 Datadog이 단일 모니터링 도구가 아니라 여러 운영 영역을 통합하는 플랫폼임을 보여줍니다. - **인프라 모니터링**: 호스트, 메트릭, 컨테이너, Kubernetes, 네트워크, 서버리스, GPU, 클라우드 비용 등을 모니터링 - **애플리케이션 모니터링**: APM, 서비스 모니터링, 지속적 프로파일링, 동적 계측 제공 - **데이터 및 로그**: 데이터베이스, 데이터 스트림, 로그 관리, 데이터 품질, 민감정보 탐지 지원 - **보안**: 코드 보안, SAST, SCA, 클라우드 보안, SIEM, 워크로드 보호, API 보호 등 포함 - **디지털 경험**: 브라우저·모바일 RUM, 세션 리플레이, 신세틱 모니터링, 오류 추적 제공 - **소프트웨어 개발 및 서비스 관리**: CI 가시성, 테스트 최적화, 서비스 카탈로그, SLO, 인시던트 대응, 워크플로 자동화 지원 - **AI 기능**: AI 에이전트 관측성, GPU 모니터링, Bits AI, MCP 서버 및 AI 기반 조사 기능 제공 ### Husky Query 아키텍처 관련 정보 - 메뉴의 Product 링크에는 `husky-query-architecture`라는 경로가 포함되어 있습니다. - 그러나 Husky Query의 저장 구조, 쿼리 실행 방식, 확장성, 성능 개선 방법 등 실제 글의 내용은 제공되지 않았습니다. - 따라서 해당 아키텍처의 기술적 설계나 장단점은 현재 자료만으로 요약할 수 없습니다. 실제 블로그 본문을 붙여 주시면 Husky Query의 아키텍처, 데이터 처리 흐름, 성능 최적화 방식까지 섹션별로 구체적으로 정리할 수 있습니다.

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

쿠버네티스옵저버빌리티애플리케이션 성능 모니터링로그 관리+4

airbnb·2025년 9월 24일원문

에어비앤비의 차세대 (새 탭에서 열림)

에어비앤비는 기존의 키-값(Key-Value) 저장소인 Mussel v1의 운영 복잡성과 확장성 한계를 극복하기 위해, NewSQL 백엔드 기반의 Mussel v2로 아키텍처를 전면 재설계했습니다. 새로운 시스템은 쿠버네티스 네이티브 환경에서 대규모 벌크 로드와 실시간 스트리밍 처리를 동시에 지원하며, 한 자릿수 밀리초 단위의 읽기 성능을 안정적으로 제공합니다. 결과적으로 에어비앤비는 데이터 일관성 제어권 확보와 비용 투명성 강화는 물론, 미션 크리티컬한 서비스들을 중단 없이 성공적으로 마이그레이션하는 성과를 거두었습니다. ### v1의 한계와 재설계 배경 * **운영 복잡성:** EC2와 Chef 스크립트에 의존했던 v1은 노드 확장이나 교체에 수 시간이 소요되었으나, v2는 쿠버네티스 매니페스트를 통한 자동화로 이를 수 분 이내로 단축했습니다. * **데이터 핫스팟:** 정적 해시 파티셔닝(Static Hash Partitioning) 방식은 특정 노드에 부하가 쏠리는 문제를 야기했으나, v2는 동적 범위 샤딩(Dynamic Range Sharding)을 도입하여 100TB 이상의 테이블에서도 안정적인 지연 시간을 유지합니다. * **가시성 부족:** 리소스 사용량이 불투명했던 과거와 달리, v2는 네임스페이스별 테넌시 관리와 쿼터 할당, 대시보드를 통해 비용 통제력을 높였습니다. ### Mussel v2의 핵심 아키텍처 * **Dispatcher:** 상태가 없는(Stateless) 쿠버네티스 서비스로, 클라이언트의 API 호출을 백엔드 쿼리로 변환하며 이중 쓰기(Dual-write)와 섀도우 리드(Shadow-read)를 관리합니다. * **이벤트 기반 쓰기:** 모든 쓰기 작업은 내구성을 위해 Kafka에 먼저 기록된 후 Replayer를 통해 백엔드에 반영되어, 트래픽 급증을 유연하게 흡수하고 일관성을 보장합니다. * **읽기 최적화:** 논리적 테이블 매핑을 통해 포인트 룩업, 범위 쿼리, 접두사 쿼리를 최적화하며, 지연 시간을 줄이기 위해 로컬 복제본으로부터의 읽기(Stale Read) 기능을 제공합니다. ### 벌크 로드 및 데이터 만료(TTL) 시스템 * **고성능 인입:** S3에 업로드된 대규모 데이터를 쿠버네티스 워커 플릿이 병렬로 처리하여 기존 테이블에 병합하거나 교체하는 벌크 로드 프로세스를 최적화했습니다. * **토폴로지 인지형 TTL:** 데이터 범위를 서브 태스크로 나누어 병렬로 스캔하고 삭제하는 서비스를 도입하여, 대규모 데이터셋에서도 라이브 쿼리에 영향을 주지 않고 효율적으로 스토리지를 관리합니다. ### 무중단 마이그레이션 전략 * **Blue/Green 방식 적용:** 기존 v1에 CDC(Change Data Capture) 기능이 부족했음에도 불구하고, Kafka 스트림을 활용한 맞춤형 파이프라인을 구축해 v1과 v2 간의 최종 일관성을 유지했습니다. * **단계적 전환:** 모든 트래픽을 v1으로 보내는 단계부터 v2에서 성능을 검증하는 섀도우 단계, v2를 주 저장소로 사용하는 리버스 단계를 거쳐 최종 컷오버(Cutover)를 진행했습니다. * **안정성 장치:** 테이블 단위로 마이그레이션을 수행하고 자동 서킷 브레이커와 즉시 롤백 로직을 구현하여, 데이터 손실이나 서비스 중단 없이 100개 이상의 유스케이스를 이전했습니다. 성공적인 저장소 엔진 교체는 단순히 성능 향상에 그치지 않고, 운영 자동화와 유연한 확장성을 통해 비즈니스 요구사항에 기민하게 대응할 수 있는 기반을 마련해 줍니다. 특히 대규모 데이터 마이그레이션 시 Kafka를 중간 매개체로 활용하고 단계별 검증 과정을 거치는 전략은 시스템 안정성을 확보하는 데 필수적인 요소입니다.

쿠버네티스Apache Kafkadatabase-migrationapache-airflow+4

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

수동 최적화 Go에서 자기

Datadog이 Gartner의 2026년 Observability Platforms 매직 쿼드런트에서 리더로 선정되었다는 내용이 핵심입니다. 제공된 본문에는 선정 근거와 세부 분석보다 Datadog의 제품군과 플랫폼 기능을 소개하는 탐색 메뉴가 대부분 포함되어 있습니다. 따라서 이 자료만으로는 Gartner의 평가 기준이나 Datadog의 구체적인 강점까지 상세히 요약하기 어렵습니다. ### Gartner 매직 쿼드런트 리더 선정 - Datadog이 **Gartner® Magic Quadrant™ for Observability Platforms 2026**에서 리더로 이름을 올렸다고 소개합니다. - 관측성 플랫폼은 인프라, 애플리케이션, 로그, 사용자 경험 등 여러 영역의 데이터를 통합해 시스템 상태와 장애 원인을 파악하는 도구입니다. - 다만 제공된 내용에는 Gartner의 평가 점수, 경쟁사 비교, 선정 이유 등은 포함되어 있지 않습니다. ### 인프라 및 애플리케이션 모니터링 - 인프라 영역에서 다음 기능을 제공합니다. - 호스트 및 서버 모니터링 - 메트릭 수집 - 컨테이너와 Kubernetes 모니터링 - 네트워크, 서버리스, GPU 모니터링 - 클라우드 비용 및 스토리지 관리 - 애플리케이션 영역에는 다음 기능이 포함됩니다. - APM(Application Performance Monitoring) - 서비스 간 의존성 및 성능 분석 - 지속적 프로파일링 - 동적 계측 - AI 에이전트 관측성 ### 로그·데이터 관측성과 보안 - 로그 관리와 Observability Pipelines를 통해 로그 수집·처리·전송을 지원합니다. - Database Monitoring, Data Streams Monitoring, Jobs Monitoring 등 데이터 처리 과정도 관측할 수 있습니다. - 보안 플랫폼에서는 코드 보안, SAST, SCA, 클라우드 보안, SIEM, 워크로드 보호, 민감 데이터 탐지 등을 제공합니다. - 관측성과 보안 기능을 하나의 플랫폼에서 연계하려는 방향이 드러납니다. ### 디지털 경험과 소프트웨어 전달 - 실제 사용자 모니터링(RUM), 세션 리플레이, 합성 모니터링, 모바일 앱 테스트 등을 제공합니다. - CI Visibility, 테스트 최적화, 코드 커버리지, 피처 플래그 등 소프트웨어 개발·배포 과정도 모니터링합니다. - 서비스 카탈로그, SLO, 인시던트 대응, 워크플로 자동화 등 운영 관리 기능도 포함합니다. ### AI 기반 운영 지원 - Bits AI Agents, Bits Chat, Bits Investigation 등 AI 기능을 통해 장애 조사와 운영 자동화를 지원합니다. - MCP Server, Agent Builder, Agent Directory 등을 통해 AI 에이전트와 Datadog 데이터를 연결할 수 있습니다. - Watchdog과 같은 자동 이상 탐지 기능으로 사람이 모든 알림과 지표를 직접 분석해야 하는 부담을 줄이려는 구조입니다. 제공된 자료를 기준으로 보면 Datadog은 단일 모니터링 도구가 아니라 인프라·애플리케이션·로그·보안·사용자 경험·개발 프로세스·AI 운영을 통합하는 관측성 플랫폼으로 포지셔닝하고 있습니다. 다만 실제 도입을 검토한다면 Gartner 원문에서 평가 기준과 한계, 비용 구조, 데이터 보존 정책을 추가로 확인하는 것이 좋습니다.

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

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

datadog·2025년 8월 12일·3분 읽기큐레이션 요약

규모를 줄여 속도를 높이다

Datadog이 Gartner의 2026년 Observability Platforms 매직 쿼드런트에서 ‘Leader’로 선정되었다는 내용의 홍보 페이지입니다. 제공된 본문에는 선정 근거와 평가 세부 내용보다 Datadog의 관측성·보안·개발·AI 제품군을 소개하는 내비게이션 목록이 주로 포함되어 있습니다. 따라서 이 자료의 핵심은 Datadog이 광범위한 통합 플랫폼을 제공하며 시장 선도 기업으로 평가받았다는 점입니다. ### Gartner 매직 쿼드런트 리더 선정 - Datadog은 Gartner® Magic Quadrant™ for Observability Platforms 2026에서 Leader로 소개됩니다. - 매직 쿼드런트는 관측성 플랫폼 시장의 주요 공급업체를 평가하는 분석 자료입니다. - 제공된 내용만으로는 평가 기준, 경쟁사 대비 강점, Gartner의 구체적인 분석 결과는 확인할 수 없습니다. ### 인프라 및 클라우드 관측성 - 인프라 모니터링과 메트릭 수집을 제공합니다. - 컨테이너와 Kubernetes 환경을 모니터링하고 오토스케일링을 지원합니다. - 네트워크, 서버리스 애플리케이션, 스토리지, GPU를 관찰할 수 있습니다. - 클라우드 비용 관리와 Cloudcraft를 통해 클라우드 구조 및 비용을 파악할 수 있습니다. ### 애플리케이션 성능 모니터링 - APM으로 애플리케이션 성능과 서비스 간 의존성을 추적합니다. - Universal Service Monitoring, Continuous Profiler, Dynamic Instrumentation을 제공합니다. - 데이터베이스, 데이터 스트림, 데이터 품질, 작업 실행 상태도 모니터링할 수 있습니다. - AI 에이전트의 동작을 관찰하는 Agent Observability도 제품군에 포함됩니다. ### 로그 및 데이터 관리 - Log Management로 로그를 수집·검색·분석합니다. - Sensitive Data Scanner를 통해 로그와 데이터에 포함된 민감 정보를 탐지할 수 있습니다. - Observability Pipelines로 관측성 데이터를 필터링, 변환, 라우팅합니다. - Audit Trail을 활용해 사용자 및 시스템 활동을 추적합니다. ### 보안 플랫폼 통합 - 코드 보안, SAST, IAST, SCA, IaC 보안 기능을 제공합니다. - 클라우드 보안 상태 관리, 권한 관리, 취약점 관리, 컴플라이언스를 지원합니다. - Cloud SIEM, 워크로드 보호, 애플리케이션·API 보호 기능도 포함됩니다. - 관측성과 보안 데이터를 하나의 플랫폼에서 연계하려는 방향을 보여줍니다. ### 사용자 경험 및 소프트웨어 전달 - Browser·Mobile RUM으로 실제 사용자 경험을 측정합니다. - Session Replay, Synthetic Monitoring, Error Tracking으로 사용자 문제를 재현하고 분석합니다. - CI Visibility, 테스트 최적화, 지속적 테스트, 코드 커버리지를 제공합니다. - 기능 플래그와 개발자 포털을 통해 배포 및 개발 프로세스도 지원합니다. ### 서비스 관리와 AI 기능 - 이벤트 관리, 인시던트 대응, SLO, 케이스 관리, 워크플로 자동화를 제공합니다. - Software Catalog로 서비스와 소유 관계를 관리할 수 있습니다. - Watchdog과 Bits 계열 AI 기능을 통해 이상 탐지, 조사, 자동화, 대화형 분석을 지원합니다. - MCP Server, AI 에이전트 디렉터리 등 외부 도구 및 에이전트와의 연계 기능도 소개됩니다. 제공된 자료는 Gartner 선정 사실과 Datadog의 제품 범위를 확인하는 용도로 적합합니다. 실제 도입을 검토한다면 Gartner 원문에서 평가 기준과 한계를 확인하고, 조직의 로그 비용·데이터 보존 정책·기존 클라우드 환경·보안 요구사항을 기준으로 별도 비교 평가하는 것이 좋습니다.

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

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

line·2025년 8월 7일원문

Nginx 설정 통합과 Loki 연동으로 설계한 유연한 멀티사이트 아키텍처 (새 탭에서 열림)

LINE NEXT는 빠르게 확장되는 글로벌 서비스 환경에 대응하기 위해 파편화된 웹 서버 인프라를 중앙 집중형 네이티브 Nginx 멀티사이트 구조로 전환했습니다. 기존의 수동 구성 방식과 Ingress Nginx의 제약을 극복하고자 Ansible 기반의 자동화와 설정 통합을 도입했으며, 이를 통해 서비스 론칭 리드 타임을 80% 이상 단축하고 고급 Nginx 기능을 유연하게 구현할 수 있는 환경을 마련했습니다. **Nginx 인프라 아키텍처의 3단계 진화** * **PMC 기반 초기 구조**: 사내 배포 도구인 PMC와 `rsync`를 이용해 서비스별로 독립된 Nginx 서버와 로드밸런서를 운영했습니다. 하지만 서버 발급부터 설정까지 최대 2주의 시간이 소요되었고, 보안망 내 SSH 포트 개방 리스크와 설정 파편화로 인한 유지보수 어려움이 있었습니다. * **Ingress Nginx 기반 구조**: 쿠버네티스 환경에서 헬름 차트를 통해 도메인과 설정을 추상화하여 배포 속도를 높였습니다. 그러나 로드밸런서 프락시 모드 사용 시 클라이언트의 실제 IP(Remote Address) 확인이 어렵고, GeoIP 등 Nginx 네이티브 모듈 활용에 제약이 발생하는 한계가 있었습니다. * **네이티브 Nginx 멀티사이트 구조(현재)**: Ingress Nginx의 설정 중심 방식과 네이티브 Nginx의 기능적 자유도를 결합한 하이브리드 모델입니다. 별도의 Ansible 배포 서버를 구축하여 공통 설정은 유지하되 서비스별로 유연한 기능을 탑재할 수 있도록 개선했습니다. **효율적인 관리와 확장성을 위한 설정 통합** * **마스터 설정과 서버 블록 분리**: Apache의 구성 방식에서 영감을 얻어 `events` 및 `http` 블록의 공통 설정(timeout, log format 등)을 마스터 설정으로 추출하고, 서비스별 가상 호스트 설정은 `sites-available` 디렉터리 내 개별 파일로 관리합니다. * **멀티사이트 아키텍처**: 단일 Nginx 인스턴스에서 다수의 도메인과 서비스를 동시에 서빙할 수 있도록 구조화하여, 신규 서비스 추가 시 설정 파일만 배포하면 즉시 반영되는 환경을 구축했습니다. * **환경별 독립 관리**: 알파, 베타, RC, 프로덕션 등 각 배포 환경에 맞는 설정을 독립적인 리포지터리 구조로 관리하여 운영 안정성을 높였습니다. **Ansible 기반의 안정적인 배포 자동화** * **자동화 프로세스**: 사용자가 타깃 서버와 환경을 지정하면 Ansible이 최신 설정을 클론하여 배포하며, `Nginx Verify`를 통한 문법 검사와 프로세스 상태 체크를 자동으로 수행합니다. * **롤링 배포(Rolling Deployment)**: 서비스 중단을 방지하기 위해 순차적으로 배포를 진행하며, 특정 단계에서 오류가 발생하면 즉시 배포를 중단하여 서비스 영향을 최소화합니다. * **고급 기능 통합**: GeoIP 모듈을 통한 국가별 트래픽 처리, Loki 연동을 통한 실시간 로그 수집, SSL 인증서 자동화 등 복잡한 요구사항을 공통 템플릿 내에서 손쉽게 관리할 수 있게 되었습니다. 다수의 도메인을 운영하고 빠른 서비스 론칭이 필요한 환경이라면, 클라우드 네이티브의 편의성과 네이티브 소프트웨어의 제어권을 모두 챙길 수 있는 'Ansible+네이티브 Nginx' 조합의 멀티사이트 구조 도입을 적극 권장합니다. 이를 통해 인프라 리드 타임 감소는 물론, 보안과 로그 수집 같은 공통 요구사항을 표준화된 방식으로 해결할 수 있습니다.

쿠버네티스nginxansibleinfrastructure-automation+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