エピローグ — サーバーレスの未来と適材適所
1年後。ダイチは新入社員のオリエンテーションで登壇していた。
「去年、深夜3時に叩き起こされたのが何回あったと思いますか?」
参加者が苦笑いする。
「ゼロです。一度もなかった」
拍手が起きた。インフラ担当としてのダイチの夜は、サーバーレスへの移行とともに変わった。
1年間で学んだこと
サーバーレスが「正解」だった場面
ダイチがサーバーレスで成功した共通点は明確だった。
- 予測できないトラフィックスパイク: セール時の商品検索
- イベントに反応する処理: ファイルアップロード後の変換
- 散発的に実行されるバッチ: 週1回のレポート
- 外部サービスのWebhook: 常時起動している必要がない
サーバーレスを「選ばなかった」場面
全部を移行しなくて良かった、とダイチは思っている。
| 残したもの | 理由 |
|---|---|
| コア注文処理（Rails） | ActiveRecordのトランザクション管理が堅牢 |
| 管理画面（Rails Admin） | 複雑な画面をLambdaで再実装するコスト > メリット |
| ユーザー認証（Devise） | 枯れたライブラリを使い続けるほうがリスクが低い |
| 在庫リアルタイム更新 | コールドスタートが許容できなかった |
サーバーレスを選ぶ判断フレームワーク
ダイチが後輩に伝えている判断の流れ。
サーバーレスの未来
オリエンテーションでダイチが話した、サーバーレスの現在地と展望。
コンテナとサーバーレスの融合
Lambda は現在、コンテナイメージをサポートしている。最大10GBのコンテナイメージをそのままLambdaで動かせる。
# Lambda 用の Dockerfile（ECR に push して Lambda で動かす）
FROM public.ecr.aws/lambda/ruby:3.2
COPY Gemfile Gemfile.lock ./
RUN bundle install --path vendor/bundle --jobs 4
COPY . .
CMD ["app.lambda_handler"]# コンテナイメージを ECR に push
aws ecr get-login-password --region ap-northeast-1 | \
docker login --username AWS --password-stdin \
123456789012.dkr.ecr.ap-northeast-1.amazonaws.com
docker build -t ec-site-products .
docker tag ec-site-products:latest \
123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/ec-site-products:latest
docker push \
123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/ec-site-products:latestこれにより「既存のDockerワークフローをそのまま使いながら、サーバーレスの利点を得る」ことができる。
Lambda SnapStart（Java向け、将来的に他言語も）
JVM言語向けに既に提供されている SnapStart は、初期化済みのスナップショットからコンテナを起動することでコールドスタートをほぼゼロにする。Ruby 向けにも将来的な展開が期待される。
AWS Lambda Web Adapter
HTTP サーバーをそのまま Lambda で動かす仕組み。Rack/Sinatra/Railsアプリを最小限の変更でLambdaにデプロイできる。
# Rack/Rails アプリを Lambda で動かす
FROM public.ecr.aws/lambda/ruby:3.2
# Lambda Web Adapter を追加
COPY --from=public.ecr.aws/awsguru/aws-lambda-adapter:0.8.1 \
/lambda-adapter /opt/extensions/lambda-adapter
ENV PORT=8080
ENV AWS_LAMBDA_EXEC_WRAPPER=/opt/bootstrap
COPY . .
RUN bundle install
# Puma を起動するだけ
CMD ["bundle", "exec", "puma", "-b", "tcp://0.0.0.0:8080"]INFO
Lambda Web Adapter を使えば、既存のRailsアプリをほぼそのまま Lambda でホストできる。EC2/ECSからの移行コストを大幅に下げる手段として注目されている。ただし15分のタイムアウト制限は変わらない。
よくある落とし穴と対策
ダイチが過去1年で踏んだ失敗と、その対策をまとめた。
1. Lambda地獄（関数の乱立）
Before: Lambda関数が100個以上に増殖
After: 機能ドメインでグルーピング、1関数に複数ルートをまとめる
判断基準:
- 同じコードを共有するなら1つの関数にまとめる
- デプロイを分けたい理由があるなら別関数
2. ローカル開発のつらさ
# Docker を使った sam local では遅くなる
sam local start-api # Docker起動で20-30秒待つ
# 改善: ビジネスロジックをLambdaから分離してユニットテストを充実させる
# Lambdaハンドラは「薄い入出力変換レイヤー」に留める# ハンドラは薄く、ビジネスロジックは別クラスに
def lambda_handler(event:, context:)
product_id = event.dig('pathParameters', 'id')
# ビジネスロジックはPOROクラスに切り出す
product = ProductFinder.find(product_id)
success_response(product.to_h)
end
# spec/product_finder_spec.rb でローカルにテストできる
# LambdaはRSpecで動く必要すらない3. 分散トレーシングの不足
Before: "どのLambdaで何が起きたか" が全く分からない
After: X-Ray + 構造化ログで全トレース可能
必須の設定:
- Globals.Function.Tracing: Active
- 全ログに requestId, correlationId を含める
- CloudWatch Logs Insights でのダッシュボード作成
4. テスト環境のドリフト
問題: ローカルと本番でIAMポリシーが違い、本番でのみ権限エラー
対策:
- sam validate --lint でポリシーを静的チェック
- IAM Access Analyzer で最小権限の検証
- Staging環境を本番と同じSAMテンプレートから生成
チームへのメッセージ
オリエンテーションの最後に、ダイチは新入社員にこう言った。
「サーバーレスは目的ではなく手段です。深夜の呼び出しをなくしたい、スケーリングの心配をなくしたい、そういう具体的な課題に対して、サーバーレスが有効な解決策かどうかを考えてください」
「ゼロからLambdaで全部作る必要もない。うちみたいに、Railsと組み合わせるハイブリッドアーキテクチャで始めるのが現実的です」
「大事なのは、小さく始めて、学んで、改善すること。それだけです」
ダイチの旅はここで終わりではない。
次のチャレンジは、機械学習モデルをSageMaker Serverless Inferenceで動かし、商品のレコメンド機能をサーバーレスで実現することだ。Lambda、Step Functions、EventBridge——これらで培った「イベント駆動の思考」が、次の挑戦でも活きてくる予感がしていた。
この本で学んだこと まとめ
| 章 | 学んだこと |
|---|---|
| 1 | サーバー管理の課題とサーバーレスへの動機 |
| 2 | FaaS・BaaS の概念、Lambda の実行モデル |
| 3 | SAM を使った Lambda 関数の作成とデプロイ |
| 4 | API Gateway + Lambda で REST API を構築 |
| 5 | S3・SQS・EventBridge によるイベント駆動設計 |
| 6 | DynamoDB と Aurora Serverless の使い分け |
| 7 | Step Functions でのワークフロー設計 |
| 8 | IAM 最小権限・Secrets Manager・VPC 配置 |
| 9 | コールドスタート対策・Provisioned Concurrency・料金計算 |
| 10 | Rails + Lambda ハイブリッドアーキテクチャ |
| 11 | 適材適所・意思決定フレームワーク |
INFO
サーバーレスアーキテクチャの全コードサンプルは、serverless-ec-api という名前のSAMプロジェクトとしてまとめて使えるよう構成されています。sam build && sam deploy --guided で、この本で学んだアーキテクチャを自分のAWSアカウントにデプロイして試してみてください。
ダイチのようなインフラエンジニアが、深夜の呼び出しから解放されて、本当に価値ある開発に集中できる日が、サーバーレスアーキテクチャとともに広がっていくことを願っています。