クラウド四方山話「サーバーレスアーキテクチャ」
IT 業界で2015年もっとも流行ったバズワードが「IoT」だとすれば、パブリッククラウド業界で2015年後半もっともバズったのが「サーバーレスアーキテクチャ」ではないかと思います。特に10月に行われた re:Invent（AWS のカンファレンス）あたりから一気に叫ばれるようになったように感じます。
他のバズワードでもありがちな明確な定義が無いマーケティング用語ですが、2012年あたりから「Serverless」という単語が明確なフレーズとして使われ始め25、AWS Lambda がそれをアピールに利用したことで一気に広がったようです。
「サーバ」でイメージされる範囲が広いのでサーバーレスアーキテクチャに対しても様々な理解があるようですが、大きく二つのパターンに整理できるようです。
アプリケーション実行環境として、サーバという抽象化単位を隠蔽したマネージドサービスを利用
するパターン2. アプリケーションのビジネスロジックをフロント（ブラウザやスマホ・デスクトップアプリ）に移したう
えで、データストアなどのコンポーネントを直接利用するパターン前者はソフトウェアのアーキテクチャ、後者はシステム全体のアーキテクチャという点で視点そのものが大きく異なります。きっかけとなった AWS Lambda は前者の認識をもとに「サーバーレス」を謳っていますが、クラウドコンピューティング全体の方向性としては後者における「サーバーレス」化も進んでいくのではないかと考えています。この記事ではそれぞれの定義における「サーバーレス」が現状どういったものであるかを整理し、課題と方向性を議論します。
「サーバーレス」については、既刊「Serverless を支える技術」にてより掘り下げて整理をして紹介しています。ここではその一節を引用します。
計算機の抽象化によって「サーバに依存しない」という制約が登場し、それによってスケーラビリティの確保が容易となり、それと相まって FaaS や Functional SaaS のようなクラウドサービスが登場しました。これらをイベントドリブンなシステムアーキテクチャによって最大限に活用すること、この全体が「サーバーレス」という技術ムーブメントの全体像です。
「サーバーレス」という言葉からイメージしやすいのはフルマネージドサービスによるサーバからの脱却という運用面ですが、実際に世の中を変えているのは開発面におけるイベントドリブンアーキテクチャによるソフトウェア開発自体のパラダイムシフトです。そしてその根底では「サーバ」というアプリケーション実行環境の抽象化が進んでいます。
サーバーレスアーキテクチャとPaaS
「サーバーレス」化を盛んに言い始めたのは AWS Lambda ですが、その流れの発端は2008年にリリースされた Google App Engine です。どちらも、下にあるサーバのプロビジョニング（仮想サーバインスタンの作成と実行環境の構成）を隠蔽してステートレスなアプリケーションを動かすことができるアプリケーション実行環境です。どちらも一見似ていますが、その発展の仕方は大きく異なります。
Google App Engine はもとよりウェブアプリが大前提となっています。時刻をトリガーとするスケジュールタスクはありますが、Cloud Pub/Sub からのプッシュや Cloud Storage の変更通知などの Google Cloud Platform 内でのコンポーネント間連携もすべて HTTP 経由で呼び出されます。
対して AWS Lambda は2014年に最初にリリースされたときには、Amazon S3や Amazon DynamoDB の更新や Amazon Kinesis 経由でのメッセージをトリガーとして、非同期に実行したアプリケーションを実装するための、いわばコンポーネント間連携の枠組みでした。それが、まず4月に同期呼び出しが実装されるとともに AWS Mobile SDK を経由してモバイルアプリから直接呼出せるようになり、API のバックエンドとしての道が開けました。さらに、7月に Amazon API Gateway の登場で普通のウェブ API が AWS Lambda で実装できるようになり一気にその可能性が注目されるようになりました。
最終的にはどちらも、ステートレスなアプリケーションを受け取り、上手い具合にプロビジョニングされた実行環境を提供してくれ、外部からの HTTP リクエストへの応答や他のコンポーネントと連携可能という、似たような立ち位置に置かれています。
サーバーレスアーキテクチャと PaaS の違いが良く議論されます。Heroku に代表されるいわゆるアプリケーション PaaS という分野は、技術的に十分成熟しプロビジョニングやオートスケールがマネージドサービスとして自動で行われることは当たり前となっています。ステートレスなアプリケーションがPaaS 上でスケールさせやすいということも以前から知られており、代表的な PaaS 事業者であるHeroku の共同創業者 Adam Wiggins 氏が「The Twelve-Factor App」26として具体的な設計方針をまとめています。
つまり、実行環境がステートレスであることを強制しているかどうかにかかわらず、そもそもスケールさせやすいアプリケーションを書くにはステートレスであるべきといえます。このようにアプリケーション自体においてそもそもサーバという単位を考えることはなくなりつつあり、いわゆるサーバーレスアーキテクチャと従来からの PaaS に大きな違いは無いように見えます。
アプリケーション実行環境としてのサーバーレス化
それでは何が「これがサーバーレスアーキテクチャだ」と呼べるような実行環境の特徴かといえば、それは実行環境のプロビジョニングとオートスケールが真に隠蔽された結果、実際に利用したリソースに限りなく近い課金が行われることではないかと考えます。
Google App Engine ではあくまでインスタンス単位で動作しますが、分単位で自動オートスケールと課金が行われるため、余剰リソースがほとんど無く実際に利用したリソースに近い課金が行われます。あくまでリソースの追加・削除がインスタンス単位でしか行えないだけだという見方もできます。AWS Lambda に至っては、実際にアプリケーションが消費した CPU 時間に対して100ミリ秒単位で課金されます（Google App Engine もプレビュー時代は CPU 時間に課金されていました）。
利用者視点で見ると、この消費した CPU 時間への課金というところが、サーバーレスアーキテクチャの一番の特徴と言えます。どんなに賢いオートスケールのアルゴリズムであっても、まともな応答時間でサービスを提供するためには余剰リソースが必要になるのに対して、消費した CPU 時間への課金であればいくら裏で余分に余計にリソースを確保していたとしても使わなければ良いので、もはや裏側でどんなオートスケールが走っているかを（正常に動いている限り）考える必要は一切無くなります。
その一方で、読込と初期化に何秒もかかるような大規模なフレームワークを使うにはまだまだ課題が大きそうです。Google App Engine ではダミーのリクエストを投げて「サーバを暖める」ためのWarm up Requests が提供されています。一方でオートスケールを完全に隠蔽した AWS Lambdaでは、使用頻度の低いアプリケーションの初期化に時間が掛かってしまうという報告もあります27。これは、高レベルな AWS コンポーネントとの連携を前提とした、初期化処理がほとんど必要無いようなMicroservice での利用を前提としているが故の割り切りとも言えるでしょう。
ほんとうのサーバーレスアーキテクチャにむけて
「確保した量」から「使用した量」へのシフトによりサーバという単位を完全に忘れようとするのがアプリケーション実行環境におけるサーバーレスアーキテクチャですが、提供されたサービスの組み合わせだけでサービスを組み立てることで、「アプリケーションサーバ」という存在自体を無くしてしまう方向での技術革新もだいぶ進みました。
スマートフォンアプリや SPA（Single Page Application）の普及により、サーバは認証と REST API によるデータの送受信だけを提供すれば良いという時代になりつつあります。REST API はその性質からデータストアと相性が良く、さらに各クラウド事業者が提供する認証基盤の SDK と組み合わせることができます。例えば Facebook でログインして Amazon Cognito の ID 連携を経由してDynamoDB や S3上の自分の領域に直接データを保存するといったことが実際に可能です28。
パブリッククラウドが提供するデータストアコンポーネントは全体として圧倒的なスケーラビリティを持っているため、アプリケーションレベルごときの突発的負荷などにも軽く対応できます。そのため、実際にはバックエンドでは AWS Lambda などでアプリケーションが動いていたとしても、ユーザとの接点はデータストアと直接やりとりするようなタイプのシステムが増えていくと予想しています。
API としてユーザに提供したいインターフェースと、実際のデータモデルの間を埋めるものとして、Amazon API Gateway や Microsoft Azure API Management のように API 管理層が間に挟まり、データ形式の変換、キャッシュなどを行うコンポーネントが提供されています。Amazon API Gateway はもっぱら AWS Lambda の呼び出しという味方をされることが多いですが、本来はもっと大きな可能性を持っています。
サーバーレス時代のID連携
もう一つ重要なものが、ユーザの識別と認証です。
従来のウェブアプリなどでは、暗号化したブラウザクッキーやセッション DB などのサーバ側アプリケーションのみがアクセスできるセッション変数などを使うことで、リクエストをまたいでユーザを識別していました。そして、アプリケーション自体はデータストアに対する全ての操作権限を持ち、アプリケーションがユーザの ID をみて可能な操作のみを実装していました。ところがアプリケーション処理がユーザ側の端末で行われるようになると、アプリケーションの実装自体を信頼できなくなります。
古くから OpenID で ID 連携を提供し現在も OpenID Connect など自ら認証基盤と ID 連携を提供する Google をはじめとして、外部のソーシャルログインとも連携できる Amazon Cognito、Microsoft Azure Active Directory B2C など、各事業者は他のコンポーネントと ID 連携できるような枠組みを揃えています。
これは、アプリケーション自体に権限を持たせるのでは無く、「アプリケーションを利用しているユーザ」ごとに信頼して権限を持たせるという流れに沿ったものです。アプリケーションの上で ID とパスワードを直接入力するのでは無く、ブラウザ等を介して認証を提供するプロバイダーと直接 ID・パスワードのやりとりをして、あらかじめ必要最低限の権限だけを与えられたアクセスキーのみをアプリケーションに渡します。これでアプリケーションはどれだけ頑張っても、あらかじめ認可された範囲の操作しかできなくなります。
セキュリティの基本は「最小権限の原則」ですが、スマートフォンを筆頭にクライアント側アプリケーションの流れが来ている中、これからの数年で認証基盤と ID 連携を中心に「最小の権限だけを与えるとはそもそもどういう事か」という見直しが進んでいくものと思います。
おまけ：「薄く広い」アーキテクチャ
プロビジョニングの話が出ましたが、最近私が注目しているのが「薄く広い」アーキテクチャです。判る人には Google BigQuery と言えばピンと来るかも知れません。Google BigQuery を簡単に紹介すると、RDBMS っぽく SQL でクエリが書けるデータストアですが、膨大な件数のテーブルに複雑なクエリを投げても一瞬で結果が帰ってくると言う夢のような代物です。ただしその分制約も多いです。
Google BigQuery がやっているのは究極の力業です。データを数万台以上の膨大な数のサーバに分散保存し、クエリもその全てのサーバで一気に走らせてフルスキャンした結果を集約するというものです。これは Google 自身が持つ巨大なデータストアを共有で相乗りしているから可能となるスケールアウトの手法です。あまりぴったりくる訳語を見かけなかったので、ひとまず私はこのようなアーキテクチャを「薄く広い」アーキテクチャと呼んでいたりします。
サーバーレスアーキテクチャも消費 CPU という結果ベースの課金であることが特徴と書いてきましたが、BigQuery の課金モデルも同様に「実際にスキャンしたディスクの容量」と大変分かりやすくなっています。
一番重要な点は、BigQuery のように「薄く広い」アーキテクチャでしか実現できないことがあり、これらはパブリッククラウド事業者のような大規模クラスタを共有できる状況でしか実装ができないというところです。今のところはまだありませんが、アプリケーション動作環境でも「薄く広い」アーキテクチャでないと実現が難しい「何か」が出てきたときが、本当の変革の時なのでは無いかと思います。その点で、IoT 業界がやろうとしていることの規模感には期待をしていたりします。