'Unrecoverable error: ResponseError('UNBLOCKED force unblock from blocking operation, instance state changed (master -> replica?)')' 에러 Troubleshooting

문제 상황

ROCCIA 901 서비스 배포 후 운영 초반에 동일한 상황을 맞닥드린 적이 있다. 동일한 에러가 발생한 것 보니 그 당시 취한 조치가 적합하지 않았던 것 같다. 당시에는 프리티어의 ec2 인스턴스의 메모리 문제라고 생각하여 overcommit 설정을 했고, 이후 동일한 에러가 발생하지 않았었다.

해당 에러의 문제점은 Redis 서버가 마스터에서 레플리카(슬레이브)로 전환되면서 Redis를 메시지 브로커로 사용하고 있는 경우, Redis가 레플리카로 전환되면 Celery와 같은 클라이언트가 더 이상 정상적으로 Redis와 통신할 수 없게 된다. 따라서 Celery woker와 beat가 정상적으로 동작하지 않았다.

문제 원인

동일한 상황을 해결한 글을 찾았다. 답변 작성자가 참고한 글 깃헙 이슈 페이지를 살펴보면 외부에서의 공격 시도로 보인다고 한다. 이 추측이 어느 정도 타당하다고 생각한 이유는 Redis의 로그를 살펴보았더니 다음과 같은 로그를 찾을 수 있었다.

아래의 로그를 보면 특정 사용자에 의해 레플리카 모드로 전환되기 시작했다.

1:S 03 Sep 2024 08:48:06.309 * Before turning into a replica, using my own master parameters to synthesize a cached master: I may be able to synchronize with the new master with just a partial transfer.
1:S 03 Sep 2024 08:48:06.310 * Connecting to MASTER 106.55.57.10:60142
1:S 03 Sep 2024 08:48:06.314 * REPLICAOF 106.55.57.10:60142 enabled (user request from 'id=39 addr=150.139.211.124:34580 laddr=172.21.0.2:6379 fd=28 name= age=1 idle=0 flags=N db=0 sub=0 psub=0 ssub=0 multi=-1 watch=0 qbuf=28 qbuf-free=20446 argv-mem=24 multi-mem=0 rbs=1024 rbp=155 obl=0 oll=0 omem=0 tot-mem=22448 events=r cmd=slaveof user=default redir=-1 resp=2 lib-name= lib-ver=')

약 5초 후 서버가 다시 마스터 모드로 전환되었다.

1:M 03 Sep 2024 08:48:11.512 * Discarding previously cached master state.
1:M 03 Sep 2024 08:48:11.512 * Setting secondary replication ID to 42212b5e69166ec02edc9d256c56b5f0d31b59f2, valid up to offset: 1. New replication ID is 733e5a931123b01eb7510a6d519e31d758747e5d
1:M 03 Sep 2024 08:48:11.513 * MASTER MODE enabled (user request from 'id=39 addr=150.139.211.124:34580 laddr=172.21.0.2:6379 fd=28 name= age=6 idle=0 flags=N db=0 sub=0 psub=0 ssub=0 multi=-1 watch=0 qbuf=16 qbuf-free=20458 argv-mem=12 multi-mem=0 rbs=1024 rbp=223 obl=0 oll=0 omem=0 tot-mem=22436 events=r cmd=slaveof user=default redir=-1 resp=2 lib-name= lib-ver=')

해결 방법

외부에서의 Redis 접근을 막기 위해선 몇 가지 방법이 있다. 가장 먼저 떠오른 방법은 Redis에 암호를 설정하고 Django 설정 파일의 Redis 설정에 비밀번호를 포함 시키는 것이다. 하지만 현 프로젝트 특성상 하나의 ec2 인스턴스만 사용할 예정이고 인프라적인 확장은 없을 것이다. 따라서 내부에서만 Redis를 사용할 것이기 때문에 Docker Compose 설정에서 포트 매핑을 제거했다.

    cache:
        container_name: cache
        image: redis:7
#        ports:
#            - "6379:6379"

우선 이와 같이 진행하고 추후에 동일한 문제가 발생하면 추가로 글을 작성할 예정이다.

문제의 핵심적인 원인(추가)

이후에 다시 살펴보니 다음과 같은 설정이 있었다.

테스트 용도로 사용 후 삭제하지 않은 인바운드 규칙이 있었던 것이다. 따라서 외부의 공격에 무방비로 당했던 것이다. 꼭 서비스 운영 시에는 보안 설정을 꼼꼼하게 확인하자.