App Engine blobstore 사용 방법 (모듈 15)

1. 개요

서버리스 마이그레이션 스테이션 Codelab 시리즈 (사용자 주도형, 실무 가이드) 및 관련 동영상은 Google Cloud 서버리스 개발자가 주로 기존 서비스에서 벗어나는 하나 이상의 마이그레이션을 통해 애플리케이션을 현대화할 수 있도록 돕기 위한 것입니다. 이렇게 하면 앱의 이식성이 높아지고 더 많은 옵션과 유연성을 제공하여 다양한 Cloud 제품과 통합하고 액세스할 수 있으며 최신 언어 출시로 더 쉽게 업그레이드할 수 있습니다. 이 시리즈는 처음에는 주로 App Engine (표준 환경) 개발자와 같은 초기 Cloud 사용자를 대상으로 하지만, Cloud Functions, Cloud Run과 같은 다른 서버리스 플랫폼이나 해당하는 경우 다른 플랫폼도 포함할 수 있을 만큼 광범위합니다.

이 모듈 15 Codelab에서는 모듈 0의 샘플 앱에 App Engine blobstore 사용을 추가하는 방법을 설명합니다. 그런 다음 16단원에서 Cloud Storage로 사용량을 이전할 수 있습니다.

Blobstore를 사용하지 않으시나요?

앱에서 App Engine Blobstore 서비스를 사용하지 않는 경우 모듈 15~16을 건너뛰거나 이 Codelab을 통해 Blobstore 이전 방법을 숙지하세요.

App Engine Cloud Storage 맞춤 클라이언트 라이브러리를 사용하시나요?

앱에서 Cloud Storage용 App Engine 맞춤 클라이언트 라이브러리 (GoogleAppEngineCloudStorageClient 또는 cloudstorage)를 사용하는 경우 Cloud Storage 클라이언트 라이브러리로도 마이그레이션하는 것이 좋습니다. 이러한 이전은 이 튜토리얼의 범위를 벗어나며 다루지 않습니다. Cloud Storage 이전 페이지에 몇 가지 일반적인 단계가 나와 있습니다.

다음 실습에서는

• App Engine Blobstore API/라이브러리 사용 추가
• 사용자 업로드를 blobstore 서비스에 저장
• Cloud Storage로 마이그레이션하기 위한 다음 단계 준비

필요한 항목

• 활성 GCP 결제 계정이 있는 Google Cloud Platform 프로젝트
• 기본 Python 기술
• 일반적인 Linux 명령어에 대한 실무 지식
• App Engine 앱 개발 및 배포에 대한 기본 지식
• 작동되는 모듈 0 App Engine 앱 (저장소에서 가져옴)

설문조사

이 튜토리얼을 어떻게 사용하실 계획인가요?

읽기만 할 계획입니다 읽은 다음 연습 활동을 완료할 계획입니다

귀하의 Python 사용 경험이 어떤지 평가해 주세요.

초급 중급 고급

귀하의 Google Cloud 서비스 사용 경험을 평가해 주세요.

초급 중급 고급

2. 배경

App Engine Blobstore API에서 이전하려면 모듈 0의 기존 기준 App Engine ndb 앱에 사용을 추가합니다. 샘플 앱은 사용자에게 가장 최근 방문 10개를 표시합니다. '방문'에 해당하는 아티팩트 (파일)를 업로드하라는 메시지가 최종 사용자에게 표시되도록 앱을 수정하고 있습니다. 사용자가 원하지 않는 경우 '건너뛰기' 옵션이 있습니다. 사용자의 결정과 관계없이 다음 페이지는 모듈 0의 앱 (및 이 시리즈의 다른 많은 모듈)과 동일한 출력을 렌더링합니다. 이 App Engine blobstore 통합을 구현했으므로 다음 (모듈 16) Codelab에서 Cloud Storage로 마이그레이션할 수 있습니다.

