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

 (thmsmlr.com)
2P by GN⁺ | ★ favorite | 댓글 1개
  • 월 2억 방문자급 상위 1000위권 웹사이트도 HTML만 보면 약 30TB/월, 평균 11MB/초 전송량이라 단일 서버로 감당할 수 있는 규모임
  • 계산은 Business Insider를 기준으로 방문자당 2페이지, 월 4억 HTML 문서, 압축 HTML 약 75KB를 두고 JS·CSS·이미지는 CDN에 맡긴다는 전제에서 출발함
  • 엣지 실행은 사용자와 가까운 서버라는 장점이 있지만, 렌더링 중 데이터베이스 왕복이 생기면 지연 시간이 원본 DB 위치로 다시 끌려감
  • 비용 차이도 큼: Hetzner는 16코어·64GB RAM·NVMe 서버를 $0.34/시간, 20TB 무료 전송 후 $1.5/TB로 제공하지만 AWS와 Vercel은 대역폭 단가가 훨씬 높음
  • 특별히 클라우드가 필요한 작업이 아니라면 단일 서버+SQLite+Litestream+CDN 구성이 더 단순하고 저렴하며, 불필요한 수평 확장을 피할 수 있음

11MB/초로 본 상위권 웹사이트의 실제 규모

  • 상위 1000위권 웹사이트 예시로 Business Insider를 사용함
    • SimilarWeb 기준 전 세계 587위였고 월 방문자는 약 2억 명
    • 방문자당 평균 2페이지를 보면 월 4억 개 HTML 문서를 제공해야 함
    • 샘플 기사 기준 표준 HTML 문서는 압축 후 약 75KB
    • 이를 곱하면 HTML만 약 30TB/월 대역폭이 필요함
  • 30TB/월은 평균으로 환산하면 약 11MB/초임
    • Business Insider 사례에서는 약 150 requests/sec 수준
    • HTML에 CDN을 쓰지 않는다는 가정이며, JS·CSS·이미지는 CDN으로 제공할 수 있음
    • 압축 HTML 75KB는 큰 편이어서, 구현에 따라 HTML 크기를 줄이거나 요청 수를 늘리는 식의 조정도 가능함
  • 현대 하드웨어에서 애플리케이션 코드가 11MB/초의 HTML을 생성하는 것은 낮은 기준임
    • 최신 AMD 서버 프로세서는 64코어·128스레드를 제공함
    • Zen 5 Turin 서버 프로세서는 192코어로 소문이 있으며, 듀얼 소켓 서버에서는 400코어에 가까운 구성과 768스레드까지 언급됨
    • 이 관점에서는 Docker, 서버리스, 수평 확장이 항상 필요한 선택지는 아님

엣지 실행이 항상 지연 시간을 줄이지는 않음

  • 지구 반대편 왕복 지연 시간의 물리적 하한은 빛의 속도 기준 약 200ms임
    • 실제로는 지구 반대편의 좋은 데이터센터까지 대략 300ms가 걸리는 경우가 많음
  • JS·CSS·미디어를 CDN으로 제공한다면 초기 렌더링에서 서버 처리 시간을 300ms 줄이는 것만으로도 서버를 사용자 가까이 옮긴 효과와 비슷해짐
  • 2세대 서버리스 기술은 과거 콜드 부트가 300ms 지연 예산을 쉽게 잡아먹던 문제를 크게 줄였지만, 데이터베이스 왕복은 여전히 남아 있음
  • 페이지 렌더링에 데이터베이스 쿼리가 하나라도 필요하면 엣지 서버는 원본 데이터베이스가 있는 us-east-1 같은 위치로 다시 왕복해야 함
    • 지연 시간이 사용자-원본 서버 사이에서 엣지 서버-원본 서버 사이로 옮겨짐
    • 복잡한 페이지는 렌더링에 5개 이상 데이터베이스 쿼리가 필요한 경우가 많음
    • 많은 웹 프레임워크는 단일 스레드 방식으로 쿼리를 순차 실행하므로, 여러 번 데이터센터 간 왕복이 생기면 한 번 원본으로 가는 것보다 더 느릴 수 있음
  • 데이터센터 간 통신은 데이터센터 내부 통신보다 10배 느리고, 데이터센터 내부 통신은 같은 장치 내부 통신보다 10배 느리다는 경험칙이 있음
    • 이 맥락에서 로컬 SQLite가 지연 시간 절감에 유리한 선택지로 등장함

