GAE

GAEでPythonアプリケーション（Google Analitics Engine でサービスつくりはじめの事始め）

  /
google app engine

GAEでの開発イメージを掴む為に、下記書籍により学習中。
今流行りのPythonを用いての開発例が掲載されていて、大枠の流れを掴むのに参考になりました。

FTPでファイルを直接ぶち上げてたところから、もう少しそれぞれモダンな開発環境に近づいていきたいと考えています。
いろんなクラウドサービスありますが、GCPにしたのは、会社が Google Workspace（旧G Suite）を契約しているので、Google関連で相性がいいというか、Googleということでイメージが湧きやすいかなと。

GAEでアプリケーション開発！？イメージ分かないな～というところから、
ああ、こんな感じか～！となるところまでを目指してます。

最初はやれデプロイやらApp Engine…？とかはちんぷんかんぷんでしたが、いろんな角度から触れてみてちょっとずつは分かってきたような気がします。
上記の本の中でも、特に気になったトピックをざっと学習がてらまとめていきたいと思います。

紹介されているサンプルを動かすにあたって、ちょっとイメージが湧きにくかったのがGoogle Cloud Shell　での操作イメージ。
また、同じようにブラウザから操作できるコードエディタの存在。
これらを使うとファイルを作成したり、編集したりできるけどこれらのファイルってどこにあるの！？と。

この点に対し結論から言うと、Googleアカウントを作成し、Google Cloud Platformを利用しようとした際は無料で使用できる5Gの容量がクラウド上に割り振られるようです。

なので、GCP上に、GCPの各種サービスを操作する為の画面と、ファイルをおける格納庫がありそこから操作ができるということですね。
そこの操縦室が、GCPの各種画面だと思うとちょっとガジェットっぽくて楽しいですね。
この操縦室に入るには請求者情報を登録しないといろいろ見れる画面が限られてしまいます。
操縦室提供するのも無料じゃねぇんだぞ！
というGooge先輩からのメッセージなのでしょう。

まあ、すぐにはイメージが沸かないにしてもサーバー一台立ち上げるような事がサクッと出来ちゃうような環境になるのでそれぐらいは必要になる気がします。

んで、ここからその見ること事態は無料の操縦室を見つつ、GAEを使用し、ちょっとしたアプリケーションをつくるところを見ていってみたいと思います。

GCPの各サービスに細かい指示をできるGoogle Cloud Shell

Google Cloud Shell（移行、クラウドシェル）はブラウザベースのコマンドラインツール。
見た目がターミナル、あの、黒い画面でコマンドを入力するところの画面、コマンドプロンプトに似ている。

裏側でGCE（Google Cloud Engine）の仮想マシンが起動している。
Debian GNU/LinuxベースのLinuxOSのイメージが使用されている。
GNUは、GNUプロジェクト　フリー。（この用語をちゃんと理解しょうとすると、これまた長くなりそう）

GCPに指示を出す機械にインストールされている主要プログラム、ツールの例

インストールされているプログラム言語の例

Python
Java
PHP

ツール

Git
Docker
Gradle（オープンソースのビルドシステム）

これらがセットアップされたマシンを、ブラウザから操作することができるということ。

ざっくりいうと、Googleアカウントに紐付いた、無料で容量もクラウド上にある自分用端末。
自身が管理するリソースを、この画面から管理することができる。（容量は5Gまで無料）

使いこなすにあたって大事そうなポイント

課金条件を設定すること

実際につくっていく前に　モダンなアプリケーションとは！？

モダン、モダンというけれど、何をもってモダンか！？というところは確かに
ちゃんと考えてことはなかったなー！

2020年時点では、モダンなWebアプリケーションはクライアントサイドレンダリングを行うことを
指すように感じる。

静的なHTML

サーバー側でHTMLまで生成、それをクライアント側に返す

モダンな開発であろうクライアントサイドレンダリング

現在はサーバーはAPIエンドポイントを用意し、クライアントのリクエストに対し、JSONを返す。
レスポンスを受け取り、クライアント側でビューを組み立てる。
と、いう手法。