App Engine은 Django 및 Jinja2 템플릿 시스템에 대한 액세스를 제공하며, 이 예시를 다르게 만드는 한 가지 요소는 (Blobstore 액세스 추가 외에) 모듈 0에서 Django를 사용하는 것에서 모듈 15에서 Jinja2로 전환한다는 것입니다. App Engine 앱을 현대화하는 주요 단계는 웹 프레임워크를 webapp2에서 Flask로 마이그레이션하는 것입니다. 후자는 Jinja2를 기본 템플릿 시스템으로 사용하므로 Blobstore 액세스를 위해 webapp2에 머무르면서 Jinja2를 구현하여 해당 방향으로 이동하기 시작합니다. Flask는 기본적으로 Jinja2를 사용하므로 16단원에서 템플릿을 변경할 필요가 없습니다.

3. 설정/사전 작업

튜토리얼의 주요 부분을 진행하기 전에 프로젝트를 설정하고, 코드를 가져온 후 기본 앱을 배포하여 작동하는 코드로 시작합니다.

1. 프로젝트 설정

모듈 0 앱을 이미 배포한 경우 동일 프로젝트 (및 코드)를 다시 사용하는 것이 좋습니다. 또는 완전히 새로운 프로젝트를 만들거나 다른 기존 프로젝트를 다시 사용할 수도 있습니다. 프로젝트에 활성 결제 계정이 있고 App Engine이 사용 설정되어 있는지 확인합니다.

2. 기준 샘플 앱 가져오기

이 Codelab의 기본 요건 중 하나는 작동하는 모듈 0 샘플 앱을 준비하는 것입니다. 샘플 앱이 없는 경우 모듈 0 'START' 폴더 (아래 링크)에서 다운로드할 수 있습니다. 이 Codelab은 각 단계를 안내하며, 모듈 15 '완료' 폴더에 있는 것과 비슷한 코드로 마무리됩니다.

• 시작: 모듈 0 폴더 (Python 2)
• 완료: 모듈 15 폴더 (Python 2)
• 전체 저장소 (클론 또는 ZIP 파일 다운로드)

모듈 0 시작 파일의 디렉터리는 다음과 같습니다.

$ ls
README.md               index.html
app.yaml                main.py

3. 기준 앱 (재)배포

이제 남은 사전 작업 실행 단계는 다음과 같습니다.

1. gcloud 명령줄 도구 다시 숙지
2. gcloud app deploy를 사용하여 샘플 앱을 다시 배포합니다.
3. 앱이 문제 없이 App Engine에서 실행되는지 확인합니다.

위 단계를 성공적으로 실행하고 웹 앱이 작동하는 것을 확인하면 (아래와 비슷한 출력) 앱에 캐싱 사용을 추가할 수 있습니다.

4. 구성 파일 업데이트

app.yaml

애플리케이션 구성에는 실질적인 변경사항이 없지만 앞서 언급한 것처럼 Django 템플릿 (기본값)에서 Jinja2로 이동하므로 전환하려면 사용자가 App Engine 서버에서 사용할 수 있는 최신 버전의 Jinja2를 지정해야 하며, 이는 app.yaml의 내장 서드 파티 라이브러리 섹션에 추가하여 수행합니다.

이전:

runtime: python27
threadsafe: yes
api_version: 1

handlers:
- url: /.*
  script: main.app

여기에 표시된 것처럼 새 libraries 섹션을 추가하여 app.yaml 파일을 수정합니다.

AFTER:

runtime: python27
threadsafe: yes
api_version: 1

handlers:
- url: /.*
  script: main.app

libraries:
- name: jinja2
  version: latest

최신 버전의 서드 파티 라이브러리가 필요하신가요?

위의 app.yaml 변경사항은 Jinja2의 '최신' 버전을 지정하는 것으로 보입니다. 하지만 이는 App Engine 서버에서 사용할 수 있는 최신 Python 2 버전을 나타내며 라이브러리 자체의 최신 버전을 나타내지는 않습니다. 지원되는 서드 파티 라이브러리 페이지에 나열된 버전보다 최신 버전이 필요한 경우 위에 설명된 대로 app.yaml에 추가하지 마세요. 대신 requirements.txt에 나열하고 pip install -t lib -r requirements.txt를 실행하여 Python 2용 Jinja2 (또는 허용된 서드 파티 라이브러리)의 실제 최신 버전을 번들링/벤더링합니다. 내장 라이브러리는 최신 버전을 항상 제공하는 대신 자체 번들링을 하지 않아도 되는 편리함을 제공합니다.

