240820 TIL

송형근·2024년 8월 20일

DB Lock TIL 공부 알고리즘 예방 조치 장애 대응 장애 복구 후속 조치

TIL

목록 보기

17/43

스파르타 Java 단기 심화 과정

코드카타

프로그래머스 133502 햄버거 만들기

https://school.programmers.co.kr/learn/courses/30/lessons/133502

— 문제 설명

햄버거 가게에서 일을 하는 상수는 햄버거를 포장하는 일을 합니다. 함께 일을 하는 다른 직원들이 햄버거에 들어갈 재료를 조리해 주면 조리된 순서대로 상수의 앞에 아래서부터 위로 쌓이게 되고, 상수는 순서에 맞게 쌓여서 완성된 햄버거를 따로 옮겨 포장을 하게 됩니다. 상수가 일하는 가게는 정해진 순서(아래서부터, 빵 – 야채 – 고기 - 빵)로 쌓인 햄버거만 포장을 합니다. 상수는 손이 굉장히 빠르기 때문에 상수가 포장하는 동안 속 재료가 추가적으로 들어오는 일은 없으며, 재료의 높이는 무시하여 재료가 높이 쌓여서 일이 힘들어지는 경우는 없습니다.

예를 들어, 상수의 앞에 쌓이는 재료의 순서가 [야채, 빵, 빵, 야채, 고기, 빵, 야채, 고기, 빵]일 때, 상수는 여섯 번째 재료가 쌓였을 때, 세 번째 재료부터 여섯 번째 재료를 이용하여 햄버거를 포장하고, 아홉 번째 재료가 쌓였을 때, 두 번째 재료와 일곱 번째 재료부터 아홉 번째 재료를 이용하여 햄버거를 포장합니다. 즉, 2개의 햄버거를 포장하게 됩니다.

상수에게 전해지는 재료의 정보를 나타내는 정수 배열 ingredient가 주어졌을 때, 상수가 포장하는 햄버거의 개수를 return 하도록 solution 함수를 완성하시오.

— 제한 조건

1 ≤ ingredient의 길이 ≤ 1,000,000
ingredient의 원소는 1, 2, 3 중 하나의 값이며, 순서대로 빵, 야채, 고기를 의미합니다.

— 입출력 예

ingredient	result
[2, 1, 1, 2, 3, 1, 2, 3, 1]	2
[1, 3, 2, 1, 2, 1, 3, 1, 2]	0

입출력 예 #1

문제 예시와 같습니다.

입출력 예 #2

상수가 포장할 수 있는 햄버거가 없습니다.

— 문제 풀이

class Solution {
    public int solution(int[] ingredient) {
        StringBuilder sb = new StringBuilder();
        int answer = 0;
        for(int i=0;i<ingredient.length;i++){
            sb.append(ingredient[i]);
            if(sb.length()>=4&&sb.substring(sb.length()-4).equals("1231")){
                sb.delete(sb.length()-4,sb.length());
                answer++;
            }
        }
        
        return answer;
    }
}

장애 대응

장애 대응 계획 수립

대응팀 구성
- 역할 및 책임 정의 : 장애 발생 시 즉각적으로 대응할 수 있도록 팀 내의 각 역할과 책임을 명확히 정의
- 연락처 및 커뮤니케이션 채널 : 대응팀의 연락처와 커뮤니케이션 채널을 사전에 설정하여 신속한 협업이 가능하도록 함
대응 절차 수립
- 표준 운영 절차(SOP) 작성 : 장애 유형별로 표준화된 운영 절차를 작성하여 일관된 대응을 보장함
- 긴급 대응 매뉴얼 : 긴급 상황에서 사용할 수 있는 대응 매뉴얼을 작성하여 신속한 대응을 지원함
- 시나리오 기반 대응 전략 : 다양한 장애 시나리오에 대비하여 구체적인 대응 전략을 수립함
사전 테스트 및 시뮬레이션
- 장애 대응 연습 : 정기적으로 장애 대응 연습을 실시하여 대응팀의 준비 상태를 점검하고 개선함
- 시뮬레이션 테스트 : 장애 시나리오를 시뮬레이션하여 대응 전략의 효과를 검증하여 개선점을 찾음

