현재 그림과 같은 형태로 Redis를 Master-Replica 패턴으로 Deploy해서 사용하고 있다. 사용하고 있는 전력이 약해서인지 문제가 있는 건지 아직 명확한 요인은 파악하지 못했지만, 컴퓨터가 셧다운 되는 현상이 발생했다. 그 때문인지 Redis와 Sentinel이 계속해서 연결 요청을 보내다가 엉켜 Master를 잘못 가리키고 있는 문제가 발생했다. 누가 Master인지 확인 하는 cli command는 나중에 글을 쓰도록 하겠다. 데이터센터의 장애의 원인중 하나로 전력 공급 불가로 일어나는 일이며 기업에서도 종종 겪는 문제이다.
다시 전원을 공급하고 Redis를 사용하려고 하면 READONLY You can't write against a read only replica와 같은 에러 메세지를 볼 때도 있다. 물론 무조건은 아니다. Write 권한은 Master Redis에만 있는데 Replica Redis에 데이터를 넣으려다가 생기는 에러이다. 즉, Sentinel이 Master를 잘못 알려주고 있다는 의미이다. 만약 나처럼 Helm Chart를 이용해 Redis-Sentinel 환경을 구축했다면 해결법은 간단하다.
OpenLens와 같은 GUI 툴을 사용하고 있다면 Workloads > Pods 에 들어간 후 redis를 검색하고 다음의 Pod들을 하나씩 순서대로 삭제하면 다시 제대로 Master를 찾을 수 있게 된다. pod을 삭제하면 Kubernetes가 Cluster에서 pod을 제거하고 pod안에서 실행중인 container를 중단시킨다. 그 후 삭제된 pod을 대체할 새 pod을 시작시킨다. 이때 새로운 pod을 실행 시킬 때 이전에 적어둔 yaml 파일을 참고하여 올리기 때문에 장애가 일어난 Redis와 Sentinel이 Reset되어 재실행 된다고 생각하면 된다.
이는 Kubernetes가 노드 장애, 중단이 발생했을 때도 애플리케이션을 사용할 수 있고 응답성을 유지하도록 설계되었기 때문이다. 대체 pod을 자동으로 생성하여 애플리케이션의 복원력을 높이고 장애로부터 신속하게 복구할 수 있도록 지원한다. 만약 자동 복구를 원하지 않는다면 따로 설정을 해주면 된다.
댓글