セクションナインの吉田真吾（@yoshidashingo）です。

さて、前回の記事では今年のカンファレンスの開催報告をしました。今年もサーバーレス盛り上がりましたね。

トレンドをみると東京でカンファレンスを初開催した咋秋から、グローバルで4倍近いアテンションに高まっています。

さて、ここでは今年のサーバーレスの動きを振り返って頭の中をダンプしますんで、界隈の人と賛否両論なフィードバックをネタに年始の飲み会などができると嬉しいなと思っています。

1/24(水)に次回のServerless Meetup Tokyoを予定してますんでそちらはまた別途告知しますね。

エコシステムの発展
サーバーレスコンピューティング = プロキシ + 実行環境 + ステート管理 = リアクティブなマイクロサービス
いろんなニューカマー
今後

エコシステムの発展

今年はエコシステムやマーケットが特に発達しました。

フレームワークツール

2015年にJAWS Frameworkから始まったServerless FrameworkはいまやGitHubで2万以上スターを獲得している超定番な開発フレームワークになりました。また、AWS SAMも順調に進化しています。

toris.io

※やっぱり読まずにスクロールしましたね。

サーバーレススタートアップ

また今年はIron Functionsの開発元であるIron.ioがXenon Venturesを経由してOracleに売却されてそのプラットフォームに組み込まれたり、OpenFaaSが急激に頭角を現したりと、オープン系FaaSの話題が多かったです。

日本ではShifter *1やGS2 *2がさらに高機能化して日本のサーバーレススタートアップシーンを牽引してます。

また、海外からも複数のサービスが日本市場に入ってきました。Auth0 *3、Algolia *4、Netlify *5あたりは日本オフィスを構えたり契約ユーザーが増えており順調な印象です。

コンサルタンシー／エージェンシー

クラウドプラットフォーム各社の上位ティアなパートナーの多く(cloudpack/クラスメソッド/サーバーワークス/スカイアーチネットワークスなど)がサーバーレスを活用した開発を請け負う専門部署を運営し始めたのも今年でした。サーバーレスのメリットを享受しながらある程度リスクオフしたいユーザーにとってこれは新たな選択肢です。

プラットフォーム

また、今年後半はクラウド各社のサーバーレスなプロダクトが充実してきたことで「サーバーレスとは何か」という定義についてあらためて考える場面が多かったです。「サーバー管理不要」「スケーラビリティ」「使ったぶんだけ課金」の3つの特徴だけが「サーバーレスコンピューティング」の特徴と言い切れなくなりました。

サーバーレスコンピューティング = プロキシ + 実行環境 + ステート管理 = リアクティブなマイクロサービス

サービスの充実を受けてあらためてサーバーレスの特徴を考えてみて、リクエストのプロキシ、実行環境、ステート管理(ステートマシンやワークフローのオーケストレーション、さらにはエラー管理やリトライ処理)が分離されて管理できることがサーバーレスの最大の特徴だと確信しています。プロキシと実行環境の分離がスケール管理不要や実行時のみリソース調達＆課金といったクラウド事業者が共通して宣伝してる部分であり、実行環境とステート管理の分離が開発生産性やアプリのロバスト性につながるアプリの実装で意識すべき部分かなと思います。

システムの処理パターンとコンポーネントの組み合わせをちょっと見てみましょう。

3つの基本的な処理パターン

Webプロセッシング
ストリームプロセッシング
バッチプロセッシング

各コンポーネントの説明

リクエストプロキシ
- WebアプリにおけるリクエストプロキシはNginxなどのプロキシサーバーやREST APIの場合はAPI Gatewayがこれにあたりますが、ここがサーバーレスにおいてはプラットフォームの提供するAPI GatewayやFaaSのHTTPトリガによってリクエストを受け付け、トラフィックルーティング、キャッシュ管理、保守不要、無限のスケール、流量管理などをしたうえでバックエンドにルートします。オープン系FaaSではこのトリガ(HTTPトリガ含む)はアプリのエンドポイントのプロキシコンテナが実行環境のコンテナとは別に常時起動しているという仕組みになっています。
- ストリームであればKinesis StreamsやEvent HubsやCloud Pub/Subがこれにあたり、Publisher(Producer)がストリームに対してデータを投げ、Subscriber(Consumer)がデータを取り出して処理を行います。
- マイクロバッチであれば、SNSやEvent Gridのような非同期かつプッシュ型のプロキシもあれば、非同期かつPull型のSQSやCloud Pub/Subといったキューがこれにあたります。
実行環境
- ロジックレイヤーである実行環境はLambdaのように言語およびバージョンに制約のあるものから、IBM Cloud FunctionsのようにDockerイメージ指定で自由に実行できるもの、OpenFaaSのように基盤からk8sなどに連携してリソーススケジュールすることができるオープン系までさまざまです。
ステート管理
- Webアプリではステートマシンを使うことはないですが、エラー処理やリトライ制御が実行環境と切り離されていることがロバスト性を担保する鍵になります。Lambdaであれば同期イベントのエラー時にはHTTP429が返却されるため、エラー処理はクライアント側での実装になるという意味で切り離されています。
- マイクロバッチにおけるステート管理はStep FunctionsやDurable Functionsのように複合条件やファンアウトの待ち合わせを行うステートマシンや、ジョブネットのような実行順序制御を管理するオーケストレーションから、Lambdaの非同期ジョブの自動リトライや、デッドレターキュー(DLQ)によるエラー制御の外部定義などです。これらを活用することで、こういった制御をロジックレイヤーから切り出すことができることで、コードに依存しないアプリのロバスト性やメンテナンス性を確保することができるようになります。おそらく今後サーバーレスの開発生産性を議論する場合にはこういったソフトウェアエクセレンスを考える必要が重要になってくるでしょう（※単純にマネージドサービスを使って「作らない部分を増やす」だけでなく、「作る部分をどれだけ小さく／正しい粒度に保てるか」といった観点や、Testableであるという観点）

