datadog2026년 8월 11일

접두사 트라이를 JVM 상수로 인코딩해 APM Java 시작 시간을 개선한 방법 (새 탭에서 열림)

애플리케이션 시작 시간은 사용자 경험, 개발 생산성, 클라우드 비용에 모두 영향을 주며, Java APM의 클래스 매칭 비용도 주요 요인이다. Datadog은 JVM 시작 단계의 제약을 고려해 클래스명 접두사 매칭을 최적화했고, 최근 4년간 관련 오버헤드를 30% 줄였다. 특히 여러 접두사 매칭 트라이(trie)를 하나의 JVM 문자열 상수로 미리 인코딩해, 시작 시 별도의 파일 읽기나 자료구조 구축 없이 빠르게 조회하도록 만든 것이 핵심이다. ## Java APM과 클래스 계측 - Java Instrumentation API는 클래스가 로드되기 전에 변환할 수 있어, 네이티브 코드가 필요한 JVMTI보다 Java 기반 APM 구현에 적합하다. - APM은 메서드 시작·종료 시점 기록, 호출 간 컨텍스트 전파 등을 위해 클래스에 코드를 삽입한다. - 개별 메서드 계측 비용은 작지만, 모든 클래스와 메서드를 계측하면 전체 성능 비용이 급격히 증가한다. - 따라서 관측 가치가 높은 클래스만 선별해야 하며, 이 선별 과정이 **클래스 매칭**이다. ## 클래스명 접두사로 탐색 범위 줄이기 - 일반적인 Java 애플리케이션은 수만 개의 클래스를 정의하고, 대규모 엔터프라이즈 애플리케이션은 10만 개 이상을 로드할 수 있다. - 클래스 파일을 분석하거나 상속 구조를 확인하는 방식은 비용이 크다. - 클래스 파일 파싱이 필요하다. - 관련 타입의 추가 클래스 파일을 읽어야 할 수 있다. - 이에 따라 Datadog APM은 먼저 클래스명과 패키지명 접두사를 curated ignore list와 비교해 계측 대상이 아닌 클래스를 빠르게 제외한다. - 이 초기 접두사 매칭은 모든 클래스에 적용되므로, 작은 알고리즘 개선도 전체 시작 시간에 측정 가능한 영향을 준다. ## JVM 시작 단계의 특별한 제약 - 에이전트는 애플리케이션의 `main`보다 먼저 실행되는 `premain` 단계에서 클래스 변환기를 등록한다. - 이 시점에는 다음과 같은 제약이 있다. - 로드된 클래스가 거의 없다. - JIT 컴파일러가 아직 준비되지 않았다. - Java 8에서는 `premain` 이후에야 JIT가 시작되므로 코드가 인터프리트되고 최적화되지 않는다. - 일부 JDK API 호출이 애플리케이션 동작에 영향을 줄 수 있다. - 예를 들어 `java.util.logging`을 사용하면 `LogManager`가 초기화된다. - 이후 애플리케이션의 `main`에서 사용자 지정 `java.util.logging.manager`를 설정하려 해도 이미 초기화가 끝났기 때문에 동작이 깨질 수 있다. - 따라서 `premain`에서는 외부 리소스, 무거운 라이브러리, 부작용이 있는 JDK API 사용을 피해야 한다. ## 기존 코드 기반 매칭의 한계 - 2020년 당시 Datadog APM Java는 복잡한 중첩 구조의 코드를 직접 생성해 접두사를 매칭했다. - 이 방식은 유연했지만 다음 문제가 있었다. - 매칭 규칙을 유지보수하기 어려웠다. - Java 8의 초기화 단계에서는 JIT 최적화를 기대할 수 없었다. - 시작 시 빠르게 실행되도록 여러 추가 최적화가 필요했다. - 분석 결과, 기존 매칭 규칙에는 트라이 자료구조가 가장 적합한 대안으로 판단됐다. - 하지만 일반적인 트라이는 리소스 파일을 찾고, 읽고, 파싱한 뒤 노드를 구성해야 하므로 `premain` 환경에 적합하지 않았다. ## 트라이를 JVM 문자열 상수로 인코딩 - Datadog은 `ClassNameTrie`라는 접두사 트라이를 만들고, 이를 하나의 JVM 문자열 상수로 표현했다. - 문자열 상수는 클래스 로딩 과정에서 JVM이 직접 로드하므로 다음 장점이 있다. - `ldc` 단일 바이트코드 명령으로 접근할 수 있다. - 파일 검색이나 I/O가 필요 없다. - 클래스 내부에 포함되므로 애플리케이션 패키징·재패키징 후에도 유지된다. - 데이터가 작고 연속적으로 저장되어 캐시 지역성이 좋다. - 시작 단계에 트라이 객체를 별도로 생성할 필요가 없다. ## 문자열 내부의 트라이 구조 - Java의 `char`는 2바이트이며 65,536개의 값을 표현할 수 있다. - 이 값을 일반적인 문자뿐 아니라 트라이의 제어 정보와 매칭 결과 저장에도 사용한다. - 각 트라이 노드는 다음 구조를 가진다. - 첫 번째 문자: 해당 노드의 브랜치 개수 - 이어지는 문자들: 각 브랜치의 문자 - 브랜치 문자 뒤의 값 문자들: 각 브랜치의 결과 정보 - 브랜치 문자는 정렬되어 저장되므로 이진 검색으로 빠르게 다음 경로를 찾을 수 있다. - 값은 상위 비트에 따라 세 가지 의미를 가진다. - **Leaf**: 확정된 결과이며 검색을 즉시 종료한다. - **Bud**: 잠정적인 결과를 제공하지만 더 긴 접두사를 확인하기 위해 검색을 계속한다. - **Inline segment 길이**: 해당 브랜치에 이어지는 문자열 구간의 길이를 나타낸다. - Bud와 leaf에는 glob 비트를 설정할 수 있다. - 기본적으로 결과는 입력 키가 해당 노드에서 정확히 끝날 때만 적용된다. - glob 비트가 있으면 뒤에 문자가 더 남아 있어도 결과를 적용할 수 있다. - 이 비트 구성 때문에 `ClassNameTrie`에 저장할 수 있는 최대 값은 8,191이다. ## 실용적인 결론 JVM의 가장 이른 시작 단계에서 실행되는 코드는 JIT 최적화나 일반적인 런타임 자료구조 생성에 의존하기 어렵다. 이런 환경에서는 작은 매칭 데이터라도 문자열 상수처럼 JVM이 직접 로드할 수 있는 형태로 미리 인코딩하면 초기화 비용과 I/O를 줄이고, 대규모 클래스 탐색의 누적 비용을 낮출 수 있다.

application-performance-monitoringjavajvmjit-compiler+2

datadog2026년 7월 22일

JDK 25에서 JFR을 활용한 편향 없는 Java CPU 프로파일링 (새 탭에서 열림)