다른 구성 파일은 업데이트할 필요가 없으므로 애플리케이션 파일로 이동합니다.

5. 애플리케이션 파일 수정

가져오기 및 Jinja2 지원

main.py의 첫 번째 변경사항에는 Blobstore API 사용 추가와 Django 템플릿을 Jinja2로 대체하는 작업이 포함됩니다. 변경되는 사항은 다음과 같습니다.

1. os 모듈의 목적은 Django 템플릿의 파일 경로 이름을 만드는 것입니다. 이 문제가 처리되는 Jinja2로 전환하므로 os와 Django 템플릿 렌더러 google.appengine.ext.webapp.template는 더 이상 필요하지 않으므로 삭제됩니다.
2. Blobstore API 가져오기: google.appengine.ext.blobstore
3. 원래 webapp 프레임워크에 있는 Blobstore 핸들러를 가져옵니다. webapp2에서는 사용할 수 없습니다. google.appengine.ext.webapp.blobstore_handlers
4. webapp2_extras 패키지에서 Jinja2 지원 가져오기

이전:

import os
import webapp2
from google.appengine.ext import ndb
from google.appengine.ext.webapp import template

main.py의 현재 가져오기 섹션을 아래 코드 스니펫으로 바꿔 위의 목록에 나온 변경사항을 구현합니다.

AFTER:

import webapp2
from webapp2_extras import jinja2
from google.appengine.ext import blobstore, ndb
from google.appengine.ext.webapp import blobstore_handlers

가져오기 후 webapp2_extras 문서에 정의된 대로 Jinja2 사용을 지원하는 상용구 코드를 추가합니다. 다음 코드 스니펫은 표준 webapp2 요청 핸들러 클래스를 Jinja2 기능으로 래핑하므로 가져오기 바로 뒤에 main.py에 이 코드 블록을 추가합니다.

class BaseHandler(webapp2.RequestHandler):
    'Derived request handler mixing-in Jinja2 support'
    @webapp2.cached_property
    def jinja2(self):
        return jinja2.get_jinja2(app=self.app)

    def render_response(self, _template, **context):
        self.response.write(self.jinja2.render_template(_template, **context))

대체 Jinja2 지원

위의 Jinja2 상용구를 인식하지 못하고 jinja2.Environment() 사용을 특징으로 하는 App Engine 문서의 샘플과 같은 것을 기대했다면 webapp2extras 솔루션을 선택한 이유는 개선된 (I18N 스레딩) 지원을 제공하기 때문입니다.

Blobstore 지원 추가

이 시리즈의 다른 이전과 달리 UX를 크게 변경하지 않고 샘플 앱의 기능이나 출력을 동일하게(또는 거의 동일하게) 유지하는 대신 이 예에서는 일반적인 방식에서 더 급진적으로 벗어납니다. 새 방문을 즉시 등록한 다음 최근 10개를 표시하는 대신, 방문을 등록할 파일 아티팩트를 사용자에게 요청하도록 앱을 업데이트하고 있습니다. 그런 다음 최종 사용자는 해당 파일을 업로드하거나 '건너뛰기'를 선택하여 아무것도 업로드하지 않을 수 있습니다. 이 단계를 완료하면 '최근 방문' 페이지가 표시됩니다.

이 변경사항을 통해 앱은 Blobstore 서비스를 사용하여 최근 방문 페이지에 해당 이미지 또는 기타 파일 형식을 저장 (나중에 렌더링할 수도 있음)할 수 있습니다.

데이터 모델 업데이트 및 사용 구현

