Flask 앱에서 App Engine Memcache를 사용하는 방법 (모듈 12)

1. 개요

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

이 Codelab에서는 모듈 1 Codelab의 샘플 앱에 App Engine Memcache를 포함하고 사용하는 방법을 알아봅니다. 이 모듈 12 튜토리얼에서는 Memcache 사용을 추가한 다음 모듈 13에서 Cloud Memorystore로 마이그레이션합니다.

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

앱에서 App Engine Memcache를 사용하지 않는 경우 모듈 12~13을 건너뛰거나 Memcache 이전 방법을 숙지하기 위한 연습으로 이 Codelab을 진행할 수 있습니다.

다음 실습에서는

• App Engine Memcache API/라이브러리 사용
• 기본 Python 2 Flask App Engine NDB 앱에 캐싱 추가

필요한 항목

• 활성 GCP 결제 계정이 있는 Google Cloud Platform 프로젝트
• 기본 Python 기술
• 일반적인 Linux 명령어에 대한 실무 지식
• App Engine 앱 개발 및 배포에 대한 기본 지식
• 작동하는 모듈 1 App Engine 앱 (Codelab 완료[권장] 또는 저장소에서 앱 복사)

설문조사

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

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

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

초급 중급 고급

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

초급 중급 고급

2. 배경

App Engine Memcache에서 마이그레이션하려면 모듈 1 Codelab에서 생성된 기존 Flask 및 App Engine NDB 앱에 사용을 추가합니다. 샘플 앱은 사용자에게 가장 최근 방문 10개를 표시합니다. 동일한 사용자가 브라우저를 새로고침하는 경우 새 방문 항목을 계속 만들고 Datastore에서 가장 최근 방문을 가져오는 것은 최적이 아니므로 가장 최근 방문을 캐시할 것입니다.

동일한 방문자가 페이지에 도달하면 해당 방문은 캐시에서 반환됩니다. 새 사용자가 사이트를 방문하거나 1시간이 지나면 캐시가 삭제되고 최신 항목으로 대체되며 새 방문이 등록됩니다. 이 App Engine Memcache 통합을 구현했으므로 다음 (모듈 13) Codelab에서 Cloud Memorystore로 마이그레이션할 수 있습니다.

이 튜토리얼에서는 다음 단계를 다룹니다.

1. 설정/사전 작업
2. 구성 업데이트
3. 애플리케이션 코드 수정

3. 설정/사전 작업

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

1. 프로젝트 설정

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

2. 기준 샘플 앱 가져오기

이 Codelab의 기본 요건 중 하나는 작동하는 모듈 1 샘플 앱을 준비하는 것입니다. 샘플 앱이 없는 경우에는 계속하기 전에 아래 가이드 (위 링크)를 완료하세요. 가이드 내용을 잘 알고 계시다면 아래 모듈 1 코드를 선택하여 시작하세요.

무엇을 사용하든 모듈 1 코드에서부터 시작해야 합니다. 이 Codelab은 각 단계를 안내하며, 모듈 11 저장소 폴더 (완료)에 있는 것과 비슷한 코드로 마무리됩니다.

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

모듈 1 시작 파일 (사용자 또는 Google의 파일)의 디렉터리는 다음과 같습니다.

$ ls
README.md               main.py                 templates
app.yaml                requirements.txt

3. 기준 앱 (재)배포

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

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

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

4. 구성 업데이트

표준 App Engine 구성 파일 (app.yaml, requirements.txt, appengine_config.py)을 변경할 필요는 없습니다.

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

App Engine API만 추가하므로 외부 패키지가 포함되지 않으며 구성 파일 (app.yaml, requirements.txt, appengine_config.py)을 업데이트할 필요가 없습니다. 애플리케이션 파일이 main.py 하나뿐이므로 이 섹션의 모든 변경사항은 해당 파일에만 영향을 미칩니다.

가져오기

가장 중요한 단계는 Memcache 라이브러리 google.appengine.api.memcache를 가져오는 것입니다. 최근 방문을 1시간 동안 캐시할 것이므로 1시간의 초 수를 나타내는 상수도 추가해 보겠습니다. 이 변경사항을 적용하기 전의 코드는 다음과 같습니다.

이전:

from flask import Flask, render_template, request
from google.appengine.ext import ndb

app = Flask(__name__)

AFTER:

from flask import Flask, render_template, request
from google.appengine.api import memcache
from google.appengine.ext import ndb

app = Flask(__name__)
HOUR = 3600

Memcache 지원으로 캐싱 추가

