홈서버에서 서비스하는 애플리케이션들이 인터넷에서 서비스되기위한 기본적인 인프라를 점검해보고 홈서버를 구동할 하드웨어를 점검해보자.

1. 인터넷 인프라와 도메인네임

홈서버가 인터넷에 어떤 서비스를 공개하기 위해서 몇가지 인프라가 필요하다. 너무 당연하게도 홈서버가 인터넷에 연결되게 하는 인터넷 서비스가 필요하고, 홈서버의 접속 주소를 알려주는 DNS도 필요하다. 또, DNS가 내 홈서버의 주소를 도메인네임으로 알려주기 위해서 도메인네임도 필요하다.

(1) 인터넷 서비스: ISP

나의 경우, ISP는 KT이고 사용 중인 서비스는 100Mbps 짜리 같다. MB/s로 환산하면 12.5MB/s 이다. 예를 들어 블로그에 게시한 어떤 글이 이미지를 포함해서 5MB라면 이 글이 브라우저에 표시되기까지 최소 0.5초 정도 필요하다는 의미이다. 실제로 사용자는 서버와 직접 연결되는게 아니라 많은 단계를 거치기 때문에 더 많은 시간이 필요 할 수 있다. 다르게 말하면 서버가 이용하는 네트워크의 대역폭이 턱없이 부족하지 않다면 그렇게 중요하지 않을 수 있다는 의미이다.(다른 단계에서의 지연에 비하면 크지 않을 수 있다.)

또 내가 사용하는 ISP는 고정 IP를 할당하지 않는다. 즉 라우터(공유기)가 재시작 할 때 마다 이전에 사용하던 IP를 할당 받을 수도 있고, 새로운 IP를 할당 받을 수도 있다. 이런 경우 홈서버가 서비스하는 애플리케이션에 사용자가 원할하게 접속하도록 하려면 DDNS서비스가 필요하다.

(2) DNS와 도메인네임

홈서버에 IP로 접속 할 것이 아니라면 도메인네임과 IP를 매칭해주는 DNS서버가 필요하고, 당연히 도메인네임도 필요하다.
홈서버에 IP로 접속하기로 결정 했더라도 홈서버가 사용하는 공인IP가 고정IP가 아니라면 IP가 변경될 때 마다 이 IP를 사용자에게 알려줄 방안이 필요하다.(왠만하면 도메인네임을 하나 마련해서 DDNS 서비스를 사용하자)

내 홈서버의 이용자는 “오직 나 뿐이다.”라고 장담할 수 있다면 IP가 변경될 때 마다 나에게 이메일로 알려주게 해도 될 것이다.(bash 스크립트와 cron 등을 이용하면 어떻게든 될 것 같다. 하지만 나는 해보지 않았으므로… 여기에서 다루지는 않겠다.) 물론 이런 경우라도 nextcloud를 운영하겠다면 얘기는 달라진다 nextcloud는 설정파일에 접속주소를 명시하도록되어있으므로 IP가 변경될 때 마다 이 설정 파일을 변경하는 것까지 bash스트립트에 추가해두어야 할 것이다.(nextcloud 뿐만 아니라 접속주소를 명시하도록 하고 이 접속주소 외에 다른 주소로는 접속을 허용하지 않는 서비스라면 모두 해당된다.)

(3) DDNS 서비스

내 ISP가 제공하는 IP주소가 고정IP가 아니라면 거의 필수적이다. 새로운 IP가 할당되었을 때, 외부 사용자가 기존의 IP 주소로 접근 할 수 없기 때문이다. 이 문제를 해결하기 위해서 도메인네임을 설정하고 이 도메인네임이 가르키는 IP 주소를 새로운 IP 주소로 갱신해주는 서비스가 DDNS이다. 여기서 외부 사용자라는 것은 외부 네트워크에서 접근하는 나 자신도 포함하는 말이다. 쉽게 말하면 새로운 IP로 갱신 되었을 때 이 IP를 모르면 홈서버의 관리자인 나도 홈서버에 접근 할 수 없다는 의미이다.

내가 사용해본 DDNS 서비스는 duckdns.org와 개인 도메인을 사용한 cloudflare.com이다. 그 외의 후보로 Dynu.com, iptime.org가 있었다.

duckdns.org 를 처음 사용했었는데, 접속 안정성이 낮다는 커뮤니티 의견이 많은 편이고 실제로 경험해본 불편함으로는 인증서 챌린지당시에 duckdns.org 서버가 불안정했는지 인증서 발급이 계속 실패하여 매우 불편했다. 그래서 다른 대안으로 dnyu.com을 검토했지만 제공되는 도메인이 개인적으로 너무 안 예뻐서 포기했다.

