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

1. 개요

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

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

Memcache를 사용하고 있지 않나요?

앱에서 App Engine Memcache를 사용하지 않는 경우 모듈 12~13을 건너뛰거나 이 Codelab을 연습하여 Memcache 이전에 익숙해지도록 할 수 있습니다.

다음 실습에서는

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

필요한 항목

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

설문조사

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

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

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

초급 중급 고급

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

<ph type="x-smartling-placeholder"></ph> 초보자 중급 숙련도

2. 배경

App Engine Memcache에서 마이그레이션하려면 모듈 1 Codelab에서 얻은 기존 Flask 및 App Engine Dataplex 앱에 해당 사용량을 추가하세요. 샘플 앱은 사용자의 가장 최근 방문 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 저장소 폴더 (FINISH)에 있는 코드와 유사한 코드로 마무리합니다.

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

모듈 1 시작 파일의 디렉터리는 다음과 같습니다 (개발자의 파일 또는 우리가 만든 파일).

$ 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를 가져오는 것입니다. 한 시간 동안 가장 최근의 방문 데이터를 캐시하기 때문에 한 시간의 초 수에 대한 상수도 추가하겠습니다. 변경 전의 코드와 변경사항은 다음과 같습니다.

이전:

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

app = Flask(__name__)

변경 후:

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와 다른 경우: 최근 방문을 저장하고 가장 최근 방문을 가져온 다음 한 시간 동안 캐시합니다.
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)

변경 후:

@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)

다음은 변경된 내용을 그림으로 나타낸 것입니다.

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

6. 요약/삭제

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

애플리케이션 배포 및 확인

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

우리가 한 것은 동일한 사용자의 사용자 경험 속도를 높이는 것뿐이었습니다. 새로고침하면 캐시에서 직접 결과를 가져와야 하므로 새 방문을 만들거나 Datastore를 가져오지 않습니다.

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

삭제

일반

이 작업이 완료되면 요금이 청구되지 않도록 App Engine 앱을 사용 중지하는 것이 좋습니다. 하지만 추가 테스트 또는 실험을 원하는 경우 App Engine 플랫폼에서 무료 할당량을 사용할 수 있으므로 이 사용 등급을 초과하지 않는 한 요금이 청구되지 않습니다. 이는 컴퓨팅을 위한 것이며, 관련 App Engine 서비스에 대한 요금이 부과될 수 있으므로 자세한 내용은 가격 책정 페이지를 확인하세요. 이 마이그레이션에 다른 Cloud 서비스가 포함된 경우 별도로 요금이 청구됩니다. 두 경우 모두 해당하는 경우 '이 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 서비스는 2가지 유형으로 제공되며, 유형마다 가격 책정 구조가 다르므로 요금과 관련하여 해당 사용량을 추적해야 합니다.
• 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의 쌍을 지원합니다.
• Cloud Memorystore (Redis용)는 App Engine Memcache보다 훨씬 더 풍부하고 심층적인 기능을 제공합니다.
• Cloud Memorystore를 사용하려면 Cloud Memorystore 서버를 설정하고 이를 Google Cloud VPC 네트워크에 추가한 다음, App Engine 앱이 해당 네트워크를 사용하여 Memorystore 서버와 통신하도록 해야 합니다.

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

모듈 13 이후로는 Cloud NBS, 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가 모두 지원 중단되었습니다.

변경 후:

방금 설명한 필수 변경사항이 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

변경 후:

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

변경 후:

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의 앱을 비교해야 하는 경우 이전 저장소의 모듈 12b 폴더를 참고하세요. Python 3과 같은 최신 런타임의 App Engine 번들 서비스 지원에 관한 자세한 내용은 기능 출시 공지 및 모듈 17 Codelab을 참고하세요.

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

8. 추가 리소스

아래에는 이 모듈이나 관련 이전 모듈 및 관련 제품을 자세히 살펴보는 개발자를 위한 추가 리소스가 나열되어 있습니다. 여기에는 이 콘텐츠에 대한 의견을 제공할 수 있는 곳, 코드 링크 및 도움이 될 만한 다양한 문서가 포함됩니다.

Codelab 문제/의견

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

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

마이그레이션 리소스

모듈 2 (START)와 모듈 12 (FINISH)의 저장소 폴더 링크는 아래 표에서 찾을 수 있습니다. 또한 ZIP 파일을 클론하거나 다운로드할 수 있는 모든 App Engine Codelab 이전 저장소에서도 액세스할 수 있습니다.

Codelab	Python 2	Python 3
모듈 1	코드	code (이 가이드에 포함되지 않음)
모듈 12 (본 Codelab)	코드	코드

온라인 참조

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

App Engine

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

Cloud Memorystore 및 Cloud Datastore

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

기타 클라우드 정보

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

동영상

• 서버리스 마이그레이션 스테이션
• 서버리스 Expeditions
• Google Cloud Tech 구독하기
• Google Developers 구독

라이선스

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