サーバーレス移行で得たリアルな開発ノート：コストと運用最適化の舞台裏
クラウドネイティブが当たり前となった昨今、多くのプロジェクトで「レガシー環境からサーバーレスへの移行」が検討されています。しかし、実際に手を動かしてみると、費用面や運用面の“思わぬ落とし穴”に直面しがちです。本記事では、あるスタートアップB社の事例を通じて、サーバーレスアーキテクチャ導入時に経験した具体的な苦労や学び、そしてコスト最適化のノウハウを余すところなく共有します。技術リーダーやプロジェクトマネージャーはもちろん、開発会社の選び方や予算・費用相場を把握したい方にも役立つ内容です。
プロジェクト背景と移行検討のきっかけ
B社は元々オンプレミスで動かすモノリシックなECシステムを運用していました。アクセス増加に伴うサーバ増強コストが膨らみ、保守運用も複雑化していたため、「クラウドに移行して費用を抑えたい」「インフラ運用をできるだけ自動化したい」という目的でサーバーレス化を検討しました。
特にAWS LambdaやAPI Gatewayを使ったマイクロサービス化により、稼働中の機能単位でインスタンスをスケールできる点に大きな魅力を感じたそうです。しかし、予算策定時に出てきた見積もり単価は「1,000リクエストあたり○円」「GB-秒あたり○円」など、慣れない単位ばかりで、発注担当は相場感が掴めずに混乱していました。そこで、まずはPoC（概念実証）を小規模に実施し、実際のリクエスト数や処理時間を測定したうえで費用予測を行うことに。
この段階での教訓は、「机上の見積もりだけで判断せず、必ず実負荷に近い形でコスト計算を行う」こと。PoCで得たログをもとにシミュレーションを繰り返し、月間予算をグラフ化して社内合意を取り付けたことで、後工程の混乱を大幅に防げました。
要件定義での失敗と教訓
要件定義段階で最も苦労したのは、バッチ処理系の移行要件です。既存システムでは深夜に大量バッチを一括実行し、売上集計やレコメンド計算を行っていました。しかし、Lambdaの実行時間制限（最大15分）や並列実行数には上限があるため、従来通り一括処理を移しても同じパフォーマンスが出せない可能性が高い状況でした。
当初の要件定義では「既存のバッチをほぼ変更せずに移行したい」という希望が強く、ここで曖昧な定義のまま見積もりだけ発注してしまったのが失敗の一因です。結果として開発途中で「Lambdaがタイムアウトする」「API Gatewayがスロットルされる」といった問題が頻発し、追加費用が大幅に膨らみました。
この経験から得た教訓は以下の通りです：
-
バッチ処理は小分けにする設計に切り替える：Lambda関数を時分割、もしくはEventBridge（旧CloudWatch Events）＋Step Functionsでワークフロー化し、長時間処理を分割実行する。
-
API仕様とSLAを明確化する：スロットルエラーや実行時間上限を踏まえ、失敗時リトライ要件や監視アラートの閾値を設計要件に盛り込む。
-
要件定義にパフォーマンスレビューを組み込む：PoCの段階で実行時間やエラー発生率をKPI化し、「要件定義→PoC→要件確定」を短いサイクルで回す。
いかに要件を具体化し、曖昧さを残さないかが、開発会社への発注と予算管理をスムーズに行うカギになります。
開発会社選定のポイントと注意点
サーバーレス黎明期と比べ、現在は多くの開発会社やSIerがサーバーレス案件を手掛けています。しかし、実際に提案を比較すると、
-
AWS認定を持つエンジニアの割合
-
ライブラリやフレームワーク活用経験（Serverless Framework、SAM、Pulumiなど）
-
既存システムからの移行実績
-
バッチ処理やAPIスロットリング対策のノウハウ
といった点で大きくバラつきがありました。さらに、見積もりに含まれる工数の粒度も「基礎実装込み」「運用自動化込み」など各社でまちまちです。
選定時のポイントとしては、
-
実案件ベースでの成功事例を確認する
-
課題発見→設計→PoC→本番移行の各フェーズ工数を細かく提示させる
-
運用設計（モニタリング/アラート設置、コストレポート作成）の工数も見積もりに含める
特にノンコア機能の自動化（Infra as Code、CI/CDパイプライン構築）を別見積もりにしてしまうと、後から都度発注となり運用フェーズで想定外の追加費用が発生しがちです。開発会社には「予算○○万円の中で初期構築から運用設計までをワンストップで依頼したい」旨を明示しましょう。
予算管理でぶつかった壁と回避策
サーバーレスは利用量に応じた従量課金モデルですが、従量とはいえトラフィック変動やバッチのピークタイムでコストが急増することがあります。B社では以下のような課題に直面しました。
-
想定外のスパイク課金：キャンペーン初日にアクセスが急増し、API Gatewayの課金が跳ね上がった
-
無駄呼び出しの発生：アプリのリトライ処理がループ状況に陥り、Lambda呼び出し数が肥大化
-
ログ出力コストの見落とし：CloudWatch Logsの保持期間設定を誤り、数十万円のログ保存料が発生
これらを回避するために取った施策は：
-
バジェットアラートの設定：AWS Budgetsで月額上限に近づいたら通知→即チューニングへ
-
呼び出し数制限：API GatewayやLambdaのConcurrency設定で上限を抑止
-
ログ保持ポリシーの最適化：必要最小限のログレベルに絞り、S3や外部ログサービスへの転送で低コスト化
また、毎月の定例レビューで「コストレポート」を全社共有し、開発／運用両面で無駄を見つけ次第改善要求を出せる体制を整えることで、予算超過のリスクを大幅に低減しました。
デプロイとCI/CDパイプライン構築の教訓
サーバーレス移行プロジェクトでは、インフラ構成の変更が頻繁に発生するため、CI/CDパイプラインの整備が成功の要となりました。B社では当初、ソースコードコミット時に手動デプロイを行っていましたが、機能追加や設定変更が増えるにつれてミスが頻発。特にステージング環境と本番環境での差異がトラブルを引き起こし、リリース直前でバグが見つかるケースが相次ぎました。
そこで、Git リポジトリと連携したCodePipeline＋CodeBuildを導入し、以下のような自動化フローを確立しました。
-
Lint／ユニットテスト実行：プルリクエスト時に自動でAngularユニットテストやESLintを実行
-
ステージング環境デプロイ：マージ後に自動でステージングにデプロイし、Smokeテストを実行
-
承認ワークフロー：ステージングテスト合格後、承認者がボタン一つで本番デプロイ
-
ロールバック機能：CloudFormationスタックの変更セットを用い、異常時は即座に前バージョンへ復元
これにより、「誰がいつ何をリリースしたか」「どのコミットで問題が生じたか」を可視化でき、開発会社への発注時にも「自動化パイプライン設計費用」を含めることで、追加予算交渉がスムーズになりました。
運用監視とトラブルシューティング
サーバーレス環境は可視化が難しい一面もあります。CPUやメモリの指標が見えにくいため、「なぜ性能劣化が起きたのか」「どこでエラーが頻発しているのか」を把握するには工夫が必要です。B社では以下の運用監視体制を整備しました。
-
カスタムメトリクスの出力：Lambda実行時間、外部API呼び出し時間をCloudWatchカスタムメトリクスとして出力
-
ダッシュボード化：Grafana＋CloudWatch Connectorでリアルタイム監視ダッシュボードを作成
-
分散トレーシング：X-Rayを有効化し、関数間での遅延やエラー箇所を可視化
-
アラート設計：エラー率やレイテンシがSLA閾値を超えた際にSNS経由で即通知
-
インシデント管理：PagerDuty連携で夜間対応も自動的にアラートがオンコール担当にエスカレーション
これらの取り組みにより、開発会社や運用ベンダーに対しても「どの指標をいくらで監視／アラート設定するか」を明確に依頼でき、予算オーバーを未然に防ぎました。
コスト最適化の継続的改善
移行初期にPoCベースで立てたコストモデルは、本番稼働後の実負荷データを踏まえ都度アップデートが必要です。B社では以下のサイクルで継続的に見直しを行いました。
-
月次コストレポート作成：サービス別、関数別、ログ出力別に費用を細分化
-
無駄リソースの洗い出し：利用率の低いLambda Layerや過剰なログレベル設定を削減
-
プラン変更交渉：Step FunctionsやEventBridgeの料金プラン変更タイミングでAWS担当と折衝
-
リザーブドコンカレンシー検討：常時高頻度関数に対してリザーブドコンカレンシー枠を購入し、従量課金単価を抑制
-
利用パターンに応じた技術見直し：一定時間あたり大量バッチはFargateバッチ或いはEC2バッチと比較してコストメリットがあるケースもあり、適宜切り替え
このPDCAを回すことで、開始半年でインフラコストを20％削減。開発会社への次フェーズ発注時には「最新の月次コストを踏まえた見積もり」を提示し、交渉力を向上させました。
組織体制とナレッジ共有の重要性
サーバーレス環境を維持するには、単に開発会社に依存するだけでは不十分です。社内の知見を蓄積し、関係者間で情報共有する体制が必要です。B社では下記の仕組みを取り入れました。
-
技術ドキュメント整備：Wikiにアーキテクチャ図、運用手順、コストモデルを時系列で保存
-
定期勉強会：毎月「サーバーレスラウンドアップ」を開催し、開発チームと運用チームが当月の改善ポイントを発表
-
オンボーディングガイド：新規エンジニア向けに「Lambda開発のベストプラクティス」や「予算管理フロー」をガイド化
-
開発会社とのナレッジトランスファー：契約終了後も半年間は定期メンテナンスを依頼し、社内担当者がハンズオンで学べる場を確保
-
Slack運用チャンネル：異常発生時に開発会社と社内運用チームがリアルタイムに情報交換
これにより、「発注したが結局ノウハウが社内に残らない」「次回発注時に予算見積もりがゼロベースになる」といったリスクを回避できます。
今後の拡張とマルチクラウド検討
サーバーレス化で得た知見を応用し、B社では次のフェーズとしてマルチクラウド戦略も検討中です。
-
GCP Cloud Runとの併用：一部バッチやCI/CDをCloud Build＋Cloud Runに移し、GCP特有の無料枠や割引プログラムを活用
-
Azure Functionsの評価：特にWindows系バッチ処理との親和性が高いケースで検証
-
コストアービトラージ：同じ処理を異なるクラウドでベンチマークし、相場に応じて使い分ける仕組みのPoC
-
データレプリケーション設計：DynamoDBのグローバルテーブルやCloud Spannerレプリケーションなどを使った可用性向上
-
コンテナ化戦略：FargateやCloud Runに耐障害性の高いマイクロサービスを分散配置
これらを通じ、さらなる費用最適化と可用性向上を目指しています。
成功のポイントと読者へのアドバイス
最後に、本事例から得られた“即実践できる”成功のポイントを整理します。
-
PoCから必ず実負荷データを取得し、予算モデルに反映する
-
要件定義時にパフォーマンス観点＋開発／運用自動化要件を盛り込む
-
開発会社選びは実績・認定だけでなく、具体的な工数見積もりの粒度を比較する
-
CI/CD／インフラ自動化を初期工数に組み込み、運用フェーズも同一ベンダーに発注する
-
月次でコストモニタリングし、無駄リソースを継続的に削減する
-
社内ナレッジ共有体制を設計し、発注／運用の“ブラックボックス化”を防ぐ
サーバーレス移行は、一見“簡単にコスト削減できそう”ですが、要件定義や開発会社選定、運用設計など多面的な観点が必要です。本記事が、次のプロジェクトで失敗を減らし、理想的なシステム運用・費用管理を実現する一助になれば幸いです。
