쿠버네티스

144 개의 포스트

datadog원문

대규모 자율형 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 에이전트 개발 시, 단순히 개별 도구의 정확도에 의존하기보다 실제 운영 데이터의 '쿼리 가능성'과 '맥락'을 보존하는 오프라인 평가 환경을 구축하는 것이 필수적입니다. 이는 사용자 피드백을 제품 개선의 선순환으로 연결하는 핵심 인프라가 됩니다.

line원문

Hive에서 Iceberg로: 데이터 반영 속도 12배 향상의 비밀 (새 탭에서 열림)

LINE Plus는 수억 건에 달하는 상품 데이터를 처리하기 위해 기존에 사용하던 전체 데이터 복제(Full Dump) 방식의 ETL 구조를 탈피하고, Apache Iceberg와 Apache Flink를 결합한 증분(Incremental) 처리 구조를 도입했습니다. 이를 통해 데이터 규모가 커질수록 기하급수적으로 늘어나던 업데이트 비용과 시간을 대폭 절감하였으며, 결과적으로 데이터 반영 주기를 60분에서 5분으로 단축하여 약 12배의 성능 향상을 이루어냈습니다. 이 글은 대규모 데이터 환경에서 실시간성에 가까운 데이터 최신성을 확보하기 위한 기술적 여정과 엔진 선택의 근거를 상세히 다룹니다. **기존 전체 데이터 복제 방식의 한계** * **리소스 낭비와 지연:** 매번 수억 건의 전체 데이터를 다시 써야 하는 구조로 인해 데이터 규모가 커질수록 처리 비용이 증가하고, 사내 Hadoop 리소스 부족 시 업데이트 주기가 지연되는 문제가 발생했습니다. * **데이터 최신성 결여:** 스냅숏 기반의 추출 방식은 정합성은 보장하지만, 추출 작업에 걸리는 시간만큼 데이터가 과거 시점에 머물게 되어 라이브 서비스에서의 실시간 대응이 어려웠습니다. * **운영 DB 부하:** 대용량 데이터를 한꺼번에 추출할 때 발생하는 막대한 디스크 I/O와 Undo 세그먼트 팽창은 운영 환경의 성능 저하를 유발하는 고질적인 원인이 되었습니다. **Apache Iceberg를 통한 증분 처리 기반 마련** * **테이블 형식의 변화:** 기존 Hive의 디렉터리 기반 관리 방식에서 벗어나, 메타데이터를 이용해 스냅숏 단위로 파일을 추적하는 Iceberg 형식을 도입했습니다. * **행 단위 업데이트 지원:** 전체 데이터를 다시 쓸 필요 없이 변경된 행(row)만 선택적으로 업데이트(upsert)하거나 삭제(delete)할 수 있어, 데이터 규모와 상관없이 일정한 업데이트 비용을 유지할 수 있게 되었습니다. **Apache Flink 선택의 결정적 이유** * **스테이트풀(Stateful) 처리를 통한 최신성 보장:** Flink의 DataStream API를 활용해 `updatedate`를 상태값으로 관리함으로써, 컨슈머 랙 등으로 인해 뒤늦게 도착한 과거 데이터가 최신 데이터를 덮어쓰는 문제를 원천 차단했습니다. * **2단계 커밋(2PC) 기반의 정확히 한 번 처리:** Iceberg 테이블 쓰기와 Kafka 상태 메시지 발행을 하나의 트랜잭션으로 묶어, 데이터 누락이나 중복 없이 '전부 아니면 전무(All-or-Nothing)'의 정합성을 보장했습니다. * **강력한 장애 허용(Fault Tolerance):** 체크포인트 메커니즘을 통해 시스템 장애 발생 시에도 마지막 성공 지점부터 즉시 복구가 가능하며, 관리하던 상태값을 유실 없이 유지할 수 있습니다. **효율적인 운영을 위한 쿠버네티스 오퍼레이터 도입** * **운영 자동화:** 설정 작업을 수동으로 진행해야 하는 네이티브 쿠버네티스 방식 대신, Flink 쿠버네티스 오퍼레이터를 도입하여 라우팅, 웹 UI 구성 등 운영 요소를 커스텀 리소스로 추상화하고 관리를 자동화했습니다. * **격리 및 확장성:** 애플리케이션 모드를 통해 잡(job)별 클러스터 격리 수준을 높이고, 헬름(Helm) 차트를 이용해 손쉽게 배포 및 확장할 수 있는 환경을 구축했습니다. 대규모 데이터셋에서 실시간에 가까운 데이터 동기화와 엄격한 정합성이 모두 필요하다면, 단순한 배치 처리보다는 Flink와 Iceberg의 조합을 통한 증분 파이프라인 구축을 권장합니다. 특히 Flink의 2단계 커밋과 체크포인트 기능을 활용하면 분산 환경에서도 데이터 무결성을 보장하면서 시스템의 업데이트 주기를 획기적으로 단축할 수 있습니다.

line원문

LINE 서비스의 대규모 광고 데이터를 처리하기 위한 Spark on Kubernetes 적용기 (새 탭에서 열림)

