Google App Engineのスタンダード/フレキシブル環境を選ぶときのヒントと設定の注意点
イメージとしては スタンダード環境の方が気楽にはじめられる フレキシブル環境の方がより細かな設定ができる という感じでしょうか。 「料金が安いのはスタンダード」とは限らない ググって見つかる情報を読むと、多くの人は「スタンダード環境の方が安く済みそうだ」という印象を持つと思います。僕もそのような考えから、当然のようにスタンダード環境を選んでいました。しかし、結果として、Zennの場合にはフレキシブル環境の方が料金は大幅に安く済むことが分かりました。 Zennの場合 具体例があった方が読んでいて楽しいと思うので、恥を捨てて実際にかかっていたGAEの料金を載せてしまいます。ほれっ。 ※ 料金の推移は、サービスへのアクセス数とはほぼ相関していない ピーク時には1万円/日近くいってしまっていますが、設定と環境を見直すと¥500/日くらいで済むようになりました。設定をミスらなければPS5を転売ヤーか
Python3.7+Django2.1のアプリケーションをGoogleAppEngine/Standard環境にデプロイする - 偏った言語信者の垂れ流し
GoogleAppEngineのStandard環境でPython3.7のランタイムがベータ版で利用できるようになったので、試していました。 ドキュメントにはFlaskアプリケーションをデプロイする手順が記載されていましたが、Djangoアプリケーションだと少し設定が追加で必要だったので、メモを残しておきます。 ファイル構成 django-adminツールの startproject コマンドでは、 mysite という名前のプロジェクトを作成しました。 manage.py ファイルの階層にapp.yamlを配置しています。 ├── app.yaml ├── db.sqlite3 ├── manage.py ├── mysite │ ├── __init__.py │ ├── settings.py │ ├── urls.py │ └── wsgi.py ├── requirements.
Go Conference 2017 Springにスピーカーとして参加しました。 - Gunosy Tech Blog
こんにちは、新規事業開発室のエンジニアの高橋(id: @timakin)です。 先日開催されたGo Conference 2017 Springに参加しました。昨年度も個人的に参加したのですが、LT枠での参加でした。今回は通常トークの枠をいただけたので、もう少し長い時間発表者側として参加することができました。 発表内容 自分が発表した内容は以下のスライドです。プライベートでAPIを叩いたりウェブページをクロールしてくるサーバーを作っていて、途中経過ではあるのですが、その設計について話しました。 また、前回のGo ConferenceではGoogle App Engineの実用に関してのセッションが、大部分を占めていたのですが、自分は今回それを個人規模で使ってみたときの所感について話しました。 speakerdeck.com 他の方のスライドまとめをしようと思いましたが、すでにまとめをされて
Snapchatを支える技術：768台のRedisをGoogleクラウドで構築 #gcpja - Qiita
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
text.ssig33.com - 金くれを App Engine から heroku に引っ越した。
金くれを App Engine から heroku に引っ越した。 App Engine が値上げをするのでそれに対応した。 Twitter で App Engine の値上げの話で盛り上がっていて、課金履歴から新料金での課金額が分かるよという話だったので、見てみると金くれの場合新料金では一日 $1.5 ほど取られるとのことらしい。 話にならない。金が欲しくて作ったのに毎月 $45 も持っていかれるのは狂気の沙汰だ。 そこで App Engine から heroku に移行することにした。 App Engine 版のソースコードは紛失してしまっているのでスクラッチで作り直した。そもそも残っていたとしても App Engine に様々な部分が最適化されており(JRuby を使ってはいたものの)再利用は難しかったと思う。 データを標準の機能でエクスポートした。なかなか再利用の難しいデータがエク
Flying with Flask in Google App Engine | Francisco Souza
Wednesday, August 11, 2010 Flying with Flask in Google App Engine A little late, finally I introduce the third part of using Python frameworks in Google App Engine. I wrote before about web2py and Django, and now is the time of Flask, a Python microframework based on Werkzeug, Jinja2 and good intentions. Unlike Django and web2py, Flask is not a full stack framework, it has not a database abstracti
#appengine うそっ、私のMapReduce、遅すぎ？ - スティルハウスの書庫の書庫
Fredさんへの別件メール中で「Mapper API遅いなぁ〜」とちょっとグチをこぼしたら、「そんなはずはない」的なリアクションだったので、先日のテスト結果をお知らせしたところ、こんな返事が来ました： You can adjust the processing_rate to be higher. The default of 100 is to prevent you from eating through quota too quickly. In mapreduce.yaml (Python) you add: - name: processing_rate default: {some large number} We missed this in the documentation. Thanks for point this out. We'll fix that. Fredな
図解 インデックス爆発 - 後ろ回しゲロ
Google App EngineのDatastoreにはインデックス爆発という現象があります。 こちらで公式に説明されているのですが、 http://code.google.com/intl/ja/appengine/docs/java/datastore/queriesandindexes.html#Big_Entities_and_Exploding_Indexes 自分にとってはすごく分かりにくく、理解するのにとても苦労しましたので、自分なりにメモを残しておきます。 まず2,3の前提を。 基本的な事ですが用語が統一されてなくて惑わされましたw 複合インデックス＝カスタムインデックス＝コンポジットインデックス です。 またGoogle App Engine for Javaでは WEB-INF/appengine-generated/datastore-indexes-auto.xm
Google App Engineでコードを書くと、処理のひとつひとつが課金に見える
先週末、ちょっとしたプログラムをGAE/Jで動かして実際に使ってもらってみたのですが、そうすると、いままでテストでちょこちょこやってたときには全部のDaily Quotaが0%だったものが、数%の数字を示すようになります。 これを、ちゃんとプロモーションして多くの人に使ってもらおうとすると、課金が発生したり制限にひっかかったりしそうです。 で、たとえばDatastore APIの呼び出し回数がヤバいとして、API呼び出しを減らすためにキャッシュしようとすると、MemcacheのほうのAPI呼び出し回数がヤバくなってきます。 で、じゃあということでデータストアにデータを置くようにすると、保存量の制約で課金がかかってきます。で、それならと、データストアに置くのはシリアライズしたデータにしてデータ量が最低限になるようにすると、今度はその処理をするためのCPU時間で課金がかかってきます。 コードを
App EngineのLogをXMPPで飛ばす． - hidemonのブログ
Log をリアルタイムで見たい App Engineにはよくできたログコンソールがあり，フィルタリングとかもできるのだが，Webベースの悲しさ，必ずリロードしなければ最新の情報をみることができない． これを解決する素晴らしい記事がこちら．叢雲の歌：XMPPを使ったログの通知．LoggerのAppenderとしてXMPPメッセージを投げるものを作り，それを使ってすべてのログをIMで飛ばす．具体的には，GmailのChatウィンドウで読めるようになる． こりゃ便利． java.util.loggingでできないか こちらの記事では，ロギングライブラリとして，sl4jとlogback-classicを使っている．これをなんとか，AppEngine 標準のjava.util.loggingライブラリを使ってできないかというのを試してみた． 結論から言うと，できない．っていうか，できるんだけどすごく
GAE Testbed — GAE Testbed v0.12 documentation
Introduction¶ Writing web apps for Google App Engine is becoming really really easy. The App Engine team is releasing new things to make developing and deploying applications as easy as clicking “Deploy” on the SDK Console. However building test suites for your applications is a little bit tricky when you get into testing that you’re using the API correctly. This is where GAE Testbed comes in. Wha
GAEの設計指針めも - あおうさ＠日記
とりあえず思いつくまま列挙。まだまだ変わる可能性は大きい。 正規化しない。RDBMSでいうところのJOIN済みのでっかいテーブル作れ。 SELECTはがんばらない。INSERT超がんばれ。 PKはString型にしてgae.encoded-pkを使用する。 PKに複合キーは使わない。(コンポジットインデックス使わない) Date型のプロパティは使わない。String型にする。 プリミティブ型はnullを許容しないので使わない テーブル間のjoinができない。→正規化せずJOIN済みのでっかいテーブルを作る 集約関数がない（group byできない）、count()で全件カウントできない →集約したい値は、集約用のエンティティを用意してInsert時に集計値を保存する（最大値／最小値も同様） 毎回対象データをすべて取得してループで集計するのは非効率（また最大1000件の制限がある）集約したい
GAEのログ表示のタイムゾーンをローカルのものに変換するuserscriptを作りましたぞ - やればできる子の日記
GAEのログは米国の太平洋標準時で時刻表示されるので、非常にわかりにくいのです。一応issue trackerには改善要望が登録されているのですが、半年以上放置されてるのでGoogle様による実装は、その、ローマの人名風にいうとキタイウスという奴です。 なので、ローカルのタイムゾーンに変換するuserscriptを作りました。グリモン入れて使ってください。 http://userscripts.org/scripts/show/47857 適用前 ↓ 適用後 ところで、このuserscriptがまだ無かった(すくなくともuserscripts.orgには無かった)ことが驚きだったり……無いと困ると思うんだけど……。
ここが大変だよBigtableとGoogle App Engine
ここが大変だよBigtableとGoogle App Engine：分散Key-Valueストアの本命「Bigtable」（3）（1/2 ページ） RDBとは別の、クラウド時代のデータベースとして注目を浴びている「分散Key-Valueストア」。その本命ともいえる、Googleの数々のサービスの基盤技術「Bigtable」について徹底解説 月間3000万PVの大規模サイトの運用費が月額4万円!? 月間3000万PV相当の膨大なトラフィックを楽々とさばく大規模サイトが、月額4万円弱で運用されている。 Google App Engine（以下、App Engine）が普及するにつれて、そんな驚愕の国内事例も登場しつつあります。GClueがApp Engine上で実装したmixiアプリモバイルモバイルには、1日100万PV以上のアクセスが集中している状態でもサービスのレスポンス低下やダウンは皆無
Google App Engine入門：Datastore上で「ユニーク制限」を実現する方法
Google App Engine のDatastoreには、通常のリレーショナルデータベースと比べた時にいくつかの制限があるが、その一つが「このプロパティの値は常にユニークでなければならない」という指定（ユニーク制限）ができないことである。 Invoice IDのように自動生成するものであれば、アプリケーション側でなんとかすることも簡単だが、メールアドレスやハンドル名など、ユーザーが入力するものになると、ユニークであることをきちんと判定した上でEntityを作ることが必要になる。 もちろん、単純に「有無をチェックして、なければ作る」というプログラムではスレッド間の競合に対応できないので、そこはトランザクションを使ってアトミックに処理をする必要がある。 App Engine上でトランザクションを実現するには、エンティティグループという仕組みを使って行うが、気をつけなければいけないのは、エン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Loading...
ミリシタを支える GAE/Go
GAE/Go コトハジメ
2016年半ば現在のGoogle App Engine - write.kogu
CoolCoding.com is for sale | HugeDomains
