참고: Python 2.7은 2024년 1월 31일 지원 종료됩니다. 기존 Python 2.7 애플리케이션을 계속 실행하고 트래픽을 받을 수 있습니다. 그러나 지원 종료 날짜 이후에는 해당 런타임을 사용하는 애플리케이션의 재배포를 App Engine에서 차단할 수 있습니다. 지원되는 최신 Python 버전으로 마이그레이션하는 것이 좋습니다.

Cloud NDB로 마이그레이션

App Engine 위치

App Engine은 리전을 기반으로 합니다. 즉, 앱을 실행하는 인프라가 특정 리전에 위치해 있으며 해당 리전 내의 모든 영역에서 중복으로 사용할 수 있도록 Google이 관리합니다.

앱을 실행하는 리전을 선택하는 데 있어 중요한 기준은 지연 시간, 가용성 또는 내구성 요구사항입니다. 일반적으로 앱 사용자와 가장 가까운 리전을 선택할 수 있지만 App Engine을 사용할 수 있는 위치와 앱에서 사용하는 다른 Google Cloud 제품 및 서비스의 위치도 고려해야 합니다. 여러 위치에서 서비스를 사용하면 앱의 지연 시간과 가격 책정에 영향을 미칠 수 있습니다.

앱의 리전을 설정한 후에는 변경할 수 없습니다.

App Engine 애플리케이션을 이미 만든 경우 다음 중 한 가지 방법으로 해당 리전을 볼 수 있습니다.

gcloud app describe 명령어를 실행합니다.
Google Cloud 콘솔에서 App Engine 대시보드를 엽니다. 이 리전은 페이지 상단 근처에 표시됩니다.

Cloud NDB는 App Engine NDB를 대체하는 Python용 클라이언트 라이브러리입니다.

App Engine NDB는 Python 2 앱이 Datastore 모드의 Firestore(Datastore) 데이터베이스에서 데이터를 저장하고 쿼리할 수 있도록 합니다. Cloud NDB는 Python 3 앱에서 동일한 데이터베이스의 데이터를 저장하고 쿼리할 수 있고 Datastore를 해당 데이터베이스를 관리하는 제품으로 사용합니다. Cloud NDB 라이브러리는 App Engine NDB로 생성된 모든 데이터에 액세스할 수 있지만 Cloud NDB를 사용하여 저장된 일부 구조화된 데이터 유형은 App Engine NDB로 액세스할 수 없습니다. 따라서 Cloud NDB로 마이그레이션하면 되돌릴 수 없는 것으로 간주됩니다.

최신 버전의 Cloud NDB는 Python 3만 지원합니다. 이전 버전에서는 Python 2 및 Python 3가 모두 지원되었습니다. Python 2 애플리케이션을 Python 3로 마이그레이션하려면 다음을 수행하는 것이 좋습니다.

Cloud NDB 버전 1.11.2로 마이그레이션합니다. Python 2를 지원하는 최종 출시 버전입니다.
애플리케이션을 Python 3로 업그레이드합니다.
Cloud NDB의 최신 안정화 버전으로 업그레이드합니다.

이 점진적인 마이그레이션 방식을 통해 마이그레이션 프로세스 전반에 걸쳐 앱을 작동하고 테스트할 수 있는 상태로 유지할 수 있습니다.

Cloud NDB는 App Engine NDB에 익숙하고 애플리케이션을 현대화하려는 Python 개발자를 대상으로 합니다. Cloud NDB로 마이그레이션하면 Python 3용 Python 2 앱을 준비하는 데 도움이 되며 원할 경우 나중에 App Engine에서 완전히 이전할 수도 있습니다.

Cloud NDB에 대한 자세한 내용은 다음 페이지를 참조하세요.

App Engine NDB와 Cloud NDB 비교

유사점:

Cloud NDB는 App Engine NDB에서 지원되는 거의 모든 기능을 지원하며, 메서드 구문에 미묘한 차이만 있을 뿐입니다.

차이점:

