시나리오새벽 3시에 서비스 알람이 울립니다. 담당자가 일어나서 systemctl restart app을 치고 다시 잡니다. 한 달 뒤 같은 일이 반복됩니다. 자동 재시작 스크립트를 짜놨더니 이번엔 서비스가 계속 죽으면서 재시작을 무한 반복하고, 디스크가 로그로 가득 차버렸습니다. Prometheus 같은 모니터링 도구를 쓰기엔 환경 제약이 있을 때, 올바르게 설계된 헬스체크 스크립트가 새벽 호출을 막아주는 유일한 방어선이 됩니다.헬스체크 & 자가복구 스크립트Prometheus, Grafana, Datadog — 훌륭한 도구들이지만 모든 환경에서 쓸 수 있는 건 아닙니다. 사내 레거시 서버, 고객사 온프레미스 환경, 인터넷이 격리된 망분리 시스템에서는 경량 셸 스크립트가 유일한 모니터링 수단이 되기도 합니..

시나리오서버를 인터넷에 공개한 지 며칠 만에 /var/log/auth.log를 보니 다른 나라 IP에서 SSH 로그인을 수백 번 시도한 흔적이 있습니다. root 계정 비밀번호 인증이 열려있는 상태였습니다. 보안 감사에서는 웹 서버 프로세스가 root 권한으로 실행되고 있다는 사실도 드러났습니다. 공격자가 SQL 인젝션 하나로 서버를 전부 장악할 수 있는 상태였습니다. OS 하드닝은 서버를 켜는 순간부터 필요한 기본 작업입니다.OS 보안 하드닝이번 챕터에서 배울 것1최소 권한 원칙(PoLP)을 이해하고 공격 표면(Attack Surface) 축소 전략을 적용할 수 있다2sshd_config로 root 로그인 차단·키 인증·접근 계정 제한을 설정할 수 있다3fail2ban으로 SSH 브루트포스를 자동 차단..

시나리오새벽에 개발자가 rm -rf /var/www/html 을 프로덕션 서버에서 잘못 실행했습니다. 백업이 있었지만 마지막 백업이 2주 전이었고, 그 사이 추가된 사용자 데이터는 복구 불가능했습니다. 다른 팀에서는 랜섬웨어에 감염되어 백업까지 같은 서버에 있었기 때문에 모두 암호화됐습니다. 체계적인 3-2-1 백업 전략과 자동화된 rsync 스크립트가 있었다면, 재앙이 아닌 단순한 복구 작업으로 끝났을 겁니다.서버 백업 & 데이터 보호데이터 손실은 "만약에"가 아니라 "언제"의 문제입니다. 디스크는 반드시 죽고, 랜섬웨어는 예고 없이 찾아오며, 실수로 rm -rf를 잘못 입력하는 순간은 누구에게나 옵니다. 체계적인 백업은 그 순간을 재앙이 아닌 단순한 복구 작업으로 바꾸어 줍니다.이 챕터에서는 tar와..

시나리오새벽 2시, 모니터링 알람이 울립니다. "메모리 사용률 95%". 서버에 급히 접속해 free -h를 실행했더니 used가 높고 free는 거의 없습니다. 그런데 available은 아직 여유가 있습니다. 진짜 위기인지 아닌지 판단이 서지 않습니다. 그 사이 OOM Killer가 조용히 핵심 프로세스를 종료해버렸고, 서비스는 아무 에러 없이 그냥 멈춰있습니다. free -h의 숫자를 읽는 법과 OOM Killer가 무엇을 죽일지를 미리 알았다면 위기를 조기에 차단할 수 있었을 겁니다.메모리 관리 & Swap새벽 2시, 모니터링 알람이 울립니다. "메모리 사용률 95%". 심장이 빨라집니다. 지금 당장 서버가 죽을까요? 아니면 그냥 지켜봐도 될까요?정답은 **"알람만으로는 알 수 없다"**입니다. ..

시나리오자정에 API 서버가 조용히 죽었습니다. 모니터링 알림은 새벽 1시에 왔고, 그때는 이미 서버가 재시작된 뒤였습니다. /var/log/app.log를 열었더니 재시작 이후 로그만 있었습니다. journald는 기본 설정 그대로라 재부팅과 함께 메모리 로그가 날아간 상태였습니다. 장애가 왜 시작됐는지, 어느 프로세스가 먼저 죽었는지, OOM이 개입했는지 — 아무것도 알 수 없었습니다. journald를 제대로 구성해두었다면 재부팅 직전까지의 전체 타임라인이 한 곳에 모여 있었을 겁니다.journald 심화 — 로그로 모든 것을 추적하는 법자정에 API 서버가 조용히 죽었습니다. 모니터링 알림은 새벽 1시에 왔고, 그때는 이미 서버가 재시작된 뒤였습니다. /var/log/app.log를 열었더니 재시..

시나리오오전에 출근해 모니터링을 보니 서버 디스크가 98%입니다. df -h로 확인하니 /var/log가 40GB를 차지하고 있었습니다. nginx 액세스 로그 파일 하나가 30GB였습니다. 지난 6개월치 로그가 압축도 안 된 채 그대로 쌓여 있었던 겁니다. logrotate를 설정했다고 생각했는데, 커스텀 애플리케이션 로그는 설정에서 빠져 있었습니다. 로그는 사고 분석에 반드시 필요하지만, 관리되지 않으면 디스크를 갉아먹어 서비스 장애를 유발합니다.로그 관리 & logrotate운영 서버에서 가장 조용하게 장애를 유발하는 원인 중 하나는 디스크 풀(Disk Full) 입니다. 그리고 그 주범은 대부분 통제되지 않은 로그 파일입니다. 로그는 필수적이지만, 관리되지 않으면 수 GB를 순식간에 차지합니다. ..

시나리오JWT 인증 토큰이 간헐적으로 거부된다는 문제 신고가 들어왔습니다. 로그를 보니 token issued in the future 에러입니다. 코드 변경은 없었는데 왜 갑자기? 원인을 추적해보니 서버 중 한 대의 시계가 다른 서버보다 30초 빠르게 맞춰져 있었습니다. 클라우드 VM이 마이그레이션된 이후 NTP 데몬이 재시작되지 않아 시계가 조금씩 벗어났던 겁니다. 분산 시스템에서는 서버마다 시간이 같아야 한다는 전제 조건이 있고, 그게 깨지면 인증과 로그 분석이 모두 엉킵니다.시간 동기화 (NTP & chrony)서버의 시스템 시계가 몇 초만 틀려도 JWT 인증 토큰 검증 실패, TLS 핸드셰이크 오류, 로그 순서 뒤집힘 같은 장애가 발생합니다. 클라우드 환경에서는 VM이 일시 정지(sleep/mi..

시나리오새벽 3시, DB 백업 스크립트가 실행됐어야 하는데 다음 날 아침에 확인해보니 결과물이 없습니다. crontab에 분명히 등록했는데 왜 안 됐는지 알 방법조차 없습니다. 로그도 없고, 에러도 없고, 그냥 조용히 실패한 겁니다. 반대로 디스크가 서서히 가득 차가는데, 매주 정리해야 할 로그 파일을 지우는 작업을 매번 수동으로 하고 있다면? cron을 제대로 이해하면 이 두 문제가 모두 해결됩니다.Cron & 작업 스케줄링서버는 잠들지 않습니다. 새벽 2시에 데이터베이스를 백업하고, 매주 일요일마다 오래된 로그를 정리하고, 매시간 디스크 사용량을 체크하는 일들을 사람이 직접 할 수는 없습니다. 이런 반복 작업을 자동화하는 것이 cron과 systemd timer입니다.cron은 Unix 시스템에서 수..

" - "## cloud-init" answer: 1 explanation: "#cloud-config 헤더로 시작하면 cloud-init이 해당 내용을 YAML cloud-config 형식으로 파싱합니다. 이 형식에서 packages, runcmd, write_files 등의 디렉티브를 사용할 수 있습니다."q: "cloud-config에서 첫 부팅 시 임의 명령을 실행하려면 어떤 디렉티브를 사용합니까?"options:"commands:""scripts:""runcmd:""exec:"answer: 2explanation: "runcmd 디렉티브는 cloud-init이 완료된 후 실행할 쉘 명령 목록을 지정합니다. 각 항목은 문자열이나 리스트로 작성할 수 있으며, 순서대로 한 번 실행..

시나리오포트를 열었는데 외부에서 "Connection timed out"이 납니다. ss -tlnp에는 포트가 LISTEN 상태인데도 마찬가지입니다. 방화벽 규칙을 확인해야 하는데 이 서버에서 iptables, firewalld, ufw 중 어느 도구가 실제로 작동하는지도 모르는 상태입니다. 더 위험한 상황은 반대쪽에서 옵니다 — SSH 포트를 바꾸다 방화벽 오픈 없이 재시작해서 서버에서 완전히 잠기는 Lock-out 입니다.방화벽 (firewalld & iptables)이번 챕터에서 배울 것1netfilter → iptables → Tables·Chains·Rules 3계층 구조를 설명할 수 있다2iptables 규칙을 조회·추가·삽입·삭제하고 iptables-save로 영구 저장할 수 있다3connt..