[Server Migration] 구형 미니PC 서버 장애 및 신규 미니 PC 구축기

1. 사건의 흐름

• AM 02:30 : 서버 하드웨어(쿨러)에서 극심한 소음 발생. 긴급 재부팅 후 임시 조치
• AM 09:00 : 오전 중 정상 작동 확인 후 안심
• AM 11:00 : 외부에서 접근 시도 → 서버 전원 완전 다운으로 접근 불가능
• PM 14: 00 : 집으로 복귀 및 재부팅 시도 → 하드웨어 소음 발생
• PM 16:00 : 컴퓨터 수리점 방문 → "수리 불가" 판정
• PM 17:00 : 미니 PC 당근으로 좋은 매물 가져오기
• PM 18:00 : OS Windows -> Ubuntu 설치 및 이전 서버에서 Nginx 및 docker-compose 설정 백업
• PM 19:00 : 신규 서버 인프라 구축 (보안 설정 및 접근 간편화)
• PM 20:00 ~ : CI/CD 재구축 및 기존 서비스 정상화

 

2. 새로운 서버 해결 방안 검토

새로운 서버 환경을 결정하기 위해 세 가지 선택지를 비교했습니다.

 

→ 아무래도 AWS는 시간이 지날 수록 사라지는 자산이며, 메인 PC 듀얼 OS는 내가 사용하면서 너무 불편하며 전력 소모가 아무래도 게이밍PC 이기 때문에 많이 된다라는 판단이 있었습니다. 따라서 지금 당장 비용이 더 들어가더라도 한번 구축해두면 지속 가능한 새로운 미니 PC 구매를 판단하게 되었습니다.

 

 

3. 신규 인프라 재구축 (Migration Steps)

1. 보안 및 접속 편의성 설정

단순한 서버 구동을 넘어, 운영 효율을 위한 보안 설정을 선제적으로 적용했습니다.

• SSH Key 기반 인증: ed25519 알고리즘을 사용해 보안을 강화하고 Password 로그인을 차단하여 Brute-force 공격 방어
• SSH Config 설정: 별칭(alias) lover를 등록하여 터미널 접속 최적화

# ssh lover 명령어로 즉시 접속
Host lover
    HostName home.inwoohub.com
    User inwoo
    IdentityFile ~/.ssh/id_lover

 

 

2. 유동 IP 한계 극복 (DDNS 자동화)

KT 유동 IP 환경은 DHCP로 인해 서버 IP가 수시로 변하므로 도메인이 항상 최신 IP를 가리키도록 Docker 기반 DDNS 시스템을 구축했습니다.

inwoo@lover:~/docker/ddns$ cat docker-compose.yml
services:
  cloudflare-ddns:
    image: favonia/cloudflare-ddns:latest
    container_name: cloudflare-ddns
    restart: always
    environment:
      - CF_API_TOKEN=cfut_~~~
      - DOMAINS=home.inwoohub.com,fcraichu.inwoohub.com,meethub.inwoohub.com
      - PROXIED=false
      - UPDATE_CRON=@every 5m
      - IP6_PROVIDER=none
      - DETECTION_TIMEOUT=15s

 

기술 스택 및 도구

• 이미지: favonia/cloudflare-ddns (Favonia 제작 오픈소스)
• 작동 원리: Cloudflare가 개방한 API를 활용하여, 서버가 직접 자신의 IP 변화를 체크하고 Cloudflare DNS 레코드를 업데이트함.

작동 매커니즘 (Mechanism)

1. IP 감지: 5분 주기로 서버의 현재 공인 IP를 확인.
2. 비교: 이전 IP와 달라졌다면 업데이트 프로세스 시작.
3. API 호출: Cloudflare API를 통해 등록된 3개의 서브도메인(A 레코드) 정보를 즉시 갱신.

• 업데이트 대상 및 용도

 

3. Nginx 리버스 프록시 및 SSL 이관

존 서버에서는 각 프로젝트 폴더 안에 docker-compose.yml이 흩어져 있었으나, 신규 서버(lover)에서는 유지보수와 확장성을 고려하여 ~/docker 디렉토리를 중심으로 인프라 구조를 전면 재설계했습니다.

~/docker/
├── ddns/           # 외부 접속을 위한 IP 자동 갱신 (Infrastructure)
│   └── docker-compose.yml
└── main/           # 실제 서비스 운영 (Application)
    ├── docker-compose.yml
    ├── fcraichu/   # FCRaichu 서비스 관련 정적 파일 및 볼륨
    └── meethub/    # MeetHub 서비스 관련 빌드 소스 및 볼륨

 