App Engine Python 2.7 런타임 관련 서비스를 사용하는 App Engine NDB API는 Cloud NDB에서 업데이트되거나 삭제되었습니다.
Python 3 및 Django의 새로운 기능으로 인해 google.appengine.ext.ndb.django_middleware가 필요하지 않습니다. 대신 몇 줄의 코드만으로 손쉽게 미들웨어를 작성할 수 있습니다.
App Engine NDB에서는 앱과 Datastore 데이터베이스가 동일한 Google Cloud 프로젝트에 있어야 하며 App Engine이 사용자 인증 정보를 자동으로 제공합니다. Cloud NDB는 클라이언트를 제대로 인증하면 모든 프로젝트의 Datastore 모드 데이터베이스에 액세스할 수 있습니다. 다른 Google Cloud API 및 클라이언트 라이브러리와도 일치합니다.
Cloud NDB는 App Engine Memcache 서비스를 사용하여 데이터를 캐시하지 않습니다.

대신 Cloud NDB는 Memorystore, Redis Labs 또는 기타 시스템에서 관리하는 Redis 인메모리 데이터 저장소에서 데이터를 캐시할 수 있습니다. 현재 Redis 데이터 저장소만 지원되지만 Cloud NDB는 추상적인 GlobalCache 인터페이스에서 캐싱을 일반화하고 정의했으며 이를 통해 구체적인 추가 구현을 지원할 수 있습니다.

Redis용 Memorystore에 액세스하려면 앱에서 서버리스 VPC 액세스를 사용해야 합니다.

Redis용 Memorystore와 서버리스 VPC 액세스 모두 무료 등급을 제공하지 않으며 이러한 제품은 앱 리전에서 제공되지 않을 수 있습니다. 자세한 내용은 마이그레이션을 시작하기 전에를 참조하세요.

차이점의 전체 목록은 Cloud NDB GitHub 프로젝트의 마이그레이션 참고 사항에서 확인할 수 있습니다.

코드 샘플:

Cloud NDB를 사용한 기본 데이터베이스 작업
App Engine NDB를 사용한 기본 데이터베이스 작업

마이그레이션을 시작하기 전에

마이그레이션을 시작하기 전에 다음 사항이 선행되어야 합니다.

데이터 캐시 필요성 판단
데이터를 캐시해야 하는 경우 서버리스 VPC 액세스 및 Redis용 Memorystore에서 앱의 리전을 지원하는지 확인
Datastore 모드 권한 이해

데이터 캐시 필요성 판단

Redis용 Memorystore와 서버리스 VPC 액세스에는 무료 등급이 없으며 모든 Google Cloud 리전을 지원하지 않으므로 앱에 캐싱이 필요합니다.

일반적으로 다음과 같습니다.

앱에서 동일한 데이터를 자주 읽는 경우 캐싱으로 지연 시간을 줄일 수 있습니다.
앱이 제공하는 요청이 많을수록 캐싱이 큰 영향을 미칠 수 있습니다.

현재 캐싱된 데이터를 얼마나 사용하고 있는지 확인하려면 Memcache 대시보드에서 캐시 적중과 누락의 비율을 확인하세요. 비율이 높으면 데이터 캐시를 사용하는 것이 앱의 지연 시간을 줄이는 데 큰 영향을 미칠 수 있습니다.

Memcache 대시보드 보기

가격 책정에 대한 자세한 내용은 Memorystore 가격 책정 및 서버리스 VPC 액세스 가격 책정을 참조하세요.

앱 리전 확인

데이터를 캐시해야 하는 경우 Redis용 Memorystore 및 서버리스 VPC 액세스에서 앱의 리전을 지원하는지 확인하세요.

Google Cloud 콘솔의 App Engine 대시보드 상단에 표시되는 앱 리전을 확인합니다.

대시보드 열기

리전은 페이지 상단의 앱 URL 바로 아래에 표시됩니다.
앱이 서버리스 VPC 액세스에서 지원되는 리전에 있는지 확인합니다.
커넥터 만들기 페이지로 이동한 후 리전 목록에서 지역을 확인하여 앱이 Redis용 Memorystore에서 지원되는 리전에 있는지 확인합니다.

커넥터 만들기 페이지 보기

앱이 Redis용 Memorystore 및 서버리스 VPC 액세스에서 지원하는 리전에 없는 경우 다음을 수행합니다.

Google Cloud 프로젝트를 만듭니다.
프로젝트에서 새 App Engine 앱을 만들고 지원되는 리전을 선택합니다.
앱이 새 프로젝트에서 사용하는 Google Cloud 서비스를 만듭니다.

