Google App Engine FAQ

Google App Engine 계정에 어떻게 로그인하나요?

Gmail 사용자를 포함한 일반적인 Google 계정의 경우 Google Cloud Platform 콘솔을 방문하여 App Engine 계정에 로그인할 수 있습니다.

App Engine용 Cloud 프로젝트를 어떻게 만드나요?

Google Cloud Platform 콘솔을 사용하여 Cloud 프로젝트를 생성합니다.

Google App Engine에서는 어떤 언어를 지원하나요?

현재 Google App Engine 표준 환경에서는 자바, Python, PHP, Go를 지원합니다. 또한 웹사이트 템플릿에는 HTML과 함께 AJAX 지원 웹 애플리케이션을 작성할 수 있는 자바스크립트가 있을 수 있습니다.

App Engine은 어떤 인증을 받았나요?

Google App Engine은 SAS70 Type II, SSAE 16 Type II, ISO 27001, ISAE 3402 Type II 표준의 감사 과정을 성공적으로 완료하였습니다.

내가 만든 프로젝트에 어떤 권리를 행사할 수 있나요?

Google 고객과 App Engine 고객은 자신이 저장한 데이터와 애플리케이션 및 프로젝트 코드에 관한 모든 지적재산권을 소유합니다. Google은 App Engine 및 Google Cloud Platform의 서비스와 소프트웨어에 관한 모든 지적재산권을 소유합니다.

이러한 용어의 정의를 비롯한 더 자세한 내용은 Google Cloud 서비스 약관을 참조하세요.

Google App Engine은 어떤 프레임워크를 지원하나요?

자바

App Engine의 자바 런타임은 Struts 2나 Spring MVC를 비롯한 여러 대중적인 자바 프레임워크에서 작동합니다. 또한 App Engine은 JRuby나 Scala 같은 대중적인 JVM 호환 언어를 지원합니다. 모든 프레임워크는 App Engine의 샌드박스 제한 범위 내에서 작동해야 하고 JRE 클래스 허용 목록에 있는 JRE 클래스만 사용해야 합니다.

Python

App Engine은 대부분의 Python 웹 프레임워크를 거의 또는 전혀 수정하지 않고 바로 실행할 수 있습니다. Google App Engine에서 Python Flask 스켈레톤을 사용하는 방법을 보여주는 GitHub 예제를 사용할 수 있습니다. 타사 라이브러리에 관한 문서에서 더 자세한 내용을 확인할 수 있습니다.

Go

App Engine용 Go 런타임은 net/http 패키지를 포함한 거의 모든 표준 라이브러리를 포함하므로 모든 웹 앱을 작성하는 데 충분합니다. 상당수의 타사 라이브러리가 수정 없이도 App Engine에서 작동합니다.

커스텀 런타임

가변형 환경을 사용하여 커스텀 런타임을 만들고 소프트웨어 스택에 다른 프레임워크를 설치할 수 있습니다.

계정이 없어도 Google App Engine 앱을 개발할 수 있나요?

물론입니다. Google App Engine 계정이 아직 없더라도 언제든지 Google SDK를 다운로드하여 개발을 시작할 수 있습니다.

Google App Engine으로 애플리케이션을 몇 개 만들 수 있나요?

사용 중인 리소스와 Google Cloud Platform의 과거 사용 이력 등 다양한 요인에 따라 만들 수 있는 App Engine 프로젝트의 개수가 결정됩니다. 고객마다 이러한 요인과 기타 다른 요인에 따라 할당량이 서로 다를 것입니다.

고객이 프로젝트 제한을 초과하려고 할 경우 GCP 콘솔에서 요청서 양식을 작성하라는 메시지를 표시합니다. 프로젝트를 만들려고 하는데 이미 할당량에 도달한 경우에 이러한 메시지가 표시됩니다. 필요한 추가 프로젝트의 개수와 해당 이메일 계정, 청구 계정, 사용 목적을 이 양식에 표기해야 합니다.

할당량 상향 요청에 관한 자세한 내용은 프로젝트 할당량 요청 페이지에서 확인할 수 있습니다.

