[20250411] 장애 대응 전략 필기

1. 장애 대응 전략

1-1. 장애 대응의 중요성과 개발자의 역할
- 장애 발생 시 적절한 대응 전략을 수립해야 시스템 안정성을 유지하면서 사용자 경험에 미치는 영향 최소화 가능함
- 효과적인 장애 대응 전략은 명확한 절차와 프로세스 수립을 통해 문제를 신속하게 해결하는 데 초점을 둠
- 개발자는 개발 역할과 함께 문서화, 커뮤니케이션 능력 등 다각도에서 능력이 필요함
- 장애 발생 시 대응을 담당하는 개발자와 연락처 및 커뮤니케이션 채널을 미리 설정하고 연락해야 함
- 대응팀 구성에 시나리오 기반의 대응 전략을 포함시켜야 함

1-2. 대응 절차와 테스트의 중요성
- 대응 절차는 표준화된 운영 절차를 작성하여 일관된 대응을 보장해야 함
- 장애 유형별 표준화된 절차를 작성하거나, 긴급 상황 시 대응 매뉴얼을 만들어야 함
- 테스트와 시뮬레이션을 통해 대응팀의 준비 상태를 점검하고 개선할 수 있음
- 군대의 프로세스는 체계적이지만, 매뉴얼은 현장의 노하우를 반영한 결과물임
- 불필요하거나 무의미해 보이는 매뉴얼도 결국 사고를 통해 중요성이 드러나므로 반드시 따라야 함

1-3. 실시간 대응 전략과 임시 조치
- 장애 발생 시 즉각적인 대응 조치가 필요하며, 임시 조치 시행이 포함되어야 함
- 대응팀은 장애 유형별 또는 긴급 상황에 따라 대응 절차를 따르거나, 시나리오 기반 대응 전략을 세워야 함
- 대응 전략은 대응 절차에 따라 테스트하고 시뮬레이션하여 장애 대응 연습을 정기적으로 실시해야 함
- 개발자는 개발 역할뿐 아니라 문서화, 커뮤니케이션 등 다각도에서 능력이 필요함

2. 장애 대응 전략

2-1. 임시 조치와 범위 설정
- 사용자 주요 기능 사용하게끔 임시 조치 시행함
- 임시 조치 범위, 시뮬레이션 등 미리 작성해놓고 진행함
- 리소스 부족 시, 중요도 평가하여 주요 곳에 리소스 우선 배정함
- 로그를 통해 사이드 이펙트 최소화함
- 장애 대응 전략 중 하나로 커뮤니케이션 및 보고 중요함

2-2. 보고의 중요성
- 군대에서 보고 체계 중요함, 상급자에게 보고하는 것 중요함
- 에러 발생 시, 빠르게 파악하고 해결할 수 있도록 보고함
- 보고를 통해 인력 지원, 인프라 자원 지원 등을 진행할 수 있음
- 문제 상황을 빠르게 알리고, 투명하게 처리해 서비스 정상화시킴
- 문제 해결 시, 신뢰를 회복하고 고객에게 금전적 보상 가능함

2-3. 모니터링과 피드백
- 실시간 모니터링하여 장애 해결 후 지속적으로 모니터링함
- 메모리 부족 등 문제 발생 시, 계속 모니터링하여 해결 여부 확인함
- 고객과 사용자에게 빠르게 보고하고 피드백을 제공함
- 상급자와 커뮤니케이션 부서에 보고하여 해결책을 찾도록 함

3. 데이터베이스 장애 복구

3-1. 장애 복구의 이해
- 장애 발생 시, 데이터 복원을 통해 문제 해결 가능함
- 백업 복원을 통해 데이터 복구 여부를 판단함
- 최근 백업 파일을 확인하여 복원에 사용할 백업 파일 선택함
- 백업 파일 로드 후, 데이터 복원이 성공적으로 이루어졌는지 체크함
- 데이터 복원 시, 주요 테이블과 샘플로 복원되었는지 확인함

3-2. 애플리케이션 장애 복구
- 배포된 애플리케이션에 문제가 생기면, 코드 수정하여 재배포함
- 로그, 오류 메시지를 통해 문제 파악 및 코드 수정함
- 애플리케이션 재배포를 통해 정상적으로 동작하는지 테스트함
- 테스트를 통해 문제 해결 여부를 확인한 후, 모니터링 도구를 통해 지속 모니터링함

