サーバーレスは、クラウドの世界で急速に注目を集めています。少なくとも3組織に1組織（33%）が、過去1年以内にサーバーレスアプリを導入しています。（出典：Digital Ocean 2018年第2四半期開発者調査）また、CNCF 2018年調査の回答者のうち、38%が現在サーバーレスを利用していると回答しました。さらに26%が、今後12か月以内にこのテクノロジーを利用する予定です。
この新興のクラウドオプションは急速に普及しているだけでなく、誤解されることも多く、コストを削減し、価値実現までの時間を短縮し、さらにはベッドまで朝食を運んでくれるかのような、ほとんど超自然的ともいえる力があると考えられています。
さらに混乱を招いているのが、Function as a Service（FaaS）とサーバーレスの混同です。この2つは同じものではありません。そのため、一般的な企業がこの注目の新技術をどのように活用できるかについても、誤解が生じています。
そこで今回は、過去6か月間にお客さまやカンファレンス参加者から繰り返し耳にした、よくある3つの誤解を解き明かします。このテクノロジーを検討する価値があるかどうかを判断するには、まずそれが何であり、何ではないのかを理解する必要があるからです。
まずは、サーバーレスとFaaSの違いを明確にしましょう。
誤解：サーバーレス === FaaS
サーバーレスは、システムであり、プラットフォームであり、フレームワークです。ジャストインタイムで伸縮自在な実行環境と表現するのが最も適切です。サーバーレスは、何らかの分離された環境で何かをオンデマンドで実行することにより、運用上のオーバーヘッドや煩雑さの解消を目指します。この分離環境には通常コンテナが使用されますが、仮想マシンやWebAssemblyを使用するサービスもあります。簡潔にするため、ここではこの3つを広く「コンテナ」と呼びます。
サーバーレスはイベント駆動型です。つまり、APIリクエストの到着や時刻が14:07になったことなど、何らかのトリガーによってプロビジョニングと処理が開始されます。自動生成されたイベントの場合もあれば、Webアプリのフォーム上のボタンを押すといった対話型イベントの場合もあります。サーバーレスモデルでは、イベントによって、「コンテナ」内に存在する何らかのものの実行が開始されます。
NETOPS向け注記：F5 iRuleに詳しい方であれば、Serverlessイベントを「HTTP_REQUEST」や「HTTP_RESPONSE」などのiRuleイベントになぞらえて理解できます。仕組みはほぼ同じで、イベントが発生するとコードが実行されます。残念ながら、ほとんどのServerlessフレームワークはTCLをサポートしていませんが、多くの場合、node.jsとPythonをサポートしています。
「コンテナ」は多くの場合、リクエスト時にリポジトリから読み込まれる（コールドスタート）か、すでに待機している（ウォームスタート）ことがあります。その「コンテナ」内にあるものが実行され、実行のトリガーとなったシステムにレスポンスを返します。
サーバーレスのビジネスモデルは通常、消費したリソースに対してのみ料金を支払う仕組みです。課金対象となるのは、「コンテナ」の実行中に消費されたリソースです。運用モデルでは、環境の運用に関するあらゆる作業を考慮する必要がなくなり、「何か」の構築に専念できます。
これがサーバーレスです。Function as a Serviceは、サーバーレスの具体的な利用形態の1つであり、「何か」を「関数」として定義します。
FaaSにより、マイクロサービスから始まったアプリケーションの分解を、その究極の形である関数にまで進めることができます。
次の誤解を解くには、ServerlessとFunction as a Serviceには違いがあることを理解しておくことが重要です。
誤解：リファクタリングが必要
FaaSとServerlessが混同されているため、市場では、Serverlessを活用するにはアプリケーションを構成する個々の関数へとリファクタリングする必要がある、という誤解が広まっています。
Serverlessを利用するために、アプリケーションをリファクタリングしたり、新しいアプリを機能単位で設計したりする必要はありません。Serverlessでは、あらゆる種類のアプリケーション、プロセス、デーモン、関数を含む「コンテナ」も同様に実行できます。「コンテナ」としてパッケージ化され、呼び出し可能であれば、Serverless環境で実行できます。
Serverlessを活用して既存のアプリケーションアーキテクチャを拡張（モダナイズ）した導入事例も成功しています。登録や注文処理など、クリティカルパスに含まれないプロセスのバッチ処理や帯域外処理は、従来のアプリケーションを全面的にリファクタリングしなくても、Serverlessモデルで実装できる場合があります。このような用途ですでに外部APIベースの連携を利用しているアプリケーションには、Serverlessを比較的容易に適用できます。既存のクライアントサーバーベースのアプリケーションでServerlessを活用するには、ほぼ確実に何らかの変更が必要ですが、全面的なリファクタリングほど大がかりな作業ではありません。
散発的または予測不能に発生する特定のイベントに基づき、たまにしか実行されないプロセスも、Serverlessに適しています。「コンテナ」を常時稼働させておくよりも、必要に応じて起動して処理を実行する方が、はるかにコスト効率に優れています。これは、パブリック環境とオンプレミス環境のどちらのServerlessにも当てはまります。
ここで、場所に焦点を当てた3つ目の誤解を取り上げます。
誤解：サーバーレスはオンプレミスでは利用できない
この主張は、各地のIT関係者や専門家から耳にしてきました。しかし、これは「クラウド」をオンプレミスで運用できないという考えと同様、明らかに誤りです。オンプレミスでの運用は間違いなく可能であり、Developer Economics State of the Developer Nationによると、実際にかなりの割合の組織が運用しています。
規模が大きく利用頻度の高いアプリケーションも、非常に効率的なスケーリングのメリットを得られます。高負荷がかかっている特定の部分に必要な追加リソースの料金だけを支払えばよく、該当部分の特定と最適化も容易になります。大規模アプリケーションにとってのこの利点が、現在サーバーレスコンピューティングを導入している組織の17%が自社のデータセンターでソリューションを運用している主な理由の1つと考えられます。
オンプレミスでのサーバーレス実装によるコスト効率の向上は、スケーラビリティだけにとどまりません。同じリソースを再利用し、利用頻度が低い複数のアプリケーション間で共有できることも、無視できないメリットです。また、サーバーレスの中核であるイベント駆動型の特性を活用することで、アプリケーションや運用機能に付加価値機能を追加できます。サーバーレスのメリットは、開発者の日常業務における運用上の負担を軽減するだけではありません。この点を理解せずに、オンプレミスでの利用を安易に退けるべきではありません。負担の軽減は確かに大きな利点ですが、それだけがメリットではなく、組織がオンプレミスのサーバーレスを試している唯一の理由でもありません。
つまり、実際にはServerlessはオンプレミスに実装可能であり、すでに実装されています。前述のCNCF調査では、最も人気のある「インストール可能な」Serverlessプラットフォームを詳しく取り上げています。
- Kubeless（2%から42%に増加）
- Apache OpenWhisk（12%から25%に増加）
- OpenFaas（10%から20%に増加）
ほかにもあり、このテクノロジーの普及が加速するにつれて、さらに増えていくことは間違いありません。
ServerlessとFunction as a Serviceは、組織が新しいクラウドネイティブアプリケーションとモダナイゼーションの両方での活用に向けて、このテクノロジーを試行し、検証する中、驚異的な勢いで導入が進んでいます。よくある誤解を見極めて排除することは、このテクノロジーが組織のアプリケーションに適しているかどうかを判断するうえで重要な第一歩です。
著者について
Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。
Lori Mac Vittieのその他のブログ記事関連するブログ記事
SOAS 2025：足並みの乱れが凡庸さを招く
AI導入における方針の不一致は、非効率を招きます。セキュリティ、自動化、導入の各戦略を整合させ、AIの可能性を最大限に引き出す方法をご紹介します。
WebAssemblyが重要な理由
WebAssembly（Wasm）は、あらゆるプラットフォームで高性能なアプリケーションを実現する、ポータブルで高速かつセキュアなバイナリ命令セットです。
インフラストラクチャは依然として格好の攻撃経路
クラウドコンピューティングでは、APIやドラッグ＆ドロップ式の設定ツールを活用し、ネットワークやインフラストラクチャを敬遠する人がそれらを直接扱わずに済むようにすることで、インフラストラクチャへの対応を不要にすることが長年追求されてきました。しかし、インフラストラクチャを無視することも、攻撃の主要な標的であるという事実を見過ごすこともできません。
堅牢なデータアーキテクチャがもたらす戦略的メリット
適切に構築されたデータアーキテクチャがもたらす効果は、業務プロセスの改善にとどまりません。戦略的な業務効率の向上、より深いビジネスインサイトの獲得、隣接するビジネス機会への展開にもつながり、これらすべてをより俊敏に実行できるようになります。
デジタルワークフローにおける不正検知には、データだけでは不十分
2019年には、業界全体でクレジットカード詐欺の試みが約25万件確認されました。これは約2分に1件の割合です。今日、不正を検知するには、デジタルワークフロー上のできるだけ多くのポイントから収集したデータを相互に関連付け、手作業によるデータ処理をはるかに上回る速度で分析する能力が求められます。