또는 기존 프로젝트의 기존 서비스를 사용하도록 앱을 업데이트할 수도 있지만 다른 프로젝트 및 리전에서 서비스를 사용하면 가격 책정 및 리소스 사용이 다를 수 있습니다. 자세한 내용은 각 서비스의 문서를 참조하세요.
앱을 새 프로젝트에 배포합니다.

Datastore 모드 권한 이해

Google Cloud 서비스와의 모든 상호작용은 승인을 받아야 합니다. 예를 들어 Datastore 모드 데이터베이스에 데이터를 저장하거나 쿼리하려면 앱에서 데이터베이스에 액세스하도록 승인된 계정의 사용자 인증 정보를 제공해야 합니다.

기본적으로 앱은 앱과 동일한 프로젝트에 있는 데이터베이스에 액세스하도록 승인된 App Engine 기본 서비스 계정의 사용자 인증 정보를 제공합니다.

다음 조건 중 하나라도 해당하는 경우 사용자 인증 정보를 명시적으로 제공하는 대체 인증 기술을 사용해야 합니다.

앱과 Datastore 모드 데이터베이스가 서로 다른 Google Cloud 프로젝트에 있는 경우
기본 App Engine 서비스 계정에 할당된 역할이 변경된 경우

대체 인증 기술에 대한 자세한 내용은 서버 간 프로덕션 애플리케이션용 인증 설정을 참조하세요.

마이그레이션 프로세스 개요

App Engine NDB에서 Cloud NDB로 마이그레이션하려면 다음 안내를 따르세요.

Python 앱을 업데이트합니다.
1. Cloud NDB 클라이언트 라이브러리를 설치합니다.
2. import 문을 업데이트하여 Cloud NDB에서 모듈을 가져옵니다.
3. Cloud NDB 클라이언트를 만드는 코드를 추가합니다. 클라이언트는 앱의 환경 변수를 읽고 데이터를 사용하여 Datastore 모드로 인증할 수 있습니다.
4. 클라이언트의 런타임 컨텍스트를 사용하여 스레드 간에 캐시와 트랜잭션을 분리하는 코드를 추가합니다.
5. 더 이상 지원되지 않는 메서드와 속성을 사용하는 코드를 삭제하거나 업데이트합니다.
캐싱 사용 설정
업데이트를 테스트합니다.
App Engine에 앱을 배포합니다.

앱을 변경할 때와 마찬가지로 트래픽 분할을 사용하여 트래픽을 천천히 늘려보세요. 앱을 면밀히 모니터링하여 데이터베이스에 문제가 없는 것을 확인한 후 더 많은 트래픽을 업데이트된 앱으로 라우팅합니다.

Python 앱 업데이트

Python 2 앱용 Cloud NDB 라이브러리 설치

디렉터리를 만들어 lib/ 같은 타사 라이브러리를 저장합니다.
app.yaml 파일과 동일한 폴더에 requirements.txt 파일을 만들고 클라이언트 라이브러리의 이름을 추가합니다.
```
google-cloud-ndb==1.11.2
```
-t <directory> 플래그와 함께 pip(버전 6 이상)을 사용하여 이전 단계에서 만든 폴더에 라이브러리를 설치합니다. 예를 들면 다음과 같습니다.
```
pip install -t lib -r requirements.txt
```

app.yaml 파일의 libraries 섹션에서 RPC 및 setuptools 라이브러리를 지정합니다.

libraries:
- name: grpcio
  version: 1.0.0
- name: setuptools
  version: 36.6.0

아직 없으면 app.yaml 파일과 같은 폴더에 appengine_config.py 파일을 만듭니다. appengine_config.py 파일에 다음을 추가합니다.
```
# appengine_config.py
import pkg_resources
from google.appengine.ext import vendor

# Set path to your libraries folder.
path = 'lib'
# Add libraries installed in the path folder.
vendor.add(path)
# Add libraries to pkg_resources working set to find the distribution.
pkg_resources.working_set.add_entry(path)
```
pkg_resources 모듈을 사용하여 앱이 클라이언트 라이브러리의 올바른 배포를 사용하는지 확인합니다.

앞의 예시의 appengine_config.py 파일은 lib 폴더가 현재 작업 디렉터리에 있다고 가정합니다. lib가 항상 현재 작업 디렉터리에 있다는 것을 보장할 수 없으면 lib 폴더에 전체 경로를 지정합니다. 예를 들면 다음과 같습니다.
```
import os
path = os.path.join(os.path.dirname(os.path.realpath(__file__)), 'lib')
```

