"서버 접속이 안됩니다..." 서버 장애 대응기 (feat.Cannot Connect to Database Server)

사건의 발단

로그인 API가 안된다는 프론트엔드 팀원님의 갑작스런 메세지.....
보고 현기증나기 시작했다.ㅎ 왜냐면 함께 하던 백엔드 팀원님이 나가셔서 이제 내가 무조건 처리해야하기 때문에.. (처리 못하면 죽음뿐 ^^)

문제 상황

* Database

server 접속 안됨 (MySQL Cannot Connect to Database Server)

디비 데이터 모두 초기화됨

 

* domain 접속 안됨

해결 방법

데이터베이스 도커 컨테이너 재기동

서버가 네이버 클라우드로 돌아가고 있는데 프로젝트 기간이 얼마 남지 않은 시점이라 처음에 크레딧 소멸을 의심했다. 다행히 아직 크레딧은 남아 있어서 클라우드에서 서버가 내려간건 아니었다.

그렇다면 디비 서버만 연결이 안된다는 건데, 여기서 클라우드 서버와 디비 서버와의 개념이 정립되어 있지 않아 무엇을 확인해야하는지 혼란스럽기 시작합니다..

네이버 클라우드 서버, 인수인계로 전달 받은 ssh 서버, 디비 정보에 등록된 서버 ip는 대체 무슨 차이인거지.....?

그래서 일단 디비가 도커로 올라가있고, 도커를 통해 접속해서 실행하고 있다는 걸 알고 있었기 때문에 도커를 살펴보았다.


*컨테이너 리스트

docker container ls -a

-a : 옵션을 붙이면 exited 상태의 컨테이너도 모두 조회한다.

 

처음에 컨테이너 리스트 조회하면서 내려간 컨테이너가 있을 거라고는 생각을 못했다.

옵션 안 넣고 조회한 덕에 내려간 상태라는걸 인지하는데 시간이 오래 걸렸다. 🙄

컨테이너 기동

기존에 있는 컨테이너를 재기동 하기 위해 start 명령어 사용하였다.

docker start containerID

디비 관련한 컨테이너(redis, mysql, mongo)가 내려간걸 확인하고 모두 재기동 하였고, 드디어 다시 서버에 접속할 수 있었다 !!


docker start / run 차이점
- docker start : 중지된 컨테이너 시작. docker create 명령을 사용하여 컨테이너를 만든 경우 이 명령으로 시작할 수 있다.
- docker run : create + start의 조합으로 새 컨테이너를 생성하고 시작한다.

docker run 명령은 로컬 시스템에서 이미지를 찾지 못하는 경우 Docker Hub에서 이미지를 가져와서 컨테이너를 생성하고 실행한다.

 

 

백업 볼륨 없어서 mysql, mongodb 데이터베이스 재구축

디비 접속했다고 모든게 끝난 줄 알았지 !
접속했더니 이게 웬걸...? 테이블 구조며 데이터며 모두 날아가고 싹 초기화 되어 있어서 2차 멘붕이 왔다.

데이터를 어디선가 불러와야 한다는 생각으로 구글링을 시작하였고, 도커에서는 volume으로 데이터 관리가 가능하다는 소리에 volume 정보를 찾아보기 시작했다.

* 컨테이너 재기동 후 volume 정보 확인

"Mounts": [
            {
                "Type": "bind",
                "Source": "/root/server/backend/tools/mysql/init",
                "Destination": "/docker-entrypoint-initdb.d",
                "Mode": "rw",
                "RW": true,
                "Propagation": "rprivate"
            },
            {
                "Type": "volume",
                "Name": "tools_beside-mysql",
                "Source": "/var/lib/docker/volumes/tools_beside-mysql/_data",
                "Destination": "/var/lib/mysql",
                "Driver": "local",
                "Mode": "rw",
                "RW": true,
                "Propagation": ""
            }
        ],

알고보니 컨테이너를 다시 올리면 기존에 볼륨은 모두 날아가고 초기화 된다는거...^^
이미 날아간 볼륨은 어쩔 수 없으니.. 다른 볼륨에 데이터가 있을 거라는 이상한 믿음(?)과 함께.. 다른 volume이 또 있는지 찾아보았다. 


* docker volume list 조회

docker volume ls

현재 사용하고 있는 컨테이너의 volume인 tools_beside-db명 으로 조회되고 있어서

해당하는 데이터베이스의 볼륨을 연결하면 기존에 사용하던 데이터를 복구할 수 있을 줄 알았다.

 

 

열심히 컨테이너에 볼륨을 연결하는 방법을 검색해보았지만

구글님은 새로운 볼륨을 생성하고, 해당하는 볼륨을 컨테이너 실행 run 할 때 지정해주는 방법만 알려주시는데....

 

원하는게 이게 아닌데...
컨테이너에 연결된 다른 백업은 어떻게 찾는거야 ?! 계속 답답한 마음이 들었다.

 

결론:

초기에 도커 환경 세팅한 팀원님께 문의한 결과.. 개발 서버로 도커를 구축하여 애초에 백업 volume은 존재하지 않았다고…..

볼륨 리스트에 존재하는게 전부가 맞다는걸 그제서야 인지했다.

 

열심히 한땀한땀 다시 데이터를 채우고 있습니다.

 

 

 

nginx 컨테이너 재기동

서버가 정상적으로 작동되어 연결된 데이터베이스 접속도 되고, 스프링 앱도 정상 실행되어 서버 작업이 끝난 줄 알았다.

그러다가 프론트 팀원이 전달해주신 청천벽력 같은 소리.. “도메인 접속이 안돼요 !! ㅠㅠ”

아니 서버가 정상적으로 작동되고 도메인에 연결된 ip도 돌리고 있는 서버의 host랑 동일한데 왜 안되는거지..? 정말 이해할 수가 없었다.

root@beside:~# nslookup harukitty.com
Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
Name:	harukitty.com
Address:

왜냐면 도메인에 대한 이해가 전혀 없었으니까……


도메인 접속 안되면서 발생한 refused to connect. 에러는

1. 서버 설정
서버 자체가 실행되지 않았거나, 서버 내의 에러로 프로세스가 죽은 경우 등 서버가 제대로 실행되지 않았을 때 발생
⇒ 서버 정상 실행 확인 필요

2. 포트 설정
포트포워딩(port forwarding) 확인

• 포트포워딩 : 비공인 IP가 할당된 서버에 접속하기 위한 기능. 포트 포워딩을 설정하면 서버 접속을 위해 계정당 1개의 공인 IP가 할당되며, 각각의 서버에 외부 포트 번호를 설정하여 포트 번호와 연결된 서버에 접속할 수 있다.

nginx 웹서버로 연결하여 도메인이 돌아가는 걸 몰랐던 나는

image 리스트에서 nginx를 보고도 재기동하지 않았음을.. 뒤늦게 깨달았다. 😅

 

nginx 도커 이미지 생성

docker build -t proxy .

 

 

 

docker container 생성하여 실행

docker run -p 443:443 -p 80:80 -d proxy

해당 포트로 잘 실행 중!!

문제 해결

이렇게 서버 장애는 모두 해결하였다.

 

 

개발자도 아닌데 주변 개발자분들께 연락해서 발 벗고 도와주신 우리팀 디자이너 님들.. 너무너무 감사하다 ㅠㅠ 🥲
피엠님도 주변 분들께 물어봐주셔서 도움이 많이 되었다.

다들 너무 감사하신 분들!!!!


이번 일은 백엔드 서버 개발자의 역할을 제대로 하지 못해서 벌어진 일이라 너무 마음이 괴로웠고
빨리 해결해야 한다는 부담감에 심하게 스트레스 받았다.. (입술 헤르페스 두번 생김)

 

프로젝트 같이 하던 팀원분께서 초반에 서버 구축, 프로젝트에 대한 전반적인 세팅을 모두 해주셔서

백엔드 개발자로서 부족한 내 역할을 다 채워주셨는데, 뒤늦게 이렇게 실력이 들통나버려서 부끄러운 마음도 아주 컸다.


한번의 장애로 서버 세팅에 대해서 빠르게 알게 된 소중한 경험. ㅎ


프로젝트 하면서 문제는 언제나 발생할 수 있고, 그걸 어떻게 잘 해결하느냐가 관건인데
당장 나한테 발생한 문제에 당황할 수 있지만

그럴수록 침착하게 근본 원인을 파악하면서 이슈 사항을 바라봐야 한다는 걸 다시금 깨달은 경험

 

차분하게 어디가 문제인지 파악하기.
그리고 어쩌다 생긴 문제인지 파악하고 피드백하기.

 

 

 

 

원인 파악

대체 왜 컨테이너가 다 내려가서 디비 서버며 웹 서버며 다 죽은걸까.... 원인을 파악해야 한다.


나의 의심
1. 서버에서 컨테이너를 강제로 kill하였다.
2. ssh 서버 연결하면서 서버가 내려가고 컨테이너가 내려갔다.

 

아직 정확한 원인은 파악하지 못하여 빠른 시일 내에 글을 업데이트 하겠습니다.

 

 

 

 

개선 사항

백업 볼륨 생성

현재 생성된 도커 컨테이너에 백업 볼륨을 연결한다.

 

 

aws db 전환 고려

네이버 클라우드 플랫폼 디비 서버는 프로젝트에서 제공받은 크레딧이 있어서 사용한 선택지이다.
하지만 앞으로 앱을 출시하고 운영하고 고도화 하면서 크레딧은 곧 소멸될거고 유지할 지 변경할 지 결정해야 한다.

aws 서버를 사용해보지 않아서 사용법도, 비용적인 측면도 고려해야할 게 많아 당장 전환한다고 확정은 못하겠지만
앱이 커지고 지속성을 생각하면 전환하는 것에 무게를 두고 있다.