こんにちは。照井＠東京出張中です。
東京は10月でも暖かいんだろうなって思って半袖をたくさん持ってきた結果、やっぱり暖かくて正解でした（オチがない）
本当はサンダルが楽で暖かい限りいつもサンダルでいたい派なのですが、それはさすがに浮くので我慢してます。
先日、2016-10-01（土）に開催された世界で２番目、日本では初のServerlessに関する大規模イベントである「ServerlessConf Tokyo 2016」にスピーカーとして参加してきました。
イベントの様子についてはレポートが弊社のこけし部部長の坂本から既に公開されています（スピード感！！）ので、そちらを御覧ください。
サーバーレスをやっていく気持ち！【ServerlessConf Tokyo 前半のレポートと資料まとめ】 | サーバーワークス エンジニアブログ
海外発のイベントで海外ゲストも多いということで、セッション資料を英語（話したのは日本語）にしてみたのですが、私の英語力のなさも相まって公開した資料を見てもあまり伝わらない可能性が高いと思い、日本語での解説を書いてみようという試みです。
公開資料
冒頭部分（3〜10スライド）
ネタの部分についてはこれ以上スベりたくないので割愛するとして、ネタに隠されたメッセージについて解説します。簡単に言うと、Serverlessにおけるサービスの可用性に関するお話です。
- Serverlessの世界ではサービスの可用性は他者に依存する
- その上で、どうやって自分達が求める可用性を担保すれば良いのか？
- これは、可用性を担保するためにどうするかという技術的な問題もあるが、経営的な問題でもある
解説
Serverlessとは、もちろんそれだけではないですが、（インフラの）運用を自分達でしない世界です。全てクラウドベンダーやサービサーに任せる形となります。その中で、依存するサービスに障害があると、自分達のサービスも影響を受けることになります。また、サービス自体が無くなる可能性もゼロではないわけです。そこで、その時どうするのか？ということは考える必要があると思います。
これは、「技術的にどういった方策を持って回避するか」ということも重要ですが、より大切なのは「経営的な判断」であると私は考えています。
「何もしない、任せる」という選択肢も十分にあります。回避策を講じるための費用的な問題もあります。また、それを回避したいがために自分達で開発・運用をするとなれば、そもそもとしてクラウドベンダーやサービサーよりも迅速なオペレーションで障害を解決するということが現実的では無いのではないかということもあります。
しかし、ミッションクリティカルで自社の根幹に関わるようなシステムであるなら、そうは言っていられないということもあるでしょう。これは、非常に経営的な問題だと思います。自分達のサービスに必要なサービスレベルはどれくらいなのか？ということはもちろんのこと、それを回避するための方策を進めるよりも、機能開発を優先すべきだというような判断もあるでしょう。外部のサービスを利用することは運用のオフロードのみならず、開発コストの削減という観点も重要です。
これはServerlessで外部サービスへの依存が強くなることで新たに出てきた文脈であるように感じるかもしれませんが、実はそうではありません。
ITシステムの世界は、今までも他者への依存を強めることで発展してきた歴史があります。アプリケーションの全てを自分達でフルスクラッチするのではなく、フレームワークやライブラリに依存して開発コストを抑えたり、近年では弊社が推進しているようにインフラをクラウドへ載せてクラウドベンダーへ依存する代わりに運用コストや機器管理コストを抑え、価値創造にフォーカスするということを実現してきました。万が一にもクラウドベンダーへ完全な依存ができないというお客様については、クロスリージョンの冗長性を持たせる方策を講じたり、オンプレミスとのハイブリット構成等という判断を経営的にしてこられた方々もいらっしゃいますし、そのお手伝いを私達もしてきました。
AWSについても、始めは「ミッションクリティカルなシステムは載せられない」と言われてきましたが、今はどうでしょうか？
そう考えていくと、Serverlessでミッションクリティカルなシステムを作ることの技術的な難しさ等の議論は別として、「Serverlessでミッションクリティカルなシステムを構築することは不可能である」とは言えないのではないかと思います。
フレームワークやツールについて（11〜20スライド）
本題のフレームワークやツールについて、比較的メジャーなものをチョイスして、私自身も一つツールを作っている身なので、その目線からご紹介しました。
Serverless Framework
Serverless Framework – Build web, mobile and IoT applications with serverless architectures using AWS Lambda, Azure Functions, Google CloudFunctions & more! –
フレームワークで一番有名なものはこれかと思います。
どんなものなのか？ということは、弊社のこけし部部長の坂本（２回目）の検証記事が非常に分かりやすいので、こちらをお読みください。
- 祝！ Serverless Framework 1.0 Beta版リリース | サーバーワークス エンジニアブログ
- サーバーレスシステム構築のベストプラクティス！ Serverless Frameworkをもっと試してみよう！ API GatewayとDynamoDB編 | サーバーワークス エンジニアブログ
こういった機能的な情報とは別に、大幅にリファクタリングされ、1.0未満から比べて遥かにフレームワークとしての抽象度が上がってプログラム的に「良い作り」になっており、Pluginによって拡張や一部の挙動を置き換えることが容易になりました。
これからAWS以外のプラットフォームへの対応も予定されており、よりエコシステム志向のフレームワークになったと言えると思います。これからも発展が期待されます。
Apex
Apex: Build, deploy, and manage AWS Lambda functions with ease (with Go support!).
もう一つの比較的人気のあるフレームワークとしてあげられるのがこちらです。
フレームワーク自体がGolangで書かれており、合わせてAWS LambdaのFunction自体もまだサポートされていない（2016.10.03現在）、Golangで記述することが出来るのが特徴で知られています。
実はもう一つ大きな特徴があります。それは、フロントエンドのツールチェインとの統合です。Lambda FunctionはJavaScript(Node.js)で書くことができますが、近年では現状のJavaScriptをそのまま記述するよりもBabel等を利用して、次世代のJavaScriptで記述して、デプロイ時に動作可能なJavaScriptへの変換を行う開発手法が主流になってきています。Apexは、そういったツールチェインとの統合をサポートしています。
その他にも多くの機能を持ち、便利なApexですが、Lambda Functionのエイリアスが固定である等、柔軟性に欠ける部分があったりもします。ただし、逆に言うとデフォルトの状態でそれなりに使えるようになっているという意味でもあります。そんなシンプルかつ便利に使えるのがApexです。
Chalice
Python Serverless Microframework for AWS
AWS公式のPython向けのマイクロフレームワークとして開発されたのがChaliceです。日本語にすると「聖杯」で、こいつのせいでスベ・・・いや、なんでもないです。
非常に簡単に使えるのが大きな特徴で、APIのルーティングをアノテーションで書くことができたり、プログラム中にboto3(AWS SDK for Python)の呼び出しがあるかどうかをチェックし、適切なIAM Policyを生成して対象のFunctionへ付与してくれます。
そんなとても便利なChaliceですが、従来のPythonマイクロフレームワークを踏襲しており、一枚のPythonスクリプトで全APIが表現され、ライブラリ等も全Functionへ同梱するモノリシックな作りとなっていて、せっかくのLambdaの依存性を排除して独立性が高いという特徴を殺してしまっているような気がしなくもありません。
Zappa
Zappa: Serverless Python Web Services
とてもおもしろいアプローチで注目を集めているのがこのZappaです。どんなアプローチかというと、API Gatewayへのリクエストを変換してPythonのWSGIというインターフェイスへ流し込むLambda Functionを全てのリクエストのエントリーポイントとすることで、WSGIをサポートする従来のPythonフレームワークを動作可能とするというアプローチですDjangoやFlaskといった従来のメジャーなフレームワークを利用できるため、それらをサポートするライブラリなどの恩恵を受けることができます。
ただし、Chaliceと同様にServerless(FaaS)の世界において、そのアプローチが正しいのかどうかには疑問が残ります。とはいえ、そんなことは気にせずに従来のフレームワークを使ってコストメリットの高いシステムを作るというのも一つの解ではあるとは思います。
Lamvery
Lamvery: User-friendly deployment and management tool for AWS Lambda function
最後に、ここまで来て自分の作ったものを紹介しないのもおかしな話なので、少しだけご紹介させていただきました。
特徴としては、YAML + Jinja2テンプレートエンジンでプログラマブルな設定ファイルとしたことや、Pythonのvirtualenv内で使うとインストールされているライブラリを自動で収集してデプロイしてくれる等の機能があげられます。
そして、他のフレームワーク（ツール）と大きく違うのが、1つのFunctionを便利かつ適切に扱うことにフォーカスしている点です。エイリアスを有効活用し、ステージング・プロダクション等のステージ分けをしやすくし、CIサービス等との親和性を高めている点や、デプロイ時にエイリアスを過去のバージョンへ付与してロールバックする際にはそのバージョンへ現在のバージョンを付け替えることで、バージョン番号を意識しない安全でフレキシブルなデプロイフローを確立します。詳しくは以下のQiita記事をご参照ください。
CircleCI + LamveryによるLambda functionのdeployベストプラクティス - Qiita
APIはあまり重視しておらず（一応機能はありますが）、Event DrivenなGlue(糊)の役割としてのLambda利用を簡単に正しく行うためのツールというイメージで作っているのがこのLamveryです。
それぞれの使い分け
フレームワーク・ツール紹介の最後に、私が思うそれぞれがマッチするユースケースをご紹介しました。
- Serverless Framework
多くのAPIを持つバックエンドシステム等を作るための最有力フレームワーク。 - Apex
SPAのバックエンドの細かいAPI等を簡単に作りたいフロントエンドエンジニア向け。 - Chalice
とにかく簡単に作りたい人向け。コーポレートサイト等をS3から配信したいけど、問い合わせフォームはほしい等のライトユースなら一番簡単に使える。 - Zappa
新しいフレームワークの学習コストを払わずに、従来のものを使ってLambdaの持つコストメリット等は享受したい。または既にDjango等で作成済みのシステムをできるだけそのまま移植したい等。 - Lamvery
Event Drivenなサービス間のGlue(糊)としてのLambda利用を簡単に正しく行えれば良い。APIはあまり重視しない。
最後に、未来のための問題提起と提案（21〜）
現状、LambdaをはじめとしたServerless(FaaS)の適用領域は以下の分類ができると思っています。
- ライトユースなAPI（前述のコーポレートサイトのお問い合わせフォームなど）
- Event DrivenなGlue(糊)としての役割
- SPA、ネイティブアプリ等のバックエンドAPI
- Micro servicesの基盤として
この中で、1と2の利用については既にServerlessConf含め色々な場面で明確なメリットが明らかになっており、現状ですぐに使い始められる領域だと思いますが、3,4についてはまだ多くの課題があると思っています。
課題
バックエンドAPIシステム開発やMicro servicesの文脈において、Serverless(FaaS)の利用には、現状のフレームワークでは解決できていない以下のような問題があると思っています。
まず、現状ではフレームワークといってもFunctionそのものや周辺リソースのデプロイや管理に主眼を置いており、本来フレームワークとして備えるべき「プログラミングモデルの誘導」のようなことは考えられていません。また、ライブラリの依存管理なども完全な個別管理や一括で全てに同梱する等といった選択肢しか取れず、十分とは言えない状況です。
また、適切な開発フローや、モニタリング・デバッグの手法も確立されておらず、個々が手探りにやっているというのが現状かと思います。
このような現状においては、ある程度の規模を超えるバックエンドAPIシステムや、Micro servicesの文脈において、既存のフレームワーク上で開発してIaaS,PaaSへデプロイすることに対する、サーバコスト以外の明確なメリットを見出すことは難しい部分があります。
そして最後に、これらを解決する一助となるかは分かりませんが、今後Serverlessなフレームワークが備えるべき機能について、以下のような提案をさせていただきました。
- Functionにタグ付けする等して、論理的なグルーピングとそれを単位としたデプロイや管理を実現する
- エイリアスやAPI Gatewayのステージ機能を活用し、CIツールの統合などを意識した実践的な開発フローを確立する
- 依存ライブラリの選択的な同梱とその依存関係の可視化
- Function間の呼び出し関係や外部リソースとの依存の管理と可視化
この提案が正しいかどうかは議論も必要かと思いますが、話しているだけでは進まない現実もあるので、私自身一部機能からServerless FrameworkのPlugin開発といった形で今後もServerlessエコシステムへの貢献いていければ良いなと思っています。
最後に
思った以上に長文になってしまいましたが、お付き合いありがとうございました。
また、主催のSection-9の吉田さん、運営・スポンサーの皆様、貴重な機会をいただき、本当にありがとうございました。
サーバーワークスは今後もよりServerlessエコシステムへの貢献を目指していきます。ご興味があれば、こちらからお問い合わせください。
