Linux Server 운영 기본
3줄 요약
- Linux 서버 운영 기본은 Spring 애플리케이션이 실제 서버에서 어떤 사용자로 실행되고, 어떤 프로세스로 떠 있으며, 어떤 포트와 로그와 디스크를 사용하는지 확인하는 능력이다.
- 핵심은 명령어 암기가 아니라 장애 중
권한 문제, 프로세스 문제, 포트/방화벽 문제, 로그/디스크/자원 문제를 안전하게 분리하는 것이다.
- 운영 서버에서는 읽기 명령과 변경 명령을 구분하고, 변경 전에는 영향 범위와 되돌리는 방법을 확인해야 한다.
핵심 정리
- Spring 프로세스를
root로 띄우면 편해 보이지만 파일 손상, 권한 오남용, 침해 사고의 범위가 커진다. 별도 app 사용자와 필요한 디렉터리 권한을 두는 편이 안전하다.
- 프로세스가 살아 있다는 사실만으로 API가 정상이라는 뜻은 아니다. 잘못된 profile, 포트 충돌, file permission, OOM, disk full, log write 실패가 함께 확인되어야 한다.
systemd는 jar 실행 명령을 서비스 단위로 관리하고, 재시작 정책, 환경 파일, 로그, 종료 신호를 일관되게 만든다.- 포트 문제는
listen, firewall, Nginx/LB upstream, SSH 접근을 나누어 봐야 한다. connection refused와 timeout은 원인 후보가 다르다.
- 로그와 자원 점검은 장애 중 가장 먼저 하는 읽기 작업이다.
journalctl, df, du, free, top, ss 출력은 실행 시각과 서비스명을 함께 남겨야 한다.
- 운영 서버의 위험 명령은 명령 자체보다 대상과 권한이 문제다.
rm, chmod, chown, kill -9, reboot, firewall 변경은 항상 확인 명령과 rollback 계획을 먼저 둔다.
헷갈리는 지점
- SSH로 접속할 수 있으면 서버가 정상이라고 생각하기 쉽다.
- 핵심은 SSH는 관리 경로이고, 사용자 트래픽 경로는 프로세스, 포트, 프록시, 방화벽, 애플리케이션 상태를 모두 지난다는 점이다.
systemctl restart를 빠른 복구로만 생각하기 쉽다.
- 핵심은 restart가 원인을 지우거나 장애를 반복시킬 수 있다는 점이다. 로그와 최근 변경을 먼저 확인해야 한다.
- 디스크 사용률이 100%가 아니면 안전하다고 보기 쉽다.
- 핵심은 inode 고갈, 특정 로그 디렉터리 포화, journal 용량, 임시 파일 증가도 Spring 서비스 실패를 만들 수 있다는 점이다.
확인 질문
- Linux 서버에서 Spring API 장애를 볼 때 가장 먼저 나눌 계층은 무엇인가?
- 실행 사용자와 권한, 프로세스 상태, 포트 listen, 방화벽/프록시 경로, 로그, 디스크와 CPU/memory 상태다.
- 운영 서버에서 변경 명령을 바로 실행하면 안 되는 이유는 무엇인가?
- 대상 경로와 영향 범위를 잘못 잡으면 데이터 삭제, 권한 손상, 접속 차단, 서비스 중단이 즉시 발생할 수 있기 때문이다.
- 인프라 담당자에게 서버 문제를 공유할 때 필요한 증거는 무엇인가?
- 시간대, 서비스명, 실행 사용자, PID, 포트 상태, 최근 systemd 로그, disk/resource 출력, 이미 실행한 명령과 결과다.