실시간 대응 전략

즉각적인 대응 조치
- 임시 조치 시행 : 장애의 영향을 즉시 줄이기 위한 임시 조치를 시행하여 시스템의 정상 작동을 복구함
- 장애의 원인 격리 : 장애의 근본 원인을 격리하고 영향을 최소화하여 다른 시스템 요소에 영향을 미치지 않도록 함
커뮤니케이션 및 보고
- 상황 보고 : 장애 발생 시 상황을 명확히 파악하고 이해관계자에게 즉각적으로 보고함
- 외부 커뮤니케이션 : 고객 및 사용자에게 장애 상황과 대응 계획을 명확히 전달하여 불안감을 줄임
모니터링 및 피드백
- 실시간 모니터링 : 장애 해결 후에도 지속적으로 모니터링하여 문제가 완전히 해결되었는지 확인함
- 피드백 수집 : 장애 대응 과정에서 얻은 피드백을 수집하여 대응 전략에 반영

장애 복구

DB 장애 복구

백업 복원 : 장애 발생 시 가장 일반적인 복구 방법. 정기적으로 백업된 데이터를 이용해 DB를 원래 상태로 복구함
- 백업 파일 확인 : 장애 발생 시 가장 최근의 백업 파일을 확인하여 복원에 사용할 백업 파일을 선택함
- 백업 파일 로드 : DB에 백업 파일을 로드하여 DB 복원 절차를 시작함
- 무결성 검증 : 복원된 데이터가 손상되지 않았는지, 데이터 무결성을 검증함. 이를 위해 DB의 중요한 테이블과 데이터 샘플을 검토함

App 장애 복구

App 재배포 : App이 정상적으로 작동하지 않는 경우, App을 재배포하여 문제를 해결함. 이는 코드 변경이나 구성 오류를 수정하는 데 효과적임
- 문제 원인 파악 : App 로그와 오류 메시지를 통해 문제 원인을 파악함
- 코드 수정 : 문제를 해결하기 위해 코드를 수정함
- App 재배포 : 수정된 코드를 배포하여 App 재시작
- 테스트 및 검증 : App이 정상적으로 작동하는지 테스트
캐시 클리어 : 캐시 관련 문제가 발생한 경우, 캐시를 비우는 작업을 통해 문제를 해결할 수 있음. 캐시 클리어는 주로 데이터 불일치나 성능 문제를 해결하는 데 사용됨
- 캐시 문제 진단 : 캐시 히트율과 관련된 문제를 파악함
- 캐시 클리어 명령 실행 : 캐시를 비우기 위한 명령을 실행함
- 시스템 상태 확인 : 캐시 클리어 후 시스템의 성능과 데이터 일관성을 확인함

시스템 장애 복구

시스템 재부팅 : 시스템이 비정상적인 상태일 때, 재부팅을 통해 문제를 해결. 이는 메모리 누수, 리소스 부족 등의 문제를 해결하는 데 효과적임
- 재부팅 필요성 확인 : 시스템 로그와 모니터링 도구를 통해 재부팅 필요성을 확인함
- 시스템 재부팅 : 시스템을 재부팅하여 모든 서비스와 App을 다시 시작
- 서비스 상태 검증 : 재부팅 후 시스템의 모든 서비스가 정상적으로 작동하는지 확인
디스크 정리 : 디스크 공간 부족으로 인한 시스템 성능 저하나 장애를 해결하기 위해 디스크 정리를 수행함
- 디스크 상태 확인 : 디스크 사용량을 확인하여 정리 필요성을 평가
- 불필요한 파일 삭제 : 로그 파일, 임시 파일 등 불필요한 파일을 삭제하여 디스크 공간 확보
- 디스크 최적화 : 디스크 조각 모음이나 최적화 작업을 수행하여 디스크 성능을 향상시킴

