EC2의 EBS 볼륨을 늘렸는데 서버에서는 여전히 기존 용량만 보이는 경우가 있습니다. 비용을 더 투자해서 스토리지를 늘렸는데 안보이니 우선 파일시스템이 의심갑니다. AWS에서 확보한 저장 공간이 곧바로 파일시스템의 사용 가능 공간이 되는 것은 아니기 때문입니다. Linux 서버에서 볼륨, 파티션, 파일시스템을 어떤 순서로 확인할지 살펴보겠습니다. 확장된 볼륨과 실제 사용 공간의 차이EBS 볼륨은 서버에 연결된 저장 장치이고, 파티션은 그 장치를 나눈 영역입니다. 파일시스템은 그 위에서 파일을 저장하고 관리합니다. 구성에 따라 파티션 없이 볼륨 전체에 파일시스템을 만들거나, 중간에 LVM 논리 볼륨을 둘 수도 있습니다.예를 들어 디스크 볼륨을 50G에서 100G로 늘렸더라도 파티션과 파일시스템이 이전 ..

점검을 마친 EC2 인스턴스가 실행 중인데도 외부 시스템에서 접속하지 못한다면 공인 IP부터 확인해 볼 만합니다. 작업자가 말한 “서버 재시작”이 EC2의 재부팅인지, 인스턴스를 중지한 뒤 다시 시작한 것인지에 따라 외부에서 접근 가능한 주소의 처리 방식이 달라집니다. 이 글은 Elastic IP를 사용하지 않고 DHCP IPv4로 직접 통신하는 EC2를 중심으로 설명합니다. 재부팅과 중지 후 시작의 주소 차이 EC2 콘솔 자체의 재부팅(Reboot)은 운영체제 재시작에 해당하며 기존 공인 IPv4 주소를 유지합니다. AWS는 프라이빗 IPv4와 인스턴스 스토어 데이터도 재부팅 시 유지된다고 설명합니다. AWS — EC2 인스턴스 재부팅반면 중지(Stop)하면 자동 할당된 공인 IPv4가 해제됩니다...

SSH 키를 바꾼 뒤 터미널에서는 접속되는데 자동 배포만 실패할 수 있습니다. 이때 수동 접속 성공은 배포 작업도 새 키를 사용한다는 증거가 아닙니다. 두 작업이 같은 서버에 접속하더라도 실행하는 계정과 읽는 파일, 인증 정보를 전달받는 환경이 다를 수 있기 때문입니다. 접속 계정과 실행 계정부터 분리가령 관리자는 노트북에서 접속하고 배포는 별도 Linux 실행기에서 수행하는 상황을 가정하겠습니다. 노트북의 키만 교체했다면 실행기에 남은 키는 그대로일 수 있습니다. 같은 서버에서 실행하더라도 관리자 계정과 배포 서비스 계정은 서로 다른 설정을 읽을 수 있습니다.먼저 작업을 실행하는 로컬 계정과 원격 서버에 로그인하는 계정을 나눠 기록합니다. 아래 명령은 배포 작업 안에서 실행하는 예시입니다. deplo..

서버에서 애플리케이션이 갑자기 사라졌는데 재시작 후에는 정상으로 보일 때가 있다. 이때 현재 메모리 사용량만 보면 종료 당시의 상황을 놓칠 수 있다. 커널의 OOM(Out of Memory) 기록을 확인하면 종료 시각과 대상 프로세스를 찾고, 서버 전체의 메모리 압박인지 특정 서비스의 제한인지 조사 범위를 좁힐 수 있다. OOM 기록이 알려주는 것과 알려주지 않는 것 커널은 메모리 확보에 실패한 상황에서 OOM killer를 호출해 프로세스를 종료할 수 있다. 다만 메모리 할당 실패가 모두 OOM killer의 실행으로 이어지는 것은 아니다. 커널 로그에 남은 종료 대상은 그 시점에 선택된 프로세스이지, 메모리 부족을 처음 일으킨 유일한 원인이라는 뜻은 아니다.서버 전체에 여유가 없어 발생하는..

같은 Docker 이미지를 운영 환경과 테스트 환경에 배포했는데 설정값을 바꾸려면 이미지를 다시 만들어야 할까요? 답은 설정이 저장된 위치와 애플리케이션이 값을 읽는 시점에 따라 달라집니다. 이미지 안에 포함된 파일과 컨테이너 생성 시 외부에서 전달한 설정을 구분하면 변경 범위와 확인 순서를 정하기 쉽습니다.이미지에 복사한 설정은 이미지 버전의 일부입니다Dockerfile의 COPY로 설정 파일을 넣으면 빌드 당시 파일이 이미지에 포함됩니다. 이후 원본 파일을 수정해도 이미 만들어진 이미지나 실행 중인 컨테이너가 자동으로 바뀌지는 않습니다. 변경된 파일을 이미지에 반영하려면 이미지를 다시 빌드하고, 새 이미지로 컨테이너를 교체해야 합니다.이 방식은 애플리케이션과 기본 설정을 함께 버전 관리하기 쉽습니다...

호스트 디스크가 가득 찼다는 이유만으로 Docker 로그가 원인이라고 단정할 수는 없습니다. 이미지, 볼륨, 애플리케이션 파일도 공간을 사용합니다. 이 글은 Linux Docker Engine과 Compose V2에서 표준 출력·표준 오류로 내보낸 컨테이너 로그를 점검하는 상황을 다룹니다.현재 컨테이너의 로그 설정부터 확인합니다Docker는 이 출력을 로깅 드라이버로 처리합니다. 기본 json-file 드라이버는 별도 제한이 없으면 로그가 계속 커질 수 있습니다. 반면 애플리케이션이 /app/logs 같은 경로에 직접 쓰는 파일에는 이 설정이 적용되지 않으므로, 먼저 어떤 로그가 증가하는지 구분해야 합니다. [1]아래 명령에서 app은 실제 컨테이너 이름이나 ID로 바꿉니다. Docker 명령을 실행할 ..

게시판을 새 이미지로 배포한 뒤 글 목록은 남아 있는데 첨부파일만 열리지 않는 상황을 가정해 보겠습니다. 데이터베이스에는 파일 경로가 남았지만, 파일 자체는 교체한 컨테이너 안에만 있었을 수 있습니다. 다만 파일이 보이지 않는다는 사실만으로 삭제를 확정해서는 안 됩니다. 파일의 위치를 기존 컨테이너에 있는건 아닌지, 배포는 정상적으로 됐는지 확인해봐야 합니다. 이 글은 Linux 컨테이너와 Docker Engine을 기준으로 실제 업로드 경로와 저장소 연결을 대조하는 순서를 설명합니다.재시작과 재생성은 파일에 미치는 영향이 다릅니다이미지는 실행에 필요한 파일의 바탕이고, 실행 중 생성한 파일은 기본적으로 해당 컨테이너의 쓰기 가능 계층에 저장됩니다. 마운트하지 않은 경로에 업로드했다면 파일의 수명은 그..

서비스가 잠깐 실행됐다가 종료되고 다시 실행되는 상황에서는 재시작 횟수만 늘려도 같은 오류가 반복될 수 있습니다. 프로세스가 끝난 이유와 systemd가 다시 실행한 조건을 나누어 봐야 합니다. 이 글은 systemd를 사용하는 Linux의 시스템 서비스에서 종료 기록, 재시작 간격, 의존 서비스의 상태를 확인하는 순서를 설명합니다. 예시의 app.service는 실제 점검할 서비스 이름으로 바꿉니다.마지막 실패 표시보다 먼저 발생한 종료 기록 확인우선 현재 상태와 이번 부팅의 서비스 로그를 함께 확인합니다. systemctl status는 최근 메시지 일부만 보여 주므로, 반복이 시작된 시점의 기록은 journalctl로 더 넓게 읽습니다. 옵션 중 -b는 이번 부팅으로 범위를 좁히며, 로그 접근 권한..

2026년 10월 30일 인천공항에서 일부 항공사의 체크인과 탑승권 발급이 지연됐습니다. 이 사건을 ‘예약불가’라고만 부르면 신규 항공권 구매 문제와 공항 현장 수속 문제가 섞입니다.와... 이때 제가 만약 현장에 있었다면 여행자로써 많이 당황스러웠을 것 같네요.확인한 보도의 중심은 출국 당일 수속 장애이며, 이 글은 공개된 경과와 기업 IT 운영에 적용할 복구 확인 기준을 구분해 살펴봅니다.최초 통신 이상과 발급 중단은 시작 시점이 상이언론 10월 30일 보도에 따르면 오전 4시 30분부터 일부 항공사 발권 네트워크에서 문제가 발생했고, 두 터미널의 항공사 13곳에서 간헐적인 통신 끊김이 나타났습니다. 낮 12시부터는 외국 항공사 일부의 일반 탑승권 발급이 사실상 중단됐습니다.언론 후속 보도는 공사 설..

관리자 접속은 확인되는데 뒤따른 작업 기록이 비어 있다면, 조사자는 어디까지 판단할 수 있을까요. 최근 발표된 VMware ESX의 CVE-2026-41709는 관리자 권한으로 수행한 일부 작업이 기록되지 않을 수 있는 취약점입니다. 로그가 없다는 사실을 행위가 없었다는 증거로 삼기 어려운 이유입니다.2026년 10월 31일 기준으로 10월 24~31일의 공식 대응 동향을 살펴보고, 해당 호스트의 패치 판단과 감사 증거의 확인 범위를 정리합니다. 제품 공지의 ESX 표기와 호스트 수정 빌드의 ESXi 표기를 구분해 읽어야 합니다.이번 주의 변화는 최초 공개가 아닌 실제 악용 목록 등록입니다Broadcom 공지의 최초 공개일은 2026년 7월 29일입니다. 해당 CVE의 최대 CVSSv3 기본 점수는 2...