가장 중요한 변경사항은 애플리케이션에 캐싱을 추가하는 것입니다. 구체적으로는 가장 최근 방문을 캐시하고, 캐시된 방문이 있는지 확인하고, 계획에 따라 캐시된 결과를 최대한 많이 사용하려고 시도해야 합니다. 앱이 목표를 달성하기 위해 취하는 단계는 다음과 같습니다.

1. 현재 방문을 설정하고 visitor를 호출합니다.
2. 캐시에서 최신 visits를 가져오려고 시도
3. 캐시가 비어 있거나 최근 방문자 (visits[0]['visitor'])가 현재 visitor와 다른 경우: 이 최신 방문을 저장하고, 최근 방문을 가져와서 1시간 동안 캐시합니다.
4. 웹 템플릿을 통해 사용자에게 visits 표시

업데이트 전후는 다음과 같습니다.

이전:

@app.route('/')
def root():
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10)
    return render_template('index.html', visits=visits)

AFTER:

@app.route('/')
def root():
    'main application (GET) handler'
    # check for (hour-)cached visits
    ip_addr, usr_agt = request.remote_addr, request.user_agent
    visitor = '{}: {}'.format(ip_addr, usr_agt)
    visits = memcache.get('visits')

    # register visit & run DB query if cache empty or new visitor
    if not visits or visits[0]['visitor'] != visitor:
        store_visit(ip_addr, usr_agt)
        visits = list(fetch_visits(10))
        memcache.set('visits', visits, HOUR)  # set() not add()

    return render_template('index.html', visits=visits)

변경사항을 그림으로 나타내면 다음과 같습니다.

이것으로 App Engine memcache 사용을 모듈 1 샘플 앱에 추가하는 데 필요한 모든 변경사항이 완료되었습니다. 이 앱을 빌드하고 배포하여 작동하는지 확인해 보겠습니다.

6. 요약/삭제

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

애플리케이션 배포 및 확인

gcloud app deploy로 앱을 다시 배포하고 앱이 작동하는지 확인합니다. 이제 코드는 모듈 12 폴더인 FINISH에 있는 것과 일치해야 합니다. 출력은 이전에 배포한 모듈 1 앱과 동일해야 합니다.

동일한 사용자의 사용자 환경을 개선했을 뿐입니다. 새로고침하면 캐시에서 직접 결과를 가져와야 하며, 이 경우 새 방문이 생성되지도 않고 Datastore 가져오기가 실행되지도 않습니다.

샘플 애플리케이션에 App Engine memcache 서비스 사용을 추가하는 모듈 12 Codelab을 완료하신 것을 축하드립니다. 이제 보너스 단계에서 이 Python 2 앱을 Python 3로 포팅할 수 있습니다.

삭제

일반

지금까지 완료한 경우 청구가 발생하지 않도록 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 Memcache 서비스는 두 가지 버전으로 제공되며 각 버전에는 자체 가격 책정 구조가 있으므로 결제와 관련된 사용량을 추적해야 합니다.
• App Engine Datastore 서비스는 무료 등급도 있는 Cloud Datastore (Datastore 모드의 Cloud Firestore)에서 제공합니다. 자세한 내용은 가격 책정 페이지를 참고하세요.

다음 단계

다음으로 고려할 수 있는 논리적 마이그레이션은 모듈 13에 설명되어 있으며, 개발자에게 App Engine memcache 서비스에서 Cloud Memorystore로 마이그레이션하는 방법을 보여줍니다. 이러한 이전은 모두 선택사항이며 애플리케이션을 현대화하기 위해 다양한 단계를 거치려는 사용자에게 제공됩니다. Cloud Memorystore 서비스는 다음과 같은 여러 이유로 App Engine의 memcache을 크게 업그레이드한 것입니다.

• Cloud Memorystore는 서버리스가 아닙니다. 즉, 캐시용 서버를 할당해야 합니다. Cloud Memorystore에도 무료 등급이 없습니다. 이 두 가지 요소는 비용에 큰 영향을 미칠 수 있습니다.
• Cloud Memorystore는 Redis와 Memcached라는 두 가지 기본 스토리지 메커니즘 (캐싱 엔진)을 지원합니다.
• Redis용 Cloud Memorystore는 App Engine Memcache보다 훨씬 풍부하고 심층적인 기능 세트를 제공합니다.
• Cloud Memorystore를 사용하려면 Cloud Memorystore 서버를 설정하고 Google Cloud VPC 네트워크에 추가한 후 App Engine 앱이 해당 네트워크를 사용하여 Memorystore 서버와 통신하도록 해야 합니다.

