운영자가 말합니다. "Tomcat이 graceful shutdown 안 돼서 배포 때 요청이 끊겨요. 자바 프로세스 CPU 100% 찍히고, Too many open files도 떴어요. systemd로 자동재시작은 되는데 catalina.out이 안 쌓여요." PM·인프라인 당신은 이 운영 용어들을 알아야 어디부터 봐야 할지 판단할 수 있습니다. 이 사전은 서버·WAS·리눅스 운영 용어를 빠르게 해독합니다. 깊은 실습은 Linux·infra-ops 트랙으로 연결합니다.
- 1Web Server·WAS·미들웨어 용어로 서버 구조를 읽을 수 있다
- 2프로세스·시그널·graceful shutdown으로 배포 시 동작을 이해할 수 있다
- 3systemd·로그·환경변수로 서비스 운영 기본을 설명할 수 있다
- 4리눅스 진단 명령(top/ps/ss/lsof 등)으로 장애 방향을 잡을 수 있다
Web Server · WAS · 미들웨어
확대
위 그림처럼 Nginx(앞)는 정적 파일·SSL·프록시를 담당하고, Tomcat(뒤)은 동적 Java 로직을 실행합니다. "정적 파일이 안 떠요"는 Nginx, "API가 500이에요"는 WAS로 방향을 가르면 진단이 빨라집니다.
앞단(정적·프록시)과 뒷단(동적 실행)
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| WAS | 동적 애플리케이션 실행 서버 | Tomcat 등 → Web Server와 WAS 미들웨어 구조의 이해 | ★★ |
| Tomcat / Jetty / Netty | 자바 WAS·서버 | Tomcat이 주류 → WAR 배포부터 server.xml 튜닝, 장애 대응까지 | ★★ |
| Apache HTTPD / Nginx | Web Server(정적·프록시·SSL) | Nginx가 주류 → Nginx 설치, 기본 설정, 정적 파일 서빙 실무 | ★★ |
| Context Path / Server Port / Port Binding | 앱 기준경로 / 포트 / 포트 점유 | 포트 충돌 단골 | ★★ |
구조 기본: Nginx(앞: 정적·SSL·프록시) → Tomcat(뒤: 동적 로직). 둘의 역할을 구분하면 "정적 파일이 안 떠요"(Nginx)와 "API가 500이에요"(WAS)의 방향이 갈립니다(Web Server와 WAS 미들웨어 구조의 이해).
프로세스 · 시그널 · 종료
확대
위 그림처럼 SIGTERM + Graceful Shutdown은 처리 중인 요청을 완료한 뒤 종료해 요청 유실이 없지만, SIGKILL은 즉시 강제 종료해 502 에러와 데이터 손상 위험이 생깁니다. 배포 시 SIGTERM이 정석입니다.
앱이 뜨고 지는 과정의 용어
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| Process / Daemon / PID | 실행 단위 / 백그라운드 / 프로세스 번호 | 기본 → 프로세스(ps), 포트(netstat), 리소스(top) 모니터링 실무 | ★★ |
| Signal / SIGTERM / SIGKILL | 프로세스 신호 / 정상종료요청(15) / 강제종료(9) | kill -9 위험 → kill/pkill 시그널의 종류와 프로세스 안전 종료 규칙 | ★★★ |
| Graceful Shutdown | 처리 중 요청 마치고 종료 | 무중단 배포 핵심 → 12-Factor App | ★★★ |
| Startup Script / Shell Script | 기동 스크립트 / 셸 스크립트 | 자동화 → Shell 스크립팅과 자동화 | ★★ |
| Systemd / Service Unit | 서비스 관리 / 유닛 정의 | 자동재시작 → systemd 서비스 등록과 자동 재시작 설정 | ★★ |
| Crontab / Logrotate | 예약 작업 / 로그 회전 | 주기 작업 → cron으로 리눅스 주기적 반복 작업(배치) 예약 및 백업 자동화 | ★★ |
핵심 신호: SIGTERM(15)은 "정리하고 종료해", SIGKILL(9)은 "즉시 강제 종료"(정리 못 함, 데이터 손상 위험). 배포는 SIGTERM + graceful shutdown이 정석입니다(kill/pkill 시그널의 종류와 프로세스 안전 종료 규칙).
로그 · 환경 · 자원 한도
운영을 들여다보는 창
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| Access Log / Error Log / Catalina Log / Application Log | 접근/에러/톰캣/앱 로그 | 어느 로그를 볼지 → 용어사전 | ★★ |
| Syslog / Journalctl | 시스템 로그 / systemd 로그 조회 | journalctl -u 서비스 → journalctl로 모든 커널/서비스 로그 검색 및 실시간 모니터링 | ★★ |
| Environment Variable / PATH / JAVA_HOME | 환경변수 / 실행경로 / 자바 위치 | 설정 → 용어사전 | ★★ |
| Heap Dump / Thread Dump / Core Dump | 메모리/스레드/코어 덤프 | 장애 분석 → Heap/GC/Thread Dump 분석과 OOM 대응 실무 | ★★ |
| File Descriptor / ulimit | 열린 파일·소켓 / 그 한도 | "Too many open files" | ★★ |
리눅스 진단 명령
확대
위 그림처럼 장애 시 top(자원 과점 프로세스) → ss(포트 LISTEN 여부) → 로그(에러 내용) → lsof(FD 누수) 순으로 범위를 좁힙니다. 무작정 재부팅하면 원인을 모른 채 재발합니다.
장애 현장에서 가장 먼저 치는 명령들
| 명령 | 무엇을 보나 | 비고 | 중요도 |
|---|---|---|---|
| top / htop | CPU·메모리 실시간 | 범인 프로세스 → 서버 다운 시 신속하게 CPU/메모리/네트워크/로그 확인하는 룰 | ★★★ |
| ps | 프로세스 목록 | ps -ef | grep | ★★ |
| ss / netstat | 포트·연결 상태 | LISTEN 포트 확인 | ★★ |
| lsof | 열린 파일·소켓·포트 | FD 누수·포트 점유 | ★★ |
| df / du / free | 디스크 / 용량 / 메모리 | 풀 알람 대응 | ★★ |
| iostat / vmstat | I/O·가상메모리 통계 | 병목 진단 | ★ |
| curl / wget / scp / sftp / rsync | HTTP / 다운로드 / 전송 | 점검·배포 | ★★ |
| sudo / chmod / chown / tar / gzip | 권한·압축 | 기본 운영 → chmod/chown으로 파일 읽기·쓰기·실행 권한 완벽 제어 | ★ |
| ssh | 원격 접속 | 배스천 → SSH 보안 설정과 서버 접속 하드닝 | ★★ |
핵심 흐름: 장애 시 top(무엇이 자원을 먹나) → ss(포트 떠 있나) → journalctl/로그(무슨 에러) → lsof(FD/포트 누수). 5단계 트리아지는 서버 다운 시 신속하게 CPU/메모리/네트워크/로그 확인하는 룰에서 실습합니다.
운영 에러 해독 — 직접 확인
운영 장애는 top·ss·로그·lsof로 영역을 가릅니다.
top -b -n1 | head -12 # CPU/메모리 범인
ss -tlnp | grep :8080 # 앱 포트 LISTEN 확인
ulimit -n # FD 한도
lsof -p <PID> | wc -l # 이 프로세스가 연 FD 수(한도 근접?)
top: java 프로세스 CPU 198% → Thread Dump로 어느 스레드인지([[jvm-operations]])
ss : :8080 LISTEN 없음 → 앱이 안 떴거나 죽음(로그 확인)
ulimit -n 1024 / lsof 990개 → FD 한도 근접 → 누수 or 한도 상향
top -b -n1 | head; ss -tlnp | head- top에서 특정 프로세스 CPU가 지속 100%+이면 → 그 프로세스(보통 java) Thread Dump로 범인 스레드 확인(Heap/GC/Thread Dump 분석과 OOM 대응 실무). 일시 스파이크면 부하·GC 의심
- ss -tlnp에 기대 포트(:8080)가 없으면 → 앱이 안 떴거나 죽은 것. 로그(catalina/app)부터 본다(용어사전)
- lsof로 센 FD 수가 ulimit -n에 근접하면 → "Too many open files" 임박. 소켓/파일 누수(안 닫음)인지, 한도가 낮은지 구분
- 배포 시 요청이 끊기면 graceful shutdown 미적용 → SIGTERM 후 유예시간 설정·앱의 종료 훅 확인(kill/pkill 시그널의 종류와 프로세스 안전 종료 규칙·12-Factor App)
상황: 롤링 배포(릴리스 전략) 중 사용자가 간헐적으로 502를 봅니다. 인스턴스를 교체하는 순간 처리 중이던 요청이 끊기는 것입니다.
원인: 프로세스가 SIGTERM을 받자마자 즉시 종료(graceful shutdown 미적용)해 진행 중 요청이 중단됩니다. 또는 로드밸런서가 인스턴스를 빼기 전에 프로세스가 먼저 죽습니다.
진단:
□ 앱이 SIGTERM 수신 시 진행 중 요청을 마치고 종료하나? (graceful)
□ 종료 전 헬스체크를 먼저 fail 시켜 LB가 트래픽을 빼게 하나?
□ 종료 유예시간(grace period)이 충분한가?
해결: (1) 앱에 graceful shutdown 구현 — SIGTERM 수신 시 새 요청 거부 + 진행 중 요청 완료 후 종료(Spring Boot는 server.shutdown=graceful). (2) 종료 순서를 'LB에서 빼기 → 유예 → 종료'로. (3) K8s면 preStop 훅 + terminationGracePeriodSeconds 설정. graceful shutdown은 12-Factor App의 일회성 프로세스 원칙이자 무중단 배포의 전제입니다.
심화 — 에러 코드와 자동 재시작이 감추는 것
심화: 502와 504는 다른 범인을 가리킨다
Nginx 뒤에 WAS를 두는 순간, 게이트웨이 에러 코드는 '어느 층이 문제인지' 알려주는 단서가 됩니다. 이 구분 하나로 장애 때 치는 첫 명령이 달라집니다.
- 502 Bad Gateway = 뒤가 없다: Nginx가 WAS로 연결을 시도했는데 거부·리셋된 것 — WAS가 죽었거나, 재시작 중이거나, 포트가 안 떠 있는 상태입니다. 첫 명령은
ss -tlnp(포트가 있나)와 프로세스 확인입니다. - 504 Gateway Timeout = 뒤가 느리다: WAS는 살아서 일하고 있는데 Nginx의 대기 한도 안에 응답을 못 준 것 — 슬로우 쿼리, 스레드 고갈, 외부 API 대기가 후보입니다. 첫 명령은 Thread Dump(Heap/GC/Thread Dump 분석과 OOM 대응 실무)와 슬로우 로그입니다. 같은 '게이트웨이 에러'지만 502에서 스레드 덤프를 뜨거나 504에서 포트를 확인하면 시간만 잃습니다.
- 타임아웃은 층마다 따로 있습니다: LB → Nginx → WAS → DB 각 층의 타임아웃이 어긋나면, 안쪽은 멀쩡히 일을 끝냈는데 바깥이 먼저 끊는 '유령 504'가 생깁니다. 원칙은 바깥 층의 타임아웃을 안쪽보다 길게 — 안쪽이 먼저 포기하고 명확한 에러를 돌려주게 만드는 것입니다.
- 면접의 다음 질문 — "유예시간 안에 안 끝나면요?": graceful shutdown을 구현했다는 답 다음에 나오는 질문입니다. 종료 유예시간은 가장 긴 정상 요청보다 길게 잡되, 그보다 오래 걸리는 작업은 애초에 동기 요청으로 받으면 안 된다(비동기 전환)는 것까지가 완결된 답입니다(kill/pkill 시그널의 종류와 프로세스 안전 종료 규칙).
"게이트웨이 에러가 났다"가 아니라 "502인가 504인가"를 먼저 묻는 것 — 이 한 질문이 트리아지(서버 다운 시 신속하게 CPU/메모리/네트워크/로그 확인하는 룰)의 방향을 절반 좁혀 줍니다.
상황: 사용자들이 "가끔 몇 초간 에러가 났다가 새로고침하면 된다"고 제보합니다. 모니터링상 서버는 항상 떠 있고 헬스체크도 통과합니다. 앱 로그에는 그 시각에 아무 에러도 없습니다.
원인: JVM 힙과 힙 외 메모리(메타스페이스·스레드 스택·네이티브)의 합이 서버 메모리를 넘어 커널 OOM killer가 java 프로세스를 강제 종료하고 있었고, systemd의 Restart=always가 몇 초 만에 되살려 왔습니다. 강제 종료라 앱은 로그를 남길 틈이 없고, 재시작이 빨라 헬스체크엔 '항상 정상'으로 보입니다 — 자동 복구가 반복 장애를 은폐한 것입니다.
진단:
journalctl -k | grep -i 'out of memory' # 커널 로그의 OOM kill 기록
systemctl status myapp # 재시작 횟수·마지막 기동 시각
ps -o etime= -p $(pgrep -f myapp) # 프로세스 나이 — 서버 uptime보다 훨씬 짧으면 신호
해결: (1) 힙 크기를 '서버 메모리 − 힙 외 사용분' 이하로 조정하고, 메모리가 계속 자라는 원인은 Heap Dump로 분석합니다(Heap/GC/Thread Dump 분석과 OOM 대응 실무). (2) 재시작 발생 자체를 알람으로 만듭니다 — systemd 재시작 카운트나 프로세스 나이를 모니터링에 올려 '조용한 반복 죽음'이 숨지 못하게 합니다(용어사전). (3) 자동 재시작(systemd 서비스 등록과 자동 재시작 설정)은 복구 수단이지 원인 조사를 대신하지 않습니다 — "죽어도 금방 살아나니 괜찮다"는 판단이 이 장애를 몇 주간 키웠습니다.
인프라/SRE에게 이 용어들은 매일의 작업 언어입니다 — top/ss/lsof로 장애를 진단하고(서버 다운 시 신속하게 CPU/메모리/네트워크/로그 확인하는 룰), systemd로 서비스를 관리하며(systemd 서비스 등록과 자동 재시작 설정), graceful shutdown으로 무중단 배포를 보장합니다(12-Factor App). 깊은 실습은 Linux·infra-ops 트랙에 있습니다. PM은 이 용어를 알면 "배포할 때 끊겨요"를 "graceful shutdown 미적용"으로, "서버가 느려요"를 "CPU/FD/메모리 중 무엇"으로 좁혀, 개발·인프라에 정확한 질문을 던지고 재발 방지를 우선순위화할 수 있습니다.
다음 용어사전에서는 이 서버들을 잇는 네트워크와 보안 용어를 정리합니다.
용어 식별 실습으로 굳히기: 용어 식별 — Server / WAS / Linux 운영 — 증상·로그·명령을 보고 WAS·시그널·진단 용어를 가려냅니다.