深夜のDAGの議論のまとめ

Masayoshi Hagiwara @masayh

最近、クラウドのインフラとアプリケーション、ロジックと人による補償、同期と非同期などの境界に関する議論があったが、これらも時代とともに変わっていくのだろう。揺り戻しと進化と。

Masayoshi Hagiwara @masayh

状態遷移のスコープをresourceと考えれば、そのresourceを適切に切り出す手法がMERODEです。クラウドで状態遷移を追跡する必要がある個所からオブジェクトを切り出します。@asami224 usecase(利用事例)=event列=resourceの状態遷移の列。

Masayoshi Hagiwara @masayh

@asami224 匠のオープンセミナーのトランザクションハブはCEPやHadoopの技術で実行するので、そこにDAGを入れていくことは可能です。Gartnerはそれをさらに発展させるビジネスルールやパターンベースのやり方を考えています。

Masayoshi Hagiwara @masayh

ビジネスプロセス、ソーシャルネットワーク、バリューチェインの3つを統一的に分析していく手法を考えることです。クラウドでビジネスプロセス、その一部のバッチ的な実行であるワークフローやHadoopの実行だけを考えていてはいけません。

Masayoshi Hagiwara @masayh

クラウドでの本質的なモデル対象であるUoWをモデル化するためには、存在依存性という概念を導入します。通常の概念モデル設計でも無意識にモデル化していた部分ですが、この概念を導入し明示的にモデル化することで、UoWの一貫性をモデル検証できます。

Suguru ARAKAWA @ashigeru

@okachimachiorz @shot6 欠けてる視点をご指摘いただけると: http://ashigeru.com/memo/adag.png

@okachimachiorz

@ashigeru 業務的には買掛金の残高更新とか、こんな感じだと思う。SourceAについても条件はいると思う。キックはAからだとおもうので、冪等という意味では、上の赤いラインのみがフローの主体になるかな。両方ってのはありうるとは思うけど、再利用性が低い。

Suguru ARAKAWA @ashigeru

@okachimachiorz ありがとうございます。一筋縄でいかなさそうな感じがありますね…。実用的にはアトミックオペレーションをジョブコントローラでSERIALIZABLEと同等になるようにスケジュールするだけにして、個別は力技って感じのほうがいいかもしれません

@okachimachiorz

@ashigeru jobの分離性の確保は、モデリング依存だと思いますが、それは割とセンスが要りますね、ってのが現在の結論ですね。うまくいくと、やはり再利用性があがる。ただし、本来はベストが自動化です。

Suguru ARAKAWA @ashigeru

@okachimachiorz 全体最適化を考えると自動化は避けて通れない感じもしますね。SERIALIZABLEだけならデータフロー的に依存関係があるジョブをブロックするだけなのでたぶん自動化は可能ですが、モデリングから明示的に記述されない部分はかなり微妙です

@okachimachiorz

@ashigeru 逆にできあがったものから、リバースして、制約条件が見れた方がいいかも。結構、便利だとおもう。

Suguru ARAKAWA @ashigeru

@okachimachiorz なるほど。たぶんDAGのほかにガントチャートみたいなものを自動的に引けますね

@okachimachiorz

@ashigeru 検証できるとうれしいのよね～。このvertexは飛ばしてもOkとか。わかると機能の分離実装ができる。多分、品質もあがる。

Masayoshi Hagiwara @masayh

いや、DAG vertexは論理なので、物理で障害があったら別の正常なノードで実行するということになると思う。だから、飛ばしてOKはなくてもいいと思えます。@okachimachiorz このvertexは飛ばしてもOkとか。わかると機能の分離実装ができる。品質もあがる。

Masayoshi Hagiwara @masayh

DAGの性質として、負荷分散や入力の待ち合わせ同期がモデルの意味に含まれているので、それを実装にマップできるようなHadoop上のミドルが必要です。障害時のjobのfailoverもvertexの意味にカプセル化されるはずです。その他にもDAGの多くの意味を乗る必要があります。

@okachimachiorz

@masayh どちらかというと、飛ばした論理を別の論理に置き換えられる、かどうかがわかるとうれしいって感じです。

Masayoshi Hagiwara @masayh

@okachimachiorz 飛ばした=skipということですか？processの可変性がある処理？僕は、飛ばす＝障害のことと思っていました。

@okachimachiorz

できるかどうかはともかく、チームはチャレンジしている感じです。機能は限定されますがDSLライクにつくれないか？と模索中。QT @masayh: DAGの性質として、負荷分散や入力の待ち合わせ同期がモデルの意味に含まれているので、実装にマップできるようなHadoop上のミドル

Suguru ARAKAWA @ashigeru

@okachimachiorz factoringといえばいいのか、「人間が組み替えて共通処理を抽出するためのヒントになる図」がほしい、というニュアンスですかね？

@okachimachiorz

@masayh あぁ.言葉足らずで申し訳ないです。DAG実装の再利用を考えたときに、可換性の確保が必要で、有る条件を満たせばdispachできるvertexがあれば、そこへ別の論理を埋め込んで、全体で別の業務が作れるだろうという発想です。

Shinpei Ohtani @shot6

@ashigeru @okachimachiorz 概観はこんなのでよいと思います。Source(A)のリロードは再試行で必須じゃないすかね。あと、同期とらせるのがどうやるか、ですね。

@okachimachiorz

@ashigeru ですね～。グラフの部分同定がNP完全であれば、ある程度発見的にやる必要があるので、パズルのヒントが欲しいというところですね。

Shinpei Ohtani @shot6

@ashigeru @okachimachiorz あと、この図だとDAGで出来上がったあとにジャーナルを書き出すポイントがあるのでそれをうまく図示しないと設計時はきついのではないかと。

Masayoshi Hagiwara @masayh

これはDAGのdataflowだけで別のvertexを通るようにすればできるはず。問題は循環しないようにすること。@okachimachiorz 有る条件を満たせばdispachできるvertexがあれば、そこへ別の論理を埋め込んで、全体で別の業務が作れるだろうという発想です。

Suguru ARAKAWA @ashigeru

@shot6 ありがとうございます。同期はジョブコントローラが、アトミック処理以降のプロセスを待機させるようなスケジュール組むイメージで考えてました。スレッドの同期とほぼ同じような感じです @okachimachiorz