読者の皆様へ: あなたのリクエストに応じて、大切な情報を見逃すことなく、ノイズを減らす機能を開発しました。お気に入りのトピックを選択して、メールとウェブで通知をもらいましょう。
ソフトウェアシステムはイベントをもっと多用すべきだ — Randy Shoup氏は先日のブログ記事で、システムにおいてイベントが第一級市民であるべき理由について明言した。我々はイベントの持つツールとしての価値をしばしば過小評価することで、そこから得られるメリットを見過ごしている、と氏は考えている。その一例として、イベントはシステムの疎結合化に有効であり、各部分を独立して考えることを可能にする。
Shoup氏はStitch Fixのエンジニアリング担当副社長を務めている。同社は、70以上の独立したアプリケーションと、ビジネスのあらゆる面を扱うサービスを備えた環境を保持している。その中でイベントは、クライアントが服のセットを注文し、それをスタイリストが選択する(Fix Delivery)という、やや複雑なワークフローで使用されている。このワークフローは、注文、スタイリストによる選択、提供、場合によっては顧客からの一部返品、という、いくつかのステップで構成される。同社はこのワークフローをステートマシンとして実装し、ステート間の遷移にイベントを使用している。実装方法としては比較的単純だが、現在の状態だけでなく、実際のフローにおける各ステップも記録している点が特徴だ。これにより、ワークフローの履歴を確認することが可能になる。例えば、どのようなステップを経由したか、各ステップにどれ程の時間を要したか、などが分かるようになる。同社にはエンジニアリングと同規模のデータサイエンスチームがあり、彼らにとってこれは非常に重要なデータである。
Shoup氏が説明したようなマイクロサービスアーキテクチャでは、個々のサービスはイベントのコンシューマでもあり、プロデューサでもある。従ってインターフェースの定義には、イベントに関する完全な定義も含める必要がある、とShoup氏は指摘する。
エンティティの状態遷移をイベントで表現することにより、これらのイベントが履歴上の記録になる。理論上の次ステップは、状態の保持を廃止し、イベントのみによる状態の再現を可能にする、イベントソーシングと呼ばれるテクニックである。このテーマに関する権威として、Shoup氏はHGreg Young氏らの名を挙げている。さらに氏は、KafkaやAkkaといった、いずれも分散型のイベントベースシステムで使用されるツールについても言及している。
Shoup氏の経験によると、特に3層アプリケーションで使用される場合、イベントは複雑で非直感的だと思われることが少なくない。イベントでは結果整合性(eventual consistency)や非同期といった用語が多用されるため、それらを複雑だと感じる場合もあるのだ。しかしながらShoup氏は、イベントの考え方はすべての開発者に共通なものだと考えている。開発コードのバージョン管理への送信、コードのテストとデプロイなど、過去形で語られるものは、そのすべてがイベントと呼ばれるべきものなのだ。氏にとってイベントは、開発者がごく日常的に行うことなのだ。
QCon New York 2017でShoup氏は、マイクロサービスにおけるデータ管理について講演し、イベントのみを使ったコミュニケーションについて取り上げている。
この記事を評価
- 編集者評
- 編集長アクション