📌 Outline

<aside> 💡 콘서트 예약 서비스 시나리오에서 발생할 수 있는 장애를 예측하고 대응방안을 조사합니다.

</aside>

❓장애란

<aside> 💡 특정 상황이 발생해 현재 운영 중인 서버가 정상 작동이 불가능한 상태입니다.

</aside>

• 장애는 언제나 발생할 수 있으므로 서비스 운영 시 발생할 수 있는 문제를 미리 예측하고, 적절한 대비책을 마련함으로써 서비스 가용성을 최대한 확보하는 것이 중요합니다.
• 내부 서비스와 외부 서비스에서 발생할 수 있는 다양한 장애 상황과 이에 대한 해결 및 대처 방안을 파악합니다.

1️⃣ 내부 서비스 장애

• 애플리케이션 장애
  1. 메모리 누수
     • 상황 : 사용자가 콘서트 티켓 예약 페이지에 접근할 때마다 세션 데이터가 메모리에 쌓이지만, 사용자가 예약을 완료하거나 페이지를 벗어날 때 이 메모리가 해제되지 않는 상황.
     • 설명 : 애플리케이션이 메모리를 할당한 후 이를 해제하지 않아, 시간이 지남에 따라 사용 가능한 메모리가 감소합니다. 이로 인해 시스템 성능이 저하되고, 최악의 경우 서비스가 중단될 수 있습니다.
     • 대응 방안
       • 숏텀 : 문제 발생 시 서비스 중단을 최소화하기 위해, 메모리 누수 문제를 감지하고 긴급 재시작을 수행하는 리스타트 스크립트를 활용합니다.
       • 미드텀 : 메모리 사용량을 모니터링하는 시스템을 강화하여, 메모리 누수 발생 시 조기 경고를 받을 수 있도록 설정합니다.
       • 롱텀 : 애플리케이션의 메모리 관리 방식을 근본적으로 개선하여, 메모리 누수가 발생하지 않도록 시스템을 재설계하고, 메모리 효율성을 높입니다.
  2. CPU 과부하
     • 상황 : 대규모 콘서트의 좌석 정보를 불러오는 작업이 비효율적인 쿼리로 인해 CPU를 과도하게 사용, 전체 시스템의 응답 속도가 느려지는 상황.
     • 설명 : 애플리케이션에서 특정 작업이나 무한 루프가 CPU 자원을 과도하게 사용하여 시스템의 다른 작업이 느려지거나 중단됩니다.
     • 대응 방안
       • 숏텀 : CPU 사용량이 과도하게 증가한 경우, 비필수적인 백그라운드 작업을 일시 중단하거나, 우선순위를 낮춰 주요 예약 처리 작업에 우선순위를 부여합니다.
       • 미드텀 : CPU를 과도하게 사용하는 쿼리나 작업을 최적화하여 CPU 사용량을 감소시킵니다.
       • 롱텀 : 애플리케이션의 전반적인 아키텍처를 재설계하여, 특정 작업에 의한 CPU 과부하가 발생하지 않도록 멀티스레딩 및 분산 처리를 최적화합니다.
