Cloud Runのリクエスト最大サイズ(32MiB)を突破する！ - Qiita
はじめに Cloud Runは、コンテナイメージを簡単にデプロイしてアプリケーションを実行できる便利なサービスです。 しかし、何も考えずにサービスを構築すると、思わぬ落とし穴にはまることがあります。 私は以前、ファイルをアップロードするAPIを作成した際、とある問題に直面しました。 〜回想〜 「よっしゃ、FastAPIを使ってファイルをアップロードするAPIを作成したやで」 「Cloud Runへのデプロイが完了した！動作確認しよーっと、curl commandぽちー」 「はっ…？ 413 Request Entity Too Large が返ってきた…！？」 「開発環境では問題なく動作したのになんでや…！？」 〜回想終〜 どうやら、リクエストサイズ（今回でいうところのアップロードするファイルのサイズ）が大きすぎてCloud Run側でリクエストが失敗しているようでした。 Cloud Ru
Cloud Run 上のページが一部の Chrome 環境で文字化けする謎を探るべく我々は Google Cloud の奥地へと向かった
この記事は 2024 年 2 月 28 日に執筆されました．今後この問題が Cloud Run 側で修正された場合，再現しない可能性がありますのでご留意ください． TL; DR Cloud Run は執筆時現在 zstd による圧縮に対応していない ヘッダの Content-Encoding: zstd のみが削除され，ボディは圧縮されたまま応答される ブラウザはこの応答を正しく解釈できないため文字化けのような表示となる zstd による圧縮は，執筆時現在 Chrome に実装されているもののデフォルトでは無効だが近い将来に有効化される 悲劇は突然訪れる 弊社では，コーポレートエンジニアリングチーム [1] [2] において，社内向けにいくつかのサービスを提供しています． これらのサービスはもともと AWS でホストされていましたが，アクセス制限に Identity-Aware Proxy
gRPC の使用 | Cloud Run Documentation | Google Cloud
このページでは、デベロッパーが gRPC を使用し、Cloud Run サービスを他のサービスと接続して、たとえば、内部のマイクロサービス間のシンプルでパフォーマンスの高い通信を行う方法について詳しく説明します。Cloud Run では、すべての gRPC タイプ（ストリーミングまたは単項）を使用できます。 考えられるユースケースには、次のようなものがあります。 内部マイクロサービス間の通信。 高負荷のデータ（gRPC では、プロトコル バッファを使用します。これは REST 呼び出しの最大 7 倍の速度です）。 単純なサービス定義だけが必要で、完全なクライアント ライブラリは作成しないケース。 gRPC サーバーで gRPC ストリーミングを使用して、より応答性の高いアプリケーションと API を構築する。 サービスを gRPC と統合するには: ストリーミング gRPC を使用している
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 の全ロケーションの公開プレビューで利用可能になっています。 ストリーミングのサポートは、応答性の高い高性能アプリケーションを構築するうえで重要です
Cloud RunとCloud PubSubでサーバレスなデータ基盤2024 with Terraform / Cloud Run and PubSub with Terraform
Google Cloudのサーバレスなサービスでデータ基盤を作った話.
SQLite + Litestream + CloudRun で「個人開発並みの予算でもSQLを捨てない」バックエンド構築（Next.jsを例にして） - Qiita
この記事を書くに至った経緯と目的 個人開発やまだ利益の出ていないアプリって、予算の制約から選べるDBが限られてしまうことがあるよね。 具体的には Amazon DynamoDB や Cloud FireStore のような 「アクセス回数や通信量、保存サイズなどで金額が決まるDB（インスタンス起動時間ではなく）」 を選ぶことが多いと思うのだけど、これらのDBはNoSQLである以上、文字通り、SQLを使えないという難点がある。 だけどNoSQLのノウハウはちょっと一癖あるから、できることなら通常のRDBMSのようにSQLを使いたい... って人が結構いるんじゃないかなと思っていて、この記事はそういった人たちに、SQLを使える低予算DBの選択肢として、SQLite + Litestream + Google Cloud Run を紹介することを目的としているよ。 筆者プロフィール Kenpal
Cloud Run + Litestream で RDB を使いつつ費用を格安に抑える
前から気になっていた Litestream を Cloud Run で使ってみたので、そのメモです。 Litestream とは？ サンプルコード 手順 動作確認してみる 制限事項 おまけ まとめ 参考 Litestream とは？ Litestream は、 SQLite のデータベースファイルを Amazon S3 や Google Cloud Storage などのオブジェクトストレージにリアルタイムでレプリケートすることができるオープンソースのツールです。 例えば通常 Cloud Run で DB エンジンとして SQLite を使用しようとしても、コンテナが破棄されると同時に毎回 SQLite のデータベースファイルも消えてしまうため、データを永続化することができません。 しかし Litestream を使用すれば、 SQLite のデータベースファイルをオブジェクトストレージに
Google Cloud で生成 AI アプリケーションを作ろう！パート 0：Google Cloud の生成 AI ソリューション
本シリーズの執筆者 Google Cloud で生成 AI アプリケーションを作ろう！ シリーズの記事は、Google Cloud Japan の下記の有志メンバーが共同で執筆しています。 執筆者 下田倫大（Norihiro Shimoda, Google Cloud AI/ML Practice Lead） 中井悦司（Etsuji Nakai, Google Cloud Solutions Architect） 木村拓仁（Takuto Kimura, Google Cloud Customer Engineer） RyuSA レビュアー 牧 允皓（Yoshihiro Maki, Google Cloud AI/ML Specialist） 鈴木かの子（Kanoko Suzuki, Google Cloud Associate Customer Engineer） 吉田望（Nozomu Y
Cloud Run 用に Python アプリケーションを最適化する | Cloud Run Documentation | Google Cloud
フィードバックを送信 Cloud Run 用に Python アプリケーションを最適化する コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 このガイドでは、Python プログラミング言語で作成された Cloud Run サービスの最適化と、最適化の一部に関連したトレードオフの理解に役立つ背景情報について説明します。このページの情報は、Python にも適用される全般的な最適化のヒントを補完するものです。 これらの従来の Python ウェブベース アプリケーションのベスト プラクティスと最適化の多くは、以下を中心に展開されています。 同時リクエストの処理（スレッドベースと非ブロッキング I/O の両方）。 バックグラウンド タスクへのトレースや指標の送信など、重要性が低い機能に接続プールとバッチ処理を適用してレスポンス レイテンシを短縮する。 コンテナ
Cloud Run に ko と skaffold を使ってデプロイまでやってみる | フューチャー技術ブログ
はじめにこんにちは！ TIG コアテクチームの川口です。本記事は、CNCF連載 の5回目の記事になります。 本記事では、CNCF の Knative を基盤として利用している Cloud Run と CNCF の各種ビルドツール ko, skaffold、Cloud Deploy を用いたうえで、アプリケーションのビルドからデプロイまでを行います。 扱う技術要素今回は、合計5つの技術要素を扱います。 全体感を掴むため、それぞれの技術とそれらの関連について図示します。 Cloud Run （Knative）Cloud Run は、Google Cloud におけるコンテナベースのサーバーレスコンピューティングサービスとしてよく知られているものかと思います。こちらは、基盤として Knative を採用しています。 この Knative は 2022年の3月に CNCF の Incupating
GCP Cloud RunでLitestreamを利用する
https://zenn.dev/voluntas/scraps/f4939cbe92525c を見て、Cloud Run でもホストできると個人的にはうれしいかもなーと思って実験してみた コツとしては、 第二世代の実行環境 で動作させる コンテナ起動時にrestoreしてGCSからデータをロードするようにする 最大インスタンス数を1にする LitestreamのGCS対応はCloud Runの実行環境のサービスアカウントでは実行されないので、サービスアカウントを作り、SecretManager経由で鍵情報をファイルとしてマウントし、GOOGLE_APPLICATION_CREDENTIALS としてパスで与える。 といったところだった。 litestream replicate -exec が実行している内容を考えると、定期的にGCSへ更新する処理が走るので、Always on CPU
The Baked Data architectural pattern
28th July 2021 I’ve been exploring an architectural pattern for publishing websites over the past few years that I call the “Baked Data” pattern. It provides many of the advantages of static site generators while avoiding most of their limitations. I think it deserves to be used more widely. I define the Baked Data architectural pattern as the following: Baked Data: bundling a read-only copy of yo
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
Zennのバックエンドを Google App Engine から Cloud Run へ移行しました（無停止！YES！）
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
FireStoreのイベントをトリガーとして、Eventarc経由でCloudRunを呼び出す
(これはこの記事からの転載です) FireStoreのイベントは、Eventarcを用いることで他のサービス、例えばCloud Runなどをトリガーできます。 今回、Eventarcを用いてFireStoreのイベントをトリガーとしてCloud Runを呼び出してみることにします。 EventarcはAuditとPub/Subの両方から流し込むことができます。PubSubはCloud PubSubとして他のいろいろなところから流し込むことができ、AuditはFireStoreのイベント以外にもGoogle Cloudで起きるほぼすべてのAPI呼び出しをイベントとして流し込めます。 1. 取得したいイベントの監査ログを有効化する 最初にEventarcを有効化する監査ログの種類を指定し、有効化します。 IAM権限管理 -> 監査ログ で、 "Firestore/Datastore API"
Cloud Runで新規サービスを構築・運用するためにSREとして取り組んだこと - ZOZO TECH BLOG
はじめに こんにちは。メディアプラットフォーム本部 WEAR部 WEAR-SREの笹沢（@sasamuku）です。 ZOZOが新しく展開する「FAANS」というショップスタッフ向けアプリをクローズドβ版としてテスト運用しています。本アプリは、WEARと連携したコーディネート投稿や、その成果を可視化する機能などをショップスタッフの皆さんに提供するtoBのソリューションです。現在、正式リリースに向け開発を進めています。 そして、FAANSのAPIはCloud Runと呼ばれるサーバレスなコンテナ実行基盤で稼働しています。本記事では、FAANSの実行基盤としてCloud Runを選定した理由や、構築・運用するためにSREとして取り組んだことをご紹介します。 Cloud Runを選んだ理由 まず、クラウドサービスはGCPを選択しています。FAANSでは開発速度の向上と運用負荷の軽減のため、認証やメ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
LLM・生成AI活用型アプリの実装スキル・トレーニング集：Google Cloud 上級編【2024年秋】
【GCP】Cloud RunでPython FastAPI・Streamlitをデプロイ | Yukkuri Machine Learning
Serverless Preview Environments and GitOps with CloudBees Core and Google Cloud Run
Serverless Jenkins Pipelines with Google Cloud Run