• 도입 효과: 인프라용 컨테이너와 서비스용 컨테이너를 분리하여 관리 효율성 증대
• Domain 분기:
  • fcraichu.inwoohub.com: Keycloak(18082) 및 API(18083)로 트래픽 분산
  • meethub.inwoohub.com: Backend(18081)로 연결 및 Swagger UI 경로 최적화
• SSL 적용: Certbot(Let's Encrypt)을 통해 모든 도메인에 HTTPS 보안 연결을 설정하고, 90일 주기 자동 갱신(Renew) 프로세스 등록
• Proxy Pass 최적화: 모든 proxy_pass 주소를 호스트 OS의 루프백 주소(127.0.0.1)로 고정하여 외부에서의 직접적인 컨테이너 접근을 차단(보안 강화)

 

4. 서버 하드웨어 마이그레이션 비교 (Migration Report)

항목	이전 서버 (inwoo-server)	현재 서버 (lover)	차이점 및 체감 성능
모델명	Intel i5-7200U	Intel i5-8500T	저전력 노트북용 → 데스크탑용 프로세서
물리 코어 수	2 Cores	6 Cores	3배 증가. 멀티태스킹 및 병렬 처리 능력 압도적
스레드 수	4 Threads (Hyper-Threading)	6 Threads (Real Cores)	가상 스레드보다 리얼 6코어가 연산 안정성 높음
L3 캐시	3 MiB	9 MiB	3배 증가. DB 조회 및 대용량 데이터 처리 효율 급상승
최대 클럭	3.1 GHz	3.5 GHz	클럭당 성능(IPC)과 절대 속도 모두 향상
아키텍처	7세대 (Kaby Lake)	8세대 (Coffee Lake)	커널 및 최신 라이브러리 최적화 성능 개선

항목	이전 서버 (i5-7200U)	현재 서버 (i5-8500T)	비고
TDP (설계 전력)	15W	35W	성능은 3배지만 소비 전력은 2배 남짓
Idle (대기 전력)	약 5~8W	약 10~15W	서버가 아무것도 안 할 때 먹는 양
Full Load (최대)	약 25W	약 45~50W	빌드나 복잡한 연산 시 순간 전력

 

전력 효율 및 유지비용 :

• 저전력 설계: TDP 35W의 T 시리즈 프로세서 채택으로 24시간 무중단 가동에 최적화됨
• 예상 유지비: 월 평균 15~20kWh 미만의 전력을 사용하며, 전기 요금은 월 3,000원 이하로 매우 경제적임
• 환경: 이전 서버보다 성능은 3배 향상되었으나, 전력 효율 설계 덕분에 유지비 차이는 미미함

 

5. 회고 (Retrospective)

"서버의 마지막 비명, 드르르륵..."

새벽 2시 30분, 비몽사몽한 눈으로 마주한 서버의 소음은 단순한 오작동이 아니라 서버가 보내는 마지막 구조 신호였다. 오전엔 멀쩡해 보였지만 외부 접속이 끊긴 것을 확인한 순간, '직감'이 왔다. 결국 조퇴 후 달려간 집에서 진단 후 컴퓨터 가게에서 서버의 사망 선고(쿨러 및 메인보드 이슈)를 들었다.

위기 대처: "비용과 시간 사이의 최적점"

팀원들과 실 서비스를 앞둔 시점이었기에 '빠른 복구' 가 최우선이었다. AWS와 로컬 PC 활용 등 여러 대안을 검토했지만, 향후 확장성과 가성비를 고려해 중고 미니 PC 영입이라는 결단을 내렸다. 다행히 좋은 매물을 빠르게 구해 즉시 인프라 구축에 착수할 수 있었다.

성장 확인: 4시간에서 1시간 30분으로

진행하며 짜릿했던 점은 나의 성장이었다. 처음 서버를 구축할 때는 삽질하며 4시간이 넘게 걸렸던 인프라 환경(Nginx, SSL, Docker, CI/CD)을 단 1시간 30분 만에 이전과 같이 완벽하게 재현해냈다. 아직 데이터 마이그레이션이 복잡하지 않은 단계였던 행운도 따랐지만, 머릿속에 그려진 인프라 지도가 확실해졌음을 실감했다.

긍정적인 마무리

갑작스러운 하드웨어 사고로 주머니 사정은 조금 가벼워졌지만 "오늘 좀 재밌겠는데?"라는 긍정적인 회로를 돌리며 이 상황을 즐겼다. 결과적으로 기존보다 CPU 성능이 업그레이드된 서버(lover)를 얻게 되어, 앞으로 다가올 실 서비스 운영이 더욱 기대된다. 위기를 기회로 바꾼, 꽤나 생산적인 하루였다.

 

 

 

고생했던 inwoo-server의 마지막 모습

나와  새로운 시작인 lover