Google App Engine에서는 어떤 유형의 콘텐츠가 허용되나요?

Google App Engine에서 어떤 유형의 콘텐츠가 허용되는지 궁금하다면 Google 서비스 약관을 참조하세요.

/favicon.ico에서 URI 오류가 생기는 이유는 무엇인가요?

favicon.ico 파일이 포함되어 있지 않은 애플리케이션은 오류가 발생할 수 있는 URI 목록에 URI /favicon.ico가 포함되어 있을 수 있습니다. Favicon.ico는 사용자의 웹 브라우저가 페이지를 로드하려고 시도할 때 요청하는 파일입니다. Favicon.ico는 웹사이트의 아이콘으로, 일반적으로 사용자의 브라우저 URL 표시줄에서 사용자 사이트의 웹 주소 옆에 표시됩니다.

애플리케이션의 경우 favicon.ico는 정적 이미지입니다. 애플리케이션에 favicon.ico 파일을 업로드한 후 app.yaml 파일에서 url /favicon.ico가 요청될 때 애플리케이션이 해당 이미지를 제공하도록 구성할 수 있습니다. appengine-web.xml(자바)과 app.yaml(Python/PHP/Go)의 예시 항목을 아래에 제시하였습니다. Python/PHP/Go의 예에서 favicon.icostatic/images에 있습니다. 여기에서는 편의상 자바의 예제에도 루트(war) 디렉토리에 동일한 파일이 있습니다.

Python/PHP/Go

app.yaml
- url: /favicon\.ico
  static_files: static/images/favicon.ico
  upload: static/images/favicon\.ico

자바

appengine-web.xml
<static-files>
  <include path="/favicon.ico" />
</static-files>

GQL이란 무엇인가요?

GQL은 Datastore에 사용되는 쿼리 언어입니다. Python 앱에서 항목의 쿼리에 GQL을 사용할 수 있습니다. GQL은 SQL과 유사한 구문을 사용하여 애플리케이션 Datastore의 전체 항목을 검색하며, 속성에 필터를 적용하고 결과의 정렬 순서를 지정하고, 반환되는 항목의 개수를 제한하는 기능이 있습니다. 전체 GQL 언어 참조는 여기에서 확인할 수 있습니다.

자바에서 GQL을 사용할 수 있나요?

GQL은 자바 SDK에 포함되어 있지 않지만 Cloud Datastore API를 통해 사용할 수 있습니다. 자바 개발자들은 GQL 대신 유형에 구애받지 않는 JDOJPA를 사용하는 것이 좋습니다. JDO/JPA를 사용하면 개발자가 런타임이 아닌 IDE의에서 실수를 더 잘 파악할 수 있고 SQL 주입 공격의 여지가 더 적습니다.

쿼리에 색인을 적용해야 하는 이유는 무엇이며, 이를 어떻게 포함시키나요?

여러 항목 속성에 필터를 적용하거나 여러 속성을 기준으로 결과의 순서를 결정하는 쿼리를 실행할 경우 해당 쿼리에 색인이 필요합니다. 애플리케이션에서 실행하는 이러한 유형의 모든 쿼리에는 색인이 있어야 합니다. 쿼리의 Datastore 색인은 Datastore의 데이터에 신속하게 액세스할 수 있도록 쿼리가 지정하는 방식으로 정렬된 키 목록을 유지하고 업데이트합니다. Datastore 색인에 관한 전체 설명은 Google 문서(자바 | Python | Go)에서 확인할 수 있습니다.

Google App Engine SDK로 애플리케이션을 개발할 경우 실행하는 모든 쿼리에 필요할 때마다 자동으로 색인이 적용됩니다. 애플리케이션을 웹사이트에 업로드하기 전에 전체적으로 테스트할 경우 애플리케이션에 필요한 모든 색인이 애플리케이션의 datastore-indexes.xml(자바) 또는 index.yaml(Python 또는 Go) 파일에 포함됩니다. 개발 테스트 시 누락된 쿼리를 발견했다면 직접 색인을 추가할 수 있습니다. 애플리케이션에 색인을 작성하는 방법에 관한 자세한 내용은 색인 문서를 참조하세요.

