GAE는 수백만 명의 활성 사용자가 사용하는 앱을 호스팅 할 수있는 인프라입니까?

아래에 나열된 GAE의 제한 사항을 알고 싶습니다 .GAE에서 해당 앱을 호스팅하여 Facebook과 같은 훌륭한 소셜 앱을 만들 수 있습니까?

다시 말해 GAE는 6 억 명의 활성 사용자가 사용하는 앱을 호스팅 할 수있는 인프라입니까?

몇 가지 포럼 / 블로그에서 삭제 한 제한 사항 (빠진 것이 있으면 목록에 자유롭게 추가하십시오).

1. HTTP 요청 / 응답

   • 최대 요청 크기 : 32MB
   • 최대 응답 크기 : 32MB
   • 모든 요청은 30 초 내에 응답해야합니다. 그렇지 않으면 GAE에서 DeadlineExceededException이 발생합니다.
   • 각 크론 작업은 10 분 이내에 실행되어야합니다.
   • 크론 작업은 맵 축소를 사용할 수 없습니다
   • 다른 사이트에 대한 모든 GET 또는 POST는 5 초 후에 중단됩니다. 최대 10 초까지 기다리도록 구성 할 수 있습니다. (트위터 및 페이스 북과 여러 번 작업하려면 중간 서버가 필요합니다)
   • 클라이언트는 FTP를 통해 GAE에 연결할 수 없습니다 (HTTP 및 HTTPS 만 해당).
   • 맞춤 도메인에 대한 https가 없습니다. your-app-id.appspot.com 도메인에만 해당합니다.
   • 사용자가 유입되면 "할당량 초과"오류가 발생합니다.

2. 데이터 베이스

   • 데이터베이스 개발은 로컬 서버에서 실제 서버와 동일하지 않습니다.
   • GQL. 다른 건 없어
   • 1000 개가 넘는 레코드를 검색 할 수있는 쿼리가 없습니다 (클라이언트가 한 번의 클릭으로 오프라인으로 전환 할 수 있도록하려면 심각하게 짜증납니다)
   • 작업을 수행하기 위해 대량의 레코드에 선형으로 액세스해야하는 경우 운이 나쁘다 (Google 시스템은 대량으로 클러스터 됨)
   • Memcache 값의 최대 크기는 1MB입니다.
   • 간단한 텍스트 검색을 할 수 없습니다
   • 2 개의 테이블을 조인 할 수 없습니다.
   • 느리게하기
   • "너무 많은 인덱스"런타임 예외
   • 엔티티는 최대 5000 개의 속성 값을 가질 수 있습니다
   • * (두 개의 밑줄로 시작하고 끝나는) 형식의 키 이름 은 예약되어 있으므로 응용 프로그램에서 사용해서는 안됩니다.
   • 키 이름은 500 바이트로 제한됩니다 (UTF-8로 인코딩되었습니다)

3. 언어

   • python 또는 java 또는 Go (또는 Groovy, Scala 등의 JVM을 사용하는 언어)

4. 서버 문제

   • 고정 IP가 없습니다 (타사 API 호출시 제한 및 할당량 문제가있을 수 있음)
   • 각 응용 프로그램은 3000 파일로 제한됩니다
   • 웹 앱을 실행하는 OS 또는 하드웨어를 제어 할 수 없음

이 질문에 대해 저를 괴롭히는 것은 당신이 그것을 말하고 결정적인 숫자를 모으기 위해 "사실"을 가지고 있다는 것입니다.

사실 Facebook, Twitter 또는 Tumblr의 기능을 복제하는 App Engine 앱을 개발할 수 있습니다. 그리고 앱이 제대로 작성되었다고 가정하면 수억 명의 사용자를 지원하도록 확장 될 수 있습니다. 원하지 않는 주된 이유는 App Engine에서 해당 크기의 서비스를 실행하는 비용입니다.

