プロローグ — サーバーを捨てる日

午前3時17分。ダイチのスマートフォンが震えた。

[CRITICAL] Production server CPU 98% - Immediate action required

彼はベッドから飛び起き、ノートパソコンを開いた。画面の光が暗い部屋を照らす。Slackには既に10件以上のメッセージが積み上がっていた。ECサイトが落ちている。毎月恒例のセール日、午前3時という最悪のタイミングで。

ダイチは入社5年目のインフラエンジニアだ。担当しているのは中規模ECサイトのバックエンド。Rails製のモノリシックアプリケーションが、3台のEC2インスタンスの上で動いている。

疲弊するサーバー管理の日々

ダイチの日常は、こんな警告との戦いだった。

# よくある深夜の作業
ssh -i ~/.ssh/production.pem ec2-user@10.0.1.45
top
# CPU使用率98%... またか
sudo systemctl restart puma
# 一時的に回復するが根本解決ではない

セール期間中はオートスケーリングが追いつかない。トラフィックのスパイクは予測できず、スケールアウトに5〜10分かかる間に、ユーザーはエラーページを見せられる。

彼のチームが管理するインフラの全貌はこうだった。

月々のEC2費用だけで約15万円。さらにRDS、ElastiCache、ALBを合わせると月30万円を超える。そして何より、ダイチと同僚たちの深夜対応という「見えないコスト」が積み上がっていた。

サーバーレスとの出会い

障害対応を終えたのは朝5時過ぎ。ダイチは疲れ果てて椅子に深く沈み込み、技術ブログをぼんやりと眺めていた。そこに一つの記事が目に入った。

「AWS Lambda で実現するゼロサーバー運用 — サーバーのことを考えない開発へ」

サーバーのことを考えない、か。

ダイチはコーヒーを一口飲んだ。サーバーを管理しなくていいなら、何が変わるのだろう。パッチ適用、OS更新、キャパシティプランニング、深夜の障害対応——これらから解放されたら、開発にどれだけ集中できるか。

記事の中には、こんな言葉があった。

「Lambda を使えば、コードをアップロードするだけで実行できる。サーバーのプロビジョニングも、スケーリングも、高可用性の確保も、すべて AWS が面倒を見てくれる」

ダイチは読み進めた。Lambda は1秒未満の実行でも課金されない。リクエスト数に応じて自動でスケールする。使った分だけ払う——それだけだ。

決意

翌週の月曜朝、ダイチはチームミーティングで提案した。

「画像リサイズ処理を Lambda に移行してみたいんですが」

ECサイトでは商品画像のアップロード時に、サムネイル生成処理が走っていた。これが CPU を食い、セール中の処理遅延の一因になっていた。Lambda に移行すれば、メインのアプリサーバーへの負荷を切り離せる。

チームリーダーの田中さんが頷いた。「小さく試してみよう。うまくいったら他の処理にも広げればいい」

これがダイチのサーバーレスへの旅の始まりだった。

この本で学ぶこと

この本は、ダイチがサーバーレスアーキテクチャを学んでいく物語に沿って構成されている。

各章では、ダイチが直面する実際の問題を解決しながら、サーバーレスの概念とAWSのサービスを学んでいく。コードは Ruby で書き、インフラは AWS で構築する。Railsエンジニアがサーバーレスを学ぶための、最も現実に即した入門書を目指している。

サーバーレスが「答え」ではない

一つ、最初に断っておきたいことがある。

サーバーレスはすべての問題を解決する銀の弾丸ではない。長時間実行処理、レガシーシステムとの統合、コールドスタートのレイテンシが許容できないユースケースでは、従来のサーバーアーキテクチャが依然として適切な選択肢だ。

この本の最後で、ダイチはその判断を学ぶことになる。「どこにサーバーレスを使い、どこには使わないか」——それが本当の意味でのアーキテクト思考だ。

さあ、ダイチと一緒にサーバーレスの世界に踏み込んでいこう。