クラウドをフル活用する“サーバレス”アーキテクチャとは

　“クラウドファースト”という考え方が当たり前の時代になりつつあります。その一方で、セキュリティへの不安、既存システムとの互換性の問題から本格的なクラウドの活用に踏み込めない企業も多いのではないでしょうか。

　本連載では、こうした状況を踏まえ、企業がクラウドを利用してシステムを変革する方法を取り上げていきます。第1回の今回は、2015年になってから少しずつ耳にするようになってきた「サーバレスアーキテクチャ」について解説します。

サーバレスアーキテクチャとは？

　クラウドが普及していくとともに、ウェブアプリケーションサーバにもサーバレスアーキテクチャという新しいタイプのシステム構成が生まれてきています。

　サーバレスアーキテクチャの特徴は、これまで“フロントエンドサービス”と位置づけられていたウェブアプリケーションサーバのような構成要素が取り除かれ、クライアントとバックエンドサービスのみで構成されるところにあります。解釈にはいくらか幅はあると思いますが、つまりサーバレスアーキテクチャの“サーバ”とは、性能や可用性を意識して設計、保守しなければならない“フロントエンドサーバ”のことを意味しています。

従来の一般的なウェブ＋データベース（DB）のアーキテクチャ

サーバレスアーキテクチャ

　クライアントは多くの場合、HTML5アプリケーションやネイティブアプリケーションで提供されます。バックエンドにはいわゆるBaaS（Backend as a Service）と呼ばれるAPI＋トリガー＋データベース（DB）で構成されるサービスが用いられます。バックエンドは上図のように単体のBaaSで構成されることもありますが、いくつかのサービスの組み合わせで構成されるケースもあります。

HTML5アプリケーションでのサーバレスアーキテクチャ

　HTML5アプリケーションでの構成例を考えてみましょう。HTML5アプリケーションでは「SPA」構成が採用されることが少なくありません。

　SPAとはSingle Page Architecture/Applicationの略で、単一ページでウェブアプリケーションを構成します。画面を遷移するときにはページ全体をロードするのではなく、JavaScriptがHTMLのDOM構造を書き換えることでユーザーインターフェース（UI）を切り替えます。JavaScriptがサーバ側のAPIを呼び出すことでサーバと通信します。また、双方向のリアルタイム性が求められるアプリケーションでは、WebSocketプロトコルを利用する場合もあります。

　SPA構成でウェブアプリケーションを開発することで、エンドユーザーのクリックやタップ、入力にあわせて、ネイティブアプリケーションのような操作が可能になります。またその都度、ページ全体をロードするのに比べ、必要最低限のデータ転送に留められるため、モバイルのような帯域が限られた環境でも応答性の高いアプリケーションを提供できます。

　前述の通りSPAでは、サーバとの通信にAPIが欠かせません。そしてクラウドで提供されるバックエンドサービスは大抵、APIを通じたアクセスが可能です。そのため、フロントエンドは省略し、ブラウザにロードされたJavaScriptとバックエンドサービスのAPIが直接通信するシンプルな構成にできるわけです。

サーバレスアーキテクチャで注意すべきポイント

　ただし、サーバレスアーキテクチャには検討すべきことが2つあります。

　まず、ブラウザはアプリケーションを起動する際、どこにアクセスすればよいのでしょうか？

　ブラウザにロードされるコンテンツは、これまでのウェブアプリケーションと同様にHTML＋JavaScript＋CSSで構成されています。従来はこのコンテンツを配信するためにウェブサーバが存在しましたが、サーバレスアーキテクチャではそのウェブサーバが存在しません。

　クライアント端末のローカルストレージにコンテンツを保存しておけば、アプリケーションを起動できますが、これでは当然、利用の範囲が自分だけに限られてしまいます。

　この問題に対する1つの解は、オブジェクトストレージサービスの活用です。

　オブジェクトストレージサービスは非構造化ファイルを保存する機能に加えて、静的なウェブコンテンツを保存した場合には、それをHTTP/HTTPSプロトコルで配信する機能も備えている場合が多いです。オブジェクトストレージサービスにHTML5アプリケーションのコンテンツを保存することで、ウェブサーバの代替となります。

　つまるところ、上記の構成でもオブジェクトストレージサービスがウェブサーバとして動作しているわけで、結局のところ、完全にフロントエンドサーバがなくなるわけではありません。ただし、実質的にほとんど運用管理が不要なサービスで代替することで、メンテナンスを必要とするビルディングブロックがなくなる、という側面がサーバレスアーキテクチャの本質だと筆者は考えています。

　このときに多くの場合、コンテンツ配信元のオブジェクトストレージサービスのURLと、APIコール先のバックエンドサービスのURLは、ドメインが異なります。注意しなければならないのは、「CORS（Cross Origin Resource Sharing）」というセキュリティルールに基づき、コンテンツ配信元と異なるドメインへのAPIコールは通常、ブラウザからブロックされるということです。バックエンドサービス側でCORS設定（コンテンツ配信元のドメインからのアクセスを許可）をすることで回避できますが、バックエンドサービスがCORS設定をサポートしているかどうかを確認する必要があります。

　もう1つ検討しなければならないのは、複合的な処理をどのように実現するのかという問題です。

　単に1つのアイテムを保存する、あるいは一括で複数アイテムを保存して完了、という処理であれば問題ありませんが、アトミック（不可分）に操作する必要のある複数の更新処理や、データを保存した後にスマートフォンにプッシュ通知したい、他のクラウドサービスでの承認フローを開始したい、といった要件がある場合は、ストレージ機能のみを提供するバックエンドサービスでは実装が難しくなります。

　この問題の解としては、「トリガー」と呼ばれるデータ更新によって連鎖的に実行される複合処理が可能なバックエンドサービスを選択するか、クライアントとバックエンドサービスの間にもう1つ複合処理を担当するビルディングブロックを追加することが考えられます。