Cloud Run東京リージョンにカスタムドメインをマッピングするとどのくらいのレイテンシが発生するのか
調査結果まとめ 日本の真ん中あたりから東京リージョンのCloudRunにアクセスしたときのTTFB（Time To First Byte）のざっくり計測結果。詳細は後述。 Cloud Runのデフォルトドメインに直接アクセスした場合: 28msくらい Cloud Runにカスタムドメインをマッピングした場合: 99msくらい さらにCloudflareからCNAMEで指した場合: 114msくらい Cloudflare WorkersでCloud Runのデフォルトドメインをプロキシした場合: 44msくらい Cloud Run + Cloud Load Balancing（CDNなし）: 31msくらい Cloud Runの東京リージョンで「カスタムドメインのマッピング」を利用するとレイテンシが発生する 2023年1月現在、Cloud Runのドキュメントの既知の問題には以下の記載があり
NodeでのCloud LoggingとError Reportの最適な使用方法を実験で導き出す
GCP の Cloud Run で Node のサーバを稼働させ、Cloud Logging にログを出力して、更にエラーが発生したときは Error Report で通知を受けるというような構成を組む際に、 どのようなケースで「重要度」が正しくマークされるのか どのような形式でログを吐けば Error Report が自動生成されるのか ドキュメントを読んでも、これらのことがいまいちわからなかったので実験してみました。 また、標準の console だけではなく、Node の主要なロガーライブラリーのうち、どれが一番 Cloud Logging と Error Report との相性が良いのかも実験から導き出しました。 前提 ロギング方法 Cloud Run で express サーバを用意し、下記のように文字列と Error をロガーで標準出力および標準エラーに出力 app.get("
なぜ今も Google App Engine を選ぶのか - ぽ靴な缶
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。 そんな歴史あるサ
Herokuにあった個人アプリを軒並み対応した - くりにっき
背景 やったこと1. 廃止 やったこと2. GCPに移行 ユースケース図 URLベースで見たユースケース図 実行環境で見たユースケース図 実際にGCPに移行したアプリ達 Cloud Run Cloud Functions AppEngine GCP移行した全てに共通してること やったこと3. CircleCIに移行 付録A. 道のり 付録B. 調査メモ（移行時に参考にしたドキュメントやサービスなど） 無料プラットフォームがまとまってるドキュメント ElephantSQL (PostgreSQL) PlanetScale (MySQL) Redis Enterprise Cloud 付録C. Redisを雑にFirestoreに置き換えたらクラウド破産しかけた 2022/09/22 20:45ブコメレス 背景 Herokuの無料プラン終了のため10個以上あった個人アプリを1ヶ月くらいかけて色
これから始める Cloud Functions 入門
はじめに本記事は Google Cloud が提供するサーバーレスコンピューティングサービスである「Cloud Functions」の入門記事です。Cloud Functions の詳細な使い方はドキュメントに網羅されていますが、本記事では Cloud Functions の概要をざっくりと知り、使い始めてみる ところに重点を置いて解説したいと思います。Cloud Functions を使い始める上での入り口としてご覧いただきながら、各機能のより詳細な内容はドキュメントを見ながら掘り下げていただければと思います。 Cloud Functions の特長サーバーレス、FaaSCloud Functions はいわゆるサーバーレス、あるいは FaaS (Function-as-a-Service) と呼ばれるサービスです。 サーバーレスとはサーバーの管理を必要としないようなアーキテクチャの総称
Cloud Functions のデプロイまとめ
最近超小規模の案件があり、先方の運用費も含めてとにかく低予算で収めたいという要望と機能・非機能の要件も満たしていたので Cloud Functions + Cloud Firestore で開発を行いました。今回は一桁程度の関数しか作成しなかったのですが、大規模になった時を見越して Cloud Functions のデプロイについて調査・検証しましたのでまとめてみたいと思います。 デプロイ方法の概要 Deploying Cloud Functions | Cloud Functions Documentation GCP コンソールを使う gcloud コマンドを使う Cloud Functions API を使う 方法としては上記の 3 つあり、どの方法を使ったとしても以下の 3 つのステップで行います。 ソースコードのアップロード ソースコードからコンテナイメージのビルド コンテナイメ
とりあえずWebサービス作る時の私の技術選定ポイント@2022/02
はじめに inspired mogaさんのブラウザで動くサービスを作るときの技術選定が素晴らしい記事だったので、自分も書いてみる事にしました。 幸いにも技術選定からのお仕事をする機会が多くて、自分の中でパターンが大体決まってきているので言語化してみます。前提が同じサービスは無いので絶対的な正解は無いですが、なんかしらの参考になれば幸いです。 ※2022/02時点 私/よくあるお仕事について Web系のサービスなんかいい感じにするマンとして、フリーランスとして働いています。 準委任という形でスタートアップ企業をお手伝いする事が多いです。 MVPを作りたい、もしくはMVPは行けたのでちゃんと作り直したい、という要望があって参画して、まるっと作ってそのまま運用をします。作って終わりではなくて、運用や拡張性を考えてやってます（サービスに必要なのはもちろん、運用する自分が楽だから）。 前提 エンジニ
お知らせ: Google Cloud の Buildpacks でコンテナ イメージ作成が簡単に | Google Cloud 公式ブログ
※この投稿は米国時間 2020 年 10 月 10 日に、Google Cloud blog に投稿されたものの抄訳です。 新しいアプリケーションを構築する開発者が集中して取り組むべきなのは、コードの記述であって、コンテナ化ではありません。また、すでにコンテナを使用している開発者であれば、適切で安全なコンテナ イメージの作成がどれだけ複雑で時間のかかる作業かということをご存じでしょう。そこで本日、安全かつ本番環境ですぐに使えるコンテナ イメージを、Dockerfile がなくてもソースコードからすばやく簡単に作成できるオープンソースのテクノロジー、Buildpacks を Google Cloud 全体で幅広くサポートする体制が整いましたことをお知らせいたします。 このリリースの目玉は、なんといってもオープンソースの Buildpacks とビルダーです。CNCF の Buildpacks
【Node.js/Next.js】Cloud Runで動作する軽量なDockerを構築してみた
概要 本記事では、Next.jsをコンテナをサーバーレスで実行するサービスであるCloud Runで動作する軽量のDocker環境構築について紹介します。 ネットにある様々な記事を見てきましたが、動作目的でDockerイメージが大きくなっており、パフォーマンスとセキュリティに課題がありました。そこでDockerの軽量化および最適化を試みました。 Docker環境 シングルステージビルド（slim） シングルステージビルドしたDockerイメージです。本番環境に必要無いデータを多く含んでいるため、イメージサイズも大きくなっています。構成はシンプルのため、理解しやすいですがパフォーマンス/セキュリティ面には課題があります。 FROM node:14.17.0-slim WORKDIR /app COPY package.json yarn.lock ./ RUN yarn --frozen-l
Next.jsアプリをVercelからGoogle Cloudに移行した話
ZennではフロントエンドにNext.jsを使っています。もともとはVercelで動かしていたのですが、2021年3月にGoogle Cloudに移行しました。今回は移行を決めた理由や、具体的な構成、移行作業などについて書きたいと思います。 なぜ移行したのか Next.jsのデプロイ先としてVercelは圧倒的に優れています。ISRやImage OptimizationといったNext.jsの強力な機能をサーバー側の追加設定なしで使用できますし、CDNでの静的ファイルのキャッシュなども特に意識しなくてもいい感じにやってくれます。 Vercel以外にデプロイするとなると、Next.jsの一部の機能がうまく動かなかったり、パフォーマンス・チューニングを自分で頑張る必要があったりと自分で面倒を見なければならない部分が多くなります。 しかし、Zennのケースでは以下のような理由からVercelから
Node.js Runtime Environment | Google App Engine standard environment docs | Google Cloud
runtime: nodejsVERSION Where VERSION is the Node.js MAJOR version number. For example, to use the latest Node.js version, Node.js 22, specify 22. For other supported Node.js versions, and the corresponding Ubuntu version for your Node.js version, see the Runtime support schedule. Node.js version The Node.js runtime uses the latest stable release of the version that is specified in your app.yaml fi
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://googlecloudcheatsheet.withgoogle.com/architecture
GitHub - gcpug/nouhau: Google Cloud Platformのノウハウを共有するRepository
物理サーバを選定する際のポイント – Eureka Engineering – Medium