いまさら聞けないサーバレス入門【前編】

サーバレスが抱える「パフォーマンスを制御できない」問題

サーバレスには多くのメリットがある。だが幾つか認識しておくべき問題もある。パフォーマンスを制御できない（実行速度を予測できない）とはどういうことなのか。解決する方法はあるのか。

公開 2021年02月08日 08時00分

更新 2022年01月18日 15時59分

著者

Daniel Robinson

[Computer Weekly]

印刷する連載新着通知を受け取る Googleで優先するソースとして追加

　サーバレスはインフラを気にすることなく単純にコードを実行でき、使ったリソースのみに課金される。サーバレスにはメリットが多いが、あらゆる技術には長所と短所がある。サーバレスにも開発者が認識して回避すべき問題点がある。

サーバレスとは

　サーバレスだからといってサーバが不要になるわけではない。そのため誤解を招きやすい名前だと言える。サーバレスは、コードを実行するサーバのプロビジョニングや管理の必要性をなくすことを意味する。それらは全てプラットフォームが処理する。

　こう聞くと、「Red Hat OpenShift」や「Google App Engine」といったPaaSのように思えるかもしれない。PaaSはアプリケーションのスケーリング方法など、デプロイ環境を開発者が細かく管理できる。これに対し、サーバレスはスケーリングが自動化される場合が多い。そのためサーバレスという用語は多種多様なサービスに当てはまる可能性がある。

　サーバレスが特に注目を集めたのは、Amazon Web Services（AWS）が2014年に「AWS Lambda」を発表したときだ。AWS Lambdaにより、何らかのイベントやトリガーに応答して実行されるコードを作成できる。例えば「Amazon S3」のバケットに新しいオブジェクトがアップロードされたときに、必要な機能（関数）を実行することが可能だ。このため、AWS LambdaはFaaS（Function as a Service）と呼ばれることも多い。

　AWS Lambdaなどのサービスは、ユーザーコードのホストにコンテナを使うのが一般的だ。コンテナの生成から関数実行後のコンテナの破棄までの全てはプラットフォームが処理する。

　必要に応じて自動的にスケーリングされ、インフラをユーザーが管理する必要がないという基準を満たすサービスはサーバレスと見なされる可能性がある。これには大手クラウドが提供するAPI駆動型の多くのサービスも含まれる。こうしたサービスは、ユーザーが開発したサーバレス要素とクラウドプラットフォームが提供する関数やサービスと結び付けることでアプリケーションを構築できる。

　この種のアーキテクチャはマイクロサービスの一例でもある。このアーキテクチャでは、アプリケーションが相互に通信する疎結合型サービスの集合体として実装される。

　この方法でアプリケーションを実装するメリットは、主要パーツを必要に応じて個別にスケールアップできる点にある。各パーツは、相互に独立してパッチの適用や更新を行うことも可能だ。これに対してモノリシックなアプリケーションは全体をひとまとめにスケールアップしなければならない。

サーバレスの長所と短所の比較

　サーバレスの長所はかなり分かりやすい。リソースのプロビジョニングを気にする必要がなくなり、生産性が向上する。自身のコードが実行したリソースにしか課金されず、スケーリングはプラットフォームが自動的に処理する。

　IDCのレポートによると、サーバレスは「インフラとアプリケーションのライフサイクルに必要なタスクが完全に抽象化され、ビジネスの成果を直接向上させる作業に開発者が専念できるシンプルなプログラミングモデル」を提供するという。IDCは、サーバレスを使うことで生産性が向上してコストが削減されることから、5年間の平均投資収益率は409％に達すると予測する。

　だがどのようなアーキテクチャにも欠点はある。サーバレスを検討している開発者やIT部門は行動を起こす前にそうした欠点を認識しておく必要がある。

　明らかな欠点は、恐らく制御が及ばなくなることだ。ソフトウェアに対する従来のアプローチでは、使用するハードウェアからアプリケーションやサービスをサポートするソフトウェアスタックまで、アプリケーション環境の一部または全てをユーザーが制御するのが普通だった。

　制御が及ばなくなるという問題の一つは、アプリケーションのパフォーマンスをほとんどまたは全く制御できないことだ。この現象は、調整できるパラメーターをほとんど持たないサーバレス関数ほどシンプルに現れる可能性がある。パフォーマンスを制御できないという問題は一部のサーバレス開発者から報告されている。サーバが異なれば仕様が異なるため、コードのデプロイ先によって実行時間が大きく異なる恐れがあるという。

　一部のサーバレスプラットフォームでよく知られている問題に、「コールドスタート」というものがある。特定の関数を実行するコンテナのインスタンスが稼働していない場合、それを新たに立ち上げるのに時間がかかるという問題だ。通常、関数が再び必要になる場合に備えてコンテナは一定時間「稼働状態」が維持される。だが、呼び出されなければ破棄される。これを回避するために、時間制約の厳しい関数を定期的に呼び出して稼働状態を維持する定期イベント関数をコーディングする開発者もいる。

後編では、サーバレスが抱えるさらなる課題と展望を紹介する。

印刷する

Computer Weekly日本語版

連載新着通知を受け取る

この連載の記事をもっと見る

この記事の著者

Daniel Robinson

サーバレスが抱える「パフォーマンスを制御できない」問題

サーバレスとは

関連記事

サーバレスの長所と短所の比較

Computer Weekly日本語版

この記事の著者

関連記事

新着ホワイトペーパー PR

瞬時にM365が乗っ取られる――全社員に周知すべき“新フィッシング”の教訓

サーバレスが抱える「パフォーマンスを制御できない」問題

サーバレスとは

関連記事

サーバレスの長所と短所の比較

Computer Weekly日本語版

この記事の著者

関連記事

サーバレスコンピューティングを使ってはいけない4つのパターン

サーバレスを導入するなら覚悟すべき4つの課題

サーバレスに飛び付く前にやるべきたった1つの作業

いまさら聞けない「サーバレス」「マイクロサービス」は何が違うのか

サーバレス対マイクロサービス──現時点で知っておくべきこと

新着ホワイトペーパー PR

瞬時にM365が乗っ取られる――全社員に周知すべき“新フィッシング”の教訓