Java Flight Recorder(JFR)는 저부하·상시 운영에 적합한 강력한 진단 도구지만, CPU 사용량을 정확히 반영해야 하는 프로파일링에서는 한계가 있다. 특히 `ExecutionSample`은 실제 CPU 시간에 비례해 샘플링하지 않아 CPU 집약적이거나 리액티브한 애플리케이션의 핫스팟을 과소·과대평가할 수 있다. 따라서 현대 프로파일러는 JFR의 안정성과 `AsyncGetCallTrace`·JVMTI 기반 샘플링의 정확성을 결합해 사용하며, 장기적으로는 JVM이 공식 지원하는 CPU 프로파일링 이벤트가 필요하다는 것이 글의 결론이다. ## 연속 프로파일링의 기본 원리 - 프로파일러는 일정 시간 동안 스택 트레이스를 반복 수집하고 집계해 애플리케이션의 동작 패턴을 파악한다. - 샘플링 시점은 프로파일러마다 다르다. - CPU 시간 기반: 실제로 스레드가 CPU를 사용하는 동안만 시간이 증가한다. - 벽시계 시간 기반: 실행, 대기, I/O, 락 대기 등 모든 경과 시간을 포함한다. - CPU 시간 프로파일링은 연산 핫스팟을 찾는 데 적합하다. - 예: 무한 루프나 계산 집중 메서드 - 벽시계 시간 프로파일링은 지연 원인을 찾는 데 유용하다. - 예: 느린 데이터베이스 쿼리, 락 대기, I/O - 메모리 할당, 락 경합, 스레드 파킹, GC 등 특정 이벤트를 기준으로 스택을 수집하는 방식도 있다. - 어떤 이벤트를 사용하든 핵심은 “이벤트가 발생했을 때 어떤 코드가 실행 중이었는가”를 스택으로 기록하고 누적하는 것이다. ## JFR `ExecutionSample`의 장점과 한계 - JFR은 JVM에 내장되어 있으며 GC, 클래스 로딩, 스레드 스케줄링, 메모리 할당 등 다양한 런타임 이벤트를 구조화해 제공한다. - 낮은 오버헤드로 상시 실행할 수 있어 운영 환경에 적합하다. - CPU 프로파일링에는 `ExecutionSample` 이벤트가 사용된다. - 그러나 `ExecutionSample`은 운영체제 수준에서 실제 CPU 시간을 직접 기준으로 샘플링하지 않는다. - JVM이 관찰한 실행 가능 스레드 중 일부를 순환하며 샘플링한다. - CPU를 많이 사용하는 스레드가 더 자주 나타날 수는 있지만, 실제 CPU 사용량에 정확히 비례하지는 않는다. - CPU가 포화된 환경이나 리액티브 애플리케이션에서는 스레드 스케줄링 특성 때문에 특정 CPU 핫스팟이 충분히 나타나지 않을 수 있다. - 결과적으로 프로파일이 틀렸다기보다는 데이터가 불완전해져 원인 분석 시간이 길어질 수 있다. ## `AsyncGetCallTrace`를 이용한 CPU 샘플링 - JVMTI 에이전트와 운영체제 신호인 `SIGPROF`를 사용하면 CPU 시간에 기반해 샘플링할 수 있다. - 신호가 발생한 스레드 안에서 HotSpot의 `AsyncGetCallTrace`를 호출해 비동기적으로 Java 스택을 추적한다. - 이 방식은 세이프포인트 편향을 피하고 JFR에 정의된 이벤트가 아닌 임의의 CPU 이벤트에서도 스택을 수집할 수 있다. - `async-profiler` 같은 도구가 이 접근법을 널리 확산시켰다. - 실제 CPU 사용량에 가까운 결과를 제공하므로 CPU-bound 작업 분석에 특히 효과적이다. ## 내부 JVM API 의존성 문제 - `AsyncGetCallTrace`는 공식 공개 API가 아니라 HotSpot 내부 메커니즘이다. - OpenJ9, Zing 등 다른 JVM에서도 지원되지만 안정적인 표준 인터페이스로 설계된 것은 아니다. - 높은 부하나 특수한 상황에서는 오류를 일으킬 가능성이 있어 프로파일러가 JVM 장애를 방지하기 위한 방어 로직을 추가해야 한다. - Datadog 프로파일러는 다음 방식을 조합한다. - JFR: 안정적인 런타임 텔레메트리 수집 - `AsyncGetCallTrace`: 정확한 Java CPU 스택 샘플링 - `vmstructs` 워킹: JVM 내부 메타데이터를 직접 읽어 스택과 런타임 상태 복원 - `vmstructs`는 표준 API가 노출하지 않는 정보를 얻을 수 있지만, 역시 JVM 내부 구조에 의존한다. - 따라서 프로파일러 제작자는 다음과 같은 절충을 해야 한다. - JFR만 사용하면 안전하지만 CPU 샘플링 정확도가 떨어질 수 있다. - 내부 API를 사용하면 정확하지만 JVM 안정성과 유지보수 부담이 커진다. - 실제 상용 프로파일러들은 대체로 두 방식을 함께 사용한다. ## JVM 프로파일링 기반을 개선하려는 움직임 - Datadog, SAP, Amazon, OpenJDK 커뮤니티는 이 문제가 특정 회사만의 문제가 아니라는 데 공감했다. - JFR은 이미 운영 환경용 프로파일링 기반으로 적합하지만, 정확한 CPU 샘플링을 위한 공식 이벤트가 부족했다. - 기존 생태계가 비공개·비공식 HotSpot API에 의존하는 것은 장기적으로 바람직하지 않다. - 글에서는 이러한 한계를 해결하기 위해 JVM에 안전성과 정확성을 모두 갖춘 “일급 CPU 프로파일링 이벤트”를 추가하려는 협력 과정을 소개한다. - 제공된 원문은 OpenJDK 논의와 새 이벤트의 구체적인 설계 설명이 시작되는 부분에서 중단되어 있다. 운영 환경에서는 JFR만으로 CPU 병목을 단정하기보다, CPU 시간 기반 샘플링을 지원하는 프로파일러를 함께 사용하는 것이 좋다. 다만 JVM 내부 API 의존성은 안정성 위험을 동반하므로, 장기적으로는 공식 JFR CPU 프로파일링 이벤트가 제공되는 JVM과 프로파일러를 선택하는 것이 바람직하다.

javajvmcpu-profilingjava-flight-recorder+3

datadog2026년 7월 1일

대규모 환경에서 데이터 완전성을 측정하는 방법 (새 탭에서 열림)

고객의 대시보드·알림·AI 에이전트가 올바르게 작동하려면 Datadog에 유입된 모든 텔레메트리 데이터가 완전하게 전달되어야 한다. Datadog은 수백 개의 분산 파이프라인과 고객별 경로를 실시간으로 추적하기 위해 파이프라인을 세그먼트로 나누고, 각 payload의 생성과 확인(acknowledgment)을 비교한다. 이 방식은 중복·순서 뒤바뀜·지연 데이터가 존재하는 환경에서도 세그먼트별 문제 위치와 전체 파이프라인의 완전성을 계산하도록 설계되었다. ## Datadog에서 데이터 완전성의 의미 - 완전한 데이터란 Datadog에 들어온 모든 payload가 고객에게 제공되는 상태다. - 대상 payload에는 다음과 같은 텔레메트리 데이터가 포함된다. - 메트릭 데이터 포인트 - 로그 - 트레이스 - 기타 수집 데이터 - 완전성은 전역 단위가 아니라 **고객별로** 판단해야 한다. - 고객마다 파티셔닝, 격리 전략, 트래픽 패턴이 다르다. - 따라서 동일한 리전에서도 데이터가 통과하는 경로가 매우 다양하다. - 시스템은 데이터가 누락되었는지뿐 아니라 다음도 즉시 설명해야 한다. - 어느 구간에서 문제가 발생했는가 - 어떤 서비스가 비정상인가 - 문제가 고객에게 영향을 주었는가 - 진단 결과는 운영자가 수 초 안에 대응하거나 자동화된 시스템이 조치하는 데 사용된다. ## 워터마크 방식의 한계 - 초기에는 Flink 같은 스트리밍 시스템의 워터마크 방식을 고려했다. - 데이터가 일정 시간 안에 도착한다고 가정하고 워터마크를 전진시킨다. - 특정 임계점을 넘으면 해당 시점까지 데이터가 완전하다고 판단한다. - 그러나 Datadog 환경에서는 고객이 임의로 지연된 데이터를 보낼 수 있다. - 또한 다음과 같은 특수 상황이 워터마크를 신뢰하기 어렵게 만든다. - 파이프라인 내부의 루프 - 트래픽 재생 - 예측하기 어려운 데이터 지연 - 따라서 데이터 도착 시점만으로 전체 파이프라인의 완전성을 판단하는 방식은 필요한 보장을 제공하지 못했다. ## 파이프라인을 세그먼트로 분할 - Datadog은 전체 파이프라인을 여러 개의 작은 세그먼트로 나누어 추적한다. - 예를 들어 다음과 같은 흐름이 있을 수 있다. - intake → Kafka → processing → Kafka → router - 각 서비스 내부와 서비스 간 연결을 별도의 세그먼트로 정의한다. - `intake-in → intake-out` - `intake-out → processing-in` - 각 세그먼트에서 다음을 독립적으로 측정한다. - 세그먼트에 들어온 payload 수 - 세그먼트에서 나간 payload 수 - 이 구조의 장점은 다음과 같다. - 누락이 발생한 위치를 구체적으로 찾을 수 있다. - 개별 세그먼트 결과를 합쳐 end-to-end 완전성을 계산할 수 있다. - 파이프라인에 분기 경로가 추가되거나 제거되어도 전체 시스템을 재정의할 필요가 적다. ## 생성 이벤트와 확인 이벤트로 payload 추적 - payload가 세그먼트에 들어오면 `create` 이벤트를 기록한다. - payload가 세그먼트를 빠져나오면 동일한 식별자에 대한 `acknowledgment` 이벤트를 기록한다. - 두 이벤트의 수를 비교해 세그먼트에서 데이터가 유실되었는지 판단한다. - 재시도와 중복 처리를 위해 모든 payload에 고유 식별자를 부여한다. ### 시간 버킷을 이용한 멱등성 - 분산 시스템에서는 이벤트가 중복되거나 순서가 뒤바뀐 채 도착할 수 있다. - 이를 처리하기 위해 완전성을 payload가 Datadog에 처음 들어온 시점의 **시간 버킷** 단위로 계산한다. - 고객 시스템의 시계가 아니라 Datadog이 관리하는 타임스탬프를 사용한다. - 각 버킷에서 payload의 세그먼트별 상태를 관리한다. - 생성됨 - 확인됨 - 생성 이벤트보다 확인 이벤트가 먼저 도착함 - 같은 버킷에서 동일한 식별자의 `create` 또는 `acknowledgment`가 반복되면 기존 상태를 확인하고 중복 이벤트를 무시한다. - 이 방식은 별도의 분산 조정 없이도 카운트를 멱등적으로 유지한다. ## 세그먼트 비율로 전체 완전성 계산 - 각 세그먼트의 완전성은 다음 비율로 정의된다. `세그먼트 완전성 = 세그먼트를 빠져나간 payload 수 ÷ 세그먼트에 들어온 payload 수` - 순차적으로 연결된 파이프라인에서는 각 세그먼트의 완전성 비율을 곱한다. - 예를 들어 두 세그먼트의 완전성이 각각 98%, 96%라면 전체 완전성은 다음과 같다. `98% × 96% = 94%` ### 병렬 분기 처리 - 병렬 분기를 단순히 하나의 파이프라인으로 취급하면 문제가 생긴다. - 예를 들어 APM 트레이스가 다음 두 서비스로 동시에 전달될 수 있다. - 오류율·요청 수를 계산하는 서비스 - 지연 시간 분포를 계산하는 서비스 - 한 분기가 늦게 처리되면 다른 분기에서 이미 사용 가능한 데이터까지 전체적으로 불완전한 것처럼 보일 수 있다. - Datadog은 병렬 분기를 **데이터 처리량에 비례한 가중 평균**으로 결합한다. - 각 분기의 기여도를 해당 분기가 처리하는 payload 양에 따라 산정한다. - 데이터가 많은 분기는 전체 결과에 더 큰 영향을 준다. - 예시에서는 한 분기가 98%와 96%의 두 세그먼트를 거쳐 94% 완전성을 보이고, 다른 분기는 100%를 처리한다. - 이후 각 분기의 처리량을 기준으로 가중치를 적용해 전체 파이프라인 완전성을 계산한다. ## 실용적인 결론 대규모 분산 수집 시스템에서는 전체 파이프라인을 한 번에 관찰하기보다, payload의 이동을 세그먼트별로 계측하는 편이 문제 위치와 고객 영향을 더 정확히 파악할 수 있다. 특히 고유 식별자, 시간 버킷, 멱등적인 상태 추적을 함께 사용하면 재시도와 지연 데이터가 많은 환경에서도 실시간 완전성 검증이 가능하다.

