전체 글(93)
-
[장애대응] DB 복제 지연, 메모리 릭, 캐시 압력과 설정 버전 관리 정리
이번 내용은 각각 다른 장애처럼 보이지만 공통점이 있다. 모두 서비스가 당장 종료되지 않은 상태에서도 데이터 불일치, 응답 지연, 성능 저하를 일으키며 점차 큰 장애로 확산될 수 있다는 점이다.DB 복제 지연 → 오래된 데이터 조회메모리 릭 → 메모리 사용량 지속 증가캐시 압력 → 적중률 저하와 원본 저장소 부하 증가설정 관리 실패 → 잘못된 설정이 전체 서비스로 확산따라서 단순한 서버 생존 여부가 아니라 데이터 최신성, 자원 사용 추세, 캐시 상태, 설정 변경 이력까지 함께 모니터링해야 한다.1. DB 복제 구조서비스의 조회 성능과 가용성을 높이기 위해 하나의 DB만 사용하지 않고 Primary와 Replica로 구성할 수 있다.쓰기 요청 → Primary DB읽기 요청 → Replica DBPrima..
2026.08.24 -
[장애대응] 낙관적 락과 데드락 실습 정리
여러 요청이 동일한 데이터를 동시에 수정하면 갱신 손실과 같은 동시성 문제가 발생할 수 있다. 이를 제어하는 대표적인 방법으로 비관적 락과 낙관적 락이 있다.비관적 락이 데이터를 먼저 잠그는 방식이라면, 낙관적 락은 데이터 충돌이 자주 발생하지 않을 것이라고 가정하고 수정 시점에 충돌을 확인하는 방식이다.또한 락을 잘못 사용하면 두 트랜잭션이 서로의 락을 기다리는 데드락이 발생할 수 있다. 따라서 락을 적용하는 것만큼 락의 범위와 획득 순서를 설계하는 것도 중요하다.1. 낙관적 락이란?낙관적 락(Optimistic Lock)은 여러 트랜잭션의 충돌이 자주 발생하지 않을 것이라고 가정하는 동시성 제어 방식이다.데이터를 조회할 때 DB Lock을 획득하지 않는다. 대신 데이터의 버전 정보를 이용해 조회 이후..
2026.08.24 -
[장애대응] DB Lock과 비관적 락 실습 정리
여러 요청이 동시에 같은 데이터를 조회하고 수정하면 예상하지 못한 결과가 발생할 수 있다. 이를 동시성 문제라고 하며, 재고 차감이나 쿠폰 발급처럼 정확한 수량 관리가 필요한 기능에서는 반드시 고려해야 한다.이번 학습의 핵심은 다음과 같다.동시에 실행되는 트랜잭션이 같은 데이터를 변경하면데이터 정합성이 깨질 수 있다.DB Lock을 사용하면 특정 데이터에 대한 접근 순서를 제어해동시성 문제를 방지할 수 있다.1. 동시성 문제란?동시성 문제는 여러 요청이 같은 자원에 동시에 접근하면서 기대하지 않은 결과가 발생하는 현상이다.재고가 10개인 상품을 두 사용자가 동시에 1개씩 주문하는 상황을 생각해 보자.현재 재고: 10개사용자 A가 재고 10개 조회사용자 B가 재고 10개 조회사용자 A가 10 - 1 계산 ..
2026.08.24 -
[장애대응] 장애 예방 조치 정리
장애 대응이라고 하면 문제가 발생한 뒤 원인을 분석하고 서비스를 복구하는 모습을 먼저 떠올리게 된다. 하지만 가장 좋은 장애 대응은 장애가 발생할 가능성을 줄이고, 문제가 발생해도 전체 서비스로 확산되지 않도록 준비하는 것이다.장애를 완전히 없애기는 어렵다. 따라서 예방 조치의 목표는 다음과 같이 정리할 수 있다.장애 발생 가능성을 낮추고,장애를 조기에 발견하며,발생하더라도 피해 범위를 최소화하고,빠르게 복구할 수 있도록 준비하는 것1. 장애가 발생하는 주요 원인효과적인 예방 조치를 마련하려면 먼저 장애가 발생하는 원인을 이해해야 한다.대표적인 장애 원인은 다음과 같다.코드의 결함잘못된 설정배포 과정의 실수갑작스러운 트래픽 증가CPU, 메모리, 디스크 등 자원 부족데이터베이스 부하 및 커넥션 풀 고갈외부..
2026.08.24 -
[장애대응] 장애 복구와 후속 조치 및 사후 평가 개선 정리
장애 대응의 목표는 단순히 서버를 다시 정상 상태로 만드는 데서 끝나지 않는다. 사용자 영향을 최소화하면서 서비스를 빠르게 복구하고, 장애의 근본 원인을 분석해 같은 문제가 반복되지 않도록 개선하는 것까지가 전체 장애 대응 과정이다.1. 장애 대응의 전체 흐름장애 대응은 크게 다음과 같은 흐름으로 진행된다.장애 탐지 → 상황 전파 → 영향 범위 파악 → 긴급 복구 → 정상화 확인 → 근본 원인 분석 → 후속 조치 → 사후 평가 및 재발 방지장애가 발생한 순간에는 완벽한 원인 분석보다 사용자 영향을 줄이고 서비스를 안정화하는 것이 우선이다.서비스가 정상화된 이후에는 로그, 메트릭, 배포 이력 등을 기반으로 원인을 분석하고 재발 방지 대책을 수립해야 한다.2. 장애 복구의 우선순위장애가 발생하면..
2026.08.24 -
[장애대응] 모니터링과 장애 분석 및 진단 정리
장애 대응에서 중요한 것은 단순히 서버를 다시 실행하는 것이 아니다. 장애의 징후를 빠르게 발견하고, 수집된 데이터를 기반으로 원인을 좁힌 뒤, 재발하지 않도록 개선하는 과정까지 포함해야 한다.1. 모니터링이 필요한 이유서비스 장애는 완전히 예방하기 어렵다. 트래픽 급증, 외부 API 지연, 데이터베이스 문제, 메모리 부족 등 다양한 원인으로 언제든 장애가 발생할 수 있다.따라서 운영 환경에서는 다음 질문에 답할 수 있어야 한다.현재 서비스가 정상적으로 동작하고 있는가?사용자 요청은 정상적으로 처리되고 있는가?평소와 다른 이상 징후가 발생하고 있는가?장애가 발생했다면 어느 구간에서 문제가 생겼는가?장애 발생 전후로 어떤 변화가 있었는가?모니터링은 장애를 발견하기 위한 도구이면서, 장애 원인을 추적하기 위..
2026.08.24