13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[태그:] 서버실

  • [HomeLabs] 홈서버 구축: 저전력 미니PC로 Proxmox VE 설치 및 최적화 가이드

    [HomeLabs] 홈서버 구축: 저전력 미니PC로 Proxmox VE 설치 및 최적화 가이드

    목차

    안녕하세요, 13년차 서버실 지킴이입니다. 🤓

    오늘은 많은 분들이 꿈꾸는 홈서버 구축, 그 중에서도 저전력 미니PC를 활용해 Proxmox VE 설치 및 최적화하는 과정을 제 경험을 바탕으로 솔직하게 풀어보려고 해요. 사실 저도 처음 홈랩을 꾸릴 때는 어떤 하드웨어로 시작해야 할지, 어떤 OS를 써야 할지 막막했거든요. 큰 서버랙을 들여놓는 건 공간도 전기세도 부담스럽고, 그렇다고 라즈베리 파이 같은 SBC(Single Board Computer)는 성능이 아쉽고요. 그래서 제가 찾아낸 답이 바로 이 미니PC 홈서버 구축이더라고요. 작지만 강한 녀석으로 Proxmox VE를 돌려보니, 정말 만족스럽더라고요. 혹시 저처럼 홈서버를 꿈꾸지만 시작이 두려우셨다면, 이 글이 좋은 가이드가 될 겁니다!

    홈랩의 심장, 미니PC 기반 Proxmox VE 아키텍처. 작지만 여러 서비스를 안정적으로 운영할 수 있는 구조를 보여줍니다.

    Proxmox VE, 너는 누구냐? (핵심 개념 파헤치기)

    자, 본격적인 이야기에 앞서 Proxmox VE (Virtual Environment)가 뭔지 간단하게 짚고 넘어갈게요. 쉽게 말해, Proxmox VE는 오픈소스 가상화 플랫폼이거든요. 서버 한 대에 여러 개의 운영체제(OS)를 동시에 돌릴 수 있게 해주는 마법 같은 녀석이죠. VMware ESXi나 Microsoft Hyper-V와 비슷한 역할을 한다고 보시면 됩니다. Proxmox VE는 크게 두 가지 방식으로 가상화를 제공해요.

    • KVM (Kernel-based Virtual Machine): 완전한 가상 머신(VM)을 생성합니다. Windows, Ubuntu Server 등 다양한 OS를 게스트로 설치할 수 있거든요. 각각의 VM은 독립적인 하드웨어 자원을 할당받아 마치 별도의 물리 서버처럼 동작합니다.
    • LXC (Linux Containers): 리눅스 컨테이너 기술로, VM보다 훨씬 가볍고 빠르게 컨테이너를 생성할 수 있어요. 호스트 OS의 커널을 공유하기 때문에 오버헤드가 적고, 특정 리눅스 배포판 기반의 서비스들을 올리기에 정말 좋습니다. Docker와는 또 다른 개념인데, 여기서는 ‘가벼운 가상화’ 정도로 이해하셔도 충분해요.

    제가 Proxmox VE를 좋아하는 이유 중 하나는 바로 웹 기반 UI(User Interface)가 아주 직관적이라는 점이거든요. 터미널 명령어에 익숙하지 않은 분들도 쉽게 VM을 만들고 관리할 수 있어요. 게다가 오픈소스라 무료로 사용할 수 있다는 점! 홈랩 구축에 이보다 더 좋은 선택지가 있을까 싶네요.

    💡 저전력 미니PC로 홈서버 구축, 이렇게 좋습니다

    저는 홈랩을 운영하면서 가장 중요하게 생각하는 게 전력 효율과 소음입니다. 24시간 켜두는 서버인데 전기세 폭탄 맞으면 안 되잖아요? 그리고 침실 옆에 두는데 웅웅거리는 소리가 나면 스트레스고요. 그런 면에서 저전력 미니PC는 정말 최고의 선택이라고 생각해요.

    • 저전력 (Low Power Consumption): 보통 CPU TDP(Thermal Design Power)가 10W ~ 25W 수준이라 전기 요금 부담이 적습니다. N100, N305 같은 인텔 저전력 프로세서들이 요즘 아주 잘 나와요.
    • 저소음 (Low Noise): 대부분 팬리스(Fanless) 디자인이거나 아주 작은 팬이 달려 있어 조용합니다.
    • 작은 크기 (Compact Size): 책상 위나 선반 어디든 부담 없이 둘 수 있습니다.
    • 적당한 성능 (Decent Performance): 홈서버 용도로는 충분한 컴퓨팅 파워를 제공합니다. 여러 개의 VM이나 LXC를 동시에 돌려도 크게 버벅이지 않더라고요.

    제가 직접 써보니, 미니PC 홈서버 구축은 처음 시작하는 분들에게 정말 좋은 진입점이 되더라고요. 투자 비용도 그리 크지 않고요.

    🛠️ 실전! Proxmox VE 설치 및 초기 설정 가이드

    자, 이제 제 미니PC에 Proxmox VE를 설치했던 과정을 단계별로 공유해 드릴게요. 따라만 오시면 됩니다!

    1. Proxmox VE 설치 미디어 만들기

    먼저 Proxmox VE ISO 파일을 다운로드해야겠죠? Proxmox 공식 웹사이트에서 최신 버전을 다운로드하세요. 저는 보통 안정적인 버전이 나오면 바로 업데이트하는 편입니다. 다운로드받은 ISO 파일은 Rufus나 balenaEtcher 같은 툴을 이용해서 USB 드라이브에 구워줍니다. 8GB 이상의 USB 메모리면 충분해요. 저는 Rufus를 주로 쓰는데, 과정이 워낙 직관적이라 실패한 적이 없네요.

    # Rufus 또는 balenaEtcher를 사용하여 ISO를 USB에 굽기