Hetzner, AWS, Vercel의 비용 차이

  • Hetzner의 16코어 서버는 64GB RAM과 NVMe 드라이브를 포함해 $0.34/시간임
  • 비슷한 x86 서버로 비교된 AWS EC2 m5a.4xlarge는 $0.68/시간임
  • 대역폭 가격 차이는 더 큼
    • Hetzner는 20TB 전송량을 무료 제공하고 이후 $1.5/TB를 청구함
    • AWS는 100GB를 무료 제공하고 이후 $90/TB를 청구함
    • Vercel은 첫 1TB 무료 이후 $200/TB를 청구하는 예시로 언급됨
  • 클라우드 벤더의 무료 제공량은 초기 진입을 쉽게 만들지만, 규모가 커질 때 높은 비용으로 돌아올 수 있음

단일 서버 구성으로 단순하게 운영하기

  • 비디오 트랜스코딩, 자체 AI 모델 실행, 시스템에 실제로 큰 부하를 주는 작업처럼 특정한 클라우드 사용 사례가 없다면 웹사이트나 SaaS는 단일 서버에서 실행 가능함
  • 버지니아에 서버를 두면 영어권 사용자에게 100ms 미만 지연 시간을 제공할 수 있음
  • 권장 구성은 서버 한 대를 중심으로 단순하게 잡음
    • 데이터베이스는 같은 박스의 SQLite를 사용함
    • Litestream으로 SQLite를 지속 백업함
    • CSS, JS, 이미지는 CDN으로 캐시함
    • SQLite와 가까운 곳에서 서버 렌더링해 왕복을 줄이고 성능을 높임
  • 배포도 복잡하게 만들 필요가 없음
    • CI가 코드를 서버로 SCP하면 됨
    • NGINX는 무중단 배포를 지원함
    • Docker와 가상화는 코드 실행과 CI/CD를 느리게 만드는 요소로 취급됨