observabilitydistributed-systemskafkaapm+3

datadog2026년 6월 23일

AI 지원 리팩토링을 활용해 실시간 라우팅 시스템을 마이그레이션한 방법 (새 탭에서 열림)

Datadog은 Stream Router의 기존 FoundationDB 기반 KV 모델이 트랜잭션 크기와 데이터 증가에 따른 한계에 도달하자, 운영 중단 없이 PostgreSQL·DuckDB 기반의 관계형 구조로 전환했습니다. 이 과정에서 Claude와 Cursor를 활용했지만, AI가 자율적으로 코드를 작성한 것이 아니라 사람이 새 스키마와 기존 구현, 실패 테스트를 제공하고 테스트 결과로 검증하는 방식으로 사용했습니다. 핵심 결론은 AI가 대규모 마이그레이션을 크게 가속할 수 있지만, 데이터 모델 설계와 안전성 판단은 여전히 사람의 전문성이 필요하다는 것입니다. ## Stream Router의 역할과 기존 아키텍처 - Datadog은 하루 100조 개가 넘는 이벤트를 처리하며, 각 메트릭 데이터를 올바른 Kafka 클러스터·토픽·파티션으로 라우팅해야 합니다. - Stream Router는 Kafka 메시지를 직접 생산하거나 소비하지 않고, 다른 서비스가 사용할 라우팅 결정을 관리하는 제어 평면 서비스입니다. - 라우팅 정보는 다음과 같은 용도로 사용됩니다. - Producer가 데이터를 기록할 위치 결정 - Querier가 데이터를 읽을 위치 결정 - 시간에 따른 데이터 위치 이력 관리 - 기존 구조는 쓰기와 읽기를 분리한 Eventually Consistent 아키텍처였습니다. - 쓰기 경로: FoundationDB의 키-값 모델 사용 - 읽기 경로: 주기적으로 생성된 스냅샷을 RocksDB와 메모리 데이터베이스에 적재 - Producer와 Querier는 쓰기 경로에 직접 접근하지 않음 ## 설정 파일에서 중앙 제어 평면으로의 발전 - 2016년에는 몇 줄짜리 설정 파일을 모든 서비스에 배포해 라우팅을 관리했습니다. - 인프라와 고객 규모가 커지면서 설정 파일이 수천 줄로 증가했고, 수동 편집과 배포가 운영 부담이 되었습니다. - Stream Router 도입 후에는 다음과 같이 개선되었습니다. - 설정 파일 대신 gRPC API로 라우팅 변경 - 자동화된 오케스트레이션 - 점진적이고 자동화된 롤아웃 - 고가용성과 장애 내성을 고려한 읽기·쓰기 분리 ## KV 모델의 확장 한계 - 라우팅 데이터는 단순한 키-값 목록이 아니라 서로 연결된 관계형 데이터였습니다. - Route는 특정 Kafka Stream을 참조 - Route는 Sharding Strategy를 참조 - Rule은 Route를 참조하고 활성화 시점과 적용 방식을 결정 - 기존 KV 구조에서는 데이터베이스가 제공해야 할 관계 검증을 애플리케이션이 직접 수행해야 했습니다. - 수만 개의 레코드를 Pod 프로세스로 가져옴 - 애플리케이션 내부에서 관계형 데이터베이스처럼 조인과 일관성 검사를 수행 - 데이터와 변경 규모가 커지면서 FoundationDB 트랜잭션 크기 제한에 걸리는 작업이 발생했습니다. - FoundationDB를 PostgreSQL로 단순 교체하는 방안도 해결책이 되지 못했습니다. - 기존 KV 접근 패턴을 그대로 유지하면 수천 번의 순차적인 데이터베이스 왕복이 필요 - 일부 작업은 약 45분이 걸릴 것으로 예상 - 따라서 병목의 원인은 특정 데이터베이스가 아니라, KV에 맞춰진 데이터 모델과 애플리케이션 로직 자체였습니다. ## 관계형 스키마로 재설계 - 팀은 AI를 사용하기 전에 도메인 관계를 직접 분석하고 새 스키마를 설계했습니다. - 관계형 구조에서는 다음 관계를 외래 키로 명시합니다. - Streams와 Sharding Strategies → Routes - Routes → Rules - 기존 애플리케이션 코드가 수동으로 복원하던 관계를 데이터베이스가 직접 표현하고 검증할 수 있게 되었습니다. - 쓰기 경로에는 PostgreSQL을 선택했습니다. - 관계형 의미론 지원 - 트랜잭션 처리 - Datadog의 자체 관리형 PostgreSQL 플랫폼 활용 가능 - 읽기 경로에는 DuckDB를 선택했습니다. - 스냅샷 기반 읽기 계층에 적합한 임베디드 데이터베이스 - 배열 컬럼을 기본 지원 - PostgreSQL과 유사한 SQL 문법 - PostgreSQL과 DuckDB 사이에서 쿼리 로직을 공유할 수 있음 - SQLite도 검토했지만 배열 컬럼을 기본 지원하지 않아 적합하지 않았습니다. ## AI를 활용한 테스트 중심 리팩터링 - Claude와 Cursor는 코드를 독립적으로 생성하도록 맡기지 않았습니다. - 각 메서드마다 사람이 다음 정보를 제공했습니다. - 기존 구현 - 새 데이터베이스 스키마 - 현재 실패하는 테스트 - AI는 이를 바탕으로 첫 번째 구현을 만들었고, 테스트가 코드의 정확성을 검증했습니다. - 이 방식의 장점은 다음과 같습니다. - 전체 마이그레이션을 한 번에 생성하지 않고 메서드 단위로 분할 - 실패 테스트가 요구사항과 오류를 구체적으로 제시 - 생성 코드가 실제 동작과 데이터 관계를 만족하는지 즉시 확인 - 사람이 설계와 판단을 담당하고 AI는 반복적인 변환 작업을 가속 ## 안전한 마이그레이션을 가능하게 한 조건 - 마이그레이션이 성공할 수 있었던 기반은 AI보다 기존 시스템의 구조와 개발 프로세스였습니다. - 특히 저장소 계층이 `Controller`라는 내부 인터페이스 뒤에 모듈화되어 있었습니다. - 이러한 추상화 덕분에 저장 엔진과 구현을 교체하더라도 상위 계층의 변경 범위를 줄일 수 있었습니다. - 글의 제공된 부분은 안전성을 뒷받침한 요소를 설명하는 도중 끝나므로, 이후 테스트 전략이나 실제 전환 절차의 상세 내용은 포함되어 있지 않습니다. 결국 AI는 관계형 스키마를 설계하거나 운영 위험을 판단하는 도구라기보다, 명확한 설계와 테스트가 준비된 상태에서 반복적인 코드 변환을 빠르게 수행하는 도구로 활용하는 것이 적절합니다. 대규모 운영 시스템에서는 먼저 데이터 모델과 인터페이스를 사람이 설계하고, 작은 단위의 실패 테스트를 기준으로 AI 생성 코드를 검증하는 방식을 추천할 수 있습니다.

database-designpostgresqlkafkagrpc+4

datadog2026년 6월 4일

페일오버가 안전하지 않을 때: Kubernetes에서 고가용성 PostgreSQL 구축하기 (새 탭에서 열림)

