2025/08/11 15:42:40

Cloud Run の Google Cloud Storage マウントと Litestream のパフォーマンス比較（2回目）

English follows Japanese.

結論

Cloud Run 上で動く Rails 8 から SQLite を利用する際、書き込み性能においては Litestream が Google Cloud Storage マウント (GCS fuse) を上回る（約1.7倍）ことが分かった。

アプリケーションが書き込み処理を伴う場合、GCS fuse の利用は慎重に検討すべきであり、Litestream が有力な選択肢となる。

この2回目で一連の記事は終わりである。

本記事の構成

• 結論
• 本記事の構成
• 参考文献
• パフォーマンス比較
  • 仕様
  • Cloud Run の Google Cloud Storage マウント (GCS fuse)
  • Litestream
• 考察
• 生データ (RAW Data)
  • Cloud Run の Google Cloud Storage マウント (GCS fuse)
  • Litestream

参考文献

• 前回記事Cloud Run の Google Cloud Storage マウントと Litestream のパフォーマンス比較（1回目）https://tako.nakano.net/blog/2025/05/cloud-run-sqlite-performance-part-1/

はじめに

前回は、Rails 8 において SQLite をバックエンドに持つアプリケーションを、Cloud Run 上で動かし、Google Cloud Storage マウント (GCS fuse) と Litestream のパフォーマンス比較を大雑把に行った。

今回は、1 vCPU でどのくらいのパフォーマンスが出るのか、もう少し詳細に検証する。

パフォーマンス比較

仕様

前回と同様、計測される側の Ruby on Rails の動作は以下である。

• id, count の2カラムを持つ counters テーブルを作成
• seeds.rb で id = 'count_up', count = 0 のレコードを1件作成
• /count_up への POST リクエスト毎に、id = 'count_up' のレコードの count を1増やす(update_all("count = count + 1"))
• レスポンスには、count の値を {"count":4856} の形式で返す
• /count_up への POST リクエストを多数回実行し、Request per second (RPS) を計測

パフォーマンス計測には k6 を用いた。
今回は、計測誤差が少なくなるよう、シナリオに変化を加えた。

import http from 'k6/http';
import { check } from 'k6';

export const options = {
  vus: 2,
  duration: '120s',
};

export default function() {
  const res = http.post('https:// URL .asia-northeast1.run.app/count_up');
  check(res, { "status is 200": (res) => res.status === 200 });
}

コンテナの同時リクエスト受け付け数を 2 から 2 刻みに 20 まで変化させた。3回計測し、それぞれの指標について、3回のうちの中央値を採用した。

取得した指標は、med, avg, p(90), p(95), min, max である。

Cloud Run のコンテナには、1 vCPU と 1 GiB のメモリを割り当てた。

Cloud Run の Google Cloud Storage マウント (GCS fuse)

CPU utilization はほぼ 100 % で、メモリ使用量は 12 % 未満だった。

単位は ms である。

Litestream

CPU utilization はほぼ 100 % で、メモリ使用量は 20 % 前後だった。

単位は ms である。

考察

全体的なレイテンシは、Litestream の方が低く、Cloud Storage に書き込むためのレイテンシが高いためだと想定される。

min レイテンシを全体的に見たときに、ほぼ変わらないのは、最初の数回のリクエストが早く応答しているためと考えられる。Litestream と Cloud Storage マウントの差は約 2 ms で、これが Cloud Storage への書き込みの最短レイテンシと考えられる。Litestream は、ローカルに書き込みを完了した時点で次の処理に進み、転送はバックグラウンドで非同期にレプリケーションされるため、書き込みの待ち時間が発生しないと考えられる。

avg （相加平均）はどちらもほぼ線形に増加している。（生データに対して）y切片を0としたときの係数は、8.19 と 4.77 である。約1.7倍の差がある。これがパフォーマンスの差ほぼそのものと言って良いだろうか？

中央値 (med) と平均値 (avg) の差分については考察が難しい。Litestream については、vus = 12 で med が小さかったところから大きくなる側に逆転しているが、その後は med, avg が近づいている。Cloud Storage については、大体の場合 med の方が若干小さく、ロングテールになっているためだと考えると、妥当な結果である。