앱을 배포할 때 App Engine은 appengine_config.py 파일에 지정된 디렉터리의 모든 라이브러리를 업로드합니다.

Python 3 앱용 Cloud NDB 라이브러리 설치

App Engine의 Python 3 런타임은 앱의 requirements.txt 파일을 사용하여 앱에 설치할 패키지와 버전을 결정합니다. Python 3 런타임에 Cloud NDB 라이브러리를 설치하려면 다음 줄을 앱의 requirements.txt 파일에 추가합니다.

google-cloud-ndb

App Engine은 앱을 배포할 때 앱의 requirements.txt 파일에 있는 모든 라이브러리를 자동으로 업로드합니다.

로컬에서 종속 항목 설치

앱을 로컬에서 개발하고 테스트할 때는 가상 환경을 사용하여 앱의 종속 항목을 시스템 패키지에서 격리하는 것이 좋습니다. 이렇게 하면 앱이 앱의 requirements.txt 파일에서 선언한 종속 항목만 로드하고 앱이 로컬 환경과 프로덕션 환경 간에 종속 항목 버전을 동기화합니다.

Python 2로 virtualenv를 사용하여 가상 환경을 만들 수 있습니다.

Python 3에서는 가상 환경을 만드는 데 venv를 사용하는 것이 좋습니다.

import 문 업데이트

NDB 모듈의 위치가 google.cloud.ndb로 이동했습니다. 다음 표와 같이 앱의 import 문을 업데이트합니다.

삭제	바꾸기
`from google.appengine.ext import ndb`	`from google.cloud import ndb`

Cloud NDB 클라이언트 만들기

Google Cloud API를 기반으로 하는 다른 클라이언트 라이브러리와 마찬가지로 Cloud NDB 사용의 첫 번째 단계는 Client 객체를 만드는 것입니다. 클라이언트에는 Datastore 모드에 연결하는 데 필요한 사용자 인증 정보와 기타 데이터가 포함되어 있습니다. 예를 들면 다음과 같습니다.

from google.cloud import ndb

client = ndb.Client()

앞에서 설명한 기본 승인 시나리오에서 Cloud NDB 클라이언트는 Datastore 모드와 상호작용하도록 승인된 App Engine의 기본 서비스 계정의 사용자 인증 정보를 포함합니다. 이 기본 시나리오에서 작업하지 않는 경우 사용자 인증 정보를 제공하는 방법에 대한 자세한 내용은 애플리케이션 기본 사용자 인증 정보(ADC)를 참조하세요.

클라이언트의 런타임 컨텍스트 사용

Datastore 모드와 상호작용하는 데 필요한 사용자 인증 정보를 제공하는 것 외에도 Cloud NDB 클라이언트에는 런타임 컨텍스트를 반환하는 context() 메서드가 포함되어 있습니다. 런타임 컨텍스트는 다른 동시 Datastore 모드 상호작용에서 캐싱 및 트랜잭션 요청을 격리합니다.

Datastore 모드와의 모든 상호작용은 NDB 런타임 컨텍스트 내에서 발생해야 합니다. 모델 정의 만들기는 Datastore 모드와 상호작용하지 않으므로 Cloud NDB 클라이언트를 만들고 런타임 컨텍스트를 검색하기 전에 모델 클래스를 정의한 다음 요청 핸들러의 런타임 컨텍스트를 사용하여 데이터베이스에서 데이터를 가져올 수 있습니다.

예를 들면 다음과 같습니다.

datastore/cloud-ndb/quickstart.py

GitHub에서 보기

from google.cloud import ndb

class Book(ndb.Model):
    title = ndb.StringProperty()

client = ndb.Client()

def list_books():
    with client.context():
        books = Book.query()
        for book in books:
            print(book.to_dict())

멀티스레드 앱

Cloud NDB 클라이언트가 반환하는 런타임 컨텍스트는 단일 스레드에만 적용됩니다. 앱이 단일 요청에 멀티스레드를 사용하는 경우 Cloud NDB 라이브러리를 사용할 각 스레드에 대해 별도의 런타임 컨텍스트를 검색해야 합니다.

WSGI 프레임워크에서 런타임 컨텍스트 사용