내 색인이 왜 오류로 표시되었나요?

색인이 과도 색인(Python | 자바 | Go)이거나, 데이터 저장소에 특정 항목을 작성할 때 기타 유사한 문제가 발생했을 것입니다. 쿼리(Python | 자바 | Go)와 색인(Python | 자바 | Go)의 지침에 따라 색인을 삭제하고 다시 빌드해보세요.

색인이 오랫동안 빌드 중 또는 삭제 중 상태로 있는 이유는 무엇인가요?

해당 종류의 항목이 많지 않더라도, 색인이 빌드되거나 삭제되는 데 걸리는 시간은 특히 Datastore에 있는 데이터의 총량, 현재 다른 앱에 빌드하고 있는 색인, 사용자 요청으로 인한 Datastore 부하에 따라 크게 다를 수 있습니다. 색인 작업을 완료하는 데 몇 시간이나 며칠씩 걸리는 경우도 있습니다.

그렇기는 하지만 중단된 것으로 보이는 색인과 관련하여 Google에서 도움을 줄 수 있는 경우도 있습니다. 색인에 이러한 문제가 발생했다고 생각되는 경우 google-appengine 그룹에 질문을 게시하세요.

내 애플리케이션의 사용자를 어떻게 인증하나요?

사용자 서비스(자바 | Python | Go)에서 Google 계정, 즉 자신의 G Suite 도메인에 있는 계정을 가진 사용자를 인증할 수 있습니다. 앱에 이러한 인증 방식 중 하나를 선택하세요.

앱에서 Google 계정을 사용할 경우 애플리케이션이 사용자 로그인을 요청하면 사용자는 Google 로그인 페이지로 안내되고 사용자 이름과 비밀번호를 입력하거나 새 계정을 만듭니다. 로그인에 성공하면 사용자는 고객의 웹사이트로 다시 돌아가고, 사용자 정보는 사용자 속성을 통해 앱에 제공됩니다.

Google App Engine에서 지원하지 않는 타사 라이브러리가 있나요?

자바

호환 및 비호환 라이브러리와 프레임워크의 목록은 JRE 클래스 허용 목록을 참조하세요.

Python

소수의 네이티브 C python 모듈과 일부 네이티브 C python 모듈은 Google App Engine에서 사용할 수 없습니다. 이러한 모듈은 다음과 같은 범주에 속합니다.

  • 디스크의 데이터베이스를 유지하는 라이브러리는 Google App Engine용 Python에서 사용 설정되지 않습니다.
  • 시스템이 하위 프로세스의 호출을 허용하지 않으므로 일부 모듈 OS 메소드가 사용 중지됩니다.
  • 스레딩을 사용할 수 없습니다.
  • 보안을 위해 대부분의 C 기반 모듈이 사용 중지됩니다.
  • 제한되는 기타 기능:
    • marshal이 사용 중지됩니다.
    • cPickle의 별칭이 pickle로 지정됩니다.
    • 시스템 호출이 사용 중지되었습니다.

위의 기능 중 하나를 사용하는 타사 패키지(PostgreSQL 등과 같은 패키지)는 Google App Engine에서 작동하지 않는다는 점에 유의하세요.

Go

순수 Go 패키지의 대다수는 Google App Engine에서 작동합니다. 패키지가 작동하지 않는 이유는 다음 중 하나일 것입니다.

  • 패키지가 syscall 또는 unsafe를 가져옵니다.
  • 패키지가 cgo 또는 어셈블리를 사용합니다.
  • 패키지의 기능이 잠겨 있어야 합니다(예: 디스크에 쓰기 또는 직접 네트워크 액세스).

내 앱이 왜 사용 중지되었나요?

앱이 Google의 이용약관을 준수하지 못할 경우 사용 중지될 수 있습니다. 또한 버그나 기타 문제로 인해 애플리케이션이 시스템 리소스를 과도하게 많이 사용하여 리소스 사용량이 비효율적인 것으로 확인될 경우 Google App Engine에서 애플리케이션을 다시 사용 설정하기 전에 개발자가 Google의 개발 SDK를 사용하여 개발 문제를 해결할 수 있도록 해당 앱을 사용 중지할 수 있습니다.

