인프런 커뮤니티 질문&답변
작성한 질문수
메시지 이벤트 발행시 에러 발생 관련 질문이 있습니다.
해결된 질문
작성
·
152
0
이번에 면접을 보면서 확실하게 대답을 못해서 고민 끝에 선생님에게 질문 드립니다.
우선 시나리오 말씀드리자면 client 가 해당 게시글에 "좋아요" 등록을 하게 된다면
좋아요 등록 관련 DB 테이블에 insert 동시에 outbox 테이블에도 insert 하도록 설계 되어 있습니다.
commit 이 정상적으로 발생되면 kafka 서버에게 이벤트 메시지를 발행 하게 되는데요.
만약 갑자기 이벤트 발행시 kafka 서버가 죽었다고 하면 복구 될때 까지 기다리다가 retry 통해 아직 메시지 발행 하지 못한 메시지 outbox 테이블에 조회해서 메시지 발행 하면 문제가 없을 것 같은데요.
하지만 다시 처음부터 설명하면 client 가 좋아요 등록 후 DB 서버가 죽어서 "좋아요" 관련 테이블 및 "outbox" 테이블에 insert 를 못했다고 가정 했을때 어떻게 대처 해야 하는지 역으로 질문 받았습니다.
일단 DB 서버가 죽었으면 빠르게 고객에게 에러 메시지를 전달과 동시에 담당 개발자에게 빠르게 전달 할 수 있도록 전달 해야 한다고 했습니다. (회사에서 slack 메신저 사용하면 메신저 통해 알림)
혹시 이것보다 더 좋은 방법이 있을까요? 재대로 대답하지 못해 찜찜해서 이렇게 선생님에게 질문 드리네요.
답변 2
0
리나님, 안녕하세요!
사실 메인 데이터베이스가 죽으면 이미 outbox 패턴과 무관한 시스템의 전면 장애 상황일거라, 복구하는 것 말고 방법이 없긴 합니다.
아래 내용들은 첨언할 수 있을 것 같네요.
트랜잭션 자체가 실패했으므로, 적어도 데이터 정합성이 깨진 상황은 아니라는 점
사용자에게 에러 응답이 내려갈 수 있으나, 결국 메인 DB 장애는 시스템 전면 장애라서 복구하는 수밖에 없음
복구에 시일이 걸린다면 장애에 대한 사용자 공지도 적절한 조치
서비스 정책이나 요구사항마다 다르겠지만, 임시로 버퍼해두었다가(로컬이든/메모리든/별도 queue든) 나중에 재처리할 수 있음(그런데 좋아요 기능에 대해서 굳이? 적절할지는 애매하네요)
추가로, DB 장애 복구 전략과 가용성을 보장하기 위한 방법에 대해서 이야기해볼 수 있음
간단하게 키워드만 전달드리면, 복구 전략은 failover/replication/이중화 이런 개념을 학습해보시면 될 것 같습니다. (Distributed Relational Database 강의에서 master DB가 죽었을 때, replica DB를 master DB로 선출한다는 개념이 유사합니다. 물론, 구성은 더욱 다양할 수 있습니다.)
샤딩 기법을 가용성을 위한 방법으로 볼 수도 있습니다. 특정 샤드에는 장애가 발생했더라도, 정상 샤드는 여전히 정상 동작하는 상황이기 때문에 장애 범위가 최소화될 수 있기 때문입니다. 강의의 좋아요 기능을 예시로 들면, 장애가 발생하지 않은 샤드로 라우팅되는 게시글 ID는 여전히 정상 동작됩니다.
임시로 복구 DB에 작업을 처리하다가, 복구가 완료되면 원본 DB에 데이터 동기화를 해줄 수도 있습니다.
가용성/정합성을 위한 조금 더 심화 내용으로는 Quorum(정족수) 개념도 살펴볼 수 있습니다. (Kafka 리더 선출 방법이나 in-sync replicas가 유사한 개념이고, 데이터베이스에서도 적용 가능한 개념입니다.)
외에도 장애 원인 및 상황에 따라서 적절한 방법을 떠올릴 수 있을 것 같습니다! 꼭 한 가지 정답이 있는 내용은 아닐 것 같네요.
즉, 기술적인 측면에서 정리해보면, DB 장애 복구 전략과 가용성을 보장하기 위한 방법들에 대해서 언급할 수 있었을 것 같네요.
물론, 쉽게 답할 수 있는 질문은 아니긴 합니다.. 😅
상황 인지 및 대응 측면에서는 리나님의 답변도 아주 중요한 내용입니다!
혹시 더 궁금한 점 있으시면 편히 문의 주시고, 꼭 좋은 결과 있으시길 바랍니다!!
0
안녕하세요, 인프런 AI 인턴입니다. 리나님.
우선, 면접에서 어려운 질문을 받으셨군요. 고객의 요청 처리가 실패했을 때의 적절한 대응 방법을 묻는 문제는 시스템의 신뢰성과 비즈니스 논리에 직결되는 중요한 주제입니다. 현재 언급하신 시나리오에서, DB 서버의 장애로 인해 “좋아요”가 등록되지 않는 상황에서 대처할 수 있는 몇 가지 방법을 살펴보겠습니다:
데이터베이스 장애 대응 방법
트랜잭션 관리 및 롤백:
- 비즈니스 로직 단위로 트랜잭션을 설정하여 모든 연산이 성공하거나 실패하는 경우 모두 롤백되도록 합니다. 이는 데이터의 일관성을 유지하는 중요한 방법입니다.
- 클라이언트에게 DB 장애 상황에 대한 적절한 처리 메시지를 제공하여 사용자가 혼란스럽지 않도록 합니다.
- 비즈니스 로직 단위로 트랜잭션을 설정하여 모든 연산이 성공하거나 실패하는 경우 모두 롤백되도록 합니다. 이는 데이터의 일관성을 유지하는 중요한 방법입니다.
장애 처리 로직:
- DB 장애가 발생하면 애플리케이션 레이어에서 예외 처리를 통해 실패 상태를 탐지하고, UI 상으로는 에러 메시지를 사용자에게 즉시 알려야 합니다.
- 동시에, 해당 정보를 Slack 등의 커뮤니케이션 도구를 통해 개발팀에 자동으로 알릴 수 있도록 시스템을 구성합니다.
- DB 장애가 발생하면 애플리케이션 레이어에서 예외 처리를 통해 실패 상태를 탐지하고, UI 상으로는 에러 메시지를 사용자에게 즉시 알려야 합니다.
로컬 캐시 및 임시 스토리지 사용:
- 잠시 동안 데이터를 유실하지 않도록 애플리케이션 내 임시 저장소나 캐시를 사용하여 나중에 DB 복구 시에 재반영할 수 있는 방법을 고려할 수 있습니다.
- 잠시 동안 데이터를 유실하지 않도록 애플리케이션 내 임시 저장소나 캐시를 사용하여 나중에 DB 복구 시에 재반영할 수 있는 방법을 고려할 수 있습니다.
재시도 메커니즘:
- 장애 발생 후 일정 시간 대기 후 재시도하는 메커니즘을 자동화할 수도 있습니다. 이때, 일정 횟수 이상 재시도 실패 시에는 관리자에게 알람을 전송하도록 하는 것이 바람직합니다.
- 장애 발생 후 일정 시간 대기 후 재시도하는 메커니즘을 자동화할 수도 있습니다. 이때, 일정 횟수 이상 재시도 실패 시에는 관리자에게 알람을 전송하도록 하는 것이 바람직합니다.
모니터링 및 알림 시스템 강화:
- 실시간 모니터링 도구나 로그 시스템을 활용하여 DB 상태를 체크하고 결함 발생 시 자동으로 알림을 수신하는 시스템을 사용해 연속적인 대응이 가능합니다.
- 실시간 모니터링 도구나 로그 시스템을 활용하여 DB 상태를 체크하고 결함 발생 시 자동으로 알림을 수신하는 시스템을 사용해 연속적인 대응이 가능합니다.
위와 같이 다양한 접근법이 있으며, 상황에 맞게 충분한 테스트를 통해 신뢰성 있는 시스템을 구성하는 것이 중요합니다.
관련한 더 많은 정보는 아래 게시글을 통해 자세히 살펴보실 수 있습니다:
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.