クライアントサイドレンダリングの流れ

ブラウザからサーバーにリクエスト
↓
プログラムがDBにアクセス
↓
プログラムによりJSONを生成

新しいサーバーサイトレンダリングの手法もある。
サーバーサイドでJavaScriptを実行、HTMLを生成して返す方法。

RESTの原則

RESTの法則に従って構築されたシステムの特徴をRESTfulと呼ぶ

ステートレス

stateless。状態がないこと。

HTTPのメッセージにすべての情報が含まれている
クライアント・サーバー間で状態を管理する必要がない
よって、サーバーがクライアントがどのような状態が知らなくてもよい。

HTTPのメソッドでリソースのアクションを決定する

GET、POST、PUT、DELETEでリソースの取得、作成、更新、削除を指定する

URLでリソースを識別する

すべてのリソースは一意なURL（厳密にはURLではなくて、URI）
他と被らない呼び出し先を指定する、的な。
また、確かにそうじゃなきゃ、という感じです。

半構造化データフォーマット

HTML、XML、JSONなどのフォーマットを扱い情報のやりとりを行う。

半構造化データ（Semi-Structured Data）。
非構造化データに「フレキシブルな構造」を与えたものと定義される。
説明しようとすると、どんどん難しい用語がむしろ増えてしまっていますね。。。！

URLにリソースの所在地と、条件を指定する

RESTfulではこのURLを使用し、対象となるリソースに、どんなアクションをするかを
HTTPメソッドで指定する！

HTTPメソッド使い分けの例

  • GET　リソースの取得
  • POST　リソースの作成
  • PUT　リソースの更新
  • DELETE リソースの削除

作成するWeb APIの例

こんな感じになるのかーとイメージを掴むのによいですね！

|機能|メソッド|URL|詳細|
|----|----|----|----|
|list|GET|/api/examples/|Exampleデータを全件返す|
|get|GET|/api/examples/<KeyID>|KeyIDと一致するExampleデータを返す|
|insert|POST|/api/examples/|Exampleデータを作成する|
|list|GET|/api/greetings/|Greetingリソースを全件取得する|
|get|GET|/api/greetings/<KeyID>|KeyIDと一致するGreetingリソースを取得する|
|update|PUT|/api/greetings/<KeyID>|KeyIDと一致するGreetingリソースを更新する|
|deleate|DELETE|/api/greetings/<KeyID>|KeyIDと一致するGreetingリソースを削除する|
|listComment|GET|/api/comments?parent_id=<ParentID>|ParentIDと一致するCommentリソースを取得する|

WSGI規格

Pythonにおいて、Web Server Gateway Interface（略して、WSGI）はWebサーバーとWebアプリを接続するためのインターフェイス規格。

Flask

Pythonで書かれたマイクロWebアプリケーションフレームワーク。
– データベースへのアクセス
– テンプレートエンジン
– フォーム処理
– セッション管理

などなど、動的なWebサイトに共通して利用される機能の開発をサポートしている。

  • データベースアクセス
  • フォーム処理
  • テンプレートエンジン
    などなどは、コアとは別の拡張機能として提供される
    そのため、マイクロWebアプリケーションフレームワーク、とマイクロがつく。

Jinja2

Jinja2はFlaskをインストールすると同時にインストールされている。
Jinja2では{%…%}や{{…}}などの制御文が用意されている。

  • {%…%}
    ifやforなどの構文が用意されている

  • {{…}}
    Pythonでコードで定義された変数の内容にアクセスできる

エラーコード

この書籍では参考として、

ログ

アプリケーションログを取得する「

プログラムが正しく動作していない場合はログを確認して問題の手がかかりを得て修正してゆく。
その際、参考とするのがログ。

GAEにはリクエストログ、アプリログがある。

  • リクエストログ
    リクエストごとにApp Engineによって自動的に書き込まれるログ

  • アプリログ

アプリから任意のデータやメッセージを出力させることができるアプリログがある。