• 데이터베이스 장애
  1. 데이터베이스 잠금(Lock) 충돌
     • 상황 : 인기 콘서트의 예약이 시작되면서 수많은 사용자가 같은 좌석을 예약하려고 시도하여 데이터베이스에서 해당 좌석 데이터에 대한 잠금이 발생, 이로 인해 다른 사용자들의 예약 프로세스가 지연되는 상황.
     • 설명 : 여러 트랜잭션이 동일한 데이터에 접근하려고 할 때 발생하는 잠금 충돌로, 이로 인해 성능 저하 또는 데드락이 발생할 수 있습니다.
     • 대응 방안
       • 숏텀 : 잠금 충돌이 발생할 경우, 실시간 트랜잭션 모니터링을 통해 장시간 잠금 상태에 있는 트랜잭션을 강제로 롤백하여 시스템 복구를 시도합니다.
       • 미드텀 : 잠금 충돌이 자주 발생하는 쿼리를 식별하고, 해당 쿼리를 최적화합니다. 특히, 인덱스를 적절히 설정하여 데이터 접근 속도를 개선하고, 잠금 시간을 단축합니다.
       • 롱텀 : 데이터베이스의 아키텍처를 근본적으로 재설계하여, 잠금 충돌이 발생할 가능성을 최소화합니다. 이를 위해 트랜잭션이 집중되는 주요 테이블에 대한 샤딩(sharding) 또는 파티셔닝(partitioning) 전략을 도입합니다.
  2. 쿼리 성능 저하
     • 상황 : 예약 가능한 좌석 조회 시, 잘못된 인덱스 설정으로 인해 데이터베이스가 전체 좌석 데이터를 스캔하는 바람에 응답 시간이 크게 늘어나는 상황.
     • 설명 : 비효율적인 쿼리 작성이나 인덱스 미설정으로 인해 데이터 조회 속도가 느려지고, 시스템 전체 성능이 저하됩니다.
     • 대응 방안
       • 숏텀 : 성능 저하를 유발하는 쿼리를 임시로 비활성화하거나, 실행 우선순위를 낮춰 다른 중요한 작업이 병목되지 않도록 조치합니다.
       • 미드텀 : 쿼리 실행 계획을 분석하여 비효율적인 쿼리 및 인덱스 문제를 해결합니다. 적절한 인덱스를 추가하여 데이터 조회 성능을 개선합니다.
       • 롱텀 : 데이터베이스 파티셔닝(partitioning) 또는 샤딩(sharding) 전략을 도입하여, 대규모 데이터셋에 대한 조회 성능을 근본적으로 개선합니다.
• 네트워크 지연(Latency)
  • 상황 : 대규모 이벤트에 대한 좌석 예약이 시작되면서 트래픽이 몰려 네트워크 지연이 발생, 사용자가 예약 절차를 완료하는 데 예상보다 더 긴 시간이 소요되는 상황.
  • 설명 : 네트워크 속도가 느려져 데이터 전송이 지연되는 현상으로, 특히 실시간 처리가 중요한 서비스에서 문제가 될 수 있습니다.
  • 대응 방안
    • 숏텀 : 중요한 트랜잭션이나 실시간 요청에 대한 우선순위를 높여, 네트워크 지연이 발생하더라도 중요한 서비스가 먼저 처리되도록 합니다.
    • 미드텀 : 네트워크 인프라의 병목 지점을 식별하고, 해당 장비를 업그레이드하거나 라우팅 경로를 최적화하여 네트워크 성능을 개선합니다.
    • 롱텀 : 자동화된 네트워크 트래픽 관리 시스템을 도입하여, 실시간으로 트래픽을 분석하고 부하가 발생하는 지점을 즉각적으로 최적화하거나 경로를 변경하는 기능을 추가합니다.

2️⃣ 외부 서비스 장애

• API 장애
  1. 외부 API 응답 지연 및 호출 실패
     • 상황 : 사용자가 티켓을 예약한 후 결제 단계에서 외부 결제 게이트웨이가 응답을 지연시키거나, API 호출 자체가 실패하여 사용자가 예약을 완료하지 못하는 상황.
     • 설명 : 외부 API 서버의 과부하 또는 네트워크 문제로 인해 응답 시간이 비정상적으로 길어지거나 호출이 실패하여 서비스의 전반적인 성능이 저하될 수 있습니다.
     • 대응 방안
       • 숏텀 : 서킷 브레이커를 적용하여 외부 API의 응답 지연이나 호출 실패가 감지될 경우, 해당 API 호출을 일정 시간 동안 중단하고, 대체 방법을 사용하도록 설정합니다.
       • 미드텀 : 재시도 로직을 개선하여, 일정 시간 후에 요청을 다시 시도하거나, 백오프(backoff) 전략을 통해 재시도의 빈도를 조절합니다. 또한, 일정 횟수 이상 실패한 요청에 대해 자동적으로 서킷 브레이커가 작동하도록 설정하여, 시스템 전체에 미치는 영향을 최소화합니다.
       • 롱텀 : 고가용성을 유지하기 위해 멀티 데이터센터나 대체 API 제공자를 활용하여, 한 지역의 데이터센터가 장애를 겪더라도 다른 지역의 데이터센터에서 API를 제공할 수 있도록 설정합니다. 또한, 자동화된 장애 대응 시스템을 통해 외부 API 지연이나 실패가 발생할 때 즉각적으로 대체 API로 전환하거나, 사용자에게 상황을 알리고 적절한 대처 방법을 안내합니다.