Datadog은 게임데이를 통해 PostgreSQL 클러스터가 특정 가용 영역의 네트워크 장애에서 안전하게 페일오버하지 못하는 문제를 발견했다. 비동기 복제 환경에서는 장애가 발생한 리더가 계속 쓰기를 처리하는 동안 복제 지연이 커졌고, 모든 스탠바이가 안전한 승격 기준을 충족하지 못했다. 이를 해결하기 위해 Patroni가 관리하는 동기 복제 기반의 페일오버 후보를 도입해 내구성과 자동 복구 가능성을 높이려 했다. ## 게임데이로 드러난 가용 영역 장애 - 스테이징 환경에서 특정 가용 영역에 네트워크 지연을 의도적으로 유발했다. - 해당 영역에 PostgreSQL의 primary 또는 writer 노드가 위치해 있었다. - primary와 replica 간 통신이 불안정해지면서: - 복제 지연(replication lag)이 빠르게 증가 - 쓰기 작업이 멈추거나 지연 - 애플리케이션이 오래된 데이터를 조회 - 모든 replica가 primary의 최신 상태를 충분히 반영하지 못해 안전한 승격 대상이 사라졌다. - 결과적으로 지연이 해소되고 replica가 따라잡을 때까지 기다리는 것 외에는 복구 방법이 없었다. ## Kubernetes 기반 PostgreSQL 아키텍처 - 클러스터는 **leader pool**과 **read replica pool**로 분리된다. - Leader pool: - 하나의 active writer가 모든 쓰기를 처리 - 두 개의 standby 노드는 애플리케이션 읽기 트래픽에는 사용되지 않음 - leader 장애 시 standby가 승격될 수 있음 - Read replica pool: - 읽기 전용 트래픽 처리 - 읽기 확장과 쿼리 격리를 담당 - 페일오버 후보에서는 제외 - 이 구조는 읽기 용량을 독립적으로 확장하고 writer의 쓰기 지연을 안정적으로 유지하는 데 유리하다. - 그러나 장애 시 실제로 승격 가능한 노드 수가 제한되므로, 해당 후보들의 복제 상태가 중요하다. ## Patroni와 ZooKeeper의 역할 - Patroni는 PostgreSQL의 복제, 리더 선출, 페일오버를 관리한다. - ZooKeeper는 분산 구성 저장소(DCS)로 사용되며 다음 정보를 저장한다. - 현재 leader 키와 락 - 클러스터 설정 - 각 노드의 복제 상태와 최신 LSN - 새 노드는 ZooKeeper에 leader가 있는지 확인한다. - leader가 없으면 ephemeral znode를 생성해 leader 락 획득을 시도 - ZooKeeper의 단일 획득 보장으로 다중 primary(split-brain)를 방지 - leader가 이미 있으면 새 노드는 replica로 동작하며 스트리밍 복제를 시작 - 네트워크 파티션 상황에서는 상태를 확신할 수 없는 노드의 승격을 보수적으로 제한한다. - leader가 ZooKeeper와 통신하지 못하면, 적격 standby만 leader 락을 획득하도록 조정한다. - 기존 leader가 복구 후 leader 락을 다시 획득하지 못하면 스스로 강등되어 단일 leader 원칙을 유지한다. ## 비동기 복제의 한계 - 기존 환경은 PostgreSQL의 기본 복제 방식인 비동기 복제를 사용했다. - primary는 replica의 WAL 수신 확인을 기다리지 않고 트랜잭션을 커밋한다. - 장점: - 쓰기 지연이 낮음 - 높은 처리량 유지 - 단점: - primary 장애 시 아직 replica에 전달되지 않은 커밋 데이터가 유실될 수 있음 - 네트워크 지연이 커지면 replica가 primary보다 크게 뒤처질 수 있음 - 게임데이에서는 primary가 복제 지연 중에도 계속 쓰기를 수락했다. - 그 결과 모든 standby가 안전한 페일오버 기준을 초과했고, 장애 시 복구 가능한 후보가 남지 않았다. ## `maximum_lag_on_failover`와 안전한 승격 - Patroni는 standby를 승격하기 전에 복제 지연이 허용 범위 안에 있는지 검사한다. - 이 기준은 `maximum_lag_on_failover` 파라미터로 설정된다. - standby가 이 기준보다 많이 뒤처진 상태에서 승격되면 데이터 손실이나 불일치가 발생할 수 있다. - 따라서 Patroni가 승격을 거부한 것은 오작동이 아니라 데이터 일관성을 지키기 위한 정상적인 동작이었다. - 문제의 본질은 Patroni가 아니라, 장애 시 기준을 충족하는 standby가 하나도 없었다는 점이다. ## 동기 복제를 통한 개선 방향 - 동기 복제에서는 primary가 최소 한 replica의 확인 응답을 받은 뒤 클라이언트에 트랜잭션 성공을 반환한다. - 이를 통해 최소 한 replica에 커밋 데이터가 반영되었음을 보장할 수 있다. - 비동기 복제보다 쓰기 지연과 성능 비용이 발생하지만, primary 장애 시 데이터 유실 위험은 크게 줄어든다. - Datadog은 페일오버 후보에 동기 복제를 적용하고 Patroni가 이를 조정하도록 아키텍처를 재설계했다. - 목표는 성능 특성을 과도하게 훼손하지 않으면서 자동적이고 안전한 페일오버를 구현하는 것이었다. 실무적으로는 모든 읽기 replica에 동기 복제를 적용하기보다, 실제 페일오버 후보에만 동기 복제를 적용해 성능과 내구성의 균형을 맞추는 접근이 적절하다. 또한 네트워크 지연과 영역 장애를 가정한 게임데이 및 복제 지연 기반의 페일오버 테스트를 정기적으로 수행해야 한다.

k8spostgresqlhigh-availabilitydatabase-replication+4

datadog2026년 6월 2일

단일 풀 리퀘스트부터 전체 소프트웨어 패키지까지: 대규모 악성 코드 탐지 (새 탭에서 열림)

BewAIre는 LLM을 활용한 악성 코드 탐지 시스템으로, 기존의 풀 리퀘스트 분석에서 전체 의존성 패키지와 패키지 레지스트리 스캔으로 범위를 확장했다. 저비용 필터 단계와 고성능 에이전트 조사 단계를 결합해 비용과 지연 시간을 줄이면서도 정확도를 97.4%에서 99.86%로 높였고, 오탐을 17건에서 0건으로 낮췄다. 또한 LLM만으로 판단하지 않고 도메인·의존성 검증 같은 정적 검사를 함께 사용해 공급망 공격 탐지의 안정성을 강화했다. ## 풀 리퀘스트 분석만으로는 부족한 이유 - 공격자는 axios, LiteLLM, Mistral 같은 널리 사용되는 의존성 패키지를 침해해 악성 코드를 downstream 사용자에게 확산시킬 수 있다. - 기존 BewAIre는 풀 리퀘스트의 diff를 분석해 침투 테스트, 버그 바운티 활동, 실제 공격을 식별했다. - 그러나 공격 표면은 풀 리퀘스트에 한정되지 않으므로, 전체 패키지와 upstream 레지스트리까지 검사할 필요가 생겼다. - 단순히 더 강력한 추론 모델을 사용하면 정확도는 높아지지만 비용이 증가하고, 대규모 diff는 컨텍스트 윈도우 제한에 부딪힌다. ## 2단계 LLM 평가 구조 - **필터 단계** - 모든 변경 사항을 저렴하고 빠른 모델로 1차 검사한다. - 대규모 diff에는 diff 청크 분할 전략을 적용한다. - 판단은 “의심스러움” 또는 “정상”의 이진 결과다. - 정상으로 판정되면 즉시 종료해 고비용 분석을 피한다. - **조사 단계** - 필터가 의심 신호를 감지한 경우에만 고성능 추론 모델을 호출한다. - 단순히 diff를 읽는 것이 아니라 도구를 사용해 추가 정보를 수집한다. - GitHub API로 커밋 목록, 파일 내용, 기여자 이력, 의존성 메타데이터, 커밋 범위를 조사할 수 있다. - 의심스러운 커밋이 최종 diff에서 사라지도록 되돌려졌는지, 의존성이 typosquatting인지, 작성자의 계정과 소속이 정상적인지 확인한다. - 의존성은 osv.dev와 Datadog SCA 같은 외부 리소스로 검증한다. ## 스택형 LLM 호출이 오탐을 줄인 방식 - 대표 테스트 데이터 690개 diff에서 정확도가 **97.4%에서 99.86%**로 향상됐다. - 오탐은 **17건에서 0건**으로 감소했다. - 대부분의 정상 변경은 필터 단계에서 빠르게 종료되므로 전체 지연 시간도 줄었다. - 의심스러운 변경에 대해서는 더 많은 문맥과 도구를 활용해 정밀한 분석을 수행한다. - 필터 단계와 조사 단계의 역할을 분리함으로써 비용, 속도, 탐지 품질을 동시에 관리했다. ## 에이전트 기반 조사 사례: 파일명에 숨은 명령어 주입 - 공격자는 다음과 같은 형태의 파일명을 사용했다. ```text m$(echo${IFS}...|base64 -d|bash).md ``` - 파일명에 셸 명령 치환을 삽입하고, Base64로 인코딩한 명령을 디코딩해 실행하도록 구성했다. - 실제 페이로드는 외부 서버에서 코드를 내려받아 `bash`로 실행하는 `curl ... | bash` 형태였다. - `${IFS}`를 사용해 공백을 우회하고 보안 필터를 피하려 했다. - 조사 에이전트는 다음과 같은 추가 정황도 확인했다. - 작성자 계정이 생성된 지 7일밖에 되지 않음 - 프로필 정보와 팔로워가 없음 - 리뷰나 승인이 없음 - diff 자체의 악성 명령뿐 아니라 계정 이력과 PR 상태까지 결합해 공격 가능성을 판정했다. ## LLM과 정적 검사의 결합 - 필터 단계는 빠르고 저렴하지만 외부 정보를 직접 탐색하지 못해 일부 공격을 정상으로 판단할 수 있다. - 대표적인 사례가 Datadog과 유사한 도메인을 사용하는 typosquatting 공격이다. - 이를 보완하기 위해 전처리 파이프라인에서 입력에 포함된 모든 도메인을 추출한다. - 정상적인 Datadog 도메인 목록을 바탕으로 생성한 typosquatting 변형 목록과 비교한다. - 이 정적 검사는 LLM에게 의심스러운 Datadog 인접 도메인이라는 명확한 신호를 제공한다. - 비결정적이고 비용이 높은 LLM 판단과 결정적이고 저렴한 정적 검사를 조합해 정확도와 비용 효율을 함께 확보했다. ## 실용적인 결론 대규모 공급망 보안에서는 모든 변경을 고성능 LLM으로 분석하기보다, 저비용 필터와 선택적 심층 조사를 결합하는 방식이 효과적이다. 특히 계정 이력·커밋 상태·도메인·의존성 데이터 같은 외부 문맥과 정적 규칙을 함께 사용해야 LLM의 오탐과 누락을 줄일 수 있다.