開発環境ではクラウドシェルのようなアプリを実行したターミナルの標準出力で確認できる。
本番環境ではStackdriver Loggingの画面から確認できる。

ログを出力する方法

Python logging モジュールを使用した方法
Logging Client Librariesを使用した方法
Cloud Logging Handler を使用した方法

もっともシンプルなのが、Python logging　でこの本では　Python logging　モジュールを使用した方法を紹介されている。

GAEにはログを出力するためのAPIが用意されておりアプリログはPythonの標準モジュールloggingを使用して出力することができる。

設定して、コンソール画面からログの確認を行うことができる。

[メニュー一覧]→[Logging]→[Logs Viewer] から確認することができる。
※2020年12月時点では　ログ　ダッシュボード　のことを指す？

Exceptionログの出力
エラーハンドラや例外があって、エラーのストックトレースを行いたい場合は
logging.exceptionメソッドを使用する。

エラーをコントロールし、発生したらきちんとログに残すようにする。

@app.errorhandler(404)
def error(exception):
    logging.exception(exception)
    return {`message`: 'Error: Resource not found.'},404

みたいに、記述することで404エラーの際にはエラーメッセージを表示することができる。

Cloud Datastoreって？

GCPの代表的なデータベースサービスの一つ。

現在、Cloud Firestoreの機能の一部が、現在はCloud Datastoreの機能を置き換えている。

「Cloud Firestore」はNoSQLデータベースサービス。
モバイルやWebアプリのバックエンドでよく使用されている。
柔軟な運用が可能で、スケーラブル。
つまり、リクエスト量の増減に対応可能ということ。

ネイティブモードとDataStoreモードがあり、以前のCloud Datastoreは現在はCloud FireStoreのDatastoreモードに置き換えられている。

GAEではCloud FirestoreのDatastoreモードというオブジェクトデータベース型のデータ・ストレージの使用が推奨されている。

2014年にGoogleが買収した、Webアプリケーション開発プラットフォームとして「Firebase」がある。
その代表的な機能として Realtime Database という機能がある。

これは、NoSQLデータベースで、データを一つの大きなJSONツリーとして保存する。
クライアントとリアルタイムに同期したり、オフラインの同期にも対応しているのが特徴。

「Cloud Firestore」のネイティブモードはRealtime Databaseの特徴を引き継ぎ、より高度な機能を兼ね備えている。

一方、Cloud DatastoreはGCPの古くからあるKVS（Key Value Store）タイプのデータベース。
ざっくり流れを説明すると

ただのDatastore・GAEのデフォルトデータベースとして登場
↓
Cloud Datastore に変更・GCPプロダクトの一つに
↓
GAEからじゃなくても利用できるように
↓
Cloud　FirestoreのDatastoreモードがリリース
↓
Cloud　FirestoreのDatastoreモードがCloud Datastoreの最新バージョンに
↓
Cloud Datastoreの最新バージョンはCloud　FirestoreのDatastoreモードになる予定

以前のCloud Datastore

優れた自動スケーリング機能を備える代わりに
– クエリは強整合性を保証しない
– 1つのエンティティグループに対する書き込みは1秒間に1回だけ
– 1トランザクションに対するエンティティグループ数は25まで
などの制限あり

それに対し、Cloud FirestoreのDatastoreモードは！？

Cloud Datastoreの自動スケーリングと高パフォーマンスを引き継ぎながら、これの制限を解消！

よって、

  • Cloud FirestoreのDatastorモード
  • Datastore

は別だけど、公式ドキュメントは上記をひとまとめでDatastoreと表記されていたりする。

んで、上記を改めてまとめると

Datastoreの特徴

  • NoSQL
  • スキーマレス
  • フルマネージドサービス

Cloud Datastoreを用いてGAEで公開したいサービスをローカルで動かす

デプロイせずにローカル環境で実行するとエラーとなる。

「permission is hereby granted free of charge to any person obtaining」
みたいなエラーが出る。

なぜ、こんなエラーが出るかというと、ローカルで実行しているPythonアプリがCloud Datastoreへのアクセス権限がない為。

