블로그에서 블로그 운영 얘기를 하기

이 글은 실제 프로덕션 환경을 보여 주면서 진행됩니다.

지인 분들은 아시다시피, 이 블로그는 C17로 작성되어 있으며, 그다지 복잡하지 않은 미니멀 블로그 엔진입니다.

HTTP/3의 QUIC 처리는 lsquic이, SSL은 boringssl이...빅 테크에 숟가락을 얹고 '내가 했는데'라고 오리발 빼는 블로그입니다.

애초에 기능도 별로 없고, 하는 거라고는 마크다운 렌더링, LaTeX 파싱, TikZ 시각화 돌리는 일밖에 없는 게으른 엔진을 돌릴 때 쿠버네티스가 필요할까요? 아닙니다.

만약 이것을 VPS들을 엮어 쿠버네티스로 올린다고 생각해 봅시다.

쿠버네티스는 여기서 너무 독하다

우선 블로그 엔진의 바이너리가 담긴 도커 이미지를 굳이 올리고, 설정 파일을 볼륨 마운트로 설정해서 정보가 호스트 OS에서도 유지되게 해 줍니다. 혹시나 죽지 말라고 레플리카셋을 설정하는 사람도 있지만, 여기서 그렇게 해 봐야 억지로 쿠버네티스를 무겁다고 주장하게 되어 명분이 깨지니 파드는 1개입니다.

이 파드 1개는 블로그 설정에 명시된 포트가 내부적으로만 돕니다. 그러나 블로그는 외부자가 봐야 하기 때문에, 파드로부터 디플로이먼트를 구성하고, 또 서비스를 구성한 후 kubectl expose로 설정된 포트를 nginx에 리버스 프록시를 묶어 줘야 합니다.

실제로 이 블로그 엔진은 이미 자체적으로 인증서 서빙, TLS 1.3까지 boringssl이 차려준 밥상에서 잘 합니다.

실제로 사용자가 원하는 것은 제사 때 쓸 막걸리 한 잔이지, 높은 도수의 소주가 아닙니다. 막걸리 한 잔으로 정갈하게 내 와야 할 술상에 굳이 플레인 HTTP로 내린 후 파드 내에 TCP 포트 설정을 하고, 디플로이먼트를 만들어서 서비스 노출을 하고, 이제서야 NGINX에서 인증서와 함께 리버스 프록시로 포트를 묶어서 편리하게 서빙하는 짓을 하자니, 도수는 달라도 알코올 양은 비슷하다면서 소주로 제사를 지내는 격입니다. 생각해 보세요, 죽어서 말도 못하고 서러운데 막걸리 말고 소주 받고 빨리 취하라니, 감칠맛이 없지 않습니까?

그리고 사람이 편한 걸 찾는 동물인지라 UDP 기반의 HTTP/3까지 포워딩하느니, 저 짓에 지쳐서 HTTP/2까지만 할걸요.

도커 컴포즈는 괜찮지만, Systemd가 있는데 굳이?

여기서 도커 컴포즈는 가볍고, 빠르고, 새로 배포하기도 좋습니다. 엔지니어링 취향에 따라서는 도커 컴포즈에서 포트 설정을 하고 볼륨 마운트를 한 후, docker compose up -d만 할 수도 있습니다. 하지만 잘 생각해 보면, 많은 리눅스 배포판은 "무겁고 느리고 근본없다"는 비판을 이미 감내하고 있습니다. 바로 Systemd라는 비대한 녀석 때문에요. 슬랙웨어 팀은 이 Systemd에 놀라울 정도로 무관심해서, "느리고 근본없으니 안 쓰는" 선택을 했고, 실제로 Systemd는 도커 컴포즈처럼 많은 것을 블랙박스화합니다.

하지만 이렇게 뚱뚱한 Systemd도 도커 컴포즈보다 가볍고, 현대 리눅스 서버는 수만 개의 서비스와 타이머 등이 의존 관계를 가지며 실타래처럼 굴러갑니다.

보통 VPS 업체에 요청하기 제일 무난한 배포판은 우분투나 데비안입니다. Systemd가 포함되어 있죠.

서비스 수십 개를 묶어야 한다면 도커 컴포즈겠지만, NATS 환경변수와 몇 개를 받아서 한 개의 바이너리에서 블로그부터 NATS까지 다 돌려 주는데, 굳이요?

그리고 어떤 사람들은 여전히 Systemd에 Sys-V나 전통적인 Init 시스템만큼의 경량성과 자율성이 있다고 생각합니다.

실제로 Systemd는 여전히 아주 편리하고, 마우스만으로 배포 가능한 시스템은 아닙니다. 하지만 이 녀석은 실패 시 재시작부터, 단순 데몬인지 부모 프로세스를 가지고 포크해야 하는지 등 아주 많은 것을 FreeDesktop 설정 파일 몇 종류로 끝내 줍니다.

가정에선 실 한 가닥을 정리하기 위해 예쁘게 감아서 바느질통에 두지 않습니다.

특히 당신이 레거시 폐쇄망이나, 연구 위탁망 등을 경험해 보셨다면 이런 파일에는 익숙할 것입니다. 그러면 이 블로그를 위해서 뭘 해야 할지도 대충 머릿속에 그려지죠.