LINE 광고 플랫폼(LINE Ads) 팀은 급격히 증가하는 광고 데이터와 연산량을 효율적으로 처리하기 위해 기존 Hadoop 기반의 YARN 환경을 Spark on Kubernetes로 전환했습니다. 기존 구조의 자원 경합 및 인프라 종속성 문제를 해결함으로써, 컴퓨팅과 스토리지를 분리하고 컨테이너 기반의 유연한 운영 환경을 구축하는 데 성공했습니다. 이를 통해 데이터 파이프라인의 확장성을 확보하고 최신 기술 스택을 자유롭게 활용할 수 있는 인프라 독립성을 달성했습니다. **기존 Spark on YARN의 구조적 한계** * **자원 경합 발생:** HDFS 스토리지와 컴퓨팅 자원이 단일 노드에 결합된 구조여서, 대규모 연산 시 HDFS 서비스와 Spark 작업 간의 리소스 간섭이 발생했습니다. * **확장의 비효율성:** 컴퓨팅 자원만 필요한 상황에서도 Hadoop 노드 전체를 증설해야 하므로 운영 비용과 스토리지 낭비가 초래되었습니다. * **환경 종속성:** Hadoop 클러스터의 설정에 묶여 있어 최신 Spark 버전이나 특정 라이브러리, JVM 환경을 자유롭게 변경하기 어려웠습니다. **Spark on Kubernetes의 작동 원리와 장점** * **파드 기반 실행:** Spark 드라이버와 익스큐터를 독립적인 Kubernetes 파드로 실행하며, Kubernetes가 클러스터 매니저 역할을 수행하여 리소스를 할당합니다. * **클러스터 모드 채택:** `spark-submit`을 통해 드라이버 파드를 먼저 생성하고, 드라이버가 직접 익스큐터 파드를 요청 및 관리하는 방식을 통해 운영 권한을 Kubernetes에 위임했습니다. * **완전한 컨테이너화:** 모든 의존성을 Docker 이미지에 포함하여 환경 재현성을 높였으며, CI/CD 파이프라인과의 연동이 쉬워졌습니다. **인프라 독립성 및 운영 효율성 확보** * **스토리지 자유도:** HDFS에 국한되지 않고 S3, GCS 등 다양한 클라우드 네이티브 스토리지를 자유롭게 선택할 수 있는 기반을 마련했습니다. * **오토 스케일링 용이:** 클러스터 오토스케일러를 통해 워크로드에 따라 유연하게 자원을 확장할 수 있으며, 온프레미스 제약에서 벗어났습니다. * **거버넌스 강화:** 네임스페이스와 리소스 쿼터(ResourceQuota)를 활용해 팀별로 자원을 격리하고, RBAC 기반의 세밀한 권한 제어가 가능해졌습니다. **통합 데이터 플랫폼을 위한 레이어 구성** * **배포 레이어:** GitHub Actions와 ArgoCD를 결합하여 코드 기반의 자동 배포 및 실시간 상태 모니터링, 손쉬운 롤백 체계를 구축했습니다. * **컴퓨팅 레이어:** Spark Operator를 도입해 Kubernetes 커스텀 리소스(CRD)로 앱을 관리하며, Apache YuniKorn을 통해 배치 잡 스케줄링을 최적화했습니다. * **관측성 및 로깅:** 파드의 로그를 OpenSearch에 실시간 적재하고, Prometheus 지표를 통해 Spark 애플리케이션의 성능을 정밀하게 모니터링합니다. 대규모 데이터 처리가 필요한 환경에서 인프라 유연성과 운영 자동화를 동시에 달성하고자 한다면 Spark on Kubernetes 도입을 적극 권장합니다. 특히 컴퓨팅과 스토리지를 분리하여 비용을 최적화하고, 다양한 워크로드를 하나의 클러스터에서 통합 운영하려는 조직에 매우 효과적인 솔루션이 될 것입니다.

cloudflare원문

연간 600시간을 절약한 쿠버네티스 한 줄 수정 (새 탭에서 열림)

쿠버네티스 환경에서 테라폼(Terraform) 운영 도구인 아틀란티스(Atlantis)의 재시작 시간을 30분에서 수 초 내외로 단축하여, 연간 600시간의 엔지니어링 대기 시간을 줄인 사례를 소개합니다. 문제의 원인은 수백만 개의 파일을 포함한 퍼시스턴트 볼륨(PV)을 마운트할 때 쿠버네티스가 기본적으로 수행하는 파일 권한 변경 작업이었습니다. 이를 해결하기 위해 `securityContext`에 단 한 줄의 설정을 추가함으로써 불필요한 재귀적 권한 검사를 방지하고 시스템 효율성을 극대화했습니다. ### 원인 불명의 느린 재시작 문제 아틀란티스는 테라폼 프로젝트의 상태를 유지하기 위해 퍼시스턴트 볼륨(PV)을 사용하는 싱글톤 스테이트풀셋(StatefulSet)으로 운영됩니다. 자격 증명 갱신이나 프로젝트 온보딩 시 재시작이 필수적인데, 이때마다 다음과 같은 심각한 지연이 발생했습니다. * **지속적인 지연:** 매 재시작 시 30분 동안 포드가 `Init:0/1` 상태에 머물며 인프라 변경 작업이 완전히 중단됨. * **운영 부담:** 매달 약 100회의 재시작이 발생하여 월 50시간, 연간 600시간의 엔지니어링 시간이 낭비되고 온콜 엔지니어에게 불필요한 알람이 전송됨. * **한계 도달:** 파일 시스템의 아이노드(Inode) 고갈로 볼륨 크기를 키워야 하는 상황에서, 재시작 지연 문제는 더욱 두드러짐. ### Kubelet 로그를 통한 기술적 병목 파악 일반적인 `kubectl events`로는 포드가 이미지를 풀링하기 전 단계에서 왜 멈춰 있는지 알 수 없었습니다. 팀은 노드 레벨의 `kubelet` 로그를 분석하여 구체적인 원인을 찾아냈습니다. * **로그 추적:** 로그상에서 볼륨 마운트 성공 메시지 이후 `context deadline exceeded` 오류가 반복적으로 발생하며 포드 생성이 지연됨을 확인. * **fsGroup 권한 설정:** 쿠버네티스는 볼륨을 마운트할 때 포드의 `fsGroup` 설정과 일치시키기 위해 볼륨 내의 모든 파일과 디렉토리에 대해 재귀적으로 `chown` 및 `chmod`를 실행함. * **파일 개수의 영향:** 아틀란티스 볼륨에 쌓인 수백만 개의 파일에 대해 매번 이 작업을 수행하면서 30분이라는 막대한 시간이 소요됨. ### 단 한 줄의 설정 변경으로 문제 해결 쿠버네티스 1.20 버전(GA 기준)부터 도입된 `fsGroupChangePolicy` 설정을 통해 이 문제를 간단히 해결할 수 있었습니다. * **기본값(Always):** 포드가 시작될 때마다 항상 모든 파일의 권한을 재귀적으로 변경함. * **해결책(OnRootMismatch):** 볼륨 루트 디렉토리의 권한이 `fsGroup`과 일치하지 않을 때만 재귀적 변경을 수행함. 이미 권한이 올바르게 설정되어 있다면 이 과정을 건너뜀. * **적용 코드:** ```yaml securityContext: fsGroup: 1000 fsGroupChangePolicy: "OnRootMismatch" ``` ### 실용적인 권장 사항 수백만 개의 작은 파일이 포함된 대규모 볼륨을 사용하는 애플리케이션(예: Prometheus, Atlantis, Jenkins 등)을 쿠버네티스에서 운영 중이라면, `fsGroupChangePolicy: "OnRootMismatch"` 설정을 기본적으로 적용하는 것이 좋습니다. 이를 통해 볼륨 마운트 시 발생하는 불필요한 디스크 I/O를 제거하고, 포드 시작 시간을 획기적으로 개선하여 인프라 운영의 가용성을 높일 수 있습니다.

aws원문

AWS 주간 소식: Amazon Bedrock의 NVIDIA Nemotron 3 Super, Nova Forge SDK, Amazon Corretto 26 등(2026년 3월 23일) | Amazon Web Services (새 탭에서 열림)

AWS는 최근 NVIDIA Nemotron 3 Super 모델의 Amazon Bedrock 추가와 Nova Forge SDK 출시를 통해 생성형 AI 생태계를 대폭 확장하고, 엔터프라이즈급 AI 맞춤화 기능을 강화했습니다. 동시에 Amazon Redshift의 쿼리 성능을 최대 7배 향상시키고 Amazon EKS의 가용성 실효 수준(SLA)을 99.99%로 높이는 등 클라우드 인프라의 성능과 신뢰성 측면에서도 유의미한 진전을 이루었습니다. 이번 업데이트는 개발자 중심의 도구 개선과 고성능 워크로드 지원이라는 AWS의 핵심 전략을 잘 보여줍니다. **생성형 AI 모델 및 맞춤화 도구 확장** * **NVIDIA Nemotron 3 Super 출시:** Amazon Bedrock API를 통해 NVIDIA의 고성능 언어 모델인 Nemotron 3 Super를 사용할 수 있게 되었습니다. 텍스트 생성, 복잡한 추론, 요약, 코드 생성에 최적화되어 있으며 별도의 인프라 관리 없이 기존 워크플로우에 통합 가능합니다. * **Nova Forge SDK 도입:** 기업용 Nova 모델을 도메인 특화 데이터에 맞게 미세 조정(Fine-tuning)하고 배포할 수 있는 간소화된 수단을 제공하여 맞춤형 AI 솔루션 구축의 복잡성을 낮췄습니다. * **에이전트 정확도 향상:** Strands 에이전트 팀이 발표한 'Steering Hooks' 기법을 통해 AI 에이전트의 정확도를 100%까지 달성했으며, 이는 기존 프롬프트 엔지니어링보다 뛰어난 제어 능력을 보여줍니다. **데이터 분석 및 컴퓨팅 인프라 성능 고도화** * **Amazon Redshift 성능 개선:** 대시보드 및 ETL 워크로드에서 캐시되지 않은 새로운 쿼리의 실행 속도가 최대 7배 빨라졌습니다. 이는 쿼리 변동성이 큰 대화형 대시보드의 대기 시간을 획기적으로 줄여줍니다. * **Amazon EKS SLA 및 확장성 강화:** 프로비저닝된 컨트롤 플레인 클러스터의 SLA가 99.99%로 상향되었으며, 4XL 대비 처리 용량이 2배인 8XL 스케일링 티어를 도입하여 대규모 AI/ML 학습 및 데이터 처리 환경을 지원합니다. * **AWS Lambda 가용 영역(AZ) 메타데이터 지원:** 함수 호출 시 실행 중인 AZ 정보를 확인할 수 있게 되어, 지연 시간에 민감한 멀티 AZ 워크로드의 관찰 가능성과 문제 해결 능력이 향상되었습니다. **개발자 편의성 및 운영 효율성 증대** * **Amazon Corretto 26 정식 출시:** OpenJDK의 최신 장기 지원(LTS) 버전인 Corretto 26이 출시되어 최신 Java 기능과 보안 패치를 다양한 운영체제에서 무료로 사용할 수 있습니다. * **CloudWatch Logs HTTP 기반 로그 수집:** 커스텀 에이전트나 SDK 없이 표준 HTTP 엔드포인트를 통해 로그를 직접 전송할 수 있게 되어 중앙 집중식 로그 관리 장벽이 낮아졌습니다. * **학생용 Kiro 지원:** 미래의 개발자들이 AI 기반 개발 도구를 무료로 경험할 수 있도록 Kiro 서비스를 학생들에게 개방했습니다. 이번 업데이트를 통해 엔터프라이즈 환경에서는 Nova Forge SDK를 활용한 도메인 특화 AI 모델 구축을 검토해 볼 가치가 있으며, 고가용성이 필요한 대규모 워크로드 운영 시 강화된 EKS 8XL 티어와 99.99% SLA를 적극 활용하는 것을 추천합니다. 또한 2026년 4월부터 시작되는 파리, 런던 등 전 세계 AWS 서밋 일정을 확인하여 최신 기술 트렌드를 직접 확인하시기 바랍니다.

datadog2분 읽기큐레이션 요약

업서트가 업데이트되지 않아도 쓰기가 발생하는 경우: 대규모 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 리포트의 평가 기준과 한계, 비용 구조, 데이터 보존 정책, 기존 인프라와의 통합성을 별도로 확인해야 합니다.

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

에이전트에 힘을 더하다: Workers AI, 이제 Kimi K2.5를 시작으로 대규모 모델 실행 지원 (새 탭에서 열림)

Cloudflare는 자사의 AI 추론 플랫폼인 Workers AI에서 Moonshot AI의 **Kimi K2.5**를 시작으로 대규모 프런티어 모델 지원을 공식화했습니다. 이를 통해 개발자는 Durable Objects, Workflows 등 기존의 강력한 인프라와 고성능 LLM을 결합하여 에이전트의 전체 라이프사이클을 단일 플랫폼에서 관리할 수 있게 되었습니다. 특히 대형 모델의 추론 비용을 획기적으로 낮추고 성능을 최적화함으로써, 복잡한 추론 기능이 필요한 지능형 에이전트 구축의 진입 장벽을 제거했다는 점이 핵심입니다. ### Kimi K2.5 도입과 경제적 효용성 * **성능 사양:** 256k의 방대한 컨텍스트 윈도우를 지원하며, 멀티턴 도구 호출(Tool Calling), 비전 입력, 구조화된 출력 기능에 특화되어 복잡한 에이전트 작업에 적합합니다. * **비용 절감:** Cloudflare 내부의 보안 리뷰 에이전트에 적용한 결과, 기존 유료 독점 모델 대비 성능 저하 없이 비용을 약 77% 절감하는 효과를 거두었습니다. * **확장성:** 개인용 에이전트나 코딩 에이전트의 사용량이 급증하는 추세에서, 독점 모델의 높은 비용 문제를 해결하고 엔터프라이즈급 추론 능력을 경제적으로 제공합니다. ### 대규모 모델 추론 스택의 기술적 최적화 * **커스텀 커널 및 엔진:** 자체 추론 엔진인 'Infire'를 기반으로 Kimi K2.5에 최적화된 커스텀 커널을 적용하여 GPU 활용도와 처리 속도를 극대화했습니다. * **병렬화 및 분산 처리:** 데이터, 텐서, 전문가(Expert) 병렬화 기술뿐만 아니라, 프리필(Prefill)과 생성(Generation) 단계를 분리하는 '분산 프리필' 전략을 통해 높은 처리량을 확보했습니다. * **서버리스 편의성:** ML 엔지니어나 DevOps 전문가 없이도 API 호출만으로 이러한 고차원적인 최적화 기술이 적용된 대형 모델을 즉시 사용할 수 있습니다. ### 에이전트 워크로드를 위한 플랫폼 개선 * **프리픽스 캐싱(Prefix Caching):** 대화 맥락이나 시스템 프롬프트 등 중복되는 입력 텐서를 캐싱하여 프리필 단계의 계산을 생략함으로써, 첫 토큰 생성 시간(TTFT)을 단축하고 처리량을 높였습니다. * **세션 어피니티(Session Affinity) 헤더:** `x-session-affinity` 헤더를 도입하여 요청을 동일한 모델 인스턴스로 라우팅함으로써 캐시 히트율을 높이고 추론 비용을 추가로 절감할 수 있도록 지원합니다. * **캐시 토큰 할인:** 캐싱된 토큰 사용량을 명확히 시각화하여 제공하며, 일반 입력 토큰보다 저렴한 가격 정책을 적용하여 대규모 컨텍스트를 사용하는 에이전트의 비용 부담을 줄였습니다. 고성능 추론 능력이 필요한 복잡한 AI 에이전트를 구축하고자 한다면, Cloudflare Workers AI 플랫폼에서 Kimi K2.5와 세션 어피니티 기능을 활용해 보시기 바랍니다. 인프라 구축의 복잡성을 Cloudflare에 맡김으로써 개발자는 에이전트의 논리와 비즈니스 가치 창출에만 집중할 수 있습니다.

aws원문

AWS 클라우드와 함께한 20년 – 시간이 정말 빠르네요! | Amazon Web Services (새 탭에서 열림)

AWS는 지난 20년 동안 240개 이상의 클라우드 서비스를 구축하며 기술 혁신의 표준을 제시해 왔습니다. 단순한 인프라 제공을 넘어 딥러닝, 생성형 AI, 그리고 에이전트형 AI로 이어지는 기술 트렌드를 고객 중심의 관점에서 선도하고 있습니다. 특히 지난 10년은 컨테이너, 서버리스, 커스텀 실리콘, 그리고 AI 민주화를 통해 개발자와 기업이 이전에는 불가능했던 가치를 창출할 수 있도록 생태계를 확장해 온 과정이었습니다. ### 기술 트렌드에 대응하는 AWS의 혁신 철학 * 2006년 Amazon S3 출시 이후 AWS는 API 경제를 개척하며 개인 연구자와 기업 모두가 대규모 프로젝트를 수행할 수 있는 강력한 도구를 제공하기 시작했습니다. * AWS의 혁신은 단순히 화려한 유행을 쫓는 것이 아니라, 고객의 실제 목소리에 귀를 기울이고 가장 시급한 과제를 해결하는 '고객 중심'의 원칙을 따릅니다. * 기술 환경은 딥러닝의 등장에서 시작해 거대언어모델(LLM) 기반의 생성형 AI를 거쳐, 현재는 스스로 작업을 수행하는 에이전트형 AI(Agentic AI)로 빠르게 진화하고 있습니다. ### 클라우드 인프라와 데이터 아키텍처의 고도화 * **컨테이너 및 서버리스:** Amazon ECS와 EKS를 통해 대규모 컨테이너 관리를 단순화했으며, Fargate를 도입해 인프라 관리 부담 없이 서버리스 환경에서 컨테이너를 배포할 수 있게 했습니다. * **고성능 데이터베이스:** Amazon Aurora는 고가용성 관계형 DB의 표준을 세웠으며, 최근에는 0으로 스케일링이 가능한 Serverless v2와 초고속 분산 SQL 데이터베이스인 Aurora DSQL로 진화했습니다. * **하이브리드 클라우드:** AWS Outposts를 통해 저지연 데이터 처리가 필요한 온프레미스 환경에서도 AWS와 동일한 인프라 및 서비스를 사용할 수 있는 일관된 경험을 제공합니다. ### 커스텀 실리콘을 통한 성능 및 비용 최적화 * **AWS Graviton:** Arm 기반의 자체 프로세서를 개발하여 클라우드 워크로드에서 최고의 가격 대비 성능을 실현했으며, 현재 9만 명 이상의 고객이 이를 활용해 비용을 절감하고 있습니다. * **AI 전용 칩셋:** 추론용 Inferentia와 학습용 Trainium 칩을 통해 생성형 AI 애플리케이션 운영에 필요한 최적의 토큰 경제성을 제공하며, Anthropic과 같은 주요 AI 기업들의 워크로드를 지원합니다. ### AI 민주화와 에이전트 기술의 미래 * **Amazon Bedrock:** 다양한 업계 선도 모델을 안전하게 활용할 수 있는 플랫폼을 제공하며, 최근에는 'AgentCore'를 통해 복잡한 워크플로우를 자동화하는 에이전트 구축 기능을 강화했습니다. * **Amazon Nova 및 Titan:** 자체 모델인 Titan 시리즈에 이어 프론티어급 성능의 Nova 모델을 출시했으며, 특히 브라우저 UI 작업을 자동화하는 Nova Act 등 실질적인 업무 자동화 도구를 선보였습니다. * **차세대 AI 코딩:** Amazon Q Developer에서 한 단계 진화한 Kiro(에이전트형 AI 개발 도구)는 독립적인 개발 작업을 수행하는 자율 에이전트 기능을 통해 프로토타입부터 프로덕션까지의 개발 과정을 혁신하고 있습니다. AWS의 지난 20년은 기술이 소수의 전유물이 아닌 모두의 도구가 되는 과정이었습니다. 이제 기업들은 단순한 클라우드 전환을 넘어, SageMaker와 Bedrock 같은 플랫폼을 활용해 비즈니스 핵심에 AI를 내재화하고 에이전트 기술을 도입하여 운영 효율성을 극대화하는 'AI 퍼스트' 전략으로 나아가야 합니다.

toss원문

소프트웨어 3.0 시대를 맞이하며 (새 탭에서 열림)

소프트웨어 개발은 명시적 코딩(1.0)과 데이터 기반 학습(2.0)을 거쳐, 자연어 프롬프트가 프로그램이 되는 '소프트웨어 3.0' 시대로 진입하고 있습니다. 하지만 강력한 LLM 모델이라도 실질적인 업무를 수행하기 위해서는 모델의 능력을 제어하고 연결하는 '하네스(Harness)'라는 도구적 환경이 필수적이며, 이를 설계하는 데 있어 기존 소프트웨어 1.0의 계층형 아키텍처 원칙은 여전히 유효한 가이드가 됩니다. 결국 미래의 개발은 전통적인 설계 원칙을 유지하면서도, 에이전트가 인간과 소통하며 의사결정을 내리는 'Human-in-the-Loop(HITL)' 모델을 결합하는 방향으로 진화할 것입니다. **소프트웨어 3.0과 하네스의 필요성** - 안드레 카파시는 소프트웨어 3.0을 자연어로 된 프롬프트가 코드를 대신하는 시대로 정의하며, 이것이 이전 세대의 패러다임을 흡수할 것이라고 예측했습니다. - 하지만 LLM 단독으로는 코드베이스를 읽거나 데이터베이스에 접근하는 등의 실질적인 작업을 수행할 수 없다는 한계가 있습니다. - 이를 해결하기 위해 등장한 것이 '하네스(Harness)' 개념으로, 앤스로픽의 'Claude Code'처럼 모델이 도구(Skills)를 사용하고 외부와 통신하며 에이전트로 동작하게 만드는 실행 환경을 의미합니다. **계층형 아키텍처로 매핑한 에이전트 구조** - **슬래시 커맨드(Slash Command) = 컨트롤러(Controller):** `/review`, `/refactor`와 같은 명령어는 사용자 요청을 받아 적절한 워크플로우를 실행하는 서비스의 진입점 역할을 합니다. - **서브 에이전트(Sub-agent) = 서비스 계층(Service Layer):** 여러 기술(Skills)을 조합해 특정 비즈니스 로직을 완수하며, 독립적인 컨텍스트를 유지하는 단위입니다. - **기술(Skills) = 도메인 컴포넌트:** 단일 책임 원칙(SRP)에 따라 코드 리뷰, 테스트 생성 등 명확한 한 가지 기능만 수행하는 가장 작은 단위의 기능 모듈입니다. - **MCP(Model Context Protocol) = 인프라/어댑터:** 외부 API나 DB와의 연결을 추상화하여 내부 로직이 외부 시스템의 구현 상세를 몰라도 동작하게 돕습니다. - **CLAUDE.md = 프로젝트 헌장:** 기술 스택, 코딩 컨벤션 등 프로젝트의 변하지 않는 근간 원칙을 정의하며 시스템의 안정성을 보장합니다. **에이전트 설계에서 경계해야 할 안티패턴** - **God Sub-agent:** 하나의 서브 에이전트가 너무 많은 역할과 권한을 가지게 되면 관리 효율이 떨어지므로 적절한 분리가 필요합니다. - **기능 편애(Feature Envy):** 특정 기술이 자신의 역할 범위를 벗어나 다른 기술의 데이터나 프롬프트에 과도하게 의존하는 경우입니다. - **프롬프트 중복:** 동일한 프롬프트 내용이 여러 기술에 중복되어 포함될 경우 유지보수가 어려워지므로 공통화가 필요합니다. **에이전트만의 핵심 차별점: 질문하는 능력(HITL)** - 전통적인 소프트웨어는 예외 상황에서 미리 정의된 에러를 던지지만, 3.0 시대의 에이전트는 `UserAskQuestion` 기술을 통해 모호한 상황에서 사용자에게 직접 질문을 던질 수 있습니다. - 에이전트는 삭제나 배포처럼 되돌리기 어려운 작업, 혹은 여러 대안 중 선택이 필요한 고위험 상황에서 인간의 판단을 구하는 'Human-in-the-Loop' 구조를 가집니다. - 반면, 관습적으로 처리 가능한 일이나 안전한 반복 작업은 질문 없이 자율적으로 수행함으로써 효율성과 안정성 사이의 균형을 맞춥니다. 소프트웨어 3.0 시대에 적응하기 위해서는 모든 로직을 명시적으로 작성하려는 강박에서 벗어나야 합니다. 대신 계층 분리, 추상화, 단일 책임 원칙과 같은 전통적인 소프트웨어 공학의 정수를 에이전트 설계에 투영하여, LLM을 단순한 자동완성 도구가 아닌 신뢰할 수 있는 협력자로 구축하는 능력이 핵심 경쟁력이 될 것입니다.

line원문

LY Corporation의 클라우드 인프라 개편: 거대한 두 개의 클라우드를 통합한 차세대 플랫폼 Flava의 아키텍처 소개 (새 탭에서 열림)

LY Corporation은 기존의 'Verda'와 'YNW'로 나뉘어 있던 프라이빗 클라우드 인프라를 차세대 기반인 'Flava'로 통합하며 대규모 트래픽을 효율적으로 수용하고 있습니다. 이 과정에서 '장애를 전제로 한 설계'와 '소프트웨어 정의 기술'을 핵심 철학으로 삼아, 전용 장비에 의존하지 않고 범용 하드웨어의 성능을 극한으로 끌어올리는 아키텍처를 구현했습니다. 단순히 오픈소스를 사용하는 수준을 넘어 업스트림 기여와 자체 개발을 병행함으로써, 지속 가능한 운영 체계와 고성능 인프라 환경을 동시에 확보하는 것이 이번 통합의 핵심 결론입니다. **장애를 전제로 한 설계와 운영 철학** * **무상태성(Statelessness) 추구:** VM의 루트 디스크를 임시 저장소로 정의하고 영속 데이터는 외부 스토리지로 분리하여, 인스턴스 장애 시에도 서비스 영향을 최소화하고 즉각적인 재구축이 가능하도록 설계했습니다. * **애플리케이션 주도 가용성:** 인프라가 모든 신뢰성을 책임지는 대신, 애플리케이션 계층의 구성과 조합하여 전체 시스템의 가용성을 확보함으로써 인프라 단의 복잡성을 제거했습니다. * **신속한 복구 중심 운영:** 장애 발생 시 원인 규명보다 IaC(Infrastructure as Code)를 통한 환경 재구축을 최우선으로 하며, AZ(Availability Zone) 단위 배포를 통해 장애 영향 범위를 국소화합니다. **소프트웨어 정의 기술과 OSS 생태계 기여** * **업스트림 추종 아키텍처:** OpenStack, Ceph 등의 오픈소스를 독자적으로 커스터마이징하는 대신, 필요한 기능 개선안을 직접 업스트림에 커밋하여 유지보수 비용을 절감하고 기술적 최신성을 유지합니다. * **범용 하드웨어 성능 극대화:** x86 서버 위에서 XDP(eBPF)를 이용한 고속 데이터 플레인을 구현하고 하드웨어 오프로드를 활용하여, 고가의 전용 장비 없이도 와이어 스피드에 가까운 저지연 처리를 실현했습니다. * **자체 개발(Full Scratch) 역량:** 오픈소스만으로 해결하기 어려운 과제는 직접 개발합니다. HDD 효율을 극대화한 오브젝트 스토리지 'Dragon'이나 Rust/Go 기반의 SDN 컨트롤 플레인이 대표적입니다. **차세대 클라우드 Flava의 주요 개선 사항** * **단일 리소스 풀 통합:** 기존의 용도별 전용 환경을 폐지하고 거대한 단일 리소스 풀로 전환하여, 용량 관리의 복잡성을 해소하고 자원 활용 효율을 극적으로 높였습니다. * **VPC 기본화 및 보안 강화:** 모든 테넌트에 VPC(Virtual Private Cloud)를 기본 적용하여 논리적 격리를 강화했으며, 기존에 수개월이 걸리던 보안 환경 구축 시간을 단 몇 분으로 단축했습니다. * **자율적 비용 최적화:** 개발 환경 리소스에 유효 기간(Lifetime) 설정을 강제하여 유휴 자원을 자동 삭제하고, 접근 빈도에 따라 스토리지 클래스를 동적으로 변경할 수 있는 기능을 제공합니다. **관찰 가능성 및 자율 운영 체계** * **거시적·미시적 모니터링:** Prometheus와 자체 대시보드로 전체 트렌드를 파악(숲)하는 동시에, 커널 레벨 트레이스와 패킷 캡처를 통해 근본 원인을 심층 분석(나무)하는 도구 체계를 갖췄습니다. * **하드웨어 자율 운영:** 수만 대의 서버에서 발생하는 하드웨어 고장을 감지부터 교체 요청, 재투입까지 자동화했으며, 향후 LLM을 도입해 예외적인 고장 패턴까지 대응할 계획입니다. 성공적인 차세대 인프라 전환을 위해서는 기술적 고도화뿐만 아니라, 인프라를 블랙박스로 취급하지 않고 내부 동작을 깊이 이해하려는 팀 문화가 필수적입니다. 특히 기존 레거시 환경에서 신규 플랫폼인 Flava로의 마이그레이션 비용을 최소화하기 위해 사용자의 수동 대응을 줄여주는 투명한 이전 도구 개발에 집중할 것을 권장합니다.

line원문

엔터프라이즈 LLM 서비스 구축기 2: 에이전트 엔지니어링 (새 탭에서 열림)

엔터프라이즈 LLM 서비스를 구축함에 있어 복잡한 최신 기술을 무작정 도입하기보다, 서비스의 본질에 집중하여 불필요한 기술을 덜어내는 '소거법' 기반의 아키텍처를 설계했습니다. 실전 운영 결과, 파인 튜닝 대신 RAG를, 기계적 청킹 대신 '검색 후 자르기' 전략을, 그리고 복잡한 워크플로 대신 단순한 ReAct 구조를 채택함으로써 96.1%라는 높은 응답률과 시스템 안정성을 동시에 확보할 수 있었습니다. 이는 화려한 기술적 기교보다 제한된 비용과 속도 안에서 최적의 효율을 찾는 것이 실제 서비스 환경에서 더 효과적임을 입증합니다. ### 지식 주입 방식의 선택: 파인 튜닝 제외와 RAG 채택 * 파인 튜닝은 새로운 지식(Fact)을 주입하기보다 답변 스타일(Style)을 조정하는 데 훨씬 효율적이며, 지식 주입 정확도는 상대적으로 낮다는 연구 결과를 바탕으로 RAG를 주력 기술로 선정했습니다. * 제품 문서가 수시로 갱신되는 환경에서 파인 튜닝은 매번 데이터셋을 재구성하고 교차 검수해야 하는 막대한 유지보수 비용이 발생하지만, RAG는 원본 문서 업데이트만으로 즉각적인 대응이 가능합니다. * 실험 결과, 소규모 데이터셋을 통한 파인 튜닝은 모델이 이미 학습한 방대한 기존 지식의 벽을 넘지 못하고, 질문 형식이 조금만 바뀌어도 오답을 내놓는 한계를 보였습니다. ### 문맥 보존을 위한 전략: 청킹 없는 '검색 후 자르기' * 기존 RAG의 기계적 청킹(Pre-split)은 문맥 상실의 문제를 야기하므로, 각 문서의 주제가 명확하고 분량이 적은 서비스 특성을 고려해 문서를 통째로 임베딩하는 역발상을 적용했습니다. * 사용자 질문이 들어오면 관련 문서를 통째로 찾은 뒤, 마크다운 헤더(##) 기준으로 분할하고 경량 LLM 필터를 통해 질문과 관련 있는 섹션만 정밀하게 추출하는 '검색 후 자르기(Post-split)' 프로세스를 구축했습니다. * 이 방식은 질문의 맥락을 이미 알고 있는 상태에서 문서를 자르기 때문에, 정보의 희석 없이 모델에게 가장 필요한 핵심 조각들만 선별하여 전달할 수 있다는 장점이 있습니다. ### 효율적인 행동 구조: 복잡한 워크플로 대신 ReAct 방식 * '계획 후 실행(Plan-and-execute)'이나 '멀티 에이전트' 구조는 시스템 복잡도와 응답 지연(Latency)을 높일 뿐, 실제 답변 품질에서의 체감 성능 향상은 크지 않았습니다. * 특히 멀티 에이전트 구조는 전문가 간의 질문 배분 과정에서 추가적인 LLM 호출 비용이 발생하고, 여러 도메인이 섞인 질문에서 정보가 누락되는 취약점을 보였습니다. * 정제된 컨텍스트와 적절한 도구가 주어진다면 모델 스스로 추론하고 행동하는 ReAct 루틴만으로도 복잡한 논리적 순서를 충분히 구현할 수 있음을 확인하여, 시스템을 단순하게 유지했습니다. 성공적인 AI 에이전트 구축의 핵심은 유행하는 기술을 좇는 '덧셈'이 아니라, 서비스의 본질에 맞는 기술만 남기는 '뺄셈'에 있습니다. 현재 발생하는 답변 실패 원인의 절반 이상이 기술적 결함이 아닌 '참조 문서의 부재'에서 기인한다는 점을 고려할 때, 모델 아키텍처를 복잡하게 만들기보다는 AI가 학습하고 참조할 '교과서(원본 문서)'의 품질을 높이는 것이 성능 향상을 위한 가장 확실하고 실용적인 투자입니다.

datadog3분 읽기큐레이션 요약

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 운영을 하나의 플랫폼으로 통합하고 있다는 점이 핵심입니다.

원문 읽기(새 탭에서 열림)
datadog2분 읽기큐레이션 요약

에이전트를 위한 MCP 도구

Datadog이 Gartner의 **2026년 Observability Platforms Magic Quadrant에서 Leader로 선정되었다는 소식**을 전하는 내용입니다. 제공된 본문에는 선정 소식과 함께 Datadog의 제품군 및 플랫폼 기능을 소개하는 탐색 메뉴가 주로 포함되어 있으며, Gartner 평가의 세부 근거는 제시되지 않았습니다. ### Gartner Magic Quadrant 리더 선정 - Datadog은 Gartner의 **Observability Platforms 부문 Magic Quadrant 2026**에서 Leader로 소개되었습니다. - 원문에는 Gartner의 평가 기준, 경쟁사 비교, Datadog의 구체적인 강점이나 약점에 대한 상세 내용은 포함되어 있지 않습니다. - 따라서 이 자료만으로는 리더 선정이 제품 기능, 시장 실행력, 비전 중 어떤 요소에 기반했는지 판단하기 어렵습니다. ### 인프라 및 애플리케이션 모니터링 - 인프라 영역에서는 다음 기능을 제공합니다. - 인프라·호스트 모니터링 - 메트릭 및 컨테이너 모니터링 - Kubernetes 오토스케일링 - 네트워크, 서버리스, GPU 모니터링 - 클라우드 비용 및 스토리지 관리 - 애플리케이션 영역에는 다음 기능이 포함됩니다. - APM(Application Performance Monitoring) - 서비스 모니터링 - 지속적 프로파일링 - 동적 계측 - AI 에이전트 관측성 ### 로그·데이터·보안 관측성 - 로그 관리와 관측성 파이프라인을 통해 로그 수집, 처리, 라우팅을 지원합니다. - 데이터베이스, 데이터 스트림, 데이터 품질, 작업 실행 상태를 모니터링할 수 있습니다. - 보안 플랫폼에는 다음 영역이 포함됩니다. - 코드 및 클라우드 보안 - SAST, IAST, SCA - 취약점·비밀·민감 데이터 탐지 - Cloud SIEM - 워크로드 및 애플리케이션·API 보호 - 규정 준수 관리 ### 디지털 경험과 소프트웨어 전달 - 실제 사용자 모니터링(RUM), 세션 리플레이, 제품 분석, 오류 추적을 제공합니다. - Synthetic Monitoring과 모바일 앱 테스트를 통해 사용자 경험을 사전에 검증할 수 있습니다. - CI Visibility, 테스트 최적화, 지속적 테스트, 코드 커버리지, 기능 플래그 등 소프트웨어 전달 과정도 관측합니다. - 내부 개발자 포털과 IDE 플러그인으로 개발자 생산성까지 지원합니다. ### 서비스 관리와 AI 기능 - 이벤트 관리, 인시던트 대응, SLO, 케이스 관리, 워크플로 자동화 기능을 제공합니다. - Software Catalog와 대시보드를 통해 서비스와 운영 상태를 중앙에서 관리할 수 있습니다. - AI 영역에는 다음 기능이 포함됩니다. - Bits AI Agents와 Bits Investigation - Bits Chat 및 Bits Code - Agent Observability - MCP Server와 Pup CLI - GPU 모니터링 및 AI 통합 - 제품 메뉴 전반에서 관측성, 보안, 개발, 운영, AI를 하나의 플랫폼으로 통합하려는 방향이 드러납니다. 실무적으로는 Gartner의 리더 선정만으로 제품을 결정하기보다, 현재 사용하는 클라우드·컨테이너 환경과 필요한 로그 보존 기간, 데이터 비용, APM 및 보안 연동성을 기준으로 평가하는 것이 좋습니다.

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

넷플릭스의 마운트 메 (새 탭에서 열림)

넷플릭스는 컨테이너 런타임을 현대화하는 과정에서 수백 개의 컨테이너가 동시에 부팅될 때 시스템이 멈추거나 헬스 체크가 실패하는 심각한 병목 현상에 직면했습니다. 조사 결과, 이는 컨테이너 보안을 위해 도입된 사용자 네임스페이스(User Namespace)의 `idmap` 마운트 작업이 리눅스 커널의 VFS(가상 파일 시스템) 전역 잠금 장치에서 경합을 일으키기 때문으로 밝혀졌습니다. 특히 이러한 현상은 구형 다중 소켓(NUMA) 하드웨어 아키텍처에서 더욱 두드러지게 나타났으며, 최신 단일 소켓 인스턴스로 전환함으로써 스케일링 성능을 크게 개선할 수 있었습니다. **컨테이너 보안 강화와 마운트 폭증의 관계** - 넷플릭스는 보안 강화를 위해 각 컨테이너에 고유한 사용자 범위를 할당하는 새로운 런타임(Kubelet + Containerd)으로 전환했습니다. - 파일 소유권을 실제로 변경하는 비용을 줄이기 위해 커널의 `idmap` 마운트 기능을 사용하는데, 이는 각 레이어마다 `open_tree`, `mount_setattr`, `move_mount` 등의 호출을 발생시킵니다. - 50개의 레이어를 가진 컨테이너 100개를 동시에 실행할 경우, 이론적으로 약 20,000번 이상의 마운트 관련 작업이 수행되며 이는 커널의 마운트 테이블 전역 락(Global Lock)에 엄청난 부하를 줍니다. **커널 및 하드웨어 수준의 병목 현상 진단** - 시스템 분석 결과, CPU는 커널의 `path_init()` 함수 내 시퀀스 락(Sequence Lock)을 기다리는 스핀 루프(Spin Loop)에서 대부분의 시간을 소비하며 'Pause' 명령어를 반복 실행했습니다. - TMA(Topdown Microarchitecture Analysis) 분석에 따르면 파이프라인 슬롯의 95.5%가 경합된 액세스로 인해 중단되었으며, 57%는 가짜 공유(False Sharing)로 인해 발생했습니다. - 여러 코어가 동일한 캐시 라인에 접근하려고 시도하면서 캐시 라인 바운싱(Cache Line Bouncing) 현상이 발생하여 시스템 성능이 급격히 저하되었습니다. **인스턴스 아키텍처에 따른 성능 차이** - 테스트 결과, 5세대 인텔 듀얼 소켓 인스턴스인 `r5.metal`은 100개 이상의 컨테이너가 동시에 실행될 때 성능이 급격히 저하되며 실패하는 모습을 보였습니다. - 반면, 단일 소켓 및 단일 NUMA 도메인을 사용하는 7세대 인스턴스(`m7i.metal-24xl`, `m7a.24xlarge`)는 높은 동시성 환경에서도 훨씬 낮은 지연 시간과 높은 성공률을 유지했습니다. - 이는 NUMA 아키텍처의 프로세서 간 상호 연결(Interconnect) 대기 시간이 전역 락 경합 상황에서 병목 현상을 수배로 증폭시키기 때문입니다. 대규모 컨테이너 환경을 운영한다면 컨테이너 이미지의 레이어 수를 최소화하여 마운트 발생 횟수를 줄여야 합니다. 또한, 컨테이너 생성 및 삭제가 빈번한 워크로드의 경우 다중 소켓 기반의 구형 인스턴스보다는 메모리 접근 대기 시간이 짧고 락 경합에 유리한 최신 단일 소켓 혹은 단일 NUMA 노드 아키텍처를 선택하는 것이 성능 안정성에 유리합니다.

airbnb원문

대규모 환경에서 동적 (새 탭에서 열림)

에어비앤비(Airbnb)는 대규모 시스템에서 서비스 재시작 없이 런타임 동작을 변경할 수 있는 동적 설정 플랫폼 'Sitar'를 통해 개발의 유연성과 시스템의 안정성을 동시에 확보하고 있습니다. 설정을 코드처럼 관리(Config as Code)하고 단계별 배포 및 로컬 캐싱 전략을 도입함으로써, 설정 오류로 인한 장애 범위를 최소화하고 신속한 사고 대응이 가능한 환경을 구축했습니다. 이를 통해 에어비앤비는 수많은 마이크로서비스 환경에서도 안전하고 신뢰성 있는 설정 변경 프로세스를 운영하고 있습니다. **현대적인 동적 설정 플랫폼의 필수 요건** * **일관된 관리 경험:** 설정의 정의, 리뷰, 테스트, 배포에 이르는 전 과정을 통합된 워크플로우로 제공하여 개발자 경험을 개선합니다. * **설정의 코드화(Config as Code):** 모든 설정 변경은 서비스 코드와 마찬가지로 버전 관리, 코드 리뷰, 감사(Audit)가 가능해야 하며, 강력한 접근 제어가 수반되어야 합니다. * **격리된 환경에서의 테스트:** 운영 환경에 적용하기 전, 로컬이나 카나리(Canary) 환경에서 설정을 안전하게 검증할 수 있는 기능을 제공합니다. * **유연한 멀티테넌트 지원:** 서비스별 위험도에 따라 배포 전략(예: AWS 존 단위, 쿠키 단위, 포드 백분율 등)을 다르게 설정할 수 있어야 합니다. * **신속하고 통제된 사고 대응:** 장애 발생 시 긴급 설정을 즉시 배포할 수 있어야 하며, 변경 사항에 대한 높은 관측성(Observability)을 통해 원인을 빠르게 파악하고 롤백할 수 있어야 합니다. **Sitar 플랫폼의 4계층 아키텍처** * **개발자 지향 계층(Developer-facing layer):** 기본적으로 Git 기반 워크플로우를 사용하며, 긴급 상황이나 특정 운영 요구사항을 위해 웹 UI(Sitar-portal)를 병행 운영합니다. * **제어 평면(Control Plane):** 설정 변경의 오케스트레이션을 담당하며 스키마 검증, 권한 확인, 배포 범위 및 속도 결정 등 핵심 로직을 실행합니다. * **데이터 평면(Data Plane):** 설정 값의 원천(Source of Truth) 역할을 하며, 대규모 환경에서도 신속하고 일관되게 설정을 배포할 수 있는 확장성 있는 저장소 역할을 수행합니다. * **에이전트 및 클라이언트(Agents and Clients):** 서비스와 함께 실행되는 사이드카 에이전트가 설정을 가져와 로컬에 캐싱하며, 클라이언트 라이브러리는 애플리케이션이 이 설정에 빠르게 접근할 수 있도록 돕습니다. **안정성을 위한 핵심 설계 선택** * **Git 기반 워크플로우 활용:** GitHub Enterprise와 기존 CI/CD 도구를 재사용하여 코드 리뷰, 승인 절차, 변경 이력 관리 등 검증된 프로세스를 설정 관리에도 동일하게 적용합니다. * **단계별 배포(Staged Rollouts)와 빠른 롤백:** 변경 사항을 한꺼번에 적용하지 않고 범위를 점진적으로 확대하며, 회귀 장애 감지 시 즉시 알림을 보내고 신속하게 이전 상태로 되돌립니다. * **제어 및 데이터 평면의 분리:** '결정'하는 로직과 '전달'하는 메커니즘을 분리하여, 배포 전략을 수정하더라도 실제 데이터 저장 및 배포 인프라에 영향을 주지 않도록 설계했습니다. * **로컬 캐싱을 통한 회복 탄력성:** 사이드카 에이전트가 설정을 로컬에 저장하므로, 백엔드 시스템에 일시적인 장애가 발생하더라도 서비스는 마지막으로 확인된 정상 설정(Last known good config)으로 중단 없이 동작할 수 있습니다. 대규모 시스템에서 동적 설정을 안전하게 운영하기 위해서는 단순한 키-값 저장소를 넘어, **자동화된 스키마 검증, 단계별 배포, 그리고 인프라 장애 시에도 동작할 수 있는 로컬 캐싱 전략**이 필수적입니다. 설정을 코드와 동일한 수준의 엄격한 프로세스로 관리할 때, 비로소 유연성과 안정성이라는 두 마리 토끼를 잡을 수 있습니다.