네트워크 장애 복구

네트워크 장비 재시작 : 네트워크 장애가 발생한 경우, 라우터, 스위치 등의 네트워크 장비를 재시작하여 문제를 해결함
- 장비 상태 확인 : 네트워크 장비의 상태를 확인하여 재시작 필요성을 평가
- 네트워크 장비 재시작 : 네트워크 장비를 재시작하여 연결을 복원
- 네트워크 상태 확인 : 재시작 후 네트워크 연결 상태와 성능을 확인함
네트워크 구성 변경 : 잘못된 네트워크 구성으로 인한 장애를 해결하기 위해 네트워크 구성을 수정함
- 구성 오류 확인 : 네트워크 구성 파일이나 설정을 확인하여 오류를 파악함
- 구성 변경 : 필요한 구성을 수정하거나 업데이트함
- 네트워크 상태 확인 : 구성 변경 후 네트워크 상태를 모니터링하여 정상 동작을 확인함

페일오버 (Failover)

페일오버는 주 시스템에 장애가 발생했을 때, 미리 준비된 스탠바이 시스템으로 자동 또는 수동으로 전환하여 서비스의 지속성을 보장하는 방법. 이 과정에서 라우터 또는 로드 밸런서를 사용하여 트래픽을 스탠바이 시스템으로 전환함
주요 구성 요소
- 주 시스템(Primary System) : 정상적으로 운영되는 시스템. 이 시스템에 장애가 발생한 경우 스탠바이 시스템으로 전환됨
- 스탠바이 시스템(Standby System) : 주 시스템이 장애를 일으킬 경우를 대비해 준비된 대체 시스템. 이 시스템은 주 시스템과 동일한 상태를 유지하도록 구성됨
- 라우터/로드 밸런서 : 네트워크 트래픽을 주 시스템에서 스탠바이 시스템으로 전환하는 역할을 함. 장애가 발생하면 라우터 설정을 변경하여 트래픽을 스탠바이 시스템으로 전환

후속 조치

장애 원인 분석

근본 원인 분석 (Root Cause Analysis)
장애의 근본 원인을 파악하기 위해 각종 로그, 메트릭, 시스템 상태를 종합적으로 분석함
장애의 재발 방지를 위해 원인 분석 결과를 문서화하고, 이해관계자와 공유함
5 Whys 기법 : 문제의 근본 원인을 파악하기 위해 “왜?”라는 질문을 다섯 번 반복하여 근본 원인에 도달함
- 예시
  - 문제 : App 배포에 실패
  - Why 1: 새로운 기능을 포함한 코드가 배포 프로세스 중에 충돌이 발생했다.
  - Why 2: 충돌이 발생한 코드는 충분히 테스트되지 않았다.
  - Why 3: 코드가 테스트 환경에서만 테스트되었고, 실제 배포 환경에서는 테스트되지 않았다.
  - Why 4: 배포 자동화 스크립트에 문제가 있어, 실제 배포 환경에서 테스트가 수행되지 않았다.
  - Why 5: 배포 자동화 스크립트가 최신 코드 변경 사항을 반영하도록 업데이트되지 않았다.
피시본 다이어그램 : 문제의 원인을 시각적으로 분석하여 관련 요소들을 식별
- 예시
해결책 도출 및 실행
- 단기 해결책 : 문제의 즉각적인 완화를 위한 단기 해결책을 도출하고 실행
- 장기 해결책 : 문제의 재발 방지를 위한 근본적인 장기 해결책을 설계하고 실행
- 테스트 및 검증 : 해결책을 테스트하고 검증하여 문제 해결의 효과를 확인함
장애 경과 분석
- 장애 발생부터 해결까지의 경과를 상세히 기록함
- 장애가 발생한 시점, 대응 조치, 결과 등을 시간 순으로 정리하여 향후 참조할 수 있도록 해야함