내 앱의 할당량이 왜 초과되었나요?

App Engine은 애플리케이션이 하루에 사용할 수 있는 각 시스템 리소스의 양에 할당량 제한을 두고 있습니다. 모든 애플리케이션은 애플리케이션의 효율성을 위해 한 달에 약 5백만 페이지뷰를 허용하는 '무료 할당량'이라는 기본 할당량 구성을 제공받습니다. 할당량 문서에서 시스템 할당량에 관한 더 자세한 내용을 확인할 수 있습니다.

애플리케이션이 커지면서 기본 할당량 구성에서 제공하는 것보다 더 많은 리소스 할당량이 필요할 것입니다. 애플리케이션에 결제를 사용 설정하여 컴퓨팅 리소스를 추가로 구입할 수 있습니다. 결제를 사용하면 개발자가 모든 시스템 리소스에 적용되는 한도를 높이고 CPU, 대역폭, 저장 공간, 이메일 사용량에 훨씬 더 높은 한도를 적용하여 유료로 사용할 수 있습니다.

Google의 이용약관에 위배되는 애플리케이션을 어떻게 신고하나요?

Google App Engine 이용약관에 위배되는 애플리케이션을 신고하려면 Google에 문의하세요. Google에서 애플리케이션이 약관에 위배되는지 결정한 후 필요 시 해당 위반 사항과 관련하여 애플리케이션 개발자에게 연락할 것입니다.

외부의 요청에 응답할 때 SDK를 사용하는 것이 좋은가요?

dev_appserver는 로컬 테스팅을 위해 설계된 것으로, 기본적으로 외부 연결을 허용하지 않습니다. 실행 시 --host <hostname> 플래그를 사용하여 이 설정을 재정의할 수 있으나, SDK는 보안이 강화되어 있지 않아서 취약점이 있을 수 있으므로 이 방법은 권장되지 않습니다.

압축된 콘텐츠는 어떻게 제공하나요?

Google App Engine은 gzip 콘텐츠를 지원하는 브라우저에 gzip 콘텐츠를 제공하기 위해 최선을 다하고 있습니다. 이 방식은 자동으로 사용되며 애플리케이션을 수정할 필요가 없습니다.

Google은 요청 헤더(Accept-Encoding, User-Agent)와 응답 헤더(Content-Type)의 조합을 사용하여 최종 사용자가 gzip 콘텐츠를 이용할 수 있는지 여부를 판단합니다. 이러한 방법은 일반 브라우저에서 잘 알려진 gzip 콘텐츠 관련 버그의 일부를 예방해줍니다. gzip 콘텐츠를 강제로 처리하도록 하려면 클라이언트가 Accept-Encoding과 User-Agent 요청 헤더의 값 모두에 'gzip'을 지정하면 됩니다. Accept-Encoding 헤더가 존재하지 않으면 콘텐츠가 절대 gzip으로 압축되지 않습니다.

이에 대한 자세한 내용은 런타임 환경 문서에서 확인할 수 있습니다(Python | 자바 | PHP | Go).

Google App Engine에서 SSL(HTTPS)을 지원하나요?

Google App Engine에서는 appspot.com 도메인을 통해 SSL(HTTPS) 트래픽을 제공할 수 있습니다. 안전한 트래픽을 제공하려는 URL의 app.yaml 핸들러에 '안전한' 매개변수를 추가하기만 하면 됩니다. 애플리케이션이 안전한 트래픽을 제공하도록 구성하는 방법에 관한 자세한 내용은 앱 구성에 관한 문서를 참조하세요(자바 | Python | PHP | Go).

커스텀 도메인을 사용하여 SSL(HTTPS) 트래픽을 제공할 수도 있습니다. SSL이 설정된 커스텀 도메인을 사용할 경우 네이키드 도메인을 사용해도 됩니다.

내 프로젝트에 Strict-Transport-Security 헤더를 사용할 수 있나요?