더 많은 데이터를 저장합니다. 특히 Blobstore에 업로드된 파일의 ID('BlobKey'라고 함)를 저장하도록 데이터 모델을 업데이트하고 store_visit()에 저장할 참조를 추가합니다. 이 추가 데이터는 쿼리 시 다른 모든 항목과 함께 반환되므로 fetch_visits()는 동일하게 유지됩니다.

file_blob, ndb.BlobKeyProperty를 사용한 업데이트 전후의 모습은 다음과 같습니다.

이전:

class Visit(ndb.Model):
    'Visit entity registers visitor IP address & timestamp'
    visitor   = ndb.StringProperty()
    timestamp = ndb.DateTimeProperty(auto_now_add=True)

def store_visit(remote_addr, user_agent):
    'create new Visit entity in Datastore'
    Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()

def fetch_visits(limit):
    'get most recent visits'
    return Visit.query().order(-Visit.timestamp).fetch(limit)

AFTER:

class Visit(ndb.Model):
    'Visit entity registers visitor IP address & timestamp'
    visitor   = ndb.StringProperty()
    timestamp = ndb.DateTimeProperty(auto_now_add=True)
    file_blob = ndb.BlobKeyProperty()

def store_visit(remote_addr, user_agent, upload_key):
    'create new Visit entity in Datastore'
    Visit(visitor='{}: {}'.format(remote_addr, user_agent),
            file_blob=upload_key).put()

def fetch_visits(limit):
    'get most recent visits'
    return Visit.query().order(-Visit.timestamp).fetch(limit)

지금까지 적용된 변경사항을 그림으로 나타내면 다음과 같습니다.

파일 업로드 지원

기능에서 가장 중요한 변경사항은 파일 업로드를 지원하는 것입니다. 여기에는 사용자에게 파일을 묻거나, '건너뛰기' 기능을 지원하거나, 방문에 해당하는 파일을 렌더링하는 것이 포함됩니다. 이 모든 것이 그림의 일부입니다. 파일 업로드를 지원하는 데 필요한 변경사항은 다음과 같습니다.

1. 기본 핸들러 GET 요청이 더 이상 표시를 위해 가장 최근 방문을 가져오지 않습니다. 대신 사용자에게 업로드를 요청합니다.
2. 최종 사용자가 업로드할 파일을 제출하거나 이 프로세스를 건너뛰면 양식의 POST가 google.appengine.ext.webapp.blobstore_handlers.BlobstoreUploadHandler에서 파생된 새 UploadHandler에 제어권을 전달합니다.
3. UploadHandler의 POST 메서드는 업로드를 실행하고, store_visit()를 호출하여 방문을 등록하고, HTTP 307 리디렉션을 트리거하여 사용자를 '/'로 다시 보냅니다. 여기서...
4. 기본 핸들러의 POST 메서드는 fetch_visits()를 통해 최신 방문을 쿼리하고 표시합니다. 사용자가 '건너뛰기'를 선택하면 파일이 업로드되지 않지만 방문은 계속 등록되고 동일한 리디렉션이 이어집니다.
5. 최근 방문 표시에는 업로드 파일을 사용할 수 있는 경우 하이퍼링크된 '보기'가 표시되고 그렇지 않은 경우 '없음'이 표시되는 새로운 필드가 포함됩니다. 이러한 변경사항은 업로드 양식 추가와 함께 HTML 템플릿에서 구현됩니다 (자세한 내용은 곧 제공 예정).
6. 최종 사용자가 업로드된 동영상이 있는 방문의 '보기' 링크를 클릭하면 GET 요청이 google.appengine.ext.webapp.blobstore_handlers.BlobstoreDownloadHandler에서 파생된 새 ViewBlobHandler에 전송됩니다. 이미지인 경우 (브라우저에서 지원되는 경우) 파일을 렌더링하거나, 그렇지 않은 경우 다운로드를 요청하거나, 찾을 수 없는 경우 HTTP 404 오류를 반환합니다.
7. 새 핸들러 클래스 쌍과 트래픽을 전송할 새 경로 쌍 외에도 기본 핸들러에는 위에 설명된 307 리디렉션을 수신하는 새 POST 메서드가 필요합니다.

