- 성능 장애가 난 뒤 진단 도구를 설치하기 시작하면 복구보다 준비 작업에 시간이 새므로, Linux 서버 이미지에 위기 관리 도구를 미리 넣어야 함
- 권장 목록은 procps, util-linux, sysstat, iproute2, tcpdump, perf, bcc/bpftrace, trace-cmd, ethtool 등이며 CPU·디스크·네트워크·커널 추적을 바로 확인하기 위한 최소 패키지임
- bcc와 bpftrace는 겹치는 도구가 많지만, bcc는 CLI 옵션이 풍부하고 bpftrace는 현장에서 편집하기 쉬우며 실행 시에는 같은 BPF 바이트코드를 내보냄
- 장애 중 설치는 느린 SSH, 깨진 apt 설정, 저장소 차단, 방화벽, 불변 파일시스템, 권한 오류 같은 변수 때문에 몇십 분 손실로 이어질 수 있음
- 비용은 주로 디스크 용량과 이미지 배포 시간이지만 권장 패키지는 대부분 작아, 엔터프라이즈 Linux 배포판에 기본 포함하면 성능 장애 대응을 더 빨리 시작할 수 있음
장애 전에 갖춰둘 최소 도구
- 성능 장애가 발생하면 원인 진단에 필요한 도구를 설치하는 시간 자체가 손실이 되므로, Linux 서버에는 위기 관리 도구를 기본 설치해 두는 편이 안전함
- 목록은 Systems Performance 2nd Edition의 “Linux Crisis Tools” 표를 기반으로 함
- Ubuntu 패키지 기준 권장 도구는 다음과 같음
procps:ps,vmstat,uptime,top- 기본 통계 확인
util-linux:dmesg,lsblk,lscpu- 시스템 로그와 장치 정보 확인
sysstat:iostat,mpstat,pidstat,sar- 장치와 시스템 통계 확인
iproute2:ip,ss,nstat,tc- 선호되는 네트워크 도구
numactl:numastat- NUMA 통계 확인
tcpdump:tcpdump- 네트워크 스니핑
linux-tools-common,linux-tools-$(uname -r):perf,turbostat- 프로파일러와 PMU 통계 확인
bpfcc-tools또는 bcc:opensnoop,execsnoop,runqlat,softirqs,hardirqs,ext4slower,ext4dist,biotop,biosnoop,biolatency,tcptop,tcplife,trace,argdist,funccount,profile등- 미리 만들어진 eBPF 도구
bpftrace:bpftrace, 기본 버전의opensnoop,execsnoop,runqlat,biosnoop등- eBPF 스크립팅
trace-cmd:trace-cmd- Ftrace CLI
nicstat:nicstat- 네트워크 장치 통계
ethtool:ethtool- 네트워크 장치 정보
tiptop:tiptop- PMU/PMC top
cpuid:cpuid- CPU 세부 정보
msr-tools:rdmsr,wrmsr- CPU 세부 조사
bcc와 bpftrace를 함께 보는 법
- bcc와 bpftrace는 겹치는 도구가 많지만 쓰기 좋은 지점이 다름
- bcc 도구는 CLI 옵션 같은 기능이 더 많아 완성된 도구처럼 쓰기 좋음
- bpftrace 도구는 현장에서 즉시 편집할 수 있어 상황에 맞춘 확인이 쉬움
- 둘 중 하나가 더 빠르다는 뜻은 아님
- 두 도구는 같은 BPF 바이트코드를 내보냄
- 실행 중에는 동일하게 빠름
- bcc는 Python 기반 도구를 libbpf C로 옮기는 방향으로 진화 중임
- CO-RE와 BTF를 사용함
- 아직 패키지는 재작업되지 않았음
- 앞으로
bpfcc-tools는 도구 바이너리만 담은 더 작은libbpf-tools패키지로 대체되어야 함
서버 유형에 따라 더 필요한 도구
- 위 목록은 어디까지나 최소 목록임
- 가속기가 있는 서버라면 해당 장비를 분석할 도구도 함께 들어가야 함
- Intel GPU 서버:
intel-gpu-tools - NVIDIA 서버:
nvidia-smi
- Intel GPU 서버:
gdb같은 디버깅 도구도 위기 상황에서 바로 쓰려면 미리 설치해 둘 수 있음- 필수 분석 도구는 자주 바뀌지 않으므로, 이 목록은 몇 년에 한 번 정도만 갱신해도 될 수 있음
기본 설치의 실제 비용
- 패키지를 추가할 때 가장 먼저 드러나는 단점은 디스크 사용량임
- 클라우드 인스턴스에서는 기본 서버 이미지에 몇 MB만 늘어도 인스턴스 배포 시간이 몇 초 또는 몇 분의 1초 증가할 수 있음
- 권장 패키지는 대부분 작고 bcc도 더 작아질 예정이라, 용량과 시간 비용은 크지 않아야 함
- debuginfo는 총량이 약 1GB에 달해 기본 포함을 막는 용량 우려가 실제로 있었음
장애 중 설치가 막히는 흐름
- 장애가 난 뒤 도구를 설치하려 하면 진단보다 설치 문제 해결에 시간이 빨려 들어갈 수 있음
- 예시 흐름은 다음과 같음
- 4:00pm: 회사 사이트가 다운되거나 너무 느려서 사용할 수 없는 상태가 됨
- 4:01pm: 모니터링 대시보드에서 백엔드 서버 그룹이 비정상이고, 높은 디스크 I/O가 의심됨
- 4:02pm: 서버에 SSH로 접속하려 하지만 로그인이 매우 느림
- 4:03pm:
iostat -xz 1을 실행하려 하지만iostat이 없고,sysstat설치 안내가 나옴 - 4:07pm: 패키지 설치가 저장소를 해석하지 못해 실패하고,
/etc/apt설정 문제가 드러남 - 4:10pm: 수정한 설정으로
apt-get update를 실행해야 하지만 매우 느림 - 4:13pm: 연결 시간 초과가 발생하고, 저장소 연결 또는 성능 문제를 의심하게 됨
- 4:17pm: 네트워크 보안팀이 예기치 않은 트래픽과 HTTP/HTTPS/FTP outbound apt 요청을 차단했다는 사실이 확인됨
- 4:20pm: 방화벽을 비활성화한 뒤
apt-get update는 되지만, 설치에서 권한 오류가 발생함 - 4:24pm: 플랫폼 보안팀이 실행 바이너리 영역 등 일부 파일시스템 쓰기가 차단된 불변 시스템이라고 설명함
- 4:27pm: SRE 팀이 대규모 장애를 알리고 경영진은 상태 업데이트와 복구 ETA를 요구하지만, 실제 진단은 거의 진행되지 못함
- 4:30pm:
cat /proc/diskstats로 조잡한iostat대체를 시도하지만, Linux 문서를 읽어야 하고 디스크가 바쁘다는 기존 사실만 확인함 - 4:55pm: 쓰기 가능한 파일시스템을 갖춘 새 서버 이미지가 뜨고
sysstat설치가 가능해졌지만, 서버 재시작으로 사이트가 돌아왔을 뿐 원인은 고쳐지지 않음 - 12:50am: 방화벽과 파일시스템 보안을 꺼 둔 영향으로 사이트가 해킹되는 상황이 예시로 이어짐
- 12:50am 사건은 실제 경험이 아니지만, 나머지는 실제 경험을 바탕으로 한 예시임
- 이전 직장에서는 약 15분 시점에 “traffic team”이 클라우드 리전 장애조치를 시작하는 경우가 있었고,
iostat설치가 끝났을 때는 대상 시스템이 이미 유휴 상태가 될 수 있었음
기본 이미지에 넣어야 하는 이유
- 위 시나리오는 프로덕션 장애 중에 도구를 나중에 설치하는 방식이 얼마나 취약한지 보여줌
- 일부 회사는 이미 OS 팀이 필요한 도구를 포함한 커스텀 서버 이미지를 만들어 사용함
- 여전히 기본 Linux 버전을 그대로 운영하는 사이트도 많고, 이런 경우 장애를 겪고 나서야 필요성을 깨닫게 됨
- 엔터프라이즈 Linux 배포판이 이런 위기 관리 도구를 기본 포함하면, 크고 작은 회사가 성능 장애 발생 시 바로 진단을 시작할 수 있음