기업 기술블로그의 Monitoring 관련 글 191개
이 글은 AWS Frontier Agents 시리즈의 세 번째이자 마지막 편입니다. 1편에서 배포 전 릴리스 리스크를 차단하고, 2편에서 배포 후 보안을 검증했다면, 이번 글은 운영 중인 워크로드의 비용 이상을 자동으로 조사하는 AWS FinOps Agent를 다룹니다. 비용 급증 알림은 받지만 “왜 올랐고 누구 책임인지”를 찾는 데는 며칠이 걸립니다. 이 글에서는 AWS FinOps Agent(Preview)가 AWS Cost Anomaly
AI 코딩 도구의 확산으로 Pull Request가 만들어지는 속도는 폭발적으로 빨라졌지만, 이를 검토하고 테스트하는 속도는 여전히 사람의 손에 머물러 있습니다. 이 글에서는 AWS Frontier Agents의 개념과 구성을 소개하고, AWS DevOps Agent에 새로 추가된 Release Management(Preview) 기능으로 코드 변경이 프로덕션에 도달하기 전에 릴리스 리스크를 자율적으로 검증하는 방법을 단계별로 살펴봅니다. >
이 글은 AWS Frontier Agents 시리즈의 두 번째 편입니다. 1편에서 다룬 배포 전 릴리스 검증에 이어, 이번 글은 배포된 애플리케이션의 보안을 검증하는 AWS Security Agent에 대한 내용을 다룹니다. 일반적으로 연 1~2회 수행하는 외주 침투 테스트만으로는 매일 배포되는 애플리케이션의 보안 변화를 따라가기 어렵습니다. AWS Security Agent는 이 문제를 해결하기 위해 소스 코드와 문서를 사전에 분석한 뒤, [
AI를 실제 업무에 적용하기 시작하면 새로운 질문들이 생깁니다.운영 데이터는 AI가 이해할 수 있는 형태로 어떻게 연결할지, 반복되는 개발 업무는 어디까지 자동화할지, 복잡해진 인프라의 이상 징후는 어떻게 더 빨리 찾아낼지 고민해야 합니다.이번 케클s피드는 이런 질문에 답을 찾아가는 kt cloud의 기술과 경험을 담았습니다. AIDC와 Cloud Platform부터 Observability, 개발환경 자동화, AI 코드 리뷰까지 개발과 운영
n8n Queue Mode에서 worker를 늘려도 처리량이 오르지 않는 이유를 k6와 Grafana로 측정했습니다. 슬롯 점유율 100%인데 CPU는 한 자릿수였던 원인은 task runner 한도였고, 러너 한도만 바꿔 처리량이 7.2배 차이 났습니다.
들어가며 수요 예측 시스템을 도입해 본 기업이라면 익숙한 패턴이 있습니다. 도입 첫해, 컨설턴트와 함께 수개월에 걸쳐 데이터를 정비하고 모델과 파라미터를 최적화합니다. 시스템은 그 시점의 비즈니스를 잘 반영하여 정확하게 예측합니다. 문제는 신규 채널에 진출하고, 프로모션 전략이 바뀌고, 신제품이 출시되고, 주력 상품의 라이프사이클이 끝날 때에 발생합니다. 비즈니스는 계속 변화하는데, 시스템은 구축 시점의 스냅샷에 멈춰 있습니다. 시스템의 예측을
.ktc-poster img { transition: transform .3s ease, box-shadow .3s ease; } .ktc-poster:hover img { transform: translateY(-4px); box-shadow:0 10px 22px rgba(0,154,135,0.22) !important; } .imageblock img { max-width:100% !important; height:auto !importan
@keyframes kttblink { 50% { opacity:0; } } .ktt-cursor { animation:kttblink 1.05s step-end infinite; } @keyframes kttlive { 0% { box-shadow:0 0 0 0 rgba(63,185,80,0.55); } 70% { box-shadow:0 0 0 6px rgba(63,185,80,0); } 100% { box-shadow:0 0 0 0 rgba
Amazon Bedrock 앞에 LLM 게이트웨이(이하 게이트웨이)를 두면 편의와 통제를 얻지만, 그 대가로 Amazon Bedrock이 보는 호출자 신원과 모델별 관측 지점이 게이트웨이 뒤로 흐려지는 사각지대가 생깁니다. 이 글은 잘 알려진 레퍼런스 아키텍처를 출발점으로, 그 사각지대를 Amazon Bedrock 네이티브 기능으로 보완하는 방법 (호출자 감사 추적과 모델별 관측 및 거버넌스)을 다룹니다. <Claude Code → LLM 게이
@keyframes kttblink { 50% { opacity:0; } } .ktt-cursor { animation:kttblink 1.05s step-end infinite; } @keyframes kttlive { 0% { box-shadow:0 0 0 0 rgba(63,185,80,0.55); } 70% { box-shadow:0 0 0 6px rgba(63,185,80,0); } 100% { box-shadow:0 0 0 0 rgba
이 글은 AWS Blog의 “PostgreSQL 18 on Amazon Aurora and Amazon RDS: Security, monitoring, and developer enhancements” by Nazneen Jafri, Sukhpreet Kaur Bedi, Ranjan Burman, and Baji Shaik 게시글을 번역한 글 입니다. 이 시리즈의 1부에서는 스킵 스캔 최적화, 향상된 EXPLAIN 출력, 자동 셀프 조인 제거,
들어가며 아임웹은 2026년 7월 10일 새벽, Amazon ElastiCache 기반 운영 캐시들을 Redis 6.x/Valkey 7.2 에서 Valkey 9.1로 업그레이드했습니다. 대표 범용 캐시는 SSR(Server-Side Rendering) 경로와 여러 서비스 로직에서 반복적으로 조회되는 캐시로, 비교 구간 3.5시간 동안 7억 건 이상의 명령어를 처리했습니다. 업그레이드 이후 전날 동일 시간대 대비 전체 CPU는 86.6%, Eng
@keyframes kttblink { 50% { opacity:0; } } .ktt-cursor { animation:kttblink 1.05s step-end infinite; } @keyframes kttlive { 0% { box-shadow:0 0 0 0 rgba(63,185,80,0.55); } 70% { box-shadow:0 0 0 6px rgba(63,185,80,0); } 100% { box-shadow:0 0 0 0 rgba
들어가며: 관측성 데이터는 많아졌지만, 분석은 여전히 어렵습니다안녕하세요. LY Corporation에서 Home 서비스의 안정성을 책임지고 있는 Home SRE(Site Reli...
페이지 2 / 11 (총 191개)
