EC2 리눅스 OS 서버 데이터 저장 구조

EC2 리눅스 OS 마이그레이션 작업 진행 중 발생한 의문점 정리. "EBS 스냅샷 생성 후 EBS·ENI를 신규 OS의 EC2로 옮긴다"는 방식이 회의에서 언급되었으나, 정작 서버 내부에 쌓이는 로그·설정·데이터가 물리적으로 어디에 저장되고 있는지에 대한 개념 혼재 상태 발견. 

---

1. RAM vs EBS vs EFS — 역할 구분

가장 먼저 명확히 할 부분은 "로그나 설정이 RAM에 저장된다"는 흔한 오해. RAM은 프로세스 실행 중 사용하는 휘발성 작업 공간이며, 재부팅 시 전체 소멸 대상. 반면 재부팅 후에도 남아있어야 하는 모든 데이터는 디스크, 즉 EBS에 저장.

구분	저장 위치	휘발성	공유 가능 여부	대표 데이터
메모리	RAM	휘발성 (재부팅 시 소멸)	불가	실행 중 프로세스, 캐시
인스턴스 전용 디스크	EBS	영속 (단, 인스턴스 종료 정책에 종속)	원칙적으로 단일 인스턴스 전용	OS, 설정, crontab, 개별 서버 로그, /home
네트워크 공유 스토리지	EFS	영속 (인스턴스 생명주기와 무관)	다수 인스턴스 동시 마운트 가능	여러 서버가 공유하는 데이터 (예: wlog)

EBS가 "인스턴스 하나에만 붙는 디스크"라는 성격을 갖는 반면, EFS는 NFS 기반이라 애초에 "공유"를 전제로 설계된 서비스라는 점이 핵심 차이.

---

2. 리눅스 디렉토리별 저장 데이터

리눅스 표준(FHS, Filesystem Hierarchy Standard)에 따른 디렉토리별 용도는 아래와 같음.

디렉토리	표준 용도
/root	root 계정 전용 홈. 개인 설정·작업 파일
/home/{user}	일반 유저 홈. dotfile, SSH key, 개인 작업 공간
/etc	시스템 및 애플리케이션 설정 파일
/var	계속 변화하는 데이터 — /var/log(로그), /var/spool(큐/스풀), /var/run 등
/opt	서드파티/자체 패키징 애플리케이션 설치 위치 (원칙상 Spring Boot 배포 경로에 해당)
/usr	배포판이 관리하는 시스템 전역 프로그램·라이브러리
/tmp	임시 파일. 재부팅 시 소멸 가능

 

참고로 crontab은 실제로는 /var/spool/cron/crontabs/{user} (Debian 계열) 혹은 /var/spool/cron/{user} (RHEL 계열)에 저장. crontab -e로 편집하는 구조이며, 홈 디렉토리에 crontab 관련 파일이 존재한다면 crontab -l > backup.txt 형태의 수동 백업 사본일 가능성 높음.

회사 자체 컨벤션 디렉토리

/cont 같은 디렉토리는 FHS 표준이 아닌 조직 자체 관례. 한국 엔터프라이즈 환경, 특히 WAS 기반 레거시 시스템에서는 /app, /was, /data1, /cont 처럼 자체 네이밍으로 배포 경로를 구성하는 경우 다수. 표준은 아니지만 조직의 오래된 관례이며, Jenkins 파이프라인·배포 스크립트가 이미 해당 경로를 기준으로 구성되어 유지되는 구조.

---

3. 데이터 3분류 — 설정 / 순수 데이터 / CI 산출물

서버에 존재하는 모든 파일이 같은 성격을 갖는 것은 아님. 마이그레이션 관점에서는 아래 3가지로 구분 필요.

분류	판단 기준	예시	마이그레이션 시 처리
설정 (Config)	언제든 플레이북 재실행으로 동일하게 재생성 가능 (idempotent)	패키지 설치, 유저/그룹, cron 엔트리, 설정파일 템플릿, fstab 엔트리, 디렉토리 권한	Ansible이 새 인스턴스에 선언·적용
CI 산출물 (Artifact)	빌드 파이프라인이 매번 새로 생성	Spring Boot 배포 zip/jar, war	별도 이전 불필요 — Jenkins 재배포로 해결. 단 롤백용 과거 버전 이력은 순수 데이터로 취급
순수 데이터 (Data)	서버가 살아온 이력이 있어야만 존재. 재생성 불가능	실제 로그 파일 내용, DB 데이터, 업로드된 문서/이미지, 축적된 캐시	EBS 볼륨 detach/attach로 물리 이전

