Serverlessアーキテクチャについて
最近、チームのデプロイ方針を整理する中で、Serverless をあらためて見直す機会がありました。この記事では、このアーキテクチャに対する私の理解——どんな問題を解決するのか、裏側の実行メカニズムはどうなっているのか、どんなシナリオに向いていて、どんなシナリオでは慎重になるべきか——を記録しておきます。
背景
この記事を書くきっかけは単純です。私たちのチームには低頻度のタスクがたくさんあります——定期実行スクリプト、イベントのコールバック、たまに発生するファイル処理など。それぞれがサーバー 1 台、あるいは半分を占有し、ほとんどの時間 CPU は遊んでいるのに、マシン代と運用の手間は一切減りません。この「リソースは常駐、負荷はまばら」という矛盾こそ、Serverless が解決しようとしている問題です。
Serverless(サーバーレスアーキテクチャ)は、近年クラウドコンピューティング分野で徐々に注目を集めている方向性です。そのコアコンセプトは、開発者はサーバーのデプロイ、運用、スケーリングを気にする必要がなく、ビジネスロジックの開発だけに集中すればよい、というものです。
補足しておくと、「サーバーレス」とは本当にサーバーが存在しないという意味ではなく、サーバーが開発者から見えなくなるということです。サーバーは依然として存在しますが、クラウドベンダーが一括してスケジューリングと保守を行い、開発者が向き合う抽象レイヤーが「マシン」から「関数」に変わるのです。
従来のアーキテクチャでは、システムをリリースするには通常、サーバーの準備、環境のデプロイ、ネットワークの設定、リソースの監視、そしてスケーリングへの対応が必要で、これらの作業には追加の運用コストがかかります。一方 Serverless アーキテクチャでは、これらのインフラはすべてクラウドベンダーが管理を担い、開発者は関数のコードを書いてデプロイするだけで実行できます。
Serverlessをクラウドで使う
Serverless は通常、クラウドファンクション(Function as a Service、FaaS) の形で提供されます。例えば Alibaba Cloud Function Compute(FC)、AWS Lambda、Tencent Cloud SCF などです。開発者はコードをアップロードするだけで、リクエストがトリガーされるとプラットフォームが自動的に関数を実行し、実際の呼び出し回数と実行時間に基づいて課金されます。
その実行モデルは、1 本のチェーンとしてシンプルにまとめられます:イベントソースがトリガー → プラットフォームがインスタンスをスケジューリング → 関数を実行 → インスタンスを回収。イベントソースは HTTP リクエスト、メッセージキュー、オブジェクトストレージのファイル変更のほか、タイマーでも構いません。プラットフォームはイベントを受け取ると、隔離された実行環境(通常はコンテナか軽量サンドボックス)に関数コードをロードして実行します。実行終了後、環境は再利用のためにしばらく保持され、長時間呼び出しがなければ回収されます。
このモデルがもたらす最大の変化は、アプリケーションがサーバーリソースを長期占有するのではなく、必要なときだけ実行できることです。
課金方式もそれに伴って変わります。従来のサーバーはトラフィックの有無にかかわらず「保有時間」に対して支払いますが、FaaS は「実際の実行」に対して支払い、通常は呼び出し回数と実行時間(割り当てたメモリスペックを掛けたもの)で計算されます。負荷がまばらであるほど、このモデルのコスト優位性は顕著になります。
例えば、次のような業務シナリオです:
- 定期タスクの処理
- Webhook イベントのトリガー
- 画像処理
- データ変換
これらのタスクには常時稼働のサーバーは必要なく、Serverless を使えばイベント発生時に関数を起動してタスクを実行できるため、リソースコストを大幅に節約できます。
Serverlessの弾力性
Serverless の重要な特徴のひとつが自動スケーリング機能です。システムへのリクエストが急増すると、プラットフォームは自動的により多くの関数インスタンスを起動してリクエストを処理し、トラフィックが減れば自動的にリソースを解放します。この一連のプロセスに人手の介入は不要で、分散性と耐障害性を最初から備えています。
この弾力性の裏側にある仕組みは、プラットフォームが「1 回の呼び出し」をスケジューリングの基本単位としていることです。各関数インスタンスは同時に処理するリクエスト数が通常限られており、リクエストが増えれば単一インスタンスに負荷を積み上げるのではなく、水平方向にインスタンスを追加起動します。インスタンス自体がステートレスで、いつでも作成・破棄できるため、スケールアウトや障害対応はプラットフォームレベルの日常的なオペレーションとなり、業務側が自前で設計する必要はなくなります。
小規模プロジェクトやスタートアップチームにとって、このモデルは非常に相性が良いものです。従来のモデルでは、アクセス量がごくわずかでもサーバーを長期的に維持する必要がありましたが、Serverless は呼び出し回数に応じた課金なので、初期のデプロイ・運用コストを大幅に下げられます。例えば Alibaba Cloud Function Compute(FC)は現在、毎月約 100 万回の無料呼び出し枠を提供しており、多くの小規模アプリケーションにはこれで十分です。
とはいえ、Serverless アーキテクチャも完璧ではなく、現時点ではトレードオフを考慮すべき問題がいくつか残っています。
最もよく挙げられるのがベンダーロックインの問題です。Serverless モデルでは、関数は OSS、RDS、メッセージキュー、ログシステムなど、クラウドプラットフォームが提供するサービスに深く依存しがちです。これらの機能を大量に使ったシステムを他のクラウドベンダーに移行しようとすると、コードにある程度の改修が必要になることが少なくありません。このロックインはコードレベルだけの話ではありません——トリガーの設定、権限体系、ログや監視の連携方法はベンダーごとにやり方が異なり、移行コストは想像以上に分散して発生します。
もうひとつの典型的な問題がコールドスタート(Cold Start) です。Serverless の関数は通常コンテナやサンドボックス環境で動作するため、長時間呼び出されないとプラットフォームがリソースを解放します。新しいリクエストが来たときには実行環境を再起動する必要があり、このプロセスが一定のレイテンシをもたらします。
コールドスタートにかかる時間は、おおよそ次の要素の積み重ねです:プラットフォームによる実行環境のスケジューリングと起動、関数コードと依存関係のロード、ランタイムとフレームワークの初期化処理。ランタイムが重く、依存が多いほどこのプロセスは遅くなります——同じビジネスロジックでも、Java のように仮想マシンの起動が必要なランタイムは、スクリプト言語よりコールドスタートが顕著になりがちなのはこのためです。
HTTP リクエストやイベントトリガーのシナリオでは、関数の初回呼び出し時にレスポンスの遅さをはっきり感じることがあります。レイテンシに非常に敏感な業務であれば、予約インスタンス(ウォームアップリソース) を購入することでコールドスタートの影響を減らせますが、その分リソースコストは増えます——本質的には「一部を常駐させる」ことでレイテンシと引き換えにするわけで、従来モデルのコストカーブに逆戻りすることになるため、トラフィックの特性に応じてコストを試算する必要があります。
総じて、Serverless は次のようなシナリオに向いています:
- イベント駆動型アプリケーション
- 短時間で完了するタスク
- トラフィックが不安定なサービス
- 初期規模が小さいプロジェクト
一方、長期稼働、高パフォーマンス、あるいは高度にカスタマイズされた環境が必要なシステム——例えば大規模データベースサービスや継続実行される計算タスクなど——には、依然として従来のサーバーアーキテクチャの方が適しています。
ハマりどころと注意点
これまでの分析を踏まえて、業務を Serverless に移行するつもりなら、事前に考えておくべきポイントがいくつかあります。
1)関数はステートレスに書くこと。 インスタンスはいつ回収されてもおかしくないため、ローカルメモリやローカルディスクに書き込んだ状態は信頼できません。永続化が必要なデータは外部ストレージやキャッシュサービスに置くべきです。
2)実行時間の制限に注意すること。 FaaS プラットフォームには通常、1 回の実行に対するタイムアウト上限があります。長時間かかるタスクは複数の関数に分割して連結するか、別のコンピューティング形態への切り替えを検討しましょう。
3)コールドスタートがリクエストチェーンに与える影響を評価すること。 外部向けの同期 HTTP インターフェースはレイテンシに敏感で、コールドスタートの影響が最も直接的に出ます。一方、非同期タスクや定期タスクはほぼ影響を感じないため、こちらを優先的に移行するとよいでしょう。
4)クラウドサービスへの依存の深さをコントロールすること。 クラウドサービスにまったく依存しないのは現実的ではありませんが、OSS やメッセージキューといったサービスへの呼び出しをコード内で独立したアダプター層に集約しておけば、いざ移行するときの改修範囲をかなり小さくできます。
現実的なやり方としては、まず非コアの非同期タスク(定期クリーンアップや画像圧縮など)を 1〜2 個選んで移行して試し、課金・ログ・アラートの一連のフローが問題なく回ることを確認してから、利用範囲を広げるかどうかを判断するのがおすすめです。
まとめ
まとめると、Serverless は従来のアーキテクチャを完全に置き換えるものではなく、新しいコンピューティングモデルです。そのコアバリューは、開発者がインフラではなく、ビジネスそのものにより集中できるようにすることにあります。
「オンデマンド実行・自動スケーリング」をプラットフォームの機能として提供する代わりに、コールドスタート、実行時間の制限、そしてある程度のベンダーロックインを受け入れることになります。採用するかどうかは、アーキテクチャの新しさではなく、業務のトラフィック形態とレイテンシ要件によって決まります。
クラウドコンピューティングの発展に伴い、Serverless 機能を提供するプラットフォームはますます増えています。将来のシステムアーキテクチャは、次のような組み合わせへと徐々に進化していく可能性が高いでしょう:
Serverless + マイクロサービス + コンテナ化の組み合わせモデルです。
COMMENTS