리눅스 위기 관리 도구

 (brendangregg.com)
2P by GN⁺ | ★ favorite | 댓글 1개
  • 성능 장애가 난 뒤 진단 도구를 설치하기 시작하면 복구보다 준비 작업에 시간이 새므로, 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
  • 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 배포판이 이런 위기 관리 도구를 기본 포함하면, 크고 작은 회사가 성능 장애 발생 시 바로 진단을 시작할 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이 목록은 유용함. apt 저장소 해석 실패처럼 서버 자체가 꼬인 상황에서는 클라우드가 잘 맞을 때가 많음
    고치려고 붙잡고 있기보다 머신을 죽이거나 풀에서 빼고 새 머신을 띄우면, 새 머신과 앱이 깨끗하게 올라와 장애가 끝남. 문제 머신은 핫패스 밖에서 따로 파보면 됨

    • 문제를 “해결”한 뒤에는 아무도 그 머신을 파볼 시간이 없거나 허락하지 않아서, 시간이 지나면 처음부터 재빌드 방식이 실제 문제 해결 능력과 축적된 지식을 잃게 만듦
      물리 세계의 “부품 교체만 하는 사람”과 같은 소프트웨어 버전이 됨
    • “4:10pm 새 머신에서도 같은 성능 문제가 계속됨”
    • 그건 꼭 클라우드만의 장점이라기보다, 가상화된 교체 가능한 서버(cattle) 운영의 장점에 가까움
    • 머신을 죽이면 증거까지 사라질 수 있음. 외부에 모든 로그가 남아 있을 수도 있지만, 보통은 뭔가 빠져 있음

  • 모든 서버가 컨테이너화된 건 아니지만, 상당수는 컨테이너이고 그 자체의 어려움이 있음
    Docker 이미지 안의 디버깅 도구들은 자동 보안 스캐너에서 “공격자가 시스템 동작을 관찰·수정하는 데 도움 되는 불필요한 도구”로 잡히는 경우가 많음. gdb처럼 타당한 우려도 있지만 아닌 것도 많음
    그래서 일부 도구는 별도 볼륨에, 가능하면 정적 바이너리로 두거나 마운트 경로를 설치 접두사로 컴파일·설치함. 디버깅이 필요하면 운영팀에 읽기 전용으로 임시 마운트해 달라고 요청함
    또 어떤 디버그 도구가 특정 커널 기능 활성화를 요구하면, 같은 호스트의 다른 컨테이너에 어떤 영향을 주는지 질문과 우려가 자주 생김

    • 공격자가 파일시스템에서 파일을 실행할 수 있고, 실행에 부족한 게 그 파일이 존재하는 것뿐이라면 그냥 직접 파일을 써넣으면 되지 않나 싶음
      이 정책이 의미 있는 시나리오는 “조직이 보안 스캐너를 잘못 쓰고 있다” 말고는 잘 모르겠음
    • 더 나은 방법은 디버그 도구와 root 사용자를 포함한 두 번째 이미지를 만들고, 프로덕션 컨테이너의 PID 네임스페이스와 네트워크 네임스페이스에 붙여 실행하는 것임
      디버거를 쓰려면 SYS_PTRACE 권한, 사용자 0, --privileged 같은 플래그가 많이 필요하니, 두 번째 컨테이너를 띄우는 게 보통 더 낫다
      이 방식이면 프로덕션 컨테이너를 재시작하지 않아도 되어 재현 증거를 잃을 가능성도 줄어듦
      다만 장애 상황에서 이 절차를 기억하기는 쉽지 않으니, 미리 해보고 런북에 단계별로 적어둬야 함

  • 관련해서 FreeBSD 5.2, 즉 2004년부터 모든 FreeBSD 시스템에는 /rescue/*가 있음
    약 150개의 핵심 도구를 하나로 묶은 정적 링크 바이너리 하나가 보통 이름으로 하드링크되어 있고, 크기는 약 17MB임
    https://man.freebsd.org/cgi/man.cgi?rescue
    https://github.com/freebsd/freebsd-src/blob/main/rescue/resc...

    • 15년 동안 그걸 쓸 일은 없었음. 최근 4~5년 동안은 정신 건강을 위해 가능한 것들을 *BSD로 포팅해 왔음

  • Netflix에 있을 때 Brendan과 그의 팀이 bpftrace, bcc, 정상 동작하는 perf 같은 디버깅 도구를 곳곳에 설치해 두도록 해줬음
    여러 번 목숨을 살려준 도구들이었음

  • 그 목록에 strace가 없어서 놀랐음. 보통 가장 먼저 집는 도구 중 하나임
    특히 프로그램이 쓸모없거나 틀린 오류 메시지를 반환할 때 strace 가 정말 유용함

  • SRE류 직무 면접에서는 항상 이런 도구들을 다룸
    후보자가 특정 명령을 얼마나 외우는지가 핵심은 아니고, 새 도구를 알려주면 인상적이긴 하지만, 무엇이 가능한지와 어떤 도구가 있는지, 어떻게 쓰는지를 봄
    네트워크 트래픽, 시스템 호출, 실행 프로파일을 캡처·분석하고 운영체제와 하드웨어 상태를 살펴볼 수 있다는 감각이 중요함

  • 이런 위기 상황에서 도구 설치가 불가능하다면, Docker로 여러 유틸리티를 실행할 수 있음
    예를 들어 컨테이너를 한 줄로 빌드하거나, 호스트 네트워크에 붙여 netstat류 도구를 실행하거나, /proc을 마운트하고 --privileged, --net host, --pid host로 iostat, sar, vmstat, mpstat, pidstat 같은 시스템 도구를 돌릴 수 있음
    물론 yum install이 더 낫지만, Docker를 쓸 수 있고 필요한 매핑을 감당할 수 있다면 대안이 됨. rootless나 Podman 구성에서는 아마 잘 안 될 것 같음

    • apt가 패키지를 내려받고 설치하지 못하는데 Docker는 새 컨테이너를 가져올 수 있는 상황이 있나?
      apt 라이브러리가 망가졌다든가 그런 경우일까?
    • 망분리 상황이면 예외임. “Ubuntu” 이미지를 당겨오려면 행운을 빌어야 함
    • 그런 맥락에서 busybox에 이런 도구들이 더 많이 들어 있으면 좋겠음
      서버에 업로드해서 바로 실행할 수 있는 1MB쯤 되는 파일이 있으면 매우 도움이 됨

  • 다들 root 접근권한을 받는 건가? 나는 뭘 하든 시스템 관리자 티켓을 올려야 함

    • 지금은 컨설턴트라 몇 달마다 새 회사에 감. 항상 잘 지내야 하는 사람들이 있음
      보안 담당자, 건물 출입을 시켜주는 어색한 재킷 차림의 사람들 이름을 외워두고 Starbucks 카드도 챙기면 좋음
      청소 담당자에게도 예의 바르게 대하고 이름을 외우면 내 자리가 깨끗해짐. 가끔 늦게 남아 이 사람들을 알아가는 것도 가치 있음
      회계팀에도 친구를 만들면 좋음. 커피 마시고 점심 먹고 일 말고도 얘기하며 관심을 보이면, 적절한 사람들은 정리해고가 오거나 회사 돈이 풀릴 때 알려줌
      IT, 즉 노트북을 나눠주고 이메일을 관리하는 사람들에게도 잘해야 함. 내 컴퓨터에서 헛소리 보안 도구를 얼마나 빨리 걷어내 주는지, 업그레이드 줄에서 얼마나 앞서게 되는지 보게 됨
      가장 중요한 건 시스템 관리자임. root 때문만이 아니라, 좋은 시스템 관리자는 코딩할 줄 알지만 절대 크게 말하지 않기 때문임. 좋은 관리자는 어디 어두운 구석에 시체가 있는지, 그게 벽장 하나인지 공동묘지인지 알려줌. 그들의 플랫폼에 맞춰 빌드하는 법을 배우면 훨씬 많은 재량을 얻음. 이들이 부탁을 하면 들어줘야 함
    • 예전에는 IT 운영을 맡았고, 여기서는 시스템·SRE·보안을 의미함
      이 글은 IT가 제공한 인프라에서 앱을 운영하는 사람들을 향한 것임. 예시처럼 상호작용해야 한다면 그건 기술 문제가 아니라 조직 차원의 실패임
      우리는 매우 명확하고 신뢰 가능한 소통 라인을 두었고, 사람들은 채팅이 아니라 전화, 요즘이라면 Teams 같은 곳에서 개발·운영·보안·컴플라이언스와 함께 움직였음
      실제로는 모든 팀에 최소한 연락 담당자가 있었고, 보통 개발자가 운영팀이 제공한 리소스 위에서 앱을 돌렸음. 컴플라이언스가 구성을 승인했고, 서비스 신뢰성은 개발 업무였음. 이런 의미로 DevOps를 하면 많은 문제가 사라짐

  • nmap, netstat, nc가 보이지 않음. 이 도구들도 여러 번 살려줬음

  • 하나만 추가한다면 nmap 임
    네트워크 연결 문제는 어떤 앱에서는 항상 명확하게 드러나지 않음

    • screen, tmux, byobu, pv, rsync, 그리고 물론 vim도 필요함
답변달기
GeekNews BeeBS 게시판 오픈! 자유로운 이야기와 소소한 일상을 함께 나눠보세요.