장애 대응 기록

대응 조치 기록
- 장애 발생 시 수행한 모든 대응 조치와 결과를 기록
- 대응 과정에서 발생한 문제점과 개선 사항을 명확히 문서화해야함
커뮤니케이션 로그
- 장애 대응 중 이해관계자와 주고받은 커뮤니케이션 내용을 기록함
- 문제 해결에 기여한 주요 커뮤니케이션과 결정을 문서화함

후속 조치 계획

재발 방지 대책 수립

시스템 개선
- 장애 원인 분석 결과를 바탕으로 시스템의 취약점을 개선
- 하드웨어 업그레이드, 소프트웨어 패치, 구성 변경 등을 통해 시스템 안정성을 높임
프로세스 개선
- 장애 대응 프로세스를 재검토하고, 개선 사항을 반영하여 SOP(Standard Operating Procedure)를 업데이트함
- 장애 발생 시 대응 속도를 높일 수 있도록 프로세스를 최적화함

교육 및 훈련

교육 프로그램 운영
- 장애 대응 관련 교육 프로그램을 운영하여 팀원들의 대응 역량을 강화
- 신규 팀원 교육과 정기적인 리프레쉬 교육을 통해 모든 팀원이 최신 대응 절차와 도구에 익숙해지도록 함
훈련 시뮬레이션
- 정기적으로 장애 대응 시뮬레이션을 실시하여 실제 상황 대비
- 시뮬레이션 결과를 바탕으로 팀의 대응 능력을 평가하고, 필요한 개선 조치를 취함

문서화 및 공유

문서 업데이트
- 장애 발생 후 모든 관련 문서를 최신 상태로 유지
- 장애 보고서, 원인 분석 문서, 대응 절차 등을 업데이트하여 향후 참조할 수 있도록 해야함
지식 공유
- 장애 대응 경험을 팀 내에서 공유하여 집단 지식을 향상시킴
- 지식 공유 세션을 정기적으로 개최하고, 대응 경험과 교훈을 팀원들과 공유함

사후 평가 및 개선

사후 평가

평가 회의
- 장애 해결 후 사후 평가 회의를 개최하여 대응 과정 전반을 평가함
- 대응 속도, 정확성, 커뮤니케이션 등 다양한 측면에서 평가하여 개선 사항을 도출함
성과 분석
- 장애 대응 성과를 객관적으로 분석하고, 목표 달성 여부를 평가함
- 대응 목표를 재설정하고, 다음 장애 발생 시 더 나은 성과를 낼 수 있도록 준비

지속적인 개선

피드백 반영
- 사후 평가 결과와 팀원들의 피드백을 반영하여 지속적으로 대응 전략을 개선함
- 피드백 수집 채널을 운영하여 팀원들의 의견을 적극적으로 수렴
기술 도입
- 최신 기술과 도구를 도입하여 장애 대응 역량을 강화
- 모니터링, 자동화, 분석 도구 등을 활용하여 대응 효율성을 높임

예방 조치

안정적인 아키텍처 설계

고가용성 아키텍처 : 마이크로서비스, 클러스터링, 로드 밸런싱 등을 활용한 고가용성 설계 기법
무중단 배포 전략 : 블루-그린 , 카나리 등 서비스의 중단 없이 배포를 수행

클러스터링 (Clustering)

클러스터링은 여러 서버를 하나의 시스템처럼 구성하여 고가용성과 로드 밸런싱을 제공하는 방법. 클러스터 내의 각 서버는 동일한 데이터를 공유하고, 하나의 서버에 장애가 발생하면 다른 서버가 그 역할을 자동으로 수행
장점
- 고가용성 : 장애가 발생해도 서비스 중단 없이 운영 가능
- 로드 밸런싱 : 트래픽을 여러 서버에 분산하여 처리 능력 향상
- 자동 복구 : 한 서버가 장애가 발생하면 다른 서버가 자동으로 서비스 수행