뭐였길래 안예쁘다는거냐? 대충 이런거다. duckdns를 사용할때는 “오리라니..귀엽자나”라는 느낌이 있었는데. dynu에서 제공하는 도메인은 고르고 싶은게 전혀 없었다.

그래서 결국 도메인을 하나 구입해서 cloudflare.com의 dns를 사용하기로 했다. 무료 ddns에서 단순히 서브도메인(호스트) 레코드만 관리가능한 것과 달리 개인 도메인이므로 모든 레코드를 관리 할 수 있다.

ddns 서비스	도메인 제공 형태	IP 갱신	비용 및 기타 제약
duckdns.org	[개인 서브도메인].duckdns.org	API 제공 (caddy ddns 모듈 사용가능)	무료 계정 당 5개 도메인 사용가능 와일드카드 인증서 불가
dynu.com	[개인 서브도메인].ddnsfree.com 외 13개	API 제공 (caddy ddns 모듈 사용가능)	무료 계정 당 4개 도메인 사용 가능
iptime.org	[개인 서브도메인].iptime.org	공유기에서 갱신 (caddy ddns 모듈 사용불가)	무료 공유기 당 1개 도메인 사용가능 와일드카드 인증서 불가
cloudflare.com	[개인 서브도메인].[개인도메인].tld	API 제공 (caddy ddns 모듈 사용가능)	무료(DDSN만) 개인 도메인 필수(도메인 별로 가격 다름)

이 후 이어질 “홈서버 구축 #단계”시리즈에서 개인도메인 + cloudflare.com 을 이용한 설정을 중심으로 설명하겠지만, 생각나는데로 duckduns.org로 설정하는 방법들도 설명하겠다. dynu.com또한 다른 점은 없다. 왜냐하면 DDNS갱신은 caddy라는 리버스프록시가 API를 이용해서 자동으로 할 것이기 때문이다. 이 API를 사용하기 위해서 보안토큰을 발급 받는 절차만 다를 뿐 나머지는 동일하다.

개인 도메인을 사용하는데 들어가는 비용은 어떤 도메인을 사용하는 지에 따라서 차이가 큰 편이다. 정확히는 최상위수준 도메인(TLD)에 따라 도메인 등록비용이 많이 차이 난다.

namecheap.com에서 검색해보면 가격을 확인해볼 수 있다. 연간 비용이므로 취미수준으로 지불가능한 비용범위에서 사용가능한 도메인들도 있다. (개인에 따라 그렇지 않을 수도 있지만.. 원화로 연간 1만원 이하로 이용가능한 도메인이 많다.)

도메인 등록 대행업체 별로도 가격차이가 있지만 유의미한 수준은 아닌 경우가 더 많다.
.com, .net, .org 와 같은 전통적인 일반목적 최상위 도메인을 사용하기로 했다면 cloudflare에서 직접등록해도된다. 물론 등록비용은 namecheap 보다는 조금 비싸다(2~3달러). 반면 갱신비용은 namecheap보다 저렴하거나 동일하다. 개인도메인을 사용하면서 비용 절감을 최우선으로 생각한다면 .xyz, .life 같은 신규 일반목적 최상위 도메인을 사용하는 편이 좋다(이때는 cloudflare 말고 다른 곳에서 도메인을 등록하고 클라우드플레어에 연결해야한다.).

나의 경우엔 전통적인 일반목적 최상위도메인 중 .net이 마음에 들었고 비용도 감수할만하다고 판단했다.
.com은 너무 비싸고, .org는 너무 기관이라는 느낌이 강했다.
.net도 전통적인 의미로는 네트워크 관련 기관이 사용하는 최상위 도메인이긴 하지만 이제 전통적인 의미로 사용되지는 않기 때문에 덜 부담스러웠다.
같은이유로 “.org도 괜찮지 않냐?”라고 한다면 org 자체가 organization의 머릿글자라서 여전히 부담스럽다.

2. 하드웨어

서버(홈서버)의 하드웨어라고 하면 보통 고사양의 장치를 상상할 것이다. 실제로 그런 면이 없지는 않다. 성능관점에서의 고사양이라기 보다는 안정성(사용성)관점에서 고사양이라면 충분히 고려해야 할 부분이긴 하다. 예를 들면 정정 웹페이지를 서비스하기위한 웹서비스라면 성능은 386 구닥다리 하드웨어라고 해도 문제가 안될지도 모른다.(극단적으로 그렇다는것이다. 실제로 문제가 없는지 확인해보지는 않았다.) 반면 안정성에 대해서라면 “24시간 365일 정지없이 서비스 할 수 있는가?”라는 관점에 주의 해야 한다. 이런 관점에서의 고사양이라는건 ECC/REG같은 하드웨어적인 오류수정 기능이 있다던가 하드웨어 확장시 시스템 재부팅이 필요없는 핫스왑 기능이 있다던가 하는 것이 중요할 것이다.

