AWS에서 Hetzner로 이전해 비용 90% 절감, Ansible로 ISO 27001 유지

 (medium.com/@accounts_73078)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 덴마크 인력관리 회사 Datapult는 AWS 기반 인프라를 유럽 클라우드로 옮기면서 ISO 27001을 유지하고 월 $2,000 수준의 비용을 크게 줄였다고 밝힘
  • 이전 배경에는 CLOUD Act와 FISA 아래 유럽 고객 데이터가 미국 정부 관할권에 노출될 수 있다는 우려와 연간 $24,000 청구액 부담이 있었음
  • Hetzner와 OVHcloud 같은 유럽 소유 인프라를 쓰면서 고객과 감사인에게 데이터 소재지를 더 명확히 설명할 수 있었다고 함
  • AWS Lambda, RDS, CloudWatch의 편의는 줄었지만 Ansible, Prometheus, Grafana, Loki로 자동화와 모니터링을 직접 구성함
  • Ansible 플레이북을 ISO 27001 Annex A 통제 항목과 연결해 감사 추적 자료로 삼았고, 줄어든 클라우드 지출을 다시 사업에 투입함

AWS 의존을 줄인 배경

  • Datapult는 덴마크의 인력관리 회사로, 직원 스케줄링과 초과근무 보상 급여 조정, 근태 데이터의 단일 진실 공급원 역할을 함
  • 이 서비스는 단순 웹서비스보다 운영 요구사항이 엄격하며, 데이터는 항상 정산되고 합산되며 손실되지 않아야 한다는 전제가 있음
  • 기존 인프라는 AWS에서 시작됐고, 법적 요구사항의 상당 부분도 AWS 기반 워크플로에 맞춰 설계돼 있었음
  • 따라서 이전은 클라우드 공급자 교체가 아니라 법적 요구사항과 운영 방식을 함께 다시 맞추는 작업이었음

AWS에서 커진 컴플라이언스와 비용 부담

  • 첫 번째 부담은 컴플라이언스 공백이었음
    • 미국 클라우드 제공자는 서버의 물리적 위치와 관계없이 미국 정부 관할권에서 완전히 벗어나기 어렵다고 판단함
    • CLOUD Act와 FISA 아래 유럽 고객 데이터가 잠재적으로 노출될 수 있어 GDPR 약속을 약화한다고 봄
  • 두 번째 부담은 월 $2,000 비용이었음
    • 연간 $24,000 청구액이 실제 필요에 비해 과하다고 판단함
    • RDS를 관리형 Postgres 인스턴스와 자동화 스크립트로 대체할 수 있는지 검토함
    • 같은 비용이면 유럽 내 복원력 있는 전용 하드웨어를 확보할 수 있다고 봄

AWS를 떠나며 포기한 편의

  • AWS를 떠나면 관리형 서비스의 편의성이 줄어듦
    • Lambda 같은 깊게 통합된 서비스
    • RDS의 원클릭 배포
    • ISO 27001 감사를 매끄럽게 만드는 내장 컴플라이언스 도구 생태계
  • 관리형 서비스의 안락함을 포기한 만큼 더 높은 수준의 통제와 책임을 직접 맡아야 함
  • 이런 변화는 많은 팀에서 두려움과 실행 지연의 원인이 될 수 있음

Hetzner와 OVHcloud 이전으로 얻은 효과

  • 유럽 제공자인 Hetzner와 OVHcloud로 옮기며 데이터 주권, 비용 효율, 운영 통제 측면의 이득을 얻음
  • 데이터 주권 측면에서는 유럽 소유 인프라에서 호스팅해 데이터 소재지를 명확히 입증할 수 있었다고 함
    • 고객 데이터가 어디에 있는지 모호함 없이 설명할 수 있었음
    • GDPR 감사와 ISO 27001 재인증에서 중요한 변화였다고 평가함
  • 비용 측면에서는 클라우드 비용이 90% 감소함
    • 비싼 관리형 서비스를 자동화된 자가 호스팅 솔루션으로 대체함
    • 예산이 더 예측 가능하고 투명해졌다고 함
  • 운영 측면에서는 AWS의 사전 구축 도구를 잃은 대신 내부 역량이 강화됐다고 봄
    • Ansible 기반 인프라 코드 구성을 구축함
    • 이전보다 더 강한 보안 통제와 감사 가능성을 확보했다고 함