수평 확장이 필요한 경우와 아닌 경우

  • 수평 확장이 필요하다는 이야기는 대부분의 경우 과장되어 있음
  • 서버 성능은 인터넷 성장보다 더 빠르게 좋아지고 있다는 전제가 깔려 있음
  • 지연 시간이 정말 중요하다면 독일과 캘리포니아에 서버를 추가하는 구성이 가능함
    • 쓰기는 primary로 라우팅함
    • 읽기는 로컬 read replica를 사용함
  • 이런 구성은 충분히 확장 가능하고, 관리 복잡도가 낮으며, 비용도 상당히 저렴함
  • 11MB/초 규모의 HTML 제공은 불필요하게 어렵게 만들 필요가 없음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 예전의 작은 호스팅 사업이 바로 이 지점에서 흥망을 겪었는데, 당시에는 무슨 일이 벌어지는지 몰랐음
    2000년대 초반에 성장할 때 큰 매출은 대개 복잡한 스택에서 나왔고, 이중화된 로드밸런서와 방화벽처럼 고객에게 실제로 필요 이상인 구성이 많았지만 고객이 원했음
    장애 조치는 의도한 방식으로 서버가 죽었을 때 얻는 이득보다 운영 복잡도 비용이 더 큰 경우가 잦았고, AWS에 맞서 API 기반 클라우드 호스팅 플랫폼도 만들었지만 매출은 2012년에 정점을 찍었음
    고객은 AWS를 일부 또는 전부 쓰는 더 복잡한 솔루션을 원했는데, 우리는 하드웨어가 10년 전보다 훨씬 강력해졌으니 큰 고객도 더 적고 단순한 서버를 원할 거라 생각했음
    하지만 그건 영리함을 파는 게 아니라 가격을 파는 일이었고, 그런 전환에 필요한 재무적 야심을 이해하지 못했음. 싼 단일 서버는 아무도 믿지 않았고, 두 대를 사도 확장성에 대한 답이 부족했음
    결국 매출은 버텼지만 Amazon보다 빠르게 관리형 서비스 스택과 소프트웨어 생태계를 만들 수는 없었고, 새로운 기술적 도전이 말라붙은 뒤 2018년에 회사를 팔았음
    부트스트랩으로 자라서 한도 없는 호스팅 청구서가 미친 위험처럼 느껴졌기 때문에 제품 설계도 그런 사고에서 나왔는데, 모두가 그 위험을 감수하고 있다는 게 뒤늦게 보였음
    AWS가 박힌 이유는 VC가 비싼 제품을 가능하게 해서만이 아니라, 그들 특유의 영리함이 한 세대의 소프트웨어 개발자에게 내장됐기 때문임. 다만 언제 클라우드가 필요 없는지, 대안이 무엇인지 아는 지식은 이제 꽤 틈새가 된 느낌

    • AWS의 복잡성과 영리함은 개발자에게 캣닢 같고, 이력서 주도 개발을 받쳐주는 면에서는 따라올 곳이 거의 없음

  • 숫자에는 몇 가지 문제가 있음
    첫째, 트래픽은 균등하게 퍼지지 않음. 글의 4억 페이지 로드/월 수치는 재귀적인 80/20 법칙을 적용받을 수 있고, 그렇게 보면 5.8시간 동안 약 2억 500만 요청이 몰려 초당 약 9.7천 요청이 됨
    단일 시스템으로도 가능은 하지만 더 이상 사소하지 않고, 읽기 복제본 없는 단일 DB까지 원하면 특히 그렇다. 총 트래픽은 같아도 피크 부하에 필요한 대역폭 한도는 낙관적으로 평균 낸 11MB/s보다 훨씬 높아짐
    둘째, 단방향 종단 간 지연시간은 스트리밍 데이터에나 적용됨. 현실의 콜드 스타트에서는 HTTP/3가 없으면 TCP 연결에 왕복 3번, TLS 연결에 최소 2번이 필요하고, 그 뒤에야 HTTP 요청과 응답이 오감
    실제 사람에게 서비스하려면 관측 가능한 모든 일이 1초 미만에 일어나야 하며, 그 뒤로는 사용자가 시스템이 고장났다고 보고 탭을 닫는 비율이 급격히 늘어남
    예전에 베팅 거래소 운영을 도왔는데 트래픽은 극단적으로 튀고 지연시간 요구는 빡빡했으며, 거래량은 전체 이벤트 창의 아주 작은 구간에 집중됐음. 실시간 거래는 사용자가 행동을 시작한 순간부터 100ms 안에 화면에 결과가 떠야 했고, 네트워크 왕복 지연이 이벤트 처리 예산을 갉아먹었음
    참고: https://www.nngroup.com/articles/response-times-3-important-...

    • Business Insider 클론 같은 서비스에서는 1번이 핵심임. 큰 Twitter 계정이 기사 하나를 링크하면 월평균 페이지 로드 전체가 몇 분 안에 몰릴 수도 있음
      그런 부하도 큰 단일 서버 구성으로 처리할 수는 있지만, 이제 단순한 웹서버가 아니라 내장 웹서버가 달린 꽤 강한 프런트엔드 로드밸런서를 만드는 셈이 됨
      AWS가 비싸게 받긴 해도 로드밸런서와 네트워크 인프라에는 엄청난 엔지니어링이 들어가 있고, 덕분에 나머지 사람들은 그 스택 영역 전체의 전문가가 되지 않아도 됨
    • 전 세계 예시는 연결 생성 과정을 고려하지 않아서 좀 우스운 면이 있지만, 주된 논지는 여전히 타당함
      실제로 전 세계 도달성이 필요한 서비스가 얼마나 되나? 여러 언어 지원까지 같이 만들었나?
      미국이나 EU 안에서 서비스한다면 괜찮은 중앙 서버 하나로도 해당 지역 전체에 30ms 이하 지연시간을 줄 수 있음
      진짜 글로벌 요구가 있고 글로벌 데이터베이스까지 관리해야 하는 경우가 아니라면 엣지는 과대평가된 편임

  • 500 Internal Server Error가 뜨는 걸 보니 작성자가 11MB/s보다 많은 트래픽을 받고 있는 듯함. 보관본은 여기 있음: https://archive.is/UVpg0

    • PR_END_OF_FILE_ERROR는 처음 봤음. 여러 웹사이트에서는 프록시, VPN, DNS-over-HTTPS 때문에 생긴다고 하지만 내 경우에는 해당하지 않음

  • 이 글은 바라보는 방식이 잘못된 것 같음
    더 나은 접근은 너무 일찍 확장하지 말라는 것임
    필요한 만큼 만들면 되고, 대다수 경우에는 CDN조차 불필요한 비용임. 단, 클라우드 제공자의 과한 대역폭 세금을 내지 않는다는 전제임
    성능 문제가 보이기 시작하면 그때 처리하면 되고, 평범한 일꾼 말이 갑자기 모두가 바라는 유니콘이 된다면 그건 갖고 싶은 문제임

    • 단일 서버로 시작하면 됨. 우리는 Facebook이 아니고, 스타트업의 성공이 첫해에 한 달 한 번 15분짜리 예기치 못한 다운타임이 있느냐에 달려 있지는 않음
      제품이 괜찮으면 사용자는 한 시간 뒤 다시 시도하지 경쟁사로 바로 갈아타지 않음. 확장성 문제가 생기면 자원 집약적인 부분만 확장 가능한 하이브리드 모델로 가면 됨
      그래도 처음부터 웹스케일, 마이크로서비스 수십 개, 그 사이에서 폭발하는 장애 상태, 첫 고객 전 AWS 청구서로 VC 돈 태우기를 원한다면 마음대로 하면 됨
    • 내 경우에는 DigitalOcean이 CDN, CI, 고가용성, Git 배포 같은 편의 기능을 월 5달러에 줘서 거기서 시작함
      직접 물리 서버를 운영하는 건 나중 문제지 지금 문제가 아님. AWS 청구서 100만 달러와 큼직한 단일 서버 중 선택해야 할 때쯤이면 블로그 글을 보고 결정하지 않고 직접 테스트를 돌리고 있을 것임

  • AWS를 쓰면 희생양도 같이 사는 셈임. 큰 클라우드 서비스 장애는 상사나 투자자에게 설명하기가 쉽지만, 팀의 사람 실수로 같은 누적 다운타임이 생겼다고 설명하기는 훨씬 어려움

    • 사람 실수는 클라우드 유행 전후를 막론하고 장애 원인 1위임
      그렇다면 클라우드가 희생양이라는 해석과 어떻게 맞물리는지 궁금함

  • 수직 확장을 노린다면 왜 SQLite인가? 같은 서버에서 앱과 함께 자체 호스팅 Postgres나 Supabase를 돌리는 걸 막는 건 없고, 설정 노력이 더 든다는 것 외에는 단점이 잘 떠오르지 않음
    DB 없이 가서 전역 상태 전체를 큰 서버 하나의 실제 메모리에 두고, Redis 왕복 없이 프로세스 내부 객체로 유지하며, 가끔 메모리를 디스크에 스냅샷하고, 컴파일되는 멀티스레드 언어를 쓴다면 1Gbit 이상의 NIC를 포화시키며 한 박스에서 전 세계를 서비스할 수 있음
    그런 아키텍처를 쓸 실제 사례가 있었으면 좋겠다는 생각도 듦

    • 왜 SQLite가 안 되나? 물론 답은 항상 “상황에 따라 다르다”지만, 요즘은 SQLite는 진짜 데이터베이스가 아니다라는 분위기가 점점 더 도전받고 있음
      표준적인 관계형 영속성 패턴 밖에서는 기능 차이가 커서 Postgres가 더 나을 수 있지만, 어떤 아키텍처 패턴에서는 SQLite가 앞설 수도 있음
      BusinessInsider처럼 콘텐츠 중심 애플리케이션에서는 SQLite 기반 Baked Data 패턴이 비용과 지연시간 면에서 더 나을 수 있음
      simonw(datasette)는 콘텐츠 중심 또는 데이터가 풍부한 웹사이트에서 SQLite를 운영 환경에 쓰는 도구와 글을 많이 만들었음: https://simonwillison.net/2021/Jul/28/baked-data/
    • 본 벤치마크들에 따르면 SQLite가 훨씬 빠르기 때문이고, 특히 왕복 시간에서 그렇다
      SQLite는 프로세스 내부에서 돌고 직렬화가 필요 없으니 말이 됨. 또 연산을 직렬 처리할 수 있다는 추가 장점도 있어 테스트, 추론, 캐시 계층 구축이 훨씬 쉬워짐
      Unix 소켓을 쓰지 않으면 네트워크 오버헤드도 있지만, 같은 서버라고 했으니 부가 사항으로 남김. 실제로는 격리를 위해 Postgres를 다른 머신에 두는 일이 매우 흔하고, 그게 네트워크 DB의 주요 장점 중 하나이기도 함
    • 단일 머신에서 돌린다면 SQLite가 Postgres/MySQL보다 나음
      필요한 기능은 다 있고 단순성과 속도도 더 좋음. SQLite는 테라바이트급 데이터, 여러 읽기, 실시간 스트리밍 백업을 처리할 수 있고 전반적으로 꽤 균형 잡힌 SQL 구현임
      단일 박스 수직 확장을 넘어설 때에만 Postgres/MySQL을 고려할 것 같음
    • 작성자는 엣지에서 SQLite를 쓸 수 있다는 뜻일 가능성이 있음
      https://blog.cloudflare.com/introducing-d1

  • 많은 사람이 작성자가 지연시간, 대역폭, 비용에 초점을 맞추자 가용성과 신뢰성을 이유로 현 상태를 방어해야 한다고 느끼는 듯함
    내 결론은 트레이드오프 앞에서 클라우드의 장점을 부정하자는 게 아니라, 이제 어디에나 있는 클라우드 아키텍처 패턴과 그에 따른 종속이 정말 필수냐는 쪽임
    이것 대 저것의 대비는 대안을 소개하기 위한 수사적 장치이고, 어떤 해법이 맞는지는 용도별로 수많은 요인에 달려 있음. 바로 그런 요인들 덕분에 엔지니어가 일자리를 얻는 것이기도 함
    다만 작성자가 제안한 패턴 안에서도 SRE 우려를 풀 수 있음. “서버 하나가 죽으면 가용성은 어쩔 건데?”는 우리가 익숙한 시스템과 다른 방식으로 가용성을 해결할 수 있다는 점에서 허수아비 공격에 가깝고, 해법은 실제로 중요한 것에 맞춰야 함

    • 그게 왜 허수아비인가? 온프레미스든 클라우드든 정상적인 사람이 설계 검토에서 당연히 물어볼 내용임

  • 검소한 예산으로 한 단계만 더해 훨씬 많은 걸 얻는 방법이 있음. API와 SQLite DB를 함께 두는 것임
    이상적으로는 API가 오버헤드 낮은 바이너리 직렬화 형식과 지속 연결을 쓰고, 웹 제공은 돈 태우는 VC 지원 엣지 서비스의 무료 티어를 활용하면 됨. 지금은 Cloudflare Workers가 꽤 후하고 송신 트래픽도 무료임
    핵심은 SQLite가 단일 스레드로도 엄청난 초당 질의를 처리할 수 있다는 점임. 많은 연산을 직렬로 밀어 넣을 수 있어 추론이 쉽고, API 쪽 메모리 캐싱과 무효화도 단순해짐
    웹 서빙을 분리해 두면 핸드셰이크의 엣지 성능을 누리고 정적 페이지에서는 DB를 아예 건너뛸 수 있음. 글은 왕복 시간 문제를 과소평가했는데, 실제 앱은 생각보다 더 많은 왕복을 필요로 해서 이 문제는 꽤 현실적임
    DB 밖의 CPU 사용량 대부분은 파싱, 역직렬화, 데이터 복사, TLS에서 나오므로 큰 덩어리를 덜어내면 보급형 머신에서도 초당 수만 쓰기를 쉽게 얻을 수 있고 읽기는 더 빠름
    그래도 전형적인 병목, 특히 I/O는 항상 벤치마크해 볼 가치가 있음. 제공자들은 과장하거나 오해를 부르는 경우가 많으니 무료 티어에서 직접 돌려봐야 함. 갈아타야 할 때를 대비해 통합 테스트와 벤치도 준비해 두는 게 좋음

    • 비슷한 개념을 실험해 보고 있음. PostgreSQL은 질의 결과를 JSON으로 출력할 수 있어서, API가 클라이언트에 내보낼 형태와 정확히 맞추면 먼저 파싱할 필요가 없음
      결과가 큰 경우 꽤 좋지만, PostgreSQL 자체가 큰 데이터셋을 JSON으로 만드는 과정에서 병목에 걸리지 않기를 바람

  • 사람들은 엣지에 있어야 하고, 사용자 가까이에 있어야 하며, 지연시간을 줄여야 한다고 함
    실제로 지연시간이 얼마나 큰 문제일까?
    독일 서버에서 운영하는 책 추천 프로젝트 Gnooks가 예시임: https://www.gnooks.com
    누군가에게 너무 느리게 느껴지는지 궁금함
    지난 몇 년간 이 프로젝트에서 사용자 제안을 수천 건 받았지만, 기억하기로는 지연시간을 주제로 꺼낸 사람은 없었음. 가장 큰 사용자 그룹은 미국인데도 그랬음

    • 이 사이트는 로직 대부분을 백엔드에 두고, 사용자 상호작용마다 서버 왕복을 한 번만 함
      그래서 로직 대부분을 프런트엔드에 구현한 뒤 필요한 데이터를 불러오려고 백엔드에 여러 질의를 보내는 요즘식 PWA보다 지연시간 문제를 훨씬 덜 겪음
    • 호주에서 보면 빠른 로컬 사이트는 아니라는 게 느껴짐. 느린 로컬 사이트이거나 빠른 해외 사이트처럼 보일 수 있고, 핑은 약 300ms라 예상 가능한 수준임
      그래도 사이트 자체는 괜찮음. 이미 느린 사이트라면 그때 문제가 됨
    • 호주에서 VPN으로 인터넷을 써 보면 됨
      유럽에서 그렇게 하면 호주 사용자가 보는 지연시간의 2배 정도가 나와서 최악의 경험을 가늠하는 데 도움이 됨
    • 하노이에서는 예상보다 나음. 초기 DNS+TLS부터 페이지 로드까지는 여전히 1초 이상 걸리지만, 이후 요청은 예상대로 더 낫고 적어도 1초 미만임
    • 오래된 질문들이 대개 그렇듯 상황에 따라 다름
      좋은 점은 이걸 신뢰성 있게 테스트해서 실제로 중요한지 확인할 수 있다는 것임. 그러면 구체적인 답이 나옴

  • 글은 가용성을 아예 다루지 않음. 단일 박스에서 도는 서비스는 계획된 다운타임과 예기치 못한 다운타임이 모두 생김
    RPO/RTO도 생각해야 함. 박스가 터질 때, 아니 터지면, 복구에 얼마나 걸리고 데이터를 얼마나 잃을지 봐야 함
    페이지 렌더링에 데이터베이스 질의가 하나라도 있으면 us-east-1의 DB로 돌아가야 한다는 문장에 대해서는 이런 선택지도 있음:
    https://aws.amazon.com/rds/aurora/global-database/
    https://aws.amazon.com/dynamodb/global-tables/
    https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Conce...
    https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/...
    비슷한 것들이 더 많고, 같은 걸 직접 얼기설기 맞추려면 고생할 것임

    • 요즘은 가용성이 과대평가된 편이라고 봄
      10~20년 전이라면 동의했을 것임. 인터넷이 새로웠고 사이트가 내려가면 사람들이 사이트를 탓했으며 상황이 빠르게 험악해졌음. 하지만 지금은 인터넷 제공자를 먼저 탓하거나 나중에 다시 시도할 가능성이 더 큼
      모두가 Google인 것도 아니고, 더 단순한 시스템은 애초에 실패할 가능성도 낮음. 백업을 유지하고 정말 걱정된다면 DB를 콜드 재해복구 사이트로 복제하면 됨. FAANG이 아닌 대부분의 기업과 상황에는 충분함
      데이터만 잃지 않으면 많은 기업에게는 짧은 깜빡임으로 끝남. 홍보가 좋고 아주 드문 사건이라면 며칠 다운도 견딜 수 있으며, 경우에 따라 데이터 손실도 버틸 수 있음
      신뢰성의 9 하나를 추가할 때마다 비용이 두 배가 된다는 말이 있었는데, ROI를 따질 때 반드시 반영해야 함. 비즈니스가 실제로 얼마나 신뢰성을 필요로 하는지는 목표 시장에 달려 있고, IT의 기본 답인 자동 100% 는 틀렸다고 봄
    • 직접 물리 서버에서 돌리면 링크된 제품들보다 지연시간을 크게 줄이고 I/O 대역폭을 높일 수 있음
      단일 서버나 이중 서버 모델은 복잡성도 훨씬 낮고, 그래서 LetsEncrypt 같은 운영팀도 전 세계 서비스를 웹스케일로 돌리기 위해 이런 이중 물리 서버 아키텍처를 선택함: https://letsencrypt.org/2021/01/21/next-gen-database-servers...
      서버 내부 DB나 바로 옆 DB의 매우 낮은 내부 지연시간 덕분에 소프트웨어가 DB 질의를 몇 자릿수 빠르게 실행하고 사용자당 자원도 덜 쓰며, 실제 관리형 DB 서비스보다 더 빠릿한 사용자 경험을 줄 수 있음
    • AWS나 비슷한 곳에서 돌리는 서비스도 다운타임은 생김
      복잡성은 자체 함정을 만들고, 이걸 한 번도 망치지 않은 웹서비스는 없다고 봄. AWS 자체가 사고를 내는 경우도 있음
    • AWS에서도 큰 가용성 문제는 생김
      VPS가 여기서 더 나쁘다고 볼 수는 없음
답변달기