opsnote - 초보 인프라 노트

운영 중인 리눅스 서버에서 서비스가 갑자기 내려갔다는 연락을 받으면 가장 먼저 떠오르는 대응 중 하나가 재시작입니다.systemctl restart 서비스명 서비스를 빨리 살려야 하는 상황에서는 필요한 조치일 수 있습니다.하지만 바로 재시작해 버리면 왜 서비스가 종료됐는지 확인할 수 있는 단서를 놓칠 수 있습니다.특히 메모리 부족으로 Linux 커널의 OOM Killer가 프로세스를 종료한 상황이라면 단순히 서비스를 다시 올리는 것만으로는 원인이 해결되지 않습니다.저라면 서비스가 갑자기 죽었을 때 다음 순서로 확인합니다.서비스 종료 확인→ OOM 로그 확인→ 어떤 프로세스가 종료됐는지 확인→ 현재 메모리와 Swap 확인→ 메모리를 많이 사용하는 프로세스 확인→ 서비스 상태와 로그 확인→ 조치→ 재확인이번..

리눅스 서버를 운영하다 보면 이런 말을 들을 때가 있습니다.서버가 느립니다.화면이 늦게 뜹니다.요청 응답이 평소보다 오래 걸립니다.처음에는 CPU부터 보게 됩니다.top을 열어봤는데 CPU 사용률이 생각보다 높지 않습니다.그러면 초보 운영자 입장에서는 이런 생각이 들 수 있습니다.CPU는 낮은데 왜 서버가 느리지?서버 문제는 아닌가?애플리케이션 문제인가?그냥 일시적인 현상인가?저도 처음에는 CPU 사용률만 보고 판단하려고 했습니다.그런데 운영 서버에서는 CPU 사용률이 낮아 보여도 서버가 느릴 수 있습니다.이럴 때 같이 봐야 하는 것이 Load Average와 wa입니다.Load Average는 서버에 얼마나 많은 작업이 밀려 있는지 보는 데 도움이 됩니다.wa는 CPU가 일을 못 해서 노는 것이 아니라..

리눅스 서버나 웹 서비스를 운영하다 보면 이런 말을 들을 때가 있습니다.서버는 살아 있는 것 같은데 사이트가 안 열립니다.ping은 됩니다.그런데 브라우저에서는 접속이 안 됩니다.처음에는 헷갈립니다.ping이 되면 서버가 살아 있는 것처럼 보입니다.그래서 초보 운영자 입장에서는 “네트워크는 정상인데 왜 사이트가 안 열리지?”라는 생각이 들 수 있습니다.저도 처음에는 ping 결과를 보고 꽤 안심했던 적이 있습니다.하지만 운영 서버에서는 ping이 된다는 것과 웹 서비스가 정상이라는 것은 전혀 다른 이야기입니다.ping은 주로 ICMP 응답을 확인합니다.반면 웹사이트 접속은 TCP 포트, 웹서버, 애플리케이션, 인증서, 라우팅, DNS, HTTP 응답까지 함께 봐야 합니다.이번 글에서는 ping은 되는데 ..

리눅스 서버를 운영하다 보면 서비스가 안 뜨는 상황을 만날 때가 있습니다.처음에는 단순하게 보입니다.서비스가 안 뜬다.프로세스가 죽은 것 같다.restart 하면 되지 않을까?저도 처음에는 이렇게 생각했습니다.그런데 운영 서버에서는 서비스가 안 뜬다고 바로 restart부터 하는 것이 항상 좋은 선택은 아닙니다.서비스가 실패한 이유를 확인하지 않고 재기동하면, 잠깐 살아나는 것처럼 보여도 같은 문제가 다시 반복될 수 있습니다.또는 실패 원인이 로그에 남아 있었는데 재기동 과정에서 중요한 단서를 놓칠 수도 있습니다.이번 글에서는 리눅스 서버에서 서비스가 안 뜰 때, systemctl status와 journalctl을 이용해서 원인을 좁혀가는 실제 점검 흐름을 정리해보겠습니다.핵심은 단순합니다.서비스가 안..

리눅스 서버를 운영하다 보면 디스크 용량 알림을 받을 때가 있습니다.처음에는 단순하게 보입니다.디스크가 90%를 넘었다.공간이 부족하다.큰 파일 몇 개만 지우면 되지 않을까?저도 처음에는 이렇게 생각했습니다.그런데 운영 서버에서는 디스크 용량 알림을 단순한 청소 문제로 보면 위험할 수 있습니다.디스크가 찼다고 바로 파일을 삭제하면 장애 원인을 확인할 로그를 지워버릴 수 있고, 서비스가 아직 사용 중인 파일을 건드릴 수도 있습니다.특히 /var, /tmp, /data, 애플리케이션 로그 경로, 백업 경로는 각각 성격이 다르기 때문에 같은 방식으로 판단하면 안 됩니다.이번 글에서는 리눅스 서버에서 디스크 용량 90% 알림을 받았을 때, 실제 운영 상황에서 어떤 순서로 확인하면 좋은지 정리해보겠습니다.핵심은 ..

리눅스 서버를 운영하다 보면 가장 자주 듣는 말 중 하나가 있습니다.접속이 안 됩니다.사이트가 안 열립니다.서버가 죽은 것 같습니다.도메인이 안 됩니다.포트가 막힌 것 같습니다. 처음 들으면 마음이 급해집니다.서버에 바로 접속해보고, ping을 날려보고, 방화벽부터 떠올리게 됩니다.하지만 접속 장애는 생각보다 원인이 다양합니다.서버 자체가 죽은 것일 수도 있고, 서비스 프로세스가 내려간 것일 수도 있습니다.포트는 열려 있는데 HTTP 응답이 이상할 수도 있고, DNS가 다른 IP를 바라보고 있을 수도 있습니다.중간 네트워크 구간에서 막힌 것처럼 보여도 실제로는 특정 장비가 응답을 제한하는 경우도 있습니다.그래서 접속 장애는 한 가지 명령어만 보고 판단하면 위험합니다.이 글에서는 리눅스 서버에서 접속 장애..

리눅스 서버를 운영하다 보면 디스크 용량 문제는 생각보다 자주 만납니다.처음에는 단순해 보입니다.디스크가 찼다.공간이 부족하다.큰 파일을 지우면 된다. 하지만 운영 서버에서는 이렇게 바로 생각하면 위험합니다.디스크가 찼다는 말 안에는 여러 상황이 섞여 있습니다./가 찬 것인지, /var가 찬 것인지, /tmp가 찬 것인지, 로그가 커진 것인지, inode가 부족한 것인지, 삭제한 파일을 프로세스가 계속 잡고 있는 것인지에 따라 확인 순서가 달라집니다.초보 운영자가 가장 하기 쉬운 실수는 df -h에서 Use%만 보고 바로 삭제할 파일을 찾는 것입니다.Use% 90%?큰 파일 하나 지우면 되겠지? 하지만 디스크 문제에서 중요한 건 “무엇을 지울까”가 아니라 어디가 왜 찼는지 먼저 확인하는 것입니다.이 글에..

리눅스 서버를 운영하다 보면 어느 날 갑자기 이런 말을 듣게 됩니다.서버가 느립니다.접속이 안 됩니다.서비스가 안 뜹니다.디스크가 가득 찼습니다.로그가 계속 쌓입니다.재기동하면 될까요? 처음에는 마음이 급해집니다.서버 화면을 열고, top을 보고, df -h를 보고, 로그를 열어보다가 어느 순간 이런 생각이 듭니다.뭘 먼저 봐야 하지?이거 바로 재기동해도 되나?파일 하나 지워도 괜찮은 건가? 초보 운영자에게 가장 어려운 부분은 명령어 자체보다 순서입니다.명령어를 하나씩 아는 것도 중요하지만, 운영 서버에서는 어떤 순서로 확인하고 어느 시점에서 조치할지 판단하는 것이 더 중요합니다.순서를 잘못 잡으면 장애를 해결하기보다 원인 단서를 먼저 지워버릴 수 있습니다.로그를 지우거나, 프로세스를 종료하거나, 서버를..

리눅스 서버에서 /var 용량이 가득 차면 단순히 디스크 공간이 부족한 문제로 끝나지 않을 수 있습니다. /var에는 로그, 캐시, 스풀, 패키지 데이터, 애플리케이션 상태 파일이 쌓이는 경우가 많아서 서버 운영 중 /var가 차면 로그 기록 실패, 서비스 기동 실패, 배치 오류, 패키지 설치 실패 같은 장애로 이어질 수 있습니다.이번 글에서는 /var 용량 부족 알림이 떴을 때 바로 삭제하지 않고, 어떤 경로가 커졌는지 구분한 뒤 안전하게 확인하는 순서를 정리해보겠습니다./var에는 뭐가 쌓일까?/var는 이름 그대로 변하는 데이터가 많이 쌓이는 경로입니다.대표적으로 이런 것들이 있습니다./var/log → 시스템 로그, 서비스 로그/var/cache → 패키지 캐시, 애플리케이션 캐시/..

리눅스 서버에서 /tmp 용량이 가득 차면 파일 업로드 실패, 압축 해제 실패, 배치 오류, 애플리케이션 임시파일 생성 실패 같은 문제가 생길 수 있습니다. 이때 초보 운영자는 “임시파일이니까 지워도 되겠지”라고 생각하고 rm -rf /tmp/*를 실행하기 쉽지만, 운영 서버에서는 현재 프로세스가 사용 중인 임시파일, 소켓 파일, lock 파일까지 지워서 장애를 키울 수 있습니다.이번 글에서는 서버 운영 중 /tmp 용량이 찼을 때 df -h, du, find, lsof로 무엇이 쌓였는지 확인하고, 오래된 파일과 사용 중인 파일을 구분해 안전하게 점검하는 순서를 정리합니다./tmp는 어떤 곳일까?/tmp는 이름 그대로 임시파일이 저장되는 경로입니다.애플리케이션, 배치 작업, 압축 해제, 업로드 처리, 패..