웹 앱에서 WSGI 프레임워크를 사용하는 경우 런타임 컨텍스트를 검색하는 미들웨어 객체를 만든 다음 미들웨어 객체에 앱을 래핑하여 모든 요청에 대해 새로운 런타임 컨텍스트를 자동으로 만들 수 있습니다.

다음은 Flask와 함께 미들웨어를 사용하는 예시입니다.

middleware 메서드는 NDB 클라이언트의 런타임 컨텍스트 내에 WSGI 미들웨어 객체를 생성합니다.
Flask 앱은 미들웨어 객체로 래핑됩니다.
Flask는 각 요청을 미들웨어 객체를 통해 전달하며 이 객체는 요청마다 새로운 NDB 런타임 컨텍스트를 가져옵니다.

datastore/cloud-ndb/flask_app.py

GitHub에서 보기

from flask import Flask

from google.cloud import ndb

client = ndb.Client()

def ndb_wsgi_middleware(wsgi_app):
    def middleware(environ, start_response):
        with client.context():
            return wsgi_app(environ, start_response)

    return middleware

app = Flask(__name__)
app.wsgi_app = ndb_wsgi_middleware(app.wsgi_app)  # Wrap the app in middleware.

class Book(ndb.Model):
    title = ndb.StringProperty()

@app.route('/')
def list_books():
    books = Book.query()
    return str([book.to_dict() for book in books])

Django에서 런타임 컨텍스트 사용

App Engine NDB 라이브러리에서 제공하는 Django 미들웨어는 Cloud NDB 라이브러리에서 지원되지 않습니다. 앱에서 이 미들웨어(google.appengine.ext.ndb.django_middleware)를 사용한 경우 다음 단계에 따라 앱을 업데이트하세요.

Django의 미들웨어 시스템을 사용하여 요청마다 새로운 런타임 컨텍스트를 만듭니다.

아래 예시를 참조하세요.

ndb_django_middleware 메서드는 Cloud NDB 클라이언트를 만듭니다.
middleware 메서드는 NDB 클라이언트의 런타임 컨텍스트 내에 미들웨어 객체를 생성합니다.

datastore/cloud-ndb/django_middleware.py

GitHub에서 보기

from google.cloud import ndb

# Once this middleware is activated in Django settings, NDB calls inside Django
# views will be executed in context, with a separate context for each request.
def ndb_django_middleware(get_response):
    client = ndb.Client()

    def middleware(request):
        with client.context():
            return get_response(request)

    return middleware

Django settings.py 파일에서 MIDDLEWARE 설정을 업데이트하여 google.appengine.ext.ndb.NdbDjangoMiddleware 대신 새로 만든 미들웨어를 나열합니다.

이제 Django가 MIDDLEWARE 설정에 나열된 미들웨어 객체를 통해 각 요청을 전달하며, 이 객체는 각 요청에 대해 새로운 NDB 런타임 컨텍스트를 검색합니다.

삭제되거나 변경된 NDB API의 코드 업데이트

App Engine 관련 API 및 서비스를 사용하는 NDB API가 Cloud NDB 라이브러리에서 업데이트되거나 삭제되었습니다.

코드가 다음 NDB API 중 하나를 사용하는 경우 코드를 업데이트해야 합니다.

google.appengine.ext.ndb.Model 및 모델 속성
google.appengine.ext.ndb.Key
google.appengine.ext.ndb.query.QueryOptions 및 PropertyOrder
google.appengine.ext.ndb.utils
google.appengine.api.namespacemanager
google.appengine.api.ext.ndb.tasklets
google.appengine.api.datastore_errors

모델 및 모델 속성

google.appengine.ext.ndb.Model의 다음 메서드는 더 이상 사용할 수 없는 App Engine 관련 API를 사용하므로 Cloud NDB 라이브러리에서 사용할 수 없습니다.

삭제된 API	대체
`Model.get_indexes` 및 `Model.get_indexes_async`	없음
`Model._deserialize` 및 `Model._serialize`	없음
`Model.make_connection`	없음

다음 표에서는 Cloud NDB 라이브러리에서 변경된 특정 google.appengine.ext.ndb.Model 속성을 설명합니다.

