この記事は、Serverless Advent Calendar 2016の16日分(だったはずのもの)です。
なんとかクリスマスまでには間に合ったのでお許しくださいorz
まとめ
- AWS Lambdaの功罪で混在されがちな概念が整理されて議論されるようになった
- 提供されるBaaSのみを使ってリッチアプリケーションを開発する手法
- フルマネージドなFaaSの実行環境
- 高水準コンポーネントをイベントで接続するリアクティブシステム
- 主要各社のFaaS実行環境が揃ってきた
- サーバレスアーキテクチャにまつわる様々な動き
- FaaSの汎用化への第一歩
- 高水準コンポーネントの拡充
- ID管理・認証・認可
- 開発者向けの動き
- 2017年に向けて
こんな感じでそれぞれを掘り下げて行きますです。
「サーバレスアーキテクチャとは議論」
「サーバレスアーキテクチャ」は、2012年に単語として提案されて以来4年が経ちましたが、その「サーバの無いアーキテクチャ」という語感から、各領域の問題意識によって様々な意味を持たされてきました。
整理の方向性としては、以下の3つ、もしくは2つ（1＋3と2）に分けられるようです。
1. 提供される高水準コンポーネント(BaaS)を使ってリッチアプリケーションを開発する手法
FirebaseやCognitoなどの、BaaS (Backend as a Service)と呼ばれるサービスの登場が、サーバレスアーキテクチャがキーワードとして取り上げられる発端の一つです。
スマートフォンアプリケーションやブラウザ上のSPA (Single Page Application)が、高水準コンポーネント、とくにID基盤とデータストアを直接利用することによって、自分でアプリケーションを書かずそのためのサーバが不要、というものです。なお、AWSなどでは特に2-Tierアプリケーションと呼んでいます。
とくにユーザ管理と簡易データストアで十分なことも多いモバイルアプリ向けのmBaaSとして広く使われるようになりました。その一方で、最有力であったはずのParse.comのサービス終了など、ビジネスとして単独では厳しいところもあるようです。
2. ステートレスなアプリケーションを動かすフルマネージドな実行環境(FaaS)
BaaSだとサーバ不要で楽だよね、と言われてきた一方で、2014年末にAWS Lambdaが登場して以来「サーバレスアーキテクチャ」の代表的な存在とみなされているのが、このFaaS(Function as a Service)とその実行環境です。AWS自身が「Serverless」であることを積極的に推しているというのもあります。この文脈において「サーバレスアーキテクチャ」とは、全ての場面において利用者が「サーバ」という管理単位を考えずに済むアプリケーション実行環境を指します。
以前よりHeroku方面の「The Twelve-Factor App」などで、アプリケーションはステートレスに作るのが良いというベストプラクティスが広まっていましたが、ステートレス（アプリケーション自身が状態を持たない）という制約のメリットを最大限に活かすことで、クラウド側が自由にスケールさせることができます。
さらに、スケールしたときの起動時間を最小にするために、アプリケーションという単位のかわりに関数(Function)という単位を用いています。実際にはRails等が利用するミドルウェアRackのエンドポイントがcallという単一メソッドであるように、あるいはFaaSであっても一つのエンドポイント関数から複雑なシステム全体を構築することも可能ですし、アプリケーションなのか関数なのかという区別は意識的な部分が強いです。とにかく、ステートレスで軽量な関数ならば、自由にプロセスを増やしたり減らしても良いよね、というわけです。
スケールをクラウド側が勝手に行うこともあり、必然的に課金単位が、利用者の確保したサーバ台数から、実際にアプリケーションの実行に要した消費時間にシフトしました。「所有から利用へ」というクラウドの性質を一歩進め、「確保量から消費量へ」を実現しました。
この「実行時間への課金」の元祖が、2008年のGoogle App Engineｎプレビューリリースがだったというのも、歴史的な経緯としては抑えておくべきでしょう。2009年の正式リリース時ではインスタンス単位の課金に変更されてしまいましたが、そこからAWS Lambdaで実効時間の課金が登場するまで5年も要してしまったわけです。
他にも、ちょっと変化球な視点として、FaaSという「Functionの実行環境」に限定せず、サーバという課金単位を持たず計算量で課金されるようなフルマネージドなデータストアもこの分類に入れることができます。たとえばBigQueryの課金形態を見ると、実際のデータ処理容量(MB単位)と処理の複雑さ係数の掛け算となっています。このような小さな処理を膨大な台数で分散して実現するような「薄く広い」元気玉のようなコンポーネントもまた、「確保量から消費量へ」を実現しているといえるでしょう。
3. 高水準コンポーネントをイベントで接続するリアクティブシステム
最後に紹介するのが、「サーバレスアーキテクチャ」と言われる概念の中で最も抽象度が高いものです。
クライアントからのリクエストを受け付けた「サーバ」が処理の全体に責任を持ち様々なリソースを利用して結果をクライアントに返すのが一般的なシステムのアーキテクチャですが、複数のコンポーネントを非同期なイベント(メッセージ)で接続し、ピタゴラ装置のように全体として機能を実現するアーキテクチャが増えてきました。AWS Lambda(とAWSの各コンポーネント)のユースケースとして様々なパターンが紹介され、確かに「中央集権的なサーバが無くなる」ということからも、この考え方そのものも「サーバレスアーキテクチャ」と呼ぶことが増えています。
実はこの概念は、特に分散並行処理のために設計された言語Erlangの方面から、「アクターモデル」という数学モデルとして整理されてきた考え方に近いものです。最近では「リアクティブシステム」として再整理が行われ、リアクティブ宣言という設計原則が書かれています。
別の視点としては、ビッグデータ分野における分類としてストリームデータ処理という分野があり、バッチ処理、クエリ処理という「サーバ」型の処理モデルに対抗して、フローデータをそのまま常時処理し続ける処理モデルをさします。こちらは、2011年にオープンソースでStormが公開されたことが最初ですが、AWSがAmazon Kinesisを2013年に正式リリースしたことをきっかけに、自前で大規模なクラスタを構築せずにストリームデータ処理ができるようになりました。並行して、FluentdやNorikraのようなよりお手軽なストリーム処理の実装が登場したこともこの動きを支えています。
実装としては、クラウド事業者が提供する高水準コンポーネントが何らかのイベントを生成し、それをメッセージとして数珠つなぎして別の機能を呼び出していきます。ここでLambdaのようなFaaSが介することも多いですが、FaaSすら介さず直接他のコンポーネントの機能を呼び出せる場面も増えています。
この考え方の変化は、アプリケーション開発者であれば、フレームワークによる制御の逆転(Inversion of Control)のクラウド版と考えると分かりやすいと思います。
サーバレスアーキテクチャというキーワードを普及させたAWS Lambda自体は2のFaaSですが、実際に世の中を変えているのは、Lambdaに接続できる高水準コンポーネントを増やした結果、様々な事をメッセージ駆動で容易に実現できるようになった3の効果です。これが一緒くたに宣伝されてしまっていることが「サーバレスアーキテクチャ」の議論が迷走しやすい原因であり、まさにAWS Lambdaの功罪と言えるでしょう。
主要各社のFaaS実行環境が揃ってきた
今年は、まさにFaaSの発展の一年でした。
AWS Lambdaが着実にユースケースを増やすと共に、大規模事業者によるFaaSの提供が始まっています。2016年内に駆け込むように、Azure Functionsとつい先日IBM OpenWhiskが正式リリースされていますし、元祖GoogleからもあらためてGoogle Cloud Functionsがアルファリリースされています。
AWS Lambda
Lambdaの今年最大のニュースは、CDN(CloudFront)内の制御にLambdaを利用できるLambda@Edgeと、IoTデバイス上でのエッジコンピューティングにLambdaを利用できるAWS Greengrassの登場です。
また、Lambdaでリアクティブシステムを実現するための部品も大幅に増え、ピタゴラ装置の安定稼働に必要なAWS Step Functionsやデッドレターキューなどが提供されました。分散アプリケーションのデバッグを実現するAWS X-Rayも、まだLambdaへの対応待ちですが楽しみなところです。
Lambda自身としてはC#が動くようになったぐらいですが、その一方で、Serverless Frameworkをはじめとしたフレームワークが揃ってきており、AWS自身からも「Serverless Application Model(SAM)」が登場しています。
Azure Functions
Azure Functionsは、今年の3月に発表され、11月に正式リリースされました。
パブリッククラウド全体の「圧倒的王者AWSをビジョンで追いかけるMicrosoft」という現状の縮図そのままに、利用できる言語環境の多さや、「出力バインド」という考え方、単独でのHTTP API実行可など、AWS Lambdaよりちょっとうまく設計している感が出ています。
開発者視点に手厚いMicrosoftらしく、Azure CLIを使ったローカル開発、ローカルデバッグ・リモートデバッグをVisual Studioや最近流行りのVS Code上から直接行えるというのが、一番嬉しいところかもしれません。
IBM OpenWhisk
こちらも2月に発表され、つい先日の12月14日に正式リリースされました。
Azure Functionsも、実行環境のランタイムエンジンはオープンソース公開されているのですが、全体がオープンソース化されているのが最大の特長でしょう。
Google Cloud Functions
今年の2月にアルファ版がリリースされ、惜しくも今年中の正式リリースは来ませんでした。
アルファ段階ということもあり、今後に期待ですね。
国内クラウドの動き
ごめんなさい、まとめます。
- ニフティクラウドはmBaaS由来のニフティクラウド スクリプトとしてFaaSを正式リリースしました。
- さくらインターネットは外部サービスとの連携を強化しています。いわゆるFinTech特需向けもあるのでしょうか。
- 各社、機械学習やブロックチェーンのコンポーネント提供を開始しています。
- エンプラ向け市場で、Cloud FoundryベースのPaaSという事例がちらほらあるようです。
- このはちゃんあざとかわいい
ニフティの富士通化、BIGLOBEのKDDI売却などを背景に、国内クラウド事業者再編の波が始まりました。
やはり「開発戦力の不足」が海外事業者に後れを取っている主原因と思いますので、再編してまだまだ頑張ってほしいところです。
サーバレスアーキテクチャにまつわる様々な動き
FaaSの汎用化への第一歩
FaaSを中心に拡がっているサーバレスアーキテクチャの波ですが、一つ確実に言えるのは、様々なコンピューティングの形が、FaaSにおけるFunctionという形で整理が進んでいるということです。
たとえばAWSは、IoTデバイスやIoTゲートウェイなどでコンピューティングを行うエッジコンピューティングや、CDNでの小さな制御処理を記述するためのDSLなど、そういった場面でのインターフェースとして、AWS Lambdaのものを拡げようとしています。
インターフェースを統一化してコードの可搬性を高める試みは、太古の昔よりさまざまな「透過性」として議論されてきた分野でもあります。とはいえオーバヘッドが……という部分が処理性能の底上げで解決してきたため、Functionという切り口を様々な場面で利用していこうというわけです。
実行バイナリを共通化するJavaバイトコードという抽象化で「Write once, run anywhere」を謳ったJavaが登場したのが1995年ですが、そこから20年余りがたち、「より良い抽象化されたインターフェース」を誰が握るかという抽象化競争が再び始まったと言えるでしょう。
高水準コンポーネントのさらなる拡充
「餅は餅屋」というわけで、高いレイヤーでの機能を数多く実装した高水準コンポーネントの拡充が、複数の領域で進んでいます。
- データストア
AWSがメイン環境でも「ここだけは」と使っている事例が多いらしいBigQueryが登場したのが2010年ですが、様々なフルマネージドなデータストアが登場しています。ついにAWSからもBigQuery対抗となるAthenaがリリースされましたし、可視化のためにBIツールとの連携も重視されています。
SORACOM Harvestのように、IoTネットワーク側に近い場所で提供されるデータストアも登場しました。
- イベントストリーム処理
ビッグデータ処理の本丸がイベントストリーム処理ですが、Amazon Kinesis AnalyticsやAzure Stream Analyticsなどパブリッククラウドでも提供されています。
BIツールへの繋ぎ込み部分というのも重視され始めています。
Kinesis AnalyticsのTokyo regionまだかなあ。
- ID管理・認証・認可
システムを分散処理として設計するには、その間でID管理をどうするかが重要となります。身近な例では、クラウド上のデータストアに直接接続するモバイルアプリが、そのID管理、権限管理を誰がどのように行うか、という領域があります。
この分野はモバイルアプリで利用できる認証基盤を核としたモバイルBaaS(mBaaS)が先行して発展しました。そのため、Amazonが提供するID基盤 Amazon Cognito User Pools がモバイル向けフレームワークの一部であったりと、若干微妙な状況になっていたりしますが、このmBaaSの流れの先で、Googleなどの一般的なID基盤のID情報を利用して、データストア側で直接認可を行う「2-tier architecture」はもはや一般化しています。
「Identity is the New Perimeter」と、セキュリティ上の境界線はもはやネットワークではなくID管理と言われ始めて数年になりますが、OpenID Connectが標準化され情報が増えてきたことで、JWT(JSON Web Token)でID情報を連携して認可を行うモデルの事例が増えてきているようです。地味ですが、サーバレスアーキテクチャをやっていくためには、きっちり抑えておきたい領域です。
Auth0使い始めましたがいいですね。公式Twitterのemoji乱舞 がかわいいです。
- コグニティブ
自然言語や画像処理など、いわゆるコグニティブ領域のコンポーネントが一気に揃ってきました。キーワードとしてはIBM Watsonが牽引していましたが、今年で一気に花開きました。
いつもSiriに穴がある問題など実用まではまだまだ課題が多い分野ですが、コグニティブ分野はとりあえずピタゴラ装置組み立てるだけでもかなり面白い事例が増えていきそうです。
開発者むけの動き
フレームワーク
先行するAWS Lambdaを主戦場に、開発やデプロイのためのフレームワークにおいて競争が始まっています。そのデカい主語の通りマルチクラウドを標榜するServerless Frameworkが1.0を迎えたのにあわせるように、AWSからもServerless Application Model(SAM)が登場しています。その一方で、REST API管理の標準であるSwaggerを中心とした仕組みも拡充してきています。
フレームワークという枠組みとしては、FaaSだけではなく様々な高水準コンポーネントの活用がサーバレスアーキテクチャの大事なところですが、クラウドコンポーネントの管理というところは、各クラウド事業者独自のCloudFormationやAzureリソーステンプレート、あるいはマルチベンダのHashicorp Terraformなどが既に十分な実績を積み立てています。これらのコンポーネント管理と、FaaSのプログラム管理をどう組み合わせていくかが重要です。
今は、FaaSにコンポーネント管理を組み込むフレームワークが主流ですが、FaaSがもはやコンポーネントを接続する「のり」でしかないとすれば、管理の方法も逆転していかなければならないのではと感じています。
デバッグと運用
旧来とくらべてデバッグしづらいメッセージ駆動アプリケーションということで、VS Code等からの直接デバッグが可能なAzure Functionsや、複数のコンポーネントにまたがった分散トレースを実現するAWS X-Ray、AWS Lambda内部のメトリクスを集めるIOpipeなど、フレームワーク以外の支援も始まっています。
また、運用が始まったあとの監視などまだまだ厳しいという感じですが、2017年に一気に市場が拡がっていくと思われます。
イベントの開催
ロンドンで開催されたServerlessConf Londonをきっかけに、日本国内でもServerlessConf Tokyoが開かれ、日本各地でのServerless Meetupなども開かれています。開発者間のコミュニティ醸成により、来年はさらなる発展の加速とベストプラクティスへの落とし込みが進むでしょう。
2017年に向けて
各社FaaSがだいたい揃ったという事で、高水準コンポーネントを含めた世界観全体で殴り合う総力戦がよーいどんです。
あと本家PaaSの本命であるHerokuあたりも、あらためて動きがあるのではないかなーと思っていたりします。
それはそれとして、大規模アプリケーションをサーバレスに実現しようとすると、まだまだ「開発で消耗する」という部分が大きいです。この「開発しやすさ」という部分が2017年の一番の主戦場となるでしょう。個人的にはデバッガでさくさくデバッグしたいところです。console.log でのprint debugは本当につらいです。本当につらいです。
ある程度の規模までは、いろいろな実現すべき仕様を分解・整理していくと、ID管理を核に接続されたマイクロサービスでシンプルに実現することができ、その方が最終的には見通しも良く不具合の影響を閉じ込められるシステムになるはずだと考えています。そういったソフトウェア工学という視点からも、様々な分析とベストプラクティスの積み上げが進むでしょう。
来年一年はまだみんな人柱ですね、「サーバレスをやっていくというお気持ち」で頑張っていきましょう。
宣伝
こんな感じの事を8月に書いた同人誌、通称「サーバレスの薄い本」を電子書籍で頒布中です。
今年の年末のコミックマーケット91にも参加します。なんとかぎりぎりまで粘って新刊出す予定です。
- 12/29(木) 西1ホール み-19b 「めもおきば」
追記: 2016-12-24 15:15
のおおおおおおおお！！！！！！！
タイトルが「2016年のサーバアレスアーキテクチャ総まとめ」になっていたのを修正しました……。