홈서버니까 안정성은 관리자가 주의를 기울이는 것, 수시간의 다운타임은 허용하는 것 정도로 타협하도록 하자. 24시간 365일 서비스 같은 목표는 엔터프라이즈 환경에서도 쉬운일이 아니다.(너무 욕심 내지 말자)

“홈서버 구축 0단계“에서 서비스할 애플리케이션을 다 정했기 때문에 다시 논의하는게 바람직 할지 모르겠지만, 확장성 관점에서 성능과 하드웨어 자원에 여유를 검토할 필요도 있다.
예를 들면 plex같은 스트리밍 서비스를 운영할거라면 아마도 CPU에서 디코더와 엔코더를 지원하는 편이 훨씬 유리 할 것이다. 그리고 고용량의 동영상 파일을 저장하기에는 512GB 라는 저장공간도 충분하지 않을 수 있다.

일단 앞선 글에서 정해둔 서비스 범위에서 어떤 수준의 하드웨어가 좋을지에 대해서만 논의 해보자.

내가 사용하는 하드웨어는 아래와 같다.

• 모델명 : LG gram(2017) 13ZD970-GX55K
• CPU : i5 7200U (2core 4thread)
• RAM : 16GB
• Storage : 512GB (nvme SSD)
• wifi support 5Ghz

라우터는 아래와 같다.

• 모델명 : IPtime A21004NS
• wifi support 5Ghz

자~ 보다시피 아주 오래되었고 지금으로써는 사무용으로도 겨우 쓸 수 있을까? 싶은 정도의 저사양이다. 어떻게 이것이 서버용으로 적합한가?

일단 오픈프로젝트와 넥스트클라우드는 개인사용목적이고 오직 블로그 서비스만 공개적으로 서비스 된다는 점을 생각해보자. 아래 결과는 전문적인 벤치마크는 아니다. 그냥 내가 블로그에 접속해서 새로고침 버튼을 반복적으로 눌렀을 때 서버의 CPU 사용률을 나타낸 것이다. 블로그 메인페이지를 새로고침할 때의 삐쭉삐죽한 그래프를 그냥 눈대중으로 평균을 내보자. 내눈에는 대충 15~20% 정도로 보인다.

그러면 이제 몇 가지 가정을 해보자 내가 블로그를 열심히 운영해서 일일 평균 방문자가 100명정도 되고, 이들이 주로 2시간 정도 범위에 걸쳐 접속하고 사용자 당 요청하는 페이지 뷰가 분 당 5회 정도라면 분 당 동시 요청은 최소5회에서 최대 10회 정도라고 가정 할 수 있다. 나 혼자 반복 요청했을 때 CPU 자원이 75~80% 정도 여유가 있으므로 그냥 산술적으로는 4~5배 정도의 여유가 있는것이고, 동시 요청 4~5건까지는 성능저하없이 처리 할 수 있을 것이다. 일일 평균방문자 100명 정도라면 약간의 성능저하가 있을 뿐 서비스를 제공하는 것 자체는 문제가 없을 가능성이 높다는 의미이다.(아마 페이지 반응속도가 좀 느려지겠지., 최악이라도 반응시간이 2배정도 길어지는 정도.)

내가 개인적으로 사용하는 서비스에 대한 점검은 오히려 간단하다. 실제로 의미가 있을지 모르는 가정 같은건 필요 없고 업로드/다운로드 중 페이지 갱신 실험까지 같이 해보면 될것이다. 실제로 내가 쓸 때 유발 할 최대 부하는 이정도 일것이 거의 확실하다. 물론 워드프레스 방문자에 의한 부하와 상호작용이 어떤 영향을 미칠지는 다른 관점에서 조사가 필요하다. 위의 그래프에서 네모 표시 해둔 오른쪽 3개를 살펴보자 마찬가지로 눈대중으로 대충 평균을 가늠해보면 내눈에는 한 30~50% 정도로 보인다. 동시접속 2~3명까지도 문제가 없고 나 혼자 쓴다면 워드프레스 서비스도 거의 정상적으로 유지될 것으로 생각된다.

객관적인 척 그래프 하나 던져 놓고 너무 제멋대로 해석한다고 생각되는가? 그래도 할 수 없다. 난 전문가가 아니니 할 수 있는 수준에서 평가해볼 수 밖에 없다. 도커의 자원 제한 기능을 이용해서 다양한 서비스 제공하는 환경에서 조금 더 안정적으로 서비스가 제공되도록 할 수는 있을 것이다. 그건 차후 생각해 보도록 하자.

3. 정리