では、なぜデプロイしているアプリからはアクセスできるのか？
GCPにはApplication Default Credential（ADC）という仕組みが用意されており、それに従いアプリのアクセス権限を確認する為。

有効なアクセス権限は次の順番で確認される。

  • 環境変数GOOGLE_APPLICATION_CREDENTIALSが指すサービスアカウントファイルを使用する
  • 環境変数が設定されていない場合は、App Engineが提供するデフォルトのサービスアカウントを使用する
  • どちらでもない場合はアクセス検眼がなしと判断、エラーが発生する

ローカル環境からDatastoreへアクセスするには！？

そもそもローカル環境で動作しない理由

クラウドで動くアプリにはデフォルトのサービスアカウントが使用される。
しかし、ローカル環境で動作するアプリにはサービスアカウントがない為動作しない。

サービスアカウントはプログラムに与えられるIDのこと。

GCPのリソースにアクセスする方法として、

  • gcloudコマンド
  • クラウドコンソール
  • Google Client Library

などの手段があり、いずれも裏でGCPのAPIを利用している。

Cloud IAMが誰がどのリソースに対してどんなアクセス権を持っているかを管理しており、誰が、という部分は人間以外、GAEアプリなどに対しても指定できる。
GAEアプリのようなプログラムに、Googleアカウントを発行することでアプリに権限を与えることができ、アプリに発行するアカウントの事をサービスアカウントという。

デプロイしたGAEアプリがDatastoreにアクセスできるのは、デフォルトで用意されているサービスアカウントを使用しアクセスしている為。
特に変更しない限りはこの通称デフォルトサービスアカウントを使用するように設定されている。

サービスアカウントの確認方法

ナビゲーションメニュー　→　IAMと管理　→　サービスアカウント

そして、ローカルで動作させるには！？

ローカルで動作するアプリにサービスアカウントを設定することで、ローカルでも実行できるようになる。
準備として、サービスアカウントのキーをダウンロードしておく。

GAEのデフォルトサービスアカウントの「操作メニュー」をクリックし、「鍵を作成」を選択する。
↓
キータイプで「JSON」を選択、作成ボタンをクリック
↓
秘密鍵がパソコンに表示されました、というダイアログが表示される。
「credentials.json」という名前で保存。
↓
ローカルのアプリが参照できる場所に、「credentials.json」を格納。
↓
環境変数「GOOGLE_APPLICATION_CREDENTIALS」を作成

export GOOGLE_APPLICATION_CREDENTIALS="$HOME/gae-study/credentials.json"

環境変数は、OSの環境をカスタマイズするためのシステム変数。
極端な例えだと、OSで使用できる「変数」。

要チェックポイント!!

デフォルトのサービスアカウント権限が強すぎるよ！
実際に運用するサービスでは、アプリごとにサービスアカウントを作成し、最小限のアクセス権限を付与して運用していくのがベター。

Datastoreのエミュレータ

ローカルで実行しても、データは実際にクラウドに送られてします！
そんなときはエミュレータ！

公式ページ

しかし、設定は複雑そう。

Google Cloud Storage

GCPでサービスを提供していくと、データがストレージに蓄積されていく。
GCPには代表的なストレージサービスとして、Google Cloud Storage（以下、GCS）がある。
GCSは主にバイナリファイルの保存場所として使用される。

AWSで言うところのS3に相当するようなサービス。

保存されるデータの例

  • クライアントからアップロードされたファイルの保存
  • バックアップファイルの保存
  • アプリで使用する画像や動画などの保存

GCSのリソースは、プロジェクトに属している。
GCSを使用するにはプロジェクトにバケットを作成する。
そして、その後バケットにファイルをアップロードする。
そうしてアップされたファイルはオブジェクトと呼ばれる。

バケットとオブジェクト

バケット

オブジェクトの入れ物。バケット（Bucket）はバケツ、とかおけ、とかの意味。
バケットの名前は全世界でユニークである必要がある。
バケットの名前には「google」が含まれていたり、「goog」で始まるものは作成できないなどの制限がある。

