하루에 1 천만 건의 요청과 mySQL 쿼리를 처리하려면 어떤 종류의 서버가 필요합니까? [닫은]

저는 서버 관리의 초보자이며 새로운 웹 사이트를 호스팅 할 강력한 호스팅 서비스를 찾고 있습니다. 이 웹 사이트는 기본적으로 모바일 온라인 게임의 백엔드이며 다음과 같습니다.

• 하루 최대 1 천만 건의 HTTPS 요청 및 mySQL 쿼리 처리
• 하드 디스크에 최대 2000GB 파일 저장
• 매월 5000GB의 데이터를주고받을 것
• PHP와 mySQL에서 실행됩니다.
• mySQL 데이터베이스에 천만 개의 레코드가 있으며 각 레코드마다 5-10 개의 필드가 있으며 약 100 바이트

이러한 요구 사항을 처리하는 데 어떤 종류의 서버가 필요한지 잘 모르겠습니다. 제 질문은 다음과 같습니다.

1. 전용 서버 또는 VPS에 필요한 CPU / RAM은 무엇입니까?
2. 어떤 종류의 호스팅 회사에서 이러한 종류의 전용 서버 또는 VPS를 제공 할 수 있습니까?
3. 클라우드 컴퓨팅은 어떻습니까? Amazon EC2를 연구했지만 복잡해 보입니다. 나는 Rackspace에 연락했지만 이상하게도 Cloudsites는 내 요구 사항에 적합하지 않다고 말했습니다. 다른 클라우드 호스팅 회사가 있는지 궁금합니다.
4. 다른 대체 방법이 있습니까?

저렴한 데스크탑?

수학에 들어 갑시다.

• 1,000 만 건의 요청.
• 이는 시간당 416667 개의 요청으로 분류됩니다.
• 분당 6944 개의 요청으로 분류됩니다.
• 초당 116 개의 요청으로 분류됩니다.

두 배로 (피크로드), 우리는 쿼리가 충분히 단순하고 실제로 얼마나 복잡한 지 말하지 않는 저렴한 쿼드 코어 데스크탑이 처리 할 수있는로드에 대해 이야기합니다.

• 한 달에 5000GB는 사소한 일입니다. 진지하게 동일한 수학이 적용됩니다.
• 그것은 하루에 208GB로 나뉩니다.
• 시간당 8GB로 분류됩니다.
• 분당 148MB로 분류됩니다.

• 2,5MB / 초, 25Mbit로 나뉩니다. 피크-50Mbit의 경우 두 배, 모든 호스팅 센터에 대한 사소한. 그래도 비용이 듭니다.

• 하드 디스크에 2000GB를 저장하십시오. RAID의 2x2000GB 하드 디스크입니까? 그렇지 않은 경우 : 데이터베이스, 복잡한 IO가 많은 경우 I / O를 얻기 위해 RAID 10 (약 60 디스크)에 수십 개의 디스크와 73GB 15.000RPM SAS 디스크가 많이 있습니다. 데이터 액세스 패턴에 대한 많은 정보가 없으면 질문에 대답 할 수 없습니다.

• PHP와 MySQL을 실행-내 휴대 전화는 할 수 있습니다;) 문제는 응용 프로그램의 복잡성입니다. MySQL은 여기에서 수용 가능한 솔루션이 아닐 수도 있습니다. BTW l. -더 많은 테스트가 필요합니다. 일부 사람들이 여전히 다른 더 큰 상용 데이터베이스를 사용하는 이유가 있습니다.

• 전용 서버 또는 VPS에 필요한 CPU / 램은 무엇입니까?

논리 (PHP 부분의 계산량, 똑똑 함 또는 프로그래머 부족 및 기타 많은 질문)에 달려 있다고 말할 수 있습니다.

정말, 이것은 사소한 설정입니다. 일부 전문가가 조사하도록하십시오.

기본적으로 숙제를 끝내야합니다. 이 형식에서는 많은 질문에 대답 할 수 없습니다. 특히 데이터에 신경 쓰지 않는 것 같아서 ...

• 백업?
• 비상 계획이 없습니까? 서버가 죽어서 교체가 구성되어있는 동안 며칠 동안 사이트를 다운해도 괜찮습니까?

도움이 될만한 경험을 추가하려면 :

• TomTom이 언급했듯이 응용 프로그램의 설계 및 구현에 따라 많은 사양을 제공하는 것이 어렵거나 불가능합니다. 나 또는 다른 사람에게 X 요청 / 초를 제공하는 하드웨어가 제대로 작동하지 않을 수 있습니다.
• CPU 유휴 속도가 90 % 인 초당 평균 100 회 요청 (1 천만 건에 근접)을 제공하는 저가형 전용 MySQL 서버 (Intel Core2 Duo E4600 2.40GHz, 4GB RAM)가 있습니다. 구성에 대한 몇 가지 기본 조정 외에 읽기 읽기 (+ 95 % 읽기)로 인해 제대로 실행되고 활성 레코드 세트가 메모리에 쉽게 포함됩니다. 큰 차이를 만들 수 있으므로 서버 RAM의 양을 선택할 때 활성 세트의 크기를 고려하십시오. 데이터베이스 크기와 활성 레코드 세트 크기의 차이를 이해해야합니다. 예를 들어, 내 데이터베이스는 총 7GB이지만 활성 집합은 100MB에 불과합니다.
• 마찬가지로, 하루에 ~ 백만 건의 요청을 처리하는 유사한 사양의 Apache 서버가 있으며 평균 ~ 95 %의 CPU 유휴 속도를 갖습니다. 요청은 매우 간단한 맵 데이터 AJAX 쿼리와보다 복잡한 MediaWiki 페이지의 혼합입니다.
• 특정 응용 프로그램을 벤치마킹하는 것은 필요한 것을 정확하게 결정하기위한 좋은 시작입니다. 과소 평가를 원하지는 않지만 잠재적 낭비와 노력으로 인해 과도한 추정이 나빠질 수 있습니다.
• 평균 요청 속도뿐만 아니라 최대 속도를 고려하십시오. 요청 속도가 하루, 주 및 월에 따라 크게 다를 수 있기 때문에 평균 속도를 거의 처리 할 수없는 서버를 원하지 않습니다. 예를 들어, 주중에 최소 시간으로하는 것처럼 주말에 피크 시간에 트래픽을 3-4 배 얻을 수 있습니다. 그 차이는 응용 프로그램과 사용자 기반에 따라 다릅니다.
• 데이터베이스 / HTTP 요청을 캐시 할 수 있습니까? 캐시 할 수있는 양에 따라 저렴하고 적은 하드웨어로 요청 속도를 크게 높일 수 있습니다.
• 나중에가 아니라 미래 성장을위한 확장 옵션을 고려하십시오. 좋은 방법은 최소 하드웨어로 시작하여 필요에 따라 쉽게 확장 할 수있는 수평 확장을 사용하는 것입니다.
• 응용 프로그램 계층의 올바른 디자인은 궁극적 인 성능에 큰 영향을 줄 수 있습니다. 인덱스가없는 테이블에서 잘못된 SQL 쿼리는 제대로 설계된 것보다 훨씬 느릴 수 있습니다. 마찬가지로, 잘못 구성된 Apache / MySQL 서버는 올바르게 설정할 때보 다 여러 배 더 느릴 수 있습니다.