• 서드파티 서비스 장애
  1. 클라우드 서비스 중단
     • 상황 : 예약 시스템이 운영되는 AWS 클라우드가 장애를 겪어 사용자가 예약 페이지에 접속할 수 없는 상황.
     • 설명 : AWS, Azure, GCP 등의 클라우드 서비스 제공자가 장애를 겪어 서비스가 중단되는 경우입니다.
     • 대응 방안
       • 숏텀 : 클라우드 장애 상황에서 사용자에게 상황을 공지하고, 장애 복구 예상 시간을 알리며, 사용자 불편을 최소화하기 위한 대응책을 안내합니다.
       • 미드텀 : 클라우드 서비스 제공자가 장애를 겪을 경우 로컬 인프라 또는 멀티 클라우드 전략을 통해 다른 클라우드 서비스 제공자로 자동 전환할 수 있는 시스템을 구축합니다.
       • 롱텀 : 멀티 클라우드 아키텍처를 구축하여, 한 클라우드 제공자에 장애가 발생하더라도 다른 클라우드에서 서비스가 정상적으로 운영될 수 있도록 합니다.
• Kafka 장애
  1. Kafka 브로커 장애
     • 상황 : 수많은 예약 요청이 동시에 발생하여 Kafka 브로커가 과부하로 다운, 예약 요청이 지연되거나 누락되는 상황.
     • 설명 : Kafka 브로커가 다운되거나 과부하로 인해 메시지를 제대로 처리하지 못하는 상황입니다. 이로 인해 메시지 전송이 지연되거나 실패할 수 있으며, 서비스 전체에 영향을 미칠 수 있습니다.
     • 대응 방안
       • 숏텀 : Kafka 브로커가 과부하 상태에 도달한 경우, 문제 발생 브로커를 신속하게 격리하고 트래픽을 다른 정상 브로커로 재분배하여 메시지 처리가 지속되도록 합니다.
       • 미드텀 : 아웃박스 패턴을 적용하여, 메시지가 Kafka로 발행되기 전에 안전하게 데이터베이스에 기록되도록 설정하여, Kafka 장애 시 메시지 유실을 방지합니다.
       • 롱텀 : Kafka 클러스터의 상태를 자동으로 모니터링하고, 장애 발생 시 자동으로 복구 절차를 실행할 수 있는 시스템을 구축합니다.
• Redis 장애
  1. Redis 서버 장애
     • 상황 : 예약 가능한 날짜 정보가 Redis에 캐시되어 있으나, Redis 서버 장애로 인해 캐시된 데이터를 가져올 수 없어 데이터베이스에 직접 조회하는 상황.
     • 설명 : Redis 서버가 다운되거나 네트워크 문제로 인해 캐시 데이터에 접근할 수 없는 상황입니다.
     • 대응 방안
       • 숏텀 : Redis 서버에 장애가 발생하면, 애플리케이션이 자동으로 데이터베이스에서 데이터를 조회하도록 전환합니다.
       • 미드텀 : Redis 노드 간의 데이터 복제 및 페일오버(failover) 전략을 강화하여, 장애 발생 시 자동으로 다른 노드가 주도권을 가져갈 수 있도록 설정합니다. 이를 통해 장애 시에도 서비스의 가용성을 유지할 수 있습니다.
       • 롱텀 : Redis의 고가용성(HA) 아키텍처를 도입하여, 여러 데이터센터나 클라우드에 분산된 Redis 인스턴스를 운영함으로써, 단일 장애 지점(Single Point of Failure)을 제거합니다.