crontab이 Ansible에 아직 관리되지 않는 상태라면, 이는 "관례상 제외"가 아니라 수동으로 추가된 뒤 IaC에 반영되지 못한 기술 부채일 가능성 높음. 마이그레이션은 이런 누락분을 코드화할 좋은 계기.

---

4. OS 마이그레이션 워크플로우

EBS·ENI를 detach 후 새 OS의 EC2에 재연결하는 방식의 실제 순서는 아래와 같음. 핵심은 Ansible이 먼저 "빈 그릇"(마운트 포인트, fstab, 설정)을 준비한 뒤, EBS가 그 그릇에 "내용물"을 채우는 구조라는 점.

• 주황색 단계: AWS 인프라 레이어 작업 (콘솔·CLI·Terraform)
• 파란색 단계: Ansible 레이어 작업
• 회색 단계: 검증 단계

EBS·ENI attach/detach는 AWS API 레벨 작업으로, Ansible이 다루는 "OS 내부 설정"과는 레이어가 다름. amazon.aws.ec2_vol 모듈로 Ansible이 직접 처리하는 것도 가능하나, 컷오버 시점의 민감한 작업이라 별도 스텝(수동 또는 Terraform/CLI)으로 분리하는 경우 다수.

ENI 이전 시점은 EBS와 반드시 같을 필요 없음. Ansible이 SSH로 프로비저닝하는 동안은 임시 IP·보안그룹 사용, 최종 컷오버 직전 ENI를 옮겨 기존 프라이빗 IP·보안그룹 그대로 유지하는 방식 일반적. EFS는 네트워크 마운트 방식이라 인스턴스에 종속되지 않으므로, 신규 인스턴스에서 마운트 설정만 다시 하면 기존 공유 데이터 그대로 접근 가능.

---

5. Auto Scaling 환경에서의 EBS·EFS

단일 서버(pet) 마이그레이션과 달리, Auto Scaling Group(ASG) 환경은 인스턴스를 "언제든 대체 가능한 자원(cattle)"으로 취급. 이 전제에서 EBS의 동작 방식이 완전히 달라짐.

• 스케일아웃: Launch Template의 AMI 기준으로 신규 EBS 매번 새로 생성. 기존 볼륨 재사용 없음. Ansible(또는 user-data/cloud-init)이 부팅 시점에 재프로비저닝.
• 스케일인: 인스턴스 종료 시 DeleteOnTermination 옵션에 따라 EBS도 함께 삭제 (root 볼륨은 기본값 true인 경우 다수). 로컬에만 있던 로그·캐시는 이 시점에 유실.

항목	ASG 환경	단일 서버(pet) 환경
EBS 취급	휘발성 스크래치 공간으로 간주	보존 대상 (detach/attach로 이전)
영속 데이터 위치	EFS, S3, 관리형 DB	EBS 자체
로그 처리	실시간으로 중앙 저장소(ELK, CloudWatch Logs 등)로 전송	로컬 보존 후 필요 시 이전
인스턴스 정체성	대체 가능 (cattle)	고유 정체성 유지 (pet)

결론적으로 여러 서버가 공유해야 하거나 인스턴스 생명주기와 무관하게 남아야 하는 데이터는 EFS·S3·DB 같은 외부 스토리지 사용 원칙. EBS는 인스턴스의 "몸", EFS는 인스턴스가 죽어도 남는 "기억"에 해당.

---

6. 전체 정리표

디렉토리/데이터	성격	저장 위치	관리 주체	마이그레이션 시
OS, 패키지, /etc 설정	설정	EBS (root)	Ansible (선언)	새 인스턴스에서 재생성
crontab	설정 (단, 미관리 시 기술 부채)	EBS (root, /var/spool/cron)	Ansible (권장)	Ansible로 흡수 또는 수동 확인
/home 내 dotfile, SSH key	설정	EBS (root)	Ansible	새 인스턴스에서 재생성
/home 내 개인 작업 스크립트·캐시	순수 데이터	EBS (root 또는 데이터 볼륨)	없음 (비관리 영역)	필요 시에만 수동 이전
/var/log, 애플리케이션 로그	순수 데이터	EBS (데이터 볼륨)	없음	EBS 물리 이전 대상
/cont 내 최신 배포 zip/jar	CI 산출물	EBS (데이터 볼륨)	Jenkins	이전 불필요, 재배포로 해결
/cont 내 과거 릴리즈 이력	순수 데이터	EBS (데이터 볼륨)	없음	롤백 필요 시 EBS 물리 이전
wlog 등 서버 간 공유 데이터	순수 데이터 (공유형)	EFS	없음	재마운트만 하면 접근 가능
실행 중 프로세스, 캐시	휘발성	RAM	없음	이전 대상 아님