オブジェクト

バケットの中に入れるものがオブジェクト。
実際のファイルとなる。
オブジェクトはイミュータブル（immutable）となる。
イミュータブルは不変の、不易の、といった意味。
つまり、更新はできず、更新の代わりに削除・作成となる。
反対にミュータブル（mutable）は変わりやすい、といった意味。

オブジェクトはバケットの直下にフラットに配置される。
ファイルシステムのようなフォルダという概念がない。
代わりに、名前に”/”を入れることで、表示上はフォルダのように使用することができる。

よって、GCSのAPIにフォルダを作成する・フォルダ内のオブジェクトを取得するといったAPIは存在しない。

コンソール画面には「フォルダ作成」ボタンがあるが、実際にフォルダが作成されるわけではない

目的に応じて使い分けたいストレージクラス

GCSはオブジェクトを入れてリ出したりする操作アクセスに対して発生する費用と、ストレージとして保存にかかる料金がある。

どちらが多くなりそうか、で使い分けたいのがストレージクラス
ストレージクラスとして、下記のようなタイプがある。

  • Multi-Regional Strage
  • Regional Storage
  • Nearline Strage
  • Coldline Strage

Regionalは地域の、地方の、地方的な、局部的な、といった意味。

Nearlineはオンラインと、オフラインの中間、といった意味。
常時の運用と即時の応答性を要求されるオンラインシステム（online system）と、必要になる毎に準備して使用されるオフラインシステム（offline system）の中間を求める際に活用。

Coldlineは更に、常時オンライン性を求めなくても～といったシステムの際に活用される。

[公式ページ：ストレージ クラス]（https://cloud.google.com/storage/docs/storage-classes?hl=ja#dra）

|頻繁にアクセスするデータを保存| Multi-Regional or Regional|操作費用が安く、ストレージ料金は高い|
|主にバックアップ用途|Nearline or Cold|操作費用が高く、ストレージ料金が高め|

米国リージョンは5Gまでは無料で使用できる
※費用については頻繁に変更される為、最新は公式をチェック！

GCSのオブジェクトに対してアクセス制御できるよ

GCSのIAMの役割

  • どのバケットを読み込むか
  • ファイルをアップロードできるのか
  • 削除できるのか

これらは、IAMの「枠割」で制御できる。
役割は

  • プロジェクト全体
  • 特定のバケット

に適用できる。
アカウントが持つ役割によって、GCSのバケット、オブジェクトに対して利用可能な操作が異なってくる。

  • プロジェクト編集者の役割をもっているユーザーの場合
    すべてのバケットとオブジェクトに対して、作成、削除、閲覧が可能

プロジェクトに対する役割はコンソール画面のIAMから設定できる。

※ストレージオブジェクトの作成者や、ストレージオブジェクトの閲覧者のような、GCSすべてのオブジェクトに対するアクセス権を有した役割もある

もう少し、細かく範囲を指定する方法としてアクセス制御リスト（ACL：Access Control List）を用いて、個別に設定する方法がある。

これにより、例えば、ダウンロードやアップロード専用のバケットを用意し、GAEアプリやGCEからのアクセスは許可する、といった設定を行うことができる。

  • 特定のユーザーやグループに対するアクセス権を設定する　→　ACL
  • GAEのWebアプリからのダウンロードやアップロードを設定する　→　サービスアカウント

簡単に、練習としてコマンドラインからバケットを作成したり、公開したりが行われている。

GAEからGCEを操作してみる

GCEへのアクセスは基本、APIを使用する。
（コマンドラインツールやコンソール画面からの操作でも、裏側ではAPIが使用されている）

GAEのアプリプログラムから操作するには　Google Cloud Client Library を使用する。
これは、複雑なAPIの呼び出しを、代わりに行ってくれる。

事前準備、Google Cloud クライアントライブラリをインストール

