지난 5편에서 Rocky Linux를 깔끔하게 설치해 봤으니, 이제 실제로 하드디스크를 하나 더 꽂아서 용량을 늘리는 작업을 해보겠습니다. 보통 “그냥 파티션 나눠서 쓰면 안 되나?”라고 생각하실 수도 있지만, 실무에서는 99% **LVM(Logical Volume Manager)**을 씁니다. 운영 중에 갑자기 “용량 모자라요!”라는 요청이 들어왔을 때, 서비스 중단 없이 디스크를 슥 늘릴 수 있는 유연함 때문이죠. 오늘 작업은 root 권한으로 … 더 읽기
요즘은 AWS나 GCP 같은 클라우드 환경에서 클릭 몇 번, 이른바 ‘딸깍’ 한 번이면 OS 설치가 완료되는 시대입니다. 참 편리하고 빠른 세상이죠. 그런데 여기서 이런 의문이 들 수 있습니다. “과연 엔지니어가 이 수동 설치 과정을 굳이 해볼 필요가 있을까?” 제 생각은 이렇습니다. 클라우드가 제공하는 이미지만 가져다 쓰면, OS는 우리에게 그저 내부를 알 수 없는 **’블랙박스’**일 뿐입니다. … 더 읽기
서론: 서비스가 예고 없이 멈추는 이유 AWS Lightsail이나 소형 클라우드 인스턴스(RAM 1GB~2GB)를 운영하다 보면 가장 자주 마주치는 문제가 바로 ‘메모리 부족으로 인한 DB 다운’ 현상입니다.(AWS Lightsail에서는 아직 이 현상을 확인하지는 않았어요) 리눅스 커널은 가용 메모리가 고갈되면 시스템 보호를 위해 특정 프로세스를 강제로 종료하는 OOM(Out of Memory) Killer를 작동시키는데, 대개 그 타겟은 메모리 점유율이 높은 MySQL이나 … 더 읽기
서론: 왜 기본 계정 대신 ‘나만의 계정’을 써야 할까요? AWS Lightsail이나 EC2를 생성하면 보통 bitnami나 ubuntu 같은 기본 계정이 주어집니다. 하지만 여러 엔지니어가 서버를 관리하거나, 본인만의 명확한 작업 흔적을 남기기 위해서는 개인 관리자 계정을 별도로 운영하는 것이 좋습니다. 특히 매번 sudo를 입력할 때마다 비밀번호를 치는 번거로움을 줄이면서도, sudo -i 한 줄로 즉시 root 권한을 얻는 … 더 읽기
서론: 이름이 없는 서버는 장애의 씨앗이 됩니다 클라우드 인스턴스를 처음 생성하면 보통 ip-172-26-xx-xx 같은 임의의 내부 IP가 호스트네임으로 지정됩니다. 소수의 서버를 운영할 때는 문제가 없지만, 관리하는 서버가 늘어날수록 터미널 프롬프트만 보고는 이 서버가 운영(Production) 서버인지 테스트(Test) 서버인지 즉각적으로 파악하기 어렵습니다. 호스트네임을 명확히 설정하는 것은 단순히 보기 좋게 만드는 작업이 아닙니다. 운영 환경 오인으로 인한 커맨드 … 더 읽기
서론: “자, 이제 뭘 해야 하지?” 환경 파악이 우선입니다. AWS Lightsail이나 클라우드 인스턴스를 막 생성하고 터미널(SSH)에 처음 접속했을 때, 엔지니어가 가장 먼저 수행해야 할 작업은 무엇일까요? 바로 내가 발을 딛고 있는 **’시스템 환경’**을 정확히 파악하는 것입니다. 리눅스는 우분투(Ubuntu), 센트오에스(CentOS), 데비안(Debian) 등 다양한 배포판이 존재하며, 같은 OS라도 버전에 따라 사용하는 패키지 매니저나 명령어 옵션이 달라집니다. 오늘은 … 더 읽기