BT

イベントは分散システムの将来を変えるか - Jonas Bonér氏のQCon Londonでの講演より

| 作者: Jan Stenberg フォローする 33 人のフォロワー , 翻訳者 h_yoshida フォローする 1 人のフォロワー 投稿日 2018年4月22日. 推定読書時間: 5 分 |

原文(投稿日:2018/03/15)へのリンク

読者の皆様へ: 皆様のご要望にお応えするべく、ノイズを削減する機能セットを開発しました。皆様が関心をお持ちのトピックを、EメールとWeb通知で受け取ることができます。新機能をぜひお試しください。

イベントには注目すべき理由がたくさんある — 自律性を向上し、安定性を高め、迅速な移行を支援し、タイムトラベルを可能にする — QCon London 2018で行われたプレゼンテーションでJonas Bonér氏は、現行のシステムをイベントがどう変えるかを説明する中で、このように述べた。

Akkaの発案者でLightbend創設者のBonér氏は、20年にわたってイベントを利用してきたが、昨今のイベントの興隆には4つの理由があると考えている。

  • クラウドおよびマルチコアアーキテクチャ
  • マイクロサービスと分散システム
  • データ中心のアプリケーション
  • 顧客の需要 — “もっと欲しい、今すぐ欲しい”

Bonér氏はまず、イベントの持つ性質について説明した。イベントの本質は、情報の不変な事実である。イベントすなわち事実には、追加のみが許されている。つまり、知識は増え続けるのみなのだ。イベントを無視することは可能だが、一旦受け入れたイベントを取り消すことはできない。ただし、後続のイベントによって無効化することは可能である。

イベント駆動サービスは事実(イベント)を受け取り、それに対応する。イベントによって変化するステータスをサービス内に保持することは可能だが、それは完全に包含された、外部から参照不可能なものでなければならない。その代わりにサービスは、新たな事実を外部に発効することで事実に対応する。

イベント駆動の世界では、すべてのイベントが非同期的に動くため、すべてにおいて結果整合的である。トランザクションや強い一貫性は存在しないが、Bonér氏はそれがデフォルトであるべきだと考えている。強い一貫性は他に選択肢がない場合にのみ、ごくまれに使用されるべきである、というのが氏の意見だ。重視すべきは結果一貫性だ、と氏は強調する。それが実世界のあり方だからだ。

サービスの境界を越えれば、すぐさま分散システムやネットワークと呼ばれる非決定的な世界に足を踏み入れる。サービスとサービスの空間では予想できないことが起こる。メッセージは欠損したり、再試行されたりする。一方でネットワークは、我々にソリューションも与えてくれている — つまり、不確実性をモデル化すればよいのだ。ここでBonér氏はPat Helland氏と、氏の論文“Life beyond Distributed Transactions”を引用する。

分散トランザクションに対応できないシステムでは、不確実性の管理をビジネスロジックに組み入れる必要があります。

我々は障害に対する考え方を根本的に変える必要がある、とBonér氏は主張する。障害はごく自然に発生するものなのだ。多くの言語で障害を例外(exception)と呼んでいるのは皮肉なことだ。障害は例外などではない、起きるべくして起きるものなのだ。障害を防ぐのではなく、管理しなければならない、と氏は考えている。イベントはそのために有効である。

合理的な障害モデルでは、障害は次のようでなくてはならない。

  • 完全な自律サービスを構築するなどの方法で、カスケード障害を防ぐ。
  • イベントとして参照される。
  • 非同期に発生する。
  • ひとつあるいは多数によって監視される。
  • 障害の発生したコンテキストで管理されるが、障害自体は外部にある。

いずれも困難であることは、氏も認めている。ここで役立つと考えられるのが、イベント優先のドメイン駆動設計だ。ただし氏は、あまり早い段階で構造に目を向けるべきではない、と警告する。最初は行動や動詞(verb)、イベントに注目することが必要だ。そのためには、意図(intent)と事実(fact)を扱うようにするとよい。何を行うのかをコマンドとして表したものが意図であり、不変のイベントが事実である。

データの更新機能も大きな問題である。それにはデータが変更可能でなければならないが、それは誤りだとBonér氏は考えるからだ。ここで氏はJim Gray氏と、同氏が1981年に公表した論文“The Transaction Concept”を引用する。

その場更新(Update-in-place)はシステム設計者が大罪に問われる機能です — 数百年間にわたって遵守されてきた、従来の会計処理の慣行に反しています。

そのためBonér氏は、会計や簿記の基本原則を学び、今日開発するシステムに適用すべきだと考える。これを実現する方法はイベントロギングの利用だ。これは従来のリレーショナルデータベースが、長年行ってきた方法でもある — トランザクションログはイベントロギングなのだ。

イベントソーシングはイベントロギングに立脚したパターンであり、これらの原則をシステムに適用する上で役に立つ。ここでは、すべてのイベントを到着順に格納する。これにより、システム内で起こったすべての事の完全な履歴へのアクセスが可能になる。現在の状態のビューを生成するためには、すべてのイベントをサブスクライブすることで、必要に応じたさまざまビューを生成可能なCQRSがひとつの手段になる。イベントソーシングのデメリットは、ほとんどのソフトウェアエンジニアにとって不慣れなモデルであるということだ。イベントのバージョニングも問題になる可能性がある。

Bonér氏はイベント優先の設計によるメリットを強調して、自身の講演を結論付ける。

  • レジリエントなアーキテクチャへの迅速な移行
  • 自律的サービスの設計
  • 確実性と不確実性のバランス
  • アプリケーション刷新時のリスク低減

イベントロギングによって可能になることは、

  • CRUDの回避とORMの利用
  • システム履歴の管理
  • 時間を遡ることによるタイムトラベルとイベント再生
  • 強い一貫性と結果整合性のバランス

Bonér氏のプレゼンテーションのスライドはダウンロード可能だ。カンファレンスの主要なプレゼンテーションは録画されており、今後数ヶ月にわたってInfoQで公開される予定である。次回のQConカンファレンスであるQCon.aiは、AIとマシンラーニングに重点を置くもので、2018年4月9~11日にサンフランシスコで開催される。QCon London 2019は、2019年3月4~8日に開催が予定されている。

 
 

この記事を評価

採用ステージ
スタイル
 
 

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT