cloudflare·2026년 8월 7일·3분 읽기큐레이션 요약

Workers AI와 AI Gateway를 하나의 AI 제어 플레인으로 통합하기

AI Gateway와 Workers AI는 각각 모델 호출 프록시와 Cloudflare 관리형 추론 서비스로 출발했지만, 이제 하나의 통합 AI 제어 평면으로 수렴하고 있다. 사용자는 단일 바인딩과 REST API를 통해 Workers AI를 포함한 여러 모델 제공자를 호출하면서 관측성, 로깅, 보안, 비용 관리, 결제를 한곳에서 처리할 수 있다. 향후에는 제공자가 아니라 원하는 모델을 기준으로 자동 라우팅·장애 조치·부하 분산까지 수행하는 모델 우선 라우팅을 제공할 계획이다. ## 통합된 바인딩과 REST API - Workers AI와 AI Gateway는 별도의 호출 경로가 아니라 동일한 `env.AI.run()` 바인딩으로 통합된다. - `gateway: { id: "default" }`를 지정하면 기본 AI Gateway를 통해 Workers AI 모델을 호출할 수 있다. - REST API도 통합되어 다음과 같은 `/ai/` 엔드포인트를 사용한다. - `https://api.cloudflare.com/client/v4/accounts/{account_id}/ai/run/{model}` - `cf-aig-gateway-id: default` 헤더로 기본 게이트웨이를 지정 - 사용자는 처음부터 Workers AI와 AI Gateway 중 어느 제품을 선택할 필요 없이 관측성과 제어 기능이 포함된 경로를 사용할 수 있다. - 여러 애플리케이션을 분리하거나 애플리케이션별 정책을 적용해야 하는 경우에는 별도의 이름 있는 게이트웨이를 지정할 수 있다. ## 자동 관측성과 제어 - AI Gateway를 사전에 생성하지 않아도 `default` 게이트웨이를 처음 인증 요청에 사용하면 자동으로 생성된다. - 별도 대시보드 설정 없이 다음 정보가 기록된다. - 요청 및 응답 전문 - 모델별 토큰 사용량 - 요청 비용 및 비용 귀속 - 지연 시간 분석 - 오류율 - 기존 Workers AI 직접 호출에 게이트웨이 옵션만 추가하면 전체 관측성을 활성화할 수 있다. - 이후 캐싱 규칙을 사용자 지정하거나 애플리케이션별로 트래픽을 분리하려면 이름 있는 게이트웨이로 변경하면 된다. - 프롬프트와 응답까지 확인할 수 있어 모델 동작 디버깅과 AI 출력 감사에 유용하다. ## AI Gateway 크레딧과 Workers AI 통합 결제 - 기존에는 AI Gateway 크레딧을 OpenAI, Anthropic 등 외부 제공자에만 사용할 수 있었다. - 이제 동일한 크레딧 지갑으로 다음 서비스의 사용량을 결제할 수 있다. - OpenAI - Anthropic - Workers AI - 기타 지원 모델 제공자 - Workers AI에도 선불 결제가 적용된다. - AI Gateway 통합 결제를 사용하는 Workers AI 이용자에게는 더 높은 요청 한도가 제공될 수 있다. - 실제 한도와 상향 요청 방법은 최신 개발자 문서를 확인해야 한다. ## 모델 우선 라우팅 - 현재는 사용자가 특정 제공자를 직접 선택해야 하므로, 해당 제공자의 장애나 속도 제한이 애플리케이션 장애로 이어질 수 있다. - 향후에는 “어느 제공자를 호출할지”가 아니라 “어떤 모델이 필요한지”를 지정하는 방식으로 전환한다. - 추론 능력이 높은 모델 - 빠른 요약 모델 - 저렴한 임베딩 모델 - AI Gateway가 모델을 호스팅하는 제공자를 선택하고 다음 작업을 자동으로 처리한다. - 제공자 선택 - 장애 조치 - 부하 분산 - 용량 부족 시 다른 제공자로의 투명한 전환 - 예를 들어 `kimi-k2.7-code`를 요청하면 Workers AI, Moonshot API 또는 동일 가중치를 제공하는 다른 검증된 제공자 중 적절한 경로가 선택될 수 있다. - 원하면 특정 제공자에 고정할 수도 있다. - 검증된 제공자를 사용하고 Zero Data Retention(ZDR) 같은 데이터 처리 요구사항도 반영할 예정이다. ## 실용적인 적용 방향 새 프로젝트라면 `default` 게이트웨이를 사용해 별도 설정 없이 로그, 토큰 사용량, 비용, 오류율을 확보하는 것이 권장된다. 애플리케이션이 커지면 이름 있는 게이트웨이로 분리하고 캐싱·보안·라우팅 정책을 세분화하면 된다. 장기적으로는 특정 제공자에 강하게 결합하기보다 모델 중심으로 호출 구조를 설계하는 편이 장애 대응과 비용 최적화에 유리하다.

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

옵저버빌리티rest-apiai-gatewayload-balancing+3

cloudflare·2026년 8월 4일·4분 읽기큐레이션 요약

이제 에이전트가 로컬 트레이싱으로 Workers를 디버깅할 수 있습니다

`wrangler dev`와 `vite dev`가 로컬 Worker 실행 중 OpenTelemetry 트레이스를 자동 수집해, 코딩 에이전트가 배포 전 오류 원인을 직접 분석하고 수정 결과를 검증할 수 있게 되었습니다. 별도의 SDK 설치, 트레이싱 설정, 에이전트 구성 없이도 에이전트 세션이 감지되면 Local Explorer API가 자동으로 안내됩니다. 에이전트는 트레이스와 로그뿐 아니라 로컬 바인딩 및 데이터 상태까지 조회해 디버깅할 수 있습니다. ## 로컬 Worker 실행 시 자동 트레이싱 - `wrangler dev` 또는 `vite dev`로 실행한 Worker 호출이 자동으로 OpenTelemetry 트레이스로 기록됩니다. - 별도의 SDK나 애플리케이션 코드 수정, 관측성 활성화 설정이 필요하지 않습니다. - Wrangler와 Cloudflare Vite 플러그인은 Miniflare를 통해 Worker를 로컬에서 실행하므로, 실제 Worker 런타임에 내장된 계측 기능을 로컬에서도 사용할 수 있습니다. - 에이전트 세션이 감지되면 개발 서버가 Local Explorer API 주소와 트레이스 조회 엔드포인트를 출력합니다. ## 에이전트가 자동으로 발견하는 Local Explorer API - Local Explorer는 로컬 리소스 데이터와 관측성 데이터를 확인할 수 있는 브라우저 UI이자 REST API입니다. - API 루트에서 OpenAPI 스키마를 제공하므로, 에이전트가 사전에 하드코딩된 지침 없이 실행 중 사용 가능한 엔드포인트를 탐색할 수 있습니다. - 트레이스와 연결된 콘솔 로그는 다음과 같은 읽기 전용 엔드포인트로 조회할 수 있습니다. ```text POST /cdn-cgi/explorer/api/local/observability/query ``` - 에이전트는 트레이스 조회 후 KV, D1, R2, Durable Objects, Workflows 등 로컬 바인딩과 저장 상태도 함께 검사할 수 있습니다. - Local Explorer는 Cloudflare 대시보드가 아니라 Worker와 같은 localhost에서 실행됩니다. - Wrangler에서 `e` 키 입력 - 또는 `/cdn-cgi/explorer` 접속 ## 트레이스로 오류 원인 식별 및 검증 예를 들어 `POST /api/orders`가 다음 작업을 수행한다고 가정합니다. - KV에서 활성 장바구니 조회 - D1에 결제 정보 저장 - Queue에 주문 처리 메시지 전송 스키마 변경 이후 요청이 500 오류를 반환하면 다음과 같이 분석할 수 있습니다. - 트레이스가 없을 때 - 500 응답만으로는 KV, D1, Queue 중 어디서 실패했는지 알기 어렵습니다. - 에이전트가 각 작업 전후에 임시 로그를 추가하고 요청을 반복 실행해야 합니다. - 로그 확인과 코드 수정이 반복되어 시간과 토큰이 소모됩니다. - 트레이스가 있을 때 - KV 조회는 성공했고, D1 삽입 단계에서 `no such column: delivery_window` 오류가 발생했다는 사실을 확인합니다. - D1 작업이 실패했기 때문에 Queue 호출까지 도달하지 않았다는 흐름도 파악할 수 있습니다. - 에이전트가 로컬 D1 스키마를 검사해 저장소에 존재하지만 아직 적용되지 않은 마이그레이션을 발견합니다. - 마이그레이션을 적용한 뒤 요청을 다시 보내고, 새 트레이스에서 성공 여부를 검증합니다. 이 과정은 임시 로그를 추가하거나 배포하지 않고도 오류 위치 확인, 환경 수정, 재검증을 한 번의 로컬 디버깅 루프에서 수행하게 해줍니다. ## 자동으로 기록되는 트레이스 범위 Worker 런타임인 `workerd`에 계측 기능이 내장되어 있어 다음 작업이 자동 기록됩니다. - **Fetch 호출** - 외부 HTTP 요청의 실행 시간 - 상태 코드 - 요청 관련 메타데이터 - **바인딩 호출** - KV, R2, D1, Durable Objects, Queues 등 Cloudflare 바인딩과의 상호작용 - **핸들러 호출** - `fetch`, `scheduled`, Queue 핸들러 등 호출 전체 생명주기 - 애플리케이션이 직접 생성한 커스텀 span도 자동 트레이스에 포함됩니다. - Miniflare는 런타임 이벤트와 콘솔 출력을 수집해 OpenTelemetry 트레이스 및 연결된 로그로 구성합니다. - 수집된 데이터는 내부 SQLite 기반 Durable Object에 저장되고, Local Explorer API를 통해 제공됩니다. ## 사람이 확인하는 Local Explorer - 에이전트는 REST API로 데이터를 조회하지만, 개발자는 브라우저 UI에서 동일한 정보를 시각적으로 확인할 수 있습니다. - 특정 요청을 선택하면 다음 정보를 볼 수 있습니다. - 전체 span 구조 - 각 작업의 실행 시간 - 속성 및 메타데이터 - 오류 정보 - 관련 콘솔 로그 - 로컬 바인딩 상태를 탐색하면서 요청 처리 흐름과 데이터 상태를 함께 점검할 수 있습니다. ## 사용 방법 - Wrangler 기반 프로젝트: ```bash npm install --save-dev wrangler@latest ``` - Cloudflare Vite 플러그인 기반 프로젝트: ```bash npm install --save-dev @cloudflare/vite-plugin@latest ``` 업데이트 후 평소처럼 `wrangler dev` 또는 `vite dev`를 실행하고, 에이전트에게 로컬에서 오류를 재현하고 수정한 뒤 검증하도록 요청하면 됩니다. 로컬 트레이스를 활용하면 배포 전에 실패한 바인딩 호출과 환경 문제를 빠르게 찾아 수정할 수 있으므로, Cloudflare Worker 프로젝트의 에이전트 기반 디버깅에서는 최신 Wrangler 또는 Vite 플러그인 사용을 권장합니다.

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

옵저버빌리티Cloudflare Workersdurable-objectssqlite+4

line·2026년 7월 31일·5분 읽기큐레이션 요약

Grafana에서 자연어로 장애 원인을 분석하기: LLM 에이전트 기반 SRELens 개발기

관측성 데이터가 메트릭·로그·트레이스·프로파일별로 분산되면, 장애 원인을 파악하기 위해 사람이 여러 도구를 오가며 맥락을 연결해야 합니다. LY Corporation의 Home SRE 팀은 이를 해결하기 위해 Grafana 플러그인인 SRELens를 개발했습니다. SRELens는 자연어 질문을 바탕으로 LLM 에이전트가 관측성 데이터를 조회하고, 도구 호출과 비용·권한·안전 정책을 백엔드에서 통제하며 원인 후보를 근거와 함께 제시합니다. ## 관측성 데이터가 분산되며 발생한 문제 - 메트릭은 Grafana·IMON, 로그는 LaaS·IU, 트레이스는 IMON 트레이스·Tempo, 프로파일은 별도 도구에서 확인해야 했습니다. - 장애 분석 과정에서 시간 범위, 서비스명, 라벨, 트레이스 ID 등의 맥락을 여러 시스템에 반복해서 옮겨야 했습니다. - 자체 호스팅형 LGTM-P 스택을 구축해 데이터를 통합했습니다. - Mimir: 메트릭 - Loki: 로그 - Tempo: 트레이스 - Pyroscope: 프로파일 - OpenTelemetry Collector: 데이터 수집 및 전달 - 데이터가 한곳에 모여도 사용자가 적절한 데이터소스와 라벨, 쿼리 방법을 알아야 한다는 문제는 남았습니다. - 예를 들어 서비스명이 데이터소스마다 `service_name`, `resource.service.name` 등 다른 필드로 표현될 수 있습니다. ## 오픈소스 PoC에서 확인한 한계 - **사용자 컨텍스트와 권한 전파** - Grafana 인증 사용자 정보를 대화 기록, 사용량 한도, 조회 권한에 안정적으로 연결하기 어려웠습니다. - **시스템 프롬프트 제어** - 도구 호출 순서, 재시도, 위험 작업 제한 같은 운영 정책을 사용자 질의와 분리해 보호하기 어려웠습니다. - **짧은 도구 호출 라운드** - 메트릭·트레이스·로그를 순차적으로 확인해야 하는 장애 분석을 충분히 수행하지 못했습니다. - **데이터소스별 라벨 차이** - 올바른 데이터소스를 선택해도 라벨이나 필드가 다르면 검색 결과가 0건이 될 수 있었습니다. - **운영 및 라이선스 제약** - 사내 환경에 맞게 수정하고 배포하는 데 한계가 있었습니다. - 이를 통해 단순한 자연어 질의 기능보다, LLM 에이전트의 행동을 운영 환경에 맞게 통제하는 것이 더 중요하다는 결론을 얻었습니다. ## SRELens 아키텍처 - SRELens는 Grafana 애플리케이션 플러그인으로 동작합니다. - 프런트엔드는 Grafana 내부에 채팅 UI를 제공합니다. - 백엔드는 다음을 담당합니다. - LLM 호출 - 시스템 프롬프트 합성 - 도구 오케스트레이션 - 사용량 및 비용 제한 - 결과 크기와 재시도 제어 - 관측성 데이터 조회는 MCP 게이트웨이를 통해 수행합니다. - 업스트림 MCP 도구 외에도 Grafana 패널 검색과 이미지 렌더링을 위한 로컬 도구를 제공합니다. - `find_grafana_panel` - `render_grafana_panel` - 업스트림 도구와 로컬 도구는 `CompositeClient`를 통해 LLM에 일관된 인터페이스로 노출됩니다. ## 세 계층으로 분리한 프롬프트 설계 ### 베이스 시스템 프롬프트 - 조직 전체에 적용되는 전역 행동 정책입니다. - 다음과 같은 규칙을 포함합니다. - 도구 호출 순서 - 결과가 없을 때의 폴백 전략 - 결과가 잘렸을 때 집계 쿼리를 재실행하는 방법 - 대시보드 생성·수정·삭제 등 위험 작업의 안전 규칙 - 응답 형식과 분석 근거 제시 방식 - 관리자만 수정할 수 있으며, 별도 설정이 없으면 코드에 포함된 기본 프롬프트를 사용합니다. ### 데이터소스 프래그먼트 - 환경별 관측성 시스템 정보를 YAML 형태로 제공합니다. - 주요 내용은 다음과 같습니다. - 우선 사용할 Mimir·Loki·Tempo 데이터소스 UID - 서비스명을 찾기 위한 라벨 후보 - Loki 로그의 JSON 파싱 및 구조화 메타데이터 처리 방법 - SRE의 운영 지식을 미리 제공해 불필요한 탐색을 줄이고 분석 성공률과 속도를 높입니다. ### 사용자 프롬프트 - 담당 서비스, 선호 응답 형식, 자주 사용하는 대시보드 등 개인·팀의 맥락을 저장합니다. - Redis에 저장되며 시스템 프롬프트의 추가 컨텍스트로 주입됩니다. - 베이스 프롬프트를 덮어쓰지 않으므로 개인화가 조직 공통 안전 정책보다 우선할 수 없습니다. ## 백엔드 중심의 툴 오케스트레이션 - 프런트엔드가 시스템 프롬프트를 조립하지 않고, 백엔드 오케스트레이터가 모든 프롬프트 합성을 담당합니다. - 에이전트는 다음 루프를 반복합니다. 1. 사용자 질문을 LLM에 전달 2. LLM이 요청한 MCP 또는 로컬 도구 실행 3. 도구 결과를 다시 LLM에 전달 4. 최종 분석이 나올 때까지 반복 - 운영 안정성을 위해 코드 수준의 가드레일을 적용했습니다. - 최대 10라운드로 도구 호출 제한 - 동일 도구·동일 인자의 중복 호출 차단 - 도구별 재시도 최대 2회 - 개별 도구 결과 크기 제한 - 전체 요청이 커질 경우 오래된 도구 결과를 플레이스홀더로 치환 - `tool_call_id`를 유지해 호출과 결과의 연결 보장 - 결과가 없으면 라벨, 시간 범위, 데이터소스를 바꿔 재시도하도록 유도 ## 비용·요청량 및 장애 대응 정책 - 사용자별 일일 토큰 한도를 적용합니다. - 분당 요청 수를 제한하고, 한도 초과 시 HTTP 429를 반환합니다. - 응답 후 OpenAI가 반환한 실제 프롬프트·출력 토큰 사용량을 사용자별 일일 버킷에 기록합니다. - 사용량은 Asia/Seoul 기준 자정에 초기화됩니다. - Redis는 대화 기록, 사용자 프롬프트, 쿼터 저장에 사용됩니다. - Redis 장애가 발생해도 단일 채팅 요청은 계속 처리할 수 있도록 설계했습니다. - 대화 기록 및 개인화 기능은 제한될 수 있습니다. - SRELens 전체가 동시에 중단되지는 않습니다. ## 실제 장애 분석 방식의 변화 - 사용자는 “특정 시간대에 왜 에러가 늘었는가”처럼 자연어로 질문할 수 있습니다. - SRELens는 하나의 분석 흐름에서 메트릭, 로그, 트레이스를 연결해 확인합니다. - 예시 시나리오에서는 베타 환경의 오류 급증을 분석하면서 특정 API 요청인 `CopyMedia` 호출 증가와 관련된 원인까지 범위를 좁혔습니다. - 기존처럼 대시보드, 로그 검색 시스템, 트레이스 도구를 오가며 사람이 상관관계를 직접 맞출 필요가 줄어듭니다. - 분석 결과는 단순한 결론이 아니라 조회된 관측성 데이터와 근거를 함께 제시하는 것을 목표로 합니다. 운영 환경에서 LLM 기반 장애 분석을 도입할 때는 자연어 인터페이스보다 통제 구조를 먼저 설계하는 것이 중요합니다. 조직 정책과 환경별 데이터소스 지식을 프롬프트 계층으로 분리하고, 도구 호출·권한·비용·재시도를 백엔드 코드로 제한해야 안정적이고 재현 가능한 분석 도구를 만들 수 있습니다.

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

옵저버빌리티모델 컨텍스트 프로토콜redisgrafana+3

gitlab·2026년 7월 8일·5분 읽기큐레이션 요약

AI 에이전트를 활용해 GitLab의 레이트 리미팅을 마이그레이션한 방법

GitLab은 3명의 엔지니어와 AI 에이전트를 활용해 레거시 애플리케이션·Rack 기반 레이트 리미팅을 `labkit-ruby` 단일 구현으로 통합했다. 에이전트는 코드 탐색, 사양 작성, 반복적인 구현과 테스트에는 효과적이었지만, 아키텍처 결정·점진적 롤아웃·관측성 설계·최종 판단은 여전히 사람의 책임이었다. 프로젝트의 성공을 결정한 것은 에이전트 자체보다 명확한 작업 루프, 작은 변경 단위, 점진적 배포, 그리고 실패를 되돌릴 수 있는 운영 체계였다. ## 레거시 레이트 리미팅 통합의 목표 - GitLab에는 다음 두 가지 레이트 리미팅 경로가 수년간 공존했다. - 애플리케이션 수준의 `Gitlab::ApplicationRateLimiter` - Rack 수준의 별도 레이트 리미터 - 목표는 두 시스템을 `labkit-ruby`의 단일 구현으로 통합하는 것이었다. - 새로운 구현은 다음 조건을 만족해야 했다. - 모든 요청에 적용될 만큼 안정적일 것 - 동작을 관측하고 테스트할 수 있을 것 - 장애 발생 시 되돌릴 수 있을 것 - 모놀리스와 다른 환경에서 동일하게 운영할 수 있을 것 - 기존 시스템에는 121개의 레이트 리미팅 키가 존재했다. ## 3명으로 구성된 포드와 AI 에이전트의 역할 - 포드는 세 명의 GitLab 엔지니어를 중심으로 구성됐다. - 모놀리스 측 구현과 롤아웃 담당 - `labkit-ruby`와 아키텍처 담당 - 범위 관리와 초기 gem 코드 작성 담당 - AI 에이전트는 다음 작업을 수행했다. - 코드와 기존 맥락 분석 - 기술 사양 초안 작성 - 범위가 제한된 변경 구현 - 테스트 작성 - 머지 리퀘스트 사전 검토 - GitLab Duo Code Review도 머지 리퀘스트의 품질 검토에 활용됐다. - 사람은 다음을 직접 맡았다. - 작업 범위 결정 - 아키텍처 설계 - 배포 및 롤아웃 판단 - 최종 리뷰와 승인 ## 사양-구현-검증 반복 루프 - 팀은 다음과 같은 엄격한 순서를 적용했다. 1. 에픽과 기존 코드 읽기 2. 사양 작성 3. 적대적 리뷰로 사양의 문제점 검토 4. 차단 이슈가 해결된 뒤 구현 5. 명시적인 증거를 바탕으로 검증 6. 머지 리퀘스트에 대한 적대적 리뷰 7. 필요 시 사람에게 에스컬레이션 8. 머지 - 적대적 리뷰는 최대 두 번의 해결 라운드까지만 허용하고, 이후에는 사람의 판단을 받도록 했다. - 프로젝트에서는 14개의 번호가 매겨진 사양과 30개가 넘는 `labkit-ruby` 머지 리퀘스트가 만들어졌다. - 레거시 코드처럼 맥락 파악과 반복 검증이 중요한 작업에서는 이처럼 제한된 루프가 에이전트 활용에 적합했다. ## 단계적 롤아웃과 에이전트가 잘한 작업 - 첫 번째 코호트에서는 트래픽이 많은 5개 키를 다뤘다. - `pipelines_create` - `notes_create` - `user_sign_in` - 그 외 주요 키 - 트래픽 비율을 `1% → 10% → 50% → 100%`로 단계적으로 높였고, 2026년 5월 5일 100% 배포를 완료했다. - 기존 `ApplicationRateLimiter`와 새 구현의 결과가 일치하는지 확인했지만, 단순히 불일치가 없다는 사실만으로 성공을 판단하지 않았다. - 실제로 제한에 걸릴 정도의 트래픽이 발생하지 않았을 가능성도 있기 때문이다. - 두 번째 코호트에서는 모놀리스 83개와 EE 12개를 포함한 95개 호출 지점을 두 개의 기능 플래그로 통합했다. - 이 작업을 수작업으로 했다면 약 95개의 플래그 변경과 190개의 YAML 수정이 필요했을 수 있지만, 에이전트는 이런 반복적인 코드베이스 전반의 변경에 특히 강했다. ## 관측성은 있었지만 실패 유형을 구분하지 못함 - 두 번째 코호트는 며칠간 섀도 모드에서 기존 구현과 비교되었고, 대체로 일치했다. - 그러나 강제 적용 모드로 전환한 뒤 인증되지 않은 일부 경로에서 식별자가 조용히 유실되는 문제가 발생했다. - 원인은 세 개의 `String` 값이 두 개의 원시 슬롯에 압축되면서 잘못된 값이 식별자를 덮어쓴 구조적 충돌이었다. - 일부 사용자는 짧은 시간 동안 일반적인 오류 메시지를 받았다. - 비교 시스템은 해당 키의 불일치를 이미 감지했지만, 대시보드가 다음을 구분하지 못했다. - 정상적인 동작 차이 - 데이터 구조 충돌 - 사용자에게 영향을 줄 수 있는 치명적 불일치 - 팀은 즉시 강제 적용 플래그를 끄고, 이틀 뒤 긴급 수정 사항을 배포했다. - 문제는 사양, 적대적 리뷰, 구현, 코드 리뷰, 점진적 롤아웃을 모두 통과했으므로, 단순히 “에이전트가 위험하다”기보다는 관측성이 충분히 세분화되지 않았던 것이 핵심 교훈이었다. ## 전체 키 인벤토리 관리의 실패 - 처음에는 다섯 개 코호트로 마이그레이션을 끝낼 계획이었다. - 마스터 브랜치 감사 과정에서 누락된 항목이 발견되어 여섯 번째 코호트를 추가했다. - Claude가 놓친 항목에는 다음이 포함됐다. - EE 전용 `notification_emails` - 일부 EE 레지스트리 항목 - 웹훅 관련 키 3개 - 1초 미만 주기의 `partner_*` 키 3개 - 고립된 어댑터 행 - 총 121개 키 중 17개가 초기 코호트에서 빠져 있었다. - 각 항목이 특정 코호트에 쉽게 들어가지 않는 이유는 있었지만, 목록에서 보이지 않아도 될 이유는 없었다. - 근본적인 실수는 에이전트와 사람이 전체 키 인벤토리 대비 진행 상황을 지속적으로 집계하도록 요구하지 않았다는 점이다. ## Redis 인프라 병목과 운영 판단 - `redis-cluster-ratelimiting`은 4개 샤드 클러스터로 운영됐다. - 마이그레이션으로 사용량이 증가하면서 기존에 알려져 있던 인프라 병목이 다시 나타났다. - 팀은 `maxclients`를 단계적으로 높였지만, 연결 수를 100,000까지 밀어붙이지 않고 75,000에서 중단했다. - 더 많은 연결을 허용하면 각 프라이머리의 CPU가 포화될 수 있었기 때문이다. - 각 샤드는 명령 실행에 하나의 코어를 사용했고, 수직 확장으로 해결할 여지도 제한적이었다. - 따라서 에이전트가 코드를 생성하더라도, 실제 배포 속도와 범위는 인프라 용량과 운영자의 판단에 의해 결정됐다. ## AI 에이전트가 바꾼 병목 - 에이전트 덕분에 코드 작성 자체는 더 이상 가장 느린 단계가 아니었다. - 대신 병목이 다음 영역으로 이동했다. - 사람의 리뷰 처리 용량 - 롤아웃 시점과 범위에 대한 판단 - 운영 중인 시스템을 주의 깊게 관찰하는 능력 - 에이전트는 요청하면 95개의 기능 플래그 같은 반복 작업도 만들어내지만, 그런 설계가 실제로 필요한지는 판단하지 못한다. - 예를 들어 코호트 1 이후 팀은 레이트 리미트마다 별도 기능 플래그를 두는 방식이 과도하다고 판단해 이후 마이그레이션에서는 적용하지 않기로 했다. - 에이전트와 협업하는 방법 자체도 학습이 필요했으며, 때로는 에이전트와 반복적으로 막혀 직접 처리하는 편이 빠르다고 느끼는 순간도 있었다. ## 최종 상태와 실용적인 교훈 - 2026년 6월 중순 기준으로 여섯 개 코호트가 모두 100% 롤아웃됐다. - `ApplicationRateLimiter`의 121개 키가 새 프레임워크를 통해 동작하게 되었고, 감사로 결과를 확인했다. - 이 사례에서 권장할 만한 방식은 다음과 같다. - 에이전트에는 반복적이고 범위가 명확한 변경을 맡긴다. - 아키텍처, 위험 허용 수준, 배포 중단 기준은 사람이 결정한다. - 전체 마이그레이션 대상을 인벤토리로 관리하고 누락 여부를 자동 검증한다. - 단순한 불일치 감지를 넘어 실패 원인과 심각도를 구분하는 관측성을 구축한다. - 기능 플래그와 점진적 롤아웃으로 즉시 되돌릴 수 있게 한다. - 코드 생성 속도가 빨라져도 리뷰와 운영 관찰에 필요한 사람의 시간을 충분히 확보한다.

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

옵저버빌리티AI 에이전트gitlab-duo-agent-platformredis+4

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

대규모 환경에서 데이터 완전성을 측정하는 방법

고객의 대시보드·알림·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의 이동을 세그먼트별로 계측하는 편이 문제 위치와 고객 영향을 더 정확히 파악할 수 있다. 특히 고유 식별자, 시간 버킷, 멱등적인 상태 추적을 함께 사용하면 재시도와 지연 데이터가 많은 환경에서도 실시간 완전성 검증이 가능하다.

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

옵저버빌리티애플리케이션 성능 모니터링Apache Kafka분산 시스템+3

discord·2026년 6월 30일·3분 읽기큐레이션 요약

Discord API의 비용 귀속

Discord의 API는 1,700개 이상의 엔드포인트와 약 700개의 백그라운드 작업을 포함한 단일 Python 코드베이스로 운영되며, 수백 개의 Kubernetes 배포에 단계적으로 배포된다. 기존 모니터링은 지연 시간·처리량·오류율은 보여주지만, 메시지 전송이나 스트리밍 같은 제품 기능별 호스팅 비용은 충분히 설명하지 못했다. Discord는 배포 구조를 변경하지 않고 애플리케이션 프로파일링 도구를 확장해, 각 기능의 코드 실행 시간에 따라 배포 비용을 배분하는 방식을 도입했다. ### 대규모 단일 API 코드베이스의 운영 - Discord API는 하나의 Python 코드베이스로 구성되어 있다. - 1,700개 이상의 API 엔드포인트와 약 700개의 백그라운드 작업을 포함한다. - 엔지니어들은 매일 공통 코드에 변경을 가한다. - 변경 사항은 수백 개의 Kubernetes 배포 환경에 단계적 롤아웃 방식으로 지속 배포된다. - 규모가 크고 변경 빈도가 높기 때문에, 매일 발생하는 변화가 사용자나 시스템에 미치는 영향을 추적하기 어렵다. ### 기존 관측성의 범위 - Discord는 다음과 같은 운영 지표를 이미 수집하고 있었다. - 지연 시간 - 처리량 - 오류율 - 이러한 지표는 성능 저하나 오류 증가 같은 회귀(regression)를 감지하는 데 유용하다. - 그러나 특정 제품 기능이 전체 호스팅 비용에서 차지하는 비중은 파악하기 어려웠다. - 예를 들어 다음과 같은 질문에 답하기 어려웠다. - 메시지 송수신 API 운영 비용은 얼마인가? - 스트림 시작 기능에는 얼마가 드는가? - Nitro 선물 전송 비용은 얼마인가? - 특정 코드 변경이 팀의 호스팅 비용을 얼마나 변화시켰는가? ### Kubernetes 배포 단위만으로는 부족한 비용 추적 - 클라우드 제공업체는 일반적으로 Kubernetes 배포별 비용 분류를 제공한다. - 하지만 Discord의 모든 배포에는 동일한 API 코드베이스가 배포된다. - 각 배포는 특정 HTTP 트래픽이나 백그라운드 작업의 일부를 처리하지만, 제품 기능 단위로 깔끔하게 분리되어 있지는 않다. - 비용 추적을 위해 배포를 기능별로 더 세분화하면 운영 복잡성이 지나치게 커진다. - 따라서 기존 배포 토폴로지를 변경하지 않고 비용을 추적할 방법이 필요했다. ### 동시 실행 환경에서의 비용 배분 - 하나의 API 워커 프로세스는 여러 작업을 동시에 처리한다. - 같은 시점에 여러 제품 기능과 관련된 코드를 실행할 수 있다. - 일부 트래픽은 특정 배포로 격리되어 있지만, 기능별 비용 분석에 충분할 정도로 분리된 것은 아니다. - 따라서 단순히 배포 단위의 비용을 특정 기능에 모두 할당할 수 없다. - 정확한 비용 배분을 위해서는 각 배포가 특정 기능의 코드 실행에 얼마나 많은 시간을 사용했는지 측정해야 한다. ### 프로파일링을 활용한 해결책 - Discord는 기존 애플리케이션 프로파일링 도구를 확장했다. - 각 기능과 관련된 코드가 실행된 시간을 측정하고, 이를 기반으로 배포 비용을 배분한다. - 이를 통해 배포 구조를 바꾸지 않고도 다음 단위의 비용을 추정할 수 있다. - 개별 API 엔드포인트 - 여러 엔드포인트로 구성된 제품 기능 - 글에 제시되는 수치와 코드는 실제 운영값이 아닌 설명을 위한 예시다. ### 실용적인 결론 기능별 인프라 비용을 파악하려면 서비스를 물리적으로 기능별 배포로 나누기보다, 공통 실행 환경에서 각 기능이 소비한 컴퓨팅 시간과 리소스를 측정해 비용을 배분하는 방식이 효과적이다. 특히 대규모 단일 코드베이스에서는 기존 관측성에 비용 귀속 정보를 결합하는 것이 운영 구조를 복잡하게 만들지 않는 현실적인 접근이다.

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

옵저버빌리티쿠버네티스PythonAPI 설계+2

aws·2026년 6월 17일·4분 읽기큐레이션 요약

AWS DevOps Agent, 프로덕션 배포 전 코드 변경 사항 평가를 위한 릴리스 관리 기능 추가(프리뷰) | Amazon Web Services

AWS DevOps Agent에 코드 변경사항을 운영 배포 전에 검토하고 자동으로 테스트하는 릴리스 관리 기능이 프리뷰로 추가되었습니다. 에이전트는 조직의 자연어 기준, 의존성 안전성, 접근 제어, 운영 환경 요구사항을 검토하고 변경사항에 맞는 테스트를 생성·실행합니다. 이를 통해 AI가 생성한 코드 증가로 발생한 리뷰 병목과 운영 환경과 테스트 환경의 차이를 줄이고, 코드 작성부터 배포까지 자동화 수준을 높일 수 있습니다. ## AI 코드 증가로 인한 리뷰와 테스트 병목 - AI 코딩 도구 확산으로 풀 리퀘스트 수가 리뷰·테스트 역량보다 빠르게 증가하고 있습니다. - 일정 압박 때문에 사람이 코드를 충분히 검토하지 못한 채 승인하는 문제가 발생합니다. - 테스트 환경이 운영 환경과 달라 실제 배포 후에야 문제가 발견될 수 있습니다. - AI 모델은 사람이 시간 압박 속에서 놓치기 쉬운 기능 및 보안 문제를 탐지할 수 있어, 빠르면서도 안전한 배포가 중요해졌습니다. ## 릴리스 준비성 검토 - 모든 코드 변경사항을 다음 기준으로 분석합니다. - 운영 환경 요구사항 - 서비스 및 리포지터리 간 의존성 안전성 - 사용자가 정의한 내부 표준과 모범 사례 - AWS Well-Architected Framework에 따른 접근 제어 변경사항 - 여러 리포지터리의 의존성을 분석해 한 서비스의 변경이 다른 서비스에 미칠 영향을 확인합니다. - 별도의 기준을 지정하지 않으면 일반적인 모범 사례를 적용합니다. - AWS가 관리하는 격리 환경에서 애플리케이션을 실행하고 다음을 확인합니다. - 빌드 성공 여부 - 애플리케이션 실행 가능 여부 - 기본적인 사용자 여정과 기능 동작 - 분석 결과는 AWS DevOps Agent 콘솔과 GitHub·GitLab 풀 리퀘스트 댓글에 표시됩니다. - Kiro power 또는 Claude Code 플러그인을 통해 커밋 전에 IDE에서 직접 검토를 실행할 수도 있습니다. ## 조직별 자연어 기준 설정 - AWS DevOps Agent 콘솔에서 `Knowledge` → `Instructions`로 이동해 검토 기준을 편집합니다. - `Release readiness review`에 특정 작업용 지침을 추가할 수 있습니다. - 일반 영어 문장으로 다음과 같은 내부 기준을 정의할 수 있습니다. - 암호화 및 네트워크 접근 규칙 - 로깅과 관측 가능성 요구사항 - 민감 데이터 분류 및 고위험 리소스 식별 - 차단하지 않고 경고만 해야 하는 기준 - 모든 에이전트에 공통 기준을 적용하려면 `All agents` 지침을 수정합니다. ## 자동 릴리스 테스트 - 웹 애플리케이션과 API 애플리케이션을 대상으로 변경사항에 특화된 테스트 계획을 자동 생성합니다. - 정적인 테스트 스위트를 반복 실행하는 대신, 변경 내용과 영향 범위를 분석해 테스트를 구성합니다. - 다음 유형의 문제를 검증합니다. - 기능적 정확성 - 기존 동작의 회귀 - 서비스 간 통합 문제 - 수동 테스트 계획에서 누락될 수 있는 시나리오 - 고객이 제공한 운영 유사 환경에서 병합 전에 테스트를 실행합니다. - 각 실행 결과에는 다음 구조화된 산출물이 포함됩니다. - 메트릭 - 로그 - 트레이스 - 테스트 실행 요약 ## 검토 실행 방법 - 먼저 GitHub 또는 GitLab 리포지터리를 Agent Space에 연결해야 합니다. - 연결된 코드는 인덱싱되며, 리포지터리와 클라우드 리소스 간 의존성을 나타내는 지식 그래프가 생성됩니다. - 웹 앱에서 Agent Space를 선택한 뒤 `Web app` 탭과 `Operator access`를 선택합니다. - 릴리스 준비성 검토는 다음 방식으로 실행할 수 있습니다. - 연결된 리포지터리에 풀 리퀘스트 제출 - 채팅에서 온디맨드 요청 실행 - 채팅에서는 다음과 같이 요청할 수 있습니다. ```text Perform a production risk analysis on my repository branch ``` - 이후 분석할 리포지터리와 브랜치를 지정합니다. - 브랜치 이름, 풀 리퀘스트 번호, 커밋 SHA를 기준으로 분석할 수 있습니다. - 인프라 영향, 설정 변경, 배포 시 발생 가능한 위험을 종합적으로 검토합니다. - 완료 후 후속 질문을 통해 특정 변경사항의 하위 소비자, 영향받는 파일과 줄 번호, 해결 방법을 추가로 확인할 수 있습니다. ## 검토 결과와 보고서 - `Changes` 메뉴의 `Proposed changes` 표에서 실행된 검토를 확인할 수 있습니다. - 카테고리와 상태로 필터링하거나 이름으로 검색할 수 있습니다. - `Timeline` 탭에서는 에이전트가 호출한 도구, 참고한 의존성, 각 단계의 관찰 내용을 시간순으로 확인할 수 있습니다. - `Report` 탭에는 다음 정보가 제공됩니다. - 최종 권고 조치 - 발견된 심각한 문제 수 - 커밋 리비전 - 변경된 파일 수 - 권고 조치는 다음 세 가지 중 하나입니다. - `BLOCK` - `Proceed with Caution` - `Safe to Release` - 보고서의 주요 구성은 다음과 같습니다. - `Analysis`: 권고 조치의 근거와 발견된 위험 - `Issues`: 심각도별 문제 목록 - `Recommendations`: 문제 해결을 위한 구체적인 조치 - `Changes`: 변경된 파일, 변경 유형, 분류, 변경 내용 AWS DevOps Agent의 릴리스 관리 기능은 사람의 리뷰를 완전히 대체하기보다는, AI 생성 코드가 늘어난 환경에서 반복적인 위험 분석과 변경별 테스트를 자동화하는 보조 수단으로 활용하는 것이 적절합니다. 우선 내부 보안·운영 기준을 자연어 지침으로 명확히 정의하고, 풀 리퀘스트 단계에서 릴리스 준비성 검토를 실행한 뒤 운영 유사 환경의 자동 테스트를 병행하는 방식을 권장합니다.

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

옵저버빌리티CI/CDgitlabgithub+4

netflix·2026년 5월 29일·5분 읽기큐레이션 요약

사일로에서 서비스 토폴로지로: 넷플릭스가 실시간 서비스 맵을 구축한 이유

넷플릭스는 수천 개의 마이크로서비스 간 실제 의존성을 실시간으로 보여주는 ‘Service Topology’를 구축했다. 기존의 지표·로그·트레이스는 시스템의 일부만 보여주므로, 장애 원인과 영향 범위를 파악하려면 엔지니어가 정보를 직접 조합해야 했다. Service Topology는 여러 데이터 소스로 네트워크와 애플리케이션 의존성 그래프를 만들고, 이를 통합해 빠르게 탐색할 수 있도록 하는 것이 핵심이다. ## 분산 시스템에서 의존성 파악이 어려운 이유 - 넷플릭스의 하나의 재생 요청도 인증, 추천, 인코딩 선택, 재생 최적화 등 수많은 서비스 호출을 발생시킨다. - 장애 상황에서 엔지니어가 즉시 확인해야 하는 질문은 다음과 같다. - 어떤 서비스가 서로 의존하는가? - 특정 서비스 장애나 점검의 영향 범위는 어디까지인가? - 문제가 상위 의존 서비스에서 시작됐는가, 현재 서비스가 다른 서비스로 전파하고 있는가? - 기존 관측 도구의 한계: - 메트릭은 성능 저하나 오류 같은 증상을 보여준다. - 로그는 개별 서비스의 동작을 보여준다. - 트레이스는 특정 요청의 흐름을 보여준다. - 그러나 시스템 전체의 지속적인 서비스 연결 구조를 한눈에 보여주지는 못한다. - 여러 도구의 정보를 엔지니어가 머릿속으로 조합해야 하므로, 장애 대응이 느리고 오류가 발생하기 쉽다. ## 실시간 서비스 맵이 필요한 배경 - 넷플릭스는 수천 개의 마이크로서비스와 수백 개의 엔지니어링 팀으로 운영된다. - 라이브 프로그램과 광고 지원 요금제 등 새로운 기능이 추가되면서 장애 조사와 모니터링의 신속성이 더욱 중요해졌다. - 특히 라이브 이벤트는 긴 장애 분석을 기다릴 수 없기 때문에 실시간에 가까운 의존성 정보가 필요하다. - 엔지니어 지원 요청을 분석한 결과, 다음과 같은 의존성 관련 질문이 반복적으로 제기됐다. - 상·하위 의존 서비스는 무엇인가? - 장애가 내 서비스 문제인가, 의존 서비스 문제인가? - 서비스를 중단하면 어떤 서비스가 영향을 받는가? - 메트릭에서 특정 서비스가 `Unknown`으로 표시되는 이유는 무엇인가? - 최근 호출 경로가 어떻게 바뀌었으며, 그것이 현재 문제와 관련 있는가? ## 기존 접근 방식에서 얻은 교훈 넷플릭스는 외부 그래프 데이터베이스와 상용 플랫폼을 검토하고, 다양한 저장 기술과 데이터 모델로 내부 프로토타입을 만들며 접근 방식을 발전시켰다. - **실시간성이 중요하다** - 하루 전 또는 몇 시간 전의 토폴로지는 자주 배포되는 환경에서는 이미 오래된 정보다. - 서비스 배포와 트래픽 변화에 따라 토폴로지가 거의 실시간으로 갱신되어야 한다. - **대규모 환경에서는 확장성이 핵심이다** - 소규모 환경에서 동작하는 저장소와 그래프 모델도 넷플릭스의 서비스 수와 트래픽 규모에서는 한계에 도달한다. - **기존 관측 생태계와의 통합이 필요하다** - 엔지니어가 새로운 도구와 작업 방식을 별도로 배워야 해서는 안 된다. - 기존 메트릭, 로그, 트레이스와 자연스럽게 연결되어야 한다. - **데이터 품질이 중요하다** - 누락되거나 잘못된 의존성 정보는 정보가 없는 것보다 위험하다. - 장애 상황에서 잘못된 원인이나 영향 범위를 판단하게 만들 수 있기 때문이다. - **단일 데이터 소스만으로는 부족하다** - 네트워크 연결 정보에는 애플리케이션 수준의 의미가 부족하다. - 애플리케이션 메트릭은 계측된 서비스만 포함할 수 있다. - 따라서 여러 관점의 데이터를 결합해야 한다. ## Service Topology의 요구사항 넷플릭스가 구축하려 한 것은 정적인 아키텍처 다이어그램이 아니라, 운영 상태를 계속 반영하는 ‘살아 있는 지도’였다. - 서비스 배포, 트래픽 변화, 신규 의존성 생성과 기존 의존성 제거를 실시간에 가깝게 반영한다. - 호출 그래프 탐색 결과를 1초 이내에 제공해야 한다. - 다음 두 계층을 모두 표현한다. - **네트워크 계층**: 실제로 어떤 서비스가 통신하는가 - **애플리케이션 계층**: 어떤 API와 엔드포인트가 호출되는가 - 단순한 연결 관계 외에도 다음 정보를 함께 표시한다. - 서비스 상태와 가용성 - 중요도 및 availability tier - 비즈니스 도메인 - 서비스 소유 팀 - 기타 운영 메타데이터 - 엔지니어가 탐색할 수 있는 UI뿐 아니라 자동화 시스템도 사용할 수 있는 프로그래밍 API를 제공한다. - 복원력 프레임워크 - 영향 범위 계산기 - 장애 대응 자동화 시스템 ## 세 가지 데이터 소스를 결합하는 구조 핵심 설계는 하나의 데이터 소스에 의존하지 않고, 서로 다른 관점에서 별도의 의존성 그래프를 구축하는 것이다. - 네트워크 계층, IPC 계층, 트레이싱 계층을 물리적으로 분리해 저장한다. - 각 계층은 독립적으로 발전하고 병렬로 조회할 수 있다. - 통합된 뷰가 필요할 때는 각 계층의 그래프를 동시에 탐색한 뒤 결과를 병합한다. - 이 구조를 통해 여러 계층을 함께 조회하더라도 1초 이내의 응답 시간을 목표로 한다. - 필요에 따라 통합된 그래프를 보거나, 특정 계층의 그래프만 독립적으로 분석할 수 있다. ## eBPF 기반 네트워크 흐름 첫 번째 데이터 소스는 커널 수준에서 eBPF로 수집한 네트워크 흐름 정보다. - 실제 네트워크 통신을 기반으로 어떤 서비스가 어떤 서비스에 연결되는지 기록한다. - 애플리케이션 계측 여부와 관계없이 실제 트래픽이 발생하는 모든 서비스를 포착할 수 있다. - 클러스터 간 통신과 애플리케이션 간 통신을 모두 파악할 수 있다. - 네트워크 트래픽이라는 실제 운영 데이터를 사용하므로 네트워크 계층의 기준점 역할을 한다. - 다만 네트워크 정보만으로는 어떤 API나 애플리케이션 기능이 호출됐는지 알기 어렵다. - 따라서 eBPF 데이터는 포괄적인 연결 관계를 제공하지만, 애플리케이션 의미를 해석하려면 IPC나 트레이싱 같은 추가 데이터가 필요하다. ## 운영 관점의 의미 - 서비스 토폴로지는 장애 원인 분석을 단순화하고, 상·하위 의존성 및 장애 전파 경로를 빠르게 확인하게 한다. - 서비스 중단이나 유지보수 전에 영향받을 서비스와 관련 팀을 파악할 수 있다. - UI와 API를 함께 제공함으로써 사람의 장애 대응과 자동화된 복원력·영향 분석을 모두 지원한다. - 정적인 아키텍처 문서보다 실제 트래픽과 현재 운영 상태를 반영하는 동적 지도가 분산 시스템에 더 유용하다. 실무적으로는 단일 관측 도구에 의존하기보다 네트워크 흐름, 애플리케이션 호출, 트레이싱 데이터를 결합해 의존성 정보를 구성하는 것이 좋다. 특히 대규모 마이크로서비스 환경에서는 실시간성, 데이터 정확성, 빠른 그래프 탐색, 기존 도구와의 통합을 초기 설계부터 핵심 요구사항으로 삼아야 한다.

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

옵저버빌리티분산 시스템마이크로서비스ebpf+2

dropbox·2026년 5월 21일·4분 읽기큐레이션 요약

Nova: 코딩 에이전트를 위한 사내 플랫폼을 소개합니다

코딩 에이전트는 코드 작성뿐 아니라 CI 장애 대응, 마이그레이션, 테스트 개선 등 소프트웨어 개발 전반의 반복 업무를 지원할 수 있다. Dropbox는 대규모 모노레포와 Bazel, 사내 인프라에 맞는 실행·검증 환경을 제공하기 위해 개별 도구 대신 클라우드 기반 플랫폼인 Nova를 구축했다. Nova는 대화형 세션과 비동기 자동화 작업을 하나의 인터페이스로 통합하고, 실제 빌드·테스트 결과를 바탕으로 에이전트가 반복적으로 수정하도록 설계됐다. ## 분산된 개발 업무를 통합하는 플랫폼 - 개발 과정에는 디버깅, 의존성 업데이트, 테스트 커버리지 개선, flaky test 수정처럼 반복적이지만 중요한 작업이 많다. - 작업에 따라 상호작용 방식이 다르다. - 개발자가 직접 대화하며 진행하는 대화형 세션 - 에이전트가 백그라운드에서 실행되고 의미 있는 결과만 전달하는 비동기 작업 - Dropbox의 대규모 모노레포는 Bazel의 캐시와 원격 실행, 온프레미스 인프라에 의존한다. - 일반적인 외부 코딩 에이전트는 로컬 개발에는 적합하지만 Dropbox의 저장소 구조와 빌드·검증 경로를 자연스럽게 지원하지 못한다. - 따라서 워크플로마다 별도 AI 도구를 만드는 대신, 실행·검증·컨텍스트 처리를 공통화한 플랫폼을 선택했다. ## Nova의 실행 및 검증 방식 - 각 Nova 세션은 특정 커밋 시점의 Dropbox 코드베이스 스냅샷을 기반으로 격리된 환경에서 실행된다. - 호출자는 다음 정보를 전달할 수 있다. - 기준 커밋 - 수행할 작업 - 작업 후 실행할 검증 명령 - 검증 실패 시 계속 진행할지 여부 - 최대 반복 횟수 - 결과를 게시할 브랜치 - 기본 흐름은 다음과 같다. - 에이전트가 변경 사항 제안 - Bazel 빌드·테스트 등 실제 검증 수행 - 실패 결과를 에이전트에 전달 - 에이전트가 원인을 분석하고 수정 - 정해진 반복 횟수까지 재검증 - 단순히 그럴듯한 패치를 생성하는 데 그치지 않고, 실제 Dropbox 개발 환경에서 변경 사항이 유효한지 확인한다. - 세션은 하나의 브랜치만 사용하고 코드 게시 작업은 에이전트 외부에서 처리한다. - 활성 브랜치와 게시 상태를 예측하기 쉽다. - 테스트 실행, 리베이스 등 후속 자동화를 단순하게 유지할 수 있다. - 여러 브랜치를 에이전트가 직접 관리할 때 발생하는 기준 브랜치 선택 문제를 피할 수 있다. ## 다양한 개발 인터페이스와 확장 기능 - Nova는 여러 코딩 에이전트를 동일한 인터페이스 뒤에서 사용할 수 있도록 확장됐다. - 제공 방식은 다음과 같다. - 웹 UI 기반 대화형 세션 - CLI - API - 로컬 에이전트, 스크립트, 사내 서비스에서 병렬 작업 실행 - 장기 실행 워크플로에 AI 단계를 추가할 수 있는 헬퍼를 제공한다. - 프롬프트 평가, 관측성, 피드백 수집 기능으로 에이전트 성능을 측정하고 개선할 수 있다. - 파일 수정 외에도 로그 수집, 장애 조사, 여러 단계에 걸친 컨텍스트 유지가 필요하므로 다음 확장 기능을 포함한다. - Skills - Plugins - MCP 통합 - 관측성 시스템 접근 ## CI 장애 대응에서 시작한 적용 - Nova는 CI 실패에 대한 수정 제안을 자동화하는 문제에서 출발했다. - 예시 요청은 특정 커밋에서 CI 실패를 조사하고, 관련 Bazel 테스트를 실행하며, 실패 시 최대 5회까지 수정·재검증하는 형태다. - 검증 명령을 호출자가 명시하므로 에이전트가 변경한 코드에 필요한 컴파일·테스트 범위를 구체적으로 지정할 수 있다. - 이 방식은 “변경 제안 → 실제 검증 → 실패 원인 반영”이라는 안정적인 자동화 패턴을 만든다. ## 개발자 주도 세션 - 엔지니어는 Nova 웹 UI에서 로컬 개발을 중단하지 않고 빠른 수정이나 프로토타입을 진행할 수 있다. - Bazel 선택성 도구와 검증 명령을 결합해 변경된 코드와 관련된 컴파일·테스트 대상만 검증할 수 있다. - Slack 대화에서 바로 Nova 세션을 시작하고 해당 스레드의 논의 내용을 컨텍스트로 전달할 수 있다. - 이를 통해 문제 설명이나 팀 내 논의를 에이전트 프롬프트에 수동으로 다시 작성하는 비용을 줄인다. ## Flaky test 자동 수정 - Nova의 대표적인 운영 자동화 사례는 flaky test remediation이다. - Dropbox의 flaky 테스트 탐지 시스템인 Athena와 내부 도구 Deflaker를 결합했다. - Deflaker의 흐름은 다음과 같다. - 테스트가 성공한 사례와 실패한 사례를 수집 - 관련 로그를 Nova에 컨텍스트로 전달 - 에이전트가 가능한 근본 원인을 분석 - 수정안을 제안 - 이는 단순 코드 생성보다 로그 분석, 증거 비교, 원인 추론이 중요한 장기 실행형 워크플로에 해당한다. ## 실용적인 시사점 코딩 에이전트를 도입할 때는 에디터 플러그인 하나를 추가하는 것보다 저장소, 빌드 시스템, 테스트 인프라, 로그와 컨텍스트를 연결하는 플랫폼 설계가 중요하다. 특히 에이전트의 결과를 실제 검증 명령으로 확인하고, 실패 결과를 다시 에이전트에 제공하는 반복 루프와 예측 가능한 브랜치·게시 정책을 갖추는 것이 안정적인 자동화의 핵심이다.

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

옵저버빌리티CI/CD모델 컨텍스트 프로토콜slack+4

kakao·2026년 5월 21일·4분 읽기큐레이션 요약

메시징 서버의 스트레스 테스트 노하우와 AI 가 덜어 준 부분

메시징 서버의 안정적 운영을 위해서는 실서비스와 동일한 환경에서 상시 스트레스 테스트를 수행하고, 실제 트래픽 패턴과 최악의 시나리오를 재현해야 한다. 테스트는 단순히 서버가 장애 없이 버티는지를 보는 것이 아니라 RPS, 지연 시간, 오류율, 시스템 자원 등을 계층적으로 분석해 병목 원인을 찾아내는 과정이다. 관측성 도구, 프레임워크, OS·보안 시스템, 신규 기능 변경 전후에도 스트레스 테스트를 적용해야 운영 장애를 예방할 수 있다. ## 상시 스트레스 테스트 환경 구성 - 테스트 대상 서버는 실운영 서버와 동일한 JVM heap, CPU·메모리 한도, 네트워크 사양으로 구성한다. - 운영 서버 대수가 다르면 측정값을 그대로 비교하기 어렵기 때문에 필요한 경우 수치 보정을 적용한다. - 부하 생성에는 Locust를 사용하며, 클러스터 리소스에 따라 수백 개의 워커 파드까지 확장한다. - 부하 생성 클라이언트의 자원 부족이 서버 성능 측정에 영향을 주지 않도록 클라이언트 리소스를 충분히 확보한다. - 경우에 따라 `org.openjdk.jmh:jmh-core`를 이용해 프레임워크나 프로토콜 자체를 벤치마크한다. ## 실제 트래픽을 반영한 시나리오 설계 - 여러 사용자 동작을 실제 환경의 비율에 맞춰 조합한다. - 평시 정오에는 메시지 전송, 채팅방 입장, 채팅방 목록 조회, 메시지 조회가 비교적 고르게 분포한다. - 신년 자정에는 메시지 전송 비중이 52%에서 61%로 증가하고, 채팅방 목록 조회는 18%에서 8%로 감소한다. - 같은 RPS라도 READ·WRITE 프로토콜 비율에 따라 병목 지점과 최대 처리량이 달라질 수 있다. - 새로운 시나리오마다 부하 코드를 새로 작성하지 않고, 사용자 수·요청 비율·동시성 등 설정값을 조합해 다양한 트래픽을 재현한다. ## 변경 유형별 스트레스 테스트 ### 관측성과 로깅 인프라 추가 - Logstash, Fluent Bit, OpenTelemetry, Vector DB 등 관측성 컴포넌트가 애플리케이션 처리량과 응답 시간에 미치는 영향을 확인한다. - 메트릭 수집 때문에 애플리케이션 부하가 증가하거나 CPU·메모리·네트워크 사용량이 변하지 않는지 측정한다. - 높은 트래픽에서 내부 메트릭과 알림 시스템 자체가 지연되는지도 검증한다. ### 프로토콜·프레임워크 벤치마크와 포팅 - 비즈니스 로직을 제외하고 동일한 I/O 부하를 주어 프로토콜이나 프레임워크별 성능을 비교한다. - WebFlux, virtual thread 등 기술 선택을 추상적인 장점이 아니라 실제 RPS, latency, CPU 사용량으로 판단한다. - CPU 부하와 I/O 대기 시간을 단계적으로 늘려 현재 서비스가 CPU-bound인지 IO-bound인지 확인한다. - C++에서 Kotlin으로 메인 서버를 포팅할 때도 전후 시스템 지표를 비교하고, GC 튜닝 등을 통해 성능 차이를 줄였다. ### OS 변경과 보안 시스템 도입 - 온프레미스 호스트 OS 변경, 백신, 보안·모니터링 에이전트 추가가 고부하 상황에서 미치는 영향을 검증한다. - 평상시에는 드러나지 않던 slab 메모리 누수나 백신 동작 시 리소스 급증이 대규모 트래픽에서 문제가 될 수 있다. - 적용 전후 응답 시간과 처리량이 악화되지 않는지 확인한 뒤 인프라 변경을 진행한다. ### 메시징 도메인 특화 임계 상황 - 한 채팅방에서 여러 사용자가 동시에 메시지를 전송하는 상황을 재현한다. - 자정 메시지 burst, 수백 명 규모의 단체 채팅방 입장 등 최악의 시나리오를 별도로 검증한다. - 신규 기능도 부하 상황에서 예상되는 병목을 먼저 파악한 후 출시한다. ## 지표를 계층적으로 분석하는 방법 ### 엔드포인트 지표 - **RPS**: 워커 수를 점진적으로 늘려 포화 지점을 찾거나, 동일한 부하에서 RPS가 안정적으로 유지되는지 확인한다. - 예상보다 낮은 RPS에서 포화되거나 처리량이 급격히 흔들리면 내부 원인 분석으로 넘어간다. - **Latency**: - P50은 대부분 사용자의 일반적인 경험을 나타낸다. - P95·P99는 최악의 응답 시간과 내부 병목을 파악하는 데 유용하다. - P95·P99가 급증하면 처리량 한계나 대기열 문제를 의심한다. - P50 자체가 목표치나 실제 환경보다 높아도 비정상으로 판단한다. - **Error rate**: - 5xx는 서버 처리 한계에 도달했을 가능성이 있다. - timeout은 클라이언트 자원 부족이나 타임아웃 설정을 확인해야 한다. - 400 오류는 테스트 데이터나 비즈니스 시나리오가 잘못되었을 가능성이 있다. ### 시스템 자원 지표 - 본문은 시스템 자원 레이어 설명 중간에서 끝나지만, 엔드포인트 지표에서 이상이 발견되면 CPU·메모리·네트워크 등 하위 시스템 지표를 세부적으로 확인하는 방식으로 이어진다. - 스트레스 테스트 결과는 단순한 성공·실패가 아니라, 어느 계층에서 병목이 발생했는지 추적하는 디버깅 과정으로 해석해야 한다. 실무에서는 운영과 유사한 테스트 환경을 상시 유지하고, 평시 트래픽뿐 아니라 도메인 특유의 폭증 시나리오까지 자동화하는 것이 중요하다. 또한 변경 사항을 도입할 때 RPS, P50/P95/P99 latency, 오류율, 시스템 자원을 동일한 기준으로 비교해 정량적으로 판단하는 것이 권장된다.

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

옵저버빌리티Kotlinopen-telemetryperformance-testing+4

gitlab·2026년 4월 29일원문

GitLab 패치 릴리스: 18.11.2, 18.10.5 | GitLab 문서 (새 탭에서 열림)

GitLab은 GitLab Dedicated 고객의 재해 복구(DR) 목표인 RTO(복구 목표 시간)와 RPO(복구 지점 목표)를 안정적으로 달성하기 위해 관측성(observability) 간극을 해결한 18.11.2 및 18.10.5 패치 버전을 출시했습니다. 이번 릴리스는 보안 수정 사항을 포함하지 않는 대신, 시스템의 안정성을 저해하는 다수의 회귀 버그와 성능 이슈를 해결하는 데 집중했습니다. 사용자들은 이번 업데이트를 통해 AI 기능의 호환성을 높이고 특정 상황에서 발생하는 시스템 부하 문제를 해소할 수 있습니다. ### 주요 기능 개선 및 버그 수정 * **AI 및 GitLab Duo 기능 강화**: 셀프 호스팅 모델을 사용하는 환경에서도 Code Suggestion 기능을 사용할 수 있도록 지원을 추가했으며, Duo Core 사용자가 코드 리뷰 기능을 차질 없이 사용할 수 있도록 개선했습니다. * **시스템 성능 및 안정성 최적화**: 특정 사용자를 차단(Ban)할 때 Sidekiq 리소스 사용량이 급증하는 스파이크 현상을 해결하여 백그라운드 작업의 안정성을 높였습니다. * **관측성 지표 추가**: 동기화되지 않은 데이터의 가장 오래된 시간을 추적하는 `*_oldest_unsynced_time` 메트릭을 추가하여 시스템 상태 모니터링을 더욱 정교화했습니다. * **UI 및 워크플로우 개선**: 워크 아이템 페이지 로드 시 기존 필터를 초기화하여 사용자 경험을 개선했으며, 실패한 재할당 작업을 다시 시도할 수 있는 GraphQL mutation을 도입했습니다. ### 인프라 및 환경별 특이 사항 * **데이터베이스 및 마이그레이션**: 18.10.5 버전에서 이미 삭제된 테이블을 참조하는 마이그레이션을 건너뛰도록 수정(BBM)하여 업데이트 오류를 방지했습니다. * **Geo 및 설치 환경 호환성**: Geo 보조(Secondary) 노드에서 불필요한 워커 실행을 방지하도록 수정했으며, 상대 경로(Relative URL)를 사용하는 설치 환경에서 OAuth 탐색이 실패하던 문제를 해결했습니다. * **기능 롤백**: 18.11.2 버전에서는 역할 및 권한 활성화와 관련된 리팩토링(ia-refactor-role-permission-enablement) 내용을 이전 상태로 되돌려 안정성을 우선시했습니다. ### 업데이트 가이드 및 권장 사항 * **다운타임 발생 유의**: 단일 노드 인스턴스의 경우 마이그레이션이 완료될 때까지 서비스 가동이 중단되므로 작업 시간을 사전에 확보해야 합니다. * **제로 다운타임 업그레이드**: 다중 노드 환경에서는 GitLab의 표준 제로 다운타임 업그레이드 절차를 따르면 서비스 중단 없이 패치를 적용할 수 있습니다. * **사후 마이그레이션 실행**: 두 버전 모두 업그레이드 프로세스 종료 후 실행해야 하는 '사후 배포 마이그레이션(Post-deploy migrations)'을 포함하고 있으므로, 관리자는 업그레이드 완료 후 해당 작업이 정상적으로 수행되었는지 확인해야 합니다.

옵저버빌리티gitlabGraphQLdatabase-migrations+4

gitlab·2026년 4월 28일원문

대규모 환경에서 CI/CD 관측성을 구축하는 방법 (새 탭에서 열림)

GitLab 셀프 매니지드 환경에서 CI/CD 가시성을 확보하는 것은 대규모 데브옵스 플랫폼의 성능 최적화와 안정적인 운영을 위한 필수 과제입니다. 이 글은 Prometheus와 Grafana, 그리고 전용 익스포터를 활용하여 원시 파이프라인 데이터를 실시간 대시보드로 변환하고 의사결정에 필요한 핵심 통찰을 얻는 기술적 방법론을 제시합니다. 이를 통해 기업은 인프라 투자 효율성을 높이고 병목 현상을 체계적으로 해결할 수 있는 데이터 기반의 관리 체계를 구축할 수 있습니다. ### 실시간 통찰을 위한 다층적 대시보드 구성 효과적인 CI/CD 옵저버빌리티를 위해 다음과 같은 네 가지 핵심 대시보드를 구성하여 운영 가시성을 확보합니다. * **파이프라인 개요 대시보드:** 전체 실행 횟수, 시간 흐름에 따른 성공/실패율, 평균 소요 시간 추이를 시각화합니다. 상태별 색상 코딩을 통해 플랫폼 팀이 성능 저하를 즉각적으로 감지할 수 있도록 합니다. * **작업(Job) 성능 대시보드:** 개별 작업의 실행 시간 분포(히스토그램)와 가장 느린 상위 10개 작업을 분석합니다. 프로젝트 및 스테이지별 실패 히트맵을 통해 최적화가 필요한 병목 지점을 특정합니다. * **러너 및 인프라 대시보드:** Node Exporter의 호스트 지표(CPU, 메모리, 디스크)와 파이프라인 대기 시간을 결합하여 분석합니다. 인프라 포화도와 작업 지연의 상관관계를 파악하여 러너 스케일링이나 인스턴스 업그레이드 등의 용량 계획 수립에 활용합니다. * **배포 빈도 대시보드:** 환경별 배포 횟수와 소요 시간을 추적하여 DORA 지표를 관리합니다. 엔지니어링 리더십은 이를 통해 릴리스 속도와 메인 브랜치 대비 커밋 지연 상태(Environment Drift)를 점검할 수 있습니다. ### 옵저버빌리티 구현을 위한 핵심 기술 스택 GitLab의 원시 데이터를 수집하고 시각화하기 위해 두 가지 주요 익스포터와 컨테이너 기반 인프라를 사용합니다. * **GitLab CI Pipelines Exporter:** GitLab API를 통해 파이프라인 소요 시간, 작업 상태, 배포 정보 등 CI/CD 관련 핵심 메트릭을 수집합니다. * **Node Exporter:** 러너가 실행되는 호스트의 하드웨어 및 OS 지표를 수집하여 인프라 수준의 통찰을 제공합니다. * **Grafana 파일 기반 프로비저닝:** 모든 대시보드를 코드로 관리하고 자동으로 배포하여 여러 환경에서 일관된 모니터링 환경을 유지합니다. 프로젝트나 브랜치별 필터링을 위한 변수 설정이 가능합니다. ### 엔터프라이즈급 Kubernetes 배포 아키텍처 대규모 환경에서는 확장성과 보안을 위해 Kubernetes 클러스터에 각 컴포넌트를 분리된 Deployment로 배포하는 것이 권장됩니다. * **네임스페이스 및 보안 관리:** `gitlab-observability`와 같은 전용 네임스페이스를 생성하고, GitLab API 접근을 위한 Personal Access Token(`read_api` 권한)을 Kubernetes Secret으로 안전하게 관리합니다. * **익스포터 배포:** `gitlab-ci-pipelines-exporter`를 Deployment로 구성하고, ConfigMap을 통해 수집 대상 프로젝트 및 설정을 주입합니다. * **데몬셋 활용:** `Node Exporter`는 DaemonSet으로 배포하여 클러스터 내 모든 노드의 메트릭을 빠짐없이 수집합니다. * **Prometheus 통합:** 수집된 모든 메트릭은 Prometheus로 집계되며, 이를 Grafana의 데이터 소스로 연결하여 시각화 체계를 완성합니다. 대규모 CI/CD 환경을 운영하는 조직이라면 단순한 로그 확인을 넘어, 이와 같은 통합 옵저버빌리티 스택을 구축할 것을 권장합니다. 특히 인프라 비용 최적화와 개발 생산성 향상을 목표로 한다면, DORA 메트릭과 인프라 지표를 연계한 분석이 병목 현상 해결의 결정적인 열쇠가 될 것입니다. 중간 규모 이하의 환경이나 PoC 단계에서는 Docker Compose를 통해 빠르게 프로토타입을 구축해본 후 Kubernetes로 확장하는 전략이 효과적입니다.

옵저버빌리티쿠버네티스CI/CDgitlab+4

line·2026년 4월 22일원문

신뢰성 향상을 위한 SLO/SLI 도입 3편 - 서비스 적용 사례 (새 탭에서 열림)

SLI(Service Level Indicator)와 SLO(Service Level Objective)의 도입은 단순히 지표를 설정하는 기술적 작업을 넘어, 사용자 중심의 관점으로 서비스를 재정의하고 조직의 협업 문화를 구축하는 과정입니다. 정량적인 지표와 오류 예산(Error Budget) 개념을 활용하면 서비스의 신뢰성과 비즈니스 혁신 사이에서 객관적인 판단 근거를 마련할 수 있습니다. 결과적으로 SLO는 사용자에게 안정적인 경험을 제공하는 동시에 엔지니어링 리소스를 효율적으로 배분하는 핵심 도구가 됩니다. **신뢰성 향상을 위한 마인드셋과 협업** * **사용자 여정 중심의 사고**: 서비스의 수많은 기능 중 사용자가 가장 많이 사용하거나 반드시 필요한 '핵심 사용자 여정(CUJ)'을 식별하는 것이 첫걸음입니다. * **다학제적 협업 체계**: 서비스 담당 부서(CUJ 정의), 인프라 조직(측정 환경 구축), SRE(도구 구현 및 모니터링) 등 이해관계자 모두가 목표를 공유하고 책임을 나누는 문화가 필수적입니다. **SLI/SLO 구현의 4단계 프로세스** * **CUJ 분석**: 가입, 메시지 송수신, 인증과 같이 비즈니스 목표와 사용자 경험에 직결되는 핵심 기능을 사용자 관점에서 선별합니다. * **SLI 정의**: 게이트웨이나 백엔드 등 적절한 측정 위치를 선정하고, 응답 시간(Latency)의 퍼센타일과 응답 성공률(Success Rate)에 대한 명확한 성공/실패 기준을 수립합니다. * **SLO 타깃 설정**: 28일 등 특정 기간 동안 달성할 현실적인 목표 수치를 정하며, 안정성 확보 비용과 사용자 경험 사이의 적절한 균형점을 찾습니다. * **시각화**: 전체 상태와 오류 예산 현황을 한눈에 파악할 수 있도록 대시보드를 구성하며, 색상(초록/주황/빨강)을 활용해 직관적인 인지성을 높입니다. **오류 예산을 활용한 의사 결정 및 운영** * **정량적 소통**: '서비스가 느리다'는 추상적 표현 대신 '응답 시간이 SLI 기준인 400ms를 초과했다'는 식의 정확한 데이터로 문제를 파악합니다. * **리소스 배분 가이드**: 오류 예산이 넉넉하면 신규 기능 출시나 공격적인 릴리스에 집중하고, 예산이 소진되어 가며 안정성 강화와 이슈 대응에 리소스를 우선 투입합니다. * **온콜(On-call) 및 예방**: 오류 예산의 상태 변화를 실시간 알림으로 받아 이슈에 신속히 대응하며, 정기적인 SLO 점검을 통해 서비스 품질을 지속적으로 관리합니다. 성공적인 SRE 문화를 정착시키기 위해서는 SLO를 단순한 규제가 아닌, 서비스의 안정성과 혁신 속도 사이에서 균형을 잡아주는 나침반으로 활용하는 것이 중요합니다. 측정 가능한 지표를 통해 막연한 불안감을 해소하고, 데이터에 기반한 의사결정을 내릴 때 비로소 지속 가능한 서비스 신뢰성을 확보할 수 있습니다.

옵저버빌리티site-reliability-engineeringresource-allocationservice-level-indicator+4

datadog·2026년 4월 7일·3분 읽기큐레이션 요약

자율형 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 평가 원문과 함께 데이터 보존 비용, 지원 환경, 기존 도구와의 연동성, 기능별 과금 구조를 별도로 확인하는 것이 좋습니다.

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

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

aws·2026년 4월 6일원문

AWS 주간 소식: AWS DevOps Agent 및 Security Agent 정식 출시(GA), 제품 수명 주기 업데이트 등 (2026년 4월 6일) | Amazon Web Services (새 탭에서 열림)

AWS는 최근 자율적으로 과업을 수행하는 '프론티어 에이전트'인 DevOps Agent와 Security Agent를 정식 출시하며 클라우드 운영 및 보안 자동화의 새로운 이정표를 제시했습니다. 이번 업데이트에는 주요 에이전트 서비스의 정식 출시(GA) 외에도 다양한 서비스의 라이프사이클 변경과 지속 가능성 보고 도구 등 운영 효율성을 높이기 위한 다각적인 기능들이 포함되었습니다. 특히 에이전트 기술을 통해 인시던트 대응 시간과 보안 테스트 비용을 획기적으로 줄인 고객사 사례를 통해 실질적인 기술적 이점이 증명되었습니다. ### AWS DevOps 및 Security 에이전트 정식 출시 * **AWS DevOps Agent**: 클라우드 운영 업무를 자율적으로 수행하며, 인시던트 조사 및 해결 시간을 단축하고 문제 발생을 사전에 방지합니다. 실제 고객사인 WGU는 문제 해결 시간을 수 시간에서 수 분으로 단축했으며, 평균 복구 시간(MTTR)을 최대 75%까지 감소시키는 성과를 거두었습니다. * **AWS Security Agent**: 개발 라이프사이클 전반에 걸쳐 지속적이고 문맥을 인식하는 모의 해킹(Penetration Testing)을 수행합니다. LG CNS와 같은 기업은 이를 통해 테스트 속도를 50% 이상 높이고 비용을 30% 절감했으며, 보안 탐지의 오탐률을 크게 낮추는 효과를 얻었습니다. * **환경 범용성**: 두 에이전트 모두 AWS 클라우드뿐만 아니라 멀티클라우드 및 온프레미스 환경에서도 작동하도록 설계되어, 인프라 위치에 상관없이 반복적인 운영 부담을 덜어줍니다. ### AWS 제품 라이프사이클 및 가용성 변경 사항 * **유지 관리(Maintenance) 서비스**: AWS App Runner, Audit Manager, CloudTrail Lake, Glue Ray jobs, Amazon SNS(Message Data Protection) 등 다수의 서비스가 유지 관리 단계로 전환되어 이에 따른 마이그레이션 가이드가 제공됩니다. * **일몰(Sunset) 예정 서비스**: Amazon RDS Custom for Oracle, Amazon WorkMail, Amazon WorkSpaces Thin Client, Amazon Chime SDK(Proxy Sessions) 등이 일몰 단계에 진입함에 따라 운영 중단을 최소화하기 위한 대체 서비스 확인이 필요합니다. * **지원 체계**: 가용성 변화가 운영에 미치는 영향을 고려하여 상세 문서와 AWS 서포트 팀을 통한 마이그레이션 지원을 강화했습니다. ### 기타 주요 기술 업데이트 및 모니터링 기능 * **컨테이너 및 컴퓨팅**: Amazon ECS 관리형 인스턴스를 위한 Managed Daemons 기능이 발표되었으며, Amazon Lightsail에는 최대 72 vCPU를 지원하는 컴퓨팅 최적화 인스턴스 번들이 추가되었습니다. * **AI 및 지속 가능성**: Amazon Bedrock AgentCore Evaluations가 정식 출시되었으며, 기업의 탄소 배출량을 통합 관리할 수 있는 'AWS Sustainability 콘솔'을 통해 Scope 1-3 보고가 가능해졌습니다. * **보안 및 관측성**: CloudFront에서 서명된 URL 및 쿠키에 SHA-256 지원을 시작했으며, Amazon EKS를 위한 OpenTelemetry 기반의 Container Insights 미리보기 버전이 출시되었습니다. 에이전트 중심의 AI 개발(Agentic AI)이 가속화됨에 따라 기업들은 단순 반복적인 운영 업무를 에이전트에게 위임하고 핵심 비즈니스 가치 창출에 집중할 수 있게 되었습니다. 특히 현재 사용 중인 서비스 중 라이프사이클 변경 대상이 있는지 정기적으로 점검하고, 새롭게 출시된 에이전트 도구들을 활용해 운영 비용과 인시던트 대응 시간을 최적화할 것을 권장합니다.

옵저버빌리티AWSDevOpssecurity+4