Session 20 — 실습 모음
Hands-on Labs · 20 시나리오

VirtualBox / VMware + Linux + 모니터링 · 네트워크 · 스토리지 · 보안 · HA

난이도 ⭐ 쉬움 (8) · ⭐⭐ 중간 (8) · ⭐⭐⭐ 어려움 (4) — 강사가 수강생 난이도에 맞춰 선택

강사 박수현 · 🚀 젠아이랩스(GenAI Labs)

🎨 이미지 프롬프트: "Editorial wide cover illustration on dark navy background — TOP MAIN TITLE in English ONLY: 'Hands-on Labs · 20 Scenarios for TA Infrastructure'; a Korean Technical Architect (around 35, busines6-casual, with USB drive lanyard) standing in front of a giant glowing whiteboard wall divided into 3 horizontal sections labeled 'Easy ⭐ (8 labs)', 'Medium ⭐⭐ (8 labs)', 'Hard ⭐⭐⭐ (4 labs)' — each section showing 4~8 lab tiles with tool icons: Easy section has Nginx + Docker + SSH + curl + htop + tar + dig + mtr icons; Medium section has Wireshark + iperf3 + HAProxy + Keepalived + PostgreSQL + Docker+cAdvisor + nftables + WireGuard icons; Hard section has mdadm RAID + Pacemaker + Prometheus + Grafana + Wazuh + GNS3/FRRouting icons. In front of the whiteboard a laptop on desk showing VirtualBox 7.0 main window with 4 VMs running (lab-vm-01 through lab-vm-04). Cinematic editorial illustration, teal #00b894 and purple #6c5ce7 accents, 16:9 — CRITICAL: All visible text MUST be in English only."

VirtualBox / VMware + Linux + 모니터링 · 네트워크 · 스토리지 · 보안 · HA

실습 19개 — 큐레이션 가이드 (20개 → 19개, 자원 모니터링 통합)

실습 #2 — Nginx Reverse Proxy — 환경·시나리오 ⭐

🎨 이미지 프롬프트: "Editorial network architecture diagram on dark navy background — title 'Nginx Reverse Proxy — Lab Topology' in white English at top, three boxes connected left to right: (1) LEFT 'Client (Web Browser / curl)' showing a laptop icon with curl command bubble 'curl -v http://192.168.56.10/', (2) CENTER 'Nginx Reverse Proxy (Ubuntu 22.04 VM · 192.168.56.10:80)' shown as a large rounded box with nginx logo + config snippet 'location / { proxy_pass http://127.0.0.1:3000; proxy_set_header Host \$host; }', (3) RIGHT 'Backend (Python http.server 127.0.0.1:3000)' showing a small Python snake icon with terminal 'python3 -m http.server 3000 --bind 127.0.0.1'; thick teal arrows show request/response flow with labels 'HTTP Request → :80', 'proxy_pass → :3000', 'HTTP Response ← Backend'; bottom strip showing terminal output of Nginx access log '192.168.56.1 - - [31/May/2026:14:22:08 +0900] \"GET / HTTP/1.1\" 200 1024 \"-\" \"curl/7.81.0\"' and curl response 'HTTP/1.1 200 OK · Server: nginx/1.24.0 · X-Backend: python-http-server'; teal #00b894 and purple #6c5ce7 accents, technical lab diagram, 16:9 — CRITICAL: All visible text MUST be in English only."

🎯 목적

• Reverse Proxy 동작 원리 이해
• Nginx 설정 파일 (proxy_pass·헤더 전달) 작성
• 백엔드 1대 + Nginx 1대 최소 구성으로 L7 프록시 이해

🛠️ 도구

