액티브-액티브 이중화로 가용성을 높인 경험
결제 승인 서버를 서울·부산 두 리전에 액티브-액티브로 운영하도록 설계했습니다. 단일 리전 장애 시에도 트래픽이 자동으로 전환되도록 헬스체크 기반 DNS 페일오버를 구성했고, 전환 시간을 실측한 결과 평균 22초 안에 정상화됐습니다. 다만 두 리전 간 데이터 동기화 지연이 있어, 결제처럼 정합성이 중요한 요청은 동기 복제로 처리하고 로그성 데이터는 비동기로 분리해 지연 문제를 최소화했습니다.
면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.
결제 승인 서버를 서울·부산 두 리전에 액티브-액티브로 운영하도록 설계했습니다. 단일 리전 장애 시에도 트래픽이 자동으로 전환되도록 헬스체크 기반 DNS 페일오버를 구성했고, 전환 시간을 실측한 결과 평균 22초 안에 정상화됐습니다. 다만 두 리전 간 데이터 동기화 지연이 있어, 결제처럼 정합성이 중요한 요청은 동기 복제로 처리하고 로그성 데이터는 비동기로 분리해 지연 문제를 최소화했습니다.
분기마다 진행하는 재해복구 훈련을 담당하며 가장 신경 쓴 부분은 실제 장애와 최대한 비슷한 시나리오를 만드는 것이었습니다. 단순히 서버를 끄는 게 아니라, 주 DB 장애 도중 트래픽이 몰리는 상황까지 재현해 복구 절차서의 허점을 찾았습니다. 첫 훈련에서는 복구까지 47분이 걸렸는데, 원인은 담당자 연락 체계가 명확하지 않았기 때문이었습니다. 이를 온콜 자동 호출 시스템으로 바꾼 뒤 다음 훈련에서는 12분으로 단축됐습니다.
전체 인프라를 점검하며 단일 장애점을 목록화했더니 12곳이 나왔는데, 예산상 전부를 한 번에 이중화할 수 없었습니다. 그래서 장애 발생 시 영향받는 사용자 수와 복구 소요 시간을 곱한 값으로 우선순위를 매겨, 인증 서버와 결제 게이트웨이부터 이중화했습니다. 나머지는 모니터링 알림 임계치를 낮춰 조기 대응 체계로 우선 보완했습니다. 이 방식으로 예산 초과 없이 핵심 장애 영향도를 60% 줄일 수 있었습니다.
같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.
진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.