트러블슈팅 10. DNS 를 바꿨는데도 authentik 아웃포스트가 옛 서버에 붙어 있을 때: 오래 열린 웹소켓

로그인을 맡는 authentik 을 도쿄 노드에서 춘천 노드로 옮길 때였습니다.

옮기는 방식은 이랬습니다. 새 노드에 authentik 을 띄우고, 옛 서버의 앞단 Caddy 는 들어오는 요청을 전부 새 노드로 넘기게 바꿉니다. 그다음 DNS 를 새 노드로 바꿉니다. DNS 가 퍼지는 동안 옛 IP 로 오는 요청도 옛 Caddy 를 거쳐 새 노드에 닿으니 끊기는 사람이 없습니다.

authentik 에는 다른 노드에서 도는 아웃포스트가 둘 있습니다. 캘린더 서버 앞의 아웃포스트와, 다른 서비스 앞의 아웃포스트입니다. 아웃포스트는 authentik 서버와 웹소켓을 하나 열어 두고 설정을 받습니다.

오전 9시에 DNS 를 바꿨고, 9시 48분쯤 공용 DNS 가 모두 새 IP 를 가리켰습니다. 그런데 옛 Caddy 에는 연결이 세 개 남아 있었습니다. 두 아웃포스트의 웹소켓과, 제 PC 에 열려 있던 관리 화면이었습니다. 셋 다 DNS 를 바꾸기 전에 열린 연결이었습니다.

웹소켓은 한 번 열리면 끊길 때까지 그 연결을 계속 씁니다. DNS 는 새로 연결할 때만 다시 묻습니다. 그러니 아웃포스트는 옛 IP 로 열어 둔 연결로 옛 Caddy 를 거쳐 새 서버와 계속 얘기하고 있었던 거죠. 옛 Caddy 가 넘겨 주는 동안은 문제가 없지만, 옛 서버를 끄는 순간 끊기고, 그때 다시 붙을 때까지 로그인이 흔들릴 수 있습니다.

그래서 옛 서버를 끄기 전에 옛 Caddy 를 먼저 재시작했습니다.

cd /opt/caddy && sudo docker compose restart caddy

연결이 끊기자 두 아웃포스트는 2초 안에 DNS 를 다시 물어 새 노드에 직접 붙었습니다. 아웃포스트 로그에서 새 서버로 웹소켓이 다시 붙는 것을 확인했고요.

마지막까지 남은 건 공유기 DNS 캐시에 옛 IP 가 남아 있던 PC 한 대였는데, 그 연결도 옛 Caddy 가 넘겨 주고 있어서 그대로 두었습니다. 옛 서버는 그 뒤에 껐습니다.

서버를 옮길 때 DNS 반영만 확인하고 끝내기 쉬운데, 웹소켓이나 데이터베이스 연결처럼 오래 열려 있는 연결은 따로 봐야 했습니다. 옛 앞단의 열린 연결 수를 한 번 보고 끄는 게 안전합니다.