• VirtualBox + Ubuntu Server 24.04 (실습 #1에서 만든 VM)
• Nginx (apt install nginx)
• Python http.server (백엔드 mock, 기본 내장)
• curl (검증)

💻 시나리오 (약 15분)

# 1) Nginx 설치 + 시작
sudo apt update && sudo apt install -y nginx
sudo systemctl status nginx     # active (running) 확인

# 2) 백엔드 띄우기 (다른 터미널)
mkdir -p /tmp/site && cd /tmp/site
echo '<h1>Backend OK</h1>' > index.html
python3 -m http.server 3000 --bind 127.0.0.1

# 3) Reverse Proxy 설정 작성
sudo tee /etc/nginx/sites-available/lab-proxy <<'EOF'
server {
    listen 80;
    server_name _;
    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
    access_log /var/log/nginx/lab-proxy.access.log;
}
EOF

# 4) 활성화 + 테스트
sudo ln -s /etc/nginx/sites-available/lab-proxy \
           /etc/nginx/sites-enabled/lab-proxy
sudo rm /etc/nginx/sites-enabled/default
sudo nginx -t                    # syntax OK
sudo systemctl reload nginx

# 5) 검증
curl -v http://localhost/         # 200 OK + Backend OK
curl -I http://localhost/         # Server: nginx/1.24.0

# 6) 로그 확인
sudo tail -f /var/log/nginx/lab-proxy.access.log

실습 #2 — Nginx Reverse Proxy — 분석·해설 ⭐

🎨 이미지 프롬프트: "Editorial split-pane terminal mockup on dark navy background — TOP MAIN TITLE in English ONLY: 'Nginx Reverse Proxy — Expected Output'; left half: dark terminal window titled '$ sudo cat /etc/nginx/sites-available/lab-proxy' showing the full nginx config 'server { listen 80; server_name _; location / { proxy_pass http://127.0.0.1:3000; proxy_set_header Host \$host; proxy_set_header X-Real-IP \$remote_addr; proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto \$scheme; } access_log /var/log/nginx/lab-proxy.access.log; error_log /var/log/nginx/lab-proxy.error.log; }' with syntax-highlighted keywords; right half: dark terminal showing '$ curl -v http://192.168.56.10/ 2>&1 | head -20' output '* Trying 192.168.56.10:80... · * Connected to 192.168.56.10 (192.168.56.10) port 80 · > GET / HTTP/1.1 · > Host: 192.168.56.10 · > User-Agent: curl/7.81.0 · * Mark bundle as not supporting multiuse · < HTTP/1.1 200 OK · < Server: nginx/1.24.0 (Ubuntu) · < Date: Sat, 31 May 2026 14:22:08 GMT · < Content-Type: text/html · < Connection: keep-alive · <!DOCTYPE html>

Backend OK

' with green status code; bottom: small Nginx access log line '$ sudo tail -1 /var/log/nginx/lab-proxy.access.log · 192.168.56.1 - - [31/May/2026:14:22:08 +0900] \"GET / HTTP/1.1\" 200 1024 \"-\" \"curl/7.81.0\"' with teal highlight; monospace font, teal #00b894 prompts, 16:9 — CRITICAL: All visible text MUST be in English only."

🔍 관전 포인트 (5종)

1. proxy_pass http://127.0.0.1:3000 — Nginx가 80 → 백엔드 3000으로 재전송
2. Host 헤더 — Nginx가 받은 Host를 백엔드에 전달 (다중 도메인 시 핵심)
3. X-Real-IP / X-Forwarded-For — 백엔드가 실제 클라이언트 IP 알 수 있게
4. nginx -t — reload 전 syntax 검증 (운영 필수 습관)
5. access.log — 80번에 들어온 모든 요청 기록 (분석·디버깅)

✅ 결론 (수강생이 학습할 것)

• L7 프록시 = HTTP 헤더를 보고 라우팅하는 장치 (vs L4는 IP·포트)
• 백엔드 1대 → 여러 대로 늘릴 때 (upstream 블록) 자연스럽게 로드밸런서가 됨 (실습 #12 HAProxy로 확장)
• 운영 Nginx 설정의 기본 패턴 4종 (proxy_pass·헤더 3종·access_log) 정착

🎙️ 강사 해설 (약 5분)

• 왜 백엔드를 127.0.0.1에만 바인딩? → 외부 직접 접근 차단, Nginx만 통하게 (보안 + 통합 로깅)
• proxy_pass의 슬래시 유무가 URI rewrite에 영향 (예: proxy_pass http://backend/ vs proxy_pass http://backend)
• 운영에서 자주 만나는 502 Bad Gateway = 백엔드 다운/타임아웃 → access.log + error.log 같이 봐야
• 다음 실습 #12 HAProxy로 확장 시: upstream backend { server 127.0.0.1:3000; server 127.0.0.1:3001; } 한 줄로 LB

🐞 자주 만나는 오류

• nginx: [emerg] → nginx -t로 syntax 확인
• 502 → 백엔드 살아있나 (curl http://127.0.0.1:3000)
• 403 → SELinux 또는 디렉토리 권한
• ports.conf 충돌 → sudo ss -tlnp | grep :80

실습 #2 — Nginx Reverse Proxy ⭐

실습 #1 — VirtualBox VM 만들고 SSH 접속 — 환경·시나리오 ⭐

🎨 이미지 프롬프트: "Editorial diagram on dark navy background — title 'VirtualBox VM + SSH — Lab Topology' in white English at top, two boxes connected: LEFT 'Host (Your Laptop)' showing a MacBook icon with terminal command 'ssh lab@192.168.56.10', RIGHT 'VirtualBox VM (Ubuntu 22.04 Server)' shown as a rounded box labeled 'lab-vm-01 · 2 vCPU · 4GB RAM · 40GB · NAT + Host-Only 192.168.56.10' with Ubuntu logo and sshd running indicator; thick teal arrow between them labeled 'TCP 22 (Host-Only Adapter)'; bottom strip showing VirtualBox 7.0 main window mockup with 'lab-vm-01 (Running)' VM entry highlighted; teal #00b894 and purple #6c5ce7 accents, technical lab diagram, 16:9 — CRITICAL: All visible text MUST be in English only."

🎯 목적

• VirtualBox로 격리된 Linux 환경 만들기
• 가장 기초인 SSH 원격 접속 익히기
• NAT vs Bridge vs Host-Only 어댑터 이해

🛠️ 도구

• VirtualBox 7.x (virtualbox.org/wiki/Downloads)
• Ubuntu Server 24.04 LTS ISO (releases.ubuntu.com)
• OpenSSH (Ubuntu 기본 포함)

💻 시나리오 (약 15분)

# 1) VirtualBox UI에서 VM 생성
#    Name: lab-vm-01 / Type: Linux / Ubuntu 64-bit
#    Memory: 4096 MB / CPU: 2 / Disk: 40 GB VDI

# 2) Settings → Network
#    Adapter 1: NAT       (외부 인터넷)
#    Adapter 2: Host-Only (vboxnet0, 192.168.56.0/24)

# 3) Ubuntu 22.04 ISO 마운트 + 설치
#    User: lab / Hostname: lab-vm-01
#    "Install OpenSSH server" 체크

# 4) VM 안에서 (콘솔 접속)
sudo systemctl enable --now ssh
sudo ufw allow 22
ip addr show enp0s8     # 192.168.56.10 확인

# 5) 호스트에서 SSH 접속
ssh lab@192.168.56.10
uname -a
sudo systemctl status ssh

실습 #1 — VirtualBox VM 만들고 SSH 접속 — 분석·해설 ⭐

🎨 이미지 프롬프트: "Editorial split-pane terminal mockup on dark navy background — TOP MAIN TITLE in English ONLY: 'VirtualBox VM + SSH — Expected Output'; left pane: dark terminal showing 'host$ ssh lab@192.168.56.10 · The authenticity of host 192.168.56.10 (192.168.56.10) cant be established. · ED25519 key fingerprint is SHA256:a1b2c3... · Are you sure you want to continue connecting (yes/no)? yes · Warning: Permanently added 192.168.56.10 (ED25519) to the list of known hosts. · lab@192.168.56.10s password: ····· · Welcome to Ubuntu 22.04.5 LTS (GNU/Linux 5.15.0-101-generic x86_64) · Last login: Sat May 31 14:22:08 2026 · lab@lab-vm-01:~$ uname -a · Linux lab-vm-01 5.15.0-101-generic #111-Ubuntu SMP x86_64 GNU/Linux'; right pane: 'lab@lab-vm-01:~$ sudo systemctl status ssh · ● ssh.service - OpenBSD Secure Shell server · Active: active (running) · Main PID: 842 (sshd) · Tasks: 1 (limit: 4554) · Memory: 5.1M · CPU: 12ms' and below 'lab@lab-vm-01:~$ ip addr show enp0s8 · 3: enp0s8: mtu 1500 · inet 192.168.56.10/24 brd 192.168.56.255 scope global'; monospace font, teal #00b894 prompts, 16:9 — CRITICAL: All visible text MUST be in English only."

🔍 관전 포인트

1. NAT vs Host-Only — NAT는 외부 인터넷, Host-Only는 호스트↔VM 사설망
2. Adapter 2 (192.168.56.10) — 고정 사설 IP라 SSH 안정
3. sshd 상태 — systemctl status ssh 가 active (running)
4. 첫 접속 시 fingerprint — ~/.ssh/known_hosts에 추가됨
5. VBoxManage list vms — CLI로도 VM 관리 가능

✅ 결론

• VM = 호스트 위에서 돌아가는 격리된 컴퓨터 — 망쳐도 호스트 멀쩡
• SSH = 원격 운영의 기본 — 모든 후속 실습의 진입점
• Host-Only 어댑터 = 실습 표준 — IP 고정 + 외부 차단

🎙️ 강사 해설 (약 5분)

• 네트워크 어댑터 4종: NAT / NAT Network / Bridged / Host-Only / Internal — 실습엔 NAT + Host-Only 조합 표준
• ~/.ssh/known_hosts 변경 시 → ssh-keygen -R 192.168.56.10
• 다음 실습 #5 ssh-keygen으로 비밀번호 X 접속 확장
• VBoxManage = GUI 없이 CI/CD에서 VM 자동화 가능

🐞 자주 만나는 오류

• Connection refused → sshd 미실행 or 포트 차단 (sudo ufw status)
• Host key verification failed → ssh-keygen -R <ip>
• 192.168.56.10 도달 X → Host-Only 어댑터 미추가
• 마우스가 VM에 갇힘 → Right-Ctrl 키로 해제

실습 #1 — VirtualBox VM 만들고 SSH 접속 ⭐

실습 #3 — Docker 한 줄로 웹 서버 띄우기 — 환경·시나리오 ⭐

🎨 이미지 프롬프트: "Editorial diagram on dark navy background — title 'Docker run nginx — Lab Flow' in white English at top, three stages left to right: (1) 'Host: docker installed' showing a terminal with command 'docker run -d --name web -p 80:80 nginx', (2) 'Docker pulls nginx:latest from Docker Hub' shown as a cloud icon labeled 'hub.docker.com/_/nginx' with download arrow to a container box, (3) 'Container running on port 80' showing a running nginx container box with the iconic green Nginx N logo + port mapping ':80 → :80' and a browser icon below showing 'http://localhost ⇒ Welcome to nginx!'; teal flow arrows between stages; bottom strip showing 'docker ps · CONTAINER ID 5f3a · IMAGE nginx · STATUS Up 2 minutes · PORTS 0.0.0.0:80->80/tcp · NAMES web'; teal #00b894 and purple #6c5ce7 accents, technical lab diagram, 16:9 — CRITICAL: All visible text MUST be in English only."

🎯 목적

• Docker 한 줄로 웹 서버 띄우기 (모든 설치 0초)
• 컨테이너 = 격리된 프로세스 개념 이해
• 포트 매핑 (-p 80:80), 백그라운드 (-d), 이름 (--name)

🛠️ 도구

• Docker Engine (get.docker.com 스크립트)
• 이미지: nginx (Docker Hub)
• curl (검증)

💻 시나리오 (약 10분)

# 1) Docker 설치 (한 줄)
curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker $USER
newgrp docker     # 또는 재로그인

# 2) nginx 컨테이너 한 줄로 띄우기
docker run -d --name web -p 80:80 nginx

# 3) 검증
docker ps                            # web Up X seconds
curl -I http://localhost             # 200 OK · Server: nginx/1.27
curl http://localhost | head -5      # Welcome to nginx! 페이지

# 4) 컨테이너 안 들어가 보기
docker exec -it web bash
# (안에서) ls /usr/share/nginx/html/
# echo "<h1>Hello Lab</h1>" > /usr/share/nginx/html/index.html
# exit

# 5) 로그·메트릭
docker logs --tail 20 web
docker stats web                     # CPU · Mem 실시간

# 6) 정리
docker stop web && docker rm web

실습 #3 — Docker 한 줄로 웹 서버 띄우기 — 분석·해설 ⭐

🎨 이미지 프롬프트: "Editorial split-pane mockup on dark navy background — TOP MAIN TITLE in English ONLY: 'Docker run nginx — Expected Output'; left pane: dark terminal showing '$ docker run -d --name web -p 80:80 nginx · Unable to find image nginx:latest locally · latest: Pulling from library/nginx · 5af00eab9784: Pull complete · 5af00eab9784: Pull complete · Digest: sha256:bc5eac5eafc581aeda3008b4b1f07ebba230de2f27d47767129a6a905c84f470 · Status: Downloaded newer image for nginx:latest · 5f3a8b1c4d2e7e9f0a... · $ docker ps · CONTAINER ID IMAGE STATUS PORTS NAMES · 5f3a8b1c4d2e nginx Up 12s 0.0.0.0:80->80/tcp web · $ curl -I http://localhost · HTTP/1.1 200 OK · Server: nginx/1.27.4 · Content-Type: text/html'; right pane: Chrome browser screenshot showing 'http://localhost' rendering the classic 'Welcome to nginx!' page with its default content 'If you see this page, the nginx web server is successfully installed and working.'; monospace font in terminal, teal #00b894 accents, 16:9 — CRITICAL: All visible text MUST be in English only."

🔍 관전 포인트

1. -d — detach (백그라운드) / 없으면 포그라운드
2. -p 80:80 — 호스트 포트 : 컨테이너 포트
3. --name web — 이후 명령에서 ID 대신 이름 사용
4. 이미지 자동 pull — 처음엔 Docker Hub에서 다운
5. docker exec -it — 살아있는 컨테이너 안으로 SSH-like 진입

✅ 결론

• 컨테이너 = 1줄로 띄우는 격리 프로세스
• 이미지 = "스냅샷", 컨테이너 = "그 스냅샷의 실행 인스턴스"
• 운영 OSS의 90%는 Docker 한 줄로 시연 가능 — 학습 가속

🎙️ 강사 해설 (약 5분)

• VM과 차이: VM = 별도 커널 (수 GB) · 컨테이너 = 호스트 커널 공유 (수 MB)
• 컨테이너 격리 = Linux namespace (PID·NET·MNT 등) + cgroup (CPU·Mem 제한)
• Docker Hub vs Private Registry (자체 이미지 보관)
• 다음 실습 #15에서 cgroup 한도 + cAdvisor로 격리 검증

🐞 자주 만나는 오류

• permission denied → docker 그룹 추가 + newgrp docker
• port is already allocated → sudo ss -tlnp | grep :80 → 기존 nginx 중지
• Cannot connect to the Docker daemon → sudo systemctl start docker
• docker: command not found → 설치 스크립트 다시

실습 #3 — Docker 한 줄로 웹 서버 띄우기 ⭐

type: content slide: 7 title: 실습 #5 — ssh-keygen 공개키 인증 ⭐ [필수] · 환경·시나리오 key: s20-016-lab-ssh-keygen-setup

실습 #5 — ssh-keygen + ssh-copy-id 비밀번호 없는 SSH — 환경·시나리오 ⭐

🎨 이미지 프롬프트: "Editorial diagram on dark navy background — title 'SSH Public Key Authentication — Lab Flow' in white English at top, two computers (Client laptop + Server) with three steps shown as numbered teal arrows: (1) 'Generate key pair on client: ssh-keygen -t ed25519' producing two file icons '~/.ssh/id_ed25519 (PRIVATE — never share)' in red lock and '~/.ssh/id_ed25519.pub (PUBLIC — copy to server)' in green, (2) 'Copy public key to server: ssh-copy-id lab@server' shown as arrow carrying the green pub key file to the server which appends it to '~/.ssh/authorized_keys', (3) 'Subsequent SSH: ssh lab@server (no password)' shown as a direct arrow with checkmark; bottom strip 'Why? Asymmetric crypto — server holds public key, client proves possession of private key via challenge-response'; teal #00b894 and purple #6c5ce7 accents, technical security diagram, 16:9 — CRITICAL: All visible text MUST be in English only."

🎯 목적

• 비밀번호 없이 SSH — 보안 + 편의 동시 확보
• 공개키 vs 개인키 비대칭 암호화 이해
• ~/.ssh/config 별칭으로 운영 효율

🛠️ 도구

• ssh-keygen, ssh-copy-id, ssh (openssh-client 기본)
• 실습 #1의 VM lab@192.168.56.10 활용

💻 시나리오 (약 10분)

# 1) 키 쌍 생성 (ED25519 — 작고 빠르고 안전)
ssh-keygen -t ed25519 -C "lab@$(hostname)"
# 기본 경로 ~/.ssh/id_ed25519 / 패스프레이즈는 선택

# 2) 공개키를 서버로 복사
ssh-copy-id -i ~/.ssh/id_ed25519.pub lab@192.168.56.10
# (서버의 ~/.ssh/authorized_keys 에 append)

# 3) 검증 — 비밀번호 없이 접속
ssh lab@192.168.56.10
exit

# 4) 별칭 설정 (~/.ssh/config)
cat >> ~/.ssh/config <<'EOF'
Host lab
    HostName 192.168.56.10
    User lab
    IdentityFile ~/.ssh/id_ed25519
EOF
ssh lab    # 짧게 접속

# 5) (서버측) 비밀번호 로그인 금지
sudo sed -i 's/^#*PasswordAuthentication.*/PasswordAuthentication no/' \
  /etc/ssh/sshd_config
sudo systemctl reload ssh

# 6) ssh-agent로 패스프레이즈 캐시
eval $(ssh-agent)
ssh-add ~/.ssh/id_ed25519

실습 #5 — ssh-keygen + ssh-copy-id 비밀번호 없는 SSH — 분석·해설 ⭐

🎨 이미지 프롬프트: "Editorial split-pane terminal mockup on dark navy background — TOP MAIN TITLE in English ONLY: 'SSH Key Auth — Expected Output'; left pane: dark terminal '$ ssh-keygen -t ed25519 -C lab@host -f ~/.ssh/id_ed25519 -N \"\" · Generating public/private ed25519 key pair. · Your identification has been saved in /home/lab/.ssh/id_ed25519 · Your public key has been saved in /home/lab/.ssh/id_ed25519.pub · The key fingerprint is: SHA256:a1b2c3d4e5... lab@host · The keys randomart image is: · +--[ED25519 256]--+ · | . o+oo.E. | · | . + .o o..o| · | o . o .. | · +----[SHA256]-----+ · $ ssh-copy-id -i ~/.ssh/id_ed25519.pub lab@192.168.56.10 · Number of key(s) added: 1 · Now try logging into the machine with: \"ssh lab@192.168.56.10\"'; right pane: '$ ssh lab@192.168.56.10 · Welcome to Ubuntu 22.04.5 LTS · lab@lab-vm-01:~$ cat ~/.ssh/authorized_keys · ssh-ed25519 AAAAC3Nz... lab@host · lab@lab-vm-01:~$ ls -la ~/.ssh · -rw------- 1 lab lab 411 authorized_keys (600 perms)'; teal #00b894 accents, monospace font, 16:9 — CRITICAL: All visible text MUST be in English only."

🔍 관전 포인트

1. ED25519 vs RSA — ED25519 추천 (작고 빠르고 강함)
2. -N "" — 패스프레이즈 없음 (실습용 / 운영은 패스프레이즈 권장)
3. authorized_keys 권한 = 600 (그 외엔 sshd 거부)
4. fingerprint — 첫 접속 시 known_hosts 등록
5. ~/.ssh/config — 운영 SSH 별칭의 핵심

✅ 결론

• PasswordAuthentication no = 운영 SSH의 표준
• 공개키 = "서버에 두고 누구나 볼 수 있는 자물쇠"
• 개인키 = "절대 나가지 않는 열쇠" — 분실 시 전부 재발급

🎙️ 강사 해설 (약 5분)

• ssh-copy-id 내부: scp + cat >> authorized_keys
• 개인키 유출 시: ssh-keygen -y -f 로 공개키 재추출 후 authorized_keys 교체
• 다중 키 관리: ~/.ssh/config 의 Host별 IdentityFile
• 2FA 강화: sshd PAM + Google Authenticator

🐞 자주 만나는 오류

• Permission denied (publickey) → authorized_keys 권한·소유자
• Bad permissions → chmod 700 ~/.ssh && chmod 600 ~/.ssh/*
• Agent admitted failure to sign → ssh-add ~/.ssh/id_ed25519
• known_hosts 충돌 → ssh-keygen -R <ip>

실습 #5 — ssh-keygen + ssh-copy-id 비밀번호 없는 SSH ⭐

실습 #6 — curl + dig — HTTP·DNS 1차 디버깅 — 환경·시나리오 ⭐

🎨 이미지 프롬프트: "Editorial flow diagram on dark navy background — title 'HTTP / DNS Debug Lab' in white English at top, two horizontal lanes: TOP lane 'DNS Resolution' showing arrow chain 'Client → /etc/resolv.conf → DNS Resolver (8.8.8.8 or 1.1.1.1) → Authoritative NS → A record 93.184.216.34' with dig output 'dig example.com +short → 93.184.216.34'; BOTTOM lane 'HTTP Request' showing 'Client → TCP 443 → TLS Handshake → HTTP/1.1 GET / → Server → HTTP/1.1 200 OK' with curl output 'curl -I https://example.com → HTTP/2 200 · server: ECS · content-type: text/html'; right side panel listing 'Debug Toolkit: dig · nslookup · host · curl -v · curl -I · curl -L · openssl s_client'; teal #00b894 and purple #6c5ce7 accents, technical lab diagram, 16:9 — CRITICAL: All visible text MUST be in English only."

🎯 목적

• HTTP 상태코드·헤더 실측
• DNS 레코드 (A / AAAA / MX / NS / TXT / PTR) 조회
• 운영 장애 1차 디버깅 도구 익히기

🛠️ 도구

• curl (8.x)
• dig (apt install dnsutils)
• 보너스: nslookup, host, openssl s_client

💻 시나리오 (약 15분)

# === HTTP 디버깅 ===
# 1) 응답 헤더만
curl -I https://example.com
# HTTP/2 200 · content-type: text/html ...

# 2) 상세 (TLS · 인증서 · 리다이렉트)
curl -v https://example.com 2>&1 | head -30

# 3) 리다이렉트 따라가기
curl -IL http://github.com
# 301 → 302 → 200

# 4) POST + JSON
curl -X POST https://httpbin.org/post \
  -H "Content-Type: application/json" \
  -d '{"name":"lab"}'

# 5) 응답 시간 측정
curl -w "DNS=%{time_namelookup}s Connect=%{time_connect}s \
  TLS=%{time_appconnect}s TTFB=%{time_starttransfer}s \
  Total=%{time_total}s\n" -o /dev/null -s https://example.com

# === DNS 조회 ===
# 6) A 레코드 (기본)
dig example.com +short
# 93.184.216.34

# 7) MX (메일)
dig example.com MX +short

# 8) 특정 DNS 서버 지정
dig @8.8.8.8 example.com
dig @1.1.1.1 example.com

# 9) Reverse DNS (PTR)
dig -x 8.8.8.8 +short

# 10) 전체 trace (root → TLD → authoritative)
dig +trace example.com

실습 #6 — curl + dig — HTTP·DNS 1차 디버깅 — 분석·해설 ⭐

🎨 이미지 프롬프트: "Editorial split-pane terminal mockup on dark navy background — TOP MAIN TITLE in English ONLY: 'curl + dig — Expected Output'; left pane: '$ curl -I https://example.com · HTTP/2 200 · content-type: text/html; charset=UTF-8 · etag: \"3147526947+ident\" · last-modified: Thu, 17 Oct 2019 07:18:26 GMT · cache-control: max-age=3600 · server: ECS (sec/97A3) · $ curl -v https://example.com 2>&1 | head -20 · * Trying 93.184.216.34:443... · * Connected to example.com (93.184.216.34) port 443 · * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 · * Server certificate: · * subject: CN=*.example.com · * issuer: DigiCert TLS RSA SHA256 2020 CA1 · > GET / HTTP/1.1 · > Host: example.com · > User-Agent: curl/8.5.0 · < HTTP/2 200'; right pane: '$ dig example.com · ;; ANSWER SECTION: · example.com. 3600 IN A 93.184.216.34 · ;; Query time: 12 msec · ;; SERVER: 8.8.8.8#53(8.8.8.8) · $ dig +short example.com MX · 0 . · $ dig -x 93.184.216.34 +short · _ip4.example.net.'; teal #00b894 highlights for status codes / IPs, monospace font, 16:9 — CRITICAL: All visible text MUST be in English only."

🔍 관전 포인트

1. HTTP 상태코드 — 2xx OK / 3xx redirect / 4xx client / 5xx server
2. curl -v 의 * = 디버그 정보, > = 요청, < = 응답
3. dig ANSWER 섹션 — 실제 레코드 값
4. time_namelookup vs time_connect — DNS와 TCP 분리 측정
5. +trace — 전 세계 DNS 위계 추적

✅ 결론

• 장애 1차 진단 = curl -I + dig +short
• DNS는 운영 장애의 30% 원인 — TTL·캐시·전파 시간 이해 필수
• curl -w 로 응답 시간 단계별 측정 가능

🎙️ 강사 해설 (약 5분)

• HTTP/2 멀티플렉싱 (curl --http2)
• TLS 1.3 핸드셰이크 0-RTT
• DNS over HTTPS (DoH) — dig @1.1.1.1 +https
• 다음 실습 #10 Wireshark로 TCP·TLS 패킷 단위 분석

🐞 자주 만나는 오류

• dig: command not found → apt install dnsutils
• curl: (6) Could not resolve host → DNS 실패 (cat /etc/resolv.conf)
• curl: (35) SSL connect error → TLS 인증서 / 시간 동기화 (NTP)
• dig 응답 SERVFAIL → DNSSEC 검증 실패

실습 #6 — curl + dig — HTTP·DNS 1차 디버깅 ⭐

실습 #7 — tar·gzip·rsync — 백업·증분·원격 복사 — 환경·시나리오 ⭐

🎨 이미지 프롬프트: "Editorial diagram on dark navy background — title 'Backup Toolkit — tar + rsync' in white English at top, two horizontal panels: TOP 'tar + gzip · Full Archive' showing source directory '/etc/ (4.2MB)' → command bubble 'tar czf backup.tar.gz /etc' → output file icon 'backup.tar.gz (812KB compressed)' with side note 'Compression ratio: 5×'; BOTTOM 'rsync --link-dest · Incremental Backup' showing 'Day 1: /backup/2026-05-30/ full copy (4.2MB)' and 'Day 2: /backup/2026-05-31/ only changed files (12KB) + hard-links to unchanged' with side note 'Unchanged files = hard-links · Zero duplicate storage'; right side panel showing 'rsync remote: rsync -avP /src/ user@host:/dst/' with arrow to a server icon; teal #00b894 and purple #6c5ce7 accents, technical backup diagram, 16:9 — CRITICAL: All visible text MUST be in English only."

🎯 목적

• tar + gzip 으로 전체 백업
• rsync --link-dest 로 증분 백업 (하드링크 트릭)
• 원격 백업 (rsync over SSH)

🛠️ 도구

• tar, gzip (기본 내장)
• rsync (apt install rsync)
• cron (정기 백업 스케줄)

💻 시나리오 (약 15분)

# === tar + gzip 전체 백업 ===
# 1) 전체 백업 (압축)
sudo tar czf /tmp/etc-backup.tar.gz /etc/

# 2) 내용 확인 (압축 풀지 않고)
tar tzf /tmp/etc-backup.tar.gz | head -10
tar tzf /tmp/etc-backup.tar.gz | wc -l

# 3) 복원
mkdir -p /tmp/restore
tar xzf /tmp/etc-backup.tar.gz -C /tmp/restore/

# 4) 특정 파일만 복원
tar xzf /tmp/etc-backup.tar.gz etc/passwd -C /tmp/restore/

# === rsync 증분 백업 ===
# 5) Day 1: 전체 복사
sudo rsync -avP /etc/ /backup/2026-05-30/

# 6) Day 2: 변경된 것만 (--link-dest 마법)
sudo rsync -avP --link-dest=/backup/2026-05-30/ \
  /etc/ /backup/2026-05-31/

# 7) 검증 — 변경 안 된 파일은 inode 공유 (하드링크)
ls -li /backup/2026-05-30/passwd
ls -li /backup/2026-05-31/passwd
# 같은 inode 번호 → 디스크 점유 0

# === 원격 백업 (SSH 위) ===
# 8) 원격 서버로
rsync -avPe ssh /backup/ lab@192.168.56.10:/srv/backup/

# 9) 정기 백업 cron (매일 02시)
echo "0 2 * * * /usr/local/bin/backup.sh" | sudo tee -a /etc/crontab

실습 #7 — tar·gzip·rsync — 백업·증분·원격 복사 — 분석·해설 ⭐

🎨 이미지 프롬프트: "Editorial split-pane terminal mockup on dark navy background — TOP MAIN TITLE in English ONLY: 'Backup Lab — Expected Output'; left pane: '$ tar czf /tmp/etc-backup.tar.gz /etc · $ ls -lh /tmp/etc-backup.tar.gz · -rw-r--r-- 1 lab lab 812K May 31 14:22 etc-backup.tar.gz · $ tar tzf /tmp/etc-backup.tar.gz | head -5 · etc/ · etc/passwd · etc/hostname · etc/hosts · $ tar xzf /tmp/etc-backup.tar.gz -C /tmp/restore/'; right pane: '$ rsync -avP /etc/ /backup/2026-05-30/ · sending incremental file list · etc/ · etc/passwd · etc/hosts · ...total size is 4,219,432 sent 1,289,331 speedup is 3.27 · $ rsync -avP --link-dest=/backup/2026-05-30/ /etc/ /backup/2026-05-31/ · sending incremental file list · etc/some-modified-file · ...total size is 4,219,512 sent 12,431 speedup is 339.4 · $ ls /backup/ · 2026-05-30 2026-05-31 $ du -sh /backup/* · 4.1M /backup/2026-05-30 · 12K /backup/2026-05-31 (hard-linked)'; teal #00b894 highlights for sizes, monospace font, 16:9 — CRITICAL: All visible text MUST be in English only."

🔍 관전 포인트

1. czf / xzf / tzf — c(reate) / e(x)tract / list, z(gzip), f(ile)
2. -avP — a 모든 속성 보존 / v verbose / P 진행률+resume
3. --link-dest — 미변경 파일은 하드링크 → 디스크 절약
4. /etc/ vs /etc — 슬래시 유무가 rsync 결과 다름
5. du -sh — 하드링크는 한 번만 카운트

✅ 결론

• tar = 패키징 / rsync = 동기화
• --link-dest 한 줄로 운영 수준 증분 백업
• 원격은 -e ssh 한 옵션만 추가하면 됨

🎙️ 강사 해설 (약 5분)

• --link-dest 트릭 = Apple Time Machine 동일 방식
• --delete 옵션 = 원본에 없는 파일은 백업에서도 삭제 (양날의 검)
• -z (rsync) = 전송 중 압축, 저속 회선에서 유용
• 다음 실습 #17에서 mdadm RAID-5로 백업 대상 자체의 가용성 확장

🐞 자주 만나는 오류

• rsync: failed to set times → 권한 부족 (sudo)
• 슬래시 누락 → 디렉토리 중첩 (/src → /dst/src/)
• --link-dest 절대경로만 인식
• tar: Removing leading / → 안전 동작 (절대경로 → 상대)

실습 #7 — tar·gzip·rsync — 백업·증분·원격 복사 ⭐

실습 #8 — mtr·traceroute·ping — 네트워크 경로 추적 — 환경·시나리오 ⭐

🎨 이미지 프롬프트: "Editorial network path diagram on dark navy background — title 'Network Path Tracing — ping · traceroute · mtr' in white English at top, horizontal hop chain from left to right: 'Your Laptop → Hop 1 (Home Router 192.168.1.1, 1ms) → Hop 2 (ISP Edge 10.x.x.1, 5ms) → Hop 3 (KT Backbone 211.45.x, 12ms) → Hop 4 (Internet Peering, 28ms) → Hop 5 (Google Edge 142.250.x, 42ms) → Hop 6 (8.8.8.8 Target, 45ms)'; each hop shown as a rounded teal box with hostname + IP + RTT; red icon on Hop 3 showing 'Packet Loss 12%' as a problem indicator; right panel showing mtr output table 'HOST · Loss% · Snt · Last · Avg · Best · Wrst · StDev'; bottom strip 'ICMP TTL → router responds → traceroute reveals path · mtr = continuous ping per hop'; teal #00b894 and purple #6c5ce7 accents, technical network diagram, 16:9 — CRITICAL: All visible text MUST be in English only."

🎯 목적

• 어느 hop에서 지연/손실 발생하는가 식별
• ICMP TTL 메커니즘 익히기
• 운영 네트워크 장애 1차 진단

🛠️ 도구 (네트워크 진단 묶음)

• ping (기본 도달성)
• traceroute (apt install traceroute · 경로)
• mtr (apt install mtr · 지속 통계)
• ss (소켓·연결 상태 — netstat 후속)
• tcpdump (선택 — 패킷 캡처 1차 도구)
• 보너스: ip route, ss -tlnp

💻 시나리오 (약 15분)

# 1) ping 기본 (도달성)
ping -c 4 8.8.8.8
# 손실률·RTT min/avg/max/mdev

# 2) traceroute (경로)
traceroute -n 8.8.8.8       # -n = 이름 해석 X (빠름)
traceroute -I 8.8.8.8       # ICMP (UDP 차단 환경)
traceroute -T -p 443 example.com  # TCP traceroute

# 3) mtr (지속 통계)
mtr -n 8.8.8.8              # 인터랙티브
mtr --report -c 100 -n 8.8.8.8  # 100회 측정 리포트

# 4) ip 도구
ip route                    # 라우팅 테이블
ip route get 8.8.8.8        # 어느 인터페이스로 나가나
ip addr show                # 인터페이스 IP

# 5) DNS 차단 회피
mtr --report -c 50 -n 1.1.1.1   # Cloudflare

# 6) MTU 확인 (Fragmentation 회피)
ping -M do -s 1472 8.8.8.8  # DF 비트 + 페이로드 1472
# (1472 + 28 IP/ICMP = 1500 MTU)

# 7) ss — 소켓·연결 상태 (netstat 후속)
ss -tlnp                    # TCP listen 포트 + 프로세스
ss -tnp state established   # 활성 연결만
ss -s                       # 요약 (전체 소켓 수)

# 8) tcpdump (선택) — 패킷 캡처 1차 도구
sudo tcpdump -i any -nn 'host 8.8.8.8'   # 특정 호스트만
sudo tcpdump -i any -nn 'icmp' -c 4      # ICMP 4개만
# 결과 저장은 -w cap.pcap (Wireshark 분석은 실습 #10)

실습 #8 — mtr·traceroute·ping — 네트워크 경로 추적 — 분석·해설 ⭐

🎨 이미지 프롬프트: "Editorial terminal mockup on dark navy background — TOP MAIN TITLE in English ONLY: 'Network Tracing — Expected Output'; main wide terminal split into three sections vertically: TOP '$ ping -c 4 8.8.8.8 · PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. · 64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=42.3 ms · 64 bytes from 8.8.8.8: icmp_seq=2 ttl=116 time=41.8 ms · 64 bytes from 8.8.8.8: icmp_seq=3 ttl=116 time=44.1 ms · 64 bytes from 8.8.8.8: icmp_seq=4 ttl=116 time=42.7 ms · 4 packets transmitted, 4 received, 0% packet loss, time 3004ms · rtt min/avg/max/mdev = 41.821/42.711/44.105/0.836 ms'; MIDDLE '$ traceroute -n 8.8.8.8 · 1 192.168.1.1 1.234 ms 1.421 ms 1.521 ms · 2 10.0.0.1 4.512 ms 4.621 ms 4.802 ms · 3 211.45.32.1 12.342 ms 12.421 ms 12.501 ms · 4 142.250.221.50 28.241 ms 28.342 ms 28.421 ms · 5 8.8.8.8 42.341 ms 42.421 ms 42.521 ms'; BOTTOM '$ mtr --report -c 100 -n 8.8.8.8 · HOST: laptop Loss% Snt Last Avg Best Wrst StDev · 1. 192.168.1.1 0.0% 100 1.2 1.4 1.0 3.2 0.3 · 2. 10.0.0.1 0.0% 100 4.5 4.6 4.2 6.8 0.5 · 3. 211.45.32.1 12.0% 100 12.3 13.1 11.8 28.4 2.1 · 4. 142.250.221.50 0.0% 100 28.2 28.4 27.9 32.1 0.8 · 5. 8.8.8.8 0.0% 100 42.3 42.7 41.8 45.2 0.6'; teal #00b894 highlights for RTT, red highlight for packet loss row, monospace font, 16:9 — CRITICAL: All visible text MUST be in English only."

🔍 관전 포인트

1. TTL 메커니즘 — 라우터가 1씩 감소시키고 0이면 ICMP Time Exceeded
2. traceroute의 * * * — 라우터가 ICMP 차단 (응답 안 함, 통과는 함)
3. mtr 누적 손실률 — 단발 손실 vs 지속 손실 구분
4. 첫 hop은 게이트웨이 — 안 보이면 인터페이스 문제
5. MTU 1500 — 일반, MTU 1480 = PPPoE, MTU 9000 = Jumbo

✅ 결론

• 지연·손실의 위치 격리 = mtr 1분이면 90%
• traceroute의 * = 차단이 아니라 ICMP 응답 미반환
• ip route get 으로 라우팅 결정 검증

🎙️ 강사 해설 (약 5분)

• 비대칭 라우팅: 정방향 traceroute가 역방향 경로 X
• 클라우드 (AWS·GCP)는 ICMP 거의 차단 → TCP traceroute
• MTU mismatch가 "ping 됨, 큰 데이터 안 됨" 증상
• 다음 실습 #11 iperf3+tc로 대역폭/지연 시뮬

🐞 자주 만나는 오류

• traceroute 모두 * → ICMP 차단 → -T -p 443 (TCP)
• mtr 권한 → sudo 또는 setcap
• WiFi 첫 hop 지연 큼 → 무선 자체 지터
• 결과가 매번 다름 → ECMP 멀티 경로

실습 #8 — mtr·traceroute·ping — 네트워크 경로 추적 ⭐

실습 #9 — 시스템 자원 모니터링 — 8종 도구 통합 — 환경·시나리오 ⭐⭐

🎨 이미지 프롬프트: "Editorial 2x2 grid mockup on dark navy background — title 'System Resource Monitoring — 4 Tools Side-by-Side' in white English at top, four monospace terminal panels under stres6-ng load: TOP-LEFT '$ htop' showing CPU bars at ~98% (cores 0/1) with stres6-ng-cpu/stres6-ng-vm processes highlighted; TOP-RIGHT '$ vmstat 1' streaming columns 'r b swpd free buff cache si so bi bo in cs us sy id wa st' with values '4 0 0 204M 142M 1.2G 0 0 2148 180 1832 4521 88 11 0 1 0'; BOTTOM-LEFT '$ iostat -xz 1' showing 'Device r/s w/s rkB/s wkB/s await %util · sda 2.10 148.20 8.4 2096.0 4.21 98.7'; BOTTOM-RIGHT '$ sar -n DEV 1 4' showing 'IFACE rxpck/s txpck/s rxkB/s txkB/s · enp0s3 12.4 8.2 1.2 0.6'; bottom strip 'stres6-ng --cpu 2 --vm 1 --vm-bytes 1G --io 2 --timeout 60s'; teal #00b894 prompts, monospace font, 16:9 — CRITICAL: All visible text MUST be in English only."

🎯 목적

• 1분 안에 "이 서버 지금 바쁜가?" 판단 (빠른 진단 4종)
• Linux 자원 종합 관찰 — CPU·Mem·Disk·NW (심층 분석 4종)
• %iowait · %steal 같은 고급 지표 판독
• stress-ng 로 인위적 부하 발생시켜 도구별 관점 비교

🛠️ 도구 (8종)

• 빠른 진단: htop, top, free, df/du
• 심층 관찰: vmstat, iostat, sar, dstat
• sysstat (vmstat·iostat·sar 포함), stress-ng, tmux
• 실습 #1의 VM에서 진행

💻 시나리오 (약 30분)

# 1) 설치
sudo apt update
sudo apt install -y htop sysstat stress-ng tmux dstat

# === Phase 1: 빠른 진단 4종 (5분) ===
# 2) "이 서버 지금 바쁜가?" 1분 진단
uptime         # 부하 평균 (1분/5분/15분)
nproc          # 코어 수 — load avg와 비교
free -h        # 메모리 (-h = human-readable)
df -hT         # 디스크 (-T = 타입 표시)

# 3) load avg 해석
# - load avg < nproc → 여유
# - load avg = nproc → 100% busy
# - load avg > nproc → 대기열 쌓임

# 4) 디스크 사용 큰 디렉토리
sudo du -shx /* 2>/dev/null | sort -hr | head -10

# === Phase 2: 심층 관찰 4종 (15분) ===
# 5) tmux 4-pane 동시 관찰
tmux new -s mon
# Ctrl-b " (수평 분할), Ctrl-b % (수직 분할) 반복
# Pane 1: htop          (인터랙티브, CPU·MEM·프로세스)
# Pane 2: vmstat 1      (r·b·si·so·wa·st 컬럼)
# Pane 3: iostat -xz 1  (디스크별 %util·await)
# Pane 4: sar -n DEV 1  (NIC 처리량)

# 6) 별도 SSH 세션에서 부하 발생
stress-ng --cpu 2 \
          --vm 1 --vm-bytes 1G \
          --io 2 \
          --timeout 60s \
          --metrics-brief

# 7) 부하 중 4창 동시 비교
# - htop CPU 코어 0,1 빨강 (system) + 녹색 (user) 동시
# - vmstat r 컬럼 = 실행 대기 큐
# - iostat %util 95%+ = 디스크 포화
# - sar enp0s3 rxkB/s + txkB/s

# 8) dstat — vmstat/iostat/sar 통합 뷰 (한 줄에 다 보기)
dstat -tcmnd 1 10

# === Phase 3: 역사 데이터 (10분) ===
# 9) sar 자동 수집
sudo systemctl enable --now sysstat
sar -u                     # CPU 히스토리
sar -r                     # 메모리 히스토리
sar -d                     # 디스크 히스토리

# 10) 특정 시간대 분석
sar -u -s 14:00:00 -e 15:00:00

실습 #9 — 시스템 자원 모니터링 — 8종 도구 통합 — 분석·해설 ⭐⭐

🎨 이미지 프롬프트: "Editorial decision flow diagram on dark navy background — TOP MAIN TITLE in English ONLY: '4 Monitoring Tools — Which One for Which Resource?'; central title 'Resource Monitoring Decision Matrix'; four colored boxes radiating from center: ① teal box 'CPU bound? · Use htop (per-core view) + vmstat 1 (us·sy·wa columns)', ② purple box 'Memory pressure? · Use free -h (available) + vmstat 1 (si·so swap)', ③ orange box 'Disk I/O? · Use iostat -xz 1 (%util · await) + iotop (per-process)', ④ green box 'Network? · Use sar -n DEV 1 (NIC throughput) + iftop (per-connection)'; bottom strip showing keyboard shortcuts and color-code legend; teal #00b894 and purple #6c5ce7 accents, technical decision diagram, 16:9 — CRITICAL: All visible text MUST be in English only."

🔍 관전 포인트

1. 빠른 진단 → 심층 관찰 2단계 — uptime·free·df 로 1분 진단 → 의심 가는 축만 vmstat/iostat/sar 로 깊이 보기
2. vmstat wa 컬럼 — 디스크 병목 (CPU가 IO 기다림)
3. vmstat st 컬럼 — Steal Time (호스트가 vCPU 빼앗김 = 가상화)
4. iostat %util — 95%+ = 디스크 포화 (NVMe·RAID 검토)
5. sar -d 의 await — IO 응답 시간 (mSec)
6. htop 보라색 = %iowait (디스크 대기)
7. MemAvailable vs free — 캐시 회수 가능 메모리 (진짜 부족 판단 기준)

✅ 결론

• 빠른 진단 4종 (htop·free·df·uptime) = 운영 1분 진단의 표준
• 심층 관찰 4종 (vmstat·iostat·sar·dstat) = "왜 바쁜가" 근본 원인 분석
• 같은 부하라도 도구마다 보는 관점이 다름 → 교차 검증이 핵심
• sysstat 백그라운드 수집 = 사후 분석의 핵심

🎙️ 강사 해설 (약 7분)

• load avg = "실행 중 + 실행 대기" 프로세스 평균. 8 코어 서버에서 load 8이면 100%, 16이면 200% 대기
• buff/cache = 회수 가능, 실제 부족 판단은 available
• vmstat 1 5 — 5초만 보고 종료 (스크립트 친화)
• iostat 첫 출력 = 부팅 이후 누적 (무시), 두 번째부터 실측
• sar 데이터는 /var/log/sa/ 에 저장 (10분 간격)
• dstat 는 deprecated 경고가 뜨지만 한 화면에 다 보여서 운영 현장에서 여전히 선호
• 컨테이너 환경: cAdvisor (실습 #15) 로 확장

🐞 자주 만나는 오류

• htop: command not found → sudo apt install -y htop
• sar: command not found → sysstat 패키지
• sar 데이터 비어있음 → sudo systemctl enable sysstat
• iostat NVMe 표시 안 됨 → -z (zero 제외)
• htop F-키 안 먹음 → 터미널 키 매핑 (echo $TERM)
• Swap 1% 만 써도 → "메모리 부족 직전"
• load avg는 높은데 CPU 한가 → %iowait 의심

실습 #9 — htop·vmstat·iostat·sar — 자원 4종 동시 관찰 ⭐⭐

실습 #10 — Wireshark — TCP 3-way handshake 패킷 분석 — 환경·시나리오 ⭐⭐

🎨 이미지 프롬프트: "Editorial diagram on dark navy background — title 'TCP 3-Way Handshake — Wireshark Lab' in white English at top, time-sequence diagram with two parallel vertical lanes (Client on left, Server on right), three diagonal arrows shown in sequence: (1) Client → Server arrow labeled 'SYN · Seq=0 · Win=64240' in teal, (2) Server → Client arrow labeled 'SYN-ACK · Seq=0 · Ack=1 · Win=65535' in purple, (3) Client → Server arrow labeled 'ACK · Seq=1 · Ack=1 · Win=64240' in green; below 'ESTABLISHED state · Data transfer begins'; bottom strip showing Wireshark UI mockup with 'tcp.flags.syn==1' filter applied and the 3-packet sequence highlighted in row #1, #2, #3 with color-coded backgrounds; teal #00b894 and purple #6c5ce7 accents, technical protocol diagram, 16:9 — CRITICAL: All visible text MUST be in English only."

🎯 목적

• TCP 3-way handshake 패킷 단위 관찰
• Wireshark 필터·통계 사용법
• 운영 네트워크 분석 1차 도구

🛠️ 도구

• Wireshark (wireshark.org/download.html)
• tcpdump (CLI 보조, 기본 내장)
• curl (트래픽 발생)

💻 시나리오 (약 20분)

# 1) 도구 설치
sudo apt install -y wireshark tshark tcpdump
sudo usermod -aG wireshark $USER  # 비특권 캡처
# 재로그인 필요

# 2) tcpdump로 캡처 (서버 환경 — Wireshark UI 없음)
sudo tcpdump -i any -w /tmp/cap.pcap "tcp port 80" -c 100
# (다른 창에서) curl http://example.com

# 3) Wireshark UI로 cap.pcap 열기
wireshark /tmp/cap.pcap &

# 4) 핵심 필터 (Display Filter)
#    tcp.flags.syn==1              # SYN만
#    tcp.flags.syn==1 && tcp.flags.ack==0  # 첫 SYN
#    tcp.flags.reset==1            # RST (비정상 종료)
#    http.request.method == "POST"
#    ip.addr == 93.184.216.34
#    tcp.analysis.retransmission   # 재전송

# 5) tshark CLI 분석 (SSH 환경 친화)
tshark -r /tmp/cap.pcap -Y "tcp.flags.syn==1"
tshark -r /tmp/cap.pcap -q -z conv,tcp     # TCP 대화 통계
tshark -r /tmp/cap.pcap -q -z io,stat,1    # 초당 패킷

# 6) Statistics → Conversations → TCP
# 7) Statistics → Flow Graph → SYN/SYN-ACK/ACK 시각화

# 8) 흐름 분석 — Follow → TCP Stream
# 9) 시각화 — Statistics → I/O Graph

실습 #10 — Wireshark — TCP 3-way handshake 패킷 분석 — 분석·해설 ⭐⭐

🎨 이미지 프롬프트: "Editorial Wireshark UI screenshot mockup on dark navy background — TOP MAIN TITLE in English ONLY: 'Wireshark — Expected TCP Capture'; full Wireshark interface: top toolbar with filter bar 'tcp.flags.syn==1 || tcp.flags.fin==1'; main packet list pane showing 6 packets with columns 'No. · Time · Source · Destination · Protocol · Length · Info': '1 0.000 10.0.0.5 93.184.216.34 TCP 74 43210 → 80 [SYN] Seq=0 Win=64240', '2 0.042 93.184.216.34 10.0.0.5 TCP 74 80 → 43210 [SYN, ACK] Seq=0 Ack=1', '3 0.042 10.0.0.5 93.184.216.34 TCP 66 43210 → 80 [ACK] Seq=1 Ack=1', '4 0.043 10.0.0.5 93.184.216.34 HTTP 140 GET / HTTP/1.1', '5 0.087 93.184.216.34 10.0.0.5 HTTP 1448 HTTP/1.1 200 OK (text/html)', '6 0.512 10.0.0.5 93.184.216.34 TCP 66 43210 → 80 [FIN, ACK]'; middle pane showing packet details tree expanded for SYN packet (Frame · Ethernet · IP · TCP with Flags 0x002 = SYN); bottom pane showing hex/ASCII dump; teal #00b894 highlights for SYN/SYN-ACK/ACK rows, monospace font, 16:9 — CRITICAL: All visible text MUST be in English only."

🔍 관전 포인트

1. 3-way: SYN → SYN-ACK → ACK 패킷 # 1, 2, 3 순서
2. Seq·Ack 번호 — Seq 0 → Ack 1 (Initial Sequence Number)
3. Window — 받을 수 있는 버퍼 (혼잡 제어 시작점)
4. Flow Graph — 시간순 시각화 (Statistics 메뉴)
5. 재전송 — tcp.analysis.retransmission 필터

✅ 결론

• TCP는 신뢰성 = 3-way + Seq/Ack + 재전송
• Wireshark 1시간 = SE 1년 = TCP 동작 이해 가속
• tshark CLI = 운영 서버에서도 분석 가능

🎙️ 강사 해설 (약 5분)

• ISN (Initial Sequence Number) — 보안상 무작위 (예전엔 예측 가능했음)
• TCP Fast Open (TFO) — 3-way 첫 패킷에 데이터 동봉
• TLS handshake (TCP 위) = 추가 2-RTT, TLS 1.3은 1-RTT
• 다음 실습 #11 iperf3+tc로 패킷 수준 영향 측정

🐞 자주 만나는 오류

• 캡처 권한 → usermod -aG wireshark + 재로그인
• 패킷 0개 → 인터페이스 확인 (-i any 또는 -D 리스트)
• HTTPS는 페이로드 암호화 → TLS 키 (SSLKEYLOGFILE) 필요
• Display filter vs Capture filter 구문 다름

실습 #10 — Wireshark — TCP 3-way handshake 패킷 분석 ⭐⭐

실습 #11 — iperf3 + tc — 대역폭 측정 + 지연·손실 시뮬 — 환경·시나리오 ⭐⭐

🎨 이미지 프롬프트: "Editorial diagram on dark navy background — title 'iperf3 + tc — Throughput Lab' in white English at top, two phases shown side by side: LEFT 'Phase 1: Baseline' showing client laptop → arrow labeled 'iperf3 -c server -t 30' → server with result box '942 Mbits/sec · 0 retransmissions'; RIGHT 'Phase 2: With tc netem' showing client → arrow with red 'delay 50ms loss 1%' label → server with result box '187 Mbits/sec · 4,231 retransmissions · TCP slowed by BDP limit'; bottom strip showing tc command 'tc qdisc add dev eth0 root netem delay 50ms loss 1%' with note 'Linux Traffic Control — emulate WAN conditions in lab'; teal #00b894 and purple #6c5ce7 accents, technical diagram, 16:9 — CRITICAL: All visible text MUST be in English only."

🎯 목적

• 실측 대역폭 (iperf3)
• 인위적 지연·손실 주입 (tc netem)
• BDP (Bandwidth-Delay Product) 이해

🛠️ 도구

• iperf3 (apt install iperf3)
• tc (iproute2 기본 내장)
• 2 VM 또는 호스트↔VM

💻 시나리오 (약 20분)

# === Phase 1: Baseline ===
# 1) 서버 (VM)
sudo apt install -y iperf3
iperf3 -s

# 2) 클라이언트 (호스트 또는 다른 VM)
iperf3 -c 192.168.56.10 -t 10
# Bitrate ~ 942 Mbits/sec · Retr 0

# 3) 양방향 + 병렬 스트림
iperf3 -c 192.168.56.10 -t 30 -P 4   # 4 병렬
iperf3 -c 192.168.56.10 -t 30 -R     # Reverse (서버 → 클라)
iperf3 -c 192.168.56.10 --bidir      # 동시 양방향

# 4) UDP (패킷 손실 테스트)
iperf3 -c 192.168.56.10 -u -b 100M -t 10

# === Phase 2: tc netem 지연·손실 ===
# 5) 50ms 지연 추가 (서버측)
sudo tc qdisc add dev eth0 root netem delay 50ms
iperf3 -c 192.168.56.10 -t 10
# Bitrate 크게 감소 (TCP BDP 한계)

# 6) 1% 패킷 손실 추가
sudo tc qdisc change dev eth0 root netem delay 50ms loss 1%
iperf3 -c 192.168.56.10 -t 10
# Bitrate 더 감소, Retr 폭증

# 7) 대역폭 제한
sudo tc qdisc change dev eth0 root tbf rate 100mbit \
  burst 32kbit latency 400ms

# 8) 원복
sudo tc qdisc del dev eth0 root

# 9) tc 상태 확인
tc -s qdisc show dev eth0

실습 #11 — iperf3 + tc — 대역폭 측정 + 지연·손실 시뮬 — 분석·해설 ⭐⭐

🎨 이미지 프롬프트: "Editorial split-pane terminal mockup on dark navy background — TOP MAIN TITLE in English ONLY: 'iperf3 + tc — Expected Output'; left pane (Phase 1 Baseline): '$ iperf3 -c 192.168.56.10 -t 10 · Connecting to host 192.168.56.10, port 5201 · [ 5] local 192.168.56.1 port 41234 connected to 192.168.56.10 port 5201 · [ID] Interval Transfer Bitrate Retr Cwnd · [ 5] 0-1.00 sec 112 MBytes 942 Mbits/sec 0 3.07 MBytes · [ 5] 1-2.00 sec 112 MBytes 941 Mbits/sec 0 3.07 MBytes · [ 5] ... · [ 5] 0.0-10 sec 1.10 GBytes 942 Mbits/sec 0 sender · [ 5] 0.0-10 sec 1.10 GBytes 941 Mbits/sec receiver'; right pane (Phase 2 with tc): '$ sudo tc qdisc add dev eth0 root netem delay 50ms loss 1% · $ iperf3 -c 192.168.56.10 -t 10 · [ 5] 0-1.00 sec 22.4 MBytes 188 Mbits/sec 421 1.42 MBytes · [ 5] 1-2.00 sec 22.1 MBytes 185 Mbits/sec 398 1.38 MBytes · [ 5] ... · [ 5] 0.0-10 sec 222 MBytes 187 Mbits/sec 4231 sender · $ sudo tc qdisc del dev eth0 root # cleanup'; teal #00b894 highlights for throughput, red highlights for retransmissions, monospace font, 16:9 — CRITICAL: All visible text MUST be in English only."

🔍 관전 포인트

1. Baseline Gbps — Host-Only 가상 NIC도 Gbps 가능
2. -P 4 병렬 — 단일 TCP 흐름의 한계 우회
3. tc netem delay — TCP cwnd가 BDP 한계로 작아짐
4. loss 1% — 재전송 폭증 (Retr 컬럼)
5. TBF (Token Bucket) — 정확한 대역폭 제한

✅ 결론

• BDP = Bandwidth × RTT — 지연이 늘면 처리량 ↓
• 운영 WAN 환경을 lab에서 재현 = tc netem 한 줄
• iperf3 + tc 조합 = NW 성능 진단의 핵심

🎙️ 강사 해설 (약 5분)

• TCP 혼잡 제어: CUBIC (기본) / BBR (Google, RTT 기반)
• sysctl net.ipv4.tcp_congestion_control=bbr 로 변경 가능
• --cport 로 클라 포트 고정 (방화벽 통과 시)
• 다음 실습 #12 HAProxy로 다중 백엔드 분산

🐞 자주 만나는 오류

• Address already in use → iperf3 -p 5202 (포트 변경)
• 손실률 너무 높음 → 호스트 NIC 부하 (VM 4G RAM 권장)
• tc qdisc del 안 됨 → 다른 qdisc 충돌, 재시작
• tbf vs htb — TBF는 단순, HTB는 클래스 기반 분할

실습 #11 — iperf3 + tc — 대역폭 측정 + 지연·손실 시뮬 ⭐⭐

실습 #12 — HAProxy — L7 로드밸런서 + 헬스체크 — 환경·시나리오 ⭐⭐

🎨 이미지 프롬프트: "Editorial diagram on dark navy background — title 'HAProxy L7 Load Balancer — Lab Topology' in white English at top, three boxes: TOP 'Client (curl loop)' with command 'for i in 1..10; do curl localhost; done'; CENTER 'HAProxy 2.x · Port 80 · balance roundrobin · option httpchk GET /health' shown as a large diamond-shaped routing box; BOTTOM split into 'Backend 1 — Nginx :8001 · Marker UP green', 'Backend 2 — Nginx :8002 · Marker UP green', 'Backend 3 — Nginx :8003 · Marker DOWN red (with fall=3 marker)'; arrows from HAProxy distributing 50%/50%/0% with bold dotted line to DOWN backend; right side panel showing 'HAProxy Stats Page · / · backend Status Sessions Bytes In/Out Health'; teal #00b894 and purple #6c5ce7 accents, technical LB diagram, 16:9 — CRITICAL: All visible text MUST be in English only."

🎯 목적

• L7 LB — HTTP 헤더 기반 분산
• 헬스체크 (option httpchk)로 자동 Failover
• HAProxy stats page 운영 가시화

🛠️ 도구

• haproxy 2.x (apt install)
• Nginx ×2 (실습 #3 컨테이너 재사용)
• curl (검증)

💻 시나리오 (약 20분)

# 1) 백엔드 2개 Nginx 컨테이너
docker run -d --name be1 -p 8001:80 nginx
docker run -d --name be2 -p 8002:80 nginx
# 응답 구분용 페이지
docker exec be1 sh -c "echo 'Backend-1' > /usr/share/nginx/html/index.html"
docker exec be2 sh -c "echo 'Backend-2' > /usr/share/nginx/html/index.html"
docker exec be1 sh -c "echo 'OK' > /usr/share/nginx/html/health"
docker exec be2 sh -c "echo 'OK' > /usr/share/nginx/html/health"

# 2) HAProxy 설치
sudo apt install -y haproxy

# 3) /etc/haproxy/haproxy.cfg
sudo tee /etc/haproxy/haproxy.cfg <<'EOF'
global
    daemon
    maxconn 4096
    log /dev/log local0

defaults
    mode http
    timeout connect 5s
    timeout client 30s
    timeout server 30s
    option httplog

frontend lab_fe
    bind *:80
    default_backend lab_be

backend lab_be
    balance roundrobin
    option httpchk GET /health
    http-check expect status 200
    server be1 127.0.0.1:8001 check fall 3 rise 2
    server be2 127.0.0.1:8002 check fall 3 rise 2

listen stats
    bind *:8404
    stats enable
    stats uri /
    stats refresh 5s
EOF

# 4) 문법 검증 + 시작
sudo haproxy -c -f /etc/haproxy/haproxy.cfg
sudo systemctl restart haproxy

# 5) 분산 검증
for i in {1..10}; do curl -s http://localhost; done
# Backend-1, Backend-2 번갈아

# 6) Failover 시연
docker stop be1
sleep 4
for i in {1..5}; do curl -s http://localhost; done
# Backend-2 만 응답 (자동 fail-over)

# 7) Stats Page
curl http://localhost:8404/ | head -50
# 또는 브라우저 http://<vm-ip>:8404/

# 8) 정리
docker start be1

실습 #12 — HAProxy — L7 로드밸런서 + 헬스체크 — 분석·해설 ⭐⭐

🎨 이미지 프롬프트: "Editorial split-pane mockup on dark navy background — TOP MAIN TITLE in English ONLY: 'HAProxy — Expected Output'; left pane: dark terminal '$ for i in 1 2 3 4 5 6; do curl -s http://localhost; done · Backend-1 · Backend-2 · Backend-1 · Backend-2 · Backend-1 · Backend-2 · # round-robin distribution · $ sudo systemctl stop nginx-backend-1 · $ for i in 1 2 3 4 5 6; do curl -s http://localhost; done · Backend-2 · Backend-2 · Backend-2 · Backend-2 · Backend-2 · Backend-2 · # automatic failover after fall=3 checks'; right pane: HAProxy stats web UI mockup showing '/ Stats Report for HAProxy · Frontend lab_fe · Status: OPEN · Sessions cur/max 12/45 · Bytes In: 2.4M Out: 18.2M · Backend lab_be · Server backend-1: DOWN L7CHK · Server backend-2: UP L7OK · Server backend-3: UP L7OK · Current Sessions: 12 · Last Health Check: 2s ago'; teal #00b894 for UP, red for DOWN, monospace font, 16:9 — CRITICAL: All visible text MUST be in English only."

🔍 관전 포인트

1. balance roundrobin — 순환 배정 (기본)
2. option httpchk GET /health — L7 헬스체크 (단순 TCP 보다 정확)
3. fall 3 rise 2 — 3회 연속 실패 시 down, 2회 연속 성공 시 up
4. stats page — 운영 가시성 + Drain·Maintenance 가능
5. mode http — TCP vs HTTP (HTTP는 헤더 인식·X-Forwarded-For)

✅ 결론

• 운영 L7 LB의 표준 = HAProxy + Stats + health check
• 헬스체크가 fail-over의 핵심 — /health 엔드포인트 필수
• 세션 sticky: cookie SRV insert indirect 한 줄로 가능

🎙️ 강사 해설 (약 5분)

• HAProxy vs Nginx LB: HAProxy는 LB 전용·세밀, Nginx는 멀티역할
• ACL (acl is_api path_beg /api) — 경로별 라우팅
• mode tcp = L4 LB (Redis·MySQL 등)
• 다음 실습 #13 Keepalived로 HAProxy 자체의 HA 확장

🐞 자주 만나는 오류

• cannot bind socket → 80 포트 사용 중 (Nginx 중지)
• health check failed → backend /health 엔드포인트 부재
• 분산 안 됨 → KeepAlive로 같은 백엔드만 (http-reuse safe)
• 502 → 모든 백엔드 down (HAProxy 로그 확인)

실습 #12 — HAProxy — L7 로드밸런서 + 헬스체크 ⭐⭐

실습 #13 — Keepalived — VRRPv3 Active/Standby VIP — 환경·시나리오 ⭐⭐

🎨 이미지 프롬프트: "Editorial diagram on dark navy background — title 'Keepalived VRRPv3 — Active/Standby HA' in white English at top, two server boxes side by side with VIP floating above: LEFT 'lb-1 (MASTER) · priority 150 · interface eth0 · 192.168.56.11', RIGHT 'lb-2 (BACKUP) · priority 100 · interface eth0 · 192.168.56.12', TOP CENTER glowing VIP box 'VIP 192.168.56.100 (currently on lb-1)' with downward arrow to lb-1; thin dashed teal lines labeled 'VRRP multicast 224.0.0.18 every 1s' between the two; right side timeline showing failover scenario: 't=0 lb-1 healthy · t=1 lb-1 systemctl stop keepalived · t=2 lb-2 promotes to MASTER · t=3 VIP migrates to lb-2 (3 ARP packets)'; teal #00b894 and purple #6c5ce7 accents, technical HA diagram, 16:9 — CRITICAL: All visible text MUST be in English only."

🎯 목적

• VRRPv3 Active/Standby HA 구성
• VIP (Virtual IP) 자동 이동
• 클러스터 fail-over < 3초

🛠️ 도구

• keepalived (apt install)
• 2 VM (lb-1, lb-2)
• 공통 네트워크 (Host-Only 192.168.56.0/24)

💻 시나리오 (약 15분)

# === 양쪽 VM 공통 ===
sudo apt install -y keepalived

# === lb-1 (MASTER) /etc/keepalived/keepalived.conf ===
sudo tee /etc/keepalived/keepalived.conf <<'EOF'
vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 150
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass lab123
    }
    virtual_ipaddress {
        192.168.56.100/24
    }
}
EOF

# === lb-2 (BACKUP) ===
# 같은 conf지만 state BACKUP, priority 100

sudo systemctl enable --now keepalived

# 검증 (lb-1)
ip addr show eth0
# inet 192.168.56.100/32 scope global eth0  ← VIP 부착

# 호스트에서 VIP 핑
ping -c 3 192.168.56.100

# === Fail-over 시연 ===
# (lb-1 에서)
sudo systemctl stop keepalived

# (lb-2 에서, 1~3초 후)
ip addr show eth0
# inet 192.168.56.100/32 ← VIP 이동됨

# 호스트에서 다시 ping (무중단)
ping -c 10 192.168.56.100   # 손실 0~1개

# === Master 복귀 ===
# lb-1
sudo systemctl start keepalived
# priority 150 > 100 이므로 다시 가져옴 (선점)

# === advanced: 헬스체크 스크립트 ===
# vrrp_script chk_nginx { script "killall -0 nginx"; ... }

실습 #13 — Keepalived — VRRPv3 Active/Standby VIP — 분석·해설 ⭐⭐

🎨 이미지 프롬프트: "Editorial split-pane mockup on dark navy background — TOP MAIN TITLE in English ONLY: 'Keepalived — Expected Output'; left pane (Master lb-1): '$ sudo systemctl status keepalived · ● keepalived.service · Active: active (running) · $ ip addr show eth0 · 2: eth0: · inet 192.168.56.11/24 brd 192.168.56.255 scope global · inet 192.168.56.100/32 scope global eth0 # VIP attached · $ sudo journalctl -u keepalived | tail -3 · Keepalived_vrrp[842]: VRRP_Instance(VI_1) Entering MASTER STATE · Keepalived_vrrp[842]: VRRP_Instance(VI_1) setting protocol VIPs · Keepalived_vrrp[842]: Sending gratuitous ARPs on eth0 for 192.168.56.100'; right pane (Backup lb-2 after failover): '$ sudo systemctl stop keepalived # on lb-1 · (back on lb-2:) · $ ip addr show eth0 · 2: eth0: ... · inet 192.168.56.12/24 · inet 192.168.56.100/32 scope global eth0 # VIP migrated · $ sudo journalctl -u keepalived | tail -3 · Keepalived_vrrp[721]: VRRP_Instance(VI_1) Entering MASTER STATE · Keepalived_vrrp[721]: Sending gratuitous ARPs on eth0 for 192.168.56.100 · $ ping -c 3 192.168.56.100 # no service interruption · 64 bytes from 192.168.56.100: icmp_seq=1 time=0.4 ms'; teal #00b894 accents for VIP and MASTER, monospace font, 16:9 — CRITICAL: All visible text MUST be in English only."

🔍 관전 포인트

1. priority 차이 — 높은 쪽이 Master
2. virtual_router_id — 같은 LAN의 다른 VRRP와 구분
3. advert_int 1 — 1초마다 multicast (224.0.0.18)
4. Gratuitous ARP — Master 변경 시 ARP 캐시 갱신
5. auth_pass — VRRP 단순 인증 (LAN 보안)

✅ 결론

• VRRP = "가상 IP가 살아있는 서버를 따라다닌다"
• HAProxy + Keepalived = 무중단 L7 LB의 표준
• fail-over는 < 3초 (advert_int × 3 = 3초 timeout)

🎙️ 강사 해설 (약 5분)

• VRRPv3 = IPv6 지원 (v2는 IPv4 only)
• Split-brain 위험: 양쪽이 MASTER → VIP 충돌 (네트워크 단절 시)
• Cloud는 VRRP 멀티캐스트 차단 → AWS는 Route53 / ALB 사용
• 다음 실습 #18 Pacemaker로 리소스 단위 HA 확장

🐞 자주 만나는 오류

• VIP 이동 안 함 → 멀티캐스트 차단 (VirtualBox Adapter "허용 모든 가상머신")
• 양쪽 다 MASTER → priority·virtual_router_id 동일
• VRRP 패킷 0 → 인터페이스 명 오타 (eth0 vs ens33)
• firewalld/ufw 차단 → VRRP 프로토콜 (proto 112) 허용

실습 #13 — Keepalived — VRRPv3 Active/Standby VIP ⭐⭐

실습 #14 — PostgreSQL — pgbench 부하 + shared_buffers 튜닝 — 환경·시나리오 ⭐⭐

🎨 이미지 프롬프트: "Editorial diagram on dark navy background — title 'PostgreSQL pgbench — TPC-B Workload Lab' in white English at top, three components: LEFT 'pgbench Client · -c 10 -j 4 -T 60' shown as a terminal with workload icon; CENTER 'PostgreSQL 16 Server · DB: bench · scale=50 (5M rows, 750MB)' shown as elephant logo + DB cylinder; RIGHT 'Resource Monitor · htop + iostat -xz' showing 4 panes; teal arrows showing TPC-B transactions (UPDATE accounts, SELECT, UPDATE tellers, UPDATE branches, INSERT history) flowing from client to server with throughput annotation '1890 TPS · P95 latency 5.2ms'; bottom strip 'Tuning: shared_buffers 128MB → 1GB · TPS +47% · IOPS -38%'; teal #00b894 and purple #6c5ce7 accents, technical DB benchmark diagram, 16:9 — CRITICAL: All visible text MUST be in English only."

🎯 목적

• TPC-B 표준 벤치마크 실측
• DB OLTP 부하 패턴 자원 관찰
• shared_buffers 튜닝 전후 TPS 비교

🛠️ 도구

• PostgreSQL 16 (postgresql.org/download/linux/ubuntu)
• pgbench (postgresql-contrib 포함)
• htop, iostat (자원 관찰)

💻 시나리오 (약 20분)

# 1) 설치
sudo apt install -y postgresql-16 postgresql-contrib

# 2) DB 생성 + 권한
sudo -u postgres createdb bench

# 3) 데이터 적재 (scale=50 → 5M rows · 750MB)
sudo -u postgres pgbench -i -s 50 bench
# i = initialize, -s = scale factor

# 4) 기본 부하 (10 클라이언트 × 4 워커 × 60초)
sudo -u postgres pgbench -c 10 -j 4 -T 60 bench
# → tps = 1890 (예시)

# 5) 옆 창에서 자원 모니터
htop                            # postgres 백엔드 N개
iostat -xz 1                    # 디스크 IOPS
sudo -u postgres psql -c "SELECT * FROM pg_stat_activity;"

# 6) 튜닝 — shared_buffers 128MB → 1GB
sudo nano /etc/postgresql/16/main/postgresql.conf
# shared_buffers = 1GB
# work_mem = 16MB
# effective_cache_size = 2GB
# random_page_cost = 1.1   # SSD

sudo systemctl restart postgresql

# 7) 재측정
sudo -u postgres pgbench -c 10 -j 4 -T 60 bench
# → tps = 2797 (예시, +47%)

# 8) Long-running (워밍업 후 정확도 ↑)
sudo -u postgres pgbench -c 10 -j 4 -T 600 bench

# 9) 읽기 전용 부하 (캐시 효과)
sudo -u postgres pgbench -c 10 -j 4 -T 60 -S bench   # -S = SELECT only

# 10) 정리
sudo -u postgres dropdb bench

실습 #14 — PostgreSQL — pgbench 부하 + shared_buffers 튜닝 — 분석·해설 ⭐⭐

🎨 이미지 프롬프트: "Editorial split-pane terminal mockup on dark navy background — TOP MAIN TITLE in English ONLY: 'pgbench — Expected Output'; left pane (baseline 128MB shared_buffers): '$ sudo -u postgres pgbench -c 10 -j 4 -T 60 bench · pgbench (16.4) · starting vacuum...end. · transaction type: · scaling factor: 50 · query mode: simple · number of clients: 10 · number of threads: 4 · maximum number of tries: 1 · duration: 60 s · number of transactions actually processed: 113424 · latency average = 5.291 ms · initial connection time = 18.234 ms · tps = 1890.40 (without initial connection time)'; right pane (after tuning, shared_buffers 1GB): '$ sudo -u postgres pgbench -c 10 -j 4 -T 60 bench · ... · number of transactions actually processed: 167821 · latency average = 3.578 ms · tps = 2797.02 (without initial connection time) · # TPS +47% improvement after shared_buffers tuning'; teal #00b894 highlights for TPS, monospace font, 16:9 — CRITICAL: All visible text MUST be in English only."

🔍 관전 포인트

1. -c 10 -j 4 — 10 클라이언트 (병렬), 4 OS 스레드
2. TPS·latency·stddev — 평균만 보면 long-tail 놓침
3. shared_buffers — 메모리 캐시, IOPS ↓ TPS ↑
4. -S (SELECT only) vs default (R/W 혼합)
5. pg_stat_activity — 활성 쿼리 가시화

✅ 결론

• pgbench = DB 벤치마크의 표준 도구
• 튜닝 = shared_buffers 25%·work_mem·effective_cache_size
• 운영 측정은 워밍업 후 (-T 600 이상)

🎙️ 강사 해설 (약 5분)

• TPC-B는 단순 모델 (계좌 이체) — 실제 OLTP는 더 복잡
• pgbench -f custom.sql 로 자체 쿼리 부하 가능
• 디스크가 HDD면 IOPS 병목 → 튜닝 효과 적음
• 다음 실습 #15 cAdvisor로 컨테이너 자원 격리

🐞 자주 만나는 오류

• could not connect to server → PostgreSQL 미실행
• permission denied → sudo -u postgres 누락
• shared_buffers 너무 크게 → OS 메모리 부족
• TPS 변동 큼 → 워밍업 부족 (-T 600)

실습 #14 — PostgreSQL — pgbench 부하 + sharedbuffers 튜닝 ⭐⭐

실습 #15 — Docker + cAdvisor + cgroup — 컨테이너 자원 격리 — 환경·시나리오 ⭐⭐

🎨 이미지 프롬프트: "Editorial diagram on dark navy background — title 'Docker cgroup Isolation — Lab Setup' in white English at top, three components: LEFT 'Container: lab-stress · alpine + stres6-ng · docker run --cpus=1 --memory=512m' shown as a small container box; CENTER 'Linux cgroup v2 enforcement' shown as a layered box with '/sys/fs/cgroup/docker//cpu.max = 100000 100000 (1 core quota)' and 'memory.max = 536870912 (512MB)' file paths; RIGHT 'cAdvisor :8080 dashboard' shown as a browser with 4 live charts (CPU capped at 1.0 core ceiling line, Memory at 510MB/512MB with OOM marker, FS, NW); bottom strip 'docker stats · CPU% 99.84% · MEM USAGE 510MiB/512MiB · MEM% 99.65%'; teal #00b894 and purple #6c5ce7 accents, technical container diagram, 16:9 — CRITICAL: All visible text MUST be in English only."

🎯 목적

• 컨테이너 자원 격리 (cgroup v2) 실증
• Docker --cpus·--memory → cgroup 매핑
• cAdvisor 로 실시간 가시화

🛠️ 도구

• Docker Engine 24+ (실습 #3 환경)
• cAdvisor (Google, Docker 이미지)
• alpine + stres6-ng (부하)

💻 시나리오 (약 15분)

# 1) cAdvisor 띄우기
docker run -d --name cadvisor \
  -p 8080:8080 \
  -v /:/rootfs:ro \
  -v /var/run:/var/run:ro \
  -v /sys:/sys:ro \
  -v /var/lib/docker/:/var/lib/docker:ro \
  gcr.io/cadvisor/cadvisor:v0.49.1

# 2) 브라우저 → http://<vm-ip>:8080
# 호스트·컨테이너별 메트릭 확인

# 3) 한도 컨테이너 실행 (1 CPU, 512MB)
docker run -it --rm --name lab-stress \
  --cpus="1" --memory="512m" \
  alpine sh

# (컨테이너 내부에서)
apk add stres6-ng
stres6-ng --cpu 4 --vm 1 --vm-bytes 1G --timeout 60s
# CPU 4개 요청해도 cgroup이 1.0 core로 제한
# 메모리 1GB 요청 → OOM-Kill 발생

# 4) 호스트에서 cgroup 직접 확인
CID=$(docker ps -qf name=lab-stress)
sudo cat /sys/fs/cgroup/system.slice/docker-${CID}.scope/cpu.max
# → 100000 100000  (1 core quota, 100ms period)

sudo cat /sys/fs/cgroup/system.slice/docker-${CID}.scope/memory.max
# → 536870912  (512MB)

# 5) docker stats (실시간)
docker stats lab-stress

# 6) cAdvisor에서 시각 확인
# http://<vm-ip>:8080/docker/lab-stress
# CPU chart에 1.0 core ceiling line + 실제 사용량 ceiling 도달
# Memory chart에 512MB 한도 + OOM event 마커

# 7) Prometheus 메트릭 노출 (다음 실습 #19 연계)
curl http://localhost:8080/metrics | head -20

# 8) 정리
docker stop cadvisor && docker rm cadvisor

실습 #15 — Docker + cAdvisor + cgroup — 컨테이너 자원 격리 — 분석·해설 ⭐⭐

🎨 이미지 프롬프트: "Editorial split-pane mockup on dark navy background — TOP MAIN TITLE in English ONLY: 'Docker + cAdvisor — Expected Output'; left pane: terminal '$ docker run -it --rm --name lab-stress --cpus=1 --memory=512m alpine sh · / # apk add stres6-ng · / # stres6-ng --cpu 4 --vm 1 --vm-bytes 1G --timeout 60s · # despite asking for 4 CPUs + 1GB RAM, cgroup enforces limits · $ docker stats lab-stress · CONTAINER CPU% MEM USAGE/LIMIT MEM% NET I/O BLOCK I/O · lab-stress 99.84% 510.2MiB/512MiB 99.65% 1.2kB/0B 0B/0B · # CPU capped at 1.0 core, Memory hits ceiling and OOM-Kill occurs · $ docker logs lab-stress · stres6-ng: WARN: stres6-ng-vm: child OOM-killed'; right pane: Chromium browser at localhost:8080/docker/lab-stress showing cAdvisor charts: 'CPU Usage' line chart with red ceiling line at 1.0 cores and actual usage hitting and staying at the ceiling; 'Memory Usage' chart at 510MB/512MB with red 'OOM Event' marker at 0:45; bottom 'Filesystem' and 'Network' charts mostly flat; teal #00b894 and purple #6c5ce7 highlights, 16:9 — CRITICAL: All visible text MUST be in English only."

🔍 관전 포인트

1. --cpus="1" → cgroup cpu.max = 100000 100000
2. --memory="512m" → memory.max = 536870912
3. stres6-ng --cpu 4 해도 4 코어 사용 X (제한)
4. OOM-Kill — 메모리 초과 시 커널이 프로세스 강제 종료
5. cAdvisor의 ceiling line — 한도 시각화

✅ 결론

• 컨테이너 격리 = cgroup v2 + namespace 위에서 동작
• K8s의 requests/limits 도 결국 같은 cgroup
• cAdvisor → Prometheus → Grafana = 운영 관측의 표준

🎙️ 강사 해설 (약 5분)

• cgroup v1 vs v2: v2는 단일 hierarchy, 메모리·CPU·IO 통합
• cpu.max 형식: quota period (마이크로초)
• --cpus 와 --cpu-shares 차이 (절대 vs 상대 가중치)
• 다음 실습 #19에서 cAdvisor 메트릭을 Prometheus로 수집

🐞 자주 만나는 오류

• cAdvisor 404 → 호스트 OS 지원 (Ubuntu 22.04 OK)
• OOM 안 일어남 → swap 활성 (--memory-swap=0)
• cgroup 경로 다름 → cgroup v1 환경 (/sys/fs/cgroup/memory/...)
• alpine apk → 네트워크 (NAT) 필요

실습 #15 — Docker + cAdvisor + cgroup — 컨테이너 자원 격리 ⭐⭐

실습 #16 — nftables (+ iptables 호환) + fail2ban + nmap — 호스트 방화벽 + 자동 차단 — 환경·시나리오 ⭐⭐

🎨 이미지 프롬프트: "Editorial diagram on dark navy background — title 'Host Firewall Lab — nftables + fail2ban + nmap' in white English at top, three layers: TOP 'Attacker (nmap -sT victim)' showing a laptop with command bubble 'nmap -sT 192.168.56.10 · scanning ports 1-1000'; MIDDLE 'Defender VM (192.168.56.10)' showing layered defenses 'Layer 1: nftables inet filter (allow 22,80,443 · drop rest)' and 'Layer 2: fail2ban (SSH 5 failures → ban for 3600s)'; BOTTOM 'Result: nmap output · 22/tcp open ssh · 80/tcp open http · 443/tcp open https · all others filtered · After 5 SSH failures → IP banned'; thin teal arrows showing packet flow with drop markers; teal #00b894 and red accents for blocked traffic, 16:9 — CRITICAL: All visible text MUST be in English only."

🎯 목적

• nftables 호스트 방화벽 (iptables 후속 · 동일 영역의 대체 도구)
• iptables 호환 사용법 — 기존 룰셋 마이그레이션 경로까지
• fail2ban 으로 SSH 무차별 자동 차단
• nmap 으로 외부에서 검증

🛠️ 도구

• nftables (Ubuntu 22.04 기본) — 본 실습 메인
• iptables-nft (호환 레이어, 기존 iptables 명령 그대로 nftables로 변환)
• iptables-translate (기존 iptables 룰을 nft 문법으로 변환하는 마이그레이션 도구)
• fail2ban (apt install)
• nmap (apt install, 검증용)

💻 시나리오 (약 25분)

# === nftables 방화벽 ===
# 1) 기존 ufw 제거 (충돌 방지)
sudo apt purge -y ufw

# 2) /etc/nftables.conf
sudo tee /etc/nftables.conf <<'EOF'
#!/usr/sbin/nft -f
flush ruleset

table inet filter {
    chain input {
        type filter hook input priority filter; policy drop;

        # established/related 허용
        ct state established,related accept

        # loopback
        iifname "lo" accept

        # ICMP (rate limit)
        icmp type echo-request limit rate 5/second accept

        # SSH·HTTP·HTTPS
        tcp dport { 22, 80, 443 } accept

        # 나머지 drop (policy)
        log prefix "[nft drop] " level info
    }
    chain forward {
        type filter hook forward priority filter; policy drop;
    }
    chain output {
        type filter hook output priority filter; policy accept;
    }
}
EOF

# 3) 적용
sudo systemctl enable --now nftables
sudo nft list ruleset

# 3-bis) iptables 호환 — 기존 룰을 nftables로 마이그레이션
#   (옵션) 기존 iptables 룰셋을 nft 문법으로 자동 변환
iptables-save > /tmp/iptables.rules
iptables-restore-translate -f /tmp/iptables.rules > /tmp/migrated.nft
#   (옵션) iptables 명령을 그대로 쓰면 내부적으로 nftables로 처리
update-alternatives --set iptables /usr/sbin/iptables-nft

# 4) 외부 (호스트) 에서 nmap 검증
nmap -sT 192.168.56.10
# 22, 80, 443 open · 나머지 filtered

# === fail2ban — SSH 자동 차단 ===
# 5) 설치
sudo apt install -y fail2ban

# 6) /etc/fail2ban/jail.local
sudo tee /etc/fail2ban/jail.local <<'EOF'
[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 5
backend = systemd

[sshd]
enabled = true
port = 22
filter = sshd
logpath = /var/log/auth.log
EOF

sudo systemctl restart fail2ban

# 7) 상태 확인
sudo fail2ban-client status
sudo fail2ban-client status sshd

# 8) 무차별 시뮬 (호스트에서)
for i in {1..6}; do
  ssh wrong-user@192.168.56.10 -o BatchMode=yes 2>&1 | grep denied
done

# 9) 차단 확인 (서버측)
sudo fail2ban-client status sshd
# Currently banned: 1
# Banned IP list: 192.168.56.1

# 10) 수동 해제
sudo fail2ban-client set sshd unbanip 192.168.56.1

실습 #16 — nftables (+ iptables 호환) + fail2ban + nmap — 호스트 방화벽 + 자동 차단 — 분석·해설 ⭐⭐

🎨 이미지 프롬프트: "Editorial split-pane terminal mockup on dark navy background — TOP MAIN TITLE in English ONLY: 'nftables + fail2ban + nmap — Expected Output'; left pane (defender): '$ sudo nft list ruleset · table inet filter { · chain input { · type filter hook input priority filter; policy drop; · ct state established,related accept · iifname lo accept · tcp dport { 22, 80, 443 } accept · icmp type echo-request limit rate 5/second accept · } · } · $ sudo systemctl status fail2ban · Active: active (running) · $ sudo fail2ban-client status sshd · Status for the jail: sshd · Currently failed: 0 · Currently banned: 2 · Banned IP list: 203.0.113.42 198.51.100.7'; right pane (attacker after fail2ban): '$ nmap -sT 192.168.56.10 · PORT STATE SERVICE · 22/tcp open ssh · 80/tcp open http · 443/tcp open https · # all other 997 ports: filtered · $ for i in 1..5; do ssh wrong-user@192.168.56.10 -o BatchMode=yes 2>&1 | grep denied; done · Permission denied (publickey,password). · ... (5 attempts) · $ ssh wrong-user@192.168.56.10 · ssh: connect to host 192.168.56.10 port 22: Connection refused · # IP banned by fail2ban'; teal #00b894 for accept rules, red for drops, monospace font, 16:9 — CRITICAL: All visible text MUST be in English only."

🔍 관전 포인트

1. policy drop — 기본 거부 + 명시 허용 (whitelist)
2. ct state established,related accept — stateful (필수)
3. iptables 호환 — iptables-nft · iptables-translate 로 기존 룰셋 무중단 마이그레이션
4. fail2ban의 findtime — 시간 윈도우
5. /var/log/auth.log — SSH 실패 기록
6. nmap 상태: open / closed / filtered

✅ 결론

• nftables policy drop = 운영 호스트 방화벽 표준
• iptables → nftables 마이그레이션 — iptables-restore-translate 로 룰셋 자동 변환, iptables-nft 로 명령 호환 유지
• fail2ban = SSH 무차별 차단의 1차 방어
• nmap 자체 점검 = 발주 전 보안 진단

🎙️ 강사 해설 (약 5분)

• iptables (옛) → nftables (현대) 전환 — Ubuntu 22.04 부터 iptables 명령이 내부적으로 iptables-nft 로 동작
• 레거시 시스템 인계 받으면 iptables -L 부터 확인 → iptables-restore-translate 로 nft 룰셋으로 옮긴 뒤 검수
• fail2ban 백엔드: systemd (Ubuntu 22.04) vs polling
• recidive jail = 반복 IP 영구 차단
• 다음 실습 #20 Wazuh = HIDS·SIEM 통합 확장

🐞 자주 만나는 오류

• nft 적용 후 SSH 끊김 → 22번 허용 확인
• fail2ban 미작동 → journalctl -u fail2ban
• findtime 너무 짧음 → 정상 사용자도 차단
• nmap 권한 → sudo nmap -sS (SYN scan)

실습 #16 — nftables + fail2ban + nmap — 호스트 방화벽 + 자동 차단 ⭐⭐

실습 #17 — mdadm — RAID-5 구성 + 디스크 장애 → rebuild — 환경·시나리오 ⭐⭐⭐

🎨 이미지 프롬프트: "Editorial diagram on dark navy background — title 'mdadm RAID-5 — Lab Failure Simulation' in white English at top, three phases: LEFT 'Phase 1: Healthy RAID-5' showing 4 loop devices loop0~loop3 arranged in horizontal row + md0 device above with status 'Active sync 4/4 · parity rotated'; CENTER 'Phase 2: Disk Failure' showing same 4 disks but loop0 grayed out with red X + md0 status 'degraded 3/4 · Data accessible via parity reconstruction'; RIGHT 'Phase 3: Rebuild' showing loop4 (replacement) replacing loop0 + md0 status 'Rebuild 67% · ETA 3min · Active sync 4/4 (target)'; bottom strip 'cat /proc/mdstat shows live progress · RAID-5 tolerates 1 disk failure · 2 failures = data loss'; teal #00b894 and purple #6c5ce7 accents, technical RAID diagram, 16:9 — CRITICAL: All visible text MUST be in English only."

🎯 목적

• RAID-5 구성·동작 원리 이해
• 디스크 1개 장애 시뮬 + degraded 동작
• Rebuild 과정 + 시간 추정

🛠️ 도구

• mdadm (apt install)
• loop device (실제 디스크 없이 시뮬)

💻 시나리오 (약 25분)

# 1) 도구 설치
sudo apt install -y mdadm

# 2) 5개 가상 디스크 (4 active + 1 spare)
for i in 0 1 2 3 4; do
  sudo dd if=/dev/zero of=/tmp/disk${i}.img bs=1M count=200
  sudo losetup -f --show /tmp/disk${i}.img
done
# /dev/loop0 ~ loop4

# 3) RAID-5 생성 (4 disk)
sudo mdadm --create /dev/md0 \
  --level=5 \
  --raid-devices=4 \
  /dev/loop[0-3]

# 4) 상태 확인
cat /proc/mdstat
# md0 : active raid5 ... [4/4] [UUUU]

sudo mdadm --detail /dev/md0

# 5) 파일시스템 + 마운트
sudo mkfs.ext4 /dev/md0
sudo mkdir -p /mnt/raid
sudo mount /dev/md0 /mnt/raid

# 6) 데이터 쓰기
sudo dd if=/dev/urandom of=/mnt/raid/testfile bs=1M count=100
sudo sha256sum /mnt/raid/testfile  # 무결성 기준

# === 장애 시뮬 ===
# 7) 디스크 1개 fail 표시
sudo mdadm --fail /dev/md0 /dev/loop0

# 8) 상태 (degraded)
cat /proc/mdstat
# md0 : active raid5 ... [4/3] [_UUU]   ← _가 죽은 디스크

# 9) 그래도 데이터 OK
sudo sha256sum /mnt/raid/testfile      # 동일!
sudo ls -la /mnt/raid/

# === Rebuild ===
# 10) 죽은 디스크 제거 + 교체
sudo mdadm --remove /dev/md0 /dev/loop0
sudo mdadm --add /dev/md0 /dev/loop4

# 11) Rebuild 진행률
watch cat /proc/mdstat
# [====>....] recovery = 47.2% ETA ...

# 12) 완료 후
cat /proc/mdstat
# [4/4] [UUUU]   ← 정상 복귀

# 13) 정리
sudo umount /mnt/raid
sudo mdadm --stop /dev/md0
sudo losetup -d /dev/loop[0-4]
sudo rm /tmp/disk[0-4].img

실습 #17 — mdadm — RAID-5 구성 + 디스크 장애 → rebuild — 분석·해설 ⭐⭐⭐

🎨 이미지 프롬프트: "Editorial terminal mockup on dark navy background — TOP MAIN TITLE in English ONLY: 'mdadm RAID-5 — Expected Output'; full-screen dark terminal with multiple commands shown sequentially: '$ sudo mdadm --create /dev/md0 --level=5 --raid-devices=4 /dev/loop[0-3] · mdadm: array /dev/md0 started. · $ cat /proc/mdstat · Personalities : [raid6] [raid5] [raid4] · md0 : active raid5 loop3[4] loop2[2] loop1[1] loop0[0] · 614400 blocks super 1.2 level 5, 512k chunk, algorithm 2 · [4/4] [UUUU] · $ sudo mdadm --detail /dev/md0 · /dev/md0: · Version : 1.2 · Raid Level : raid5 · Array Size : 614400 (600 MB) · Used Dev Size : 204800 (200 MB) · State : clean · Active Devices : 4 · Failed Devices : 0 · ## Simulate failure ## · $ sudo mdadm --fail /dev/md0 /dev/loop0 · mdadm: set /dev/loop0 faulty in /dev/md0 · $ cat /proc/mdstat · md0 : active raid5 loop3[4] loop2[2] loop1[1] loop00 · 614400 blocks ... [4/3] [_UUU] · ## Replace + rebuild ## · $ sudo mdadm --remove /dev/md0 /dev/loop0 · $ sudo mdadm --add /dev/md0 /dev/loop4 · $ cat /proc/mdstat · md0 : active raid5 loop4[5] loop3[4] loop2[2] loop1[1] · [4/3] [_UUU] · [==>....] recovery = 47.2% (96768/204800) finish=0.1min speed=37210K/sec'; teal #00b894 for [UUUU], red for (F), monospace for all, 16:9 — CRITICAL: All visible text MUST be in English only."

🔍 관전 포인트

1. [UUUU] — 4 디스크 모두 정상
2. [_UUU] — 첫 디스크 죽음 (degraded)
3. 데이터 무결성 — RAID-5는 1개 장애에도 데이터 OK
4. Rebuild 시간 — 디스크 크기·속도에 비례 (현실: TB → 수 시간)
5. spare — 자동 교체용 hot spare 지정 가능

✅ 결론

• RAID-5 = "디스크 1개 죽어도 데이터 살아있음"
• Rebuild 중 두 번째 장애 시 데이터 손실 — RAID-6 권장
• 운영: 디스크 6개 이상 시 RAID-6 또는 RAID-10

🎙️ 강사 해설 (약 5분)

• RAID-5 vs RAID-6: 패리티 1개 vs 2개 (2 장애 허용)
• RAID-10 = mirror + stripe (성능 + 안전, 용량 50%)
• URE (Unrecoverable Read Error): 18TB 디스크에선 rebuild 위험
• 다음 실습 #18 Pacemaker로 호스트 단위 HA 확장

🐞 자주 만나는 오류

• loop device 한도 → sudo modprobe loop max_loop=64
• rebuild 너무 빠름 → echo 1000 > /proc/sys/dev/raid/speed_limit_min
• mdadm.conf 누락 → 재부팅 시 array 안 살아남
• spare 안 들어옴 → --add 후 --manage --add

실습 #17 — mdadm — RAID-5 구성 + 디스크 장애 → rebuild ⭐⭐⭐

실습 #18 — Pacemaker + Corosync — 2-node 클러스터 HA — 환경·시나리오 ⭐⭐⭐

🎨 이미지 프롬프트: "Editorial diagram on dark navy background — title 'Pacemaker + Corosync — 2-Node Cluster Lab' in white English at top, two server boxes connected by Corosync heartbeat: LEFT 'node1 · 192.168.56.21 · Online · Currently active for: VIP + nginx', RIGHT 'node2 · 192.168.56.22 · Online · Standby'; ABOVE both boxes a glowing cluster resource group 'Resource Group: web · VIP 192.168.56.100 + nginx systemd unit · current location: node1'; thin dashed teal lines labeled 'Corosync UDP 5405 · Heartbeat every 1s' between nodes; right side panel showing 'pcs status output: 2 nodes online · 2 resources running · web_vip Started node1 · web_nginx Started node1'; bottom strip 'Failover: shutdown node1 → resources migrate to node2 in < 30 seconds'; teal #00b894 and purple #6c5ce7 accents, technical cluster diagram, 16:9 — CRITICAL: All visible text MUST be in English only."

🎯 목적

• Pacemaker + Corosync 2-node HA 클러스터
• 리소스 단위 fail-over (VIP + nginx 묶음)
• pcs CLI 운영

🛠️ 도구

• pacemaker, corosync, pcs (apt install)
• 2 VM (node1, node2)
• nginx (리소스 대상)

💻 시나리오 (약 30분)

# === 양 노드 공통 ===
# 1) 설치
sudo apt install -y pacemaker corosync pcs nginx
sudo systemctl disable --now nginx   # Pacemaker가 관리

# 2) /etc/hosts (양쪽)
echo "192.168.56.21 node1" | sudo tee -a /etc/hosts
echo "192.168.56.22 node2" | sudo tee -a /etc/hosts

# 3) pcsd 사용자 (양쪽)
sudo passwd hacluster   # 'cluster' 입력
sudo systemctl enable --now pcsd

# === node1에서만 ===
# 4) 노드 인증
sudo pcs host auth node1 node2 -u hacluster

# 5) 클러스터 셋업
sudo pcs cluster setup lab-cluster node1 node2
sudo pcs cluster start --all
sudo pcs cluster enable --all

# 6) STONITH 비활성 (실습용; 운영은 펜싱 필수)
sudo pcs property set stonith-enabled=false

# 7) 리소스 등록 — VIP
sudo pcs resource create web_vip \
  ocf:heartbeat:IPaddr2 \
  ip=192.168.56.100 \
  cidr_netmask=24 \
  op monitor interval=10s

# 8) 리소스 — nginx
sudo pcs resource create web_nginx \
  systemd:nginx \
  op monitor interval=10s

# 9) 리소스 그룹 (같은 노드에 묶기)
sudo pcs resource group add web web_vip web_nginx

# 10) 상태
sudo pcs status

# === Fail-over 시연 ===
# 11) node1 종료
sudo pcs cluster stop node1
# node2에서 1~3초 후 리소스 이관

# (node2 에서)
sudo pcs status
# Started node2
ip addr show | grep 192.168.56.100   # VIP 부착
curl http://192.168.56.100           # nginx 응답

# 12) node1 복귀
sudo pcs cluster start node1
# 리소스 stickiness에 따라 자동 복귀 여부

# 13) 수동 이동
sudo pcs resource move web node1
sudo pcs resource clear web

실습 #18 — Pacemaker + Corosync — 2-node 클러스터 HA — 분석·해설 ⭐⭐⭐

🎨 이미지 프롬프트: "Editorial split-pane terminal mockup on dark navy background — TOP MAIN TITLE in English ONLY: 'Pacemaker pcs — Expected Output'; left pane (node1 before failover): '$ sudo pcs status · Cluster name: lab-cluster · Stack: corosync · Current DC: node1 (version 2.1.5) · 2 nodes configured · 2 resource instances configured · Online: [ node1 node2 ] · Full list of resources: · Resource Group: web · web_vip (ocf::heartbeat:IPaddr2): Started node1 · web_nginx (systemd:nginx): Started node1 · Daemon Status: · corosync: active/enabled · pacemaker: active/enabled · pcsd: active/enabled'; right pane (node2 after node1 shutdown): '$ sudo pcs status · ... · Online: [ node2 ] · OFFLINE: [ node1 ] · Resource Group: web · web_vip (ocf::heartbeat:IPaddr2): Started node2 · web_nginx (systemd:nginx): Started node2 · # resources migrated successfully · $ ip addr show eth0 · inet 192.168.56.22/24 · inet 192.168.56.100/24 # VIP migrated · $ curl http://192.168.56.100 ·

Lab HA Nginx on node2

'; teal #00b894 highlights for Started, monospace font, 16:9 — CRITICAL: All visible text MUST be in English only."

🔍 관전 포인트

1. Corosync = 통신, Pacemaker = 리소스 관리
2. stonith-enabled=false — 실습용만, 운영 절대 X (Split-brain)
3. resource group — VIP + nginx 같은 노드에 함께
4. op monitor — 헬스체크 간격
5. pcs resource move — 수동 이전

✅ 결론

• 2-node HA = "리소스가 살아있는 노드를 따라 다닌다"
• 운영은 3 노드 이상 (quorum) + STONITH 펜싱 필수
• systemd:nginx = 모든 systemd unit을 클러스터 리소스화 가능

🎙️ 강사 해설 (약 5분)

• Split-brain: 양쪽 노드가 서로 죽었다고 판단 → 동시에 master
• 펜싱 = "확실히 죽이기" (전원 차단, fence_ipmilan / fence_vmware)
• 3-node quorum = 다수결 (2/3 살아있으면 OK)
• 다음 실습 #19 Prometheus로 클러스터 메트릭 수집

🐞 자주 만나는 오류

• 인증 실패 → pcs host auth 다시
• Corosync Bind failed → bindnetaddr 양쪽 동일 LAN
• VIP 안 붙음 → 같은 서브넷 + 다른 노드 IP 사용 X
• pcs cluster start 실패 → journalctl -u corosync

실습 #18 — Pacemaker + Corosync — 2-node 클러스터 HA ⭐⭐⭐

실습 #19 — Prometheus + Grafana + Node Exporter — 관측성 스택 — 환경·시나리오 ⭐⭐⭐

🎨 이미지 프롬프트: "Editorial diagram on dark navy background — title 'Prometheus + Grafana — Observability Lab' in white English at top, four components in left-to-right flow: (1) 'Targets · Node Exporter :9100 · cAdvisor :8080 · App :8000/metrics' shown as 3 boxes; (2) 'Prometheus :9090 · scrape every 15s · TSDB local storage' shown as red flame logo + DB cylinder; (3) 'Grafana :3000 · dashboards · data source: Prometheus' shown as orange Grafana logo + dashboard tile grid; (4) 'Alertmanager :9093 · route → Slack/Email/PagerDuty' shown as alert icon with notification arrows; thin teal scrape arrows + PromQL query labels 'rate(node_cpu_seconds_total[5m])'; bottom strip 'Pull model — Prometheus pulls from /metrics endpoints · TSDB stores time-series'; teal #00b894 and purple #6c5ce7 accents, technical observability diagram, 16:9 — CRITICAL: All visible text MUST be in English only."

🎯 목적

• Prometheus 메트릭 수집 + PromQL
• Grafana 시각화 (대시보드)
• Alertmanager 알람 라우팅

🛠️ 도구

• Prometheus 2.55 (prometheus.io/download)
• Grafana 11 (grafana.com/grafana/download)
• Node Exporter (Prometheus 진영)

💻 시나리오 (약 25분)

# === Node Exporter ===
# 1) 다운로드 + systemd 등록
cd /tmp
wget https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz
tar xzf node_exporter-1.8.2.linux-amd64.tar.gz
sudo mv node_exporter-1.8.2.linux-amd64/node_exporter /usr/local/bin/

sudo tee /etc/systemd/system/node_exporter.service <<'EOF'
[Unit]
Description=Node Exporter
After=network.target

[Service]
ExecStart=/usr/local/bin/node_exporter
Restart=always

[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable --now node_exporter

# 검증
curl http://localhost:9100/metrics | grep node_cpu_seconds_total | head -3

# === Prometheus ===
# 2) 다운로드
cd /tmp
wget https://github.com/prometheus/prometheus/releases/download/v2.55.1/prometheus-2.55.1.linux-amd64.tar.gz
tar xzf prometheus-2.55.1.linux-amd64.tar.gz
cd prometheus-2.55.1.linux-amd64

# 3) prometheus.yml 수정
cat > prometheus.yml <<'EOF'
global:
  scrape_interval: 15s
scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']
  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9100']
EOF

# 4) 실행 (foreground)
./prometheus --config.file=prometheus.yml &

# 5) UI: http://localhost:9090
# Status → Targets → 모두 UP 확인

# 6) PromQL 쿼리
# rate(node_cpu_seconds_total{mode="user"}[5m])
# node_memory_MemAvailable_bytes / 1024 / 1024 / 1024
# 100 - (avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

# === Grafana ===
# 7) 설치 (apt repository)
sudo apt install -y software-properties-common
sudo wget -q -O /usr/share/keyrings/grafana.key https://apt.grafana.com/gpg.key
echo "deb [signed-by=/usr/share/keyrings/grafana.key] https://apt.grafana.com stable main" | \
  sudo tee /etc/apt/sources.list.d/grafana.list
sudo apt update && sudo apt install -y grafana
sudo systemctl enable --now grafana-server

# 8) http://localhost:3000 (admin/admin)
# Data sources → Add Prometheus → URL http://localhost:9090

# 9) Import dashboard 1860 (Node Exporter Full)
# Dashboards → New → Import → 1860 → Load → Prometheus 선택

# === Alertmanager (선택) ===
# 10) 알람 룰
# rules.yml: ALERT HighCpu IF rate(...) > 0.8 FOR 5m

실습 #19 — Prometheus + Grafana + Node Exporter — 관측성 스택 — 분석·해설 ⭐⭐⭐

🎨 이미지 프롬프트: "Editorial Grafana dashboard mockup on dark navy background — TOP MAIN TITLE in English ONLY: 'Grafana Node Exporter Full — Dashboard 1860'; full Grafana dashboard UI with dark theme, top navigation 'Home > Dashboards > Node Exporter Full · time range: Last 1 hour · refresh: 30s'; main panel grid with 6 time-series charts in 3×2 layout: ① 'CPU Busy' showing 8-core line chart 0~100% with current 42%, ② 'Sys Load 1m/5m/15m' showing 3 lines with values 0.42/0.58/0.61, ③ 'Memory Used' showing 5.2 GiB / 15.6 GiB pie + line, ④ 'Network Traffic' showing rx/tx bytes/sec dual line, ⑤ 'Disk I/O' showing read/write kB/sec, ⑥ 'Disk Space Used Percent' bar showing / 40% used; right side panel showing Prometheus query bar 'rate(node_cpu_seconds_total{mode!=\"idle\"}[5m])' with green '14 series' badge; bottom alert banner 'Active Alerts: 0 · Last evaluation: 12s ago'; teal #00b894 and purple #6c5ce7 accents, dashboard mockup style, 16:9 — CRITICAL: All visible text MUST be in English only."

🔍 관전 포인트

1. scrape_interval — 15s 표준 (해상도)
2. Pull model — Prometheus가 /metrics 풀
3. PromQL rate() vs irate() — 5분 평균 vs 순간
4. 메트릭 타입 — Counter / Gauge / Histogram
5. 대시보드 ID 1860 — 가장 유명한 Node Exporter Full

✅ 결론

• 관측성 = 메트릭 (Prometheus) + 로그 + Trace 3종
• Prometheus pull + ServiceDiscovery (K8s 환경)
• Grafana 1860 대시보드 = 사실상 표준

🎙️ 강사 해설 (약 5분)

• Pull vs Push: Pull은 Prometheus 표준, Push는 Pushgateway 별도
• TSDB 보관: 기본 15일, 길게 가져가려면 Thanos·Cortex·VictoriaMetrics
• AlertManager → Slack/Email/PagerDuty 라우팅
• 다음 실습 #20 Wazuh = 로그/이벤트 측면 보완

🐞 자주 만나는 오류

• Targets DOWN → 방화벽 (9100/9090)
• PromQL syntax → 공백·중괄호
• Grafana 데이터 없음 → 시간 범위 (오른쪽 위 Last 5min)
• prometheus.yml YAML 들여쓰기 (스페이스 2칸)

실습 #19 — Prometheus + Grafana + Node Exporter — 관측성 스택 ⭐⭐⭐

실습 #20 — Wazuh — SIEM + HIDS + EDR 통합 관제 — 환경·시나리오 ⭐⭐⭐

🎨 이미지 프롬프트: "Editorial diagram on dark navy background — title 'Wazuh — SIEM + HIDS + EDR Lab' in white English at top, three layers: TOP 'Wazuh Manager + Indexer + Dashboard (single VM)' shown as a unified server box with components; MIDDLE 'Wazuh Agent on endpoint VMs (enrolled)' shown as 3 small agent boxes connecting upward via TLS 1514; BOTTOM 'Data sources monitored: FIM (File Integrity) · Syscheck · Rootcheck · Vulnerability · MITRE ATT&CK · Auditd · Sysmon · OpenSCAP' shown as 8 small data-source tiles; right side panel showing 'Wazuh Dashboard URL: https://manager:443 · login: admin · default credentials in /opt/wazuh-install-files/wazuh-passwords.txt'; teal #00b894 and purple #6c5ce7 accents, technical SIEM architecture, 16:9 — CRITICAL: All visible text MUST be in English only."

🎯 목적

• SIEM + HIDS + EDR 통합 관제
• FIM (File Integrity) 변경 감지
• MITRE ATT&CK 매핑

🛠️ 도구

• Wazuh 4.7 (documentation.wazuh.com)
• Manager VM (4 vCPU / 8GB RAM 권장)
• Agent VM (별도)

💻 시나리오 (약 30분)

# === Wazuh Manager (All-in-One 설치) ===
# 1) Manager VM에서 (8GB RAM 권장)
curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh
sudo bash ./wazuh-install.sh -a
# (3분 정도 설치 — Indexer + Manager + Dashboard 통합)

# 2) 비밀번호 확인
sudo tar -axf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt -O
# admin 계정 비밀번호 기록

# 3) 대시보드 접속
# https://<manager-ip>:443  (admin / 위 비밀번호)

# === Wazuh Agent ===
# 4) Agent VM 에서 (별도 VM)
sudo curl -sO https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.7.5-1_amd64.deb

WAZUH_MANAGER=<manager-ip> sudo dpkg -i wazuh-agent_4.7.5-1_amd64.deb

sudo systemctl daemon-reload
sudo systemctl enable --now wazuh-agent

# 5) Manager에서 Agent 등록 확인
sudo /var/ossec/bin/manage_agents -l
# Agent 'agent-01' Status: Active

# === FIM 시연 ===
# 6) Agent에서 모니터링 대상 파일 변경
sudo bash -c "echo 'test' >> /etc/passwd"

# 7) Dashboard에서 Alert 확인 (1~2분 후)
# Security Events → level 7 'File integrity changed: /etc/passwd'

# 8) /etc/passwd 원복
sudo sed -i '$d' /etc/passwd

# === Rootkit 시뮬 ===
# 9) 의심 파일 생성
sudo touch /tmp/.suspicious
sudo chmod 4755 /tmp/.suspicious  # setuid

# 10) Rootcheck 실행 (수동)
sudo /var/ossec/bin/agent_control -R 000

# 11) Dashboard → Policy Monitoring → Rootcheck

# === MITRE ATT&CK 매핑 ===
# 12) Dashboard → Threat Hunting → MITRE ATT&CK
# Heatmap에서 tactic·technique 확인

# === Vulnerability Detector ===
# 13) Module 활성화
sudo nano /var/ossec/etc/ossec.conf
# <vulnerability-detector><enabled>yes</enabled>

sudo systemctl restart wazuh-manager

# Dashboard → Vulnerabilities → CVE 목록

실습 #20 — Wazuh — SIEM + HIDS + EDR 통합 관제 — 분석·해설 ⭐⭐⭐

🎨 이미지 프롬프트: "Editorial Wazuh dashboard mockup on dark navy background — TOP MAIN TITLE in English ONLY: 'Wazuh Dashboard — Security Events'; main panel grid: top header shows 'Wazuh v4.7 · Cluster Status: Active · Agents Total: 2 · Active: 2 · Disconnected: 0'; left sidebar with categories 'Security Events · Integrity Monitoring · Policy Monitoring · Auditing · Threat Hunting · Vulnerabilities · MITRE ATT&CK'; main view showing Security Events table with timestamp/agent/level/rule.id/description columns: '2026-05-31 14:22:08 · agent-01 · level 7 · 550 · File integrity changed: /etc/passwd', '2026-05-31 14:23:42 · agent-01 · level 5 · 5503 · PAM: User login failed (sshd)', '2026-05-31 14:25:17 · agent-02 · level 12 · 100002 · Rootkit detected (suspicious file in /tmp)'; right panel showing MITRE ATT&CK heatmap with highlighted tactics (Initial Access, Persistence, Defense Evasion) in red squares; bottom 'Top Tactics: T1059 PowerShell · T1547 Registry Run · T1027 Obfuscated Files'; teal #00b894 and red accents, dashboard mockup style, 16:9 — CRITICAL: All visible text MUST be in English only."

🔍 관전 포인트

1. Manager + Indexer + Dashboard 3종 통합 설치
2. Agent enroll = manager에 자동 등록
3. FIM rule (550) = 파일 무결성 변경
4. MITRE 매핑 = Wazuh rule → ATT&CK technique
5. Vulnerability Detector = OS 패키지 CVE 검색

✅ 결론

• Wazuh = OSSEC fork + 현대 UI + ELK 기반
• HIDS + SIEM + EDR 단일 솔루션
• 공공·중견기업 표준 OSS SIEM

🎙️ 강사 해설 (약 5분)

• Wazuh vs Splunk ES: Wazuh 무료 OSS, Splunk 상용 (라이센스 큼)
• Decoder + Rule = 로그 → Alert 변환
• API: https://manager:55000 (Bearer token)
• Suricata IDS 통합 → 네트워크 IDS 결합

🐞 자주 만나는 오류

• 8GB RAM 부족 → Indexer OOM (heap 2~4GB)
• Agent 미등록 → Manager 1514 포트 차단
• Dashboard 접속 X → 443 포트 + 자체 서명 인증서 (브라우저 예외)
• FIM rule 안 옴 → <directories realtime="yes">/etc</directories>

실습 #20 — Wazuh — SIEM + HIDS + EDR 통합 관제 ⭐⭐⭐

Session 20 — 학습 정리 + 다음 단계