로드 밸런싱

네트워크 트래픽을 여러 서버에 분산시키는 기술. 각 서버의 부담을 줄이고, 특정 서버에 장애가 발생해도 다른 서버가 트래픽을 처리할 수 있게 함
장점
- 확장성 : 필요에 따라 서버를 추가하여 시스템 확장 가능
- 가용성 : 한 서버에 장애가 발생해도 다른 서버가 트래픽을 처리
- 성능 향상 : 트래픽 분산을 통해 서버 응답 시간 개선

지오 리던던시 (Geo-Redundancy)

데이터를 지리적으로 떨어진 여러 장소에 저장하여, 한 지역에서 발생한 장애에도 다른 지역에서 서비스를 지속할 수 있도록 하는 방법
장점
- 재난 복구 : 지역적 재난 발생 시에도 서비스 지속 가능
- 가용성 : 여러 지역에 분산된 데이터로 가용성 향상
- 데이터 접근성 : 지리적으로 분산된 사용자에게 빠른 데이터 접근 제공

성능 및 용량 계획

캐싱 전략 : CDN, 메모리 캐싱을 활용한 성능 최적화
용량 계획 : 트래픽 예측 및 자원 확장을 위한 용량 계획 기법
성능 테스트 및 벤치마킹 : JMeter, Gatling 등 도구를 활용한 성능 테스트 기법

보안 취약점 관리

취약점 스캐닝 : OWASP ZAP, Nessus 등 도구를 사용한 정기적인 취약점 스캔
보안 패치 관리 : 자동화된 보안 패치 적용 및 관리 프로세스
침입 탐지 및 방어 시스템(IDS/IPS) : 네트워크 및 App 보안을 위한 IDS/IPS 시스템 구축

장애 대응 프로세스 개선

DevOps 및 CI/CD 파이프라인

지속적 통합 및 배포 : Jenkins, GitLab CI/CD 등을 활용한 자동화 파이프라인 구축
컨테이너 오케스트레이션 : Kubernetes를 통한 App 배포 및 관리

문제 해결 기법

장애 대응 훈련 : 장애 상황을 가정하여 훈련. 결과를 통해 부족한점 파악하고 보완
사후 평가 : 시스템 장애, 사고, 프로젝트 실패 등 특정 사건이 발생한 후, 그 사건을 분석하고 평가하는 과정. 사건의 원인과 영향을 이해하고, 향후 유사한 문제가 발생하지 않도록 개선 방안을 도출하는 데 목적이 있음

오픈소스 및 솔루션

대시보드 및 리포팅 : Grafana, Kibana를 통한 실시간 대시보드 및 리포팅 시스템 구축
클라우드 기반 장애 대응 : AWS, GCP, Azure의 클라우드 네이티브 솔루션을 활용한 장애 대응
서버리스 아키텍처 : 서버리스 컴퓨팅을 통한 비용 절감 및 확장성 향상
Multi-Cloud 전략 : 다중 클라우드 환경에서의 장애 예방 및 대응 전략

실습 시나리오

장애 시나리오 재현 : 실제 환경에서 장애 시나리오를 재현하고 대응 연습
문제 해결 실습 : 다양한 장애 상황에서의 문제 해결 능력 강화

DB Lock

DB Lock 이란?

DB Lock은 데이터베이스에서 여러 트랜잭션이 동시에 같은 데이터에 접근할 때, 데이터의 무결성을 보장하기 위해 사용되는 메커니즘
한 트랜잭션이 특정 데이터에 대해 작업을 하고 있을 때 다른 트랜잭션이 그 데이터에 접근하지 못하도록 잠그는 것
이로써 데이터의 일관성을 유지하고, 동시에 발생할 수 있는 충돌을 방지

DB Lock의 필요성

