최근 GIS 서버에서 꽤 이상한 장애를 하나 겪었다.
처음 증상은 단순했다.
갑자기 지도 서비스가 정상적으로 나오지 않았다.
처음에는 당연히 지도 서비스 자체의 문제라고 생각했다.
관련 프로세스가 정상적으로 떠 있는지 확인하고, 포트도 보고, 로그도 확인하면서 하나씩 원인을 찾아보기 시작했다.
그런데 확인할수록 조금 이상했다.
웹에서는 되는데 SSH로 접속하면 이상해진다?
문제를 확인하던 중 특이한 현상을 발견했다.
웹에서 지도 서비스를 확인하면 정상적으로 지도가 나왔다.
그런데 GIS 서버에 SSH로 접속하면 갑자기 웹 연결이 끊기면서 지도도 나오지 않았다.
ssh -o ServerAliveInterval=20 \
-o ServerAliveCountMax=3 \
user@192.168.x.x
처음에는 우연인 줄 알았다.
다시 웹에서 확인하면 정상.
그 상태에서 SSH로 접속하면 또 이상해진다.
심지어 SSH 세션 자체도 안정적이지 않았다.
접속해서 작업하고 있으면 세션이 끊어지는 일이 반복됐다.
SSH로 접속했을 뿐인데 웹서비스가 왜 같이 이상해지지...?
여기서부터 문제가 생각보다 단순하지 않다고 느꼈다.
일단 서버 안에서 원인을 찾기 시작했다
처음에는 서버 문제라고 생각했기 때문에 자연스럽게 서버 안에서 원인을 찾았다.
서비스 프로세스를 확인하고,
포트가 정상적으로 열려 있는지도 보고,
서버 로그도 계속 확인했다.
관련 서비스를 재기동해보기도 하고 DB 연결 상태나 서버 자원도 확인했다.
그런데 뭔가 이상했다.
문제가 해결된 것처럼 보이다가 다시 발생하고, SSH 세션은 여전히 불안정했다.
특히 SSH 접속과 웹서비스 장애가 왜 연결되는지 설명이 되지 않았다.
로그를 봐도 결정적인 원인이 나오지 않았다.
그날은 결국 이 문제 때문에 퇴근도 못 하고 계속 서버를 보고 있었다.
로그 보고,
프로세스 보고,
포트 보고,
재기동하고,
다시 접속해보고...
야근하면서 이것저것 계속 확인했는데도 원인을 정확하게 찾지 못했다.
이쯤 되니까 슬슬 답답해지기 시작했다.
같은 IP인데... 파일이 왜 다르지?
그러다가 다음 날 문제를 다시 확인하던 중 정말 이상한 점을 하나 발견했다.
분명 같은 IP의 GIS 서버에 접속하고 있었다.
그런데 서버에서 확인되는 파일 상태가 달랐다.
한쪽에서 확인했던 파일이 다른 접속에서는 보이지 않거나, 파일의 상태가 서로 맞지 않았다.
처음에는
파일 동기화가 안 되고 있나?
라고 생각했다.
그런데 다시 생각해보니 말이 안 됐다.
같은 서버라면 파일이 다를 이유가 없다.
여기서 처음으로 서버 자체가 아니라 다른 가능성을 의심하기 시작했다.
잠깐만... 이거 진짜 같은 서버에 접속하고 있는 거 맞나?
지금 생각하면 이게 가장 결정적인 힌트였다.
원인은 VM 복제로 인한 IP 충돌
다른 팀에도 혹시 최근 서버와 관련해서 작업한 게 있는지 확인했다.
그리고 드디어 원인을 찾았다.
다른 팀에서 기존 VM을 복제해서 테스트 환경으로 사용하고 있었는데,
VM을 복제하면서 IP 설정까지 그대로 복제된 상태였다.
결국 네트워크에는 이런 상황이 만들어져 있었다.
기존 GIS 서버
192.168.x.x
복제된 VM
192.168.x.x
같은 IP를 가진 서버가 두 대 떠 있었던 것이다.
그 순간 그동안 이해되지 않았던 현상들이 한꺼번에 설명되기 시작했다.
그래서 SSH가 계속 끊겼던 거였다
같은 네트워크에서 두 서버가 동일한 IP를 사용하면 IP 충돌이 발생한다.
내 PC에서는 계속 같은 IP로 요청을 보내고 있지만 실제 네트워크에는 해당 IP를 가진 서버가 두 대 존재하고 있었다.
그러다 보니 통신이 정상적으로 유지되지 않고 기존에 연결되어 있던 세션도 불안정해질 수 있다.
내가 겪었던 현상을 다시 정리해보면 이랬다.
SSH 세션이 계속 끊김
웹서비스가 됐다가 안 됨
같은 IP로 접속했는데 파일 상태가 다름
지도 서비스가 정상적으로 나오다가 갑자기 끊김
각각 따로 보면 원인을 찾기 어려운 현상이었다.
하지만 IP가 같은 서버가 두 대 있었다고 생각하면 전부 연결됐다.
특히 같은 IP인데 파일이 다르다는 현상이 가장 큰 힌트였다.
복제된 VM을 내렸더니
원인을 확인하고 다른 팀에서 복제해 사용하고 있던 VM을 종료했다.
그리고 다시 GIS 서버에 접속했다.
그랬더니...
바로 정상으로 돌아왔다.
지도 서비스도 정상적으로 나오고,
SSH 세션도 더 이상 끊기지 않았다.
심지어 SSH 접속 속도까지 이전보다 훨씬 빨라졌다.
그동안 서버 로그와 프로세스를 계속 들여다보고 있었는데 원인은 너무 단순했다.
IP 충돌.
이걸 찾으려고 야근까지 했다고 생각하니 조금 허무했다 ㅋㅋ
야근까지 했는데 서버 안에는 답이 없었다
이번 장애를 겪으면서 가장 크게 느낀 부분이다.
처음 문제가 발생했을 때 나는 당연히 서버 안에 원인이 있다고 생각했다.
그래서 계속 서버 안에서 답을 찾았다.
로그
↓
프로세스
↓
포트
↓
DB 연결
↓
서비스 재기동
↓
다시 로그...
그런데 아무리 확인해도 모든 현상을 설명할 수 있는 원인이 나오지 않았다.
지금 생각하면 당연하다.
애초에 문제의 원인이 서버 안에 없었기 때문이다.
다른 팀에서 동일한 IP의 VM을 띄웠다는 사실을 모르는 상태에서 서버 로그만 보고 이 문제를 찾아내기는 쉽지 않았다.
오히려
"최근에 이 서버나 네트워크 쪽에 변경된 게 있나요?"
라고 한 번 물어봤다면 훨씬 빨리 원인을 찾았을 수도 있다.
서버 장애라고 항상 서버만 볼 필요는 없었다
보통 장애가 발생하면 가장 먼저 로그를 본다.
그리고 프로세스나 포트, DB 연결 상태 등을 하나씩 확인하면서 원인을 좁혀간다.
물론 이런 과정은 중요하다.
하지만 이번에는 하나를 더 배웠다.
기술적인 확인만큼 주변의 변경사항을 확인하는 것도 중요하다는 것.
특히 여러 팀이 서버나 네트워크 환경을 함께 사용한다면 내가 건드리지 않은 부분에서도 얼마든지 장애가 발생할 수 있다.
이번에는 서버 안에서 원인을 찾느라 꽤 오래 헤맸다.
다음에 비슷하게 도저히 설명이 안 되는 이상한 현상이 생긴다면 서버만 계속 붙잡고 있지는 않을 것 같다.
로그도 보고, 서버도 확인하겠지만...
다른 팀에서 최근에 뭐 한 거 없는지도 먼저 물어봐야겠다 ㅋㅋ