Google Cloud Run と AWS Lambda のコールドスタート時間を言語別に観察してみる - Qiita
コンテナをリクエスト処理時間ベースの料金体系で実行できるサーバレス環境としては、Google の Cloud Run（2019年11月GA）と AWS Lambda（2020年12月にコンテナに対応）が特に有名でしょう。 これらの環境は、一度起動したコンテナインスタンスをしばらく生かしておき、その後のリクエストに使いまわします。しかし、生きているインスタンスが足りない場合は新たなコンテナの起動から始めるいわゆる「コールドスタート」となり、応答のオーバーヘッドが大きく増加します。用途によっては、このコールドスタートにかかる時間が問題になります。 Cloud Run と Lambda でのコールドスタートの様子を観察するため、いくつかの言語で "Hello, World!" を返すだけのWebアプリコンテナを作り、コールドスタートの時間を「雑に」観察してみました。 注意: コストや性能は考慮し
Cloud Functions 2nd genを解剖する
TL;DR Cloud Functions 2nd genはEventarc + Cloud RunのWrapperのように振る舞います Cloud RunでCloud Functions 2nd genと同等の振る舞いを構築します はじめに どうも、アニメマスターです。 今回は実質Cloud RunであるところのCloud Functions 2nd genについて、実際どのような構成になっているのか検証していきたいと思います。 概観 Cloud Functions 2nd genは上記の通り、Artifact Registry + Cloud Run (+ Eventarc)で構築されておりそれらのWrapperのような振る舞いをします。 EventarcはCloud Functionsと統合されていますが、オプションなので今回は触れません。 1. 実際にCloud Functions
ZennにみるCloudRunとBigQueryによるアプリケーション構築 / zenn-cloudrun-bigquery-serverless
Zennは、クラスメソッドが展開する技術者向けの知識共有プラットフォームです。Cloud Runを中心としたGoogle Cloudのソリューションをメインで使用しており、スケーラブルなWebアプリケーションとなっています。 このセッションでは、「サーバーレスとはなにか」という部分から改めてディスカッションし、アプリケーションをスケーラブルに、ビジネスに集中するという目的に対してZennがどうアプローチしているかを解説します。 また、Google Cloud を利用するモチベーションのひとつにBigQueryの存在があると思います。Zennでも統計機能に利用しており、アプリケーションとどのように統合しているか紹介、それがどの程度 Google Cloud を使う理由になるか議論します。 サーバーレスアプリケーションを組むときに、みなさまの選択肢をひとつ増やし、結果的によりニーズに合致したア
Cloud Run で作るサーバーレス アーキテクチャ 23 連発 - これのときはこう！
2023年は「Cloud Run を触って覚える」をテーマとした ひとりアドベントカレンダー を開催しており、Cloud Run のさまざまな機能や Cloud Run でよく使う構成などをご紹介しています。 最終日、25日目は Cloud Run を中心としたサーバーレス アーキテクチャをいくつか紹介します。2023年にちなんで23個のアーキテクチャを用意しました。 Cloud Run の概要は「gihyo.jp」で解説していますので、こちらもぜひご覧ください。 Web アプリケーション + API の 3-Tier 構成 (SPA) Web アプリケーション + API の 3-Tier 構成 (SPA) SPA (Single Page Application) がフロントになり、バックエンドの API サーバーとして Cloud Run を使用するアーキテクチャです。SPA は N
Cloud Run jobs and second-generation execution environment GA | Google Cloud Blog
Serverless for all your needs: Cloud Run jobs and second-generation execution environment now GA For the past 15 years, organizations have been using Google Cloud serverless products to connect the world, secure cloud banking, provide free education to anyone, revolutionize the cosmetic industry, re-architect the freight industry, redefine the retail industry, and more. And today, with the general
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のドキュメントの既知の問題には以下の記載があり
Cloud Run Jobs がリリースされたので、何ができるか試してみた！
2022/05/11にCloud Run Jobsがプレビューでリリースされました！ Unlike services, which listen for requests, a job does not serve requests but only runs its tasks and exits when finished. 従来のCloud Runのserviceでジョブ的なことを実装する場合、ポートをリッスンしてリクエストを受け取り、ジョブを実行して、成功/失敗のレスポンスを返すという流れでした。 今回リリースされたCloud Run Jobsでは、ポートをリッスンする必要がなくなったということで、ついに待ち望んでいた機能がきたのか！？とさっそく動作確認し、僕が期待してたことは全部できそうでした🎉 これまでCloudBuildでワークフロー組んでたんですが、対応リージョン増えてC
Cloud Run でマイクロサービスを作る 5 つのポイントをまとめてご紹介！
はじめに早速ですが、皆さんはマイクロサービスを構築するとしたら、どのような構成を考えますか？ 多くの企業で、GKE を使ったマイクロサービス アーキテクチャが採用されています。選定理由として、Kubernetes が持つ機能や大きめなリソースが必要であったり、社内インフラチームによる Kubernetes のサポートがあるといった理由などがあります。一方、定期アップグレードなどの観点から、Kubernetes の運用は少し大変…と感じる方もいるかと思います。 GKE Autopilot の利用という考えもありますが、サーバーレスでコンテナを動かせる Cloud Run を使って、インフラ管理不要でマイクロサービスを構築が出来ると嬉しくないですか？ 実際、そういった構成を採用されている企業も見かけます。 この記事では、設計や実装時に考えるであろう、以下の 5 つのポイントにフォーカスしてみた
Cloud Run gets always-on CPU allocation | Google Cloud Blog
Cloud Run, Google Cloud's serverless container platform, offers a very granular pay-per-use pricing, charging you only for CPU and memory when your app processes requests or events. By default, Cloud Run does not allocate CPU outside of request processing. For a class of workloads that expect to do background processing, this can be problematic. So today, we are excited to introduce the ability to
GoでHeadless browserを使いClient Side Renderingを Cloud Run で動かす
はじめに この記事は、Go言語でヘッドレスブラウザを実装したサーバ（サーバレスなので実際にはコンテナという表現が正しいかも知れません）を作り、Google Cloud Platform (GCP) の Cloud Run (Knative を使用) でセキュアに実行する内容となります。 ハンズオンではありませんが、少し手を加えれば動くものが作れるレベルの資料としています。 一応、なるべく幅広い読者層に分かりやすく伝えるため、人によって冗長的な説明に感じるところもあると思います。その場合は本題に入る「Go で ヘッドレスブラウザ を実装したサーバを用意するの」 の章から読み進めて下さい。 Goals Go で CSR (Client Side Rendering / クライアントサイドレンダリング) に対応する方法が知れる たとえば CSR 対応のテストやスクレイピングなどの環境を作る知識が
Cloud Run の WebSocket、HTTP/2、gRPC 双方向ストリームのご紹介 | Google Cloud 公式ブログ
※この投稿は米国時間 2021 年 1 月 22 日に、Google Cloud blog に投稿されたものの抄訳です。 このたび、Cloud Run に新しいトラフィック配信機能が追加され、エンドツーエンドの HTTP/2 接続、WebSocket のサポート、gRPC の双方向ストリーミングが可能になりました。これにより、gRPC で提供される全タイプのリモート プロシージャ コールを実行できるようになりました。これらの機能を使用することで、サーバーレス インフラストラクチャを利用しながら、これまでサポートされていなかった種類のアプリケーションを Cloud Run にデプロイできるようになりました。これらの新機能は現在、Cloud Run の全ロケーションの公開プレビューで利用可能になっています。 ストリーミングのサポートは、応答性の高い高性能アプリケーションを構築するうえで重要です
2020 年を振り返る: 不確実性の時代にお客様がサーバーレス ソリューションで対処した方法 | Google Cloud 公式ブログ
※この投稿は米国時間 2020 年 12 月 24 日に、Google Cloud blog に投稿されたものの抄訳です。 何という 1 年だったでしょう。2020 年は、特に適応力のある企業でさえ問題に直面し、慎重に練った計画が頓挫しました。それでも、Google Cloud の数多くのお客様が不確実性をチャンスに変えました。彼らはサーバーレス ソリューションに頼ってイノベーションを加速し、多くの場合、最新のプロダクトを導入して市場のニーズに対応する新たな機能を提供しました。Google Cloud はお客様に寄り添い、100 以上の新機能をかつてないほど迅速に導入しました。インスピレーションを提供してくださり、サーバーレス ソリューションとクラウドネイティブ アプリケーションの配信に関して多大なエネルギーを注いでいただいたことに感謝しています。 不確実性の中で Cloud Run が不
たった一つで Cloud Run にビルドしてデプロイするコマンドの紹介 | Google Cloud 公式ブログ
※この投稿は米国時間 2020 年 12 月 18 日に、Google Cloud blog に投稿されたものの抄訳です。 Cloud Run に対する Google のビジョンはシンプルです。デベロッパーのソースコードを、HTTPS で保護されたドメイン名を使用したフルマネージドの自動スケーリング インフラストラクチャ上で実行できるようにすることです。しかし、従来は、Cloud Run へのデプロイには少なくとも次のような 2 段階のステップが必要でした。 コードをコンテナ イメージへとパッケージ化する このコンテナ イメージを Cloud Run にデプロイする コンテナ イメージはソフトウェアのパッケージ化、デプロイ、スケーリングの業界基準となったものの、すべてのデベロッパーがコンテナの仕組みや、（それぞれの好みの言語で書かれた）アプリをコンテナ イメージへとビルドする方法を知りたい
Introduction to Cloud Run 2021
https://gdg-tokyo.connpass.com/event/201523/
Eventarc でサーバレスに非同期処理を実現しよう
この記事は Google Cloud Japan Customer Engineer Advent Calendar 2020 の 18日目の記事です。 みなさんこんにちは、最近すっかり寒くなってきましたね。来週はクリスマス、もうすぐ年越しで、イベント尽くしです。イベント… Event… ということで、今年の 10 月に Eventarc という機能がリリースされたのをご存知でしょうか（強引）？ Eventarc とはGCS にファイルが置かれたり、Firestore に書き込みがあった場合など、Google Cloud 上でイベントがあった際に別の処理を実行させたい場合、Cloud Functions や Pub/Sub を利用する方法があります。それも良い方法なのですが、Pub/Sub が対応していないイベントなど、より多くのサービスを連携させたいケースもあるかと思います。 Event
Build event-driven applications in Cloud Run | Google Cloud Blog
Trigger Cloud Run with events from more than 60 Google Cloud sources Cloud Run (fully-managed) lets you create microservice-based applications that are scalable and extensible. But setting up event-based communication between decoupled microservices can be hard to implement, customize and maintain. Today, we’re announcing Eventarc, new events functionality that allows you to trigger Cloud Run from
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
02-04 Cloud Run と Eventarc による Event Driven Architecture 入門
https://cloud.google.com/blog/ja/topics/developers-practitioners/trying-out-source-based-deployment-cloud-run
Event-driven applications with Eventarc and Cloud Run
Cloud Run: What no one tells you about Serverless (and how it's done) | Google Cloud Blog