Hacker News 의견

• 호스팅 사업의 경험

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

• 트래픽 분석의 오류

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

• 서버 오류와 트래픽

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

• 서비스 확장에 대한 접근

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

• AWS의 이점

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

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

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

• SQLite와 수직 확장

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

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

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

• 단일 서버의 가용성 문제

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

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

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