또한 나열된 제한 사항으로 인해 그러한 앱을 개발하지 못하는 방법을 알 수 없습니다.

1. HTTP 요청 / 응답

   • 최대 요청 크기 : 10MB-잘못된 32MB
   • 최대 응답 크기 : 10MB-잘못된 32MB

   -10MB보다 큰 페이지를 자주 전달해야하는 소셜 앱을 개발하는 경우 아마도 잘못된 것일 수 있습니다. 또한 32MB보다 큰 콘텐츠를 제공해야하는 경우 최대 2GB의 파일에 blobstore를 사용할 수 있습니다.

   • 파일 시스템에 액세스 할 수 없습니다. (파일 시스템에 업로드 저장을 잊어 버렸습니다)-잘못되었습니다. 로컬 파일 시스템에서 읽고 파일을 Blobstore에 업로드하고 읽고 쓸 수 있습니다.

   -Facebook, Twitter 또는 Tumblr가 사용자 업로드를 가져 와서 폴더로 복사하는 방법은 없습니다. 별일 아니다.

   • 모든 요청은 10 분 이내에 응답해야합니다. 그렇지 않으면 GAE에서 DeadlineExceededException-오류가 발생합니다. 실제로 30 초입니다.

   -사용자의 요청에 결과를 전달하기 위해 30 초 이상이 필요한 경우 잘못된 작업 일 수 있습니다.

   • 각 cron 작업은 30 초 이내에 실행되어야합니다. 10 분입니다.

   -긴 작업을 10 분 단위로 나눌 수없는 경우 A : 아마 잘못하고 B : 이제 해당 작업을 백엔드 인스턴스로 옮길 수 있습니다. 요청에는 시간 제한이 없습니다.

   • Cron 작업은 map reduce를 사용할 수 없습니다-사용한 map reduce는 없지만 인용이 필요하다고 생각합니다.

   • 다른 사이트에 대한 모든 GET 또는 POST는 5 초 후에 중단됩니다. 최대 10 초까지 기다리도록 구성 할 수 있습니다. (트위터와 페이스 북으로 여러 번 작업하려면 중간 서버가 필요합니다)-맞습니다.

   -외부 API에 대한 사용자의 요청이 10 초 이상 걸리는 경우 사용자에게 다시 시도하도록 지시하는 것이 좋습니다. 사용자 요청이 아닌 경우 API가 응답 할 때까지 작업을 자동으로 다시 시도 할 수 있습니다.

   • 클라이언트는 FTP를 통해 GAE에 연결할 수 없습니다 (HTTP 및 HTTPS 만 해당). - 진실

   -왜 이것이 문제입니까? 대규모 회사에서 FTP를 통해 변경 사항을 배포한다고 생각하십니까?

   • 맞춤 도메인에 대한 https가 없습니다. your-app-id.appspot.com 도메인에만 해당합니다. - 진실.

   -로드맵에 있습니다.

   • 사용자가 유입되면 "할당량 초과"오류가 발생합니다. 절반 만 참입니다.

   -앱 예산을 적절하게 설정하면 할당량 초과 오류가 발생하지 않습니다. Royal Wedding 사이트는 App Engine에서 호스팅되었으며 초당 32,000 건의 요청을 받았습니다. 초과 할당량 오류가 없습니다. 또한 트위터에서 실패 고래를 보거나 Tumblr에서 초과 용량 오류를 본 적이 있습니까? 본질적으로 할당량 초과 오류입니다.

