はじめに WASMをブラウザの外で動かすトレンドに関して「Linuxコンテナの「次」としてのWebAssemblyの解説」というタイトルで動画を投稿したのですが、動画では話しきれなかった内容をこちらの記事で補完したいと思います。 2022年もWebAssembly(WASM)の話題が多く発表されましたが、そのひとつにDocker for DesktopのWASM対応があります。FastlyやCloudflareもエッジ環境でWASMを動かすソリューションを持っていますし、MSのAKS(Azure Kubernetes Service)でもWASMにpreview対応しています。WASM Buildersでも2023年のWASMの予想としてWASMのアプリケーションランタイム利用に関して言及されました。 WASMといえば元々ブラウザ上で高速にC++のコードなどを実行するところから始まっている
Zennという技術情報共有サービスを作りました。有益な知見をシェアした開発者が、その見返りを得られるようなサービスにしたいと思います。気合いを入れつつも、時間をたっぷりかけて地道に育てていきます。 このページでは、Zennを支えている技術やサービスを紹介します。 フロントエンド Next.js フロントエンドにはNext.js（React）を使っています。開発当初はNuxt.jsを使っていたのですが、TypeScriptとの相性を考えてNext.jsへ移行しました。 技術情報共有サービスなので、主要な流入元はいずれ検索エンジンに落ち着くと予想しています。そのため、検索エンジンにインデックスしてもらいたいページはサーバーサイドレンダリング（SSR）しています。 動的コンテンツもキャッシュ Next.js 9.4からIncremental Static Regenerationという最高の機能
こんにちは！ Tech KAYAC Advent Calendar 2021 7日目を担当する荒賀(@ken39arg) です。 カヤックのエンジニアブログには2008年にPHPを使ったガラケー関連の記事を書いたのが最初になります。 それから10年以上たち、ガラケーも弊社でのPHPのプロジェクトもほぼなくなり、メンバーもかなり入れ替わり、私自身も20代だったのがついに40歳になりました。そんな私にとってこのアドベントカレンダーは私は今でもここにいるよというPingのような役割になっているため、年に一度若者に混じってアドベントカレンダーに参加しております。 例年ですと、趣味のマラソンなどに関する実績も書いているのですが、昨年同様、今年も続くコロナ禍により多くの大会が中止となったためこちらに関しては特に特記すべき実績はありません。ただ2020年に走るはずだった東京マラソンは権利は移行を続けてお
yaml、どうしてこんなに使われているのだろうか。kubernetesにも責任があるというのはありそうな話だけど、色々考えてみるとそこまで簡単な話でもなさそうな気がする。例えばtravis-CIの設定ファイルがyamlであったりというように、この分野ではyamlは割と広く使われていたんじゃないかという気がする。思い起こせばGoogle AppEngineもapp.yamlに設定を書いていたし、設定にyamlというのは割とよくあることであった、のではないかなあ。 しかしなぜyamlなんだろうか。yamlのフォーマットには問題がたくさんあることが知られているし、自分も全く好きではない。 例えばyamlの問題の一つとして、キーに任意のデータ構造を持ってこれるという話があり、これが一部のプログラミング言語で問題を厄介にしている。またエイリアスがあってデータ構造がツリーにならない（複数の経路から同じ
ZennではフロントエンドにNext.jsを使っています。もともとはVercelで動かしていたのですが、2021年3月にGoogle Cloudに移行しました。今回は移行を決めた理由や、具体的な構成、移行作業などについて書きたいと思います。 なぜ移行したのか Next.jsのデプロイ先としてVercelは圧倒的に優れています。ISRやImage OptimizationといったNext.jsの強力な機能をサーバー側の追加設定なしで使用できますし、CDNでの静的ファイルのキャッシュなども特に意識しなくてもいい感じにやってくれます。 Vercel以外にデプロイするとなると、Next.jsの一部の機能がうまく動かなかったり、パフォーマンス・チューニングを自分で頑張る必要があったりと自分で面倒を見なければならない部分が多くなります。 しかし、Zennのケースでは以下のような理由からVercelから
Zennは、Next.js + Ruby on Rails（APIモード）を Google Cloud の App Engine へデプロイして稼働していました。最近、Rails の実行環境を App Engine Flexible から Cloud Run へ移行したので、その記録を残します。 ロードバランサーのバックエンドサービスを付け替えることで実現 最初に、どうやって移行したかです。Zennのバックエンドはもともとロードバランサーで構成されていました。以下の図のように、ロードバランサーの Backend Service より背後を切り替えることにより実現しています。Cloud Run とそこにアクセスするための Serverless NEG はあらかじめ稼働させておくことで、ダウンタイムなしで切り替えられました。 参考：負荷分散 | Google Cloud https://clo
Google Cloud で何かアプリケーションを動かしたい時、いつも App Engine (GAE) を第一の選択肢として挙げています。 なのにみ〜んな Cloud Run に行ってしまう。なぜなのか?? 確かに Cloud Run のほうが新しくて公式に露出が多いし、GAE はこういうランディングページからの言及も消えているので無理もない。Google Cloud 的にもあんまり使って欲しくない雰囲気が漂っている。 cloud.google.com App Engine は GCP 最初期からあるサービスで今年で 14 年目になるらしい。 当時学生だった僕はすげーのが出たぞと聞いて GAE を触っていた記憶がある。その頃は Google App Engine 単体で出ていて、他のサービスが続いて Google Cloud Platform になったような気がする1。 そんな歴史あるサ
Cloud Run CPU 0.08 ~ 8 Core (2nd gen は最小 0.5~) Memory 128 MiB ~ 32 GiB (2nd gen は最小 512MiB~) Deploy App Engine は Deploy (gcloud app deploy) を実行すると Cloud Build が暗黙的に動いて Deploy が行われるが、これがなかなか時間がかかる。 開発環境だと CI でとりあえず main branch に merge されたら、Deploy したりするけど、Deploy を Skip してもよいような時でも CI 回してると Deploy を待つことになって、ちょっとめんどうに感じる。 更にこの仕組みは成果物は Deploy しないと生まれないので、CI と CDを分離しづらい。 Cloud Run は Container Registry a
この記事はこの記事は Google Cloud Japan Customer Engineer Advent Calendar 2019 の 12日目の記事です。 はじめにGoogle Cloud Platform (GCP) でバッチ処理を起動するための以下のパターンについてご紹介したいと思います。以下、８パターンあげてみました。とはいえ、最後の3つは GCP のバッチスケジューリングという観点からは少し外れますが、バッチの起動時に使われるということでご容赦を。 Cloud Scheduler : フルマネージドな cron ジョブスケジューラです。フルマネージドという点が非常に大きなメリットであり、多くの処理を自動化し実行することが可能です。Google App Engine cron サービス : HTTP GET を利用して、特定の URLを呼び出します。Google AppEng
クソアプリ2 Advent Calendar 2019の20日目の記事です。 作ったもの Barcode The Gathering https://barcode-the-gathering.appspot.com/ バーコード（QRではない、商品についてる一次元バーコード）から、ギャザのカードを生成できます。 異なるバーコード3枚スキャンするとデッキとして保存出来ます。 簡単な創作ルールでランダム対戦も行えます。 なんで？ 皆さんはMagic:TheGathering®︎1（略称 ギャザ）をご存知だろうか。 トレーディングカードゲームの元祖であり、「世界でいちばん遊ばれているTCG」を筆頭に７つのギネス記録を持つカードゲームである。 日本では遊戯王やポケモンカードゲームの認知度が高いが、それらは全てギャザが元となっている。 そんなギャザのカード情報を取得するAPIが存在することを知った
最近Nuxtでいろいろ作っているけど、無料で使える環境をいろいろ試してる。 いろいろメリデメあるけど、SPAならNetlify/SSRならHerokuがよさそう。 いままで試したものをまとめてみた。 ほしかったもの 主に開発してるのがCGM系のWebサービスなので、 動的なOGP画像などが設定できる(OGP芸) カスタムドメインが使える 日次のランキング集計などの定期実行ができる が、無料でできて、なるべく実装が楽で、そこまで遅くないのがうれしい。 試した5つのパターン 試したのは以下の5パターン。試してみた順で記載。 Nuxt(SSR) + Cloud Function 起動がかなり遅かった。。実装も大変なのでNG Nuxt(SPA) + Firebase Hosting 構築はかなり楽。ただ、OGP芸が大変でFunctionsが必要 Nuxt(SPA) + Netlify プレレンダリ
イメージとしては スタンダード環境の方が気楽にはじめられる フレキシブル環境の方がより細かな設定ができる という感じでしょうか。 「料金が安いのはスタンダード」とは限らない ググって見つかる情報を読むと、多くの人は「スタンダード環境の方が安く済みそうだ」という印象を持つと思います。僕もそのような考えから、当然のようにスタンダード環境を選んでいました。しかし、結果として、Zennの場合にはフレキシブル環境の方が料金は大幅に安く済むことが分かりました。 Zennの場合 具体例があった方が読んでいて楽しいと思うので、恥を捨てて実際にかかっていたGAEの料金を載せてしまいます。ほれっ。 ※ 料金の推移は、サービスへのアクセス数とはほぼ相関していない ピーク時には1万円/日近くいってしまっていますが、設定と環境を見直すと¥500/日くらいで済むようになりました。設定をミスらなければPS5を転売ヤーか
g4というサービスを運営しているのですが、ここ数ヶ月間でGCPの月額費用を4万円以上節約したので、経緯を書いておきます。 7月の費用 ¥53,818 9月の費用 ¥18,801 詳しくはこちらのレポート 11月の費用 ¥7,333 詳しくはこちらのレポート 5月はこんな感じでした。 完全にやらかしてますね！！敗因は 無料期間なのもあり利用料金気にせずに使っていた そして無料期間の終わりを忘れていた アラートを設定していなかった です。 まずは、 7月の費用から約3万円節約するために、GAEのオートスケール周りの設定を見直しました 7月の状態は 本番: (GAE flexible/custom cpu x 2) x 2台 ステージング: (GAE flexible/custom cpu x 2) x 2台 （DBに関しては本番とステージングで同じインスタンスを使っています） でした。これは、
｜DMM inside
こんにちは、エンジニアの@tarr [https://github.com/tarr1124]です。 前回の連載記事 [https://tech.plaid.co.jp/karte-blocks-multicloud/]ではマルチクラウドなどを使い、Blocksでは最大限落ちないようにリスクヘッジをしながらシステムを構築しているという記事を書きました。 * AWSが落ちてもGCPに逃がすことで
はじめに以前 Yuki Furuyama さんが「NEG とはなにか」という哲学的な(?)記事を書かれていましたが、このたび「Serverless NEG」(Serverless Network Endpoint Group)という新しいタイプの NEG が追加されました。(まずは Beta でのご提供です → EDIT(2020–10–14): 2020年10月14日に GA になりました。) これで NEG は Zonal NEG、Internet NEG、Serverless NEG の三種類になりました。 Furuyama さんの Zonal NEG に関する記事には「NEG は Kubernetes の Service に相当するもの、Network Endpoint は Pod に相当するものです」とありましたが、Serverless NEG では「Network Endpoi
https://matopee.com Firebaseを管理画面側に、GAEを公開側に使って、日本語のオノマトペを集めて辞典などとして公開するサービスを作っています。まだまだ不足だらけですが、まずは3200件ちょっと集めたオノマトペの五十音別全一覧を中心に公開しています。 オノマトペにも過不足がありますし、古語や方言はまだほぼ手つかずです。今後は地道に語義を増やし、分類し、論文や書籍、Webなどの参考情報を集め、幾つか毛色の違うコンテンツの準備をしよう、という状況です。 コメントで @scivola と @perpouh からいただいた以下のオノマトペなどを追加し、現在3340件になりました。 以下は語義付きで登録しました。 かこーん ぐすぐす しみじみ ちんちくりん てれてれ どんぶらこ 以下は登録のみ。 ざんぶ, じゃらん, じゃらーん, しゃらん, しゃりん, すぼっ, ぱったり,
「ごめん、同級会にはいけません」 強烈なインパクトを持つこのCM。 これが大好きなので、同級会に誘うと 「今、シンガポールにいます」と 返事を返してくれるLineBotを作ってしまいました。 さらに、ドヤァ感をよりいっそう高める仕様をいろいろモリこみ、 地図には残らなくても、使った人の記憶に残る仕事にしたいと思います！ クソアプリ Advent Calendar 2019 の４日目です。 と、書くまでもなくタイトルから漂うクソアプリ感 使い方： ① 同級会を開く ② おもむろにLineを立ち上げ「綾乃、いまどこ？」と聞く ③ 「ごめん、同級会にはいけません～～～以下略」と返信が来る ④ 「え、シンガポールだって」という感じでみんなでのぞきこむ 実行した時の様子： ※親切に、シンガポールの地図を示してくれる（地図に残る仕事） 他にも形態素解析などの無駄な機能を満載。 LineBot作成のノウ
マンガ『ゲームセンターあらし』をはじめ、数々の人気作で知られるマンガ家・小説家のすがやみつる氏。2020年には新刊『ゲームセンターあらしと学ぶプログラミング入門 まんが版こんにちはPython』を上梓し、注目を集めた。またすがや氏は、京都精華大学マンガ学部の教授として、多くの学生を世に送り出してきた人物でもある。2021年3月の退職を機に、研究者・教育者としての足跡について聞いた（写真はすべてすがや氏提供）。 INTERVIEW＿小野憲史 / Kenji Ono EDIT＿三村ゆにこ / Uniko Mimura（@UNIKO_LITTLE）、海老原朱里 / Akari Ebihara 大学の教員を退職し、再びクリエイター活動へ CGWORLD（以下、CGW）：遅ればせながら、京都精華大学を退職おめでとうございます。 すがやみつる氏（以下、すがや）：2020年3月に専任教員を定年退職して、
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Back in college, I was very interested in Java bytecode. When I got an internship at Google in 2013, I was skeptical of the security of the Java version of Google App Engine and got permission to spend the last week of my internship doing a mini red team exercise, trying to break into App Engine. This is the story of how I found a vulnerability and developed an exploit to break out of the App Engi
こんにちは。Mackerelチーム CREの井上（id:a-know）です。 昨日、待望の Google Cloud インテグレーションがリリースされました！今日は、Google Cloud インテグレーション・AppEngine 連携をさらに便利に活用するための tips をお届けしたいと思います。 本記事の要約 Google Cloud インテグレーション・AppEngine 連携を使うと、バージョンごとにホストが登録されます 「カスタムダッシュボード」と「カスタマイズグラフ」を使うことで、複数ホスト（バージョン）にまたがるリソースの変遷を横断的に閲覧可能にすることができます それを簡単に実現するためのテンプレートもご用意しました！ぜひご利用ください！ Google Cloud インテグレーションについて 昨日リリースした Google Cloud インテグレーションですが、現在の段階
追記） サービス間通信に関わらず、東京リージョンではカスタムドメインを使うとレイテンシが増加 sinmetalさんにコメントで教えていただきました。 お察しの通り、Tokyo Regionを含むいくつかのRegionのApp EngineはCustom DomainでアクセスするとLatencyが増加します。 ドキュメントとしては https://cloud.google.com/appengine/docs/standard/ruby/mapping-custom-domains?hl=en に書いてあります。 確証はないですが、GoogleのネットワークのエッジポイントにあるGoogle Frontend Serverは、App EngineのCustom Domainの紐付けを持っておらず、us-central1に一度行ってしまうために、発生するLatencyなのではないかと思います
サーバ管理なしでWebサービス公開 -Firebase(Authentication, Hosting, Firestore) + GAEで『LogCrow(ログ情報共有サービス)』開発-GAEVue.jsFirebase個人開発algolia FirebaseとGoogle App Engineを中心に活用し、Webサービスをローンチしたのでそのアーキテクチャ & サービス概要を紹介します。 LogCrow(ログ情報共有サービス) 背景・動機 私は日頃業務で、システムの保守・運用の効率化・改善について検討しており、いろんな運用者の知見が共有できている状態が作れると運用者が幸せになれるのではないかと考えています。 そんな中で、特に保守・運用時にキーポイントとなるログ情報についてフォーカスし、こういうログが出たときには「原因」として何が考えられ、どういった「対処」が必要となるのかといった情報
はじめに 今回は、Google App Engine に Next.js アプリケーションをデプロイした際に遭遇した課題と、それぞれの対応について紹介します。 npx create-next-app コマンドの実行後にデプロイした際に、以下の課題に遭遇しました。 next/image を利用している画像へのリクエスト時に App Engine 上で書き込みエラーが発生する App Engine のイメージサイズが400MB弱程度と大きい App Engine のパフォーマンス改善のためのウォームアップリクエストの構成方法が分からない 1. next/image を利用している画像へのリクエスト時に App Engine 上で書き込みエラーが発生する next/image を利用することで、WebP 対応や画質の調整、画像のサイズに応じた配信など簡単に実現することができます。詳しくは、Nex
NTT Tech Conference 2022（2022年3月23日開催） 「音声系サービスにおける サーバーレスアーキテクチャの 活用について」 (講演者：西谷 智広[NTTコミュニケーションズ株式会社])の講演スライドです。 GCPのサーバーレスアーキテクチャを使ってNTTコミュニケーシ…
これは何？ Google App Engine (Standard Environment) は 2nd Generation にアップグレードして、GAE 専用の実行モジュール（各言語で用意された GAE 対応の専用ライブラリ等）が不要になり、一般的なライブラリやフレームワークが比較的自由に使えるようになりました。 cloud.google.com ここでは、Go 1.13 と軽量 Web Framework の Echo を用いて、GAE 上で Web Application を作る方法（主要なポイント）をまとめて紹介します。 echo.labstack.com 大事な宣伝 ここで利用するサンプルコードは、下記の書籍のサンプルアプリ（Python + Flask）を Golang で書き直したものです。GAE そのものの説明や今風な Web Application の作り方については、
GCPのApp Engine（GAE）とCloud CDNを合わせて使う方法について、ググってもあまり解説が見つからなかったのでまとめておきます。 GAEとCloud CDNを合わせて使うメリット GAEにはエッジキャッシュがデフォルトで備わっています。レスポンスのヘッダーでCache-Control: public, max-age=86400などと指定するだけでレスポンスがGoogleのエッジサーバにキャッシュされます。 残念ながら、このエッジキャッシュについて公式ドキュメントがほとんど見つかりません。 GAEのエッジキャッシュが使えるならCloud CDNは不要では？ GAEのエッジキャッシュは気軽に使えて楽なのですが、キャッシュを明示的に削除することができないという難点があります。アプリの新しいバージョンをデプロイしてもしばらくは古いキャッシュが表示され続けてしまったりするので、本
はじめに 2日くらい前に突然webサービスのアイデアが浮かびました。 バレンタインにも合いそうなwebサービスなので、とにかく速く製造してリリースするという目標でやってみました。 どんなwebサービス chocopoi 「ちょこぽい」というwebサービスです。 twitterで見かけた気になる人にchoco（≒いいね）をひそかに送るサービスです。 （twitter認証が必要です） ※ホントのチョコを渡すわけではありません。「いいね」を送るとお考え下さい。 バレンタインに、下駄箱を開けるとチョコが入っててドキドキみたいなのが体験できないかな？ という思いつきから作ったwebサービスです。 chocoを渡す方法は簡単！ まず送りたい相手のユーザー名や@の名前を入れて、検索してください。 送りたいユーザーがでたら選択し「chocoをあげる」ボタンを押すだけ！ これでchocopoiちょこぽいアカ
この記事は Google Cloud Japan Customer Engineer Advent Calendar 2020 の 6日目の記事です。 はじめにGoogle Cloud でアプリケーションを実行する基盤として、Google Compute Engine ( GCE ), Google Kubernetes Engine ( GKE ), Google App Engine ( GAE ), Cloud Run, Cloud Functions などの選択肢が挙げられます。これらのプラットフォームを適切に選択するためのベストプラクティスを本記事では書いていきたいと思います。GAE について、第2世代を対象としています。 各プラットフォームの特徴まずは、Google Cloud でアプリケーションを実行するためのプラットフォームについて簡単に説明をしたいと思います。 GCEGC
この記事について 何かしらwebアプリをデプロイしたいけど個人で動かすと意外と料金がかかりがち。 GAEとFirestoreをうまく使ってwebアプリを無料でデプロイしてみる。 きっかけ GCPのGAE/Goで適当なアプリを作ってみようかなぁと思って、特になにも考えずにGo+Mysqlで動かそうとしていた。 ただGCPでデプロイしようとしたときCloudSQLを使うと、大したことないアプリのわりに無駄に高機能で高い料金になってしまう... (GCEも意外とかかる) ってことでCloudSQLじゃなくて料金がやすそうなNoSQLで構築すればいいんじゃないの？と気づいた。(遅い) 料金（無料枠）に関して 公式 https://cloud.google.com/free/?hl=ja 1日あたりGAEのインスタンス28時間分が無料 要は1インスタンス24時間分＋スケールアウト用の4時間分ってこと
JX通信社シニア・エンジニアの@shinyorke（しんよーく）です. ちょっと前のお話になりますが, JX通信社のニュース速報アプリ「NewsDigest」で, 「AIワクチン接種予測」という新機能の提供を開始しました. prtimes.jp 「自分がいつコロナワクチンを接種できるか?」を簡単に予測できるサービスです. 使っていただけると嬉しいです🙏 大変ありがたい事に,「AIワクチン接種予測」はリリース後多くの反響を頂いていまして, リリースから約半月で利用回数が100万回を突破（プレスリリース）. 同じく, リリースから半月で20本以上ものTV番組で紹介 と, 多くのユーザーさんにお使いいただきました. ありがとうございます🙏 これだけ多くの方に使っていただくとなると, リクエスト数・ユーザー数の増減に合わせたコンピューティングリソースの配分 特に, 「TV経由で認知したユーザー
こんにちは、ソフトウェアエンジニアの yuku です。好きなおでんの種は大根です。 仕事をしていると社内向けに何かしらのサービスを作りたくなることがありますよね。この時面倒なのが認証と認可です。外部に公開されていない社内ネットワークにだけ公開すれば安全ではありますが、外からアクセスするためにいちいち VPN 接続せねばならず面倒です。インターネットからアクセス可能にする場合、画像などコンテンツもセキュアな場所に確実に配置する必要があります。 こんな時 G Suite を使っている会社であれば Cloud IAP を使ってどこからでもアクセス可能な社員向けサービスを簡単に作ることができます。今回の記事では Cloud IAP と、フライウィールで実際に Cloud IAP を使って実装されている社内向けドキュメント共有サービスを紹介します。 Cloud IAP とはCloud IAP (Id
概要 GCPから以下のようなメールが来ていた 要約すると「セキュリティの変更を行うけどIAMで権限を変更しないとデプロイできなくなるから2021年1月27日までに権限変更しておいてね」かと 参考までに実際対応した記録を以下に記載 件名：ご対応のお願い - AppEngineのIAMの更新が必要です Google App Engine をご利用のお客様 Google Cloud では、App Engine のセキュリティ体制の変更を行っております。 今後、App Engine アプリケーションをデプロイするデベロッパーは、 App Engine のデフォルトサービス アカウントに対する iam.serviceAccounts.actAs 権限が必要になります。 これらの変更は、2021 年 1 月 27 日から適用されます。 デベロッパーの皆様がAppEngineアプリケーションのデプロイを
GAE (standard) に対して、ロードバランサー及びVPCからのトラフィックのみを受け付けるようにする設定が追加されました。詳しくはこの記事のGAEの項目を参照ください。 External HTTP(S) Load BalancerとCloud Armorの関係 External HTTP(S) Load Balancerは、Googleのpoints of presence (PoPs) において実装されています。Googleのpopとは、Googleのネットワークへの入り口のようなもので、世界中に沢山存在しています。Googleのサービスへのアクセスは、これらのpopを通り、Googleのデータセンターに到達します (厳密には、使用しているGCPのVPCがPremium Tierかどうかが関係しています)。 “Google Cloud Armor security policy
メモ的共有 2020年にリリースされたMackrelのGCPインテグレーション。 GAEのみを動かしているプロジェクトの監視を入れてみた。 相変わらず、分かりやすい手順書を公開していただいているので、ポチポチと設定完！ https://mackerel.io/ja/docs/entry/integrations/gcp しかし、待てども待てどもホスト追加されない。 ドキュメント記載の確認ポイントを調べても、解決せず。。。 https://mackerel.io/ja/docs/entry/integrations/gcp/appengine ネット上にもそれっぽい悩みは見つからず。。。 そこで、GCP側を調査。 APIとサービスのダッシュボードで、インテグレーション設定したタイミングから、computeのエラーが発生していた。 手順では、GAEしか使わない環境だったので、GCE、Cloud
公開日: 2021.2.8 Google App Engineを使っていると、いつの間にかCloud Storageの使用量が勝手に増えて課金されるようになります。今回はこの現象の原因と解決策についてまとめました。 編集ノート: SERVERSUSでは、パートナーリンクからコミッションを得ています。コミッションが記事の意見や、サービスの評価に影響を与えることはありません。 無料なはずなのに・・App Engineでいつ間にか課金が Google App EngineはGoogle Cloud PlatformのAlways Free対象プロダクトなので、無料で利用することが出来ます。 しかし、ある程度使っているとある日から突然Google Cloud Platformから請求のメールが届いてびっくりします。他のプロダクトを使っていないのであれば、Cloud Storageの課金になっている
公開日: 2019.11.19 Google App Engine(GAE)のバックエンド環境である、フレキシブル環境とスタンダード環境の違いを見ていきます。 編集ノート:SERVERSUSでは、パートナーリンクからコミッションを得ています。コミッションが記事の意見や、サービスの評価に影響を与えることはありません。 Google App Engineの環境とは？Google App Engineには、フレキシブル環境とスタンダード環境の二つ環境があります。環境の指定は、app.yamlで、 env: standard とすることで、指定できます。 名前が違うだけでなく、中身も料金体系も全く異なるため、GAEでアプリをリリースする前にそれぞれの特徴を確認しておきましょう。 スタンダード環境の特徴スタンダード環境は、指定した言語のアプリを「GAEが用意するサンドボックス内で実行」する環境です。
こんにちは。ピリカ開発チームの伊藤です。 GCPの各種サーバーレスサービスにアクセスするには、認証情報が必要となります。App EngineやCloud Functions上で動作している場合は、GCPの各種ライブラリを使っていれば特に何もしなくても認証が通った状態となり、FirestoreやCloud Storageなどを扱うことができるようになっています。 しかし、ローカルでの動作確認を行う場合など、GCP外で動く場合には認証情報を渡す必要があります。 これまで、ローカルでの認証のためには「サービスアカウントキー」というJSONファイルを取得することが多かったのですが、サービスアカウントキーファイルが漏洩した場合に検知が難しいなどの問題があり、最近は非推奨となっています。 では具体的にどのようにすれば良いのかというと、あまりまとまった情報がありませんでした。 今回は、GAE/Pytho
はじめに 最近GCPでWebサービスを立ち上げたので、そのときに実施したことをメモとして残しておきます。 今回はGCEで Debian + Nginx + Railsで環境を作りました。 ドメイン取得以外は終始無料で進めるための努力をしました。 また、今回はRailsアプリケーションを作成することは目的としていませんので、そこについてはあまり触れません。 やったこと GCEでインスタンスを立ち上げる アカウント作成時に貰える無料トライアル枠とは別に、無料で利用できるリソースがあります。 Always Free と呼ばれていて、GCEの場合は以下の要件を満たすインスタンスのみ永久に無料でインスタンスを立てることができます。 リージョンをus-*1から選択する 1つのf1-micro VM インスタンス 30GB以内 の永続ストレージ ※無料対象リージョンはus-*1のみというご指摘を受けまし
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
