tech.guitarrapc.cóm

Technical updates

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

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

Azure AWS Serverless Review AWSLambda AzureFunctions

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

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

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

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

2016 の初開催から2年連続で参加です。去年も思いましたが、これほどまでに参加して最高と思う機会は年に数回なので本当に素晴らしかったです。

http://2016.serverlessconf.tokyo/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紹介をしつつデモサイトでの処理フローをVSCode でデバッグしつつ紹介してくれました。

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

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

https://carreview.azurewebsites.net/

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

github.com

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

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

microsoft.github.io

customers.microsoft.com

感想

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 と、スケールアウトの利便性と複雑性をバランスとっていくかを考えるじかんでした。

github.com

感想

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

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

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

keisuke69.hatenablog.jp

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

まとめ

明日へ続く。

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

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

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

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

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