サーバーレスは、なんとも魅力的な選択肢だ。インフラ管理から解放され、使った分だけ払えばよい。ところが実際に導入してみると、インフラの手間が減った代わりに別の苦労が待っている。アプリケーション設計の側で、特有の制約や複雑さと向き合う羽目になるのだ。

たとえるなら、サーバーレスは時間貸しの会議室である。事務所を構えるよりずっと身軽だが、貸し会議室には貸し会議室の規約がある。つまり、誰にとっても正解になるわけではない。なぜそうなのかを、主要な制約と、そこから導かれる向き不向きという順で整理してみた。

短命でステートレスな実行モデル

サーバーレス、とりわけ FaaS を採用するなら、避けて通れない現実的な制約がいくつかある。そもそもサーバーレスは、短時間で終わるイベント駆動の処理を前提にしたモデルだ。会議室は、長居するための場所ではない。

まず、実行時間に上限がある。通常のAWS Lambda関数では最大15分なので、それを超える処理は分割や別の実行方式を考える必要がある。また、常駐プロセスのように、呼び出しが終わった後も自分の処理が動き続ける前提にはできない。ただし、実行環境が毎回ただちに破棄されるわけではなく、後の呼び出しに再利用される場合もある。

さらに、アプリケーションはステートレスに設計する。再利用された実行環境ではメモリや一時ファイルが残る場合があるが、次のリクエストが同じ環境に来る保証はない。継続して必要な状態は、外部のデータベースやストレージへ持たせる。貸会議室のホワイトボードに前回の文字が残っていても、それを正式な台帳にはしない、ということだ。

コールドスタート

しばらく呼ばれていなかった関数が実行されるとき、環境の初期化が走ってレスポンスが遅れることがある。いわゆるコールドスタートだ。長らく使われていなかった部屋は、鍵を開けて空調を入れるところから始まる、というわけである。

この遅れは、Java や .NET のように起動の重い言語を使う場合にとりわけ目立ちやすい。関数を VPC 内に置く場合も同様だ。低レイテンシが求められる API では、ユーザー体験にじかに響きかねない。

見えにくさ

システムが小さな関数の群れに分散するので、従来のモノリスに比べてトラブルシューティングは格段に難しくなる。ローカル環境で完全に再現するのは困難だ。複数の関数をまたぐ処理のトレースも、込み入ってくる。

結果として、全体像を掴むには専用の観測ツールを使いこなす技量が欠かせない。CloudWatch Logs、X-Ray、Datadog といった面々である。どこで落ちたのかを探すうちに、障害そのものより捜索のほうが大仕事になっている。そんな事態も、十分ありうる。

ロックインとコスト

なお、サーバーレスはクラウドベンダーが提供する各種サービスと密接に結びついている。DB、ストレージ、トリガーといったものだ。そのため、あとから他社のクラウドやオンプレミスへ移ろうとすると、移行コストがかさむ。アーキテクチャごと書き直す必要が出てくることもある。

コストの見積もりも、いささか厄介だ。使わないときは 0 円という利点がある反面、アクセスが急増したときに請求額がどこまで膨らむかは読みにくい。翌月の請求書を開くまで真相が分からない、というのは心臓に悪い。

また、24 時間 365 日ずっと高い負荷がかかり続ける処理では、固定のインスタンスを借りるよりも割高になるケースが多い。毎日朝から晩まで会議室を借りるくらいなら、素直に事務所を構えたほうが安上がりなのだ。

設計に移ってくる責任

極めつけは、アーキテクチャの複雑化である。インフラ管理が要らなくなった分、その責任はそっくりアプリケーション設計へと移ってくる。建物の管理は貸主がやってくれるが、会議の段取りまでは面倒を見てくれない。

たとえば、失敗時のリトライ方針を決め、2回実行されても問題が起きないように冪等性を担保しなければならない。複数の関数にまたがる処理で一部が失敗したとき、どう整合性を保つかという分散トランザクションの問題も出てくる。これらはすべて、コードの水準で解決する必要がある。チームの設計力が、そのまま生産性に跳ね返ってくるわけだ。

向いている仕事、向いていない仕事

こうした制約を踏まえると、向き不向きはおのずと見えてくる。サーバーレスが向いているのは、まず予測しにくいスパイクがある処理だ。急なアクセス増に合わせて勝手にスケールしてくれるのは、ありがたいことこの上ない。

次に、1 日に数回しか走らないバッチや Webhooks の受け口のような、間欠的な処理。そして、ファイルがアップロードされたら変換処理を走らせる、といったトリガーベースのイベント駆動パイプラインである。どれも、必要なときだけ部屋を押さえれば済む仕事だ。

翻って、向いていないのは、動画変換や巨大なデータの解析バッチのような長時間の実行が必要な処理だ。WebSocket のように接続を常に維持し続けるリアルタイム通信も、相性が悪い。

コールドスタートを許容できない、極めて低いレイテンシが常に求められる API も避けたほうがよい。さらに、常にリクエストが来続ける高負荷なシステムなら、固定インスタンスのほうがコスト効率はよくなる。いずれも、会議室に住み着こうとするような使い方なのである。

以上、サーバーレスの制約と向き不向きを整理した。サーバーレスは魔法の杖ではない。インフラ管理をクラウドベンダーに委ねる代わりに、アプリケーション設計の厳密さを引き受けるという選択である。

導入を検討するなら、運用負荷が減るという利点だけを見ていては足りない。分散システム特有の複雑さを、チームが受け止められるか。その視点で判断したい。サーバーがなくなっても、考えるべきことはなくならないのだ。