まず、Google Cloud クライアントライブラリをインストールする。
GCEを操作するライブラリ名は google-cloud-strageという名称だけど、このライブラリを使用するには google-cloud-core というライブラリも一緒にインストールする必要がある。

ファイルをGCSにアップロードしてみる

クライアンからPOSTされたファイルをGCSに保存する流れ

# かきが動作するにはいろいろ設定が必要だけど、ここはあくまでの流れを確認する用

from google.cloud import strage

# フォームから送信（POST）されたファイルを取得する
# リクエストパラメーターから取得
upload_file = request.files['file']

# Cloud Strage Clientオブジェクトの作成
client = strage.Client()

# 使用するバケットを取得
bucket = client.get_bucket('<バケット名>')

# バケット内に作成するオブジェクトの名前をファイル名と同じにする
blob = bucket.blob(uploaded_file.filename)

# バケットにアップロードする
blob.upload_from_file(upload_file)

※GAEはリクエストを1分以内に処理しないといけないという制限がある為、ファイルが重いとタイムアウトして失敗する。その際はCloud Tasksと併用して対応する

GCSからファイルを取得してみる

コードの例

client = strage.Client()
bucket = client.get_bucket('<バケット名>')
for blob in bucket.list_blobs():
    logging.info(blob.name)
    logging.info(blob.public_url)

その他

  • OAuthによるユーザー認証
  • 時間のかかる処理をバックグランドで行う
  • 定期的なスケジューリング処理
  • リレーショナル・データベースの使用
  • キャッシュサーバーの使用
  • リクエストの監視
  • データ収集と分析
  • アプリへのAI（人工知能）導入

Cloud Identity-Aware Proxy（Cloud IAP）とは

GAEやGKE（Google Kubernetes Engine）、GCE（Google Compute Engine）などで実行されているアプリへのアクセスを管理することができる。

Cloud IAPはアプリのインターネットフロントエンド（ユーザーが触れる部分）として機能する。
Cloud IAPのレイヤーで、ユーザーのIDを確認したうえでアプリへのアクセスを許可するかどうかをユーザーIDを使用し、判断する。

IAPにより、アプリに対してグループベースのアクセス制御が可能になる。
それにより、DoS攻撃（（Denial of Service Attack））の問題などを解決できる。
DoS攻撃は悪意を持ってサーバーに大量のデータを送りつけるサイバー攻撃のこと。

Cloud Identity-Aware Proxyの使い方

クラウドコンソール画面・gcloudコマンド・REST APIなどで設定する。

設定後、アプリのフロントエンドでユーザーのリクエストを監視・承認されている正しいリクエストだけをバックエンドで動作するアプリに送信する。

Cloud Task

GAEはデフォルトではアプリが60秒以内にレスポンスを返さないといけないとう制限がある。

時間のかかる処理を行うとタイムアウトが発生してしまう。

最も簡単な方法はデフォルトの設定を変更して制限時間を伸ばすこと。
しかし、この方法だと処理が終わるまでひたすら待つ必要があり、ユーザビリティがよくない。

適切な方法として、バックグランドで動かす方法がある
フォアグラウンド（foreground、手前にある画面とか）でユーザーのリクエストを受け取り、バックグランドで重い処理を行うと、リクエストに対してはすぐレスポンスを返すことができる。

GAEではこの方法を実現する為、Cloud Tasksというサービスを提供している。
Cloud Tasksにより、デフォルトで10分、最大で24時間まで処理時間を伸ばすことができる。

Cloud Tasksの仕組み

Cloud TasksにはHTTPとGAEをターゲットにしたものがある。
以下はGAEをターゲットにしたCloud Tasksの例。

処理の流れは下記のようになる。

1.　Cloud Tasksにタスクキューを作成する
2.　タスクを作成しキューに追加する
3.　ワーカーがタスクを処理する
4.　結果を返す

1.　Cloud Tasksにタスクキューを作成する
タスクの作成はクラウドコンソールや、gcloudコマンドによって作成する。
作成するのは最初の一回だけ。

2.　タスクを作成しキューに追加する

