▲

AWS에서 베어메탈로 이전한 지 2년: AWS 탈출에 대한 질문에 답하다

 (oneuptime.com)
16P by GN⁺ 3일전 | ★ favorite | 댓글 3개
  • 2년전 AWS에서 베어메탈로 이전해 연간 23만 달러를 절감했던 경험 공유 후, 커뮤니티의 다양한 질문에 대한 후속 답변을 정리한 보고서 2년간의 실전 운영 데이터를 공개하며 $120만 이상의 연간 절감 효과를 달성했다고 밝힘
  • 실전 운영을 통해 절감액은 연간 120만 달러 이상으로 증가했으며, 이를 AI 기반 사고 요약 및 자동 코드 수정용 서버 투자에 재투자해 서비스 품질 향상으로 이어짐
  • MicroK8s + Ceph 스택을 기반으로 99.993% 가용성을 유지하고, 이중 데이터센터 구성으로 단일 장애 지점을 제거함
  • 실제 운영 비용, 장애 대응, 하드웨어 수명, 보안 인증, 클라우드 대체 서비스 등 주요 쟁점을 구체적 수치와 함께 설명
  • 결과적으로 안정성과 비용 효율 모두 향상되었으며, 일정 규모 이상의 상시 부하 시스템에서는 Bare Metal이 더 합리적이라는 결론을 제시

2년간의 운영 결과 요약

  • 24개월 동안 MicroK8s + Ceph 스택을 프로덕션 환경에서 운영하며 99.993%의 가용성 달성
    • 단일 랙 문제를 해소하기 위해 프랑크푸르트에 두 번째 랙을 추가하고, 파리 메인 랙과 DWDM 이중 연결 구성
    • 로컬 NVMe와 소음 간섭 제거로 고객 지연시간을 19% 단축
  • 절감된 비용을 베어메탈 AI 서버 구매에 재투자해, OneUptime의 LLM 기반 알림 요약 및 자동 코드 수정 기능 확장

절감 효과 및 비용 비교

  • 초기 예상 절감액은 연간 $230,000이었으나 현재는 $1.2M 이상으로 증가함
    • 이는 AWS 대비 약 76% 절감 효과에 해당함
    • 글로벌 인건비 기준으로는 엔지니어 2~5명의 연봉에 해당하는 규모임
  • Savings Plans / Reserved Instances를 적용하더라도 여전히 Bare Metal이 유리함
    • Savings Plans는 S3·Egress·Direct Connect 비용에는 적용되지 않음
    • EKS 제어 플레인 비용 $1,260/월, NAT 게이트웨이 $600/월 등도 절감 불가
    • 24/7 상시 운영형(steady) 워크로드로 리저브 인스턴스 효율이 제한적이었음

마이그레이션 및 운영 비용

  • 초기 마이그레이션은 약 1주일의 엔지니어링 작업으로 완료됨
    • IaC 정비, 백업 정책 강화 등 기존에 필요했던 작업이 대부분이었음
  • 현재 운영비는 다음과 같음:
    • 직접 관리: 분기당 약 24시간 (패치·펌웨어 업데이트 포함)
    • Remote Hands: 24개월 동안 2회만 개입 필요(주로 디스크 문제), 평균 대응 시간 27분
    • 자동화: PXE 부팅(Tinkerbell), Talos 이미지 관리, Flux/Terraform 구성 자동화
  • 운영 인력은 기존 AWS 시절보다 오히려 릴리스 속도 증가, “비용 최적화 회의” 부담 제거 효과도 확인됨

장애 대비 및 가용성 확보

  • 프랑크푸르트에 두 번째 랙 추가, DWDM 이중 경로 연결로 단일 장애 지점 제거
    • 비동기 복제 기반 Ceph 미러링과 이중 제어 플레인 구성
    • 4G/위성 기반 관리 경로 추가로 네트워크 장애 시 원격 접근 가능
  • MicroK8s → Talos로 전환 중
  • AWS Failover 백업 클러스터는 여전히 유지하며, 분기별 장애 복구 리허설 수행
  • Anycast+BGP 기반 Ingress로 DNS 전환 지연도 1분 미만으로 개선
  • 2년간 99.993% 가용성 유지, 최근 AWS 리전 장애의 영향도 받지 않음

