性能は取るがコスト11倍！僕がProvisioned Concurrencyを見送った、技術的意思決定の舞台裏

背景

AWS Lambdaのパフォーマンス問題を調べていると、ほとんどの場合「Provisioned Concurrencyを使えばCold Startが解消できる」という情報にたどり着きますよね。まさに、パフォーマンスを劇的に改善する「特効薬」のような機能です。

しかし、現実の開発では「技術的に最適＝ビジネス的に最適」とは限りません。僕たちのプロジェクトでも、この特効薬の導入を真剣に検討したのですが、最終的にはコスト対効果の観点から「今回は見送ろう」という決断に至りました。

この記事では、なぜ僕たちがその決断をしたのか、もし導入していたらどうなっていたのか、そしてどのような判断基準で意思決定したのかを、実際のデータとコスト試算を交えながら詳しく解説していきます。技術選択における現実的な意思決定プロセスの一例として、きっと皆さんの参考になるはずです。

Provisioned Concurrencyとは？

Provisioned Concurrencyとは？ タクシーに例えてみましょう。

• 通常 (オンデマンド): タクシーに乗りたい時に電話で呼びます。到着まで数分待ちますが、料金は乗った分だけです。これが通常のLambdaです。
• Provisioned Concurrency: 自宅の前に24時間タクシーを待機させておくようなものです。乗りたい時に一瞬で乗れますが、乗っていない時間も待機料金がかかります。

このように、Provisioned Concurrencyは、Lambda関数を常時準備完了状態で待機させることで、Cold Startを完全に解消してくれる機能なんです。ただ、その利便性と引き換えに、待機時間分の追加コストが発生してしまいます。

コスト構造の分析

私たちのプロジェクトでの試算

実際に、僕たちのプロジェクトでコストがどれくらい変わるのかを試算してみました。

シナリオ1: Provisioned Concurrency未使用（現状）

• 月間総コスト: $0.19 （約20円）

シナリオ2: 主要な関数にProvisioned Concurrencyを適用

• 月間総コスト: $2.11 （約230円）

【ポイント】コスト比較サマリ

• 現状: 月額 $0.19
• 改善案: 月額 $2.11
• 増加額: $1.92（約11倍のコスト増）

金額自体は小さいものの、コストが11倍になるという事実は、特に小規模なプロジェクトにとっては、やはり無視できないインパクトがありました。

特に、サラリーマンであり、お小遣い制度な自分にとって月額2ドルは看過できない金額です。

パフォーマンス向上効果のシミュレーション

次に、コストをかけてでも得られるパフォーマンス向上の価値を考えました。

効果1: Cold Start完全解消

Provisioned Concurrencyを適用すれば、応答時間は常に安定し、ユーザーは予測不能な遅延から解放されます。

効果2: ユーザー体験の劇的向上

• 改善前: 「たまにすごく遅い」という不安定な体験。
• 改善後（予想）: 「常に高速で安定している」という信頼感のある体験。

効果3: ビジネスメトリクスへの影響（推定）

ビジネスメトリクスとは？

• コンバージョン率: サイト訪問者のうち、商品購入や会員登録など、目標とする行動を完了した人の割合。
• 離脱率: 1ページだけ見てサイトを去ってしまった人の割合。サイトの表示が遅いと、この率が高くなります。

Webサイトの表示速度が1秒遅れると、離脱率が7%増加するという業界データがあります。私たちの改善で最悪ケースの遅延が約2秒短縮されるため、ユーザーの離脱が減り、ビジネス的な価値（売上や登録者数の増加）につながる可能性があります。

代替案の検討と実装効果

「11倍のコストを払う前に、他にできることはないか？」と考え、以下の無料の対策を先に行いました。（他の対策は別の記事に書きました。）

• 代替案1: コード最適化: アプリケーションのコード自体を整理し、効率化しました。
• 代替案2: アーキテクチャ改善: データのやり取りを効率化し、体感速度を向上させました。

結果: これらの対策だけで、最悪ケースの応答時間を79%短縮でき、ユーザーからの不満は解消されると判断しました。

意思決定プロセスと判断基準

評価マトリクス

各選択肢を「技術効果」「コスト効率」「実装の容易さ」などの観点で点数付けし、比較しました。

最終的な判断理由

私たちは、以下の理由からProvisioned Concurrencyの採用を見送りました。

1. コストインパクト: お小遣い制の私にとって、コスト11倍増は大きな負担でした。
2. 代替案の十分な効果: 無料の対策で、ユーザーが満足するレベルまで十分に性能を改善できました。
3. 将来の再検討の余地: プロジェクトが成長し、ユーザー数が10倍、100倍になれば、追加コストの割合は相対的に小さくなります。その時に改めて導入を検討することにしました。
4. 技術的学習の価値: 簡単な設定で解決するのではなく、自分たちでコードを最適化することで、技術力が向上しました。

できるだけコストを抑えたいという背景はもちろんありますが、何よりもプロジェクトのステージ（段階）に合った選択をするのが大事だと考えています。

• 立ち上げ期: コスト効率を重視し、完璧な性能より「十分な性能」を目指す。
• 成長期: ユーザー体験の重要性が増すため、コストをかけてでも性能向上策を検討する。
• 成熟期: 安定性と信頼性が最優先。最高の性能を維持するための投資を惜しまない。