App Engine에서 Strict-Transport-Security를 사용할 수 있습니다. 앱에 HTTP Strict-Transport-Security 헤더(HSTS)를 추가하려면 이 헤더를 앱의 구성 파일(app.yaml 또는 appengine-web.xml)이 아니라 앱의 코드 내부에 구현해야 합니다.

App Engine에서 내 커스텀 도메인에 SSL(HTTPS)을 사용할 수 있나요?

커스텀 도메인을 통해 SSL을 제공할 수 있습니다.

appcfg와 같은 도구가 SSL(HTTPS)을 사용하나요?

로그인을 사용하는 SDK 도구(appcfg, remote_api, appengine_rpc)는 모두 이메일 주소와 비밀번호를 전달할 때 SSL을 사용합니다.

Python과 Go SDK에는 원격 연결을 통해 SSL 인증서의 유효성을 검사하는 기능이 있습니다. 이를 위해서는 시스템에 ssl Python 모듈이 설치되어 있어야 합니다. Python 2.5를 사용하고 있다면 http://pypi.python.org/pypi/ssl/에서 해당 모듈을 설치할 수 있습니다. SSL 인증서의 유효성을 검사하는 도중 오류가 있으면 InvalidCertificateException이 발생하고 문제에 대한 설명이 표시됩니다.

자바 SDK도 기본적으로 SSL을 사용 설정합니다. SSL 인증서의 유효성을 검사하는 도중 오류가 발생하면 자바 SDK에서 javax.net.ssl.SSLHandshakeException을 생성합니다.