이 업데이트 전에는 Module 0 앱에 GET 메서드와 단일 경로가 있는 기본 핸들러만 있었습니다.

이전:

class MainHandler(webapp2.RequestHandler):
    'main application (GET) handler'
    def get(self):
        store_visit(self.request.remote_addr, self.request.user_agent)
        visits = fetch_visits(10)
        tmpl = os.path.join(os.path.dirname(__file__), 'index.html')
        self.response.out.write(template.render(tmpl, {'visits': visits}))

app = webapp2.WSGIApplication([
    ('/', MainHandler),
], debug=True)

이러한 업데이트가 구현됨에 따라 이제 1) POST 메서드가 있는 업로드 핸들러, 2) GET 메서드가 있는 '블롭 보기' 다운로드 핸들러, 3) GET 및 POST 메서드가 있는 기본 핸들러의 세 가지 핸들러가 있습니다. 이제 앱의 나머지 부분이 아래와 같이 표시되도록 변경합니다.

AFTER:

class UploadHandler(blobstore_handlers.BlobstoreUploadHandler):
    'Upload blob (POST) handler'
    def post(self):
        uploads = self.get_uploads()
        blob_id = uploads[0].key() if uploads else None
        store_visit(self.request.remote_addr, self.request.user_agent, blob_id)
        self.redirect('/', code=307)

class ViewBlobHandler(blobstore_handlers.BlobstoreDownloadHandler):
    'view uploaded blob (GET) handler'
    def get(self, blob_key):
        self.send_blob(blob_key) if blobstore.get(blob_key) else self.error(404)

class MainHandler(BaseHandler):
    'main application (GET/POST) handler'
    def get(self):
        self.render_response('index.html',
                upload_url=blobstore.create_upload_url('/upload'))

    def post(self):
        visits = fetch_visits(10)
        self.render_response('index.html', visits=visits)

app = webapp2.WSGIApplication([
    ('/', MainHandler),
    ('/upload', UploadHandler),
    ('/view/([^/]+)?', ViewBlobHandler),
], debug=True)

방금 추가한 코드에는 몇 가지 주요 호출이 있습니다.

• MainHandler.get에는 blobstore.create_upload_url 호출이 있습니다. 이 호출은 양식이 POST하는 URL을 생성하여 업로드 핸들러를 호출하여 파일을 Blobstore로 전송합니다.
• UploadHandler.post에는 blobstore_handlers.BlobstoreUploadHandler.get_uploads 호출이 있습니다. 이것이 파일을 Blobstore에 넣고 해당 파일의 고유하고 영구적인 ID인 BlobKey를 반환하는 실제 마법입니다.
• ViewBlobHandler.get에서 파일의 BlobKey로 blobstore_handlers.BlobstoreDownloadHandler.send를 호출하면 파일이 가져와서 최종 사용자의 브라우저로 전달됩니다.

이러한 호출은 앱에 추가된 기능에 액세스하는 대부분을 나타냅니다. 다음은 main.py의 두 번째이자 마지막 변경사항을 그림으로 나타낸 것입니다.

HTML 템플릿 업데이트

기본 애플리케이션의 일부 업데이트는 앱의 사용자 인터페이스 (UI)에 영향을 미치므로 웹 템플릿에 해당하는 변경사항이 필요합니다. 실제로 두 가지가 있습니다.

1. 파일 업로드 양식에는 파일과 파일 업로드 및 건너뛰기를 위한 제출 버튼 쌍 등 3개의 입력 요소가 필요합니다.
2. 해당 파일 업로드가 있는 방문에는 '보기' 링크를 추가하고 그렇지 않은 경우에는 '없음'을 추가하여 가장 최근 방문 출력을 업데이트합니다.

이전:

<!doctype html>
<html>
<head>
<title>VisitMe Example</title>
<body>

