역할에 따른 서버 분리
DB 서버의 개수가 증가함에 따라, 관리해야 하는 정보 증가
DB 서버의 개수가 증가함에 따라, 이를 관리하기 위해 필요한 정보들이 많아졌습니다.
이러한 정보는 Redis에 저장되고 관리되며, 키 생성 이벤트와 키 삭제 이벤트를 구독하여 필요한 데이터를 처리합니다.
구체적으로 관리해야 할 정보는 다음과 같습니다.
-
사용자에게 연결된 DB 서버의 정보
사용자의 세션 아이디마다 연결된 DB 서버의 IP를 저장합니다.
-
실시간 사용자 목록
실시간 사용자의 세션 아이디 목록을 TTL로 관리합니다.
-
쿼리 실행을 위한 DB 서버의 Pod 정보
DB 서버의 Pod의 IP와 실시간 사용자 수를 저장합니다.
이와 같이, API 요청이 아닌 DB 서버 관리를 위한 역할을하는 서버를 DB Manager Server라는 이름으로 분리하여 운영하였습니다.
DB Manager Server를 분리하여 관리하는 이유는 다음과 같습니다.
구독 중복 이벤트 발생 문제 해결
현재 프로젝트에서는 PM2를 사용하기 때문에 코어 수 만큼의 서버가 동일한 이벤트를 구독하게 되어 중복된 로직이 실행되는 문제가 발생하였습니다.
- Redis의 pub/sub을 통해 실시간 사용자 목록을 관리
- K8S API의 watch를 활용하여 pod의 목록을 관리
Redis Streams를 활용해 서버를 그룹화하여 문제를 해결하려 했지만, Redis KeyEvent에 따른 이벤트에는 이를 적용할 수 없었습니다.
따라서 서버를 분리하여 각 서버가 독립적으로 이벤트를 처리하도록 구성하였습니다.
DB 서버 접속 관리 기능 분리
DB 서버에 접속하기 위한 정보와 관련된 기능 로직과 API 요청에 대한 응답 로직을 분리하였습니다.
API 서버와 DB Manager 서버가 처리하는 기능은 아래와 같습니다.
-
API 서버 - 쉘 정보 CRUD, 연결되어 있는 DB 서버로의 쿼리 실행 요청
사용자가 새로운 쉘을 생성하거나 수정하면 해당 정보를 저장합니다. 또한 DB Manager 서버에서 생성된 connection을 통해 쿼리를 실행합니다.
-
DB Manager 서버 - 쿼리 요청시 DB 서버와의 연결 처리
새로운 세션의 경우, 실시간 사용자 수가 가장 적은 DB 서버를 확인하여 로드밸런싱을 진행합니다.
그렇지 않은 경우 저장된 세션별 DB 정보를 조회하여 해당 DB 서버와의 connection을 생성합니다.
DB Manager Server라는 이름으로 서버를 분리하여 Redis의 이벤트 처리를 위한 구독 중복 문제를 해결하였습니다.
또한 기존 API 서버와 DB 서버 접속 관리 서버를 분리하여 서버 간의 의존성을 줄이고 DB 서버와의 연결을 효율적으로 관리할 수 있게 되었습니다.