devBlog
기업 기술블로그의 Monitoring 관련 글 191개
안녕하세요! 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
AccessBlock, 그 시작과 진화의 여정
들어가기 앞서 이번 블로그에서 설명할 내용은 지난 Lustre의 파일 create & open 과정 분석 -1의 후속 내용으로, 클라이언트에서 보낸 요청이 MDS에서 처리되는 과정과 이후 클라이언트의 후속 처리 과정을 담고 있습니다. 아래 그림에서 1번은 지난 1편 블로그의 내용이고, 2번은 본 편에서 설명할 내용입니다. 1편의 내용을 숙지하고, 2편을 보시면 전체 흐름을 이해하는 데 도움이 될 수 있습니다. 러스터의 전체적인 software
카카오뱅크 알림탭 시스템에서 발생한 동시성 문제를 해결한 경험을 다룬 글입니다. ShardingSphere 라이브러리로 인해 발생한 문제를 분석하고, 이를 재현 및 해결한 과정을 상세히 담았습니다. 또한, 핵심 라이브러리 관리의 중요성과 새롭게 도입한 관리 방법에 대해 설명합니다. 알림탭 시스템의 비정상적인 동작과 그 원인을 파악하는 여정을 다룬 만큼, 백엔드 개발과 시스템 안정성에 관심 있는 분들은 꼭 읽어보세요!
저희는 Kubernetes 환경에서 동작하는 서비스의 증가와 최근 k8s 환경에서 대규모 서비스 오픈을 진행 했으며, 이에 대비하여 어떻게 마이크로 서비스에서 가시성을 확보할지, 또 문제가 생겼을 경우 어떻게 쉽게 문제를 확인하고 추적 할지에 대해 고민하게 되었습니다. 그 결과, OpenTelemetry와 SigNoz 조합을 활용한 Observability 환경을 구축하게 되었으며, 그 경험을 공유하고자 합니다. 시작하게 된 배경 기존 모니터링
Database Insights
안녕하세요. 포스타입 기술팀의 백엔드 엔지니어 김안선 입니다. 포스타입은 대량의 요청을 실시간으로 처리하는 서비스 입니다. 대규모 서비스 운영에서 데이터베이스의 안정성은 곧 서비스의 품질과도 직결되는 요소인데요. 데이터베이스는 마치 시스템의 심장과도 같아서 사용자가 늘어남에 따라 데이터를 혈액처럼 끊임없이 공급하고 생성합니다. 하지만 급격한 혈류의 증가로 처리 속도가 저하된다면 시스템의 장애를 야기할 수도 있습니다. 오늘은 포스타입을 지탱하는
IMQA가 고객 중심 시스템을 갖추고 고객 접점에서 빠른 응대와 안정적인 시스템을 운영하는 라이나생명과 함께합니다.
오늘은 BESPIN GLOBAL SRE실 지봉근님이 작성해주신 '[WhaTap] RDS Failover / Reboot 관제 2 - RDS Failover'에 대해 소개해드리도록 하겠습니다. The post [WhaTap] RDS Failover/Reboot 관제 2 – RDS Failover appeared first on BESPIN Tech Blog.
오늘은 BESPIN GLOBAL SRE실 지봉근님이 작성해주신 '[WhaTap] RDS Failover / Reboot 관제 1 - Describe RDS' 에 대해 소개해드리도록 하겠습니다. The post [WhaTap] RDS Failover / Reboot 관제 1 – Describe RDS appeared first on BESPIN Tech Blog.
페이지 6 / 11 (총 191개)