task = {
        `app_engine_http_request`: {
            `http_method`: `POST`,
            `relative_uri`: url_for(`run_task`)
            `body`: `Hello Cloud Tasks!`.encode()
        }

クライアントアプリはバックグランドで処理してほしいタスクを作成し、キューに追加する。

キューは基本的なデータ構造の一つで、要素を入ってきた順に一列に並べ、先に入れた要素から順に取り出すという規則で出し入れを行うもの。
とにかく、先にお願いしたものからやっていってね！という感じ。

タスクはターゲットURLにGAEのタスクハンドラを指定してリクエストをPOSTで送信する。
すると、リクエストを受けバックグランド側にあるワーカー（処理する部分）が実際に処理を行う。
リクエストの中にはワーカーに渡したいデータを入れる。

3.　ワーカーがタスクを処理する
タスクが追加されると、Cloud Tasksはタスクを処理する為のワーカーを起動する。
実際の処理はワーカーが実行する。
GAEのタスクハンドラをターゲットにした場合はGAEで起動したワーカーがタスク（リクエスト）を処理する。

ハンドラ（handler）は扱う人、調教師、といった意味がありタスクハンドラはタスクのお願い、リクエストが来たら実行されるプログラムのこと。

似た言葉で「イベントハンドラ」があり、イベントハンドラはコンピュータプログラムで、特定の出来事（イベント）が発生した時に実行するよう定められた処理のことを指す。

4.　結果を返す
タスクの処理を行ったGAEのワーカーは処理結果をHTTPのレスポンスコードで返す。
200番台のステータスコードで返すと成功・それ以外は失敗を意味する。
デフォルトの設定ではCloud Tasksは処理が成功するまで再試行される。

よって、どこかのタイミングで必ずHTTPレスポンスコードの200を返すか、リトライ設定を変更・再試行回数を制限することなどを検討するとよい。

タスクが正しく処理されてない！？ひたすら再試行を繰り返している場合

そのようなときは手動でタスクを終了させる必要がある。
タスクの強制終了はクラウドコンソールから行う。

クラウドコンソール　Cloud Tasksの画面のキュー一覧へ
↓
キューを選択
↓
現在実行中のタスクが表示される
↓
チェックボックスにチェック
↓
画面上部の[タスクを削除]をクリック

cron ジョブのフルマネージドサービス・Cloud Scheduler

GAE 第2世代（GAE 2nd）では決まった時間に何かしらの処理を行うといったスケジューリングの機能はないため、
Cloud Schedulerのようなサービスを使用しスケジューリング処理を行う。

例えば、

  • アンケート結果の集計
  • 毎時実行されるバッチ処理
  • データのバックアップ

などなど。

Cloud Scheduler　はオートスケールする為、リソース不足などの心配もない。
エラーの再試行などの機能も備わっており、cronジョブが正常に行われなかったときの対策なども不要。

ただ、Cloud Tasksと同様デフォルトでは無制限に再試行するのでリトライポリシーの工夫が必要
無闇やたらに何度もリトライさせるな、ってことですな。

Cloud Schedulerの使い方

まずはジョブを実行してくれるターゲットを用意する必要がある。

Cloud Scheduler　はジョブを作成し、ターゲットに送信する。
ターゲットは次の3種類。

  • HTTP/Sエンドポイント
  • Cloud Pub/Sub トピック
  • App Engine アプリ

App Engine アプリをターゲットとした作成の流れは

  • ジョブを作成
  • App Engine HTTPターゲットを作成

となる。

おわりに

なんかクラウドは利用すると便利だし、いろいろよさそうだけど、どっから始めたらいいのか。。。
という感じでしたが分からないなりにちょこちょこサンプルつくってみると見えてくるものもありました。

こちらの書籍は一つ一つのサンプルがちょうどいい手頃感でよかったです。
また、GCPのコンソールの裏側ってDebianなん、、、という事も知る事ができました。
書籍ではもちろん、実装の工程について画面付きで解説してあるので興味のかる方はぜひ。

%d人のブロガーが「いいね」をつけました。