tech.guitarrapc.cóm

Technical updates

ServerlessConf Tokyo 2017に参加してきた(キーノート編)

勉強会、カンファレンス、ミートアップ、言い方は違っても参加するたびに多くのことを学ばせてもらっています。普段、参加ログを書かないのですが、多くのことを人の参加記事から学んでいるので参加したセッションについて書いてみます。

※ この記事ではキーノート部分だけで、午後の個別セッションはまた明日。*1

2017/11/2,3と開催していたServerless Conf Tokyo 2017のDay2(11/3) に参加してきました。*2

http://tokyo.serverlessconf.io/home.html

2016の初開催から2年連続で参加です。去年もですが、参加して最高と感じる機会は年に数回なので本当に素晴らしかったです。

http://2016.serverlessconf.tokyo/

Software Productivity and Serverless

セッション資料 : 未公開

Nick Gottlieb - Serverless,inc.

Productivityを「Developer Productivity」と「Software Productivity」に分けて問題定義してから、Serverlessでどういった課題が解決できるのかに触れるセッションでした。

Developer Productivityを上手く改善するために、これまで様々な方法が取れてきたことからセッションが始まります。

  1. Product / Engineering Process
    • どう開発をすすめるか
  2. DevOps/Atomation
    • どうすすめるかのやり方。よりAgileになどなど
  3. Outsourced Infrastructure
    • 自分でインフラを調達するのではなくほかから調達しましょう、とか
  4. Architectures
    • microservicesも含めて、どのような構成にするのか

ただそれでも、年代を経ることでProductivityは徐々に下がってきており、推測として「複雑な開発に対して、十分なツール、方法がない?」ということに触れていました。

具体的なProductivityの障害となることを展開し、それに対してServerlessが助けとなりえることを9つ挙げていました。

  1. remove scaling from equation
    • スケーリングとか考えたくないよね。顧客の問題を解決することと、スケーリングは切り離して考える
  2. make it easy to go global
    • グローナルな提供をよりかんたんに。どこに提供するかと、アプリケーションの開発を切り離す
  3. make expelimentation cheap
    • 試すことをより安く、かんたんに。試すことに高価な対価を払うことは辞めたい
  4. tech should scale with a product
    • プロダクトの成長とともに、必要とされるものは変わってくる
    • そのたびたびで、チームの再教育など多くのことをする必要がある。会社をスケールさせるには、変化を受け入れて行く必要がある
  5. make tech as accessible as possible
    • OSSは偉大。AWSやAzureを使ったことがなくても、デプロイすればアプリが動く。このようなやりやすさ大事
  6. make it easy to customize tooling
    • やりたいことは「処理を書きたい」。Serverlessのためのツールはよりかんたんにカスタマイズできる方がいい
  7. make data accessible
    • 多くのデータはアクセスしにくい
    • でもServerlessのevent architechtureがこれを解決する。イベントはデータ。イベントにデータが詰まってくるので、必要なデータの加工や利用が可能になる
  8. make code more reusable
    • Serverlessのコードは、コード自身のメインロジックはどのServerless環境でも変わらない。再利用が可能
  9. enable low/no-code development
    • ほとんどコードを書かずに開発できる、これが理想

感想

私の場合、なぜServerlessを必要とするかの動機付けって目の前にある課題解決から始まることが多いため、では「どんなことを解決するのか」を網羅的に触れることは避ける傾向にあります。ProductivityとServerlessは断片的に触れられる文脈を見る一方で、正面から考えることがなかったので刺激的でした。面白いです。

Serverless on Microsoft Azure

セッション資料 : 未公開

Chris Risner, Thiago Almeida - Microsoft

Serverlessの定義に触れたうえで、

Scalable and reliable event based compute experience for code and workflows that accelerate the development of applications while hiding the infrastructure and providing auto-scale.

文脈から開発、環境のそれぞれに焦点を分けることから始まります。

code, workflow, development: 開発に寄与すること infrastructure, auto-scale: 環境に提供すること

ここから事例紹介をしつつ、パターンの紹介、デモでした。

例えば、Codeに関してはAzureFunctions紹介をしつつデモサイトでの処理フローをVS Codeでデバッグしつつ紹介してくれました。

  • Execute your code based on some events (イベントベースでのコード実行)
  • Azure Functions
    • Develop locally using best of class developer tools (ローカル実行による開発としてVS Codeのデバッグデモ)
    • Most productivity through trigger and bindings (TriggerとBindingsによる開発のしやすさ)
  • Functions triggers and bindings