<h1>VisitMe example</h1>
<h3>Last 10 visits</h3>
<ul>
{% for visit in visits %}
    <li>{{ visit.timestamp.ctime }} from {{ visit.visitor }}</li>
{% endfor %}
</ul>

</body>
</html>

위 목록의 변경사항을 구현하여 업데이트된 템플릿을 구성합니다.

AFTER:

<!doctype html>
<html>
<head>
<title>VisitMe Example</title>
<body>

<h1>VisitMe example</h1>
{% if upload_url %}

<h3>Welcome... upload a file? (optional)</h3>
<form action="{{ upload_url }}" method="POST" enctype="multipart/form-data">
    <input type="file" name="file"><p></p>
    <input type="submit"> <input type="submit" value="Skip">
</form>

{% else %}

<h3>Last 10 visits</h3>
<ul>
{% for visit in visits %}
<li>{{ visit.timestamp.ctime() }}
    <i><code>
    {% if visit.file_blob %}
        (<a href="/view/{{ visit.file_blob }}" target="_blank">view</a>)
    {% else %}
        (none)
    {% endif %}
    </code></i>
    from {{ visit.visitor }}
</li>
{% endfor %}
</ul>

{% endif %}

</body>
</html>

이 이미지는 index.html에 필요한 업데이트를 보여줍니다.

마지막으로 변경할 사항은 Jinja2가 templates 폴더에 템플릿을 두는 것을 선호하므로 해당 폴더를 만들고 index.html을 폴더 안으로 이동합니다. 이 마지막 단계로 Module 0 샘플 앱에 Blobstore 사용을 추가하는 데 필요한 모든 변경사항이 완료되었습니다.

(선택사항) Cloud Storage '개선사항'

Blobstore 스토리지는 결국 Cloud Storage 자체로 발전했습니다. 즉, Blobstore 업로드가 Cloud Console, 특히 Cloud Storage 브라우저에 표시됩니다. 문제는 어디에 있느냐입니다. 답은 App Engine 앱의 기본 Cloud Storage 버킷입니다. 이름은 App Engine 앱의 전체 도메인 이름인 PROJECT_ID.appspot.com입니다. 모든 프로젝트 ID가 고유하므로 매우 편리합니다.

샘플 애플리케이션에 적용된 업데이트는 업로드된 파일을 해당 버킷에 저장하지만 개발자는 더 구체적인 위치를 선택할 수 있습니다. 기본 버킷은 google.appengine.api.app_identity.get_default_gcs_bucket_name()을 통해 프로그래매틱 방식으로 액세스할 수 있으므로 업로드된 파일을 정리하기 위한 접두사로 사용하는 등 이 값에 액세스하려면 새로 가져와야 합니다. 예를 들어 파일 유형별로 정렬하는 경우:

예를 들어 이미지에 이와 같은 기능을 구현하려면 원하는 버킷 이름을 선택하기 위해 파일 형식을 확인하는 코드와 함께 다음과 같은 코드가 있어야 합니다.

ROOT_BUCKET = app_identity.get_default_gcs_bucket_name()
IMAGE_BUCKET = '%s/%s' % (ROOT_BUCKET, 'images')

또한 Python 표준 라이브러리 imghdr 모듈과 같은 도구를 사용하여 업로드된 이미지를 검증하여 이미지 유형을 확인합니다. 마지막으로 악성 사용자를 대비하여 업로드 크기를 제한하는 것이 좋습니다.

이 모든 작업을 완료했다고 가정해 보겠습니다. 업로드된 파일을 저장할 위치를 지정할 수 있도록 앱을 업데이트하려면 어떻게 해야 하나요? 핵심은 MainHandler.get에서 blobstore.create_upload_url 호출을 조정하여 다음과 같이 gs_bucket_name 매개변수를 추가하여 업로드할 Cloud Storage의 원하는 위치를 지정하는 것입니다.

blobstore.create_upload_url('/upload', gs_bucket_name=IMAGE_BUCKET))

