Google Cloudのサーバレスなサービスでデータ基盤を作った話.
SQLite + Litestream + CloudRun で「個人開発並みの予算でもSQLを捨てない」バックエンド構築（Next.jsを例にして）SQLite3個人開発Next.jsCloudRunLitestream この記事を書くに至った経緯と目的 個人開発やまだ利益の出ていないアプリって、予算の制約から選べるDBが限られてしまうことがあるよね。 具体的には Amazon DynamoDB や Cloud FireStore のような 「アクセス回数や通信量、保存サイズなどで金額が決まるDB（インスタンス起動時間ではなく）」 を選ぶことが多いと思うのだけど、これらのDBはNoSQLである以上、文字通り、SQLを使えないという難点がある。 だけどNoSQLのノウハウはちょっと一癖あるから、できることなら通常のRDBMSのようにSQLを使いたい... って人が結構いるんじゃないかなと思
前から気になっていた Litestream を Cloud Run で使ってみたので、そのメモです。 Litestream とは？ サンプルコード 手順 動作確認してみる 制限事項 おまけ まとめ 参考 Litestream とは？ Litestream は、 SQLite のデータベースファイルを Amazon S3 や Google Cloud Storage などのオブジェクトストレージにリアルタイムでレプリケートすることができるオープンソースのツールです。 例えば通常 Cloud Run で DB エンジンとして SQLite を使用しようとしても、コンテナが破棄されると同時に毎回 SQLite のデータベースファイルも消えてしまうため、データを永続化することができません。 しかし Litestream を使用すれば、 SQLite のデータベースファイルをオブジェクトストレージに
本シリーズの執筆者 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 アプリケーションを最適化する コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 このガイドでは、Python プログラミング言語で作成された Cloud Run サービスの最適化と、最適化の一部に関連したトレードオフの理解に役立つ背景情報について説明します。このページの情報は、Python にも適用される全般的な最適化のヒントを補完するものです。 これらの従来の Python ウェブベース アプリケーションのベスト プラクティスと最適化の多くは、以下を中心に展開されています。 同時リクエストの処理（スレッドベースと非ブロッキング I/O の両方）。 バックグラウンド タスクへのトレースや指標の送信など、重要性が低い機能に接続プールとバッチ処理を適用してレスポンス レイテンシを短縮する。 コンテナ
はじめにこんにちは！ 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
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
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
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は、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を用いることで他のサービス、例えばCloud Runなどをトリガーできます。 今回、Eventarcを用いてFireStoreのイベントをトリガーとしてCloud Runを呼び出してみることにします。 EventarcはAuditとPub/Subの両方から流し込むことができます。PubSubはCloud PubSubとして他のいろいろなところから流し込むことができ、AuditはFireStoreのイベント以外にもGoogle Cloudで起きるほぼすべてのAPI呼び出しをイベントとして流し込めます。 1. 取得したいイベントの監査ログを有効化する 最初にEventarcを有効化する監査ログの種類を指定し、有効化します。 IAM権限管理 -> 監査ログ で、 "Firestore/Datastore API"
はじめに こんにちは。メディアプラットフォーム本部 WEAR部 WEAR-SREの笹沢（@sasamuku）です。 ZOZOが新しく展開する「FAANS」というショップスタッフ向けアプリをクローズドβ版としてテスト運用しています。本アプリは、WEARと連携したコーディネート投稿や、その成果を可視化する機能などをショップスタッフの皆さんに提供するtoBのソリューションです。現在、正式リリースに向け開発を進めています。 そして、FAANSのAPIはCloud Runと呼ばれるサーバレスなコンテナ実行基盤で稼働しています。本記事では、FAANSの実行基盤としてCloud Runを選定した理由や、構築・運用するためにSREとして取り組んだことをご紹介します。 Cloud Runを選んだ理由 まず、クラウドサービスはGCPを選択しています。FAANSでは開発速度の向上と運用負荷の軽減のため、認証やメ
こんにちは。ソウゾウのSoftware Engineer(CTO)の@suguruです。連載：メルカリShops 開発の裏側 Vol.2の1日目を担当させていただきます。 去年、2021年に開始した メルカリShopsの技術スタック についての記事を書きましたが、今回はリリースまでに採用した技術スタックが、半年通してどのようにアップデートしてきたかを共有したいと思います。 ローンチ時に採用した技術が、実際の運用でどのように変遷したのかを共有することで、技術スタックを考える際の何らかの参考になれば幸いです。 monorepo メルカリShops ではサービスに必要なコードを1つに集約する monorepo を採用しています。リリース後半年たってコード量はかなり増えてきましたが、monorepo に対する満足度は非常に高く、うまく機能しています。 サービス全体の見通しが良くなることと、すべての
フィードバックを送信 チュートリアル: Cloud Run での Filestore の使用 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 このチュートリアルでは、Filestore をネットワーク ファイル システムとして Cloud Run サービスにマウントし、複数のコンテナとサービス間でデータを共有する方法について説明します。このチュートリアルでは、Cloud Run の第 2 世代の実行環境を使用します。 第 2 世代の実行環境では、ネットワーク ファイル システムをコンテナ内のディレクトリにマウントできます。ファイル システムをマウントすると、ホストシステムとインスタンスの間でリソースを共有し、インスタンスがガベージ コレクションされた後もリソースを保持できます。 Cloud Run でネットワーク ファイル システムを使用するには、コンテナ
フィードバックを送信 実行環境について コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 Cloud Run サービスでは、デフォルトで実行環境が指定されていません。つまり、Cloud Run は使用されている機能に基づいて実行環境を選択します。サービスの実行環境を指定しない場合、Cloud Run は第 1 世代または第 2 世代の環境を選択できます。 Cloud Run ジョブは第 2 世代の実行環境のみ使用します。この動作をジョブで変更することはできません。 第 1 世代の実行環境は、コールド スタート時間が高速で、エミュレーションを行いますが、すべてのオペレーティング システム コールを実行できるわけではありません。当初は、これが Cloud Run のサービスで使用できる唯一の実行環境でした。 第 2 世代の実行環境では、システムコールのエミュレー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
