[NCloud 1기] 서버를 껐다 켰더니 백엔드가 사라졌다

4대 서버 재부팅 & 서버 이미지에 대한 오해 정리

이번 글은 4개의 서버(web 2대, was 2대)를 모두 껐다가 다시 켰을 때 내가 겪었던 상황과,
그 과정에서 정리하게 된 개념들을 기록해두는 글이다.

특히 아래 두 가지 질문을 중심으로 고민했다.

1. 서버가 재부팅되면, 전에 실행되던 백엔드 애플리케이션도 자동으로 다시 실행될까?
2. 재부팅 후 “원본 서버”에서만 백엔드 애플리케이션을 다시 실행해주면,
   그 서버의 서버 이미지로 만들어진 다른 서버도 별도 수작업 없이 같이 실행될까?

앞으로 비슷한 인프라를 운영할 때 “내가 뭘 기대하면 안 되는지”를 상기하기 위한 나만의 기록이다.

---

1. 서버 구성과 상황 정리

먼저 내가 갖고 있던 서버 구성은 다음과 같다.

• web-svr01
• web-svr02 ← web-svr01의 서버 이미지로 생성
• was-svr01
• was-svr02 ← was-svr01의 서버 이미지로 생성

WAS 서버에서는 백엔드 애플리케이션(JAR 파일)을 다음과 같이 실행하고 있었다.

nohup java -jar image-platform-api.jar > app.log 2>&1 &

•  java -jar ...  : 스프링부트 백엔드 애플리케이션 실행
•  nohup  : SSH 연결이 끊겨도 프로세스가 계속 돌도록 하는 옵션
•  &  : 백그라운드 실행

어느 날, 서버 점검을 위해 4대 서버(web 2대, was 2대)를 모두 정지했다가 다시 시작했다.
그리고 여기서부터 의문이 시작됐다.

---

2. 첫 번째 질문:  “재부팅하면 백엔드도 자동으로 돌까?” 

서버를 다시 켠 뒤, was-svr01에 SSL VPN으로 접속해서 확인해봤다.

• 예상했던 대로, 전에 nohup으로 실행했던 백엔드 프로세스는 더 이상 존재하지 않았다.
•  ps  ,  netstat  ,  curl  등으로 확인해봐도, 백엔드 포트는 열려 있지 않았다.

그래서 다시 아래 명령을 직접 실행해서 백엔드를 띄웠다.

nohup java -jar image-platform-api.jar > app.log 2>&1 &

 

 

이 과정을 통해 다음 결론을 얻었다.

결론 1.
서버를 재부팅하면, nohup으로 실행 중이던
백엔드 애플리케이션은 자동으로 다시 실행되지 않는다.

왜 그럴까?

여기서 중요한 포인트는:

• 프로그램(프로세스)은 “메모리에서 실행”되고,
• 서버 이미지는 “디스크 상태를 복제”한다는 점이다.

서버를 끄면:

• 메모리에 올라가 있던 모든 프로세스는 사라진다.
• nohup은 “터미널이 끊겨도 살아있게” 해줄 뿐이지,
  “서버가 껐다 켜져도 살아있게” 해주는 기능이 아니다.

즉, 재부팅을 하면 nohup이든 뭐든 상관없이 전부 종료된다.
자동으로 다시 실행되려면, 이를 담당할 추가적인 메커니즘(systemd 등)이 필요하다.

---

3. 두 번째 질문:  “원본 서버만 다시 실행하면, 이미지로 만든 서버도 같이 돌까?” 

이제 두 번째 궁금증이 생겼다.

“was-svr02는 was-svr01의 서버 이미지로 만들어진 서버니까,
재부팅 후에 원본인 was-svr01에서만 백엔드 애플리케이션을 띄워주면
was-svr02에서도 따라서 자동으로 돌아가지는 않을까?”

 

직감적으로는 “아닐 것 같다”였지만,
서버 이미지를 사용하는 구조를 정확히 정리해두고 싶었다.

---

4. 서버 이미지에 대한 오해 풀기

핵심은 이것이다.

서버 이미지는 “과거의 디스크 스냅샷”이지,
“현재 원본 서버와 실시간으로 연결된 복제본”이 아니다.

 

조금 더 풀어보면:

• was-svr02는 과거의 어느 시점에
  “was-svr01의 디스크 상태를 한 번 떠서 만든 복사본”일 뿐이다.
• 그 이후부터는 각각 완전히 독립된 서버로 움직인다.
  • CPU도 다르고
  • 메모리도 다르고
  • 부팅/종료도 따로
  • 프로세스 실행도 따로

따라서:

• was-svr01에서 백엔드를 띄웠다고 해서, was-svr02에서 백엔드가 자동으로 뜨지 않는다.
• was-svr02도 직접 접속해서 똑같이 실행해줘야 한다.

# was-svr02에서도 직접 실행해야 한다
nohup java -jar image-platform-api.jar > app.log 2>&1 &

 

결론 2.
원본 서버(was-svr01)의 백엔드를 다시 실행해도,
그 서버 이미지로 만든 was-svr02의 애플리케이션이 자동으로 따라 실행되지는 않는다.
각 서버는 재부팅 후 각각 따로 띄워줘야 한다.

---

5. 여기까지 정리한 진실 2가지

이번 경험을 통해 다시 정리한 사실은 다음과 같다.

1. 재부팅 후 자동 실행 X
   • 서버를 껐다 켜면, nohup으로 돌고 있던 백엔드도 모두 종료된다.
   • 재부팅만으로는 애플리케이션이 자동으로 살지 않는다.
2. 이미지 기반 서버도 자동 연동 X
   • was-svr02는 was-svr01의 옛날 디스크 복사본일 뿐,
     “지금 이 순간의 was-svr01과 동기화된 쌍둥이”가 아니다.
   • 원본 서버에서 애플리케이션을 실행해도,
     이미지 기반 서버가 같이 살아나지는 않는다.
   • 결국 두 서버 각각에 접속해서 애플리케이션을 실행해야 한다.

이 두 가지를 정확히 이해하고 나니,
“내가 서버 이미지에게 과도한 기대를 하고 있었구나”라는 생각이 들었다.

---

6. 그렇다면, 어떻게 해야 더 편해질까? (systemd 도입)

여기까지가 “현실”이라면, 이제는 “해결책”을 고민할 차례다.

매번:

1. 서버를 재부팅하고
2. SSL VPN 접속해서
3.  nohup java -jar ...  를 서버 개수만큼 타이핑하는 것은

사람이 실수하기 딱 좋은 방식이다.
이럴 때 등장하는 것이 바로 systemd다.

---

7. systemd로 백엔드 자동 실행시키기 (요약)

systemd는 요즘 리눅스 배포판에서 기본으로 사용하는 서비스 관리 시스템이다.
우리가 원하는 건 딱 이거다:

• 서버 부팅 시 자동으로 백엔드 애플리케이션 실행
• 애플리케이션이 죽으면 자동 재시작
•  systemctl status  로 상태 한 번에 확인
•  systemctl start/stop  으로 서비스처럼 관리

예시: Spring Boot JAR용 서비스 유닛 파일

 /etc/systemd/system/image-platform-api.service  파일을 만든다고 가정하면:

[Unit]
Description=Image Platform Backend API
After=network.target

[Service]
User=ec2-user
WorkingDirectory=/home/ec2-user/app
ExecStart=/usr/bin/java -jar image-platform-api.jar
Restart=on-failure

[Install]
WantedBy=multi-user.target

 

그리고 아래 순서로 활성화한다.

# 유닛 파일 변경 사항 반영
sudo systemctl daemon-reload

# 서비스 시작
sudo systemctl start image-platform-api

# 부팅 시 자동 실행 설정
sudo systemctl enable image-platform-api

# 상태 확인
sudo systemctl status image-platform-api

# 로그 확인
sudo journalctl -u image-platform-api -f

 

이렇게 설정해두면:

• web-svr01, web-svr02, was-svr01, was-svr02
  어느 서버를 재부팅하든 부팅과 함께 백엔드가 자동 실행된다.
• 프로세스가 죽으면 systemd가 다시 띄워준다.
• 여러 서버에 같은 유닛 파일만 복사하면 되니,
  “서버 수 × nohup 명령 수작업” 같은 패턴에서 벗어날 수 있다.

---

8. 마무리: 이번에 얻은 교훈

이번 일을 통해 얻은 개인적인 교훈은 다음과 같다.

• 서버 이미지는 “환경 복제”이지 “실행 상태 복제”가 아니다.
• 재부팅은 메모리 위 프로세스를 전부 날려버린다. nohup도 예외가 아니다.
• 원본 서버와 그 이미지 기반 서버는 “한 번 복사되고 끝인” 완전 독립체다.
• 운영 환경에서는 “수작업으로 nohup 돌리기”보다
  systemd와 같은 정식 프로세스 관리 도구를 사용하는 것이 훨씬 안전하고 효율적이다.

앞으로는 서버를 여러 대 운영할 때,
“재부팅하면 서비스 잘 떠 있을까?” 같은 막연한 기대 대신,

• systemd로 자동 실행을 구성했는지
• 각 서버에 동일하게 적용했는지

를 체크 리스트로 관리하려고 한다.

 

이 글이 나중에 같은 고민을 다시 할 미래의 나에게,

그리고 비슷한 상황을 겪는 누군가에게 작은 힌트가 되었으면 한다.