업로드 위치를 지정하려면 선택적으로 업데이트해야 하므로 저장소의 main.py 파일에 포함되지 않습니다. 대신 main-gcs.py이라는 대체 항목을 저장소에서 검토할 수 있습니다. 별도의 버킷 '폴더'를 사용하는 대신 main-gcs.py의 코드는 main.py와 마찬가지로 업로드를 '루트' 버킷 (PROJECT_ID.appspot.com)에 저장하지만 이 섹션에 나와 있는 것처럼 샘플을 더 많은 것으로 파생하는 경우 필요한 스캐폴딩을 제공합니다. 아래는 main.py와 main-gcs.py 간의 '차이'를 보여주는 그림입니다.

6. 요약/삭제

이 섹션에서는 앱을 배포하고 의도한 대로 작동하는지, 반영된 출력이 있는지 확인하여 이 Codelab을 마무리합니다. 앱 검증 후 정리 단계를 실행하고 다음 단계를 고려합니다.

애플리케이션 배포 및 확인

gcloud app deploy를 사용하여 앱을 다시 배포하고 앱이 광고된 대로 작동하는지 확인합니다. 사용자 환경 (UX)은 Module 0 앱과 다릅니다. 이제 앱에 두 개의 서로 다른 화면이 있습니다. 첫 번째는 방문 파일 업로드 양식 프롬프트입니다.

여기에서 최종 사용자는 파일을 업로드하고 '제출'을 클릭하거나 '건너뛰기'를 클릭하여 아무것도 업로드하지 않습니다. 어떤 경우든 결과는 가장 최근 방문 화면이며, 이제 방문 타임스탬프와 방문자 정보 사이에 '보기' 링크 또는 '없음'이 추가됩니다.

모듈 0 샘플 앱에 App Engine Blobstore 사용을 추가하는 이 Codelab을 완료하신 것을 축하드립니다. 이제 코드가 완료 (모듈 15) 폴더에 있는 것과 일치합니다. 대체 main-gcs.py도 해당 폴더에 있습니다.

삭제

일반

지금까지 완료한 경우 청구가 발생하지 않도록 App Engine 앱을 사용 중지하는 것이 좋습니다. 하지만 테스트나 실험을 더 진행하고 싶다면 App Engine 플랫폼에 무료 할당량이 있으므로 해당 사용량 등급을 초과하지 않는 한 요금이 청구되지 않습니다. 이는 컴퓨팅에 대한 요금이며 관련 App Engine 서비스에 대한 요금도 부과될 수 있으므로 자세한 내용은 가격 책정 페이지를 확인하세요. 이 이전과 관련된 다른 클라우드 서비스는 별도로 청구됩니다. 두 경우 모두 해당하는 경우 아래의 '이 Codelab에만 해당' 섹션을 참고하세요.

완전한 공개를 위해 말씀드리면 App Engine과 같은 Google Cloud 서버리스 컴퓨팅 플랫폼에 배포하면 약간의 빌드 및 스토리지 비용이 발생합니다. Cloud Build에는 Cloud Storage와 마찬가지로 자체 무료 할당량이 있습니다. 해당 이미지를 저장하면 할당량의 일부가 사용됩니다. 하지만 무료 등급이 없는 지역에 거주할 수도 있으므로 스토리지 사용량을 파악하여 잠재적인 비용을 최소화하세요. 검토해야 하는 특정 Cloud Storage '폴더'는 다음과 같습니다.

• console.cloud.google.com/storage/browser/LOC.artifacts.PROJECT_ID.appspot.com/containers/images
• console.cloud.google.com/storage/browser/staging.PROJECT_ID.appspot.com
• 위의 스토리지 링크는 PROJECT_ID 및 *LOC*에 따라 달라집니다. 예를 들어 앱이 미국에서 호스팅되는 경우 'us'입니다.

반면에 이 애플리케이션 또는 기타 관련 이전 Codelab을 계속하지 않고 모든 것을 완전히 삭제하려면 프로젝트를 종료하세요.

이 Codelab에만 해당

