## 시작하며: 갑작스러운 서버 재부팅과 마주하다
서버 재부팅은 언제나 긴장되는 순간입니다. 특히 여러 팀이 협업하는 환경에서는 "어떤 서비스가 어디서 돌아가고 있는지" 정확히 파악하지 못한 채 재부팅을 맞이하면, 복구 과정이 혼란스러워질 수 있습니다.
이번 글에서는 서버 재부팅 후 서비스 복구 과정에서 진행했던 **전체 인프라 서비스 인벤토리 작성 경험**을 공유하고, 이를 통해 얻은 실무 노하우를 정리해보겠습니다.
## 본론: 인프라 인벤토리 전수조사 진행
### 1. 현황 파악의 중요성
재부팅 후 가장 먼저 해야 할 일은 **전체 서비스 현황을 파악**하는 것입니다. 우리는 다음과 같은 환경을 조사했습니다:
- 데이터베이스 서버: 25개 Docker 컨테이너, 6개 systemd 서비스
- 애플리케이션 서버: 가상화 환경 및 주요 앱
- 여러 VM 환경: 개발/스테이징/프로덕션 용도로 구분된 총 77개 이상의 컨테이너와 서비스
### 2. 주요 복구 사례와 해결 방법
복구 과정에서 마주한 대표적인 문제들과 해결 방법은 다음과 같습니다:
#### (1) Python 경로 문제
```bash
# systemd 서비스 파일에서 Python 경로 확인
sudo systemctl status your-service.service
# ExecStart 경로 수정
sudo vim /etc/systemd/system/your-service.service
# ExecStart=/usr/bin/python3 /path/to/script.py
sudo systemctl daemon-reload
sudo systemctl restart your-service.service
```
#### (2) 데이터베이스 연결 정보 불일치
재부팅 후 일부 서비스의 데이터베이스 포트 설정이 변경되어 있었습니다.
```bash
# 환경변수 또는 설정 파일에서 DB 포트 확인
cat /path/to/config.env | grep DB_PORT
# PostgreSQL 연결 테스트
psql -h localhost -p 51030 -U username -d database
```
#### (3) Docker 고아 컨테이너 정리
```bash
# 중지된 컨테이너 확인
docker ps -a --filter "status=exited"
# 고아 컨테이너 정리
docker container prune -f
# 특정 컨테이너 재시작
docker restart container-name
```
### 3. 인벤토리 문서화 전략
복구 과정에서 가장 중요한 것은 **문서화**였습니다. 우리가 작성한 인벤토리 문서에는 다음 정보를 포함했습니다:
- **서비스 목록**: 각 서버별 실행 중인 모든 서비스
- **재시작 절차**: 서비스별 올바른 재시작 순서 및 명령어
- **DB 연결 정보**: 각 서비스가 사용하는 데이터베이스 및 포트
- **의존성 관계**: 서비스 간 의존성 매핑
- **담당자 정보**: 각 서비스의 소유권 및 연락처
### 4. 예방을 위한 체크리스트
이번 경험을 바탕으로 다음과 같은 예방 체크리스트를 만들었습니다:
```markdown
## 서비스 인벤토리 관리 체크리스트
- [ ] 모든 서버의 서비스 목록 문서화
- [ ] 각 서비스의 자동 재시작 설정 확인 (systemd restart=always 등)
- [ ] 데이터베이스 연결 정보 중앙 관리
- [ ] 서비스별 헬스체크 엔드포인트 구현
- [ ] 모니터링 알림 설정 (서비스 다운 시 즉시 통지)
- [ ] 분기별 인벤토리 리뷰 및 업데이트
```
## 결론: 인벤토리 관리는 재해 복구의 핵심
서버 재부팅이라는 예상치 못한 상황은 오히려 **전체 인프라를 재점검할 수 있는 기회**가 되었습니다. 특히 다음 세 가지 교훈을 얻었습니다:
1. **문서화는 선택이 아닌 필수**: 머릿속 지식이 아닌 문서로 남겨야 팀 전체가 대응할 수 있습니다.
2. **자동화 가능한 부분은 자동화**: systemd 자동 재시작, Docker restart policy 등을 적극 활용해야 합니다.
3. **정기적인 인벤토리 리뷰**: 서비스는 계속 추가되므로 분기별 리뷰가 필요합니다.
다음 단계로는 Infrastructure as Code(IaC) 도구(Terraform, Ansible 등)를 활용해 인프라 상태를 코드로 관리하는 방안을 검토 중입니다. 이를 통해 재해 복구 시간을 더욱 단축할 수 있을 것으로 기대합니다.
여러분의 인프라 관리 노하우도 댓글로 공유해주시면 감사하겠습니다!