하드웨어 및 CapEx 관리

  • 서버는 5년 감가상각 기준(2×EPYC 9654, 1TB RAM, NVMe 구성)으로 운용
    • 성능 포화 시 분석 클러스터로 이관 후 신규 서버로 교체
    • 절감분 덕분에 2년마다 40% 리프레시 가능해 졌으며, 여전히 AWS 대비 연간 비용 절감
  • Supermicro 보증 연장 + 예비 서버 3대 보유
    • 실제 수명은 7~8년이지만 보수적으로 5년으로 산정함

관리형 서비스 대체 논리

  • OneUptime의 제품 철학은 자체 호스팅 가능성이므로 동일한 스택 유지가 필요함
    • Kubernetes·Postgres·Redis·ClickHouse 등 오픈스택 일관성 유지
  • Terraform + EKS + RDS → MicroK8s + Argo Rollouts + Ceph로 진화
    • 자체 포크 없이 순정 오픈소스 활용
  • 여전히 클라우드도 병행 사용 중: AWS Glacier(백업), CloudFront(엣지 캐싱), 부하 테스트용 임시 인스턴스
  • 클라우드는 탄력성 중심, 베어메탈은 기본 부하 중심에 적합

네트워크 및 보안

  • 5Gbps(95th percentile) 회선 2개 확보, AWS egress 대비 8배 저렴
  • DDoS 방어는 Cloudflare 전면 배치로 해결
  • 독립된 4G/위성 기반 관리망 확보로 장애 시 원격 접근 가능

컴플라이언스 및 감사 대응

  • SOC 2 Type II, ISO 27001 인증 유지
    • 코로케이션센터의 Tier III 인증·출입 로그·CCTV 자료 활용
    • Terraform/Talos 설정 로그를 변경 이력 증빙으로 활용
  • 감사인은 AWS 콘솔 스크린샷보다 이를 더 신뢰했다고 평가

클라우드 대안 비교

  • Hetzner, OVH, Leaseweb, Equinix Metal, AWS Outposts 비교
    • Hyperscaler는 egress 비용이 여전히 높음
    • 유럽 호스트는 대규모 Ceph 클러스터와 SLA 요건 충족 어려움
    • Equinix Metal은 CapEx 대비 25~30% 프리미엄 존재
    • 자가 하드웨어 운용이 전력밀도·업그레이드 자유도 면에서 우위
  • 결과적으로 15kW 랙 구성과 부품 재사용 가능성 덕분에 콜로케이션이 비용·성능 양면에서 우세

운영 부담(TOIL) 측정

  • 주간: 커널/펌웨어 패치 및 Ceph 점검 (1시간)
  • 월간: Kubernetes 제어 플레인 카나리 업그레이드 (2시간)
  • 분기: DR 훈련, 용량 계획, 통신사 계약 점검 (12시간)
  • 총합 월 14시간 수준, AWS 시절과 유사하나 “비용 추적”에서 “운영 자동화”로 초점이 이동함

클라우드의 여전히 유효한 경우

  • 워크로드가 스파이크형 또는 계절적 패턴인 경우
  • Aurora Serverless, Kinesis, Step Functions 등 관리형 서비스 의존도가 높은 경우
  • Kubernetes·Ceph·모니터링·사고 대응을 직접 운영할 여력이 없는 경우
  • 즉, 초기 단계나 가변 부하가 큰 비즈니스에는 여전히 클라우드 우위가 존재함

향후 계획

  • Colo 예산 예측용 Terraform 모듈 및 Runbook 공개 예정
  • Talos 기반 운영 경험을 다룬 심층 기술 포스트도 준비 중
  • 지속적으로 HN·Reddit 피드백에 응답하며 실제 수치 중심의 사례 공유를 이어갈 계획
▲
okxrr 3일전  [-]

aws 에서만 제공하는 서비스를 전혀 쓰지않는데 aws를 열정적으로 쓰는 회사를 다니고 있습니다.