아래에 나열된 서비스는 이 Codelab에만 해당합니다. 자세한 내용은 각 제품의 문서를 참고하세요.

• App Engine Blobstore 서비스는 저장된 데이터 할당량 및 한도에 해당하므로 해당 페이지와 기존 번들 서비스 가격 책정 페이지를 검토하세요.
• App Engine Datastore 서비스는 무료 등급도 있는 Cloud Datastore (Datastore 모드의 Cloud Firestore)에서 제공합니다. 자세한 내용은 가격 책정 페이지를 참고하세요.

다음 단계

다음으로 고려할 수 있는 논리적 마이그레이션은 16단원에서 다루며, 개발자가 App Engine Blobstore 서비스에서 Cloud Storage 클라이언트 라이브러리 사용으로 마이그레이션하는 방법을 보여줍니다. 업그레이드하면 더 많은 Cloud Storage 기능에 액세스할 수 있고 Google Cloud, 기타 클라우드, 온프레미스 등 App Engine 외부의 앱에서 작동하는 클라이언트 라이브러리에 익숙해질 수 있습니다. Cloud Storage에서 제공하는 모든 기능이 필요하지 않거나 비용에 미치는 영향이 우려되는 경우 App Engine Blobstore를 계속 사용해도 됩니다.

모듈 16 외에도 Cloud NDB 및 Cloud Datastore, Cloud Tasks, Cloud Memorystore와 같은 다양한 마이그레이션이 가능합니다. Cloud Run 및 Cloud Functions로의 교차 제품 이전도 있습니다. 마이그레이션 저장소에는 모든 코드 샘플이 포함되어 있고, 사용 가능한 모든 Codelab 및 동영상으로 연결되는 링크가 있으며, 고려해야 할 마이그레이션과 관련 '순서'에 관한 안내도 제공됩니다.

7. 추가 리소스

Codelab 문제/의견

이 Codelab에 문제가 발견된 경우 문제를 기록하기 전에 먼저 비슷한 기록이 있는지 검색해보세요. 검색 및 새 문제 만들기 링크:

• 문제 검색
• 새로운 문제/의견 제출

마이그레이션 리소스

모듈 0 (시작) 및 모듈 15 (완료)의 저장소 폴더 링크는 아래 표에서 찾을 수 있습니다. 또한 클론 또는 ZIP 파일로 다운로드할 수 있는 모든 App Engine Codelab 마이그레이션 저장소에서 액세스할 수도 있습니다.

Codelab	Python 2	Python 3
모듈 0	코드	해당 사항 없음
모듈 15 (이 Codelab)	코드	해당 사항 없음

온라인 리소스

다음은 이 튜토리얼과 관련이 있을 수 있는 온라인 리소스입니다.

App Engine

• App Engine Blobstore 서비스
• App Engine 저장 데이터 할당량 및 한도
• App Engine 문서
• Python 2 App Engine (표준 환경) 런타임
• Python 2 App Engine에서 App Engine 내장 라이브러리 사용
• App Engine 가격 및 할당량 정보
• 2세대 App Engine 플랫폼 출시 (2018)
• 1세대 플랫폼과 2세대 플랫폼 비교
• 기존 런타임 장기 지원
• 문서 마이그레이션 샘플 저장소
• 커뮤니티에서 제공한 마이그레이션 샘플 저장소

Google Cloud

• Google Cloud Platform에서 Python 사용
• Google Cloud Python 클라이언트 라이브러리
• Google Cloud '상시 무료' 등급
• Google Cloud SDK (gcloud 명령줄 도구)
• 모든 Google Cloud 문서

Python

• Django 및 Jinja2 템플릿 시스템
• webapp2 웹 프레임워크
• webapp2 문서
• webapp2_extras 링크
• webapp2_extras Jinja2 문서

동영상

• Serverless Migration Station
• 서버리스 Expeditions
• Google Cloud Tech 구독
• Google Developers 구독

라이선스

이 작업물은 Creative Commons Attribution 2.0 일반 라이선스에 따라 사용이 허가되었습니다.