2026/04/10

webアプリケーションのクラウドでの性能優先設計

宣伝です。

noteでマガジン「webアプリケーションのクラウドでの性能優先設計」を公開しました。↓こちらの写真が目印です。クラウドの記事なので雲が主役(?)の写真を見出しに使ってます。


2026/03/01から公開していましたが、noteのフォーロー中のトップから外れるとページビューが激減したので、ここでも宣伝してみることに。


内容はタイトルどおりですが、クラウドでwebアプリケーションを実装するにあたって網羅的に必要な知識・技術から書いています。特に運用コスト削減に関する内容が多くなっています。処理性能については良くするというより、必要な性能を確保するという内容になっています。

このブログでは散発的な記事しか書いていませんが、このブログに書いていない内容の方が多くなっています。

以下のような問題に遭遇した方は、ぜひ読んでいただきたいと思っています。解決策が見つかるはずです。

  • 費用
    • クラウドを使っているけど運用費用が想定より高い。
    • クラウドに乗り替えたらオンプレミス/レンタルサーバより運用費用が増えた。
  • 性能
    • スケーリングができない。
    • リクエストの処理に時間がかかる。
    • スケールアウトのたびにリクエストのレイテンシが増加してレスポンスが悪い。

    • その他
      • そもそもクラウドをどのように使えばいいのかわからない。
      • 非同期処理/バッチ処理の効率的な実装方法がわからない。
      • 非同期処理が意図せず中断する。


    またクラウドで使われる以下の技術についても、詳細や使いどころを説明しています。

    • スケーリング
    • サーバレスアーキテクチャ
    • マイクロサービスアーキテクチャ


    A4サイズでデザインしたところ全部で100ページ近い分量になりました。読みごたえがあります。noteでは 1記事=1ページ なので、長い記事は読みにくくなります。それを回避するため複数の記事に分割し、まとめてマガジンとしています。

    分量や、経験からしか得られないノウハウも掲載していますので、有料としています。今は試しにマガジンのみ半額にしています。いつまで半額かは未定で気分次第ですので、興味のある方はお早めに。


    2026/04/07

    Cloud Runのインスタンスベース料金

    Cloud Runの料金体系についての疑問

    Cloud Runサービスには2種類の料金体系があります。

    • リクエストベース(デフォルト)
    • インスタンスベース


    デフォルトのリクエストベースの料金体系はおなじみです。webサーバを構成するCloud Runサービスの機能とも一致していて、わかりやすいのですね。

    一方でインスタンスベースの料金体系はどういう状況で使うべきなのかずっと理解できませんでした。


    インスタンスベースの料金体系

    この疑問については偶然ですが、ブログ記事「新しい CPU 割り当てコントロールにより Cloud Run 上でさらに多様なワークロードを実行」を見つけて理解できました。

    2021/09/28とちょっと古い記事なので、時期的にはCloud Runにはまだサービスしかありません。Jobsはまだリリースされていません。Cloud Functionsはまだ第1世代のみで、Cloud Runとは独立したプロダクトという位置づけでした。


    結論ですが、ユースケースとしてはCloud Runサービスでサブスレッドを使って非同期処理を実行する場合を考慮したものでした。Cloud Runサービスではメインスレッドでリクエストを受信後、そのメインスレッドでレスポンスを返すと処理が終了したものと判断されます。そしてリクエストを処理していないインスタンスは、その後一定時間新たなリクエストが割り当てられないと、スケールインしてスピンダウンする対象となります。

    ここでリクエスト開始~レスポンスを返すまでの間にサブスレッドを生成し、そのサブスレッドでメインスレッドよりも時間のかかる処理を行う実装を行っているとします。メインスレッドがレスポンスを返してしまった時点で、プラットフォーム(Cloud Runサービス)からは 処理中のリクエスト数=0 と見えてしまい、インスタンスのスピンダウンが起きます。この時点でまだサブスレッドは実行中だと、完了前に強制終了させられることになります。




    これを避けるために上記の記事にあるように、CPUの常時割り当ての機能が追加されたということです。最小インスタンス数の設定と組み合わせることで、インスタンスの強制終了によるサブスレッドの停止を回避できます。そしてそれに対応する料金体系がインスタンスベースということでした。


    歴史は繰り返す?

    App Engineでも同じ問題は起きていましたね。App Engineだけ使う場合はサブスレッドを諦めて、タスクキューで解決していました。

    Cloud RunでもCloud Tasksと組み合わせれば同様の方法で回避可能です。


    より新しいソリューション

    現在では非同期処理を実装するためには、BatchやCloud Run Jobsが用意されています。これらはスレッドだけでなくタスクでも並列処理を実装できます。タスクの方がCPU・メモリリソースを分け合わないので、実装やパフォーマンスチューニングは簡単です。起動に時間がかかりますが。