App Engine スタンダード環境のアウトバウンド サービス（URL Fetch API、Sockets API、Mail API など）は、IP アドレスの大規模なプールを使用します。このプールの IP アドレス範囲は、定期的な変更の対象です。実際、同じアプリからの 2 つの連続した API 呼び出しは、2 つの異なる IP アドレスから発生したように見えることがあります。 サービスからの送信トラフィックに関連付けられた IP アドレスを知る必要がある場合は、サービスの現在の IP アドレス範囲を確認するか、サービスに対して静的 IP アドレスを設定します。 App Engine サービス用の IP アドレス App Engine サービスの現在の IP アドレス範囲は、Google が公開している IP 範囲情報に基づいて確認できます。 Google では、インターネット上でユーザ
こんにちは。次世代システム研究室のM.Mです。 GAEに関するブログも今回で4回目になります。 前回はサービス公開に向けて必要となるドメインやロードバランサの設定について記載しました。 ただサービス公開にあたって必要となる作業はそれだけではなく、自動スケーリングの設定もしておく必要があります。 自動スケーリングの設定についてはスタンダード環境やフレキシブル環境のマニュアルに記載があるので、今回は設定についての説明ではなく、10000rpsまでリクエスト数を上げて自動スケーリングの検証をした際の結果を共有したいと思います。 1. 検証環境と検証内容 検証環境 スタンダード環境（F1インスタンス） Python, Flask 0.01秒スリープして、Hello World!を出力するWEBアプリ 初期インスタンス数は1000rpsを処理できる程度の数を設定。その他パフォーマンス重視設定(2.
ちょっと期間が空きましたが、1つ前のポストこのブログで使ってる WP テーマと追加したプラグインの話の続きの話です。 前回までで一通りブログの新サーバへの移行作業は完了し、想定外のエラーなどが発生していないか数日間様子を見ていたときのことでした。こんな弱小サイトでまさか発生しないだろうと思っていた課金が発生していたのです。といってもクレカを登録した際にもらった $300 が少し目減りした程度の話ですし、追加課金は許可していないので実際の課金が発生したわけではありません。 ただこのままでは $300 の有効期限が切れた後、課金が発生するタイミングで実際に課金が発生する代わりにエラーが発生するようになってしまうので、それは避けなければなりません。そこで課金の発生箇所を確認したところ、唯一フロントエンドのインスタンス時間が無料時間分を超えていました。 GAE はクラウドがベースのサービスなので、
Google App Engine（GAE）のフレキシブル環境へデプロイを行っていたところ、以下のようなエラーが発生しました。 ERROR: (gcloud.app.deploy) INVALID_ARGUMENT: The following quotas were exceeded: BACKEND_SERVICES (quota: 9, used: 9 + needed: 1). GAEフレキシブル環境では同時に起動できるバージョン数に厳しめの上限が設定されており、その制限を超えてしまったことが原因です。 定期的にトラフィックが流れていない古いインスタンスが自動停止されるようにしていたのですが、短時間に連続してデプロイしたことにより制限に引っかかってしまったようです。 対処法: トラフィックが流れていない提供中のバージョンを停止する 暫定対応としては、トラフィックが流れていない提供中
フィードバックを送信 予算と予算アラートの作成、編集、削除 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 Cloud Billing の予算を作成して、Google Cloud のすべての料金を 1 か所でモニタリングすることで、想定外の請求が発生する事態を回避します。予算により、実際の Google Cloud の費用を予定費用と照らし合わせて追跡できます。予算額を設定したら、メール通知のトリガーに使用する予算アラートしきい値のルールを設定します。予算アラートのメールにより、予算に対する費用の追跡に関する最新情報を常に取得できます。また、予算を使用して費用管理レスポンスを自動化することもできます。 図 1: 予算アラート通知のデフォルト機能、さまざまなオプションおよび使用について示しています。 Cloud Billing の予算の場合: 予算の期間を指
公開日: 2019.7.23 Google Cloud Platformのサーバーレスサービス・GAE(Google App Engine)の「サービス」機能を使って、1プロジェクトで複数アプリを複数ドメインで運用する方法をまとめました。 編集ノート:SERVERSUSでは、パートナーリンクからコミッションを得ています。コミッションが記事の意見や、サービスの評価に影響を与えることはありません。 GAEのサービスとはGAEでアプリをデプロイすると、デフォルトでは1プロジェクトに対して1つのアプリ・ドメインしか適用できないように錯覚します。 しかし、GAEには「サービス」という概念があって、アプリをデプロイする際にサービスを指定することで、複数のアプリを同時に立ち上げることができます。 また、各サービスにドメインを割り当てることもできるので、サービスを使いこなすことで、複数アプリを複数ドメイン
はじめに コマンドでGoogle App Engineを停止する。 前提条件としてgcloudコマンドがインストールされてあること。 script #!/bin/bash set -eu env=$1 method=$2 # allocations ID取得 ID=$(gcloud app services describe $1 | tail -n1 | awk '{print $1}' | sed "s/://g") echo $ID if [ $method == 'stop' ]; then gcloud app versions stop $ID -q elif [ $method == 'start' ]; then gcloud app versions start $ID -q else echo ‘check your parameter’ fi gcloud app v
初めまして、最近お客様にフォースがないアピールをするためにトルーパーに変身したg-yamaです。 今後トルーパーと名乗ります。 (画像欠けているけど) GAE上で個人ブログを構築し運用しているのですが、GCPのベータ版機能：Serverless NEG（Network Endpoint Group)を使ってみたくなり、ブログに適用する前に検証してみたので、記事にしました。 運営しているブログ ヤマログというブログを運営しています。 https://yamavlog.com/ GCPで触ったことなどの備忘録を書いていますが、たまにガジェットネタなんかも書いています。 ※GAEでWordpressを構築する方法や今回のServerless NEGに関する記事もこちらに書いています。 Serverless NEG（Network Endpoint Group)って何？？ 端的に言えば、GCPのロ
GAEのベータ機能として8/24より登場した「ファイアウォール ルール」 これまでもGAEでは dos.xml や dos.yaml を設定することによって、IP アドレスのブラックリスト登録をすることはできました。 しかし、dos 設定は、登録できるルールは100件まで、特定の IP アドレスのみを許可する設定はできない、などあまり使い勝手のよいものではありませんでした。 例えば、特定の IP アドレスのみを許可したい場合はアクセスしてきた IP アドレスをアプリケーション内でチェックして許可/拒否 の処理をする必要があったため、アクセス分がそのまま処理コストとなっているなど、GAEにおけるIP制限は課題がありました。 そんな課題を払拭する、GAEの新機能（結構珍しい）「ファイアウォール ルール」はクラウドコンソールやコマンドラインから容易に操作出来るIP制限機能です。 クラウドコンソー
イメージとしては スタンダード環境の方が気楽にはじめられる フレキシブル環境の方がより細かな設定ができる という感じでしょうか。 「料金が安いのはスタンダード」とは限らない ググって見つかる情報を読むと、多くの人は「スタンダード環境の方が安く済みそうだ」という印象を持つと思います。僕もそのような考えから、当然のようにスタンダード環境を選んでいました。しかし、結果として、Zennの場合にはフレキシブル環境の方が料金は大幅に安く済むことが分かりました。 Zennの場合 具体例があった方が読んでいて楽しいと思うので、恥を捨てて実際にかかっていたGAEの料金を載せてしまいます。ほれっ。 ※ 料金の推移は、サービスへのアクセス数とはほぼ相関していない ピーク時には1万円/日近くいってしまっていますが、設定と環境を見直すと¥500/日くらいで済むようになりました。設定をミスらなければPS5を転売ヤーか
公開日: 2019.11.19 Google App Engine(GAE)のバックエンド環境である、フレキシブル環境とスタンダード環境の違いを見ていきます。 編集ノート:SERVERSUSでは、パートナーリンクからコミッションを得ています。コミッションが記事の意見や、サービスの評価に影響を与えることはありません。 Google App Engineの環境とは？Google App Engineには、フレキシブル環境とスタンダード環境の二つ環境があります。環境の指定は、app.yamlで、 env: standard とすることで、指定できます。 名前が違うだけでなく、中身も料金体系も全く異なるため、GAEでアプリをリリースする前にそれぞれの特徴を確認しておきましょう。 スタンダード環境の特徴スタンダード環境は、指定した言語のアプリを「GAEが用意するサンドボックス内で実行」する環境です。
リージョン ID REGION_ID は、アプリの作成時に選択したリージョンに基づいて Google が割り当てる省略形のコードです。一部のリージョン ID は、一般的に使用されている国や州のコードと類似しているように見える場合がありますが、このコードは国または州に対応するものではありません。2020 年 2 月以降に作成されたアプリの場合、REGION_ID.r は App Engine の URL に含まれています。この日付より前に作成されたアプリの場合、URL のリージョン ID は省略可能です。 詳しくは、リージョン ID をご覧ください。 App Engine アプリの設定を構成する際には、app.yaml ファイルを使用します。このファイルでは、URL パスとリクエスト ハンドラや静的ファイルとの対応関係を指定します。app.yaml ファイルには、ランタイムや最新バージョンの
今年もWACULのアドベントカレンダー、順調に埋まって、残すところ2日です。 クリスマスイブを担当する、CTOの包です。 なかなか濃い記事がいっぱいあって、よくもまぁこんな人達が集まったなぁという感慨深い感じです。 今日は妻と娘たちとケーキを作って食べました。ホイップクリームを泡立器で作ったら疲れたのでブレンダーがほしいです。 アクセス解析サービスを作ろう さてさて、今回は、(弊社のような)弱小企業に務めるあなたが、会社の偉い人とかに、Webサイトにいれるアクセス解析ツール作ってね！しかも一人で！ とか言われた時のために、GCPを使った構成を考えて検証してみました。 (あたなが、goとjavaをちょっと書けること前提です！) 検証なので、細かいエラー処理などは省いていますのでご了承を。 アクセス解析ツールの構成部品 Webのアクセス解析ツールを作るにはほんっとざっくり言うと 何はともあれ、
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? GoogleのSVP、Urs Hoelzleが「いま世界でもっとも人気のあるスマートフォンアプリ」と評し、Facebookによる3000億円の買収提案をスルーしたとされるSnapchat。その共同設立者でCTOのBobby Murphyが、3/25に開催されたGoogle Cloud Platform Liveに登場し、“Snapchatを支える技術”としてのGoogle Cloud Platform (GCP)の使い所や開発体制をかなり具体的に説明していたので、補足と解説を交えながらざっと意訳してみた。 SnapchatのCTO, B
appengine ja night11で紹介した裏技１について、もうちょっときちんと測定した結果を書いときます。 limit無し測定で使ったプログラム List<Key> keys = null; log.info("log 0."); keys = Datastore.query(getMeta()).query().asKeyList(); log.info("limit無し. :" + keys.size()); limit有り測定で使ったプログラム List<Key> keys = null; log.info("log 0."); keys = Datastore.query(getMeta()).query().limit(110000).asKeyList(); log.info("limitあり. :" + keys.size()); データ件数100,450件での測定結
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く