Cloud Memorystore에서 제공하는 모든 기능이 필요하지 않거나 비용에 미치는 영향이 우려되는 경우 App Engine Memcache를 계속 사용해도 됩니다.

모듈 13 이후에는 Cloud NDB 및 Cloud Datastore 또는 Cloud Tasks와 같은 다양한 마이그레이션이 가능합니다. Cloud Run 및 Cloud Functions로의 교차 제품 이전도 있습니다. 이전 저장소에서 모두 확인할 수 있습니다.

다음 단계로 Python 3로 포팅하는 것도 가능합니다. 이는 다음 섹션에서 선택사항으로 다룹니다.

7. 보너스: Python 3으로 마이그레이션

개요

이 섹션에는 위에서 완료한 모듈 12 애플리케이션을 Python 3로 이전하는 선택적 보너스 콘텐츠가 포함되어 있습니다. 구성부터 시작한 다음 애플리케이션을 진행합니다.

app.yaml 단순화

Python 3 런타임의 이점 중 하나는 app.yaml를 크게 간소화할 수 있다는 것입니다.

이전:

모듈 12가 끝날 때 app.yaml에 포함되는 내용은 다음과 같습니다.

runtime: python27
threadsafe: yes
api_version: 1

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

Python 3 런타임에서는 웹 프레임워크가 자체 라우팅을 실행해야 하므로 app.yaml의 모든 경로 핸들러를 auto로 변경해야 합니다. 제공되는 정적 파일이 없으면 사용자는 handlers: 섹션을 완전히 삭제할 수 있습니다. 또한 threadsafe 및 api_version가 모두 지원 중단되었습니다.

AFTER:

앞서 설명한 필수 변경사항을 적용하면 Python 3의 대체 app.yaml는 다음과 같습니다.

runtime: python39
app_engine_apis: true

설명이 필요한 유일한 줄은 app_engine_apis: true입니다. 2021년에 기존 App Engine 서비스를 2세대 런타임에서 사용할 수 있게 되었을 때 Python 3를 비롯한 일부 런타임에서는 ndb, taskqueue, memcache과 같은 API에 액세스하기 위해 추가 부트스트랩이 필요합니다. 구성의 이 줄이 이러한 용도로 사용됩니다.

requirements.txt 업데이트

requirements.txt에서 원본 API의 또 다른 부트스트래핑이 필요합니다. 새 App Engine SDK에 대한 액세스가 포함되어야 합니다.

이전:

모듈 12가 끝날 때 app.yaml에 포함되는 내용은 다음과 같습니다.

flask

AFTER:

App Engine Python SDK를 추가하면 다음이 표시됩니다.

flask
appengine-python-standard

패키지 버전 번호

저장소의 requirements.txt 파일에 버전 번호가 있을 수 있습니다. 이러한 정보는 정기적으로 변경되므로 여기에서 제외했습니다. 버전 번호가 지정되지 않으면 최신 버전이 사용됩니다.

appengine_config.py 및 lib 삭제

차세대 App Engine 런타임은 서드 파티 패키지 사용을 개선합니다.

• 내장 라이브러리는 Google에서 검토하고 App Engine 서버에서 제공하는 라이브러리입니다. 개발자가 클라우드에 배포할 수 없는 C/C++ 코드가 포함되어 있기 때문일 수 있습니다. 이러한 라이브러리는 2세대 런타임에서 더 이상 사용할 수 없습니다.
• 2세대 런타임에서는 더 이상 비기본 제공 라이브러리를 복사할 필요가 없습니다('벤더링' 또는 '자체 번들링'이라고도 함). 대신 빌드 시스템이 배포 시 자동으로 설치하는 requirements.txt에 나열해야 합니다.

서드 파티 패키지 관리의 변경으로 인해 appengine_config.py 파일도 lib 폴더도 필요하지 않으므로 삭제합니다. 2세대 런타임에서 App Engine은 requirements.txt에 나열된 서드 파티 패키지를 자동으로 설치합니다. 요약:

1. 자체 번들 또는 복사된 서드 파티 라이브러리가 없습니다. requirements.txt에 나열하세요.
2. lib 폴더로 pip install을 수행하지 않음, lib 폴더 기간 없음
3. app.yaml에 기본 제공 서드 파티 라이브러리 목록 없음 (따라서 libraries 섹션 없음), requirements.txt에 목록 작성
4. 앱에서 참조할 서드 파티 라이브러리가 없으므로 appengine_config.py 파일이 없습니다.

