Kurly, nginx 없이 애플리케이션 레벨에서 서비스 점검을 차단하는 AccessBlock 시스템 구축

Kurly의 Inbound Product Development Team은 Inventory DB 유지보수 중 발생한 적치 오류를 해결하기 위해 AccessBlock 시스템을 도입했다. 기존 인프라 팀의 nginx 설정 변경이 느린 대응 시간과 권한 문제로 인해, 애플리케이션 레벨에서 직접 접근을 차단하는 방식을 채택했다.

초기 AccessBlock 구현과 한계

초기 버전은 MySQL의 access_block과 access_block_group 테이블을 기반으로 동작했다. 프론트엔드는 페이지 라우팅 시 차단 상태 확인 API를 호출하여 URL을 검증하고, 매칭 시 유지보수 페이지로 리다이렉트했다. 이 방식은 nginx 접근 없이도 즉시 로그아웃 처리가 가능하다는 부수적 이점을 제공했으나, DB 유지보수 시 AccessBlock 데이터 자체에 접근할 수 없다는 치명적인 한계가 있었다.

Redis 캐싱을 통한 RDBMS 의존성 제거

DB 장애 상황에서도 차단 기능을 유지하기 위해 Redis를 활용한 캐싱 전략으로 시스템을 고도화했다. MySQL은 메타데이터 소스로만 사용하며, 실제 차단 여부 판단은 Redis의 BLOCKED_..._ID_LIST 데이터 구조를 참조하도록 변경했다. toggle 상태 변경 시 Redis 데이터 구조를 즉시 업데이트하고, 조회 API는 RDBMS 대신 Redis 값을 읽어 응답 속도를 향상시켰다.

남은 과제와 향후 계획

현재 시스템은 RMS DB 전체 다운 시에도 차단 여부 조회가 가능하지만, 새로운 메타데이터 등록 및 수정은 여전히 RDBMS에 의존한다. DB 다운 시 메타데이터 변경이 불가능한 문제를 해결하기 위해, 직관적인 테이블 조회 및 수정 UI 제공과 완전한 RDBMS 의존성 제거가 향후 과제로 남아 있다.