2. 데이터 베이스

   • 데이터베이스 개발은 로컬 서버에서 실제 서버와 동일하지 않습니다. -거짓

   -랩톱에서 데이터 저장소를 실행하는 것이 App Engine의 클러스터에서 실행하는 것보다 느리면 true, 그렇지 않으면 true가 아닙니다.

   • GQL. 다른 건 없어 -거짓

   -대부분의 개발자는 db 필터를 사용하여 데이터 스토어를 쿼리합니다. 또한, MySQL은 "SQL. Nothing else"를 허용한다고 말할 수 있습니다.

   • 1000 개가 넘는 레코드를 검색 할 수있는 쿼리가 없습니다 (클라이언트가 한 번의 클릭으로 오프라인으로 전환 할 수 있도록하려면 심각하게 빠짐)-False.

   -1000 레코드 한도는 오래 전에 해제되었습니다. 또한 Facebook, Twitter 또는 Tumblr에서 렌더링하기 위해 1000 개 이상의 레코드가 필요한 사용자 관련 페이지를 표시하십시오.

   • 작업을 수행하기 위해 대량의 레코드에 선형으로 액세스해야하는 경우 운이 나쁘다 (Google 시스템은 대량으로 클러스터 됨)

   -당신이 여기서 무엇을 받고 있는지 잘 모르겠습니다. 대부분의 사람들은 Google의 대규모 클러스터 속도를 시스템의 큰 장점으로 생각합니다.

   • 최대 Memcache 값은 10MB입니다. -실제로 다른 모든 memcache 구현과 동일하게 memcache 항목 당 1MB입니다.

   • 간단한 텍스트 검색을 할 수 없습니다-True.

   -갑판에있는 기능입니다. 대부분의 대규모 사이트는 자체 텍스트 검색 인덱싱을 수행하지 않습니다.

   • 2 개의 테이블을 조인 할 수 없습니다. - 진실.

   -App Engine 개발자는 단일 대규모 다중 조인 SQL 쿼리에서 여러 개의 작은 개별 쿼리로 생각을 조정하거나 조인이 필요하지 않도록 데이터를 비정규 화해야합니다.

   • 느림

   -번역 / 인용 필요

   • "너무 많은 인덱스"런타임 예외-True

   -단일 앱의 인덱스 수에는 제한이 있습니다. 나는 학술 연구 응용 프로그램이 그것을 명중하는 것을 보았습니다.

   • 엔티티는 색인에 최대 5000 개의 특성 값을 가질 수 있습니다.-True

   -누군가 친구가 5000 명을 초과하면 친구 그룹에 두 개의 엔티티가 필요합니다.

   • 양식의 키 이름 __*__(두 개의 밑줄로 시작 및 끝)은 예약되어 있으므로 애플리케이션에서 사용해서는 안됩니다. - 진실

   -그런데 뭐?

   • 키 이름은 500 바이트로 제한됩니다 (UTF-8로 인코딩되었습니다)-True

   -다시, 그래서 무엇? 키 이름은 소설을 저장하기위한 것이 아니라 개체를 고유하게 식별하기위한 것입니다.

3. 언어

   • python 또는 java 또는 Go (다른 언어는이 언어로 번역해야 함)-절반 참

   -실제로 PHP 및 JRuby를 포함하여 JVM에서 실행되는 모든 언어를 실행할 수도 있습니다. 그래도 왜 문제인지 잘 모르겠지만 Python과 Java는 사용 가능한 도구, 자습서 및 숙련 된 프로그래머가 많은 강력한 두 언어입니다.

4. 서버 문제

   • 고정 IP 없음 (타사 API를 호출하는 조절 및 할당량 문제)-절반 참

   -대부분의 타사 API는 App Engine을 알고 있거나 Google과 관계가 있습니다. 트위터가 실수로 App Engine을 차단 한 후 몇 시간 내에 수정되었습니다.

   • 각 응용 프로그램은 3000 개 파일로 제한됩니다.

   -웹 응용 프로그램에 3000 개 이상의 코드 파일이 실제로 필요한 경우 zip 가져 오기를 사용할 수 있습니다 (또한 잘못된 작업 일 수 있음).

   • 웹 앱을 실행하는 OS 또는 하드웨어를 제어 할 수 없음-True

   -App Engine은 서비스 형 플랫폼 입니다. 사람들이 지불하는 OS 또는 하드웨어 서비스에 대해 걱정할 필요가 없습니다. 이것이 App Engine의 주요 장점이며 제한 사항은 아닙니다.

