Amazon OpenSearch Service백프레셔와 Admission Control에 대한이해와 클러스터 복원력 향상
“이 게시글은 AWS Big Data Blog에 작성된 “Improved resiliency with backpressure and admission control for Amazon OpenSearch Service” 블로그를 번역및 편집 하였습니다.” Amazon OpenSearch Service는 AWS가 관리하는 관리형 서비스로 클라우드 환경에서 OpenSearch 클러스터를 대규모로 보안, 배포 및 운영하는 것을 간단하게 만들어주는 관
Claude Code Action: 조직 전반의 코드 품질을 지키는 AI 코드 리뷰 플랫폼화
들어가며안녕하세요. LINE NEXT DevOps 팀에서 일하고 있는 이동원입니다. 저는 쿠버네티스 기반 인프라 운영과 CI/CD 구축, 모니터링 및 장애 대응 등 인프라 운영 관...
Kubernetes 기반 사내 개발 환경 구축기 2편: ARC와 CI/CD 인프라 고도화
HyperAccel의 CI/CD 인프라를 Actions Runner Controller(ARC) 기반으로 전면 재설계한 기술적 여정과 Vault JWT/Kubernetes Auth 이중 연동, 그리고 자체 개발한 Go 기반 Prometheus Exporter를 통한 파이프라인 관측성(Observability) 확보까지의 전 과정을 다룹니다.
2시 배포, 3시 오픈, 그리고 장애
장애 대응의 성패를 가르는 First Action: 우아한형제들의 장애 관리 라이프사이클
First Action에 따라 달라지는 장애 영향 우아한형제들의 2025년 장애를 돌아보면 인지는 비교적 빠른 편이었습니다. 그러나, 장애로 고객 경험의 악영향이 오래 이어진 사례들이 적지 않았습니다. 장애 대응 과정을 하나씩 다시 들여다보면 차이는 대부분 인지 이후 가장 먼저 어떤 조치를 취했는지, 즉 First Action(초동 조치)에서 시작됐습니다. 실제 내부적으로 약 70여 건 이상의 장애 사례를 분석한 결과, 첫 […] The pos
ALB Health Check Logs 지원
ALB
Amazon OpenSearch Service User Behavior Insights(UBI)로 사용자 행동 분석하기
대고객 서비스를 제공하는 워크로드의 경우 고객 경험을 지속적으로 향상시키기 위해서 다양한 이벤트나 프로모션을 진행합니다. 어떤 경우는 정기적으로 고객을 초청하여 인터뷰를 하며 서비스의 개선을 위한 피드백을 받기도 하고 어떤 경우는 웹 서비스상의 설문 조사를 통해 개선점을 수집하기도 합니다. 이커머스와 같은 서비스는 고객의 경험이 매출과 직결되는 대표적인 워크로드입니다. 따라서 다양한 고객의 피드백과 워크로드의 품질을 검토하기 위해서 해당 […]
이구위크 전시 장애 대응기: Redis에는 무슨 일이 있었나
MongoDB 커넥션 풀 모니터링과 알림 시스템 구축기
배달대행사 API 연동과 장애 대응 - 오늘드림 서비스 개발기
오늘 주문하면 오늘 받는 오늘드림 서비스, 이를 위해 뒤에서는 얼마나 바쁘게 돌아갈까요? 안녕하세요. 올리브영 배송 및 물류 스쿼드에서 백엔드 개발을 담당하고 있는 맹곰이입니다.✌️ 올리브영은 택배 배송과 오늘드림 두 가지 배송 서비스를 제공하고 있는데요. 이 중 택배 배송과 관련 있는 물류시스템과 데이터 전송 방식은 "올리브영 물류시스템에서는 데이터를 어떻게 주고 받을까?"라는 제목으로 지난 해에 소개드렸습니다. 오늘은 물류시스템만큼 많은 트
Lustre Changelog DR
목차 인사말 전통적인 rsync 방식의 한계와 파일 히스토리 기반 DR Lustre Changelog Changelog의 동작 원리 Changelog 활성화 및 확인 changelog_mask 이벤트 타입 Changelog 읽기 글루시스 DR 솔루션 주요 특징 시스템 구성 시스템 아키텍처 컴포넌트별 상세 기능 동작 원리 1. 이벤트 수집 단계 2. 동기화 처리 단계 3. 이벤트 처리 상태 관리 4. 예상치 못한 종료 시 복구 메커니즘 5. 오류
한계에 도달한 전시 서버, 그리고 우리의 해답
늘어나는 트래픽, 늘어나는 서버: 한계를 돌파하다 안녕하세요. 11번가 전시서비스개발팀에서 백엔드를 담당하고 있는 서장원입니다. 이번 글에서는 고객이 11번가에 처음 진입하는 관문인 전시서비스를 더 비용 효율적으로, 그리고 대량 트래픽 환경에서도 안정적으로 운영하기 위해 전시서비스개발팀의 김민교 님과 함께 고민하고 풀어나갔던 과정에서 다뤘던 주요 개선 포인트를 중심으로 소개합니다. 목차 미리보기: 핵심 개선 포인트 들어가며 트래픽의 꾸준한 증가
‘에러를 읽는 AI’ - Gemini와 Slack으로 만든 자동 오류 분석 시스템 Solomon
1. 들어가며 현재 사내의 로그 수집은 Heimdall과 OpenTelemetry(w. sigNoz)를 기반으로 이루어지고 있습니다. 오류 관제의 대부분은 Heimdall의 룰(rule) 에 따라 Slack 채널로 전달되며, 실제 장애 발생 시 관련 로그가 아래와 같이 공유 되고 있습니다. (이미지 참조) 그러나 기존 메시지 템플릿으로 모니터링을 진행하면서 다음과 같은 불편함이 있었습니다. 불필요하게 긴 Stack Trace (메시지가 너무 길
nginx 설정 없이 우아하게 서비스 점검하기 (上)
AccessBlock, 그 시작과 진화의 여정
nginx 설정 없이 우아하게 서비스 점검하기 (下)
리뉴얼된 AccessBlock
Lustre의 파일 create & open 과정 분석 - 2
들어가기 앞서 이번 블로그에서 설명할 내용은 지난 Lustre의 파일 create & open 과정 분석 -1의 후속 내용으로, 클라이언트에서 보낸 요청이 MDS에서 처리되는 과정과 이후 클라이언트의 후속 처리 과정을 담고 있습니다. 아래 그림에서 1번은 지난 1편 블로그의 내용이고, 2번은 본 편에서 설명할 내용입니다. 1편의 내용을 숙지하고, 2편을 보시면 전체 흐름을 이해하는 데 도움이 될 수 있습니다. 러스터의 전체적인 software
그 많던 메시지는 누가 다 먹었을까? 🧀
카카오뱅크 알림탭 시스템에서 발생한 동시성 문제를 해결한 경험을 다룬 글입니다. ShardingSphere 라이브러리로 인해 발생한 문제를 분석하고, 이를 재현 및 해결한 과정을 상세히 담았습니다. 또한, 핵심 라이브러리 관리의 중요성과 새롭게 도입한 관리 방법에 대해 설명합니다. 알림탭 시스템의 비정상적인 동작과 그 원인을 파악하는 여정을 다룬 만큼, 백엔드 개발과 시스템 안정성에 관심 있는 분들은 꼭 읽어보세요!
표준을 통한 마이크로 서비스의 Observability 구축기
저희는 Kubernetes 환경에서 동작하는 서비스의 증가와 최근 k8s 환경에서 대규모 서비스 오픈을 진행 했으며, 이에 대비하여 어떻게 마이크로 서비스에서 가시성을 확보할지, 또 문제가 생겼을 경우 어떻게 쉽게 문제를 확인하고 추적 할지에 대해 고민하게 되었습니다. 그 결과, OpenTelemetry와 SigNoz 조합을 활용한 Observability 환경을 구축하게 되었으며, 그 경험을 공유하고자 합니다. 시작하게 된 배경 기존 모니터링