속성	변경
`TextProperty`	`google.cloud.ndb.TextProperty`의 색인을 생성할 수 없습니다. `google.cloud.ndb.TextProperty.indexed`를 설정하려고 하면 `NotImplementedError`가 발생합니다.
`StringProperty`	`StringProperty`는 항상 색인이 생성됩니다. `google.cloud.ndb.StringProperty.indexed`를 설정하려고 하면 `NotImplementedError`가 발생합니다.
생성자의 `name` 또는 `kind` 인수가 있는 모든 속성.	`unicode`가 Python 3에서 `str`로 대체되었으므로 `name` 또는 `kind`는 `str` 데이터 유형이어야 합니다.

다음 표의 클래스와 메서드는 더 이상 사용할 수 없는 App Engine 관련 리소스를 사용하므로 더 이상 사용할 수 없습니다.

삭제된 API	대체
`google.appengine.ext.ndb.msgprop.MessageProperty` 및 `google.appengine.ext.ndb.msgprop.EnumProperty`	없음 이러한 객체를 만들려고 하면 `NotImplementedError`가 발생합니다.
`google.appengine.ext.ndb.model.Property`: `_db_get_value` `_db_set_value` `_db_set_compressed_meaning` `_db_set_uncompressed_meaning` `__creation_counter_global`	없음 이러한 메서드는 변경된 Datastore 모드 프로토콜 버퍼를 사용합니다.
`Model.make_connection`	없음

키

google.appengine.ext.ndb.Key의 다음 메서드는 Cloud NDB 라이브러리에서 사용할 수 없습니다. 이러한 메서드는 더 이상 지원되지 않는 DB Datastore API와 키를 주고받는 데 사용되었습니다(DB는 App Engine NDB의 전신).

삭제된 API	대체
`Key.from_old_key` 및 `Key.to_old_key`	없음

또한 다음과 같은 변경 사항이 있습니다.

App Engine NDB	Cloud NDB
종류 및 문자열 ID는 500바이트 미만이어야 합니다.	종류 및 문자열 ID는 1,500바이트 미만이어야 합니다.
`Key.app()`은 키를 만들 때 지정한 프로젝트 ID를 반환합니다.	`google.cloud.ndb.Key.app()`에서 반환한 값은 생성자에 전달된 원래 ID와 다를 수 있습니다. s~example과 같은 프리픽스가 붙은 앱 ID가 App Engine의 기존 식별자이기 때문입니다. example과 같은 동일한 프로젝트 ID로 대체되었습니다.

쿼리

App Engine NDB와 마찬가지로 Cloud NDB는 QueryOptions 클래스(google.cloud.ndb.query.QueryOptions)를 사용하면 각 쿼리에 대해 재정의하는 대신 특정 쿼리 옵션 집합을 재사용할 수 있습니다. 하지만 Cloud NDB의 QueryOptions는 google.appengine.datastore.datastore_rpc.Configuration에서 상속되지 않으므로 ...datastore_rpc.Configuration 메서드를 지원하지 않습니다.

또한 google.appengine.datastore.datastore_query.Order는 google.cloud.ndb.query.PropertyOrder로 대체되었습니다. Order와 마찬가지로 PropertyOrder 클래스를 사용하면 여러 쿼리에서 정렬 순서를 지정할 수 있습니다. PropertyOrder 생성자는 Order의 생성자와 동일합니다. 클래스 이름만 변경되었습니다.

삭제된 API	대체
`google.appengine.datastore.datastore_rpc.Configuration`: `deadline(value)` `on_completion(value)` `read_policy(value)` `force_writes(value)` `max_entity_groups_per_rpc(value)` `max_allocate_ids_keys(value)` `max_rpc_bytes(value)` `max_get_keys(value)` `max_put_entities(value)` `max_delete_keys(value)` 이러한 메서드에 대한 설명은 소스 코드를 참조하세요.	없음
`google.appengine.ext.ndb.Order` 예시: `order=Order(-Account.birthday, Account.name)`	`google.cloud.ndb.PropertyOrder` 예시: `google.cloud.ndb.PropertyOrder(-Account.birthday, Account.name)`

Utils

ndb.utils 모듈(google.appengine.ext.ndb.utils)은 더 이상 사용할 수 없습니다. 이 모듈의 대부분의 메서드는 App Engine NDB 내부에 있었지만 새 ndb의 구현 차이로 인해 일부 메서드가 삭제되었으며 다른 메서드는 새로운 Python 3 기능으로 인해 사용되지 않습니다. 일부 메서드는 마이그레이션을 돕기 위해 계속 제공됩니다.