llmagentic-aidependency-scanningsoftware-supply-chain-security+4

datadog2026년 4월 21일

대규모 스테가노그래피: Datadog 위젯 스크린샷에 공유 URL 삽입하기 (새 탭에서 열림)

데이터독(Datadog)은 사용자가 위젯을 스크린샷으로 캡처하더라도 쿼리, 시간 범위, 대시보드 설정과 같은 풍부한 컨텍스트를 보존할 수 있도록 픽셀 단위의 '보이지 않는 워터마크' 시스템을 구축했습니다. 위젯의 메타데이터 전체를 이미지에 직접 담는 대신, 해당 데이터를 저장한 Redis 캐시의 고유 키를 위젯 테두리 픽셀의 RGB 값을 미세하게 조정하여 인코딩하는 방식을 채택했습니다. 이를 통해 사용자 경험을 해치지 않으면서도 하루 10억 개 이상의 위젯에 대해 스크린샷만으로 원본 데이터에 접근할 수 있는 연결성을 제공합니다. **스크린샷의 한계와 워터마킹의 도입 배경** - 대시보드 위젯을 복사하여 붙여넣으면 라이브 프리뷰와 데이터 연결이 유지되지만, 많은 사용자는 직관적이고 권한 문제에서 자유로운 스크린샷 방식을 선호합니다. - 하지만 일반적인 스크린샷은 캡처 시점의 쿼리, 시간 범위, 시각화 유형 등 유용한 메타데이터를 모두 잃어버린다는 단점이 있습니다. - UI에 요소를 추가하지 않고도 이 정보를 보존하기 위해, 육안으로는 식별할 수 없지만 알고리즘으로 읽을 수 있는 픽셀 기반 워터마킹 기술을 도입했습니다. **데이터 최적화 및 캐싱 전략** - 위젯 정의 데이터는 평균 2KB로 이미지에 직접 인코딩하기에는 너무 크기 때문에, 전체 데이터는 Redis 캐시에 저장하고 이를 참조하는 짧은 고유 ID만 워터마크에 포함합니다. - 위젯이 렌더링될 때마다 프론트엔드에서 낙관적(Optimistic)으로 ID를 생성하여 백엔드 응답을 기다리지 않고 즉시 워터마크를 삽입함으로써 성능 저하를 방지합니다. - 조직 ID와 8바이트 무작위 ID를 조합하여 대규모 환경에서도 ID 충돌 가능성을 극도로 낮추었으며, 데이터는 스크린샷이 주로 활용되는 시간대를 고려해 1시간 동안 캐싱됩니다. **픽셀 레벨의 미세 인코딩 기법** - 모든 대시보드 위젯이 공통적으로 가진 1px 두께의 테두리를 데이터 삽입 공간으로 활용하여 시각화 유형에 상관없이 일관된 적용이 가능하게 했습니다. - RGB 모델의 각 채널 값을 미세하게 오프셋(Offset)하는 방식을 사용합니다. 기본 배경색에서 각 채널값을 조정한 뒤 0~7 사이의 값을 더해 픽셀당 약 9비트의 데이터를 저장합니다. - 워터마크의 시작과 끝을 알리는 센티널(Sentinel) 픽셀을 배치하고 그 사이에 8개의 데이터 픽셀을 넣어 총 8바이트의 ID를 인코딩하며, 이는 육안으로 거의 식별되지 않습니다. 이 시스템은 장애 대응이나 협업 과정에서 스크린샷이라는 익숙한 도구를 사용하면서도, 필요할 때 언제든 원본 데이터 컨텍스트로 복귀할 수 있는 강력한 연결성을 제공합니다. 대규모 트래픽 환경에서도 성능 영향 없이 작동하도록 설계된 이 기법은 단순한 이미지를 지능적인 데이터 포인터로 변환하는 실용적인 해법을 제시합니다.

datadogperformance-optimizationrediswatermarking+3

datadog2026년 4월 21일

대규모 스테가노그래피: Datadog 위젯 스크린샷에 공유 URL 임베딩하기 (새 탭에서 열림)

Datadog은 사용자가 대시보드 위젯을 스크린샷으로 캡처할 때 유실되는 쿼리, 시간 범위 등의 컨텍스트를 보존하기 위해 픽셀 수준의 보이지 않는 워터마크 기술을 도입했습니다. 위젯의 테두리 픽셀에 미세한 색상 변화를 주어 메타데이터 키를 인코딩함으로써, 정적 이미지에서도 원본 데이터와 상호작용할 수 있는 기능을 구현했습니다. 이 시스템은 하루 10억 개 이상의 위젯 렌더링을 처리하면서도 사용자 경험에 영향을 주지 않는 성능과 투명성을 유지합니다. ### 스크린샷의 한계와 보이지 않는 워터마크의 필요성 - 대시보드 공유 링크는 실시간 데이터와 쿼리 정보를 포함하지만, 많은 사용자는 여전히 직관적이고 권한 문제에서 자유로운 스크린샷 공유를 선호합니다. - 일반적인 스크린샷은 이미지 픽셀 정보만 남기 때문에, 당시의 구체적인 타임프레임이나 기반 쿼리, 대시보드 상태와 같은 중요한 컨텍스트가 모두 사라집니다. - Datadog은 사용자 인터페이스를 해치지 않으면서도 스크린샷 내부에 보이지 않게 메타데이터를 심어, 이미지를 다시 Datadog이나 협업 도구(Slack 등)에 붙여넣었을 때 원본 위젯을 복구하고자 했습니다. ### 효율적인 데이터 관리를 위한 Redis 캐싱 전략 - 위젯 정의(Definition) 데이터는 평균 2kB로 이미지에 직접 모두 인코딩하기에는 너무 큽니다. - 이를 해결하기 위해 전체 위젯 정의는 Redis 캐시에 저장하고, 이를 식별할 수 있는 짧은 8바이트 고유 키(Snapshot ID)만 워터마크로 인코딩합니다. - 하루 10억 건 이상의 위젯 렌더링과 초당 35,000건의 피크 타임을 감안하여, 충돌 방지를 위해 조직 ID(Org ID)를 조합한 키 구조를 사용하며 데이터는 1시간 동안 유지됩니다. - 지연 시간을 최소화하기 위해 프론트엔드에서 낙관적(Optimistic)으로 ID를 생성하여 렌더링 즉시 워터마크를 적용합니다. ### 픽셀 단위의 RGB 인코딩 메커니즘 - 모든 위젯에 공통적으로 존재하는 1픽셀 두께의 테두리(Border)를 데이터 삽입 위치로 선정하여 시각적 일관성을 유지합니다. - 워터마크는 총 10개의 픽셀로 구성됩니다. 시작과 끝을 알리는 2개의 센티널(Sentinel) 픽셀과 그 사이의 8개 데이터 픽셀이 배치됩니다. - 각 데이터 픽셀은 1바이트(8비트)를 저장하며, RGB 채널에 비트를 분산(R: 3비트, G: 3비트, B: 2비트)하여 저장합니다. - 기본 색상에서 채널별로 아주 미세한 오프셋(최대 +7)만 조정하기 때문에 육안으로는 원본 테두리 색상과 구분이 불가능합니다. 이 기술은 대규모 트래픽 환경에서도 성능 저하 없이 정적 이미지에 생명력을 불어넣는 창의적인 엔지니어링 사례입니다. 협업 과정에서 스크린샷을 자주 활용하는 팀이라면, Datadog의 이러한 기능을 통해 이미지 너머의 원본 지표와 쿼리를 즉시 추적하여 문제 해결 속도를 높일 수 있습니다.

datadogredisincident-managementwatermarking+3

datadog2026년 4월 7일

자율형 SRE 에이전트를 위한 대규모 실세계 평가 플랫폼 구축 방법 (새 탭에서 열림)

