【FaaS】サーバーレス開発のメリット・デメリット どんなアプリがサーバレスに向いている?

『サーバレス』という言葉をご存知ですか?
聞き慣れない言葉かもしれませんが、この「サーバレス」は現在成長している技術の一つです。

2022年02月12日にREPORTOCEANが発行した新しいレポートによると、-世界のサーバーレスアーキテクチャ市場は、予測期間2022年から2030年にかけて21.5%以上の健全な成長率で成長すると予測されています。

https://prtimes.jp/main/html/rd/p/000005259.000067400.html

もしシステムの開発・運用に携わる立場の人ならば、「サーバレス」を知っておいて損はありません。
この記事ではサーバレスのメリット・デメリット、向いているアプリ等についてご紹介します。

目次

サーバーレスとは何か。クラウドと何が違うの??

『サーバーレス』というと、まったくサーバを介せず処理を行うような印象を持つかもしれませんが、そうではありません。
『サーバーレス』という言葉を一般的に使う場合、その多くは『FaaS』のことを指します。
(違う使い方をされることもありますが、この記事では主にFaaSについて解説します)

『FaaS』とは『Function as a Serviceサービスとしての機能』の略です。
『通常のクラウドサーバ(IaaS)』が、好きにシステムを載せられる”場”を提供しているとすれば、
『FaaS』は、予めクラウド側が用意した”機能”を提供します。

上記図を見ていただくと分かる通り、
FaaSではOSはもちろん、新たなランタイムやアプリケーションのインストールを行なうことはできません。
すでにクラウド側へ用意されているアプリケーションを用いて、データのやり取りを行なう形になります。

なので『サーバレス』とは、「サーバがいらない」というよりは「サーバの管理がいらない」と捉えたほうが、イメージしやすいかもしれません。

実際のサービス名としては、
『IaaS』が「Amazon EC2」「Azure VM」「Google Cloud IaaS」
『Faas』は「AWS lambda」「Googl Cloud Functions」「IBM Cloud Functions」等が挙げられます。

サーバレスのメリット

先に説明した『サーバの管理がいらない』という他にも、サーバレスのメリットはいくつかあります。

利用した時間・回数だけの支払い

通常のクラウドサーバやVPSでは、システムが待機している時間も、稼働している時間と同じ分だけ料金を支払います。

一方で、サーバレスの場合、システムが稼働していない間は料金を支払う必要がありません。
稼働している間だけ、利用時間、もしくは利用した回数によって支払うことになります。
もし月に一度も利用しなければ、その月のコストは0円です。

それどころか、サービスによっては無料枠もふんだんに用意されています。
小規模なシステムならば、その無料分で賄えてしまうことも少なくないでしょう。

自動でスケーリングしてくれる

もしクラウドサーバでメモリ2GBのインスタンスを借りた場合、
何が起きようとも処理できるのはメモリ2GB分だけになります。
もちろんオートスケーリングを設定することもできますが、設定が複雑ですし、スケーリングが適用されるまでにはしばらく時間が掛かります。

その点、サーバレスのサービスはほとんどが自動でスケーリングを行ってくれます。
『どのぐらいアクセスがあるかわからない』『急に需要が増す可能性がある』というシステムの場合、サーバレスのほうが柔軟に対応できるでしょう。

サーバ構築不要!設定のみですぐに使える

どれだけ慣れた人でもサーバの構築には時間が掛かるものですが、
サーバレスのサービスには、必要な環境が最初から用意されています。

特に時短が求められるMVP等の開発では、なるだけサーバレスを使ったほうが良いでしょう。

セキュリティを提供ベンダー側に任せられる

クラウドサーバやVPSを借りた場合、セキュリティは頭痛の種です。考えなければならない範囲は広く、1つでも誤ればセキュリティホールが開くことになります。
もし「既存のシステムに脆弱性が見つかった場合」は、緊急で更新する必要がありますし、
その更新作業により障害が生じたりしたら悪夢ですね……。何も得にならない作業に追われることとなります。

一方で、サーバレスを用いる場合、セキュリティについて考える必要はほとんどありません。
脆弱性が見つかったとしても、対処は提供ベンダーに任せることができますし、万一攻撃を仕掛けられたとしても、提供ベンダーが高度な対処を行ってくれるでしょう。
この点も、大きなコスト削減になると思います。

デメリット

一方で、サーバレスにもデメリットはあります。
しっかり確認した上で、サーバレスを採用するかどうか決めましょう。

カスタマイズ範囲が狭い

サーバレスでは、アプリケーションをベンダーが用意するため、
独自に構築・カスタマイズすることができません。

もし何か複雑な処理を行いたい場合は、独自の処理を挟んだり、複数の「関数(Function)」を利用したり、といった手間が生じます。
場合によっては、サーバレスのメリットが失われてしまうかもしれません。

自分の行いたいことが、サーバレスに適しているのかどうか、見極めてから開発に入りましょう。

システムの全体像が把握しにくい

先程述べた通り、サーバレスで複雑なことを行なう場合は、複数の関数を用いることがあります。
これ自体は普通に行われているものですが、
各関数は独立しているため、全体像を把握するのが難しくなることも少なくありません。

