신뢰성 향상을 위한 SLI/SLO 활용 1편 - SLI/SLO 프레임워크 및 서비스 상태 확인 도구 LINE Status 개발기
시작하며안녕하세요. SRE(Site Reliability Engineer)로 일하고 있는 어다희입니다. 저희 팀은 Media Platform SRE를 비롯해 글로벌 트래픽 관리 업...
기업 기술블로그의 Monitoring 관련 글 183개
시작하며안녕하세요. SRE(Site Reliability Engineer)로 일하고 있는 어다희입니다. 저희 팀은 Media Platform SRE를 비롯해 글로벌 트래픽 관리 업...
개요 Amazon EBS(Elastic Block Store)는 Amazon EC2(Elastic Compute Cloud)의 인스턴스에 영구 블록 스토리지를 제공하는 핵심 서비스입니다. 엔터프라이즈 환경에서 수백, 수천 개의 EBS 볼륨을 운영할 때, 각 볼륨의 성능을 실시간으로 모니터링하고 병목 지점을 신속하게 파악하는 것은 서비스 안정성과 직결되는 중요한 과제입니다. Amazon CloudWatch는 EBS 볼륨에 대해 다양한 성능 지표를
“이 게시글은 AWS Big Data Blog에 작성된 “Improved resiliency with backpressure and admission control for Amazon OpenSearch Service” 블로그를 번역및 편집 하였습니다.” Amazon OpenSearch Service는 AWS가 관리하는 관리형 서비스로 클라우드 환경에서 OpenSearch 클러스터를 대규모로 보안, 배포 및 운영하는 것을 간단하게 만들어주는 관
들어가며안녕하세요. LINE NEXT DevOps 팀에서 일하고 있는 이동원입니다. 저는 쿠버네티스 기반 인프라 운영과 CI/CD 구축, 모니터링 및 장애 대응 등 인프라 운영 관...
HyperAccel의 CI/CD 인프라를 Actions Runner Controller(ARC) 기반으로 전면 재설계한 기술적 여정과 Vault JWT/Kubernetes Auth 이중 연동, 그리고 자체 개발한 Go 기반 Prometheus Exporter를 통한 파이프라인 관측성(Observability) 확보까지의 전 과정을 다룹니다.
First Action에 따라 달라지는 장애 영향 우아한형제들의 2025년 장애를 돌아보면 인지는 비교적 빠른 편이었습니다. 그러나, 장애로 고객 경험의 악영향이 오래 이어진 사례들이 적지 않았습니다. 장애 대응 과정을 하나씩 다시 들여다보면 차이는 대부분 인지 이후 가장 먼저 어떤 조치를 취했는지, 즉 First Action(초동 조치)에서 시작됐습니다. 실제 내부적으로 약 70여 건 이상의 장애 사례를 분석한 결과, 첫 […] The pos
ALB
대고객 서비스를 제공하는 워크로드의 경우 고객 경험을 지속적으로 향상시키기 위해서 다양한 이벤트나 프로모션을 진행합니다. 어떤 경우는 정기적으로 고객을 초청하여 인터뷰를 하며 서비스의 개선을 위한 피드백을 받기도 하고 어떤 경우는 웹 서비스상의 설문 조사를 통해 개선점을 수집하기도 합니다. 이커머스와 같은 서비스는 고객의 경험이 매출과 직결되는 대표적인 워크로드입니다. 따라서 다양한 고객의 피드백과 워크로드의 품질을 검토하기 위해서 해당 […]
안녕하세요! FLO 데이터&추천팀의 Ken, Julian입니다. 저희 데이터&추천팀에서는 매일 수십 개의 Spark 배치 작업을 운영하고 있습니다. 추천 모델 학습, 사용자 행동 데이터 집계, 데이터마트 생성, 사용자 추천 데이터 추출 등 다양한 ETL 파이프라인이 Amazon EMR 클러스터에서 돌아가고 있죠. 그런데 이 Spark 작업들이 실패하면... 정말 머리가 아픕니다. "어? 새벽 3시에 돌린 작업이 실패했네? 로그 보러 가야겠다..
오늘 주문하면 오늘 받는 오늘드림 서비스, 이를 위해 뒤에서는 얼마나 바쁘게 돌아갈까요? 안녕하세요. 올리브영 배송 및 물류 스쿼드에서 백엔드 개발을 담당하고 있는 맹곰이입니다.✌️ 올리브영은 택배 배송과 오늘드림 두 가지 배송 서비스를 제공하고 있는데요. 이 중 택배 배송과 관련 있는 물류시스템과 데이터 전송 방식은 "올리브영 물류시스템에서는 데이터를 어떻게 주고 받을까?"라는 제목으로 지난 해에 소개드렸습니다. 오늘은 물류시스템만큼 많은 트
목차 인사말 전통적인 rsync 방식의 한계와 파일 히스토리 기반 DR Lustre Changelog Changelog의 동작 원리 Changelog 활성화 및 확인 changelog_mask 이벤트 타입 Changelog 읽기 글루시스 DR 솔루션 주요 특징 시스템 구성 시스템 아키텍처 컴포넌트별 상세 기능 동작 원리 1. 이벤트 수집 단계 2. 동기화 처리 단계 3. 이벤트 처리 상태 관리 4. 예상치 못한 종료 시 복구 메커니즘 5. 오류
늘어나는 트래픽, 늘어나는 서버: 한계를 돌파하다 안녕하세요. 11번가 전시서비스개발팀에서 백엔드를 담당하고 있는 서장원입니다. 이번 글에서는 고객이 11번가에 처음 진입하는 관문인 전시서비스를 더 비용 효율적으로, 그리고 대량 트래픽 환경에서도 안정적으로 운영하기 위해 전시서비스개발팀의 김민교 님과 함께 고민하고 풀어나갔던 과정에서 다뤘던 주요 개선 포인트를 중심으로 소개합니다. 목차 미리보기: 핵심 개선 포인트 들어가며 트래픽의 꾸준한 증가
1. 들어가며 현재 사내의 로그 수집은 Heimdall과 OpenTelemetry(w. sigNoz)를 기반으로 이루어지고 있습니다. 오류 관제의 대부분은 Heimdall의 룰(rule) 에 따라 Slack 채널로 전달되며, 실제 장애 발생 시 관련 로그가 아래와 같이 공유 되고 있습니다. (이미지 참조) 그러나 기존 메시지 템플릿으로 모니터링을 진행하면서 다음과 같은 불편함이 있었습니다. 불필요하게 긴 Stack Trace (메시지가 너무 길
AccessBlock, 그 시작과 진화의 여정
페이지 5 / 11 (총 183개)