Datadog이 Gartner의 2026년 Observability Platforms 매직 쿼드런트에서 Leader로 선정되었다는 소식을 전하는 글입니다. 글에 제공된 내용은 Datadog이 인프라·애플리케이션·로그·보안·디지털 경험·소프트웨어 제공·서비스 관리·AI를 아우르는 통합 플랫폼을 제공한다는 점을 강조합니다. 다만 Gartner의 평가 기준이나 Datadog의 구체적인 강점·약점에 대한 본문은 포함되어 있지 않습니다. ### Gartner 매직 쿼드런트 리더 선정 - Datadog은 Gartner® Magic Quadrant™ for Observability Platforms 2026에서 Leader로 소개되었습니다. - 이는 Datadog이 관측 가능성 플랫폼 시장에서 비전과 실행력을 모두 갖춘 업체로 평가되었음을 의미합니다. - 제공된 발췌문에는 평가 점수, 경쟁사 비교, 선정 근거 등 구체적인 Gartner 분석 내용은 없습니다. ### 통합 인프라 모니터링 - 호스트, 메트릭, 컨테이너, Kubernetes, 네트워크, 서버리스 환경을 모니터링합니다. - 클라우드 비용, 스토리지, GPU까지 관리 범위를 확장합니다. - Cloudcraft를 통해 클라우드 인프라를 시각적으로 구성하고 파악할 수 있습니다. ### 애플리케이션 성능 관측 - APM으로 애플리케이션 성능과 서비스 간 의존성을 분석합니다. - Universal Service Monitoring, Continuous Profiler, Dynamic Instrumentation을 제공합니다. - Agent Observability를 통해 AI 에이전트의 동작과 성능도 관찰할 수 있습니다. ### 로그·데이터·파이프라인 관리 - 로그 관리와 민감 데이터 탐지, 감사 추적 기능을 제공합니다. - Observability Pipelines로 로그와 관측 데이터를 수집·필터링·라우팅할 수 있습니다. - 데이터베이스, 데이터 스트림, 데이터 품질, 작업 실행 상태를 모니터링합니다. ### 보안과 관측성의 통합 - 코드 보안, SAST, IAST, 소프트웨어 구성 분석, IaC 보안을 지원합니다. - 클라우드 보안 상태, 권한, 취약점, 규정 준수를 관리합니다. - Cloud SIEM, 워크로드 보호, 애플리케이션·API 보호 기능도 포함합니다. - 관측 데이터와 보안 데이터를 한 플랫폼에서 연계해 위협 탐지와 대응을 지원하는 방향입니다. ### 디지털 경험과 소프트웨어 제공 - Browser·Mobile RUM으로 실제 사용자 경험을 측정합니다. - Session Replay, Synthetic Monitoring, 오류 추적, 제품 분석 기능을 제공합니다. - CI Visibility, 테스트 최적화, 지속적 테스트, 코드 커버리지로 배포 과정의 품질을 관리합니다. - 내부 개발자 포털, 기능 플래그, IDE 플러그인 등 개발자 생산성 기능도 제공합니다. ### 서비스 관리와 AI 기능 - 이벤트 관리, 서비스 카탈로그, SLO, 인시던트 대응, 워크플로 자동화를 지원합니다. - Watchdog과 Bits AI를 활용해 이상 징후 분석, 조사, 자동화된 대응을 수행할 수 있습니다. - AI 에이전트, AI 통합, MCP 서버, AI 기반 조사·보안 분석 기능을 제공하며 AI 운영 환경까지 관측 범위를 넓히고 있습니다. 제공된 내용만 보면 이 글의 핵심은 Datadog이 단순한 모니터링 도구가 아니라 인프라부터 보안, 개발, 사용자 경험, AI 운영까지 포괄하는 통합 관측성 플랫폼으로 자리매김했다는 점입니다. 실제 도입을 검토한다면 Gartner 평가 원문과 함께 데이터 보존 비용, 지원 환경, 기존 도구와의 연동성, 기능별 과금 구조를 별도로 확인하는 것이 좋습니다.

aik8sobservabilitylog-management+4

datadog2026년 4월 7일

대규모 자율형 SRE 에이전트를 위한 실환경 평가 플랫폼 구축 방법 (새 탭에서 열림)

Datadog은 자율형 사고 조사 에이전트인 'Bits AI SRE'를 개발하면서, 특정 기능을 개선했을 때 다른 영역에서 예상치 못한 성능 저하(Regression)가 발생하는 문제를 겪었습니다. 이를 해결하기 위해 실제 운영 환경의 사고 맥락을 재현하고 에이전트의 추론 과정을 일관되게 측정할 수 있는 '재현 가능한 평가 플랫폼'을 자체 구축했습니다. 이 플랫폼은 프로덕션 환경의 복잡한 신호를 오프라인에서 재실행 가능한 환경으로 변환함으로써, 에이전트의 품질을 데이터에 기반해 지속적으로 개선할 수 있게 해줍니다. **기존 테스트 방식의 한계와 회귀 문제** * 단순한 단위 테스트나 개별 도구(Tool) 레벨의 테스트는 에이전트가 여러 도구를 체이닝(Chaining)하며 추론하는 복합적인 과정을 검증하는 데 한계가 있었습니다. * 특정 모니터에서 서비스 이름을 추출하는 등의 기능 개선이 실제로는 불필요한 노이즈를 유발하여, 오히려 에이전트의 전체적인 추론 품질을 떨어뜨리는 사례가 발생했습니다. * 실시간 운영 환경에서의 재실행(Live Replay)은 데이터의 만료, 환경의 가변성, 결과 집계의 어려움으로 인해 대규모 평가에 적합하지 않았습니다. **재현 가능한 평가를 위한 '레이블'의 구조** * 플랫폼의 핵심인 '레이블'은 근본 원인을 정의하는 '정답(Ground Truth)'과 사고 당시의 신호를 담은 '월드 스냅샷(World-snapshot)'으로 구성됩니다. * 월드 스냅샷은 원시 데이터를 그대로 저장하는 대신 에이전트가 당시 사용할 수 있었던 텔레메트리 쿼리(지표, 로그, 배포 이벤트 등) 정보를 보존하여 실제 제약 사항을 재현합니다. * Kubernetes 파드 실패부터 Kafka 지연까지, 실제 SRE가 직면하는 다양한 장애 모드와 기술 스택을 포괄하는 광범위한 레이블 세트를 구축하여 평가의 객관성을 확보했습니다. **레이블 생성 및 검증의 자동화 (Agentic Validation)** * 초기 수동 레이블링의 한계를 극복하기 위해, 사용자의 피드백과 Bits AI의 자체 조사 데이터를 결합하여 레이블을 자동 생성하는 파이프라인을 구축했습니다. * 레이블의 양이 급증함에 따라 발생하는 품질 저하 문제를 해결하기 위해, 에이전트가 직접 모호한 신호를 정리하고 관계를 도출하는 '에이전트 기반 검증' 단계를 도입했습니다. * 이 시스템을 통해 레이블 생성 속도를 10배 이상 향상시켰으며, 사람이 최종 검토하기 전 데이터의 정밀도를 높여 평가 신뢰도를 강화했습니다. **대규모 평가 오케스트레이션과 성능 추적** * 다양한 모델 버전과 설정 변경 사항이 기존의 Kafka나 Kubernetes 조사 품질에 영향을 주지 않는지 확인하기 위해 대규모 병렬 평가 시스템을 운영합니다. * 레이블 세트를 세부 카테고리별로 분할(Segmentation)하여 관리함으로써, 어떤 변경이 특정 시나리오에 어떤 영향을 주는지 정밀하게 분석할 수 있습니다. * 모든 평가 결과는 지표화되어 시간에 따른 성능 추이를 추적하고, 버전 간 비교를 용이하게 하여 새로운 기능 배포에 대한 확신을 제공합니다. 복잡한 추론을 수행하는 AI 에이전트 개발 시, 단순히 개별 도구의 정확도에 의존하기보다 실제 운영 데이터의 '쿼리 가능성'과 '맥락'을 보존하는 오프라인 평가 환경을 구축하는 것이 필수적입니다. 이는 사용자 피드백을 제품 개선의 선순환으로 연결하는 핵심 인프라가 됩니다.

k8sdatadogkafkasre+3

datadog2026년 3월 23일

업서트가 업데이트되지 않아도 쓰기가 발생하는 경우: 대규모 Postgres 성능 디버깅 (새 탭에서 열림)