アプリケーション共有リポジトリ

生産性について言うと、今年はAWS Serverless Application Repositoryのようにアプリケーションを定義化して共有できるサービスも増えました。これは当初Serverless Platformが似たような構想として始まっていましたが、AWSはSAMをベースにこれを実現し、StdLibではそれぞれリクエストのIFや実装方法が違うFaaSのコードを共通化しておいて、各プラットフォームに合うように変換してデプロイできるレポジトリサービスを開始しました。

認証サービス

従来モノリシックなサービスであれば、アイソレートされたサーバーの内側での通信や保護されたネットワーク内部の通信で良かったものの、マイクロサービスのようなドメインをまたいだサービスの呼び出しなどが必要な場合、ネットワークによる保護以外の方法で安全に呼び出し会える必要があります。

リクエスト時に認証された一時トークンを引き回すためにOAuth2などに対応したAuth0のようなサービスや各クラウドプロバイダーのマネージドサービスがサーバーレスなマイクロサービスを作る上でのキモになります。

いろんなニューカマー

4つのサーバーレスカンファレンス勢

今年はServerlessconfや元々Serverlessconfを始めたメンバーによって立ち上げられたJeffConfがより運営をフランチャイズ化して発展しました。それにくわえて、Serverless, inc. 主催のemitが初開催され、ServerlessconfやJeffConfよりもより対話・議論を重視した内容で盛り上がりました。

また、インドではServerless Summitというこれら3者とはまったく別のイベントがOracleをリードスポンサーとして初開催されました。

Oracle Cloud

そのOracleですが、買収したIron.io自体は既存事業を維持しつつもOracle Cloud上での展開も見据えてIron Functionsとは違った新しいFaaSのプロジェクトであるFn Projectを提供し始めました。先行きに関してはまだ不透明ですが、来年はさらなる台頭が期待されます。特にIronFunctionsはただのオープン系FaaSというだけでなく、自社で提供しているIronMQなどと連携ができることを売りにしていたので、Oracle Cloud内の各種サービスや、人事や会計のSaaSパッケージとの統合が進むと有益なユースケースが多いのではないかと考えています。

とはいえ、少なくとも日本においてはクラウド事業のプレゼンスがほぼゼロに近いオラクルが、まだ儲かりそうにないサーバーレス分野において継続的に積極投資ができるかどうかは未知数ですね。

さらに来年はAlibaba Cloudのクラウドマーケットでのプレゼンスがさらに高まります。彼らはすでに中国国内(かつ中国アカウント)のみで利用できるFunction ComputeというLambdaに似たFaaSを提供しています。

どこかで見たことある感じ pic.twitter.com/9uJI1qGTfl
— Shingo(吉田真吾) (@yoshidashingo) 2017年10月20日

FaaSはバインドサポートの多さがあってこそとあらためて思った

ただしこのFunction Compute、現状OSS(オブジェクトストレージ)のオブジェクト作成のトリガしかサポートされていないため、画像のサムネイル作成や圧縮ファイルをほどくようなユースケースしかないなと感じたのが正直なところで、あらためて「FaaSは周辺サービスとのネイティブなバインドサポートがどれだけ充実しているか」によって開発生産性が大きく変わりそうだなと感じました。

ロジックレイヤーだけあっても、上記で書いたようなプロキシ(Enent Grid機能)とステート管理レイヤーが充実しないとサーバーレスなシステムを作るベネフィットは得られにくいなという感想です。

Alibaba Cloud

そのAlibaba Cloudですが、上記のFunction Compute以外にもk8sベースのContainer Serviceもあったり、ビッグデータ系のサービスも充実しており、モダンなクラウドサービスで当然提供されているべきマネージドサービスが一通り揃っています。

先日Container ServiceのPMと会話したところ、Alibaba.comはすでにすべての基盤をこのContainer Service上で展開したうえで先日のダブルイレブン(11月11日、通称独身の日)の注文を捌いたらしいです。またSwarmモードしかなかったリソーススケジューラーもKubernetesモードの展開を進めていくので、特定のユースケースを除けばKubernetesモードがデフォルトになっていくだろうとのことでした。

来年はさらにグローバルなマーケットを相手にしてる会社ほど、中国の内需を取り込むことを想定してはじめから基盤をAlibaba上でという選択が増えていくと思います。ICPライセンスの申請しやすさや、ビジネス慣習にあった業務提携が得られるというのもメリットだと思います。

ちなみに準拠法については日本で契約したアカウントは日本に準拠します。とはいえ地政学的リスクとして中国のクラウドプロバイダーの姿勢はちょっとなーということも実際あるので、ユーザー自身の情報の開示は仕方ないにせよ、保存されるカスタマーのデータはクライアントサイド暗号化で保護すべきで、そこらへんはまた別途の機会に真剣に考えてみましょう。