예를 들어 이전 utils 모듈의 위치 데코레이터는 함수 또는 메서드의 첫 번째 n 인수만 위치일 수 있다고 선언했습니다. 그러나 Python 3는 키워드 전용 인수를 사용하여 이를 수행할 수 있습니다. 이전에는 다음과 같이 작성되었습니다.

@utils.positional(2)
def function1(arg1, arg2, arg3=None, arg4=None)
  pass

Python 3에서는 다음과 같이 작성할 수 있습니다.

def function1(arg1, arg2, *, arg3=None, arg4=None)
  pass

네임스페이스

네임스페이스를 사용하면 멀티테넌트 애플리케이션이 동일한 Datastore 모드 데이터베이스를 사용하는 동안 각 테넌트에 대해 별도의 데이터 사일로를 사용할 수 있습니다. 즉, 각 테넌트는 자체 네임스페이스 아래에 데이터를 저장합니다.

App Engine 관련 google.appengine.api.namespacemanager를 사용하는 대신 Cloud NDB 클라이언트를 만들 때 기본 네임스페이스를 지정한 다음 클라이언트의 런타임 컨텍스트 내에서 Cloud NDB 메서드를 호출하여 기본 네임스페이스를 사용합니다. 네임스페이스를 지원하는 다른 Google Cloud API와 동일한 패턴을 따릅니다.

삭제된 API	대체
`google.appengine.api.namespace_manager.namespace_manager.set_namespace(str)` 및 `google.appengine.api.namespacemanager.getnamespace()`	client=google.cloud.ndb.Client(namespace="my namespace") with client.context() as context: key = ndb.Key("SomeKind", "SomeId") 또는 key-non-default-namespace=ndb.Key("SomeKind," "AnotherId", namespace="non-default-nspace")
기타 모든 `google.appengine.api.namespacemanager` 메서드	없음

Tasklets

이제 Tasklet은 Return 예외를 발생시키는 대신 표준 return 문을 사용하여 결과를 반환할 수 있습니다. 예를 들면 다음과 같습니다.

App Engine NDB 라이브러리	Cloud NDB 라이브러리
@ndb.tasklet def get_cart(): cart = yield CartItem.query().fetch_async() raise Return(cart)	@ndb.tasklet def get_cart(): cart = yield CartItem.query().fetch_async() return cart

Return 예외를 발생시켜 Cloud NDB에서 결과를 반환할 수는 있지만 권장되지 않습니다.

또한 Cloud NDB 라이브러리에서 NDB 컨텍스트를 만들고 사용하는 방법이 변경되어 다음 Tasklets 메서드와 서브클래스를 더 이상 사용할 수 없습니다.

삭제된 API	대체
`google.appengine.api.ext.ndb.tasklets`: `add_flow_exception` `make_context` `make_default_context` `set_context`	없음
`google.appengine.api.ext.ndb.tasklets`: `QueueFuture` `ReducedFuture` `SerialQueueFuture`	없음

예외

Cloud NDB 라이브러리의 google.cloud.ndb.exceptions 모듈에는 App Engine NDB 라이브러리의 동일한 예외가 많이 포함되어 있지만 이전 예외 중 일부는 새 라이브러리에서 사용할 수 없습니다. 다음 표에는 더 이상 사용할 수 없는 예외가 나와 있습니다.

삭제된 API	대체
`google.appengine.api.datastore_errors`: `BadKeyError` `BadPropertyError` `CommittedButStillApplying` `EntityNotFoundError` `InternalError` `NeedIndexError` `QueryNotFoundError` `ReferencePropertyResolveError` `Timeout` `TransactionFailedError` `TransactionNotFoundError`	`google.cloud.ndb.exceptions`

데이터 캐싱 사용 설정

Cloud NDB는 Memorystore, Redis Labs 또는 기타 시스템에서 관리하는 Redis 인메모리 데이터 저장소에서 데이터를 캐시할 수 있습니다. 이 가이드에서는 Redis용 Memorystore를 사용하여 데이터를 캐시하는 방법을 설명합니다.

서버리스 VPC 액세스 설정
Redis용 Memorystore 설정
앱에 Redis 연결 URL을 추가합니다.
RedisCache 객체를 만듭니다.

서버리스 VPC 액세스 설정

