운영자가 말합니다. "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 · 미들웨어
앞단(정적·프록시)과 뒷단(동적 실행)
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| WAS | 동적 애플리케이션 실행 서버 | Tomcat 등 → [[web-was-structure]] | ★★ |
| Tomcat / Jetty / Netty | 자바 WAS·서버 | Tomcat이 주류 → [[tomcat-was]] | ★★ |
| Apache HTTPD / Nginx | Web Server(정적·프록시·SSL) | Nginx가 주류 → [[nginx-basics]] | ★★ |
| Context Path / Server Port / Port Binding | 앱 기준경로 / 포트 / 포트 점유 | 포트 충돌 단골 | ★★ |
구조 기본: Nginx(앞: 정적·SSL·프록시) → Tomcat(뒤: 동적 로직). 둘의 역할을 구분하면 "정적 파일이 안 떠요"(Nginx)와 "API가 500이에요"(WAS)의 방향이 갈립니다([[web-was-structure]]).
프로세스 · 시그널 · 종료
앱이 뜨고 지는 과정의 용어
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| Process / Daemon / PID | 실행 단위 / 백그라운드 / 프로세스 번호 | 기본 → [[process-port-resource]] | ★★ |
| Signal / SIGTERM / SIGKILL | 프로세스 신호 / 정상종료요청(15) / 강제종료(9) | kill -9 위험 → [[process-signals]] | ★★★ |
| Graceful Shutdown | 처리 중 요청 마치고 종료 | 무중단 배포 핵심 → [[twelve-factor-app]] | ★★★ |
| Startup Script / Shell Script | 기동 스크립트 / 셸 스크립트 | 자동화 → [[shell-scripting]] | ★★ |
| Systemd / Service Unit | 서비스 관리 / 유닛 정의 | 자동재시작 → [[service-startup]] | ★★ |
| Crontab / Logrotate | 예약 작업 / 로그 회전 | 주기 작업 → [[cron-scheduling]] | ★★ |
핵심 신호: SIGTERM(15)은 "정리하고 종료해", SIGKILL(9)은 "즉시 강제 종료"(정리 못 함, 데이터 손상 위험). 배포는 SIGTERM + graceful shutdown이 정석입니다([[process-signals]]).
로그 · 환경 · 자원 한도
운영을 들여다보는 창
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| Access Log / Error Log / Catalina Log / Application Log | 접근/에러/톰캣/앱 로그 | 어느 로그를 볼지 → [[glossary-observability]] | ★★ |
| Syslog / Journalctl | 시스템 로그 / systemd 로그 조회 | journalctl -u 서비스 → [[systemd-journal-advanced]] | ★★ |
| Environment Variable / PATH / JAVA_HOME | 환경변수 / 실행경로 / 자바 위치 | 설정 → [[glossary-config-env]] | ★★ |
| Heap Dump / Thread Dump / Core Dump | 메모리/스레드/코어 덤프 | 장애 분석 → [[jvm-operations]] | ★★ |
| File Descriptor / ulimit | 열린 파일·소켓 / 그 한도 | "Too many open files" | ★★ |
리눅스 진단 명령
장애 현장에서 가장 먼저 치는 명령들
| 명령 | 무엇을 보나 | 비고 | 중요도 |
|---|---|---|---|
| top / htop | CPU·메모리 실시간 | 범인 프로세스 → [[server-triage]] | ★★★ |
| 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 | 권한·압축 | 기본 운영 → [[file-permissions]] | ★ |
| ssh | 원격 접속 | 배스천 → [[ssh-advanced]] | ★★ |
핵심 흐름: 장애 시 top(무엇이 자원을 먹나) → ss(포트 떠 있나) → journalctl/로그(무슨 에러) → lsof(FD/포트 누수). 5단계 트리아지는 [[server-triage]]에서 실습합니다.
운영 에러 해독 — 직접 확인
운영 장애는 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로 범인 스레드 확인([[jvm-operations]]). 일시 스파이크면 부하·GC 의심
- ss -tlnp에 기대 포트(:8080)가 없으면 → 앱이 안 떴거나 죽은 것. 로그(catalina/app)부터 본다([[glossary-observability]])
- lsof로 센 FD 수가 ulimit -n에 근접하면 → "Too many open files" 임박. 소켓/파일 누수(안 닫음)인지, 한도가 낮은지 구분
- 배포 시 요청이 끊기면 graceful shutdown 미적용 → SIGTERM 후 유예시간 설정·앱의 종료 훅 확인([[process-signals]]·[[twelve-factor-app]])
상황: 롤링 배포([[release-strategy]]) 중 사용자가 간헐적으로 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은 [[twelve-factor-app]]의 일회성 프로세스 원칙이자 무중단 배포의 전제입니다.
인프라/SRE에게 이 용어들은 매일의 작업 언어입니다 — top/ss/lsof로 장애를 진단하고([[server-triage]]), systemd로 서비스를 관리하며([[service-startup]]), graceful shutdown으로 무중단 배포를 보장합니다([[twelve-factor-app]]). 깊은 실습은 Linux·infra-ops 트랙에 있습니다. PM은 이 용어를 알면 "배포할 때 끊겨요"를 "graceful shutdown 미적용"으로, "서버가 느려요"를 "CPU/FD/메모리 중 무엇"으로 좁혀, 개발·인프라에 정확한 질문을 던지고 재발 방지를 우선순위화할 수 있습니다.
다음 용어사전에서는 이 서버들을 잇는 네트워크와 보안 용어를 정리합니다.