아니요, 6 억 명의 활성 사용자가있는 앱에는 App Engine이 적합하지 않습니다.

실제로이 앱은 자체 데이터 센터 외부의 고도로 맞춤화 된 인프라에서 실행됩니다. Google에서 이러한 앱을 호스팅하는 것이 가능할 수도 있지만 영업 팀과 직접 협력하여 솔루션을 디자인해야합니다. 위에 나열된 샌드 박스 제한 사항은 오랫동안 관련이 없습니다.

방금 시작한 경우 Facebook만큼 인기가 있다고 가정하는 것은 어리석은 일입니다. 이 크기가 큰 앱은 점진적으로 리팩토링을 통해 점진적으로 증가합니다. 첫째, 6 억 명의 사용자를 유치 할 기능을 설계하는 것에 대해 걱정하십시오. 증가하는 사용자 기반을 지원하도록 구현을 재 설계하는 것은 비교에있어 사소한 문제입니다.

FAQ의 요점은 몇 가지 주요 영역에 속한다고 생각합니다.

우선, 실제로 는 손해보다는 확장 성의 이점 에 있습니다. 확장 성이 뛰어난 애플리케이션에서 모든 요청이 다른 요청과 크게 독립적이며 CPU 사용량, 메모리, 네트워크 등의 측면에서 모두 동일한 "크기"를 유지하도록 노력하고 있습니다.

이렇게하면 동일한 노드에서 더 작은 요청을 고갈시키는 "대형"요청 그룹에 대해 걱정하지 않고 클러스터의 노드간에 요청을 쉽게 분배 할 수 있습니다. 유지 관리, 성능 및 안정성 측면에서 인프라를 단순하게 유지합니다.

그래서 그것은 다음과 같은 것들을 다룹니다.

• 최대 요청 / 응답 크기
• 응답 시간 요청
• 외부 요청 응답 시간 제한
• Memcache 최대 크기 (실제로 memcache의 기본 빌드에서 최대 값 크기는 1MB이므로 Google은 10 배로 제한하는 사용자 지정 바이너리를 실행하고 있음)
• 최대 데이터베이스 응답 크기 (예 : 1,000 행 제한)
• 기타

두 번째 범주는 단순히 오래된 것입니다.

• Google Go는 이제 App Engine에서 언어로 제공됩니다 . 고성능 언어면에서 Go보다 훨씬 나아지지는 않습니다. 나는 실제로 이것을 정말로 좋아합니다
• 데이터 스토어 실패- 높은 복제 데이터 스토어 에서는 사실이 아닙니다 (분명히 memcache는 실패 할 수 있지만 캐시 일뿐입니다)
• 파일 수의 제한은 1,000이 아닌 3,000입니다.

이제 크론 작업이 Map Reduce를 활용하고 전체 데이터 세트에 대해 쿼리를 실행할 수 있도록 인프라를 열면 좋을 것입니다. 그러나 시간에 당신도 상당한있어 일부 600,000,000 사용자가 이미 구글의 매우 큰 고객이 될거야 어쨌든 앱 엔진에서 사용할 수있는 것보다 더 많은 옵션을 가질 것이다.

6 억 명의 사용자는 물론 100 명까지 끌어들일 수있는 아이디어가 나오면 벤처 캐피탈과 기술 팀이 모든 인프라에서이를 개발하고 실행할 수 있습니다. 또한 Google은 모든 GAE 앱의 소스 코드에 액세스하기를 원하기 때문에 GAE가 제공하지 않는 지적 재산권도 보호하려고합니다.
GAE는 IT 인프라 비용을 없애고 코드 IP를 보호 할 필요가없고 데이터 만 보호하려는 기업에 적합합니다.