どちらも、純粋に CPU と書き込みの待ち時間が処理に影響しており、特別なボトルネックはないと考えて良さそうだ。

生データ (RAW Data)

Cloud Run の Google Cloud Storage マウント

Litestream

Cloud Run SQLite Persistence: GCS Mount vs. Litestream Performance Comparison (Part 2)

Conclusion

When using SQLite with Rails 8 on Cloud Run, we found that for write performance, Litestream outperforms Google Cloud Storage mount (GCS fuse) by about 1.7 times.

If your application involves write operations, using GCS fuse should be carefully considered, making Litestream a strong alternative.

This is the end of the series of articles.

Table of Contents

• Conclusion
• Table of Contents
• References
• Introduction
• Performance Comparison
  • Specifications
  • Cloud Run Google Cloud Storage Mount (GCS fuse)
  • Litestream
• Analysis
• Raw Data (See the Japanese part)

References

• Previous Article: Cloud Run の Google Cloud Storage マウントと Litestream のパフォーマンス比較（1回目）https://tako.nakano.net/blog/2025/05/cloud-run-sqlite-performance-part-1/

Introduction

In the previous article, we performed a rough performance comparison between Google Cloud Storage mount (GCS fuse) and Litestream for a Rails 8 application with a SQLite backend running on Cloud Run.

This time, we will conduct a more detailed investigation to see how much performance can be achieved with 1 vCPU.

Performance Comparison

Specifications

As before, the behavior of the Ruby on Rails application being measured is as follows:

• A counters table is created with two columns: id and count.
• seeds.rb creates one record: id = 'count_up', count = 0.
• For each POST request to /count_up, the count of the id = 'count_up' record is incremented by 1 (update_all("count = count + 1")).
• The response returns the value of count in the format {"count":4856}.
• We execute numerous POST requests to /count_up to measure Requests Per Second (RPS).

We used k6 for performance measurement.
This time, we modified the scenario to reduce measurement errors.

import http from 'k6/http';
import { check } from 'k6';

export const options = {
  vus: 2,
  duration: '120s',
};

export default function() {
  const res = http.post('https:// URL .asia-northeast1.run.app/count_up');
  check(res, { "status is 200": (res) => res.status === 200 });
}

We varied the number of concurrent requests the container accepts from 2 to 20, in increments of 2. We ran the measurement 3 times for each setting and used the median of the three runs for each metric.

The metrics collected were: med, avg, p(90), p(95), min, and max.

The Cloud Run container was allocated 1 vCPU and 1 GiB of memory.

Cloud Run Google Cloud Storage Mount (GCS fuse)

CPU utilization was nearly 100%, and memory usage was less than 12%.

All units are in ms.

Litestream

CPU utilization was nearly 100%, and memory usage was around 20%.

All units are in ms.

Analysis

Overall latency is lower with Litestream, which is assumed to be due to the high latency of writing to Cloud Storage.

When looking at the overall min latency, there is almost no difference. This is likely because the first few requests respond quickly. The difference between Litestream and the Cloud Storage mount is about 2 ms, which can be considered the minimum write latency to Cloud Storage. With Litestream, it is thought that there is no write latency because it proceeds to the next operation as soon as the write to the local file is complete, and the transfer is replicated asynchronously in the background.

The avg (arithmetic mean) increases almost linearly for both. The coefficients, when the y-intercept is set to 0 (based on the raw data), are 8.19 and 4.77. This is a difference of about 1.7 times. Can we say this is essentially the performance difference?

The difference between the median (med) and the average (avg) is difficult to analyze. For Litestream, at vus = 12, the med flips from being smaller than avg to being larger, but they converge afterward. For the Cloud Storage mount, the med is generally slightly smaller, which is a reasonable result considering it has a long tail.

It seems safe to conclude that for both methods, the processing is purely affected by CPU and write latency, with no other specific bottlenecks.

Raw Data (See the Japanese part)

See the Japanese part above for the raw data.