「サーバーレスアーキテクチャ」というシステム構築の手法が、システム開発の現場で取り入れられ始めている。文字通りサーバーを不要とするシステム構成であり、その利点もある一方、システム設計が複雑になるという見落とされがちな欠点がある。
「サーバーがあることによる悩み」から開発者を開放する、サーバーレスアーキテクチャ
典型的なITシステムの開発は、サーバー、OS、ミドルウェアを用意するところから始まる。これらを適切に設定、保守・運用するためには、少なくない工数と費用が発生する。開発者はシステムの中でも特にアプリケーションの実装にできるだけ注力したいところだが、「サーバーがあることによる悩み」は、開発者にとって常に悩みの種であった。
この悩みから開発者を開放しうる実装方法として、「サーバーレスアーキテクチャ」という考え方がある[1]。
サーバーレスアーキテクチャとは、読んで字のごとく「サーバーのないシステム構成」を指す。開発者がサーバーやOS、ミドルウェアの存在を意識せずに、プログラム、ストレージ、DB、ネットワーク、セキュリティ対策等々、システム基盤に必要なすべての機能・非機能要件を構築するシステム構成方法である。
クラウドサービス上で構築されるサーバーレスアーキテクチャ
サーバーレスアーキテクチャは、Amazon Web Services（AWS）、Microsoft Azure、Google Cloud Platform（GCP）といったクラウドサービスベンダーが提供する各サービスを組み合わせて構築することが一般的である。
サーバーレスアーキテクチャのキモとなるのが、FaaS（Function as a Service）と呼ばれる形式のサービスである。端的にいえば、FaaSとはプログラムの実行環境を提供するサービスである。PythonやJava等のソースコードをアップロードし、そこで定義した関数に対して外部からリクエストを渡すと、その処理結果をJSON等の形式で得ることができる。AWSでいえばLambda、AzureでいえばAzure Functions、GCPでいえばCloud Functions等がFaaSに相当する。
FaaSが担うプログラムの実行以外のシステム基盤（ストレージ、DB、セキュリティ等）の機能・非機能要件は、その他のSaaS型サービスを組み合わせることで構築できる。
このようにクラウドサービスを組み合わせるサーバーレスアーキテクチャには、迅速にシステムが構築できること、スケーラビリティが高いことといった利点がある。その一方で、システム設計が複雑になるという欠点もある。
システム設計が複雑になる欠点1：クラウドサービス固有の設計思想に従う難しさ
サーバーレスアーキテクチャをクラウドサービスを組み合わせて構築すると、そのクラウドサービス固有の設定値やファイルの配置方法に開発者は従わなければならない。AWS、Azure、GCP等の各種クラウドサービスベンダーから等価なサービスが提供されているものの、それぞれ仕様や設定方法が異なるため、開発者は個別対応を余儀なくされる。
このように考えると、旧来のサーバーを用いたアーキテクチャの方が、新しい学習コストが少なく、ノウハウも豊富に存在していることから、開発者の負荷が少ない場合もある。
システム設計が複雑になる欠点2：バージョン管理と依存関係解決の難しさ
現代のシステム開発では、ソースコードや設定値を記載したドキュメントを、GitやSubversionといったバージョン管理システムで管理することが通常である。
一方、FaaSに限ってはソースコードを配置することで実装されるものの、SaaSはソースコードないしドキュメントの存在を前提としないものがほとんどである。ブラウザまたはコマンドライン[2]で設定値や必要なリソースを適宜配置していくことで実装を行うからだ。つまり、SaaS型サービスはバージョン管理という考え方とは馴染みにくい。
さらに、バージョン管理に馴染みにくいため、各サービス間の依存関係の解決も複雑になりがちだ。あるサービスのある瞬間に設定した値をドキュメントとして保存しておくことが難しいため、システムとして動作確認が取れていたスナップショットを記述することが難しい[3]。
効率的な開発手法＝ノウハウ・ツールの活用の重要性
さて、冒頭で述べたように、確かにサーバーレスアーキテクチャは、「サーバーがあることによる悩み」から開発者を開放する。しかし、上述したような「サーバーレスアーキテクチャであることによる悩み」が、今度は頭をもたげてくることになる。
とはいえ、そのような問題を解決するためのノウハウ・ツールも徐々に現れ始めている。
例えば「Serverless Framework」というツールである。各クラウドサービスに依存する差異の吸収をある程度担ってくれるため、サービス固有の設計思想に従う負担が小さくなる。さらに、サービスの設定値をドキュメントとして管理するので、バージョン管理にも親和性が高く、依存関係解決も行いやすい[4]。
新しいアーキテクチャを使う場合、同時に効率的な開発手法を学ぶ必要があることは、サーバーがあろうと無かろうと同じことであろう。
脚注：
- [1] 「クラウドコンピューティング」とも呼ばれる。海外ではこちらの呼び方のほうが一般的なようである。
- [2] AWS、Azure、GCPともに、ブラウザ上での管理画面に加えてCLIツールが提供されている。
- [3] もちろん、コマンドラインで実行するコマンドもソースコードの一種であると考えれば、バージョン管理は可能である。しかし、それは「状態のスナップショット」というよりは「その状態を作り出すための命令集」に過ぎず、システムを記述するドキュメントとしての活用は難しい。
- [4] Serverless Frameworkはいうなれば、各クラウドサービスベンダーを更に一段抽象化・一般化したラッパーツールであると考えることもできる。