앱은 서버리스 VPC 액세스 커넥터를 통해서만 Memorystore와 통신할 수 있습니다. 서버리스 VPC 액세스 커넥터를 설정하려면 다음 안내를 따르세요.

Redis용 Memorystore 설정

Redis용 Memorystore를 설정하려면 다음 안내를 따르세요.

Memorystore에서 Redis 인스턴스를 만듭니다. 인스턴스를 만들 때 다음을 수행합니다.
- 리전에서 App Engine 앱이 있는 리전과 동일한 리전을 선택합니다.
- 승인된 네트워크에서 서버리스 VPC 액세스 커넥터가 사용 중인 네트워크를 선택합니다.
만들려는 Redis 인스턴스의 IP 주소와 포트 번호를 기록합니다. 이 정보는 Cloud NDB에 데이터 캐싱을 사용 설정할 때 사용됩니다.

앱 업데이트를 배포하려면 gcloud beta 명령어를 사용해야 합니다. 베타 명령어만 VPC 커넥터를 사용하도록 앱을 업데이트할 수 있습니다.

Redis 연결 URL 추가

앱의 app.yaml 파일에 REDIS_CACHE_URL 환경 변수를 추가하여 Redis 캐시에 연결할 수 있습니다. REDIS_CACHE_URL의 값은 다음 형식입니다.

redis://IP address for your instance:port

예를 들어 앱의 app.yaml 파일에 다음 줄을 추가할 수 있습니다.

     env_variables:
      REDIS_CACHE_URL: redis://10.0.0.3:6379

Redis 캐시 객체 생성 및 사용

REDIS_CACHE_URL을 환경 변수로 설정한 경우 코드 한 줄로 RedisCache 객체를 만든 다음 런타임 컨텍스트를 설정할 때 Client.context()에 전달하여 캐시를 사용할 수 있습니다.

client = ndb.Client()
global_cache = ndb.RedisCache.from_environment()

with client.context(global_cache=global_cache):
  books = Book.query()
  for book in books:
      print(book.to_dict())

REDIS_CACHE_URL을 환경 변수로 설정하지 않으면 Redis 클라이언트를 구성하고 클라이언트를 ndb.RedisCache() 생성자에 전달해야 합니다. 예를 들면 다음과 같습니다.

global_cache = ndb.RedisCache(redis.StrictRedis(host=IP-address, port=redis_port))

Cloud NDB 라이브러리는 이미 Redis 클라이언트 라이브러리에 종속되어 있으므로 Redis 클라이언트 라이브러리에 대한 종속 항목을 선언할 필요가 없습니다.

Redis 클라이언트를 구성하는 예시는 Memorystore 샘플 애플리케이션을 참조하세요.

업데이트 테스트

App Engine에 배포하기 전에 테스트 데이터베이스를 설정하고 로컬에서 앱을 실행하려면 다음 안내를 따르세요.

Datastore 모드 로컬 에뮬레이터를 실행하여 데이터를 저장하고 검색합니다.

앱이 프로덕션 Datastore 모드 환경 대신 에뮬레이터에 연결되도록 환경 변수 설정 안내를 따라야 합니다.

데이터베이스에 사전 로드된 데이터로 테스트를 시작하려면 에뮬레이터로 데이터를 가져올 수도 있습니다.
로컬 개발 서버를 사용하여 앱을 실행합니다.

로컬 개발 중에 GOOGLE_CLOUD_PROJECT 환경 변수가 올바르게 설정되었는지 확인하려면 다음 매개변수를 사용하여 dev_appserver를 초기화합니다.
```
--application=PROJECT_ID
```
PROJECT_ID는 Google Cloud 프로젝트 ID여야 합니다. gcloud config list project 명령어를 사용하거나 Google Cloud 콘솔에서 프로젝트 페이지를 검토하여 프로젝트 ID를 찾을 수 있습니다.

앱 배포

앱이 로컬 개발 서버에서 오류 없이 실행되면 다음을 수행합니다.

App Engine에서 앱을 테스트합니다.
앱이 오류 없이 실행되면 트래픽 분할을 사용하여 업데이트된 앱의 트래픽을 천천히 늘립니다. 앱을 면밀히 모니터링하여 데이터베이스에 문제가 없는 것을 확인한 후 더 많은 트래픽을 업데이트된 앱으로 라우팅합니다.