▲

GN⁺: 2023년, 영광은 단 11MB/초 거리에

 (thmsmlr.com)
2P by neo 8달전 | favorite | 댓글 1개

클라우드 비용에 대한 진실

  • 클라우드 서비스가 저렴하다는 인식이 있지만, 실제로는 사용자가 과도한 비용을 지불할 가능성이 있음.
  • AWS는 아마존의 대부분의 이익을 창출하지만, 이는 클라우드 서비스가 실제로 비싸다는 것을 의미할 수 있음.

첫 원칙에서의 계산

  • 상위 1000개 웹사이트 중 하나를 만들고자 한다면, 예를 들어 businessinsider.com처럼 월 200M 방문자와 400M 페이지 뷰가 필요함.
  • HTML 문서만으로 월 30TB의 대역폭이 필요하지만, 이는 초당 11MB에 불과하며, 이는 현대 하드웨어에서 매우 낮은 기준임.

지연 시간에 대한 이해

  • 빛의 속도로 볼 때 지구 반대편까지 왕복하는 데 약 200ms가 필요하지만, 실제로는 약 300ms가 걸림.
  • CDN을 사용하여 JS, CSS, 미디어를 전달하면, 서버 처리 시간을 300ms 줄여 사용자 옆에 서버를 두는 것과 같은 효과를 낼 수 있음.

엣지 기술의 한계

  • 엣지 기술은 두 번째 세대 서버리스 기술의 발전에도 불구하고 데이터베이스 문제를 해결하지 못함.
  • 대부분의 복잡한 페이지는 데이터베이스 쿼리가 필요하며, 이는 지연 시간을 증가시킬 수 있음.

비용에 대한 고려

  • Hetzner.com은 AWS EC2와 비교했을 때 훨씬 저렴한 서버와 대역폭 비용을 제공함.
  • 클라우드 벤더들은 초기에 무료로 많은 것을 제공하지만, 확장 시 비용이 크게 증가함.

현실적인 상황

  • 특정 사용 사례가 아니라면 대부분의 웹사이트나 SaaS는 단일 서버에서 실행될 수 있으며, 이는 더 저렴하고 유지 관리가 간단함.
  • SQLite를 로컬에서 사용하고, CDN을 통해 CSS, JS, 이미지를 캐시하며, 서버 렌더링을 통해 성능을 향상시킬 수 있음.
  • 복잡한 도커나 가상화 없이도 충분히 확장 가능하며, 관리가 더 쉽고 비용이 저렴함.

GN⁺의 의견

  • 이 기사는 클라우드 서비스의 비용 효율성에 대한 일반적인 믿음에 도전하며, 사용자들이 실제로 필요한 것보다 더 많은 비용을 지불하고 있을 수 있음을 지적함.
  • 클라우드 서비스의 비용 구조와 비교하여, 전통적인 단일 서버 호스팅이 여전히 유효한 대안일 수 있음을 보여줌.
  • 서버리스, 도커, 수평 확장성 등의 기술이 모든 상황에 필요한 것은 아니며, 때로는 더 단순한 접근 방식이 더 나은 성능과 비용 절감을 가져올 수 있음을 강조함.
  • 데이터베이스 최적화와 지역적 배치의 중요성을 강조하며, 이는 클라우드 서비스가 제공하는 것과 동일한 또는 더 나은 성능을 달성할 수 있음을 시사함.
  • 기술 선택 시 고려해야 할 사항으로는 실제 트래픽과 성능 요구 사항을 평가하고, 비용 대비 효율성을 고려하여 클라우드 대신 전통적인 서버 호스팅을 고려할 수 있음.
▲
neo 8달전  [-]
Hacker News 의견

  • 호스팅 사업의 경험

    • 과거 호스팅 사업에서는 고객의 요구에 따라 복잡한 시스템을 제공했음.
    • AWS에 대응하기 위해 API 기반 클라우드 호스팅 플랫폼을 개발했으나, 2012년에 매출이 정점을 찍음.
    • 고객은 AWS 기반의 더 복잡한 솔루션을 원했고, 단순한 서버를 신뢰하지 않았음.
    • 회사는 부트스트랩 방식으로 운영되었고, AWS의 비용 위험을 감수할 필요성을 이해하지 못했음.
    • AWS는 소프트웨어 개발자 세대에 깊이 뿌리내린 '클레버니스'로 인해 선호됨.

  • 트래픽 분석의 오류

    • 트래픽은 균등하게 분포되지 않으며, 피크 시간에 대한 대역폭 요구가 평균치보다 훨씬 높음.
    • 실제 서비스에서는 TCP 및 TLS 연결 설정에 여러 번의 왕복이 필요하며, 사용자 경험에 대한 응답 시간이 중요함.

  • 서버 오류와 트래픽

    • 500 Internal Server Error는 서버가 예상보다 많은 트래픽을 처리하고 있음을 나타냄.

  • 서비스 확장에 대한 접근

    • 불필요한 확장을 피하고, 필요할 때만 구축하는 것이 바람직함.
    • 성능 문제가 발생하면 그때 대응하는 것이 좋음.

  • AWS의 이점

    • AWS를 사용하면 서비스 장애 시 변명의 여지를 제공함.

  • 클라우드 아키텍처에 대한 논의

    • 클라우드 아키텍처의 필요성과 관련된 논쟁이 아니라, 대안을 제시하기 위한 수단임.
    • 서버가 다운될 경우의 가용성 문제는 다른 방식으로 해결할 수 있음.

  • SQLite와 수직 확장

    • SQLite 대신 자체 호스팅된 Postgres를 사용할 수 있으며, 이는 더 많은 설정 노력을 요구함.
    • 전체 글로벌 상태를 메모리에 유지하고 디스크에 스냅샷을 저장하는 아키텍처가 가능함.

  • API와 SQLite 데이터베이스의 결합

    • SQLite는 단일 스레드에서 많은 쿼리를 처리할 수 있음.
    • API 측에서 메모리 캐싱을 사용하고, 정적 페이지에 대해서는 데이터베이스를 건너뛰어 성능을 향상시킬 수 있음.

  • 단일 서버의 가용성 문제

    • 단일 서버에서 서비스를 운영하면 계획되지 않은 다운타임이 발생할 수 있음.
    • 데이터 복구 시간과 데이터 손실량을 고려해야 함.

  • 클라우드로의 이동과 가용성

    • 클라우드로의 이동은 종종 동료 압력으로 느껴짐.
    • 가용성 측면에서 단일 서버는 위험할 수 있으며, CDN과 클라우드를 현명하게 혼합하여 사용하는 것이 좋음.
답변달기