이 블로그는 단순히 몇 가지 서버 튜닝 설정을 갖추고, 서버 프로세스를 실행하며, 어쩌다 사고로 죽으면 재시작을 해야 합니다. 프레임워크가 어느 정도 안정된 후에는 겪은 적이 적지만 크래시같은 상황을 들 수 있죠. 이 때 당황하지 않고 재시작을 해 줘야겠죠.

그럼 서비스 종류는 simple, 정책은 Restart=on-failure가 되겠습니다. 실제로는 아래처럼 서버 튜닝도 좀 진행해 주었습니다.

[Unit]
Description=Fly Board Service
After=network.target
After=nats.service
Wants=nats.service

[Service]
Type=simple
Environment=CWIST_WORKERS=1
Environment=CWIST_USE_TCP_CORK=1
Environment=CWIST_C1M_MODE=1
Environment=MALLOC_ARENA_MAX=4
Environment=MALLOC_TRIM_THRESHOLD_=262144
Environment=MALLOC_MMAP_THRESHOLD_=65536
Environment=FLYBOARD_ADVERTISE_H3=true
Environment=BLOG_ECH_KEY=/root/fly.board/ech/server.ech
Environment=NATS_URL=nats://127.0.0.1:4222
LimitNOFILE=1048576
ExecStart=/root/fly.board/fly_board
Restart=on-failure
User=root
Group=root
WorkingDirectory=/root/fly.board/

[Install]
WantedBy=multi-user.target

참고로 말씀드리자면 이 FreeDesktop 구문 강조기는 제가 기여했습니다. 보기에 어떤가요?

수많은 유튜브 IT 채널에서 "당신이 VPS에 배포할 때 도커 컴포즈를 써야 하는 5가지 이유" 같은 것을 설명하지만, 이 설정파일로도 꽤 많은 부분이 감당 가능합니다.

CDN 없이 대륙을 건너는 아프리카권 VPS에서 지연 시간을 향상시키는 것도 환경 변수로 간단하게 처리했고, io_uring을 쓰는 C1M 대비 최적화는 쓰레드 풀을 계속 키우는 모드보다 RSS 증가 폭이 완만해서 잘 켜 줬습니다. VPS의 4GB DDR3 RAM 역시 malloc 최적화와 아레나 설정으로 적절히 개선해 줬습니다. 나름 이 블로그는 플래그십 블로그로 운영 중이라서 NATS도 설정에 들어가 있습니다.

그리고 우리는 단 한 개의 저렴한 Systemd 서비스만으로, 과하게는 Node Taint 설정이나 HA Cluster 구성같은 비대함을 고민할 필요도 없어졌고 작게는 docker-compose.yml의 볼륨 마운트 옵션까지 생각할 필요가 없어졌습니다.

생각보다 블로그를 운영하다 보면 대용량 비디오나 수 GB가 되는 패키지를 아카이빙할 일은 적습니다. 우리가 매일 콘서트에 가는 것도 아니고, 미술관장의 아들딸도 아닙니다. 만약 당신의 집안이 미술관을 하는 간송 재단이거나, 당신이 미술관 서버를 관리한다면 S3 스토리지를 통한 정기 백업이나 국내 클라우드 업체와 계약을 알아봐야겠지만 그렇지도 않습니다. 그렇다고 그림을 그려 보관하고 즐길 수 있는 겸재 정선같은 천재 화가도 아니니까 솔직히 그런 수준의 아카이브는 조금 제쳐 놔도 되겠죠. 어지간히 여행을 많이 다녀도, 500GB 용량을 주는 VPS 하나를 사서 tar -czvf하면 잘 압축됩니다.

cd ~/ && nohup tar -cvzf fly.board.tar.gz path_to_your_blog

깔끔하네요. 이대로 rsync 하면 돼요.

요약해 말하자면 우리가 아무리 글을 많이 써도, 수백 기가바이트의 아카이브로 쩔쩔맬 일은 적습니다. 끽해야 수십 기가바이트 수준의 백업본 하나는 rsync를 돌려 두고 주무셔도 되겠죠.

여기서도 반복되는 언급은 어떤 종류의 작업을 수행할지에 따라 비즈니스 스탠다드가 오히려 과할 때가 있다는 뜻입니다. 앞선 비유를 끌어오자면, 제사 지낼 때 소주를 들이부으면 속설로는 후손이 독종이 된다고 합니다.

어떤 결정은 비즈니스와 소규모 배포에서 모두 유효하고, 어떤 결정은 한 쪽에선 좋지만 한 쪽에선 위태롭습니다.

이런 것을 보면 컴퓨터가 굴러가는 것도 사람의 심리학과도 좀 비슷해 보입니다. 비즈니스에서 하니까 나도 해야 할 것 같은 불안감, 옆 사람은 멋진 사설 클라우드를 구축했으니 나도 뽐내고 싶은 과시욕은 때때로 소프트웨어의 존재 의미를 퇴색시키고 한결같음을 잃게 합니다.

마지막으로 저도 잘 못 지키지만 늘 되새기는 '중용(中庸)'의 미덕을 기술에서도 명심해야 하지 않을까 해서 서경의 구절을 남겨 봅니다.

사람 마음은 위태롭고, 도의 마음은 은미하니, 오직 정밀하게 살피어 한결같이 하여, 진실한 중도를 지킬 수 있다. (人心惟危, 道心惟微, 惟精惟一, 允執厥中.)