デモに用いていたサイトがこちら。

https://carreview.azurewebsites.net/

同デモのリポジトリがこちら

https://github.com/Azure-Samples/customer-car-reviews

Azure Functions Proxyで受け口URLを抽象化しつつ、SPAなサイトでフロント待ち受け。サイトの状態はCosmosDBで保持。サイトから車の写真をアップロードすると、Blob Storageに行き、Event DrivenでFunctionsに連携。 Compute Visionで写真の解析、判定して本物の車の場合は車種などを入れつつ受け入れ、違う場合はRejectへ。リジェクトした場合は、Logic Apps経由で、メールでどうするかの確認する。メールの選択肢によってそのままRefectかApproveとして受け入れるかの「人の処理の介入」まで触れているのがとても面白いデモでした。

他にもNaviTimeの事例やFirst Gasの事例にも触れつつ、Azure Functionsでの構成を紹介してくれました。

https://microsoft.github.io/techcasestudies/cognitive%20services/2017/06/28/Navitime.html

http://customers.microsoft.com/en-us/story/first-gas-and-theta

感想

Azure Functionsはヘビーに使っていて相当好きなサービスです。その中でLogic Appsにつないでコードレスに「インタラクティブな処理」を介在させるのがとても面白いですし刺激でした。OrchestrationはDurableFunctionsでかなり解消したので、EventDriven、FaaSの先としてインタラクティブとのつなぎこみが課題に感じていたので非常に良かったです。この選択は、現状AZureが最も楽、かつ適切に組み込みやすいので着実に正当進化しつつ、利用の幅を広げていて素敵ですね。*3

Growing up Serverless

セッション資料 : 未公開のようです*4

Keisuke Nishitani - AWS

「なぜサーバーレスが必要となったのか」に触れつつ、どんな変化があり、どんな使われ方をされていて、困ることへのフレームワーク/サービスでのアプローチまで網羅的に触れているセッションでした。

Lambdaの実行ホストが、数時間でプールに戻されてパッチを当てられ続けているのは嬉しいですね。

SQUARE ENIXさんにおけるDQ11の記念撮影の処理をオンプレからLambdaに移行した事例紹介は、ちょうどいい感じでLambdaによるスケールやイベント処理が活用できる題材で面白いです。

  • 1分あたり200 - 300イメージを処理
  • ピークで1分あたり6000イメージを処理
  • 処理時間が数時間から10数秒に
  • オンプレミスとうらべ1/20までコスト削減

またサーバーレスを、ComputeなLambdaだけでなく多くのコンポーネントに触れつつ紹介されているのが良かったです。

デリバリの変化、X-Rayの登場、Map&ReduceにPyWrenと、スケールアウトの利便性と複雑性をバランスとっていくかを考えるじかんでした。

https://github.com/pywren/pywren

感想

他の方が触れない部分をきっちり抑えられているのと「提供する側としてどのような未来」が見えているのかを触れられているのが他の方とは角度の違う切り口で面白いセッションでした。

このあたりは著書にも垣間見えるので、読んでおくとセッションが面白いと感じました。

https://www.amazon.co.jp/dp/B071FZL2RZ/ref=dp-kindle-redirect?_encoding=UTF-8&btkr=1

http://keisuke69.hatenablog.jp/entry/2017/06/09/134147

実際のところ、サーバーレスってコンピュートが皮切りに出てきましたが、SaaSや(フル)マネージドサービス、とどう分けるかはまだまだ議論がありそうです。(当日の様子もそうでした) 個人的には「イベント連携できるフルマネージドなサービス」はサーバーレスビルディングブロックにいれつつ、イベント連携できない場合はサービス連携程度にゆるくとらえています。AWSやAzureだけではなく、両者あるいは他クラウドも連携させているからです。今後どうなるかは分かりませんが、説明の時に考慮することはあっても普段の利用ではそこまで気にならないような気がします。

まとめ

明日へ続く。

esaにすべて書いてあるので、公開URLしてもいいのですがそこはまぁ抜粋です。内容濃いセッションが多かった分、メモも多くなりました... いい一日でした。

*1:キーノートに関する感想記事が全然ないのですが、書いちゃだめって説明なかった認識です... もしダメなら消します

*2:tokyo.serverlessconf.ioが毎年どんどんその年のになっていくのでこういう過去の紹介時はひと手間

*3:こっそりセッション中にデモサイトへ車の写真を挙げておいたのですがVS Codeのデバッグが効いたままだったらしくPendingのままでした。上手。

*4:おおよそこれに沿っていましたGrowing up serverless