DB는 여러 사용자나 시스템이 동시에 데이터를 읽고 쓰는 환경에서 운영됨. 이런 환경에서 문제가 발생할 수 있는 대표적인 사례는 다음과 같음
- Dirty Read : 한 트랜잭션이 데이터를 수정 중일 때 다른 트랜잭션이 그 데이터를 읽는 상황. 첫번째 트랜잭션이 롤백된다면, 두 번째 트랜잭션은 잘못된 데이터를 읽은 것이 됨
- Non-repeatable Read : 한 트랜잭션이 데이터를 읽은 후, 다른 트랜잭션이 그 데이터를 수정하고 커밋하여 첫 번재 트랜잭션이 동일한 데이터를 다시 읽을 때 값이 달라지는 상황
- Lost Update : 두 개의 트랜잭션이 동시에 같은 데이터를 수정하려 할 때, 한 트랜잭션의 수정 내용이 다른 트랜잭션에 의대 덮어씌워져 사라지는 상황
DB 락을 통해 데이터에 대한 접근을 제어하면, 위와 같은 상황에서 발생할 수 있는 데이터 무결성 문제를 예방할 수 있음

DB 락의 종류

공유 락 (Shared Lock, S Lock)
- DB에서 데이터를 읽을 때 사용됨. 여러 트랜잭션이 동시에 같은 데이터를 읽을 수 있지만, 공유 락이 걸린 동안에는 데이터를 수정할 수 없음
- 예시
  - 고객 정보 시스템에서 여러 직원이 동시에 같은 고객의 정보를 조회할 수 있지만, 조회 중에는 그 정보를 수정할 수 없음
배타 락 (Exclusive Lock, X Lock)
- 데이터를 수정할 때 사용됨. 배타 락이 걸린 데이터는 다른 트랜잭션이 읽거나 수정할 수 없음.
- 예시
  - 재고 관리 시스템에서 한 직원이 특정 상품의 재고를 수정하고 있을 때, 다른 직원이 그 상품의 재고를 조회하거나 수정하지 못하게 하는 상황
비관적 락 (Pessimistic Locking)
- 데이터를 읽을 때부터 락을 걸어 다른 트랜잭션이 접근하지 못하도록 하는 방식
- 예시
  - 은행 시스템에서 한 사용자가 특정 계좌의 잔액을 조회하고 수정하려는 시나리오에서, 다른 사용자가 이 계좌에 접근하지 못하게 하는 방식
낙관적 락 (Optimistic Locking)
- 데이터를 수정하기 전까지 락을 걸지 않고, 수정 시점에만 충돌을 확인하는 방식. 주로 데이터의 버전 번호를 사용하여 동시성 문제를 해결함
- 예시
  - 온라인 쇼핑몰에서 여러 사용자가 동시에 동일한 상품의 정보를 수정할 수 있는 상황에서, 수정 시점에 충돌을 감지하여 해결하는 방식
명명된 락 (Named Lock)
- DB에서 특정 이름으로 락을 설정하여, 동시에 하나의 프로세스만 특정 리소스에 접근하도록 하는 방식. 주로 특정 리소스나 작업에 대한 접근을 직관적으로 제어하기 위해 사용됨
- 예시
  - PostgreSQL에서 특정 보고서를 생성하는 작업에 대해 이름 기반으로 락을 걸어, 두 명의 사용자가 동시에 같은 보고서를 생성하지 못하게 하는 상황
분산 락 (Distributed Lock)
- 여러 시스템이나 인스턴스에서 동시에 동일한 자원에 접근할 때, 자원의 일관성을 유지하기 위해 사용되는 락. Redis와 같은 분산 시스템을 사용하여 구현됨
- 예시
  - 온라인 예약 시스템에서 여러 서버 인스턴스가 동일한 좌석을 동시에 예약하지 못하도록 하는 상황

송형근

기록을 남겨보자

이전 포스트

240819 TIL

다음 포스트