そういった状況の場合「モニタリングに1手間かかる」というデメリットもありますし、
複数人で作業する場合等、しっかりと連携を確認しておかないと大事故が起きてしまいます。

初回起動のタイムラグ

常時待機状態のサーバと違い、サーバレスでは休止状態からプログラムを実行するまでに、若干のタイムラグが生じます。

実行頻度の高いアプリの場合は、環境が維持し続けられるため、ほとんどラグは発生しませんが(ウォームスタート)、
実行頻度が低いアプリの場合は、再度環境をアクティブにするところから始まるので、ラグが生じるのです。(コールドスタート)

一応各ベンダーで対処法等が用意されており、モノによっては気にしなくていい程度のラグで済むこともありますが、
javaやコンパイルが関係するファンクションの場合は、この点も考慮に入れる必要があります。

即時の応答が必須の場合などは、サーバレスを避けたほうが無難でしょう。

実行時間や同時実行数、サイズの制約がある

どのサーバレスサービスでも、実行時間・同時実行数・処理できるサイズには制限がついています。
例えばAWS Lambdaではタイムアウトが最長15分に制限されています。
これは「知らない間にすごい請求額になっていた」といった事態を避けるためでもありますし、
そもそも「大きなリソースが必要な用途」向けのサービスない、といった側面もあります。

上限は各サービス・ファンクションで異なるため、予め調べた上で、適切な処理を投げる必要があります。

他サービスに切り替えられない【ベンダーロックイン】

例えばあなたがAWS Lambdaを使って、とある社内用のシステムを作ったとします。
システム自体はとても評判がよく、気を良くしたあなたは2年掛けて色々と機能を追加しました。

しかし3年が経った頃、他の部署で使っているシステムと、あなたの作ったシステムを統合するよう指示がでます。
聞いたところ、他の部署で使っているシステムはAzure上にあるようです。
あなたはどのぐらいの作業時間を上司に要求しますか?

……もちろんどんなシステムかにもよるのですが、相当な時間と手間とコストがかかるでしょう。
単純なサーバ移動ではありません。
サーバレスで動いているアプリケーションは、あなたが作ったものではないので、他のサービスに移動することができません。
Azure上にも似たようなものがあるかもしれませんが、全く仕様の違う2つのサービス間で移行を行なうのは、大変な苦労を強いられるでしょう。
いっそ1から作り直してしまったほうが早いかもしれません。

このような「1つのサービスに依存し、他社サービスに移行できない」状況を「ベンダーロックイン」といいます

サーバレス以外でもベンダーロックインが起きることはありますが、
そもそもアプリケーションを保持していないサーバレスは、ベンダーロックインが起こりやすい環境です。

……正直、対応策はこれといってなく、覚悟の上で使うしかないというのが実情ですが、
以下の点を予め考慮しておくことで、ベンダーロックインのデメリットを軽減することはできるかもしれません。

  • 連携する可能性があるシステムとは、共通したベンダーを用いる。
  • ドキュメントの整備をしっかりと行なう。
  • ベンダーロックインのリスクを計算した上で、サーバレスにするかどうか判断する。

「サーバレス」は、どんなアプリに向いている?

以上を踏まえた上で、以下のようなアプリには「サーバレス」が向いています。

超ミニマムな機能のシステム

単純なでミニマムな作業なら、サーバレスのデメリットは全て無視できます。
一番サーバレスに向いているアプリです。

ベンダーロックインしても問題ないシンプルなコーディングでシンプルな機能のアプリ

シンプルなコーディング・シンプルな機能であれば、他のベンダーが運営するクラウドに移したいときでも、すぐに移行ができるでしょう。
そんなアプリのために、クラウドサーバを管理するのも手間なので、これも非常にサーバレス向きです。

初回起動のラグに時間が掛かってしまっても問題ないサービス

先程書いた通り、低レイテンシを求められるアプリはサーバレスに不向きです。
逆に言えば、多少ラグが発生しても良い作業では、サーバレスが本領を発揮します。

MVP開発などサンプルとして利用するアプリ

”需要の検証”等のため、とにかく機能が動けば良い『MVP開発』は、サーバレスと非常に相性が良いと言えます。
サーバレスをふんだんに用いて、とにかくサービスを作ってしまいましょう。
需要が確認できたら、その時に初めてサーバのことを考えればいいのです。

既存のシステムでサーバレスに移行した方がいい物

また、すでに利用しているシステムの中でも、サーバレスに移行できるものは、移行してしまったほうが良いかもしれません。

サーバレスに移行した方がいい物

  • 定期バッチ(バックアップ、CSV出力)
  • Slack通知やメール送信
  • WebサイトのデータのAPI化

知っておいて損はないサーバレス

以上、サーバレスの損得や、向いているシステムについてご紹介しました。サーバレスは決して万能ではありませんが、有効に使うことで飛躍的に効率を上げることができる素晴らしい技術です。
システムの開発や運用を行なう方であれば、知っておいて損はないでしょう。

ただし、「サーバレス」だからこそ起きる失敗というものもあります。
次回、サーバレスの失敗例や対応策についてご紹介します。

お問合せ&各種リンク

presented by 

よかったらシェアしてね!
  • URLをコピーしました!
目次