昨今注目される新たなクラウドアーキテクチャ「FaaS」とは
昨今ではSaaSやPaaS、IaaSといったクラウドベースのサービス運用・利用手法が普及しているが、最近登場した新たな動きとして「Function as a Service」（FaaS）がある。FaaSはその名前のとおり、機能（Function）の実行環境がサービスとして提供されるのが特徴だ。今回はこのFaaSというアーキテクチャを紹介する。
「FaaS」は仮想化を突き詰めていった最終形？
2000年代中ごろから現在までの十数年間では、コンピュータシステムの運用方法が大きく変化した。2000年代前半にはXenやKVMといったLinux向けの仮想化技術の普及により、かつてはメインフレームや大型コンピュータシステムでのみ使われていた「1台のハードウェアを仮想化によって分割して複数の利用者で共有して利用する」という運用が、比較的安価なハードウェアでも実現できるようになった。
そして2000年代後半には、APIやWebブラウザから操作できる管理コンソール経由でシステム運用のためのインフラストラクチャを用意できる「Infrastructure as a Service（IaaS）」と呼ばれる形式のクラウド型サービスや、アプリケーション実行環境を提供する「Platform as a Service（PaaS）」と呼ばれる形式のクラウド型サービスが登場、現在でもこれらが広く使われるようになっている。
こういったクラウド型のホスティングサービスを利用するメリットとしては、まずアプリケーションとは直接関係ない部分の管理をサービス運営側に任せられるという点が挙げられる。図1は、サーバーの置き場所だけを提供するハウジング（コロケーション）サービスとIaaS、PaaSそれぞれでサービスの開発/運用者が管理しなければならない領域を比較したものだ。
IaaS型のクラウドサービスではハードウェアの設置や保守管理は基本的にサービスの運営者側が行う。また、ハードウェア故障などが発生した場合も、ユーザーは対処する必要はない。サービスによっては簡単な操作でCPUやメモリといったリソースの割当量を変更できるものもある。
いっぽう、PaaSではハードウェアだけでなくOSの管理についてもサービス運営者側に任せることができる。アプリケーション開発者はアプリケーションをビルドして所定の方法でクラウドにアップロードするだけでサービスの運営が可能になり、OSのセキュリティアップデートや設定などを気にする必要はない。
IaaSやPaaSのもう1つの利点は、運用コストを削減できることだ。多くのクラウド型サービスでは時間や分単位での料金請求が行われており、さらに使用状況に合わせて使用するリソースをほぼリアルタイムで増減できる。これによって「実際に使った分だけ」の料金でサービスを運用できるようになる。もちろん、自前でサーバーを運用したり、レンタルサーバーを利用したほうが単純な支払いコストでは安くなるケースもあるが、IaaSやPaaSを利用することでハードウェアやOS、ミドルウェアの管理が不要になるため、そのコストを入れるとトータルではクラウドサービスを利用するほうがコスト的に優位になることもある。
さて、こういったクラウドインフラストラクチャを使ったサービス運用が普及するとともに、サービスの構築アーキテクチャとして「マイクロサービス（Microservices）」というものが使われだした（図2）。
従来のアーキテクチャでも、サービスを提供するためのプログラムを複数のコンポーネントに分割することは一般的だったが、マイクロサービスアーキテクチャはコンポーネント分割をさらに細かく行うことで、保守コストやプログラムの複雑性の削減を図るというものだ。
マイクロサービスアーキテクチャでは、必要最小限の機能のみを提供するコンポーネント（マイクロサービス）を多数組み合わせて相互通信させることでサービス全体を構成する。これによって各コンポーネントの複雑性が減少し、開発効率の向上が期待できる。
マイクロサービスアーキテクチャは、比較的低コストで多数の仮想マシンやアプリケーション実行環境を用意できるIaaSやPaaSに適しており、そのためクラウドベースで運用されるアプリケーションの構築で広く使われるようになっている。
ただ、こういったマイクロサービスアーキテクチャによってサービスを構築する場合、機能を分割していくとどうしても利用頻度の少ない機能や、処理内容が薄い機能というものも出てきてしまう。さらに、実行するプログラムやマシンの総数も増加してしまう。そのため、機能や負荷の少ないマイクロサービスをどのように実装・管理するかが、マイクロサービスアーキテクチャでサービスを運用する際の課題となっていた。
FaaSとは
今回紹介するFaaSは、サービスよりもさらに粒度の細かい「Function」（日本語に訳すと「関数」や「機能」）という単位で処理を実行させるアーキテクチャだ。実際にFaaSを提供するサービスプロバイダによって細かい仕様は異なるが、FaaSでは開発者はハードウェアやOSの管理を行う必要は無く、その面ではPaaSと似ている。いっぽうでFaaSがPaaSと異なるのは、FaaSはリクエストの送受信についてもサービスプロバイダ側が管理するという点だ（図3）。
PaaSでは、処理すべきリクエストを受信するとそのリクエストに関するほとんどの情報がそのままプログラムに渡される。一方FaaSではリクエストを受信すると、それをパースした上でリクエストボディなどの必要な情報のみがプログラムに渡される。また、PaaSではプログラム内で適切なメソッドを呼び出してレスポンスを送信する必要があるが、FaaSでは実行したプログラムの戻り値がレスポンスとして自動的に送信される。
さらに、PaaSでは、プログラムは常時稼働してリクエストの待受を行うのに対し、FaaSではリクエストを受信したタイミングでプログラムが起動され、処理が完了するとその時点で終了するという点も異なる。そのため、FaaSは常時起動してなんらかの処理を行うといったプログラムには適していない。
ちなみに、FaaSではスケーリングに関する設定などもほとんどがサービスプロバイダに「お任せ」となる。その代わり、処理のトリガーとなるリクエストやイベントが発生していないときはプログラムが実行されないため料金が発生しない。料金はリクエスト数やコードの実行時間単位で計算されるのが一般的だ。
FaaSの先駆けとされているのが、「hook.io」というサービスだ。こちらは、作成したマイクロサービスを実行するための商用ホスティングサービスで、2014年にスタートした。ちなみにhook.ioの創業者であるMarak Squires氏は以前に同名のNode.js向けメッセージングフレームワークを開発していたが、それと現在のhook.ioは直接の関わりはないようだ。
hook.ioはさまざまな言語で実装されたマイクロサービスを実行できるプラットフォームで、特定のHTTPリクエストを受信するとあらかじめアップロードしておいたプログラムが実行され、その結果がHTTPレスポンスとして送信される、というサービスとなっている。
また、2014年11月にはAmazon Web Services（AWS）の1つとして「AWS Lambda」がスタートした。AWS LambdaはAWSと密に統合したサービスとなっており、任意のHTTPリクエストだけでなく、ほかのAWSサービスで発生したイベントをトリガーとして登録しておいた処理を実行できるようになっている。
そのほか、Googleの「Google Cloud Functions」、Microsoftの「Microsoft Azure Functions」など、近年同種のサービスを提供しているクラウドサービスプロバイダは増加している。
FaaSとServerless Computing
FaaSとともによく使われる言葉として、「サーバーレスコンピューティング（Serverless computing）」という言葉がある。サーバーレスコンピューティングというと「サーバーを使わないコンピューティング」のようにも聞こえてしまうが、この「サーバーレス」は、「開発者はサーバーのことを一切考慮しなくて良い」といったような意味で使われている。FaaSでは開発者は実行するプログラムにのみ注力すれば良いため、サーバーレスコンピューティングの実現形態の1つだと言うことができる。
一方で、認証機能やデータベースといった機能をAPIのような形で提供する「Backend as a Service（BaaS）」と呼ばれる形態のクラウドサービスも存在する（図4）。このようなサービスを利用することで、開発者はサーバー管理を行うことなく独自のサービスを開発・運用できるようになる。そのため、これらもサーバーレスコンピューティングの実現形態の1つと言われている。ただ、最近ではこういったサービスはやや下火になりつつあり、サーバーレスコンピューティングという言葉がFaaSと同義で使われることも多いようだ。
FaaSの制約と適した処理内容
さて、こういった特徴のあるFaaSだが、当然ながらIaaSやPaaSと比較すると長所と短所の両方がある。そのため、マイクロサービスすべてがFaaSに置き換えられるというわけではない（表1）。
| 要素 | IaaS | PaaS | FaaS |
|---|---|---|---|
| 開発者が運用・管理すべき対象 | OS環境およびネットワーク環境、サービスを提供するためのソフトウェア | サービスを提供するためのソフトウェア | サービスを提供するためのソフトウェア |
| 利用できる言語・ライブラリ・フレームワーク | 基本的に制限無し | 一部制限あり | 制限あり |
| 課金対象 | リソースの割り当て時間 | リソースの割り当て時間＋プログラムの実行時間 | リクエスト数＋プログラムの実行時間 |
| スケーリング | あらかじめ開発者による設定が必要 | あらかじめ開発者による設定が必要 | 自動（設定不要） |
| インスタンスの作成/削除 | 手動 | 手動（スケーリング時は自動） | 自動 |
| プラットフォームへの依存度 | 低 | 中 | 高 |
FaaSがほかのプラットフォームと比較して大きく異なるのは、プログラムの起動/終了タイミングを開発者がコントロールできない点だ。そのため、初期化・前処理・後処理などに時間のかかるプログラムは大きくパフォーマンスが落ちる可能性がある。さらに、利用できるプログラミング言語やフレームワークやライブラリに制約があることも多い。実行できるプログラムの内容や利用できるリソースにも制限がある。そのため大規模なプログラムはFaaSでは運用しにくい。さらにサービスプロバイダによって仕様が大きく異なるため、そのプロバイダへの依存度が高くなるという問題もある。
コストの面で見ると、FaaSではコードを実行していないときのコストが0になることが多い。そのため割安だと言われているが、逆に常にコードが実行されているような状況ではPaaSやIaaSよりも割高になる可能性もある。
さらに、FaaSでは大規模な（複雑な）プログラムを実行しにくいため、結果としてマイクロサービスの総数は増加する。その結果、マイクロサービス同士の協調動作やマイクロサービス自体の管理に必要なコストが増加する可能性もある。
FaaSの開発スタイル
FaaSを利用する場合、本番運用環境はFaaSプロバイダが提供するため、コードを実際に実行させるためにはFaaSプロバイダのサーバーにアップロードする必要がある。こういった作業は手間がかかるため、多くのFaaSでは開発・デバッグ用に手元の環境でFaaS向けのプログラムを実行するためのソフトウェアを公開している。たとえばAWS LambdaであればAWS Serverless Application Model (SAM)、Google Cloud FunctionsではGoogle Cloud Functions Emulatorなどがこれに該当する。ただし、これらはあくまで運用環境に近い環境を提供するというものであり、実際の本番運用環境とは一部仕様が異なっているものもある点には注意が必要だ。
FaaSの相互運用性には注意が必要
FaaSを利用するに当たってもっとも注意したいのが、現時点ではサービス毎に仕様が大きく異なる点だ。利用できるプログラミング言語も異なるほか、処理を開始するためのトリガーとして利用できるイベントやデプロイ方法、料金体系も異なる。さらに、当然ながらAWS LambdaはAWSのほかのサービスと連携しやすいようになっており、また同様にGoogle Cloud FunctionはGoogle Cloud Platformのサービスと連携しやすいようになっている。そのため、一度開発したシステムを別のFaaSサービスで動作させるように変更するためにはそれなりに工数が必要となる。
こういった背景から、オープンなFaaS実装を作ろうという動きも生まれた。その一つが、オープンソースで開発されている「OpenFaaS」だ。OpenFaaSはDockerをベースに、FaaSの仕組みをうまく取り入れて自前のインフラストラクチャで手軽に使えるようになっている。本記事後編では、このOpenFaaSについて紹介する。