Datadog이 Gartner의 2026년 Observability Platforms 매직 쿼드런트에서 ‘Leader’로 선정되었다는 내용을 소개하는 페이지입니다. 제공된 본문에는 선정 근거와 평가 세부사항보다 Datadog의 제품군 및 관련 링크 목록이 대부분 포함되어 있습니다. 따라서 이 자료만으로는 Gartner의 구체적인 평가 기준이나 Datadog의 강점·약점을 자세히 분석하기 어렵습니다. ### Gartner 매직 쿼드런트 선정 - Datadog이 Gartner의 **Observability Platforms 부문 Leader**로 소개됩니다. - 연결된 리소스는 Datadog의 시장 평가 및 제품 포지셔닝을 강조하기 위한 홍보 자료로 보입니다. - 제공된 내용에는 Gartner의 평가 방법론, 경쟁사 비교, 실행 능력 및 비전 완성도에 대한 구체적인 설명은 없습니다. ### 인프라 모니터링 - 호스트, 메트릭, 컨테이너, 네트워크, 서버리스 환경을 모니터링합니다. - Kubernetes 오토스케일링, 클라우드 비용 관리, 스토리지 및 GPU 모니터링 기능을 제공합니다. - Cloudcraft를 통해 클라우드 인프라를 시각화할 수 있습니다. ### 애플리케이션 및 데이터 관측성 - APM, 서비스 모니터링, 연속 프로파일링, 동적 계측을 지원합니다. - 데이터베이스, 데이터 스트림, 데이터 품질, 작업 실행 상태를 관찰할 수 있습니다. - 애플리케이션 성능 문제와 데이터 파이프라인 문제를 하나의 플랫폼에서 분석하는 방향을 보여줍니다. ### 로그 및 보안 - 로그 관리, 민감 데이터 탐지, 감사 추적, 관측성 파이프라인 기능을 제공합니다. - 코드 보안, SAST·IAST, IaC 보안, 클라우드 보안, 취약점 관리, SIEM 등을 포함합니다. - 애플리케이션·API 보호와 워크로드 보호까지 보안 영역을 확장하고 있습니다. ### 디지털 경험 및 소프트웨어 전달 - 브라우저·모바일 RUM, 세션 리플레이, 합성 모니터링, 오류 추적을 지원합니다. - CI 가시성, 테스트 최적화, 지속적 테스트, 코드 커버리지, 기능 플래그 등을 제공합니다. - 사용자 경험부터 코드 변경과 배포 과정까지 관측 범위를 넓힌 것이 특징입니다. ### 서비스 관리와 AI - 이벤트 관리, SLO, 인시던트 대응, 워크플로 자동화, 서비스 카탈로그를 제공합니다. - Watchdog과 Bits 계열 AI 기능을 활용해 이상 탐지, 조사, 보안 분석, 자동화를 지원합니다. - MCP 서버, AI 에이전트, GPU 모니터링 등 AI 운영 환경을 위한 기능도 포함합니다. 실제로 Datadog 도입이나 경쟁 제품 비교에 활용하려면, 연결된 Gartner 리포트의 평가 기준과 한계, 비용 구조, 데이터 보존 정책, 기존 인프라와의 통합성을 별도로 확인해야 합니다.

k8sdatadogobservabilitypostgresql+2

datadog2026년 3월 23일

업서트가 업데이트하지 않아도 쓰기가 발생하는 경우: 대규모 Postgres 성능 디버깅 (새 탭에서 열림)

데이터독(Datadog)은 수백만 개의 일시적인 호스트 메타데이터를 효율적으로 관리하기 위해 새로운 업서트(Upsert) 쿼리를 도입했으나, 예상과 달리 디스크 쓰기와 WAL(Write-Ahead Logging) 동기화가 급증하는 문제에 직면했습니다. 조사 결과, PostgreSQL의 `ON CONFLICT DO UPDATE` 구문은 `WHERE` 조건에 의해 실제 업데이트가 수행되지 않더라도 행 잠금을 위해 WAL 레코드를 생성한다는 점이 원인이었습니다. 이 글은 고성능 시스템에서 단순한 쿼리 최적화 가정이 어떻게 물리적 성능 병목으로 이어질 수 있는지, 그리고 이를 어떻게 진단했는지 설명합니다. ### 효율적인 업서트 테이블 설계 * **업데이트 비용 절감:** PostgreSQL은 MVCC(MultiVersion Concurrency Control)를 사용하므로 업데이트 시마다 새로운 행 버전이 생성됩니다. 메타데이터 테이블의 비대화를 막기 위해 `last_ingested` 필드를 별도의 전용 테이블로 분리하여 쓰기 데이터양을 최소화했습니다. * **HOT(Heap-Only Tuples) 업데이트 활용:** 인덱스가 있는 컬럼을 수정하면 인덱스 페이지도 함께 수정되어야 합니다. 이를 피하기 위해 `last_ingested` 컬럼에는 인덱스를 생성하지 않았으며, `fillfactor`를 80%로 설정하여 페이지 내 여유 공간을 확보함으로써 HOT 업데이트가 가능하도록 설계했습니다. * **업데이트 빈도 제한:** 7일간 데이터가 없는 호스트를 식별하는 것이 목적이므로 1일 단위의 정밀도로 충분했습니다. 따라서 `WHERE` 절을 사용하여 마지막 업데이트로부터 24시간이 지난 경우에만 실제 쓰기가 발생하도록 쿼리를 구성했습니다. ### 예상치 못한 성능 지표의 변화 * **I/O 및 WAL 동기화 급증:** 쿼리 배포 후 업데이트 속도는 예상대로 낮게 유지되었으나, 디스크 쓰기 IOPS는 2배, WAL sync 횟수는 4배나 증가했습니다. * **쓰기 예산 소모:** PostgreSQL 클러스터는 단일 라이터(writer) 구조이므로 처리 가능한 쓰기 작업량에 한계가 있습니다. 실제 데이터 변경이 없는 'No-op' 쿼리들이 이 한정된 자원을 과도하게 소모하는 문제가 발생했습니다. * **내부 동작의 모순:** `INSERT ... ON CONFLICT DO UPDATE` 문에서 `WHERE` 조건이 거짓(false)이 되어 행이 업데이트되지 않더라도, 데이터베이스는 동시성 제어를 위해 해당 행에 락(lock)을 겁니다. 이 잠금 행위 자체가 WAL에 기록되면서 물리적인 쓰기 부하를 유발한 것입니다. ### pg_walinspect를 이용한 심층 진단 * **WAL 레코드 조사:** Postgres 15에서 도입된 `pg_walinspect` 확장 프로그램을 사용하여 실제 WAL에 어떤 데이터가 기록되고 있는지 분석했습니다. * **진단 도구 설정:** `pg_get_wal_records_info` 함수를 호출하여 특정 LSN(Log Sequence Number) 범위 내의 레코드를 확인했습니다. 이를 통해 쿼리 실행 시 업데이트가 발생하지 않음에도 불구하고 WAL 레코드가 생성되는 과정을 구체적으로 확인했습니다. * **원인 규명:** 분석 결과, `ON CONFLICT` 상황에서 잠금 처리가 WAL에 기록되는 것을 확인했으며, 이것이 전체적인 디스크 I/O 상승의 주범임을 입증했습니다. ### 실용적인 제언 PostgreSQL에서 고빈도 업서트를 설계할 때는 `WHERE` 조건문이 애플리케이션 레벨의 논리적 업데이트는 막아줄 수 있지만, 데이터베이스 엔진 레벨의 물리적 쓰기(WAL)까지 완전히 차단하지 못할 수 있음을 유의해야 합니다. 극도로 높은 처리량이 요구되는 환경에서는 `pg_walinspect`와 같은 도구를 사용하여 쿼리의 물리적 오버헤드를 사전에 검증하고, 불필요한 잠금 발생을 줄이는 방향으로 쿼리를 재작성하는 과정이 필수적입니다.

database-designpostgresqlupsertwal+4

datadog2026년 3월 9일

AI 에이전트가 문을 두드렸을 때: 데이터독 오픈 소스 저장소의 악성 기여 탐지 (새 탭에서 열림)

Datadog이 Gartner의 2026년 Observability Platforms 매직 쿼드런트에서 ‘Leader’로 선정되었다는 소식과 제품 포트폴리오를 소개하는 내용입니다. 제공된 본문에는 상세한 평가 기준이나 선정 이유, 기술적 분석보다 Datadog의 제품 메뉴와 기능 목록이 대부분 포함되어 있습니다. ### Gartner 매직 쿼드런트 리더 선정 - Datadog은 Gartner® Magic Quadrant™ for Observability Platforms 2026에서 리더로 소개되었습니다. - 다만 제공된 내용에는 Gartner의 구체적인 평가 점수, 경쟁사 비교, 선정 근거는 포함되어 있지 않습니다. - 따라서 리더 선정이 제품 완성도, 실행력, 비전 중 어떤 요소에 기반했는지는 확인할 수 없습니다. ### 인프라 및 애플리케이션 모니터링 - 인프라 모니터링, 메트릭, 컨테이너 및 Kubernetes 모니터링을 제공합니다. - 네트워크, 서버리스, 클라우드 비용, 스토리지, GPU 모니터링까지 지원합니다. - 애플리케이션 성능 모니터링(APM), 서비스 모니터링, 코드 프로파일링, 동적 계측 기능도 포함됩니다. - 데이터베이스와 데이터 스트림 모니터링을 통해 애플리케이션 외부의 데이터 처리 상태도 관찰할 수 있습니다. ### 로그 및 데이터 관측성 - 로그 관리와 Observability Pipelines를 통해 로그 수집·처리·전송을 관리합니다. - Sensitive Data Scanner로 로그와 데이터에 포함된 민감정보를 탐지할 수 있습니다. - 데이터 품질 모니터링과 작업(Job) 모니터링을 통해 데이터 파이프라인의 오류와 품질 문제를 추적합니다. - Audit Trail은 플랫폼 내 활동과 변경 사항을 기록하는 기능으로 제시됩니다. ### 보안 통합 - 코드 보안, SAST, IAST, 소프트웨어 구성 분석(SCA), IaC 보안을 제공합니다. - 클라우드 보안 상태 관리(CSPM), 권한 관리(CIEM), 취약점 관리, 컴플라이언스 기능을 포함합니다. - Cloud SIEM, 워크로드 보호, 애플리케이션·API 보호 등 런타임 보안 영역도 지원합니다. - Datadog Security Labs와 오픈소스 프로젝트를 통해 보안 연구 및 생태계 활동도 강조합니다. ### 사용자 경험과 소프트웨어 전달 - Browser·Mobile RUM, 세션 리플레이, 신서틱 모니터링으로 실제 사용자 경험을 분석합니다. - 오류 추적, 제품 분석, 실험 기능을 통해 사용자 행동과 애플리케이션 품질을 함께 관찰할 수 있습니다. - CI Visibility, 테스트 최적화, 지속적 테스트, 코드 커버리지로 개발·배포 과정까지 모니터링합니다. - 기능 플래그와 내부 개발자 포털도 소프트웨어 전달 영역에 포함됩니다. ### 서비스 관리와 AI - 이벤트 관리, 서비스 카탈로그, SLO, 인시던트 대응, 워크플로 자동화 기능을 제공합니다. - Watchdog과 Bits AI Agents, Bits Investigation 등 AI 기반 분석·조사 기능을 내세웁니다. - AI 에이전트 관측성, GPU 모니터링, MCP Server 등 AI 시스템 운영을 위한 기능도 포함됩니다. - 대시보드, 알림, 접근 제어, 거버넌스 콘솔 등 플랫폼 운영 기능도 제공됩니다. 실제 글의 상세 주장이나 기술적 결론을 정확히 요약하려면 기사 본문이 추가로 필요합니다. 현재 제공된 내용만으로는 Datadog이 관측성·보안·개발·AI 운영을 하나의 플랫폼으로 통합하고 있다는 점이 핵심입니다.

