Serverless Architecture としてのイベント駆動型 PaaS の話
-
- いいね！4
naoya
@naoya_ito
もう記事になってた。はやい、ありがとうございます / “伊藤直也氏が語る、サーバーレスアーキテクチャの性質を解剖する（前編）。QCon Tokyo 2016 － Publickey” htn.to/BkyCNE
2016-10-25 07:42:53
Yuta Okamoto
@okapies
「あれ、Lambda の実装がコンテナだって明言されてたっけ」と思ってたので、なるほど。 twitter.com/naoya_ito/stat…
2016-10-25 20:08:16
naoya
@naoya_ito
@tomotaka_ito speakerdeck.com/naoya/serverle… の description に追記しました。
2016-10-25 19:01:59
Yuta Okamoto
@okapies
すんごい大雑把に言うと、同じイベント駆動でも、FaaS が状態を（捨てちゃう場合があるの前提で）持てる場合が、リアクティブマニフェストの提唱者たちが念頭に置いてるアクターモデルベースのアーキテクチャだと思うけど、さて、世の中のニーズはどっちにあるのかしら、という。
2016-10-25 20:09:59
Yuta Okamoto
@okapies
FaaS 的な完全に状態を持たないモデルだと、例えば集約処理が非常に非効率（単純なカウンタを実装するにも外部のデータストアが必要）だとか色々と「できないこと」は多いわけです。
2016-10-25 20:24:25
Yuta Okamoto
@okapies
一方で、アクターモデルだと突然死したアクターの状態をいつでも復活できるように supervisor hierarchy を用意して snapshot を取り…みたいに色々と考えることが増えるので、カジュアルさが低いのも確かであり。 slideshare.net/mobile/jboner/…
2016-10-25 20:27:51
Yuta Okamoto
@okapies
@Tanaka9230 はい、僕も同じ理解です。うまいこと流れを引き寄せるなり提携を組むなりすればワンチャンあるとは思いますが…。
2016-10-25 20:35:32
たなかこういち
@Tanaka9230
コレオグラフィーが本命のはずだけど人智を越えてる恐れがある。データフロー記述言語が登場しない限り！ twitter.com/Tanaka9230/sta…
2016-10-25 20:41:33
たなかこういち
@Tanaka9230
SOAのいにしえよりオーケストレーションとコレオグラフィというのがある。端的にオーケはProcessMgr、コレオはPub/Sub。オーケは粒度変えたトランザクションスクリプト、コレオ本命と思うが、全てイベント連鎖で書くのは人の認知能力越える恐れ。過去SOAの成功例は全てオーケ。
2016-09-30 10:22:22
たなかこういち
@Tanaka9230
SOA(プロセス粒度のコンカレント系)でもコレオ＝リアクティブはほとんどムリだったのに、MSA（プロシージャ粒度のコンカレント系）でコレオ＝リアクティブやるには、よほどの何かが必要
2016-10-25 20:47:33
たなかこういち
@Tanaka9230
プロセスレベルのデータフローにおいていわゆるトランデータが要所に置かれたが、プロシージャ粒度のデータフロー系ではそれはイベントソースのが担うとかは良い方向と思う。ただいわゆるログとトランデータを統合する必要がある。
2016-10-25 20:54:15
たなかこういち
@Tanaka9230
リアクティブはCPUをキンキンに使いきるの目的もあるけど、「データフロー処理系のランタイムとしてのリアクティブ」が @okapies さんに聞いてから、自分的な本流。
2016-10-25 20:57:42
Masayoshi Takahashi
@takahashim
@okapies カジュアルさが低いのは致命的じゃないかと思いますね…。広く使われるにはバカっぽい（褒め言葉）方が圧倒的に有利なので
2016-10-25 21:34:41
Yuta Okamoto
@okapies
@takahashim はい。なので、一枚抽象化は要ると思っています。実際に、リアクティブマニフェストの人たちは、関数ベースのデータフロー DSL で描いた処理をアクターの組み合わせにマッピングする仕組みを開発しています。 slideshare.net/okapies/scalam…
2016-10-25 21:55:52
Yuta Okamoto
@okapies
slideshare.net/mobile/okapies… @okapies pic.twitter.com/23tkVn0SQt
2016-10-26 19:38:11
拡大
Yuta Okamoto
@okapies
@takahashim あと、FaaS にしても、それを使って大規模な仕組みを作る段になれば、似たような「記述言語」は必要だろうと思います。アクターベースの上に DSL を置くメリットは、細かいすり合わせや調整がしたくなった時に「ボンネットを開ける」ことができる点だと思ってます。
2016-10-25 22:00:17
Masayoshi Takahashi
@takahashim
@okapies 確かにその懸念はありますが、一足飛びに大規模FaaSはないでしょうし、FaaSによる簡易的リアクティブな仕組みが広まった後で、改めてどうしたものかという議論になるんではないかと思っています
2016-10-25 22:14:39
Yuta Okamoto
@okapies
@takahashim そうですねー。おっしゃる通り、一通り考え方が浸透したあとに出てくるニーズ次第だと思いますし、個人的には今後が楽しみです。
2016-10-25 22:25:29
Yuta Okamoto
@okapies
んー、AWS Akka 的な提携が実現すれば Lightbend 大勝利行けるのかなー。資源利用効率的には本当は軽量スレッドが欲しいところだろうけど、現状でも Lambda はユーザごとに JVM 起動してるっぽいし、それはまぁ許容範囲なのかな。
2016-10-26 08:13:15
Yuta Okamoto
@okapies
既存の Java コードをそのまま Lambda に置き換えるのはまぁ無理なんじゃん？ っていう流れだと思うし、そうなるとフレームワークには前提を置かなくて良いから、そこに Akka が入り込む余地はあると思うんだけど。
2016-10-26 08:16:32
つかの@量子コンの入門書発売中
@snuffkin
@okapies AWS Akka、面白いですね。継続的にアクセスがあればLambdaはJVMを使い回すので、JVMの起動時間は気にならないのでは、と思います。 「非同期応答の受け方の工夫」「応答待ちの間も課金される」が課題な気がします。
2016-10-26 08:36:59
Yuta Okamoto
@okapies
@snuffkin なるほど。イベントループの部分をカスタマイズして、メータリングの仕組みを仕込んでもらえばいけるのかもしれません。
2016-10-26 08:42:14
Yuta Okamoto
@okapies
とか思ってたら、Azure Service Fabric さんに「そこはすでに我々が1年前に通過したところだ！」って怒られた。PaaS なんだけど Reliable Actors ってフレームワークが提供されてるらしい。 qiita.com/TsuyoshiUshio@…
2016-10-26 12:34:56
Yuta Okamoto
@okapies
Reliable Actors は、分散環境でインスタンスの生成とか管理をある程度透過的にやってくれる Virtual Actor パターンって考え方に基づいているらしい。MS Research の人たちの論文がこの辺に。 research.microsoft.com/apps/pubs/defa…
2016-10-26 12:38:17