네트워크 인프라 중 홈서버 운영에 가장 걸림돌은 내 공인 IP가 변경될 수 있다는 점이다. DDNS 서비스를 활용하면 해결할 수 있다. 비용이 들지 않는 옵션과 비용이 드는 옵션 모두 있다. 이 문제로 홈서버 운영을 주저 하지 말자.

네트워크 인프라 환경에서 두번째 걸림돌은 대역폭이다. 100Mbps짜리 회선이라면 좀 작게 느껴질 수 있다. 블로그 서비스라면 최적화 된 이미지를 사용하자 1개 포스팅 당 10장 정도 넣는다고 해도 페이지 트래픽이 10MB를 넘기지는 않을 것이다. 그렇다면 100Mbps가 결코 작은 대역폭이 아니다.(캐시서버 없이 5명의 동시 접속을 고려해도 대역폭 자체는 100Mbps정도면 1초 내에 콘텐츠를 전송 할 수 있다.)

하드웨어는 7세대 이상의 intel 저전력 프로세서 이상이라면 왠만한 서비스를 운영하는데 문제는 없을것이다. 오히려 100Mbps의 빈약한 네트워크를 가지고 있다면 이쪽이 더 문제일 확률이 높다. 잘 튜닝된 애플리케이션 환경이고 파일서버만 운영한다는 점을 고려해야겠지만 구형 synology NAS도 2core(2thread) 환경으로 구성되어있다. 더 좋은 하드웨어는 더 많은 확장성을 제공하겠지만 어떤 하드웨어를 가지고 있든지 지금 홈서버를 시작하는데 그것이 걸림돌이 될 가능성은 낮다.

홈서버는 완제품으로 제공되는 파일서버 머신(synology 등 유사 제품)과 달리 안정성과 관리 편의성의 관점에서 하드웨어와 소프트웨어 모두 약점을 가지고있다. 이점을 잊지 않는다면 홈서버를 시작할 준비가 된것이다.

개인적으로 홈서버로 왠만하면 하지 않았으면 하는 서비스가 있다.

• NAS : 이건 홈서버로 서비스하더라도 왠만하면 완제품을 사용하자 백업관리 기능 등의 신뢰 수준이 다르다.
  하드웨어가 마련되어있어서 완제품을 구입하는 것이 중복투자라면 unraid같은 전용 소프트웨어를 사용하자.
  내가 넥스트클라우드를 운영하는 것은 실제 NAS로 사용하는 것이 아니라 실험적인 용도이다. 예를 들면 이 블로그에 올리는 글에 들어가는 도표들을 넥스트클라우드 화이트보드에서 그리고있다.
• NAS 외의 어떤 서비스라도 홈서버로 서비스해도 된다고 본다. 홈서버 + NAS 환경을 구축하고 NAS에 홈서버를 자동으로 백업하는 스크립트를 운영한다면 홈서버라도 충분한 안정성을 갖추게된다.

홈서버가 조금더 홈랩스럽기를 원한다면 가급적 proxmox 같은 가상화 환경을 사용하도록하자. 실험적 시도 도중 홈서버가 망가질 가능성을 줄일 수 있고, 복구과정이 매우 신속하다. 이 내용은 더 나은 옵션이 있다는 것을 알리기 위해 적은 것이고 나는 적용하지 않았다.
나의 경우엔 proxmox 하이퍼바이저를 구동하는 자원조차 아끼고 싶을 만큼 저사양의 하드웨어라서 proxmox를 적용하지 않았다. 그리고 또 다른 이유는 실험적인 시도보다는 현재 운영 중인 서비스를 잘 활용하는 것을 주된 목표로 하고 있다. 물론 현재 운영 중인 서비스의 개선(성능이나 보안)을 위해서 실험적 시도를 하고 있고 서버를 망가트려서 처음부터 다시 세팅하기도했다.(proxmox 환경이였다면 좋았겠다는 생각도 했다.ㅠㅠ)

다시 정리하자면 홈서버에 관심이 있으면서 현재의 인프라와 하드웨어를 탓으로 주저하지 말자. 당신은 이미 충분한 인프라와 하드웨어를 갖추고 있는게 분명하다. 그럼에도 불구하고 망설여진다면, 당신은 타협해야할 것을 타협하지 못하고 있는 것이다. 더 나은 서비스를 위해서 타협하는 것은 나중에도 할 수 있다. 지금 가진 것으로 홈서버를 경험해보는 것은 그 나중의 타협을 위한 통찰을 제공할 것이다.

다음 글에서는 본격적인 실행을 다루어보자. debian 13 리눅스 운영체제를 설치하고 기본적인 설정을 해보자. 그리고 나와 같이 구형 랩탑을 하드웨어로 선택한 경우 해야하는 추가설정도 살펴보겠다.(이미 미완성의 글로 이 블로그에 포스팅되어 있긴하다.)