k8sdatadogobservabilitylog-management+2

datadog2026년 3월 9일

AI 에이전트가 문을 두드리자: Datadog 오픈 소스 저장소의 악성 기여를 포착하다 (새 탭에서 열림)

데이터독(Datadog)은 최근 GitHub Actions 및 LLM 기반 워크플로우를 표적으로 삼는 AI 에이전트 'hackerbot-claw'의 악성 기여 시도를 성공적으로 차단했습니다. 이 공격은 AI 기술을 활용해 오픈소스 리포지토리에 취약점을 주입하려는 시도였으나, 데이터독의 AI 기반 탐지 시스템인 'BewAIre'와 선제적인 CI/CD 보안 제어 덕분에 무력화되었습니다. 이번 사례는 공격자들이 LLM을 통해 공격 규모를 확장함에 따라, 방어자 또한 AI를 보안 체계에 적극적으로 도입해야 함을 시사합니다. **오픈소스 CI 파이프라인을 향한 주요 공격 벡터** - **변수 삽입 취약점:** PR 제목과 같이 사용자가 제어할 수 있는 변수를 워크플로우 스크립트 내에 안전하지 않게 삽입하는 경우를 악용합니다. - **I-PPE(간접 포이즌 파이프라인 실행):** 악성 의존성이나 빌드 지침을 PR에 삽입하여 빌드 과정에서 자동으로 실행되게 함으로써 CI 비밀번호(Secrets)를 탈취합니다. - **`pull_request_target` 오용:** 신뢰할 수 없는 PR에서 실행되는 워크플로우에 높은 권한을 부여하는 설정을 악용하여 시스템을 장악합니다. - **LLM 프롬프트 인젝션:** `claude-code-action`이나 `run-gemini-cli`처럼 LLM을 사용하는 GitHub 액션에 악의적인 지시를 주입하여 자동화된 트리징 시스템을 교란합니다. **AI 기반 탐지 시스템 'BewAIre'의 운영** - **실시간 코드 리뷰:** 매주 유입되는 약 10,000건의 내외부 PR을 대상으로 LLM 기반의 자동화된 보안 검사를 수행합니다. - **2단계 분석 파이프라인:** GitHub 이벤트를 통해 코드 차분(diff) 데이터를 추출 및 정규화한 뒤, 2단계 LLM 파이프라인을 거쳐 변경 사항을 '악성' 또는 '정상'으로 분류하고 그 근거를 구조화하여 제시합니다. - **SIEM 통합 및 대응:** 악성으로 판정된 결과는 즉시 Datadog Cloud SIEM으로 전송되어 보안 사고 대응 팀(SIRT)이 즉각적으로 조사하고 사고화할 수 있도록 지원합니다. **선제적인 인프라 강화 및 보안 모범 사례** - **최소 권한의 임시 자격 증명:** OIDC identity federation을 활용한 `dd-octo-sts-action`을 도입하여, 수명이 길고 권한이 과도한 개인 액세스 토큰(PAT) 대신 수명이 짧고 권한이 제한된 인증 정보를 동적으로 생성합니다. - **비밀 정보 관리:** 수천 개의 리포지토리를 전수 조사하여 사용되지 않는 GitHub Actions 비밀 정보를 대규모로 식별하고 제거했습니다. - **CI 보안 정책 강제화:** 브랜치 보호 규칙, 휴먼 및 봇의 커밋 서명 의무화, 필수 PR 승인 절차를 도입하고 `GITHUB_TOKEN` 권한을 기본적으로 최소 수준으로 설정했습니다. - **보안 골든 패스(Golden Paths):** 엔지니어들이 별도의 복잡한 설정 없이도 보안이 확보된 표준 CI 파이프라인을 사용할 수 있도록 가이드를 문서화하고 시스템화했습니다. AI 에이전트를 활용한 공격이 현실화됨에 따라 단순한 규칙 기반의 탐지는 한계에 직면해 있습니다. 조직은 BewAIre와 같은 AI 기반 탐지 모델을 구축함과 동시에, OIDC를 통한 인증 체계 개선 및 GITHUB_TOKEN 권한 최소화와 같은 근본적인 CI/CD 보안 설정을 병행하여 자동화된 공격에 대한 방어 계층을 다각화해야 합니다.

database-designllmci-cdopen-source+4

datadog2026년 3월 4일

에이전트를 위한 MCP 도구 설계: Datadog의 MCP 서버 구축을 통해 배운 교훈 (새 탭에서 열림)

AI 에이전트를 위한 관측성(Observability) 인터페이스 구축 시, 단순히 기존 API를 그대로 노출하는 방식은 컨텍스트 창의 한계와 비용 문제로 인해 한계가 명확합니다. Datadog은 MCP(Model Context Protocol) 서버를 구축하며 데이터 포맷 최적화, SQL 기반 쿼리 도입, 도구의 효율적 관리라는 세 가지 핵심 설계를 통해 에이전트의 작업 효율을 극대화했습니다. 결과적으로 이러한 설계 변경은 에이전트의 추론 정확도를 높이는 동시에 토큰 사용량을 줄여 운영 비용을 절감하는 효과를 가져왔습니다. ### 컨텍스트 창 효율성 극대화 * **데이터 포맷 최적화**: JSON은 프로그래밍 방식에는 적합하지만 토큰 소모가 큽니다. 평면적인 데이터에는 CSV(토큰 약 50% 절감)를, 계층 구조가 있는 데이터에는 YAML(약 20% 절감)을 사용하여 동일한 컨텍스트 내에 더 많은 정보를 담았습니다. * **필드 트리밍**: 에이전트에게 불필요한 필드를 기본 출력에서 제거하고 필요한 경우에만 요청하게 함으로써, 동일한 토큰 예산 내에서 레코드 수용량을 최대 5배까지 늘렸습니다. * **토큰 기반 페이지네이션**: 레코드 개수 단위로 데이터를 끊어 보내는 전통적인 방식 대신, 실제 소비되는 토큰량을 기준으로 응답을 제한하여 에이전트의 컨텍스트 창이 예기치 않게 가득 차는 문제를 방지했습니다. ### 단순 조회를 넘어선 SQL 기반 쿼리 도입 * **서버 측 집계**: 에이전트가 수천 개의 로그를 직접 내려받아 트렌드를 분석하는 대신, 서버에서 SQL을 실행하여 요약된 결과만 받도록 개선했습니다. * **비용 및 성능 개선**: SQL을 통해 꼭 필요한 필드만 선택(SELECT)하고 행을 제한(LIMIT)함으로써, 평가 시나리오에서 실행 비용을 약 40% 절감하고 정답률을 높였습니다. * **에이전트 적응력**: AI 에이전트는 SQL 작성에 매우 능숙하며, 이를 통해 컨텍스트 윈도우에 들어갈 데이터를 스스로 세밀하게 제어할 수 있게 되었습니다. ### 도구 비대화 방지 및 관리 전략 * **유연한 도구 설계**: 개별 API 엔드포인트마다 도구를 만드는 대신, 하나의 도구가 여러 유즈케이스를 처리할 수 있도록 스키마를 범용적으로 설계하여 도구의 총 개수를 줄였습니다. * **도구 세트(Toolsets) 분리**: 모든 도구를 한꺼번에 노출하지 않고, 핵심 도구와 특정 워크플로우를 위한 선택적 도구 세트를 구분하여 에이전트의 혼란을 방지하고 컨텍스트 소모를 최소화했습니다. * **도구 계층화**: "어떻게 작업을 수행할지"를 묻는 도구와 실제 동작 도구를 분리하여 검색 효율을 높였습니다. 다만, 이 방식은 레이턴시 증가라는 기회비용이 발생하므로 신중한 적용이 필요합니다. AI 에이전트를 위한 도구를 설계할 때는 인간 사용자를 위한 API 설계와는 다른 접근이 필요합니다. 에이전트가 데이터를 직접 처리하게 두기보다, 서버 측에서 데이터를 가공하고 요약할 수 있는 강력한 쿼리 기능을 제공하고 전송 포맷을 최적화하는 것이 성능과 비용 측면에서 모두 유리합니다.

database-designdatadogobservabilityapi-design+4