3-3. 캐시 관련 문제 해결
- 캐시에 문제가 생기면, 캐시 클리어 명령을 통해 문제 해결함
- 캐시 클리어를 통해 데이터 불일치와 성능 문제를 해결함
- 마스터 롤을 통해 데이터를 저장하고, 레디스 클리어 명령을 통해 데이터를 제거함
- 레디스 클리어는 강력한 기능이므로 특정 사용자나 개발자만 접근 가능하도록 제한함
- 레디스 클리어를 통해 데이터를 제거하면, 해당 데이터는 없어지지만, 해당 사용자 데이터는 남아있을 수 있음

4. 네트워크 장애 복구 방법

4-1. 장애 대응 방법 이해
- 시스템 장애 발생 시 DB 부하 증가로 인한 장애 포인트 발생 가능성을 인지함
- 사용자 데이터를 미리 쌓아 두어 DB 부하를 줄이는 방법을 강조함
- 디스크 정리 및 용량 확장을 통해 디스크 공간을 확보하고, 디스크 최적화를 수행함
- 디스크 정리 및 용량 확보를 위한 그라파나 모니터링의 중요성을 강조함
- 장애 대응 시, 시스템 재부팅을 통해 문제를 해결하고, 로그 모니터링을 통해 재부팅의 필요성을 확인함

4-2. 네트워크 장애 복구 접근
- 네트워크 장애 시 라우터와 스위치 등을 재시작하거나, 네트워크 구성 변경을 통해 문제를 해결함
- 네트워크 구성 오류를 확인하고, 필요한 경우 업데이트나 수정을 통해 문제를 해결함
- 네트워크 환경 설정과 파일 데이터를 업데이트하여 네트워크가 정상적으로 작동하는지 확인함
- AWS 리눅스 상에서 애플리케이션을 배포하여 네트워크 환경을 모니터링하고 정상 작동 여부를 확인함
- 네트워크 환경에 대한 지식을 쌓기 위해, AWS나 방화벽 등의 설정을 변경해 보는 것이 도움이 됨

4-3. 페이 로버 개념 및 접근
- 시스템 장애 발생 시 미리 준비된 스탠바이 시스템으로 자동 또는 수동으로 전환하여 서비스 지속성을 보장하는 방법임
- 라우터나 로드 밸런서를 사용하여 트래픽을 스탠바이 시스템으로 전환함
- 장애 대응 시, 주 시스템이 장애를 일으킬 경우를 대비한 대체 시스템으로 전환하여 운영함
- 장애 대응 시, 스탠바이 시스템은 주 시스템과 동일한 상태로 유지하도록 구성함

5. 네트워크 장애 대응

5-1. 네트워크 장애와 트래픽 전환
- 라우터 로드 밸런서는 네트워크 트래픽을 스탠바이 시스템으로 전환하는 역할을 함
- 장애 발생 시 라우터 설정을 변경하여 트래픽을 스탠바이 시스템으로 전환함
- 예를 들어, 철도 통로에 문제가 생겼을 때, 통로를 다른 방향으로 변경하여 문제를 해결할 수 있음
- 애플리케이션을 각각 따로 만들어 서비스로 제공하고, 이 인프라를 통해 사용자에게 응답함
- 페이로버는 같은 세트의 인프라를 사용해 시스템이 장애되어도 정상적으로 동작하도록 함

5-2. 페이로버의 장점과 단점
- 페이로버는 네트워크 인프라가 동일한 위치에 있으면 문제가 해결될 수 있음
- 인프라 비용이 많이 들고, 같은 위치에서 장애 발생 시 모든 트래픽을 전환해야 함
- 장애 상황 발생 시, 배포를 통해 다른 곳으로 트래픽을 이전하여 문제를 해결할 수 있음
- 단점으로는 인프라 비용과 제약 사항을 고려해야 함
- 인프라 비용이 많이 들고, 장애 발생 시 동일한 위치의 다른 인프라에 영향이 있을 수 있음

5-3. 페이로버의 구현
- 페이로버를 구현하기 위해 장애 대응 방법과 커뮤니케이션의 중요성을 강조함
- 페이로버는 네트워크 인프라의 사용량을 고려해야 하므로, 인프라 구성에 대한 고려가 필요함
- 기존 DB를 마스터-슬레이브나 다른 방법으로 보관하여 멀티-마스터 공유를 방지할 수 있음
- 비용 효율성을 고려하여 페이로버를 도입하고, 현업에서 사용되는 절차와 커뮤니케이션 기술을 설명함