이 결정에 몇몇 리더분들의 커리어 개발이라는 지극히 개인적인 욕심이 크게 작용하는걸 본 웃픈 이야기..

답변달기
▲
GN⁺ 3일전  [-]
Hacker News 의견

  • AWS는 너무 비쌈. 완전히 AWS 위에 시스템을 올릴 이유가 생각보다 드묾. 예전엔 다들 베어메탈 서버 직접 돌릴 줄 알았는데, 이제는 그걸 잊은 듯함. 우리 팀은 730일 넘게 99.993% 가용성을 유지했고, 최근 AWS 리전 장애도 피해갔음. Cloudflare로 DDoS 방어를 하긴 하지만, DNS나 인그레스 관리가 풀타임 일이 되는 건 이해함. 하지만 마이크로서비스 몇 개와 DB 정도는 직접 돌려도 충분함. AWS는 대부분의 회사에 과금이 과함

    • AWS의 진짜 문제는 직원들의 AWS 종속화임. AWS 인증 따고, AWS Well Architected Framework에 맞춰야 한다는 분위기 속에서 스스로 생각하지 않게 됨. AWS의 락인 서비스는 일부러 싸게 보이게 가격을 책정하지만, 결국 더 깊이 묶이게 됨. 예를 들어 PostgreSQL을 DynamoDB로 옮기면 단기적으로는 절약 같지만, 장기적으로는 AWS 의존이 커짐
    • 온프레미스는 싸지만 전문 인력 확보가 어려움. 단순한 제품엔 잘 맞지만, 복잡한 시스템은 오히려 인건비와 운영 리스크가 커짐. AWS/Azure/GCP가 완벽하진 않지만, 요즘은 온프레미스 전문가가 너무 희귀함
    • AWS를 비판하면 이상하게 반발하는 사람들이 많음. Reddit에서도 비슷한 현상이 있음. 마치 누군가 돈 받고 AWS를 옹호하는 것처럼 느껴짐
    • 셀프호스팅 성공담엔 확증편향이 있음. 서버 직접 운영은 초기엔 좋아 보이지만, 1년쯤 지나면 문서와 실제 설정이 달라지고, 담당자가 퇴사하면 혼란이 커짐. 결국 많은 스타트업이 다시 AWS로 돌아감. 이런 실패담은 잘 공유되지 않음
    • 베어메탈을 잘 돌리려면 숙련된 엔지니어가 필요함. 신입이나 컨설팅 회사 출신 “클라우드 전문가”로는 어려움

  • 초창기 클라우드는 단순하고 가성비 좋은 서비스로 시작했지만, 지금은 200개 넘는 복잡한 서비스로 뒤엉켜 있음. 관리 안 하면 요금이 폭증함

    • 사실 AWS는 처음부터 “싸다”가 아니라 “빠르게 확장할 수 있다”가 핵심이었음. 2010년대 초엔 비쌌지만 유연성이 장점이었음. 지금도 성능 대비 가격은 여전히 비쌈. 서버 관리 기본기만 있으면 전용 서버가 훨씬 나음
    • AWS는 이제 200개 넘는 서비스로 과잉 확장됨. 기본 기능에 집중해야 함
    • AWS 콘솔에 들어갈 때마다 복잡함과 피로감이 밀려옴. 너무 비대함
    • AWS 서비스마다 가성비 편차가 큼. 특히 오래된 핵심 서비스들은 여전히 가치가 있음

  • AWS의 진짜 기능은 (1) 조직 확장과 권력 구조를 가능하게 함, (2) CapEx 대신 OpEx로 회계 처리 가능함, (3) 무능한 인사 구조를 감춤. 예전엔 5~10명으로 데이터센터를 돌릴 수 있었지만, 이제는 3000명짜리 DevOps 조직이 생김

    • OpEx vs CapEx 차이가 왜 중요한지 모르겠음. 결국 돈은 돈 아닌가?
    • 클라우드는 초기 스타트업엔 유용함. 용량 계획 걱정 없이 빠르게 성장 가능함. 하지만 성장률이 낮은 회사가 계속 클라우드에 머무르면 비효율적임
    • 온프레미스는 커스텀화가 심해 인력 교체가 어려움. 반면 AWS 인력은 어디서나 구할 수 있음
    • 숙련된 시스템 관리자는 실제로 구하기 어렵고 비쌈. 싸게 하려다 백업이 2년째 안 된 경우도 봄

  • 이 성공의 핵심은 24/7 일정한 부하임. 대부분의 회사도 사실상 비슷한 패턴임

    • 사실 초기에 단일 랙, 단일 데이터센터로 시작한 게 운이 좋았음. 신뢰성 비용을 미리 안 냈기 때문임
    • 관련 글: One Big Server
    • AWS는 종종 “재고 없음”이라며 예약 인스턴스를 강요함. 결국 상시 운영 비용과 비슷해짐
    • Hetzner 같은 곳은 AWS보다 10배 싸게 같은 성능을 제공함. 클라우드의 “탄력성”은 과장된 신화임

  • 탄력성 vs 기저 부하가 핵심임. 데이터 수집처럼 트래픽이 폭발적으로 몰릴 때만 클라우드가 유리함. 대부분의 경우엔 베어메탈이 낫음

  • 2010년대엔 하드웨어와 네트워크가 느렸지만, 지금은 CPU 성능과 효율이 수백 배 향상됨. 예전 64대 서버가 지금은 1대면 충분함. 앞으로는 100:1 비율까지 갈 것임. 이런 상황에서 클라우드의 장점은 점점 줄어듦

  • 아마존 직원으로서 보기에, Kubernetes 자체 관리는 너무 위험함. etcd 같은 구성요소는 불안정하고, 직접 패치까지 해야 했음. 글에서 말하는 셀프호스팅은 리스크가 과소평가됨

    • 다른 하이퍼스케일러에서도 Kubernetes 관리 실패로 큰 장애를 겪음. Microk8s처럼 단일 랙용 간단한 대안이 나음. 관련 글: Microk8s 6 Months Later
    • 복잡한 환경은 어디서든 어렵고, 결국 전문가가 필요함. AWS도 마찬가지로 쉽지 않음. 클라우드 장애가 나도 세상은 계속 돌아감
    • k3 같은 경량 버전은 훨씬 단순함
    • Kubernetes는 필요할 때만 써야 함. 기본값으로 쓰면 시간과 돈 낭비임

  • 많은 스타트업은 AWS 요금이 너무 비싸서 존재조차 못 했을 것임. 예를 들어 GeoIP 무료 다운로드(링크) 같은 건 불가능했을 것임. 클라우드는 느리고, 디스크 지연과 CPU 과밀이 심함. 월 1만 달러 이하에서는 괜찮지만, 그 이상이면 베어메탈이 훨씬 효율적임

    • 클라우드의 느린 성능에 익숙해져 이상한 적응 현상이 생김. 항상 베어메탈 기준으로 비교해야 함

  • 내가 일하던 회사도 트래픽이 적었는데 AWS로 옮기려 했음. 이유는 단순했음 — 이력서에 AWS를 넣고 싶어서였음. 개발자뿐 아니라 경영진도 마찬가지였음. “AWS 마이그레이션 리드”가 경력에 좋아 보였기 때문임. 결국 회사는 매각되고 사무실은 비었음. 이제는 “AWS에서 벗어났다”가 새로운 경력 포인트가 될지도 모름

    • 개발자들이 AWS를 원하면, 다음 세대는 AWS밖에 모르게 됨. 논의가 편향됨
    • 결국 결정은 리더십의 의지에 달림

  • 결국 중요한 건 무엇을 하려는가임

    • 내부용 데이터 중심 웹사이트라면 서버랙 하나면 충분함
    • 불규칙하고 캐시 불가능한 대규모 트래픽이라면 클라우드가 유리함
    • DNS나 인그레스가 복잡하면 하이브리드 접근이 좋음
    • 데이터 규모가 커질수록 클라우드의 장기 감가상각 구조가 유리해짐
답변달기