# (GUI 툴이므로 명령어는 별도로 없습니다.)
# balenaEtcher 설치 예시 (Linux)
# sudo apt update
# sudo apt install curl
# curl -L https://etcher.balena.io/etcher/deb/balena-etcher_latest_amd64.deb -o balena-etcher_latest_amd64.deb
# sudo dpkg -i balena-etcher_latest_amd64.deb

    2. 미니PC BIOS 설정 및 부팅

    USB 설치 미디어를 미니PC에 꽂고 전원을 켜세요. 그리고 BIOS(Basic Input/Output System) 또는 UEFI 설정으로 진입해야 합니다. 보통 부팅 시 Delete, F2, F10, F12 키를 연타하면 진입할 수 있어요. 미니PC 제조사마다 다르니 사전에 확인해 보세요.

    BIOS 설정에서 다음을 확인하고 변경해 주세요:

    • 부팅 순서 (Boot Order): USB 드라이브가 첫 번째로 부팅되도록 설정합니다.
    • 가상화 기술 활성화 (Virtualization Technology): Intel VT-x 또는 AMD-V 기능이 활성화되어 있는지 확인합니다. 이게 꺼져 있으면 Proxmox VE가 제대로 동작하지 않아요!
    • 내장 LAN 카드 설정: 필요한 경우 Enable로 설정.

    설정을 저장하고 재부팅하면 USB로 부팅되어 Proxmox VE 설치 화면이 나타날 겁니다. 🎉

    Proxmox VE 설치의 핵심 단계, OS를 설치할 디스크를 선택하는 화면입니다. 여기서 실수가 없어야 해요!

    3. Proxmox VE 설치 과정 진행

    이제 화면의 지시에 따라 설치를 진행하면 됩니다. 몇 가지 중요한 단계들을 짚어드릴게요.

    1. 설치 디스크 선택: Proxmox VE를 설치할 디스크를 선택합니다. 저는 보통 NVMe SSD를 OS용으로 사용하고, 추가 스토리지는 나중에 붙여서 쓰는 편이에요. 중요한 데이터가 없는 디스크를 선택해야 합니다!
    2. 국가 및 시간대 설정: 대한민국(South Korea), 서울(Seoul)로 설정합니다.
    3. 관리자 비밀번호 설정: Proxmox VE 웹 UI에 접속할 root 계정의 비밀번호를 설정합니다. 강력한 비밀번호는 필수!
    4. 네트워크 설정: hostname, IP Address, Netmask, Gateway, DNS Server를 설정합니다. 저는 보통 DHCP로 할당받은 후, 라우터에서 해당 MAC 주소에 고정 IP를 할당해주는 방식으로 사용합니다. 처음부터 고정 IP를 설정해도 좋고요.

    이후 설치가 시작되고, 미니PC의 성능에 따라 10~20분 정도 소요될 겁니다. 설치가 완료되면 USB를 제거하고 재부팅하세요.

    4. 설치 후 초기 설정 (네트워크 본딩 및 저장소 추가)

    재부팅 후 웹 브라우저를 열고, 설정했던 IP 주소로 접속합니다. (예: https://[설정했던 IP]:8006) 로그인 후 Proxmox VE 대시보드가 보이면 성공입니다! 이제 몇 가지 초기 최적화를 해볼까요?

    네트워크 본딩 (Network Bonding)

    제 미니PC는 LAN 포트가 두 개더라고요. 이럴 때 네트워크 본딩(Network Bonding)을 사용하면 대역폭을 늘리거나, 한쪽 포트에 문제가 생겼을 때 다른 포트로 자동 전환되는 고가용성(High Availability)을 확보할 수 있습니다. 저는 주로 balance-xor 모드를 선호합니다. 설정은 [노드] > System > Network에서 할 수 있어요.

    # Proxmox VE 웹 UI에서 설정하는 것이 일반적이지만,
# CLI로 설정할 경우 /etc/network/interfaces 파일 수정
# (예시 - bonding mode 2 (balance-xor))
auto bond0
iface bond0 inet static
        address 192.168.1.100/24
        gateway 192.168.1.1
        slaves enp1s0 enp2s0 # 실제 NIC 이름으로 변경
        bond_miimon 100
        bond_mode balance-xor
        bond_xmit_hash_policy layer2+3
# 변경 후 적용
# systemctl restart networking

    저장소 추가 (Storage Configuration)

    VM이나 LXC를 위한 추가 저장소가 필요하겠죠? 저는 보통 SATA SSD나 HDD를 추가해서 사용합니다. [노드] > Datacenter > Storage > Add에서 Directory나 LVM, ZFS 등을 선택해서 추가할 수 있어요. 저는 간편하게 Directory로 설정하고, 나중에 TrueNAS 같은 NAS 솔루션을 VM으로 올려서 NFS/SMB로 마운트하는 방식도 즐겨 사용합니다.

    # 새 디스크 파티션 및 포맷 (예시: /dev/sdb)
# fdisk /dev/sdb # 파티션 생성
# mkfs.ext4 /dev/sdb1 # 파일 시스템 포맷
# mkdir /mnt/data # 마운트 포인트 생성
# mount /dev/sdb1 /mnt/data # 마운트
# echo "/dev/sdb1 /mnt/data ext4 defaults 0 2" >> /etc/fstab # 재부팅 시 자동 마운트 설정
# Proxmox VE 웹 UI에서 "Directory" 타입으로 /mnt/data 추가

    ⚠️ 삽질 경험: Proxmox VE 설치 후 네트워크 문제 해결

    제가 겪었던 흔한 문제 중 하나는 바로 네트워크 드라이버 문제였어요. 특정 미니PC에 들어있는 Realtek NIC (Network Interface Card) 드라이버가 Proxmox VE 기본 커널에 포함되지 않아 설치 후 네트워크가 먹통이 되는 경우가 있더라고요. 처음엔 ‘아, 망했다!’ 싶었죠. 😅

    해결 방법은 다음과 같았거든요:

    1. 설치 중 네트워크 설정 스킵: 일단 네트워크 설정 없이 설치를 완료합니다.
    2. USB 테더링 또는 임시 유선 연결: 스마트폰 USB 테더링 등으로 임시 인터넷 연결을 확보하거나, 다른 NIC이 있는 경우 그쪽으로 연결합니다.
    3. 필요한 드라이버 수동 설치: Proxmox VE는 Debian 기반이므로, Realtek 공식 웹사이트에서 해당 NIC의 Linux 드라이버를 다운로드하여 컴파일 후 설치합니다. (dkms 패키지를 이용하면 커널 업데이트 시에도 드라이버가 유지되어 편리합니다.)
    # Realtek 드라이버 설치 예시 (r8168 드라이버)
# apt update && apt install pve-headers-$(uname -r) build-essential dkms
# wget https://www.realtek.com/Downloads/Upload/r8168-dkms_8.049.02-1_all.deb # 최신 버전 확인 후 다운로드
# dpkg -i r8168-dkms_8.049.02-1_all.deb
# modprobe -r r8169 # 기존 드라이버 언로드 (필요시)
# modprobe r8168 # 새 드라이버 로드
# systemctl restart networking # 네트워크 서비스 재시작

    이 과정을 거치고 나니 드디어 네트워크가 잡히고 웹 UI에 접속할 수 있더라고요. 이런 삽질 경험이 쌓여서 문제 해결 능력이 늘어나는 것 같습니다. ㅎㅎ

    Proxmox VE 웹 대시보드에서 시스템 자원 사용량을 한눈에 확인하는 모습. 제가 구축한 홈서버가 얼마나 효율적으로 작동하는지 보여줍니다.

    ✅ 결과 확인 및 자원 모니터링

    모든 설정이 끝나면 Proxmox VE 웹 UI에서 모든 것을 관리할 수 있습니다. Datacenter 레벨에서 전체 자원 사용량을 확인하고, 각 Node(미니PC)를 클릭하면 해당 노드의 CPU, 메모리, 디스크 I/O, 네트워크 트래픽 등의 상세 정보를 그래프로 볼 수 있어요. 제가 직접 VM과 LXC를 몇 개 생성해서 돌려봤는데, N100 기반 미니PC도 홈서버 용도로는 충분히 쾌적한 성능을 보여주더라고요. Plex Media Server, Home Assistant, AdGuard Home 등을 동시에 돌려도 CPU 사용률은 20%를 넘지 않았어요. 💡

    Proxmox VE vs. 다른 가상화 솔루션 비교

    구분 Proxmox VE VMware ESXi (무료 버전) Docker (Standalone)
    가상화 방식 KVM (VM), LXC (컨테이너) VM (하이퍼바이저) 컨테이너 (OS 위에서 실행)
    설치 용이성 쉬움 (전용 ISO) 보통 (전용 ISO) 설치된 OS 위에 설치
    웹 UI 지원 ✅ 매우 강력 ✅ 강력 (vSphere Client) ❌ (Portainer 등 추가 설치)
    오픈소스 여부 ✅ 완전 오픈소스 ❌ (제한적 무료) ✅ 핵심은 오픈소스
    HA/클러스터링 ✅ 기본 지원 ❌ (유료 버전) ❌ (Kubernetes 등 필요)
    권장 사용처 종합적인 홈서버, 랩 환경 VM 중심의 안정적인 환경 단일 애플리케이션 컨테이너

    미니PC와 Proxmox VE 조합의 시너지 효과를 한눈에 볼 수 있는 요약 인포그래픽입니다.

    마무리하며: 저전력 홈서버의 무한한 가능성!

    이렇게 저전력 미니PC로 Proxmox VE를 설치하고 초기 최적화하는 과정을 쭉 살펴봤습니다. 처음에는 조금 어렵게 느껴질 수도 있지만, 한 번 구축해두면 정말 무궁무진한 활용이 가능하거든요. 개인 NAS, 웹 서버, 미디어 서버(Plex), 스마트 홈 허브(Home Assistant), 광고 차단 서버(AdGuard Home) 등 원하는 모든 서비스를 VM이나 LXC 컨테이너로 올려서 사용할 수 있어요. 저는 이 조합으로 벌써 3년 넘게 안정적으로 홈랩을 운영하고 있는데, 전기세도 부담 없고, 성능도 만족스러워서 정말 후회 없는 선택이었어요.

    여러분도 이 가이드를 통해 자신만의 멋진 홈랩 구축에 성공하시길 바랍니다! 다음 글에서는 이 Proxmox VE 위에 Docker를 올리고 다양한 서비스를 컨테이너로 배포하는 방법에 대해 자세히 다뤄볼 예정입니다. 궁금한 점이 있다면 언제든지 댓글로 남겨주세요. 제가 아는 선에서 최대한 도와드리겠습니다! 😉

  • [NAS] Synology DSM 7.x 최신 업데이트: 주요 변경점 및 안정적 업데이트 가이드

    [NAS] Synology DSM 7.x 최신 업데이트: 주요 변경점 및 안정적 업데이트 가이드

    목차

    안녕하세요, 13년차의 서버실입니다! 오늘은 많은 분들이 궁금해하시고, 또 한편으로는 살짝 두려워하는 Synology NAS의 DSM(DiskStation Manager) 7.x 버전 업데이트 이야기를 해보려고 합니다. 저도 처음 DSM 7.0이 나왔을 때부터 지금까지 여러 번의 업데이트를 거치면서 정말 많은 삽질을 했거든요. 특히 DSM 6.x에서 7.x로 넘어갈 때의 변화는 정말 컸죠!

    제 홈랩에서도 Synology NAS는 핵심 중의 핵심이라, 항상 최신 상태를 유지하려고 노력합니다. 이번 DSM 7.x 업데이트는 단순한 기능 추가만이 아니라 사용자 경험(UX)과 보안, 그리고 시스템 내부 구조까지 많은 부분이 개선되었어요. 특히 지금은 DSM 7.2가 안정화되어 많은 분들이 사용하고 계실 텐데요. 과연 어떤 점들이 바뀌었고, 업데이트는 어떻게 해야 안정적으로 할 수 있는지, 제 경험을 바탕으로 자세히 알려드릴게요!

    DSM 7.x, 무엇이 달라졌을까요? (핵심 변경점)

    솔직히 DSM 6.x에서 7.x로 넘어올 때 처음엔 “이게 뭔가” 싶을 정도로 UI가 확 바뀌어서 당황했습니다. 하지만 며칠 써보니 훨씬 직관적이고 세련된 느낌이 들더라고요. Synology DSM 7.x 업데이트의 주요 변경점을 꼽아보면 이렇습니다.

    • 새로운 사용자 인터페이스(UI)와 사용자 경험(UX): 전체적으로 더 현대적이고 깔끔하게 개선됐습니다. 응답성도 좋아졌고, 웹 기반이지만 마치 데스크톱 OS를 쓰는 듯한 느낌을 줍니다.
    • 스토리지 관리자(Storage Manager) 개편: 저장소 풀(Storage Pool)과 볼륨(Volume) 관리가 훨씬 시각적으로 명확해졌어요. 디스크 상태나 RAID 구성 현황을 한눈에 파악하기 정말 편해졌더라고요.
    • 보안 강화: 2단계 인증(2FA) 강화, 보안 자문(Security Advisor) 기능 개선 등 전반적인 보안 기능이 업그레이드되었습니다. 제 NAS는 외부에서도 접근하기 때문에 이런 부분은 정말 중요하죠.
    • 사진 관리 기능 개선 (Synology Photos): 기존 Moments와 Photo Station이 통합되어 Synology Photos로 재탄생했습니다. 개인적으로 가장 만족스러운 변화 중 하나인데요. 인공지능(AI) 기반의 얼굴 인식, 객체 인식 기능이 훨씬 강력해져서 사진 정리의 신세계를 경험했어요.
    • SSD 캐싱(SSD Caching) 성능 향상: 저는 NAS에 SSD 캐시를 사용하고 있는데, DSM 7.x에서 캐시 효율성이 더 좋아진 걸 체감했습니다. 특히 가상 머신(VM)이나 데이터베이스를 돌리는 환경에서는 체감 성능이 꽤 크더라고요.
    • Active Insight 도입: Synology NAS의 상태를 중앙에서 모니터링하고 분석할 수 있는 클라우드 기반 서비스입니다. 여러 대의 NAS를 관리하는 분들에게는 정말 유용할 것 같아요.

    이 외에도 백업 패키지(Hyper Backup) 개선, 드라이브(Synology Drive) 기능 확장 등 자잘하게 바뀐 부분들이 많아요. 이런 변화들이 모여서 전체적인 NAS 사용 경험을 한 단계 끌어올려 줬다고 생각합니다.

    Synology DSM 7.x의 깔끔해진 UI 대시보드입니다. 한눈에 들어오는 디자인이 정말 인상적이죠!

    Synology DSM 7.x 업데이트, 이렇게 진행하세요! (단계별 가이드)

    자, 이제 실전입니다. Synology NAS 업데이트는 언제나 신중해야 하죠. 특히 데이터가 들어있는 NAS라면 더욱 그렇습니다. 제가 직접 업데이트하면서 지켜봤던 안정적인 DSM 업데이트 가이드를 단계별로 설명해 드릴게요.

    1. 백업은 선택이 아닌 필수! ⚠️

    아무리 안정적인 업데이트라고 해도 만약의 사태에 대비해야 합니다. 저도 예전에 한번 업데이트하다가 패키지 충돌로 식겁한 적이 있거든요. 가장 중요한 건 데이터 백업입니다.

    1. Hyper Backup으로 중요 데이터 백업: 외장 하드 드라이브, 다른 NAS, 클라우드 서비스(Google Drive, S3 등) 등 최소 한 곳 이상에 중요 데이터를 백업하세요.
    2. 설정 백업: DSM 제어판 > 업데이트 및 복원 > 구성 백업에서 현재 DSM의 시스템 설정을 백업 파일(.dss)로 저장해두세요. 참고로 이 방법으로는 패키지 설정까지 백업되지 않습니다.

    이 두 가지만 해둬도 업데이트 중 문제가 생겼을 때 복구할 수 있는 확률이 훨씬 높아집니다.

    2. 패키지 호환성 확인 및 업데이트

    DSM 6.x에서 7.x로 넘어갈 때 가장 많이 겪는 문제 중 하나가 패키지 호환성입니다. 일부 서드파티 패키지는 DSM 7.x를 지원하지 않거나, 새로운 버전으로 업데이트해야 정상 작동하는 경우가 많거든요.

    1. Synology 공식 패키지 업데이트: DSM 제어판 > 패키지 센터에서 설치된 모든 Synology 공식 패키지를 최신 버전으로 업데이트하세요.
    2. 서드파티 패키지 확인: DSM 7.x 업데이트 전에 사용 중인 서드파티 패키지(예: Docker 컨테이너, Plex Media Server 등)가 DSM 7.x를 지원하는지 미리 확인해야 합니다. 공식 웹사이트나 커뮤니티에서 정보를 찾아보세요. 저도 Plex 때문에 업데이트를 미뤘던 적이 있습니다.
    3. 불필요한 패키지 제거: 더 이상 사용하지 않거나 호환성 문제가 예상되는 패키지는 미리 제거하는 것도 좋은 방법입니다.

    3. DSM 업데이트 시작

    모든 준비가 끝났다면 이제 Synology DSM 7.x 업데이트를 시작할 차례입니다.

    1. DSM 제어판 접속: 웹 브라우저로 Synology NAS에 접속하여 DSM 제어판으로 이동합니다.
    2. 업데이트 및 복원: ‘업데이트 및 복원’ 메뉴를 클릭합니다.
    3. 수동 업데이트 또는 자동 업데이트:
      • 자동 업데이트: ‘DSM 업데이트’ 탭에서 새로운 DSM 버전이 감지되면 ‘다운로드’ 후 ‘지금 업데이트’를 클릭합니다.
      • 수동 업데이트: Synology 다운로드 센터에서 해당 NAS 모델에 맞는 .pat 파일을 직접 다운로드하여 ‘수동 DSM 업데이트’ 섹션에서 업로드 후 업데이트를 진행합니다. 저는 가끔 자동 업데이트가 느리거나 특정 버전을 선택하고 싶을 때 이 방법을 씁니다.
    4. 업데이트 진행: 업데이트 확인 메시지를 읽고 동의한 후 진행합니다. NAS가 재부팅되면서 업데이트가 진행됩니다. 이 과정은 모델과 업데이트 크기에 따라 수십 분에서 1시간 정도 소요될 수 있습니다. 업데이트 중에는 절대로 NAS의 전원을 끄지 마세요!

    DSM 7.x의 업데이트 및 복원 화면입니다. 여기서 업데이트를 시작하거나 설정을 백업할 수 있죠.

    ⚠️ 업데이트 중 발생할 수 있는 문제 및 트러블슈팅

    저처럼 삽질을 즐기는(?) 분들이라면 업데이트 중 예상치 못한 문제를 겪을 수도 있습니다. 제가 경험했던 몇 가지 문제와 해결 방법을 공유해 드릴게요.

    • “패키지 호환성 문제로 업데이트 불가” 메시지: 특정 패키지가 DSM 7.x와 호환되지 않아 업데이트를 막는 경우입니다. 해당 패키지를 제거하거나, 호환되는 최신 버전으로 수동 업데이트해야 합니다. 저 같은 경우엔 오래된 Docker 컨테이너 이미지 때문에 이런 경고를 받은 적이 있네요.
    • 업데이트 후 패키지 작동 불능: 업데이트는 성공했지만, 일부 패키지가 실행되지 않는 경우가 있습니다. 대부분 패키지 센터에서 해당 패키지를 다시 설치하거나, 수동으로 최신 버전 .spk 파일을 다운로드하여 설치하면 해결돼요. “재설치해도 데이터가 날아가지 않을까?” 걱정하실 수 있는데, 대부분의 Synology 패키지는 데이터와 설정을 별도로 저장하므로 재설치해도 데이터는 유지되는 경우가 많습니다. 그래도 백업은 필수라는 거 잊지 마세요!
    • 웹 UI 접속 불가: 업데이트 후 NAS가 재부팅되었는데 웹 UI에 접속이 안 되는 경우가 간혹 있습니다. 이때는 잠시 기다려보거나, NAS를 물리적으로 재부팅(전원 버튼 길게 누르기) 해보는 수밖에 없어요. 그래도 안 된다면 Synology Assistant를 사용하여 NAS를 찾고, IP 주소를 확인해보세요.
    • 예상보다 긴 업데이트 시간: “NAS가 멈춘 건가?” 싶을 정도로 업데이트 시간이 길어질 때가 있습니다. 특히 저장된 데이터가 많거나, 구형 모델일수록 더 그렇습니다. 인내심을 가지고 기다리는 것이 중요합니다. 1시간 이상 지나도 반응이 없다면 Synology Assistant로 NAS 상태를 확인해보는 게 좋습니다.

    ✅ 업데이트 후 확인 및 안정화

    업데이트가 성공적으로 완료되었다면, 이제 NAS가 제대로 작동하는지 확인하고 안정화 작업을 해줘야 합니다.

    1. 시스템 상태 확인: DSM 제어판 > 정보 센터에서 CPU 사용량, 메모리 사용량, 저장소 상태 등을 확인합니다. 평소와 다른 과도한 리소스 사용이 없는지 살펴보세요.
    2. 설치된 패키지 확인: 패키지 센터에서 모든 설치된 패키지가 정상적으로 실행되고 있는지 확인합니다. 업데이트가 필요한 패키지가 있다면 최신 버전으로 업데이트해주세요.
    3. 서비스 테스트: 파일 공유(SMB/AFP), 웹서버, VPN, Docker 컨테이너 등 본인이 사용하는 주요 서비스들이 정상적으로 작동하는지 하나씩 테스트해봅니다. Synology Photos에 사진이 잘 올라오는지, Synology Drive 동기화는 잘 되는지 등 실제로 사용해보는 게 정말 중요하죠.
    4. 로그 확인: DSM 제어판 > 로그 센터에서 시스템 로그를 확인하여 비정상적인 오류 메시지가 없는지 확인합니다.

    DSM 7.x의 리소스 모니터링 화면입니다. 업데이트 후 시스템이 안정적인지 확인하는 데 정말 유용하죠.

    마무리하며: DSM 7.x, 새로운 경험을 위한 투자!

    오늘은 Synology DSM 7.x 업데이트에 대한 제 경험과 노하우를 공유해 드렸습니다. DSM 6.x에서 7.x로의 전환은 분명 큰 변화였고, 그만큼 업데이트 과정에서 신경 써야 할 부분도 많았어요. 하지만 그만큼 새로운 UI와 강력해진 기능들은 충분히 그럴 가치가 있다고 생각합니다. 특히 Synology Photos 같은 기능은 정말 감동적이었어요.

    물론 Synology NAS 업데이트는 항상 조심해야 합니다. 저도 여러 번의 시행착오를 겪으면서 “백업은 생명이다”라는 교훈을 다시 한번 새기게 되었죠. 이 글이 Synology NAS 사용자분들이 DSM 7.x로 안정적으로 업데이트하는 데 도움이 되었으면 좋겠습니다.

    혹시 Synology DSM 7.x 업데이트 관련해서 더 궁금한 점이나 겪었던 삽질 경험이 있으시다면 언제든지 댓글로 남겨주세요! 다음번에는 DSM 7.x에서 강화된 보안 기능이나, 제가 홈랩에서 활용하고 있는 Synology Photos 설정 팁에 대해 다뤄볼까 합니다. 다음에 또 유익한 정보로 찾아올게요! 감사합니다!

    DSM 6.x와 7.x의 주요 기능 비교 인포그래픽입니다. 어떤 점들이 개선되었는지 한눈에 파악할 수 있어요.

  • [k8s] 쿠버네티스 모니터링: Prometheus & Grafana 구축 및 대시보드 활용 가이드

    [k8s] 쿠버네티스 모니터링: Prometheus & Grafana 구축 및 대시보드 활용 가이드

    목차

    🚀 쿠버네티스 모니터링, 왜 중요할까요?

    안녕하세요, 13년차의 서버실 주인장입니다. 오늘은 쿠버네티스 모니터링의 핵심이라고 할 수 있는 Prometheus(프로메테우스)와 Grafana(그라파나) 구축 경험을 공유해볼까 합니다. 쿠버네티스 환경을 운영하다 보면 ‘도대체 내 파드는 잘 돌고 있나?’, ‘CPU 사용량이 왜 이렇게 높지?’, ‘메모리 누수가 생긴 건 아닐까?’ 같은 고민을 하게 되죠.

    저도 처음 쿠버네티스를 도입했을 때, 여러 파드들이 여기저기서 돌아다니는데 이걸 어떻게 한눈에 볼 수 있을까 막막했어요. 로그를 일일이 뒤져보는 것도 한계가 있고요. 그때 제 눈을 번쩍 뜨이게 한 것이 바로 Prometheus와 Grafana 조합이었습니다. 이 두 가지 도구 덕분에 제 홈랩의 쿠버네티스 클러스터는 24시간 감시 체제를 갖추게 되었고, 문제가 생기면 빠르게 파악하고 조치할 수 있게 됐죠. 마치 제 서버실에 똑똑한 비서 한 명을 들인 기분이랄까요?

    이번 글에서는 이 강력한 모니터링 스택을 어떻게 구축하고, 어떤 대시보드를 활용하면 좋을지 제 경험을 녹여서 자세히 알려드리겠습니다. 삽질했던 부분들도 솔직하게 공유할 테니, 여러분은 저처럼 헤매지 않으시길 바랍니다! 자, 그럼 시작해볼까요?

    쿠버네티스 환경에서 Prometheus와 Grafana를 이용한 모니터링 시스템의 전체 아키텍처 다이어그램입니다.

    💡 Prometheus와 Grafana, 핵심 개념 파헤치기

    자, 이제 본론으로 들어가서 쿠버네티스 모니터링의 양대 산맥인 Prometheus(프로메테우스)와 Grafana(그라파나)에 대해 좀 더 깊이 있게 알아볼까요? 처음엔 이름도 어렵고, 뭐가 뭔지 헷갈렸는데, 사실 원리만 이해하면 생각보다 간단하더라고요.

    Prometheus (프로메테우스): 지표 수집의 달인

    Prometheus는 오픈 소스 모니터링 시스템으로, 시계열 데이터베이스(Time-series Database, TSDB)를 기반으로 합니다. 쉽게 말해, 시간의 흐름에 따라 변화하는 다양한 지표(Metrics)들을 수집하고 저장하는 데 특화된 도구거든요. 기존의 많은 모니터링 시스템이 에이전트가 데이터를 서버로 밀어 넣는 Push 방식이었다면, Prometheus는 대상으로부터 데이터를 Pull(가져오는) 방식을 사용합니다. 이 방식은 서비스 디스커버리(Service Discovery)와 결합될 때 쿠버네티스 같은 동적인 환경에서 정말 큰 시너지를 내거든요.

    • Metrics (메트릭, 지표 데이터): CPU 사용량, 메모리 사용량, 네트워크 트래픽 등 서버나 애플리케이션의 상태를 나타내는 수치 데이터입니다.
    • Exporters (익스포터): Prometheus가 지표를 가져올 수 있도록 데이터를 노출하는 작은 에이전트예요. 예를 들어, 서버의 OS 지표를 수집하는 Node Exporter나 쿠버네티스 노드/파드의 지표를 수집하는 cAdvisor 같은 것들이죠.
    • Service Discovery (서비스 디스커버리): 쿠버네티스 환경에서는 파드(Pod)가 수시로 생성되고 사라집니다. Prometheus는 이런 변화를 감지해서 자동으로 새로운 모니터링 대상을 찾아냅니다. 정말 편리하더라고요.

    Grafana (그라파나): 시각화의 마법사

    Prometheus가 지표를 열심히 수집하고 저장해놨다면, Grafana는 그 데이터를 멋진 그래프와 대시보드로 시각화해주는 도구입니다. 복잡한 숫자들을 한눈에 알아보기 쉽게 보여주니까, 이상 징후를 빠르게 파악하고 문제 해결에 집중할 수 있게 도와주죠. 처음에는 Grafana UI가 좀 어려웠는데, 몇 번 써보니 이거 진짜 물건이더라고요! 다양한 데이터 소스(Prometheus 외에도 많은 DB를 지원합니다)를 연결해서 대시보드를 만들 수 있고, 커스텀도 자유롭습니다.

    🛠️ 실전! Helm으로 Prometheus & Grafana 배포하기

    이제 이론은 충분히 봤으니, 실제로 쿠버네티스 클러스터에 Prometheus와 Grafana를 배포해보겠습니다. 저는 Helm(헬름)을 이용하는 것을 선호하는데, 복잡한 쿠버네티스 리소스들을 한 번에 쉽게 배포하고 관리할 수 있거든요. 마치 패키지 매니저처럼요!

    사전 준비물

    1. 동작하는 쿠버네티스 클러스터 (저는 홈랩에서 Kubeadm으로 구성한 클러스터를 사용했습니다.)
    2. Helm v3 이상 설치
    3. (선택 사항) PersistentVolume(영구 볼륨)을 위한 StorageClass(스토리지 클래스) 설정 (데이터 유실 방지를 위해 권장합니다)

    Step 1: Helm Repository 추가

    Prometheus와 Grafana를 포함하는 <code>kube-prometheus-stack은 Helm 차트로 제공됩니다. 먼저 Helm 레포지토리를 추가해주세요.

    helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

    Step 2: Prometheus 스택 배포

    이제 kube-prometheus-stack을 배포할 차례입니다. 이 차트 안에는 Prometheus, Grafana, Alertmanager(알림 관리자), Kube-State-Metrics(쿠버네티스 상태 지표 수집기), Node Exporter(노드 지표 수집기) 등 쿠버네티스 모니터링에 필요한 모든 것이 한 번에 들어있어서 정말 편합니다. 저는 보통 monitoring 네임스페이스에 배포합니다.

    ⚠️ 중요: 프로덕션 환경에서는 values.yaml 파일을 통해 스토리지 클래스, 리소스 제한, 서비스 타입 등을 반드시 커스터마이징해야 합니다. 저는 홈랩이라 기본 설정으로 진행했지만, 여러분은 꼭 신경 써주세요!

    # values.yaml 파일 예시 (간단하게 스토리지 클래스만 지정)
# my-prometheus-values.yaml

prometheus:
  prometheusSpec:
    storageSpec:
      volumeClaimTemplate:
        spec:
          storageClassName: my-storage-class # 본인의 StorageClass 이름으로 변경
          resources:
            requests:
              storage: 10Gi

grafana:
  persistence:
    enabled: true
    storageClassName: my-storage-class # 본인의 StorageClass 이름으로 변경
    size: 5Gi

    이제 위 values.yaml 파일을 적용하여 배포합니다.

    helm install prometheus prometheus-community/kube-prometheus-stack \
  --namespace monitoring --create-namespace \
  -f my-prometheus-values.yaml # 커스터마이징한 values.yaml 파일 적용

    배포가 완료되면 kubectl get pods -n monitoring 명령어로 파드들이 잘 떠 있는지 확인해보세요. 모든 파드가 Running 상태라면 성공입니다! 🎉

    Step 3: Grafana 접속 및 초기 설정

    Grafana는 기본적으로 ClusterIP 타입의 서비스로 배포됩니다. 외부에서 접속하려면 Ingress(인그레스, 외부 트래픽 진입점)를 설정하거나, 간단하게 포트 포워딩(Port-forwarding)을 이용할 수 있어요. 저는 테스트를 위해 포트 포워딩을 자주 사용합니다.

    kubectl port-forward svc/prometheus-grafana 3000:80 -n monitoring

    이제 웹 브라우저에서 http://localhost:3000으로 접속해보세요. 초기 로그인 정보는 다음과 같습니다.

    • User (사용자): admin
    • Password (비밀번호): prom-operator (또는 kubectl get secret prometheus-grafana -n monitoring -o jsonpath='{.data.admin-password}' | base64 --decode 명령어로 확인)

    로그인 후에는 비밀번호 변경을 요청할 겁니다. 안전하게 변경해주세요!

    Grafana에서 Prometheus 데이터 소스를 추가하는 설정 화면입니다.

    📊 나만의 쿠버네티스 대시보드 만들기 & 활용하기

    Grafana에 접속했다면 이제 Prometheus 데이터를 시각화할 차례예요. kube-prometheus-stack 덕분에 Prometheus 데이터 소스는 이미 설정되어 있을 겁니다. 혹시 없다면, Configuration > Data Sources에서 Prometheus를 추가하고 URL을 http://prometheus-kube-prometheus-prometheus.monitoring.svc.cluster.local:9090 (네임스페이스와 서비스 이름에 따라 다를 수 있음)으로 설정하면 됩니다.

    기본 대시보드 활용하기

    kube-prometheus-stack은 기본적으로 여러 유용한 대시보드들을 Grafana에 자동으로 임포트해줍니다. 왼쪽 메뉴에서 Dashboards > Manage로 이동해보세요. 아마 Kubernetes / Compute Resources, Node Exporter Full 같은 대시보드들을 볼 수 있을 겁니다. 저도 처음엔 이 대시보드들만으로도 충분히 모니터링이 가능해서 정말 편하더라고요.

    Grafana Labs 공유 대시보드 임포트하기

    만약 더 다양한 대시보드를 원한다면, Grafana Labs 웹사이트(https://grafana.com/grafana/dashboards/)에서 다른 사람들이 공유한 대시보드를 임포트할 수 있습니다. 예를 들어, Node Exporter Full 대시보드(ID: 1860)나 Kubernetes Cluster Overview(ID: 12150) 같은 것들이 인기가 많죠.

    1. Grafana 좌측 메뉴에서 + > Import를 클릭합니다.
    2. Import via grafana.com dashboard 칸에 대시보드 ID (예: 1860)를 입력하고 Load를 클릭합니다.
    3. 대시보드 이름, 폴더를 설정하고, Prometheus 데이터 소스를 선택한 후 Import를 클릭합니다.

    짜잔! 멋진 대시보드가 눈앞에 펼쳐질 겁니다. 🤩

    나만의 대시보드 커스터마이징

    기존 대시보드를 활용하는 것도 좋지만, 특정 애플리케이션이나 서비스에 특화된 대시보드 구축은 필수입니다. 저는 주로 복제(Duplicate) 기능을 이용해서 기존 대시보드를 복사한 다음, 필요한 패널(Panel)을 추가하거나 수정하는 방식으로 커스터마이징합니다. PromQL(프로메테우스 쿼리 언어)을 조금만 익히면 원하는 지표를 자유자재로 뽑아낼 수 있거든요.

    Prometheus와 Grafana를 통해 구현된 쿠버네티스 클러스터 모니터링 대시보드 예시입니다.

    ⚠️ 삽질 대잔치! 트러블슈팅 경험담

    인프라 엔지니어의 삶은 삽질의 연속이죠. 저도 Prometheus & Grafana 구축 과정에서 몇 번의 삽질을 경험했어요. 여러분은 이런 문제들을 미리 알고 피하시길 바랍니다.

    1. PersistentVolumeClaim (PVC) Pending 문제

    증상: Prometheus나 Grafana 파드가 Pending 상태에서 벗어나지 못하고, PVC가 Pending으로 남아있을 때입니다.

    원인: 대부분 StorageClass가 없거나, 잘못 지정되었을 때 발생합니다. Prometheus는 데이터를 저장하기 위해 영구 스토리지를 써야 하는데, 이를 위한 StorageClass가 없으면 볼륨을 프로비저닝할 수 없거든요.

    해결: 클러스터에 NFS CSI Driver나 Longhorn 같은 동적 프로비저너를 설치하고, 해당 StorageClass를 values.yaml에 올바르게 지정해주세요. 저는 처음에 이 부분을 놓쳐서 한참 헤맸습니다. 🤦‍♂️

    2. 리소스 부족으로 인한 OOMKilled

    증상: Prometheus 파드가 자꾸 재시작되면서 OOMKilled(Out Of Memory Killed) 오류가 발생합니다.

    원인: Prometheus는 수집하는 지표의 양이 많아질수록 메모리 사용량이 늘어나요. 기본 설정된 리소스 제한(Resource Limits)이 클러스터 규모에 비해 너무 낮을 때 발생하는 거죠.

    해결: values.yaml에서 Prometheus 파드의 resources.requests와 resources.limits를 적절히 늘려주세요. 특히 memory 부분을 여유 있게 설정하는 게 중요합니다. 너무 많이 늘리면 다른 파드에 영향을 줄 수 있으니, 모니터링하면서 점진적으로 조정하는 것을 추천합니다.

    3. Prometheus가 타겟을 찾지 못하는 문제

    증상: Grafana 대시보드에서 데이터가 보이지 않거나, Prometheus UI의 Targets 페이지에서 특정 파드가 DOWN 상태로 표시될 때입니다.

    원인: Prometheus의 서비스 디스커버리 설정이 잘못되었거나, 파드에 올바른 레이블(Label)이 지정되지 않았을 때, 혹은 네트워크 정책(Network Policy) 등으로 인해 Prometheus가 파드의 익스포터에 접근하지 못할 때 발생합니다.

    해결:

    • 해당 파드에 Prometheus가 찾을 수 있는 annotations나 labels가 잘 붙어있는지 확인합니다. (예: prometheus.io/scrape: "true")
    • ServiceMonitor 또는 PodMonitor 리소스가 올바르게 정의되어 있는지 확인합니다.
    • 네트워크 정책이 Prometheus 파드에서 대상 파드로의 트래픽을 허용하는지 검토합니다.

    제가 직접 커스텀 애플리케이션을 모니터링할 때 이 문제로 고생 좀 했어요. 애플리케이션 파드에 어노테이션을 빼먹어서 그랬더라고요. ㅎㅎ

    ✅ 구축 결과 확인 및 다음 단계 제안

    이제 여러분의 쿠버네티스 클러스터는 Prometheus와 Grafana라는 강력한 모니터링 시스템을 갖추게 되었습니다. Grafana 대시보드를 통해 노드의 CPU/메모리 사용량, 파드의 상태, 네트워크 트래픽 등 다양한 지표들을 한눈에 볼 수 있을 겁니다. 문제가 발생하면 즉시 알 수 있고, 미리 예방할 수도 있게 되는 거죠. 정말 뿌듯하지 않나요? 🎉

    저도 처음 이 대시보드를 보면서 ‘드디어 됐다!’ 싶었던 기억이 생생하네요. 덕분에 제 홈랩 클러스터가 훨씬 더 안정적으로 운영되고 있습니다.

    다음 단계로 나아가기

    여기서 멈추지 마세요! 쿠버네티스 모니터링은 계속 발전해야 합니다. 몇 가지 다음 단계를 제안해봅니다.

    • Alertmanager(알림 관리자) 설정: Prometheus가 수집한 지표를 기반으로 알림(Alert)을 생성하고, 이를 Slack, 이메일, PagerDuty 등으로 전송하도록 설정해보세요. 저는 슬랙으로 알림을 받는데, 긴급 상황 발생 시 정말 유용합니다.
    • Custom Exporter 개발: 여러분의 특정 애플리케이션에서만 나오는 커스텀 지표를 수집하고 싶다면, 직접 익스포터를 개발해보는 것도 좋은 경험입니다. Python이나 Go 언어로 쉽게 만들 수 있어요.
    • 장기 지표 저장 (Long-term Storage): Prometheus는 기본적으로 로컬 스토리지를 써요. 장기간 지표를 보관하고 싶다면 Thanos(타노스)나 Cortex(코텍스) 같은 솔루션을 연동하여 스케일 아웃 및 장기 보관 기능을 추가할 수 있습니다.

    Prometheus 및 Grafana 기반 쿠버네티스 모니터링 시스템의 주요 이점과 활용 방안을 요약한 인포그래픽입니다.

    맺음말: 13년차 엔지니어의 조언

    쿠버네티스 모니터링은 클러스터 운영의 핵심이자, 인프라 엔지니어의 역량을 보여주는 중요한 부분입니다. 처음에는 어렵게 느껴질 수 있지만, 이렇게 직접 구축하고 활용해보면서 얻는 경험은 그 어떤 이론보다 값지다고 생각합니다. 저도 13년차 엔지니어이지만, 여전히 새로운 기술을 배우고 직접 손으로 만져보면서 배우는 것이 가장 즐겁고 효과적하더라고요.

    오늘 제가 공유한 내용이 여러분의 쿠버네티스 여정에 작은 도움이 되었기를 바랍니다. 혹시 진행 중에 궁금한 점이나 막히는 부분이 있다면 언제든지 댓글로 남겨주세요. 제가 아는 선에서 최대한 도와드리겠습니다. 다음에는 Alertmanager 설정이나 Custom Exporter 개발 경험에 대해서도 다뤄볼 예정이니 기대해주세요!

    다음 글에서 또 만나요! ✋

  • [Proxmox] LXC 컨테이너 심화 활용: Docker 연동 및 성능 최적화 (Proxmox VE 9.1)

    [Proxmox] LXC 컨테이너 심화 활용: Docker 연동 및 성능 최적화 (Proxmox VE 9.1)

    목차

    LXC 컨테이너 심화 활용: Docker 연동 및 성능 최적화 (Proxmox VE 9.1)

    안녕하세요, 13년차 인프라 엔지니어 ’13년차의 서버실’ 블로그 주인장입니다. 오늘도 홈랩에서 밤샘 삽질 끝에 얻어낸 귀한 경험 하나를 공유해드리려고 해요. 💡

    홈랩을 운영하거나 소규모 서버를 돌리시는 분들이라면 Proxmox VE (Virtual Environment)의 매력에 빠져 계실 텐데요. 특히 LXC (Linux Containers)는 가벼운 오버헤드로 높은 성능을 내주기 때문에 저도 애용하고 있습니다. 여기에 Docker까지 연동하면 어떨까요? 효율은 물론이고 관리 유연성까지 챙길 수 있거든요.

    오늘은 Proxmox VE 9.1 환경에서 LXC 컨테이너 안에 Docker를 설치하고, 실제 서비스를 운영하면서 겪었던 삽질과 함께 성능 최적화 팁까지 아낌없이 풀어보겠습니다. LXC와 Docker 연동에 어려움을 겪으셨다면, 이 글이 든든한 가이드가 될 거예요!

    Proxmox VE 호스트에서 LXC 컨테이너와 Docker가 연동되는 아키텍처 다이어그램

    LXC와 Docker, 그리고 그들의 시너지

    먼저 LXC와 Docker가 뭔지 간단하게 짚고 넘어갈게요. 이미 잘 아시는 분들도 계시겠지만, 핵심만 콕 짚어드리겠습니다.

    • LXC (Linux Containers, 리눅스 컨테이너): 리눅스 커널의 컨테이너 기술을 활용한 OS 수준의 가상화예요. 쉽게 말해, 별도의 커널 없이 호스트의 커널을 공유하면서도 독립적인 운영체제 환경을 만들어주는 거죠. 가상 머신(VM)보다 훨씬 가볍고 빠르고, 부팅 시간도 거의 없어서 자원 소모가 정말 적어요.
    • Docker (도커): 애플리케이션 수준의 컨테이너 기술입니다. 특정 애플리케이션과 그에 필요한 모든 종속성(라이브러리, 설정 파일 등)을 하나의 이미지(Image)로 묶어서 어디서든 동일하게 실행되도록 해줘요. 개발 환경과 운영 환경의 불일치 문제를 한 번에 해결하는 거죠.

    그럼 이 둘을 왜 같이 쓸까요? 직접 써본 결과 이런 장점들이 정말 크더라고요.

    특징 LXC + Docker 연동의 장점 기존 방식 대비
    자원 효율성 LXC는 VM보다 오버헤드가 적어서, 그 위에 Docker를 올리면 VM 내 Docker보다 훨씬 적은 자원으로 많은 서비스를 돌릴 수 있어요. VM 내 Docker: 커널 이중화로 자원 낭비
    베어메탈 Docker: 호스트 OS 오염 우려
    격리성 LXC 컨테이너가 OS 수준의 격리를 제공하고, 그 안에 Docker가 또 한 번 애플리케이션 격리를 제공하니 보안성과 안정성이 정말 높아져요. 베어메탈 Docker: 호스트 OS와 Docker 컨테이너 간 완전한 격리가 어려움
    관리 용이성 Proxmox VE의 강력한 LXC 관리 기능(스냅샷, 마이그레이션 등)과 Docker의 애플리케이션 배포/관리 기능을 동시에 누릴 수 있어요. 각각의 장점을 한 번에!

    Proxmox VE 9.1 버전에서는 LXC 컨테이너 기능이 더욱 안정화되고 사용성이 개선되었기 때문에, Docker 연동할 때 시너지가 정말 커져요.

    Proxmox VE 9.1 환경에서 LXC 컨테이너 생성 및 Docker 연동 실전 가이드

    자, 이제 직접 해볼 시간입니다. 제가 홈랩에서 실제로 진행했던 과정을 그대로 따라하시면 돼요. 😎

    1. LXC 컨테이너 기본 생성

    먼저 Proxmox VE 웹 UI에 접속해서 LXC 컨테이너를 생성합니다. OS 템플릿은 Ubuntu 22.04 LTS (Jammy Jellyfish)를 추천할게요. 가장 안정적이고 Docker 지원도 정말 잘 되거든요.

    1. Proxmox VE 웹 UI (https://<Proxmox_IP>:8006) 에 접속합니다.
    2. Datacenter -> pve -> Local (pve) -> CT Templates -> Templates에서 원하는 Ubuntu 템플릿을 다운로드해요.
    3. pve 노드에서 CT 생성 버튼을 클릭합니다.
    4. 일반 설정: Hostname, Password 등을 설정하세요.
    5. 템플릿 설정: 다운로드한 Ubuntu 22.04 LTS 템플릿을 선택해요.
    6. 디스크 설정: 최소 8GB 이상으로 설정해주세요. Docker 이미지를 많이 올릴 계획이라면 더 크게 잡는 게 좋습니다.
    7. CPU 설정: 코어는 1개 이상, CPU units (CPU 유닛)은 기본값(1024)으로 둬도 되지만, 고성능이 필요하면 더 높게 설정할 수 있어요.
    8. 메모리 설정: 최소 512MB 이상을 권장합니다. Docker 앱에 따라 달라지니 유연하게 설정하세요.
    9. 네트워크 설정: Bridge (브리지) 모드로 설정하여 호스트와 동일한 네트워크 대역을 사용하도록 하세요.
    10. 마지막으로 확인을 눌러 LXC 컨테이너를 생성합니다.

    ⚠️ 중요 포인트: 비특권 컨테이너(Unprivileged Container) 설정!

    Docker를 LXC 컨테이너 안에서 안전하게 사용하려면 비특권 컨테이너로 만드는 게 좋아요. 보안상 훨씬 유리하거든요. 하지만 비특권 컨테이너에서 Docker가 제대로 동작하려면 몇 가지 추가 설정이 필요해요.

    1. 컨테이너 생성 후, Proxmox VE 웹 UI에서 해당 LXC 컨테이너를 선택하세요.
    2. 옵션 탭으로 이동합니다.
    3. Features (기능) 항목을 찾아서 편집을 클릭하세요.
    4. 여기서 Nesting (중첩)과 FUSE (파일 시스템 인 유저스페이스)를 활성화하고 확인을 눌러요.

    이 두 가지 옵션이 Docker의 스토리지 드라이버(특히 overlay2)가 LXC 내부에서 정상적으로 작동하도록 하는 핵심이에요. 제가 이걸 몰라서 며칠 밤낮을 삽질했던 기억이 생생하네요… 😅

    Proxmox VE 웹 UI에서 LXC 컨테이너 생성 시 Nesting 및 FUSE 기능을 활성화하는 화면

    2. Docker 설치 및 설정

    LXC 컨테이너가 준비되었다면, 이제 컨테이너에 접속해서 Docker를 설치해봅시다. Proxmox 웹 UI에서 해당 LXC 컨테이너를 선택하고 콘솔 탭으로 이동하면 바로 접속돼요.

    \n# LXC 컨테이너 내부에서 실행

# 패키지 목록 업데이트 및 필요한 도구 설치
sudo apt update
sudo apt install -y apt-transport-https ca-certificates curl gnupg lsb-release

# Docker 공식 GPG 키 추가
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

# Docker Stable 저장소 추가
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Docker 엔진 설치
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io

# Docker 서비스 시작 및 부팅 시 자동 시작 설정
sudo systemctl start docker
sudo systemctl enable docker

# 현재 사용자에게 Docker 그룹 권한 추가 (선택 사항, sudo 없이 docker 명령어 사용 가능)
sudo usermod -aG docker $USER

# 변경 사항 적용을 위해 재로그인 또는 새 쉘 시작
# exit 후 다시 접속하거나, su - $USER 명령으로 적용

# Docker 설치 확인
docker run hello-world

    docker run hello-world 명령을 실행했을 때 성공 메시지가 나온다면 🎉 Docker 설치가 완벽하게 된 거예요!

    3. 비특권(Unprivileged) 컨테이너의 Docker 이슈 해결 (추가 팁)

    위에서 Nesting과 FUSE를 활성화했지만, 간혹 비특권 컨테이너에서 Docker를 사용할 때 권한 문제나 스토리지 관련 이슈가 발생할 수 있어요. 특히 subuid, subgid 매핑이 제대로 안 되어있을 때 그렇습니다. 제가 겪었던 문제 중 하나였죠.

    만약 Docker 컨테이너 실행 시 권한 관련 오류가 발생한다면, Proxmox 호스트에서 다음 설정을 확인해보세요.

    1. Proxmox 호스트에 SSH로 접속합니다.
    2. /etc/subuid와 /etc/subgid 파일에 LXC 컨테이너의 UID/GID 범위가 매핑되어 있는지 확인하세요. 보통 LXC 생성 시 자동으로 추가돼요.
    3. 만약 특정 Docker 컨테이너가 호스트의 특정 디렉토리에 접근해야 하는데 권한 문제가 있다면, /etc/pve/lxc/<VMID>.conf 파일에 다음 라인을 추가하세요. (예시: 100은 컨테이너 ID) 
      echo 'lxc.apparmor.profile: unconfined'
echo 'lxc.mount.auto: cgroup:rw'

      이 설정은 컨테이너의 보안 프로파일을 완화하고 cgroup 마운트를 허용하여 Docker가 더 자유롭게 동작하도록 해요. 하지만 보안상 약간 취약해질 수 있으니 신중하게 사용하세요.

    4. 또 다른 방법으로는 Docker root directory를 변경하여 /var/lib/docker 대신 /mnt/data/docker처럼 별도의 마운트 경로를 사용하는 거예요. /etc/docker/daemon.json 파일을 생성(또는 편집)하고 다음 내용을 추가하세요. 
      {
  "data-root": "/mnt/data/docker",
  "storage-driver": "overlay2"
}

      그 후 Docker 서비스를 재시작해요: sudo systemctl restart docker. 이 방법은 특히 ZFS 같은 파일 시스템을 사용하는 Proxmox 호스트에서 LXC에 더 안정적인 Docker 스토리지 환경을 제공할 때 정말 유용해요.

    성능 최적화를 위한 팁과 트러블슈팅 ⚠️

    LXC 컨테이너에 Docker를 올리면 기본적으로 성능이 좋지만, 몇 가지 설정을 통해 더 극대화할 수 있어요.

    1. 컨테이너 자원 관리 (CPU, RAM)

    • CPU Core (CPU 코어) 할당: Proxmox VE 웹 UI에서 LXC 컨테이너의 CPU 코어를 필요한 만큼 할당하세요. 너무 많이 할당하면 다른 컨테이너나 VM의 자원을 잠식할 수 있으니, 실제 워크로드에 맞춰 조절하는 게 중요해요.
    • CPU Units (CPU 유닛) 조절: 여러 컨테이너가 CPU를 경쟁할 때, 특정 컨테이너에 더 높은 우선순위를 주고 싶다면 CPU units 값을 높게 설정해요. 기본값 1024가 공평한 분배라면, 2048은 두 배의 우선순위를 갖는 식이죠.
    • Memory (메모리) 및 Swap (스왑): Docker 컨테이너가 사용할 메모리를 충분히 할당해주세요. 스왑은 꼭 필요한 경우가 아니라면 비활성화하거나 최소한으로 설정하는 게 성능에 좋아요. 스왑이 너무 많이 발생하면 I/O 병목 현상이 생기거든요.

    2. I/O 성능 개선 (Storage)

    • SSD 사용: Proxmox VE 호스트의 OS 및 LXC 컨테이너 스토리지는 반드시 SSD (Solid State Drive)를 사용하는 게 좋아요. 특히 Docker는 이미지 다운로드, 레이어 관리 등으로 I/O 작업이 빈번하니 SSD의 이점이 극대화돼요. NVMe SSD라면 더할 나위 없겠죠.
    • LVM-Thin or ZFS: Proxmox에서 LXC 컨테이너를 생성할 때 LVM-Thin이나 ZFS 같은 스토리지를 사용하는 게 좋아요. 스냅샷 기능도 유용하고, 성능도 괜찮거든요. 개인적으로는 ZFS를 선호해요.
    • Bind Mount (바인드 마운트) 활용: Docker 컨테이너가 영구 데이터를 저장해야 한다면, LXC 컨테이너 내부의 디렉토리를 호스트의 물리 디스크에 바인드 마운트하는 게 좋아요. 예를 들어, 호스트에 별도의 데이터 디스크를 마운트하고, 이를 LXC 컨테이너에 다시 마운트한 뒤 Docker 볼륨으로 사용하는 방식이죠.
    \n# Proxmox 호스트에서 LXC 컨테이너 설정 파일 편집
# /etc/pve/lxc/VMID.conf 에 다음 라인 추가
lxc.mount.entry: /path/on/host /path/on/lxc none bind,create=dir 0 0

    3. 네트워크 설정 최적화

    • Bridge (브리지) 모드: LXC 컨테이너의 네트워크는 기본적으로 브리지 모드를 사용하는 게 가장 일반적이고 성능 저하가 적어요. 호스트의 브리지(vmbr0)에 직접 연결돼서 별도의 NAT 변환 없이 호스트와 동일한 네트워크에서 통신하거든요.
    • MacVLAN (맥브이랜): 특정 Docker 컨테이너에 별도의 물리적 MAC 주소를 할당하여 호스트 네트워크와 동등하게 통신하고 싶다면 MacVLAN을 고려할 수 있어요. 하지만 설정이 조금 복잡하고, 네트워크 장비가 이를 지원해야 해요. 저도 이 부분은 아직 삽질 중이지만, 특정 시나리오에서는 정말 유용할 수 있습니다.

    성능 검증 및 결과 확인 ✅

    모든 설정이 끝났다면, 이제 실제로 Docker 컨테이너를 띄워서 성능을 확인해볼 차례예요. docker stats 명령어로 각 Docker 컨테이너의 자원 사용량을 실시간으로 모니터링할 수 있거든요.

    \n# LXC 컨테이너 내부에서 실행
docker stats

    이 명령어를 실행하면 CPU 사용량, 메모리 사용량, 네트워크 I/O, 블록 I/O 등을 한눈에 볼 수 있어요. 이 외에도 htop이나 glances 같은 도구를 LXC 컨테이너에 설치하여 전체적인 자원 사용량을 확인하는 것도 정말 좋습니다.

    제가 직접 여러 Docker 컨테이너(Nginx, MariaDB, Portainer 등)를 LXC에 올려서 테스트해보니, 확실히 VM에 올렸을 때보다 CPU와 메모리 사용량이 눈에 띄게 줄어드는 거더라고요. 특히 아이들(idle) 상태에서는 거의 자원을 사용하지 않아서 매우 만족스러웠어요. 🎉

    Proxmox LXC 내 Docker 컨테이너의 CPU, 메모리, I/O 성능 모니터링 대시보드

    마무리하며: 13년차 엔지니어의 한마디

    오늘은 Proxmox VE 9.1 환경에서 LXC 컨테이너와 Docker를 연동하고 성능을 최적화하는 방법을 심도 있게 다뤄봤어요. 제가 직접 겪었던 Nesting, FUSE 같은 핵심 삽질 포인트를 해결하는 방법을 공유하면서, 독자분들의 시간을 절약해드리고 싶었거든요. 😅

    이 조합은 가벼운 홈랩부터 소규모 프로덕션 환경까지, 자원을 효율적으로 사용하면서도 높은 유연성을 제공하는 정말 강력한 솔루션이에요. Proxmox의 안정적인 가상화 기반 위에 Docker의 강력한 애플리케이션 관리 능력을 더하는 거죠.

    물론 모든 기술이 그렇듯, 완벽한 솔루션은 없어요. 하지만 LXC와 Docker의 장점을 잘 이해하고 활용한다면, 여러분의 서버실도 더욱 스마트하고 효율적으로 운영될 수 있을 거예요. 다음에는 이 LXC + Docker 환경 위에 Docker Compose (도커 컴포즈)를 활용해서 여러 서비스를 한 번에 배포하는 방법을 다뤄볼까 하는데, 기대해주세요!

    궁금한 점이나 추가로 알고 싶은 내용이 있다면 언제든지 댓글로 남겨주세요. 여러분의 서버실 운영에 조금이나마 도움이 되었으면 좋겠고, 다음 글에서 또 만나요! 👋

    Proxmox LXC와 가상 머신(VM)에서 Docker를 실행할 때의 성능 및 자원 활용 비교 인포그래픽