내 앱을 네이키드 도메인(예: http://example.com)에 매핑하고 싶습니다.

'네이키드 도메인'을 사용하면 사용자가 하위 도메인(예: http://www.example.com 또는 http://myapp.example.com) 없이 도메인 이름(http://example.com)에서 직접 앱에 액세스할 수 있습니다. Google Cloud Platform 프로젝트 콘솔에서 네이키드 도메인으로 App Engine 앱을 설정할 수 있습니다. 커스텀 도메인 사용을 참조하세요.

SSL이 설정된 커스텀 도메인을 사용하는 경우에도 네이키드 도메인이 지원됩니다.

정적 IP 주소와 App Engine 앱

App Engine은 현재 애플리케이션에 정적 IP 주소를 매핑하는 방법을 제공하고 있지 않습니다. 여러 ISP나 지리적 위치에 있는 여러 최종 사용자는 최종 사용자와 App Engine 애플리케이션 간의 네트워크 경로를 최적화하기 위해 동일한 App Engine 애플리케이션에 액세스할 때 서로 다른 IP 주소를 사용합니다. DNS는 시간이 흐름에 따라, 또는 여러 네트워크 위치에서 App Engine에 액세스하기 위해 서로 다른 IP 주소를 반환할 수 있습니다.

URL 가져오기, Socket, Mail API와 같은 아웃바운드 서비스는 대규모 IP 주소 풀을 사용합니다. 이러한 풀의 IP 주소 범위는 계속 변합니다. 실제로, 동일한 애플리케이션에서 연달아 실행된 2개의 API 호출은 서로 다른 2개의 IP 주소에서 시작된 것처럼 보일 것입니다.

현재 App Engine의 발신 IP 주소 범위는 _cloud-netblocks.googleusercontent.com의 발신자 정책 프레임워크(SPF) 레코드에 인코딩되어 있습니다. IP 범위의 전체 목록을 확인하려면 DNS SPF 조회를 재귀적으로 수행해야 합니다. 다음과 같이 _cloud-netblocks.googleusercontent.com을 확인하는 것부터 시작하세요.

nslookup -q=TXT _cloud-netblocks.googleusercontent.com 8.8.8.8

이 쿼리에서 반환되는 응답에는 App Engine의 현재 _cloud-netblocks가 모두 포함됩니다. (이 결과는 정적이지 않다는 점에 유의하세요. 즉, Google은 언제든지 새 _cloud-netblocks 항목을 도입할 수 있습니다.) 예를 들어 이 쿼리는 다음을 반환할 수 있습니다.

Non-authoritative answer:
_cloud-netblocks.googleusercontent.com	text = "v=spf1 include:_cloud-netblocks1.googleusercontent.com include:_cloud-netblocks2.googleusercontent.com include:_cloud-netblocks3.googleusercontent.com ?all

이와 같은 쿼리 응답에서 사용자는 이 응답으로 반환된 각각의 _cloud-netblocksN을 쿼리합니다. _cloud-netblocksN 항목이 3개인 앞의 응답 예시의 경우 사용자는 모든 IP 범위를 확인할 때 다음과 같은 3개의 쿼리를 실행합니다.

nslookup -q=TXT _cloud-netblocks1.googleusercontent.com 8.8.8.8
nslookup -q=TXT _cloud-netblocks2.googleusercontent.com 8.8.8.8
nslookup -q=TXT _cloud-netblocks3.googleusercontent.com 8.8.8.8

위의 각 항목의 쿼리에서 반환된 SPF 레코드가 App Engine 발신 트래픽에 사용할 수 있는 IP 범위입니다. 예를 들어 위의 _cloud-netblocks1의 쿼리 결과로 다음이 반환됩니다.

Non-authoritative answer:
_cloud-netblocks1.googleusercontent.com	text = "v=spf1 ip4:8.34.208.0/20 ip4:8.35.192.0/21 ip4:8.35.200.0/23 ip4:108.59.80.0/20 ip4:108.170.192.0/20 ip4:108.170.208.0/21 ip4:108.170.216.0/22 ip4:108.170.220.0/23 ip4:108.170.222.0/24 ?all"

이 예에서는 App Engine 트래픽에 8.34.208.0/208.35.192.0/21 IP 범위를 사용할 수 있음을 알 수 있습니다.

정적 IP 주소 필터링은 안전하고 효과적인 보호 방법으로 간주되지 않는다는 점에 유의하세요. 예를 들어 공격자는 사용자의 애플리케이션과 동일한 IP 주소 범위를 공유할 수 있는 악성 App Engine 앱을 만들 수 있습니다. Google에서는 이 방법 대신 OAuthCerts를 사용하는 심층 방어 접근법을 택할 것을 권장합니다.

내 애플리케이션에 크론 작업을 어떻게 정의하나요?

애플리케이션에 크론 작업을 정의하는 방법에 관한 내용은 언어별 문서를 참조하세요(자바 | Python | Go | PHP).

작업 대기열이란 무엇인가요?

작업 대기열은 나중에 처리할 새 요청을 동적으로 추가하는 메커니즘을 제공합니다. 앱은 백그라운드 작업을 실행해야 할 경우 Task Queue API를 사용하여 해당 작업을 Tasks라는 별도의 작은 여러 개의 단위로 구성할 수 있습니다. Tasks는 하나 이상의 대기열에 삽입됩니다. App Engine은 새 Tasks를 자동으로 감지하고 시스템 리소스가 허용하면 해당 Tasks를 실행합니다. 자세한 내용은 Task Queue API에 관한 문서를 참조하세요(자바 | Python | Go | PHP).

Google 그룹을 사용하여 내 App Engine 프로젝트에 대한 액세스 권한을 부여할 수 있나요?

App Engine 프로젝트에 Google 그룹을 추가할 경우 해당 그룹의 구성원은 해당 프로젝트 리소스(예: Datastore, 작업 대기열, Memcache 등)에 액세스할 수 있습니다.

사용자/서브넷이 내 앱에 액세스하지 못하게 막는 방법은 무엇인가요?

App Engine이 제공하는 DoS 보호 서비스를 사용하여 IP 주소나 서브넷을 차단할 수 있습니다. 자세한 내용은 DoS 보호 서비스에 관한 문서를 참조하세요(자바 | Python | Go | PHP).

내 앱의 애플리케이션 중단 및 액세스 문제에 관한 더 자세한 정보를 어디에서 얻을 수 있나요?

Google Cloud 상태 대시보드는 Google Cloud Platform을 구성하는 여러 서비스에 관한 상태 정보를 제공합니다.

중국의 경우 Google App Engine에 간헐적으로 액세스할 수 있을 것입니다. 중국 내 다른 Google 제품의 액세스 문제에 대해서는 Google 투명성 보고서를 참조하세요.

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

App Engine Documentation