一生書くことはない(可能性が高い)エンタープライズアプリケーションの話

tagomoris @tagomoris

信頼性で思い出したけど、アプリケーションサーバ上にFluentd置いて、mutex保護された連番id採番プラグインがあれば、エンタープライズでも普通に使えるよね、って考えてた

Suguru ARAKAWA @ashigeru

@tagomoris そこまでやるならついでにチャンキングしてまじめにやるとたぶん普通に使えるようになると当時考えてました

tagomoris @tagomoris

@ashigeru それ、普通に、の範囲がだいぶ下の方までカバーしないといけなくてめんどくさいことが多そうｗ

tagomoris @tagomoris

たとえば銀行での取引の分散トランザクションはFluentdに乗っかるとしたらその上にアプリケーションがあれこれやるレイヤを作ることになって、そこのスループット依存になることはわかりきってるので、まあFluentd向きではないですね

tagomoris @tagomoris

でも課金や受発注での分散トランザクションだとshardがいくらでも分割できるのでアプリケーションレイヤでいくらでもやりようがあるから、やれるでしょ

Suguru ARAKAWA @ashigeru

@tagomoris 結局まじめにやるとend to endの到達保証と絶対時間内での制限付けなきゃならんのですわ。ただ、スループットが絶望的かというとそんなことはないんじゃないかと思ってます。DBのレプリケーションとかと似た感じで。

tagomoris @tagomoris

@ashigeru うん、でもそれミドルウェアで担保すべきものでは本来無い(アプリケーションの領域だ)と自分は思ってるので、Fluentdを下回りの配送に使って信頼性の担保は別レイヤでやればやれるでしょ、と

tagomoris @tagomoris

1トランザクションを極短時間で終わらせないといけないものは置いといて、それ以外であればフロントエンドで採番+ローカルディスクに書き出し+バックエンドに配送、バックエンドで処理と同時に連番idがちゃんと抜け漏れなくリアルタイムでチェックして以下略、とかやれば簡単にやれるんじゃね

Suguru ARAKAWA @ashigeru

@tagomoris んー、end to endと絶対時間保証と再送系はどっちにすべきなのかいつも悩むところではありますね。ただ、syncに近いプロトコルはアプリレイヤーだけでやっちゃいけないとは思います

tagomoris @tagomoris

@ashigeru ディスクへのsyncをトランザクションの終了要件に含めるのはイマドキは時代遅れ感があると思うけどなーとは思うけど、まあそのへんをミドルウェアとして担保するものがあるならそれを使うべき、というなら、それは同意です

Suguru ARAKAWA @ashigeru

@tagomoris あー、ローカルディスクへのっていうか、特定のendへのflush伝搬っていう意味で。

tagomoris @tagomoris

@ashigeru え、そこ？ それはアプリケーションが責任持つべきって言ってもいいと思ってるんだけどなー。だってミドルウェアは情報の価値の軽重を知らないもん。

Suguru ARAKAWA @ashigeru

@tagomoris んー、アプリとミドルの分界点次第だとは思うけど、無限に処理の開始を待機しないですむためにはアプリの要請で一気通貫のheartbeatとsyncの処理を行えるべき、って感じ。かみ合ってなかったらスマヌ

Guutara mmmmm (⁰⊖⁰) くぁwせdrftgy ふじこlp @Guutara

@ashigeru @tagomoris sync 考えられるやつは、普通のやつより、したに行くよ。w

tagomoris @tagomoris

@ashigeru いや言ってることはわかる。処理の待機がどんだけ許せるかってのはアプリケーションの都合(とその時の処理内容)によって変わるし、それをミドルウェアに対して指定して守られることを期待するか、アプリケーション側で手を尽くしてなんとかすることを考えるべきか、って話でしょ

tagomoris @tagomoris

@Guutara @ashigeru それは単に下の方を考えられる人間はアプリケーションを書く人間よりも貴重だ、という世間の認識のせいでしょｗ

Guutara mmmmm (⁰⊖⁰) くぁwせdrftgy ふじこlp @Guutara

ま、TCP/IPと、南国生まれの、Ethernet 使ってるんだから、考え方、かえろよ！ってのは、どういする。

tagomoris @tagomoris

@ashigeru で、自分の考えとしては、ちゃんと効率よく処理毎に担保する信頼性の違いをコントロールする(その方が最終的には全体の効率が良い)には、アプリケーション頑張んないとダメなんじゃないの、という

tagomoris @tagomoris

「アプリケーションなんてアホの集団が書くんだから信頼性はミドルウェアで担保するに決まってんだろ！」おっしゃる通りです、こころ洗われる考えかたですね(棒読

Guutara mmmmm (⁰⊖⁰) くぁwせdrftgy ふじこlp @Guutara

@tagomoris @ashigeru 少ないのが、貴重だとは、限らんのだよ。:p ただ、いまのお二人さんのような、会話は、しないだろうという、事実だね。やぁ、Sync 三回叩けば、いいっていわれたんで、えへへ。みたいな。

Suguru ARAKAWA @ashigeru

@tagomoris そそ。ミドルで通信路確保してるなら、その通信路外でやっても効果が薄い可能性があるなーって話。もちろんやってやれなくないということは承知の上で。

tagomoris @tagomoris

俺はアプリケーション開発者が下の方まですべて考えてコードを書く世界が素晴らしいしそうなってほしいなーと思っていますよ

tagomoris @tagomoris

@ashigeru ああ、そういう意味では個別の経路の効率は多少犠牲にした上ででも、別のミドルウェアを組合せてアプリケーションがend-to-endで複数の経路をコントロールすべきなんじゃないかってのが自分の意見ですね

tagomoris @tagomoris

なぜ俺はもう一生書くことはない(可能性が高い)エンタープライズアプリケーションの話をこのような夜中にしているのだろう

Guutara mmmmm (⁰⊖⁰) くぁwせdrftgy ふじこlp @Guutara

@tagomoris すごい、人間性がすけてみえるぞ！w そういうかんじは、好きじゃないな。 ただ、数の論理で、たくさんいる方が、振り幅はおおきくなるって、だけじゃないかね。