requirements.txt에 원하는 모든 서드 파티 라이브러리를 나열하는 것이 유일한 개발자 요구사항입니다.

App Engine SDK를 사용하도록 애플리케이션 업데이트

위에서 언급한 바와 같이 Python 3 앱에서 App Engine 번들 서비스에 액세스하려면 몇 가지 수정이 필요합니다.

1. App Engine SDK 번들 (requirements.txt)
2. App Engine SDK 활성화 (app.yaml)
3. WSGI 객체 래핑 (main.py)

첫 번째 쌍은 위에서 완료했으므로 마지막 요구사항은 main.py를 업데이트하는 것입니다.

이전:

다음은 모듈 12가 끝날 때의 Python 2 main.py입니다.

from flask import Flask, render_template, request
from google.appengine.api import memcache
from google.appengine.ext import ndb

app = Flask(__name__)
HOUR = 3600

AFTER:

Python 3 포트의 경우 SDK를 가져와 Flask 앱 객체를 SDK 래퍼로 래핑합니다. 결과는 다음과 같습니다.

from flask import Flask, render_template, request
from google.appengine.api import memcache, wrap_wsgi_app
from google.appengine.ext import ndb

app = Flask(__name__)
app.wsgi_app = wrap_wsgi_app(app.wsgi_app)
HOUR = 3600

개발자는 번들 서비스에 액세스하기 위해 2.x에서 3.x로 포팅할 때 Python 앱을 변경해야 합니다. Flask를 사용하지 않는 경우 문서에 Django 및 Pyramid 샘플도 있습니다. Python 2 코드가 웹 앱이 아닌 경우 Python 3로 포팅할 때 SDK 패키지만 포함하면 됩니다. 애플리케이션 코드는 원래 Python 2와 3에서 작동하도록 제작되었으므로 추가 호환성 변경이 필요하지 않습니다.

애플리케이션 배포

위의 변경사항을 완료한 후 업데이트된 샘플 앱을 배포할 수 있습니다. 동일한 GCP 프로젝트에서 원래 Python 2 버전을 통해 Python 3 버전을 배포할 때는 문제가 없습니다. 앱 동작은 동일하게 유지되어야 합니다. 업데이트된 앱을 Google 앱과 비교해야 하는 경우 이전 저장소의 Module 12b 폴더를 참고하세요. Python 3과 같은 최신 런타임에서 App Engine 번들 서비스 지원에 대해 자세히 알아보려면 기능 출시 공지와 모듈 17 Codelab을 참고하세요.

모듈 12의 보너스 단계를 완료하신 것을 축하합니다! Python 3 런타임을 위한 구성 파일 준비 문서도 참고하세요. 위의 요약/삭제 섹션에서 다음 단계와 삭제를 검토하세요.

8. 추가 리소스

아래에는 이 마이그레이션 모듈 또는 관련 마이그레이션 모듈과 관련 제품을 자세히 살펴보는 개발자를 위한 추가 리소스가 나와 있습니다. 여기에는 이 콘텐츠에 대한 의견을 제공할 수 있는 위치, 코드 링크, 유용할 수 있는 다양한 문서가 포함됩니다.

Codelab 문제/의견

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

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

마이그레이션 리소스

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

Codelab	Python 2	Python 3
모듈 1	코드	코드 (이 튜토리얼에서는 다루지 않음)
모듈 12 (이 Codelab)	코드	코드

온라인 참조

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

App Engine

• App Engine 문서
• Python 2 App Engine (표준 환경) 런타임
• Python 3 App Engine (표준 환경) 런타임
• Python 2 및 3 App Engine (표준 환경) 런타임 간의 차이점
• Python 2~3 App Engine (표준 환경) 마이그레이션 가이드
• App Engine 가격 및 할당량 정보
• 2세대 App Engine 플랫폼 출시 (2018)
• 1세대 플랫폼과 2세대 플랫폼 비교
• 기존 런타임 장기 지원
• 문서 마이그레이션 샘플 저장소
• 커뮤니티에서 제공한 마이그레이션 샘플 저장소

Cloud Memorystore 및 Cloud Datastore

• Cloud Memorystore 제품 페이지
• Redis용 Cloud Memorystore 문서
• Cloud Memorystore for Memcached 문서
• Cloud Memorystore (Redis용) 가격 정보
• Cloud Datastore 문서
• Cloud Datastore 가격 정보

기타 클라우드 정보

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

동영상

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

라이선스

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