Ansible과 오픈소스 모니터링으로 만든 운영 체계

  • Ansible 플레이북을 단순 설정 자동화가 아니라 컴플라이언스 엔진으로 사용함
    • 서버 설정의 각 줄을 ISO 27001 Annex A 통제 항목과 직접 연결할 수 있음
    • 인프라 코드가 자체 문서화된 감사 추적 자료가 됨
  • CloudWatch 없이도 엔터프라이즈급 모니터링을 구성할 수 있다고 봄
    • Prometheus, Grafana, Loki 조합을 사용함
    • AWS에서 가졌던 가시성을 복제했고, 일부 측면에서는 더 나아졌다고 함
    • 사고 대응 속도 향상에 도움이 됐다고 함
  • 클릭으로 적용하는 사전 제작 보안 솔루션이 없기 때문에 보안을 기반부터 직접 설계해야 했음
    • Ansible로 자동화한 설계 단계 보안(security-by-design) 접근을 사용함
    • ISMS, 즉 정보보안관리시스템을 더 견고하고 개발자가 따르기 쉽게 만들었다고 함

사업에 남은 결과

  • 미국 감시 법률과 관련한 컴플라이언스 리스크를 줄였다고 함
  • 유럽 호스팅을 영업 도구로 활용해 브랜드 신뢰를 강화함
  • 클라우드 지출의 90% 를 사업에 되돌렸다고 함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • “핵심 AWS 기능을 직접 재구현했다”는 말에서 빠진 건 직접 운영 비용임. 자체 호스팅에서 보통 가장 비싼 부분이 이 비용이고, 직접 만든 것에 24/7 지원을 붙이면 Amazon에 맡기지 않아 아낀 돈이 크게 줄어들 가능성이 큼
    연 24,000달러는 괜찮은 DevOps 프리랜서 1~2개월치, 개발자를 낮게 잡아도 연간 정규직 1/3명 수준이라 그 예산으로 24/7 지원은 어렵다. 비슷한 이전을 검토 중이긴 하지만, 우리 쪽은 독일 고객들이 미국 호스팅 회사를 꺼리는 비즈니스 이유가 더 크고 비용과 번거로움은 오히려 늘어날 것 같음. 작은 구성에는 Terraform이 과하고 YAGNI에 가깝지만 Ansible은 마음에 듦

    • 클라우드 제공사가 앱에 24/7 지원을 해준다는 건 Azure, AWS, GCP 마케팅이 밀어온 신화에 가까움. 실제로는 그들의 인프라가 대체로 돌아가도록 보장할 뿐이고, 앱 통합이 깨지지 않게 하거나 비용 폭탄을 피하려면 여전히 전문가가 필요함
      클라우드 청구서가 총소유비용(TCO)이라는 생각은 조작에 가깝고, 그 청구서 자체도 제공 가치 대비 매우 비쌀 때가 많음
    • 미국 정부가 Amazon에 계정 폐쇄를 강제해서 AWS에서 쫓겨날 위험까지 고려하면 말이 됨. 미국이 유럽과의 전쟁 가능성까지 암시하는 상황이라면 미국과 연결을 두는 것 자체가 좋지 않은 선택일 수 있음
    • AWS 기능을 100% 복제하면 비싸겠지만 실제로 80%만 필요할 수도 있음. AWS를 설정하고 그 기술을 계속 유지하는 노력, AWS 대시보드 대신 Grafana 같은 더 나은 도구를 쓰지 못하는 기회비용도 같이 봐야 함
      수요의 규모, 다양성, 변동성에 따라 다르고, 모든 못에 공구함에서 가장 큰 망치를 들이댈 필요는 없음
    • 절대 절감액으로 보면 24,000달러의 90%, 즉 연 21,600달러 정도를 아끼는 셈임. 적지 않은 금액이지만 그 돈으로는 SRE/DevOps 엔지니어를 고용할 수 없고, 유럽에서도 그런 엔지니어는 연 70,000달러 이상 받는 편임
      장기적으로는 총소유비용이 더 높아질 것 같음. 이제 소프트웨어 스택의 작은 부분까지 인프라 담당자가 관리해야 하고, 업데이트와 깨지는 변경이 쌓이면서 점점 복잡해질 테니까
    • 이 경우 연간 AWS 비용 24,000달러라는 계산도 순진한 회계일 수 있음. AWS에서 쓰는 서비스를 처음 구성하는 데 들어간 정규직 환산 인력은 얼마였고, 연 청구액을 48,000달러나 100,000달러가 아니라 24,000달러로 유지하는 데 필요한 인력은 얼마인지도 봐야 함

  • Prometheus, Grafana, Loki 같은 훌륭한 도구가 있는데도 AWS 모니터링 스택은 느리고 비싸며 사용자 경험도 부족해서 놀랄 때가 많음
    AWS를 쓰면서 모니터링은 빠르게 가장 비싸고 가장 불쾌한 부분이 됐음

    • Live Tail, 사실상 tail -f ...로 로그를 보는 기능이 유료라는 걸 알고 크게 웃었음. 매일 로그를 보는 데 가장 당연한 기능도 무료가 아니고, CloudWatch는 고통스러움

  • Azure에서도 비슷했고, 매우 유사한 스택으로 약 90% 절감했음. 대형 클라우드는 기업을 이상한 서비스 추상화에 대한 역량에 의존하게 만들고, 기업에 보통 필요한 단순한 운영 이야기를 천천히 갉아먹는 전략처럼 보임

    • Azure가 어떻게 더 저렴한지 더 자세히 설명해줄 수 있음?

  • Hetzner 주소가 수상한 사용자들 때문에 오염되는 문제는 자주 언급되며, AWS/Cloudflare를 통한 “출구”로 완화할 수 있을지도 모름. 또 장애가 나거나 업그레이드가 필요한 하드웨어 위에서 돌아간다는 점도 걱정됨
    Loki도 궁금함. 긴 범위 쿼리에서 Loki 리더의 메모리 과식은 어떻게 다루고, 대안은 있는지 궁금함

    • 오염 문제는 사용자-facing 전체를 Cloudflare 뒤에 두고, 외부 사용자와 봇이 Hetzner/OVH IP와 직접 상호작용하지 않게 함. ufw와 Cloudflare IP 허용 목록으로 L4에서도 신뢰한 소스만 접속 가능하게 막아둠
      장애와 업그레이드는 Terraform으로 프로비저닝해서 교체나 증설을 빠르고 결정적으로 수행함. Prometheus와 node exporter로 하드웨어 지표를 모니터링해 조기 경보를 받고, 9개월 동안 하드웨어 장애는 없었지만 자동화와 설계로 위험을 상쇄함. 앱은 대체로 무상태이고 데이터베이스는 자주 테스트하는 재해 복구 절차가 있음
      Loki는 보존 한도와 인덱스 보존을 구분하고, Loki 설정과 systemd 리소스 제한으로 쿼리 동시성과 최대 메모리 사용량을 조정하며, Promtail식 레이블과 구조화 로깅으로 전체 로그를 정규식으로 훑기보다 초기에 필터링함. 깊은 과거 검색은 객체 저장소 접근 도구나 백업 grep으로 넘기고, Loki는 운영 로그와 근실시간 저장소로 취급하지 아카이브 검색 엔진으로 보지 않음
    • Loki도 비슷한 문제가 있었음. 설정을 많이 만져봤고, Loki 성능 관련 블로그를 읽다 보면 권장 인덱싱 설정이 Helm 기본값이나 다른 배포 설정의 기본값과 다르다는 걸 알게 됨
      재설정하고 읽기 전용 인스턴스를 추가하며 권장 사항을 적용하니 성능이 훨씬 좋아졌음. 다만 그들의 관심은 오픈소스 버전에 기본으로 훌륭한 경험을 제공하는 게 아니라 클라우드 서비스 구매를 유도하는 데 있다는 걸 기억해야 함
    • Loki의 좋은 대안으로 Victoria가 있음. 인기 있고 훨씬 성능이 좋으며 평판도 괜찮지만, 두 프로젝트의 유지보수자 규모와 다양성을 보고 Loki를 선택했음. 제기한 문제들은 타당했고 위에서 말한 방식으로 우회했음
    • https://en.wikipedia.org/wiki/Sybil_attack
      더 비싼 제공자의 장점 중 하나는 사실상의 작업증명 메커니즘 덕분에 평판이 좋다는 점으로 보임

  • 직접 클라우드 이전에 관여하고 있어서 주제는 흥미롭지만, Medium 글에는 이 “Show HN” 게시물보다 정보가 적음. Medium 글은 대부분 홍보성 문구와 리드 생성용에 가까움

    • Medium 글은 비기술 의사결정자까지 포함한 혼합 독자를 위한 높은 수준의 사례 연구에 가까움. 독자를 압도하지 않으려는 이유도 있었고, Ansible/Terraform 패턴이나 Prometheus 설정 같은 진짜 핵심은 그 형식에서 거대한 기술 부록 없이 전달하기 어렵기 때문에 일부러 가볍게 썼음
      구체적인 설정, 다이어그램, 배운 점은 여기서 원하면 공유할 수 있고, 오히려 이 스레드가 그런 심층 논의에 훨씬 나은 장으로 보임. Terraform 모듈 구조, Ansible 하드닝, Prometheus 알림, Loki 튜닝 중 어떤 부분을 더 풀어보면 좋을지 궁금함

  • ISO 27001은 국제 보안 관리 표준이고 유럽에서 인기가 있음. 하지만 미국에서는 그다지 관련성이 높거나 흥미로운 표준이 아니며, 일부 유럽 회사들이 이 점을 잘 이해하지 못함
    미국에서는 SOC 2가 기본이자 선호 표준이고, ISO 27001보다 더 국내 지향적이며 덜 엄격함

    • ISO 27001을 딱히 엄격하다고 부르진 않겠음. 소프트웨어를 쓴다면 어차피 해야 할 일이 대부분임
      다만 그런 일을 실제로 하고 있다는 증거를 확인하는 과정은 빡빡함. SOC 2의 증명 방식은 그렇게 많은 문서를 요구하지 않음
    • 둘 다 겪어본 입장에서는 “엄격한” ISO 27001 쪽을 훨씬 선호함. SOC 2 감사는 감사인과 얼마나 잘 맞았는지, 감사인의 역량이 어땠는지에 더 좌우되는 것처럼 보임
      감사 대상이 너무 넓고 해석 여지가 크며, 감사인이 통제 항목을 묘사하는 방식도 쉽게 왜곡될 수 있음
    • ISO 27001을 준수하지 않는 대형 미국 클라우드 제공자나 비슷한 회사를 하나라도 들어보면 됨

  • 90% 절감은 놀랍지 않음. 초기에 AWS는 자체 하드웨어, 코로케이션, VPS/VDS 호스팅보다 “저렴하다”고 여기저기 홍보됐던 기억이 있음
    예전에 직원 100명 정도의 작은 아시아 회사가 모든 것을 AWS에 올려두고 있었는데, 높은 청구액과 다른 문제 때문에 DigitalOcean으로 옮겼고 SES 같은 일부만 AWS에 남겼음. 그 결과 월 호스팅 비용이 약 10분의 1로 줄었고, 신뢰성이 낮아지는 부작용도 없었음. 누가 AWS가 다른 모든 것보다 싸다고 계산했는지 아직도 의문이고, AWS는 확실히 가장 비싼 제공자 중 하나임

    • 가상 머신, 저장소 같은 범용 서비스를 같은 조건으로 비교하면 DigitalOcean이 항상 AWS보다 더 비싸 보였음. 절감의 주된 원인이 무엇이었는지 기억나는지 궁금함
    • 기억이 틀릴 수도 있지만, 초기에 AWS가 “더 싸다”고 약속한 건 자체 하드웨어를 구매하고 유지하는 것과 비교했을 때뿐 아니었나 싶음
    • AWS는 특정한, AWS에 유리한 가정 아래에서는 더 저렴함. 주로 하드웨어 유지보수 인력을 덜 필요로 한다는 가정에 기대고 있음
    • 덴마크 회사라면 개발자 한 명이 회사에 연 100,000달러 정도는 쉽게 들 수 있음
      하드웨어에서 24,000달러의 90%를 아껴도, 급여로 그 두 배를 쓸 가능성이 큼. 그래서 같은 소프트웨어에 더 비싸더라도, 실제로는 완전히 같은 것도 아니지만, 결국 AWS가 더 저렴해질 수 있음

  • 숫자가 이해되지 않음. 원래 연 24,000달러였고 90%를 아꼈다면 Hetzner에 월 200달러를 쓰는 셈 아닌가? 그건 말 그대로 EPYC 서버 한 대 수준이고, 그 정도면 분산 시스템이 필요 없을 텐데 초당 요청 수나 사용자 수를 더 설명해줄 수 있는지 궁금함

    • ISO 27001을 준수하려면 워크로드를 단일 서버 구성으로 둘 수 없고, 로깅과 모니터링도 별도 서버가 필요함. 부하와 무관하게 인증 때문에 복잡성이 필요해짐
      스케줄링 앱이라 모든 직원이 매일 로그인하지는 않고, 대부분은 일주일에 몇 번 확인함. 일간 활성 사용자는 약 10,000~20,000명, 피크 동시 접속자는 새 스케줄 공개나 교대 시작·종료 시간에 보통 1,500~2,000명, 임의 시점 평균 동시 사용자는 50~150명 정도임
      실시간 기능을 많이 쓰고 복잡한 노동 규칙이 있어 데이터 처리가 많고, 최종적으로 급여 시스템과 동기화해야 해서 클라우드 비용이 쌓일 수 있음. 예를 들어 어떤 교대에 배정되면 사용자마다 의미가 달라지고, 불편 수당이 발생할 수 있으며 그 수당도 교대 배정 시점과 시작 시점의 관계 같은 특정 조건에서만 발생함. 마지막으로 스케줄 최적화는 계산 비용이 큼
    • 월 200달러가 아니라 2,400달러임

  • Hetzner를 좋아함. 내 인터넷 검색 엔진을 거기서 돌리고 있고, 베어메탈이 최고임

  • Hetzner의 가장 큰 문제는 사용자가 CPU 자원을 아주 많이 쓰기 시작하거나, 사실상 어떤 이유로든 경고 없이 계정을 종료할 수 있고 실제로 그렇게 한다는 점임. 물론 아주 합법적인 사용이어도 그럴 수 있음
    몇 달 만에 이런 일을 겪는 사람들도 있고, 그때는 데이터를 잃고 계정이 막힌다고 봐야 함. 설명도 제공하지 않으며 한 달 요금 청구서까지 보냄. Hetzner는 조금도 신뢰할 수 없음
    OVH는 위와 같은 짓은 하지 않지만, 계획 없는 다운타임이 일주일씩 이어질 수 있어 선택적 자원으로만 쓰는 게 괜찮음. 그래도 Amazon보다 싸면서 뒤통수를 치지 않는 제공자는 많음

    • 온라인 소문과 달리 직접 겪지는 않았음. 아래 두 댓글에서 말했듯, 언젠가 둘 다 장애가 날 수 있다고 가정하되 동시에 장애가 나지는 않는다는 전제로 설계로 우회하기로 했음
      1. https://news.ycombinator.com/item?id=44335920#44339234
      2. https://news.ycombinator.com/item?id=44335920#44337619
    • 단일 제공자에 의존하면 안 됨. 항상 제공자 간 실시간 복제를 해야 함. OVH 다운타임은 회사 전체가 단일 서버에서 돌아갈 때만 문제가 되고, 실제로 돈을 버는 서비스라면 여러 영역으로 나눠야 함
답변달기