서론
쓸 데 없이 일 벌리는 게 취미라 사이드 프로젝트가 많아졌고, 퇴직후 시간이 남는 김에 탄력이 붙어 오픈을 준비하는 프로젝트들이 하나 둘 생기다 보니 집에 서버를 둬야만 하겠다는 생각이 든 것이 작년 말의 이야기다. 사실 처음 든 생각도, 시도가 없었던 것도 아닌데, 첫 시도는 10대때 용도가 사라진 펜티엄4 LP 컴퓨터를 미디어 및 파일 서버로 쓰겠다는 계획이었다. 구축 자체는 성공했지만 서버를 켜두고 얼마 지나지 않아 누진세의 폭탄을 직격으로 맞고 강제 철거가 됐었다. 두 번째는 시간이 흘러 20대때의 이야긴데 우연히 커뮤니티에서 나눔 받게 된 iptime nas2를 사용했었다. 당연 파일 및 미디어 서버였고, 몇년을 트랜지스터 교체까지 해 가며 잘 쓰다가 결국엔 전원이 켜지지 않게 되고, 용도가 사라짐에 따라 자연스래 철거됐다.
작년에 시작한 새로운 서버는 M1 맥 미니였다.
| AP | RAM | Storage | Idle | Max | OS |
| M1 | 8GB | 256GB | 6~8W | 28~30W | Sequia |
일단 맥이라서 보안에 조금 덜 신경 써도 되겠다고 생각한 점, 상당한 고성능임에도 저전력, 저발열, 저소음 이라는 점, 중고로 인해 30만원 선의 가격적 접근성이 좋다는 점이 홈서버로써 꽤나 매력적인 선택지라고 생각했다.
| PostgreSQL | 50MB ~ |
| Golding-collector | 40MB ~ |
| Golding-api | 16MB ~ |
| Redmine | 200MB ~ |
| TOB-data | 70MB ~ |
유휴상태로만 보면 충분히 여유 있었지만 실제 맥미니의 가용 RAM이 6GB라고 보고, 서비스를 게시하고 DB에 부하가 실리면 GB 단위로 실리니 쓸 데 없는 걱정이 되는 상황이었다. 또한 진행중인 프로젝트들에서 추가적으로 서비스가 추가되면 조금 더 간당간당할 것 같다는 생각이 들었다.
Plan A
당초 구성에 부족한 부분으로 꼽는 것은 아무래도 부족한 RAM과 더 부족한 스토리지다. DB와 레드마인을 동시에 사용하게 되면서 Golding에서 주기적으로 쌓아가는 데이터와 Redmine 사용중 발생하는 여러 산출물들이 빠르게 용량을 늘려 가고 있는 상황이었고, 추가적으로 오픈 할 서비스가 zip파일과 이미지 파일 등을 서빙하게 되면서 스토리지의 용량 문제를 신경쓰지 않을 수 없었다.
| 후보 | ||
| 품목 | 품명 | 용도 |
| DAS | QNAP TR-004 | 용량 확장 후보 1 |
| NAS | Synology | 용량 확장 후보 2 |
| 맥미니 | M1/16GB/256GB | 서비스 전용 |
DAS는 하드 여러개를 다루는 외장하드 케이스의 느낌이고, 제품 자체에 OS가 들어있어 레이드 등의 고급 기능을 사용할 수 있다는 점, 기가비트 연결 대비 USB/TB 를 이용해서 연결되기 때문에 레이턴시가 낮다는 장점이 있다. NAS는 네트워크를 경유하는 스토리지로 보통 일반 가정의 미디어서버, 백업서버로 사용되고는 하고, OS 내에 서비스를 올려 다른 기능을 하기도 한다.
| 1차 결정 | ||
| 품목 | 품명 | 용도 |
| 맥미니 | M1/8GB/256GB | DB 전용 |
| 맥미니 | M1/16GB/256GB | 서비스 전용 |
| DAS | QNAP TR-004 | 용량 확장용 |
서버로 사용하는 맥의 스토리지를 확장한다는 목적때문에 DAS로 잠정 확정된 상황이었으나, 서비스 전용으로 사용하는 맥미니와 동시에 사용하려면 DB용 맥미니에 서비스를 하나 추가해서 사실상 NAS와 비슷한 역할을 하게 된다는 점에서 NAS를 함께 고려하게 됐다. 다만 PostgreSQL의 테이블용으로는 사용이 불가능하다는 점, 레이턴시가 높다는 점에서 결론으로 DAS로 결정했다.
Plan B
| 2차 결정 | ||
| 품목 | 품명 | 용도 |
| 맥미니 | M1/8GB/256GB | DB 전용 |
| 맥미니 | M1/16GB/256GB | 서비스 전용 |
| R2 | 컨텐츠 저장용 |
하지만 DAS 를 추가하는 비용이 그리 만만치 않다는 점, 내장이 아닌 외장으로 연결 된 스토리지를 테이블로 사용하게 되면 크게 불안정하다는 분석이 존재한다는 점이 다시 대두됐고, 1월부터 본격적으로 쌓이기 시작한 DB의 용량이 현재 1GB 단위라는 점, 서비스 전용으로 맥미니를 별도로 분리하면 여유 용량이 확보 된다는 점에 빌어 근 시일내에는 DB가 용량을 가득 채울 가능성이 없다고 판단해 DAS를 제외한 쪽으로 다시 결정했다. 파일을 서빙하는 서비스가 일반 사용자에게 제공되지 않을 거라는 점에서 R2의 무료 플랜으로 커버가 가능할 것이라는 생각이 들었던 부분도 크다.
구성
| 변경 전 | |
| 컨테이너 런타임 | Docker Desktop |
| DDNS | iptime DDNS |
| DNS 관리 | CloudFlare DNS |
| Object Storage | CloudFlare R2 |
맥미니 서버 1대를 사용했던 인프라 구조는 위와 같다. 이후 맥미니로 서버를 확장하는 경우를 가정해 새로 인프라 구조를 다듬을 필요가 생겼고, 임의로 대중적인 입맛을 따랐던 인프라를 조금 더 효율 중심의 것으로 교체하는 목표가 생겼다.
| 변경 후 | |
| 컨테이너 런타임 | OrbStack |
| 컨테이너 관리 | Portainer/Dockhand |
| DDNS | iptime DDNS |
| DNS 관리 | CloudFlare DNS |
| Object Storage | CloudFlare R2 |
Docker Desktop 대비 메모리, CPU 점유가 낮고, Apple Silicon에 조금 더 적합한 OrbStack을 사용하도록 바꿨다. 수치상 OrbStack의 RAM 점유는 Docker Desktop 대비 60% 정도 절감되고, 전력 소비는 절감은 75%나 된다. 벤치마크 수치는 다음과 같다.
| 항목 | Docker Desktop | OrbStack | 개선폭 |
| 시작 시간 | 20~30s | 2초 | 약 90% 단축 |
| 유휴 CPU | n% 지속 | ~0.1% | 대폭 감소 |
| 메모리 사용량 | 3~4GB (유휴) | - | 약 60% 절감 |
| 전력 소비 | ~726mW | ~180mW | 약 75% 절감 |
| 파일시스템 속도 | 기준 | - | 2~10배 향상 |
| 일반 작업 속도 | 기준 | - | 약 1.3배 향상 |
| 컨테이너 시작 속도 | 기준 | - | 약 60% 향상 |
| 이미지 빌드 속도 | 기준 | - | 40~50% 향상 |
| OrbStack 공식 벤치마크 기준 (https://docs.orbstack.dev/benchmarks) 사용자 테스트 참고 (https://www.repoflow.io/blog/apple-containers-vs-docker-desktop-vs-orbstack) |
|||
Portainer와 Dockhand는 Docker 런타임 위에서 돌아가는 웹UI 기반 관리도구이다. 이번 인프라 구성의 주요 항목인데, 지금의 인프라처럼 Docker 호스트가 다수 존재하는 경우 대시보드에서 동시에 관리하기 수월해 진다.
Docker 관리 면에서는 Portainer가 조금 더 사용성이 좋은 느낌이고, Dockhand는 Portainer에 없는 리소스 모니터링과 알림 기능을 제공 하는 것이 장점이다. Portainer로 Docker를 관리하면서 Grafana, Prometheus를 추가로 사용해 알림과 리소스 모니터링을 하는 것이 국룰조합으로 보이는데, 관리 엔드포인트는 한 군데인 것이 용이하기도 하고, 어차피 추가적인 컨테이너로 메모리를 잡아 먹을 거면 Dockhand가 Portainer 대비 메모리를 조금 더 먹는다고 해도 큰 손해는 아닐 것이라는 생각이 들어 최종적으로는 Dockhand로 결정했다.
진행상황
현재 두 대의 맥미니가 각각 역할을 나눠 운영 중이다. DB 전용(8GB)에는 PostgreSQL이, 서비스 전용(16GB)에는 Golding(collector/api), Redmine, TOB-data 컨테이너가 올라가 있다. 컨테이너 런타임은 OrbStack으로 교체 완료했으며, Dockhand를 통해 두 호스트를 단일 대시보드에서 관리하고 있다.
TODO
관리 및 구성은 지금 상태에서 크게 변할 것이 없다고 느끼고 있다. 일반 가정집이다보니 여러 변수가 존재하고, 심지어 여름에는 종종 정전이 되는 집이기에 안정성을 조금 높이는 방향으로 생각중이다. 스위칭허브, UPS등의 장비가 더 필요하고, 유선으로 변경하며 발생하는 공유기 설정이 귀찮으니 조만간 다음 글로 돌아오겠다.